1 INFO-VAX	Wed, 26 Jun 2002	Volume 2002 : Issue 349       Contents:! Re: $CRMPSC and memory management ! Re: $CRMPSC and memory management ; Re: A possible shift in the status of VMS ar HP ???? ERRATA ; Re: A possible shift in the status of VMS ar HP ???? ERRATA ; Re: A possible shift in the status of VMS ar HP ???? ERRATA 8 Re: Amdrew wants numbers, here they are!  Blow out baby!8 Re: Amdrew wants numbers, here they are!  Blow out baby!8 Re: Amdrew wants numbers, here they are!  Blow out baby!8 Re: Amdrew wants numbers, here they are!  Blow out baby!8 Re: Amdrew wants numbers, here they are!  Blow out baby!8 Re: Amdrew wants numbers, here they are!  Blow out baby!8 Re: Amdrew wants numbers, here they are!  Blow out baby!8 Re: Amdrew wants numbers, here they are!  Blow out baby! another press release  Re: another press release C BACKUP/INCREMENTAL not parsing directories properly during restores G Re: BACKUP/INCREMENTAL not parsing directories properly during restores G Re: BACKUP/INCREMENTAL not parsing directories properly during restores " Capellas resigns from Dynegy board Re: Case sensitive identifiers dec 3000-300LX mobo  Re: HSZ50 and RZ1DF-CB" Re: Intel booting contest - Update" Re: Intel booting contest - Update" Re: Intel booting contest - Update$ Intel Wall Street Journal Itanium Ad( Re: Intel Wall Street Journal Itanium Ad IPSEC ?  Re: IPSEC ? $ Re: Middle European DST change rules Re: More good news Re: More good news Re: More good news Re: Open Letter to HP  Re: Open Letter to HP  Re: Open Letter to HP  Re: Open Letter to HP  Re: Open Letter to HP  Re: Open Letter to HP  Re: Open Letter to HP # OpenVMS Alpha V7.3 - system lockups ' Re: OpenVMS Alpha V7.3 - system lockups  Re: OpenVMS on CNBC  Re: OpenVMS on CNBC  Re: OpenVMS on CNBC  Re: OpenVMS on CNBC  Re: OpenVMS on CNBC  Re: OpenVMS on CNBC  Re: OpenVMS V7.3-1 Announcement  Re: OpenVMS V7.3-1 Announcement  RE: OpenVMS V7.3-1 Announcement ? Re: Process Software does SSH for TCP/IP Services - new release & remote node is not currently reachable& remote node is not currently reachable* Re: remote node is not currently reachable* Re: remote node is not currently reachable3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 2 Send again: remote node is not currently reachable4 Success Re: Euro symbol, DECterm, Hummingbird ExceedL support for OpenVMS V7.3 by the Brooks-PRI Automation PROMIS MES application
 Re: TCO study 
 RE: TCO study 
 Re: TCO study 
 Re: TCO study 
 Re: TCO study 
 Re: TCO study 
 Re: TCO study 
 Re: TCO study 
 RE: TCO study 
 Re: TCO study 
 Re: TCO study  Trouble with BACKUP/RECORD Re: Trouble with BACKUP/RECORD Re: VMS port delayed!  Re: VMS port delayed!  Re: VMS port delayed!  Re: wow   F ----------------------------------------------------------------------  # Date: Wed, 26 Jun 2002 09:48:35 GMT  From: system@SendSpamHere.ORG * Subject: Re: $CRMPSC and memory management0 Message-ID: <00A1005D.93A0AB76@SendSpamHere.ORG>  F In article <slrnahhpqm.d7o.danco@pebble.org>, danco@pebble.org writes:< >In article <3D18D1F8.2F42998B@gte.net>, Robert Davis wrote:G >> Sorry I wasn't clear ... I do know the size of the second section at I >> the fixed address and it's relatively small. So once I know what's the I >> 'safe' top end, I can easily decide the start address. I'm mostly just E >> a little unclear about the relationship between VIRTUALPAGECNT and @ >> P0/P1, and where that makes P0/P1 begin/end, and exactly what >> addresses are available.  > B >So far as I know, VIRTUALPAGECNT has no bearing on where P0 ends,A >at least not in the normal OpenVMS user mode program.  P0 begins @ >at 0 and ends at 4FFFFFFF.  You can map to any address range in   Incorrect...  * P0 space begins at 0 and ends at 3FFFFFFF.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------    Date: 26 Jun 2002 08:38:17 -0600- From: koehler@encompasserve.org (Bob Koehler) * Subject: Re: $CRMPSC and memory management3 Message-ID: <XIzauwbugYeg@eisner.encompasserve.org>   O In article <3D18C119.D74FC50F@gte.net>, Robert Davis <res057y3@gte.net> writes:  > G > I'm trying to understand a little more about VMS memory management so ? > I can pick the 'best' address to map a shared memory section.   D    Generally it's a bad idea to base images.  Let the system map the$    image and tell you where it went.  M    We had one shareable writeable image which was based because it contained  G    a pointer to data in itself.  Basing it meant everybody saw the same B    pointer value and that pointer was correct.  This broke when we@    updated from VMS 6.0 to 6.1.  Simply using a relative pointerF    eliminated the need for basing.  All references to the image are byH    variable name, which is resolved correctly by cooperation between the&    compiler, linker, and image loader.   ------------------------------  % Date: Wed, 26 Jun 2002 03:05:54 -0400 ( From: David Froble <davef@tsoft-inc.com>D Subject: Re: A possible shift in the status of VMS ar HP ???? ERRATA( Message-ID: <3D1967D2.100@tsoft-inc.com>   John Smith wrote:   > > "Terry C. Shannon" <terryshannon@attbi.com> wrote in message; > news:rg3S8.176145$6m5.147186@rwcrnsc51.ops.asp.att.net...  > 	 >>terry s " >>Shot in Foot With Own Gun, Again    3 When it's the foot, it's usually your own gun.  :-)    >> > E > At the risk of starting a 'war', perhaps it's time for gun control?     Q I agree completely.  Let's keep them out of the hands of criminals and such, and  4 in the hands of honest citizens.  Great gun control!   Dave   ------------------------------  % Date: Wed, 26 Jun 2002 06:57:58 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)D Subject: Re: A possible shift in the status of VMS ar HP ???? ERRATAK Message-ID: <rdeininger-2606020657580001@11cust99.tnt1.nashua.nh.da.uu.net>   A In article <1Q6S8.151538$nZ3.65801@rwcrnsc53>, "Terry C. Shannon"  <terryshannon@attbi.com> wrote:     L >Agreed! Time will tell. Perchance there will be tales to tell subsequent to >my next pilgrimage to ZKOland.     B And when might we expect that to happen?  Or is it only for paying customers to know?   ------------------------------  # Date: Wed, 26 Jun 2002 13:14:29 GMT # From: "John Smith" <a@nonymous.com> D Subject: Re: A possible shift in the status of VMS ar HP ???? ERRATAD Message-ID: <V6jS8.114$MIK.101@news01.bloor.is.net.cable.rogers.com>  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in message E news:rdeininger-2606020657580001@11cust99.tnt1.nashua.nh.da.uu.net... C > In article <1Q6S8.151538$nZ3.65801@rwcrnsc53>, "Terry C. Shannon" ! > <terryshannon@attbi.com> wrote:  >  > K > >Agreed! Time will tell. Perchance there will be tales to tell subsequent  to! > >my next pilgrimage to ZKOland.  >  > D > And when might we expect that to happen?  Or is it only for paying > customers to know?      B Personally, I'd like to get into ZKO too, poke around and ask someJ questions. But I somehow doubt HP will let me. So my proxy, Terry, does it instead.  K If companies were as forthright with customers as they ought to be, perhaps J we wouldn't need the services of people like Terry. But since he does haveI so ability to get 'inside', both physically and temporally, and you and I K don't have that ability, give the man a chance to make a living. We'll find I out sooner from Terry, even if it is later than 'tomorrow afternoon' :-), J what HP will wait to tell us for months. For those who need to know before) yesterday, unfortunately you have to pay.   G In the on-line newspaper world, its the latest news that's free and the L archives that cost money. For Terry, it's the inverse. It costs money to flyG to these places, and the man has to eat.....how else does Terry pay for  that?    ------------------------------  / Date: Wed, 26 Jun 2002 09:27:38 +0200 (MET DST) & From: Rudolf Wingert <win@fom.fgan.de>A Subject: Re: Amdrew wants numbers, here they are!  Blow out baby! 6 Message-ID: <200206260727.JAA10594@sinet1.fom.fgan.de>   Hello,  F Andrew (sorry Andrew for miswriting your name within the subject) if I7 did compute right, your argument is not very powerfull:    	1. SPECint2000 4 	   EV68:        1.0GHz --> 1.25GHz = 1.25*679 = 8506 	   UltraSparc:  0.9GHz --> 1.05GHz = 467/9*10.5 = 545   	2. SPECfp20006 	   EV68:        1.0GHz --> 1.25GHz = 1.25*950 ~= 11736 	   UltraSparc:  0.9GHz --> 1.05GHz = 482/9*10.5 = 562  B If I see this right, the UltraSparc with 1.05GHz will not have theC performance of the 1.0GHz Alpha (EV68). If the Marvel is out (EV7), A then you will see a new one performance boost. You can't tell me, A that the CPU performance will have to do nothing with the overall A performance. All the new one systems will have crossbar switching B architecture like Sun with a very good memory and I/O performance.B With Marvel HPAQ a new architecture will come. Every CPU will haveE a four way CPU bus. In case of this the max. delay of inter processor B communication will be less then the min. within the crossbar. Also? will this chip have an eight way 1.8MB onchip cache, which will D groth the performance too. If I count 1+1 together, I will see, thatB the Alpha is a good chip with a competative performance and price.   Regards Rudolf Wingert   ------------------------------  # Date: Wed, 26 Jun 2002 09:22:04 GMT * From: "Bill Todd" <billtodd@metrocast.net>A Subject: Re: Amdrew wants numbers, here they are!  Blow out baby! B Message-ID: <0JfS8.406124$%y.29773894@bin4.nnrp.aus1.giganews.com>  3 "Rudolf Wingert" <win@fom.fgan.de> wrote in message 0 news:200206260727.JAA10594@sinet1.fom.fgan.de... > Hello, > H > Andrew (sorry Andrew for miswriting your name within the subject) if I9 > did compute right, your argument is not very powerfull:  >  > 1. SPECint20005 >    EV68:        1.0GHz --> 1.25GHz = 1.25*679 = 850 7 >    UltraSparc:  0.9GHz --> 1.05GHz = 467/9*10.5 = 545  >  > 2. SPECfp2000 7 >    EV68:        1.0GHz --> 1.25GHz = 1.25*950 ~= 1173 7 >    UltraSparc:  0.9GHz --> 1.05GHz = 482/9*10.5 = 562  > D > If I see this right, the UltraSparc with 1.05GHz will not have the) > performance of the 1.0GHz Alpha (EV68).   L While that happens to be true, the way to derive it is from the SPEC results themselves, not by calculation.   L What you don't seem to see is that having a great CPU doesn't guarantee thatL you'll have a great system.  Both Sun and SGI have traditionally had systemsL that made very good use of their middle-of-the-road CPU performance, whereasH (aside from the ES40/45 and smaller AlphaServers) Alpha systems have notI made anything like optimal use of their leading CPUs.  The result is that ; Sun and SGI systems compete very effectively with Alphas in < larger-than-4-processor configurations, despite slower CPUs.    If the Marvel is out (EV7),0 > then you will see a new one performance boost.  G That's probably true.  But Andrew has confined his comments to shipping G products, not future products (however promising) that have not yet had ) their performance properly characterized.     You can't tell me, C > that the CPU performance will have to do nothing with the overall  > performance.  K He hasn't tried to:  he's just been saying that other areas can matter just J as much, and that Alpha has, so far, been somewhat lacking in some of themJ to the point where the advantage of its leading CPU performance is largely lost.   E You really can't have a sensible discussion with someone if you don't H understand what he is saying.  I realize that English is not your nativeB language, but that should cause you to make an extra effort when aL difference of opinion arises rather than just to assume that the other party	 is wrong.    - bill   ------------------------------  % Date: Wed, 26 Jun 2002 11:43:37 +0100 U From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com> A Subject: Re: Amdrew wants numbers, here they are!  Blow out baby! 0 Message-ID: <afc5qv$8uv$1@new-usenet.uk.sun.com>   Rudolf Wingert wrote:    > Hello, > H > Andrew (sorry Andrew for miswriting your name within the subject) if I9 > did compute right, your argument is not very powerfull:  >  > 	1. SPECint2000 6 > 	   EV68:        1.0GHz --> 1.25GHz = 1.25*679 = 8508 > 	   UltraSparc:  0.9GHz --> 1.05GHz = 467/9*10.5 = 545 >  > 	2. SPECfp20008 > 	   EV68:        1.0GHz --> 1.25GHz = 1.25*950 ~= 11738 > 	   UltraSparc:  0.9GHz --> 1.05GHz = 482/9*10.5 = 562 > D > If I see this right, the UltraSparc with 1.05GHz will not have theE > performance of the 1.0GHz Alpha (EV68). If the Marvel is out (EV7), C > then you will see a new one performance boost. You can't tell me, C > that the CPU performance will have to do nothing with the overall C > performance. All the new one systems will have crossbar switching D > architecture like Sun with a very good memory and I/O performance.D > With Marvel HPAQ a new architecture will come. Every CPU will haveG > a four way CPU bus. In case of this the max. delay of inter processor D > communication will be less then the min. within the crossbar. AlsoA > will this chip have an eight way 1.8MB onchip cache, which will F > groth the performance too. If I count 1+1 together, I will see, thatD > the Alpha is a good chip with a competative performance and price. >     @ I don't think you get it either. I have virtually no interest in= single CPU SPECint or SPECfp numbers and only marginally more > than that in SPECrate numbers. This is because they only model9 a specific set of almost entirely CPU bound applications.   < They don't do I/O, they arn't particularly latency or memory: bandwidth dependant (SPECfp more so) and now that IBM have9 found a way of running them almost entirely in cache they 1 don't even really need a memory subsystem at all.   8 Alpha has always given great SPECint and SPECfp numbers,8 but a system is a combination of CPU's memory subsystem,7 I/O, OS and apps, and for a variety of reasons when you 8 drop an Alpha processor into a system and saddle it with7 the job of being part of a team it doesn't play so well 4 or rather some of the other team members arn't up to scratch.  6 Just as an example Compaq mistakenly compare the GS320< with a Sun F15000, this is a mistake based on the benchmarks7 that Compaq themselves published for the box but if you 4 look at speeds and feeds inside the systems you get.   1.  0 Local memory latency, both the GS and the F150008 are NUMA systems the lowest local memory latency in a GS> is 3x longer than the lowest local memory latency in a F15000.   2.  7 Remote memory latency, the lowest remote memory latency ? in the GS320 is 3x longer than the lowest remote memory latency  in a F15000. 3.  9 Bisectional bandwidth, the GS320 switch has a bisectional 7 bandwidth of ~15 GB/s the F15000 43 GB/s ~3x different.  4.  4 Total local memory bandwidth, the GS has 8 QBBS each= has a quoted maximum of 6.4 GB/s for a total system bandwidth : (apparently) of 51 GB/s. The Sun F15000 has a total system" bandwith if all local of 178 GB/s. 5.  6 The GS320 has a maxium I/O bandwidth of 12 GB/s, halve> this for actual throughput as Compaq havn't ever published any@ I/O benchmarks to proves this an 50% is a good rule of thumb for@ their bandwidth claims. The F15000 has a maxium I/O bandwidth of> ~20 GB/s and we have demonstrated 12 GB/s disk I/O pretty good/ and ~2x what the GS is likely to be capable of.2  : And this is before you get to the fact well covered in the7 past that Sun quotes acheivable throughput numbers wille Compaq does not.  = This illustrated by the GS320 running Tru64 with local memory @ placement optimisation getting 21 GB/s using STREAMS copy, while% the F15000 gets 56 GB/s STREAMS copy.m  9 And then people wonder why the GS320 doesn't perform whenw6 compared with a F15000 ! and why people like me object5 to the GS320 being grouped size wise with the F15000.m  6 It isn't rocket science, the reason why the GS does so6 badly at actual benchmarks is that its internals don't match its competition.  4 Now do this same excercise with the 8400/SunE6500 or5 even if you want real laughs with the 8400/Sun E10000s< and you get exactly the same story for previous generations.     Regards    Andrew HarrisonC   ------------------------------    Date: 26 Jun 2002 05:55:29 -0700( From: bob@instantwhip.com (Bob Ceculski)A Subject: Re: Amdrew wants numbers, here they are!  Blow out baby!s= Message-ID: <d7791aa1.0206260455.3ca41f77@posting.google.com>   e "rob kas" <rob@paychoice.nospam.com> wrote in message news:<3d18c13d$0$1421$8e9e3842@news.atx.net>...  > Bob  > 7 >  Do you ever think about what you read or do you just  >  regurgitate Web Pages ? > 9 > You do know that is comparing the lasest GREATEST AlphaPK >  againest a older SUN chip. And all thing considered not much better thens > IBM's P4.o > : > By the way I am looking foward to meeting you at the VMS > Roadshow.e > $ >                                Rob >   @ and you think the newer sparky is going to overtake the EV68 ... I don't think so ...   ------------------------------    Date: 26 Jun 2002 05:59:37 -0700( From: bob@instantwhip.com (Bob Ceculski)A Subject: Re: Amdrew wants numbers, here they are!  Blow out baby!n= Message-ID: <d7791aa1.0206260459.5501028a@posting.google.com>3  u "Bill Todd" <billtodd@metrocast.net> wrote in message news:<zQ7S8.439346$Oa1.31010046@bin8.nnrp.aus1.giganews.com>...o7 > "Bob Ceculski" <bob@instantwhip.com> wrote in messager9 > news:d7791aa1.0206251455.5842cd40@posting.google.com...e >  > ...e > I > > the clue is Andrew, if you expect someone to believe that a processorkA > > with triple the floating point performance and double the inte > N > Hmmm.  Perhaps you're an idiot in the technical sense of the term as well asH > the colloquial one.  You certainly don't appear to have mastered basic > arithmetic, anyway.m > K > 467 * 2 = 934.  The new Alpha hits only 850 SPECint, so even based on the L > Inquirer's data (without realizing that it just happened to ignore USIII'sJ > top-of-the-line 1050 MHz processor) the Alpha doesn't double the SPECintK > performance.  Use the top-of-the-line USIII SPECint number (which is 610,tN > not that I expect you to be aware of it, off in your own little world as youJ > are) and the Alpha edge dwindles farther to a bit under 1.4x:  certainly* > decent, but nothing like what you claim. > N > Same problem with the SPECfp numbers, of course - at least you're consistentN > in your ignorance, though it gets pretty 'old' after far less exposure to itL > than you insist on providing.  And, of course, you've consistently ignoredL > Andrew's point from the beginning that great single-processor SPEC numbers) > do not necessarily a great system make.  > K > Pretty much batting .000 as usual, Bob.  After this long, I'm not holding   > out much hope for improvement. >  > - bill  D it's called rounding Bill, something Sun drastically does with their) numbers to make them look competitive ...-   ------------------------------    Date: 26 Jun 2002 11:52:33 -0600+ From: young_r@encompasserve.org (Rob Young)dA Subject: Re: Amdrew wants numbers, here they are!  Blow out baby!>3 Message-ID: <ay$VIouPV10A@eisner.encompasserve.org>c  \ In article <3D19F13D.69DD33C8@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Rudolf Wingert wrote: E >> If I see this right, the UltraSparc with 1.05GHz will not have theiF >> performance of the 1.0GHz Alpha (EV68). If the Marvel is out (EV7),1 >> then you will see a new one performance boost.t > O > I have only heard of EV7 for Wildfire/Marvel type systems being deployed. ArehL > there plans to deploy EV7 chips in ES and the DS systems ? I was under theO > impression that the mnimum requirements for the chip would not bode well with  > smaller systems (memory etc).r >    	Yes.  Check this out:  9 http://www.compaq.com/hps/announce/alphaserver_image.htmlo  A 	While details are lacking (I can't find them ... feel free) that H 	box out front is obviously fairly small... guess is it is a 2 processor 	(no less than 2) box.  M > If a significant number of alpha systems will continue to be sold with EV6x 2 > CPUs, then EV7 may not benefit that many people.  @ 	Demarcation line in performance.  Buy it if you need it.  Don't 	if you don't.   				Robg   ------------------------------  % Date: Wed, 26 Jun 2002 12:52:13 -0400o- From: JF Mezei <jfmezei.spamnot@videotron.ca>'A Subject: Re: Amdrew wants numbers, here they are!  Blow out baby! , Message-ID: <3D19F13D.69DD33C8@videotron.ca>   Rudolf Wingert wrote: D > If I see this right, the UltraSparc with 1.05GHz will not have theE > performance of the 1.0GHz Alpha (EV68). If the Marvel is out (EV7), 0 > then you will see a new one performance boost.  M I have only heard of EV7 for Wildfire/Marvel type systems being deployed. ArevJ there plans to deploy EV7 chips in ES and the DS systems ? I was under theM impression that the mnimum requirements for the chip would not bode well with. smaller systems (memory etc).r  K If a significant number of alpha systems will continue to be sold with EV6x 0 CPUs, then EV7 may not benefit that many people.   ------------------------------  % Date: Wed, 26 Jun 2002 13:16:22 -0400i- From: JF Mezei <jfmezei.spamnot@videotron.ca>pA Subject: Re: Amdrew wants numbers, here they are!  Blow out baby!3, Message-ID: <3D19F6E4.7F9A9BFA@videotron.ca>   Bob Ceculski wrote:oF > it's called rounding Bill, something Sun drastically does with their+ > numbers to make them look competitive ...r  I In the end, what counts most ? The actual performance of a system, or they8 number of systems sold because you have good marketing ?   ------------------------------  # Date: Wed, 26 Jun 2002 15:26:57 GMTt2 From: "Sue Skonetski" <susan.skonetski@compaq.com> Subject: another press release2 Message-ID: <53lS8.39$Dk6.509045@news.cpqcorp.net>  8  Just got this Press Release, thought you might like it. suem FOR IMMEDIATE RELEASE.    CONTACT INFORMATION   TECSys Development, LP   Phil Reinkemeyer   972.881.1553   800.695.1258   info@tditx.com  
 www.tditx.comc    I TECSys Development, LP (TDi) Increases Security For Enterprise Management3G TDi Releases Latest Version of ConsoleWorks with SSL and SSH Capabilitym    I Plano, Texas, June 25, 2002 - TECSys Development, LP (TDi), the leader inrI enterprise management and monitoring software, today announced the latesto? release and new feature set of TDi's premiere software product,-
 ConsoleWorks.,  F TDi's ConsoleWorks is a Web-based solution that provides secure remoteL monitoring and management for enterprise networks or devices.  ConsoleWorks'F unique management is achieved through the use of the console interfaceB without using a software agent.  ConsoleWorks provides a cohesive,L integrated, and centralized management solution for use with in-band or SNMP based products.n  H  ConsoleWorks latest release features the ConsoleWorks secure Web serverH with Secure Socket Layer (SSL) and Secure Shell (SSH) capabilities.  SSLH provides an encrypted communication path between the Web browser and theL ConsoleWorks Web server, and the SSH capabilities provide encryption betweenI ConsoleWorks and the terminal server.  TDi built the secure Web server totF ensure that our customers have the highest level of security for theirK enterprise management software.  "The front to back encryption enhances the H other levels of security within ConsoleWorks, and with security being soL important in today's infrastructure, TDi feels this is an important additionL to our product and a major benefit to our customers," said Phil Reinkemeyer,, TDi's Vice-President of Sales and Marketing.  L  TDi has received approval from the federal government to begin shipping theF ConsoleWorks SSL security option to customers overseas.  Bill Johnson,K President of TDi stated, "We are proud to bring the only out-of-band securerI Web-based console management solution to our customers.  ConsoleWorks can C now eliminate the concern of security with regard to remote consoleo management."    About TECSys Development, LP   L TECSys Development, LP is a private corporation dedicated to the developmentE and marketing of enterprise management software for a wide variety ofaL operating systems and vendors such as Windows NT, Unix, and OpenVMS, such asI SUN, Compaq, Cisco, IBM, and Intel.  TDi's focus is to develop and marketpC enterprise management solution for users who need state-of-the-art, J automated lights-out solutions.  TDi also seeks to improve performance andI management in systems used by IT operations and systems support personnel C with advanced technology software products that utilize the maximum H potential of hardware and software configurations. For more information,H please visit TDi at www.tditx.com, email questions to info@tditx.com, or call 972-881-1553.  K  TECSys Development, LP, TDi, and ConsoleWorks are registered trademarks ofnH TECSys Development, LP.  Product names mentioned herein maybe trademarks; and/or registered trademarks of their respective companies.    ------------------------------  # Date: Wed, 26 Jun 2002 16:12:52 GMTi2 From: "Sue Skonetski" <susan.skonetski@compaq.com>" Subject: Re: another press release2 Message-ID: <8KlS8.44$8g6.316515@news.cpqcorp.net>   This is a VMS application.   sueo      = "Sue Skonetski" <susan.skonetski@compaq.com> wrote in messager, news:53lS8.39$Dk6.509045@news.cpqcorp.net...9 > Just got this Press Release, thought you might like it.t > suee > FOR IMMEDIATE RELEASEe >d >  CONTACT INFORMATION >- > TECSys Development, LP >e > Phil Reinkemeyer >2 > 972.881.1553 >l > 800.695.1258 >e > info@tditx.com >: > www.tditx.com  >b >,K > TECSys Development, LP (TDi) Increases Security For Enterprise ManagementnI > TDi Releases Latest Version of ConsoleWorks with SSL and SSH Capabilityg >  >sK > Plano, Texas, June 25, 2002 - TECSys Development, LP (TDi), the leader innK > enterprise management and monitoring software, today announced the latestyA > release and new feature set of TDi's premiere software product,6 > ConsoleWorks.- >1H > TDi's ConsoleWorks is a Web-based solution that provides secure remote? > monitoring and management for enterprise networks or devices.G
 ConsoleWorks'=H > unique management is achieved through the use of the console interfaceD > without using a software agent.  ConsoleWorks provides a cohesive,I > integrated, and centralized management solution for use with in-band ore SNMP > based products.  > J >  ConsoleWorks latest release features the ConsoleWorks secure Web serverJ > with Secure Socket Layer (SSL) and Secure Shell (SSH) capabilities.  SSLJ > provides an encrypted communication path between the Web browser and theF > ConsoleWorks Web server, and the SSH capabilities provide encryption betweennK > ConsoleWorks and the terminal server.  TDi built the secure Web server toeH > ensure that our customers have the highest level of security for theirI > enterprise management software.  "The front to back encryption enhancese the J > other levels of security within ConsoleWorks, and with security being soE > important in today's infrastructure, TDi feels this is an importants additionA > to our product and a major benefit to our customers," said Philt Reinkemeyer,. > TDi's Vice-President of Sales and Marketing. > J >  TDi has received approval from the federal government to begin shipping the H > ConsoleWorks SSL security option to customers overseas.  Bill Johnson,F > President of TDi stated, "We are proud to bring the only out-of-band secureK > Web-based console management solution to our customers.  ConsoleWorks canPE > now eliminate the concern of security with regard to remote consoles > management." >e >  About TECSys Development, LPe > B > TECSys Development, LP is a private corporation dedicated to the developmentsG > and marketing of enterprise management software for a wide variety of K > operating systems and vendors such as Windows NT, Unix, and OpenVMS, such- asK > SUN, Compaq, Cisco, IBM, and Intel.  TDi's focus is to develop and marketoE > enterprise management solution for users who need state-of-the-art,jL > automated lights-out solutions.  TDi also seeks to improve performance andK > management in systems used by IT operations and systems support personnel E > with advanced technology software products that utilize the maximumIJ > potential of hardware and software configurations. For more information,J > please visit TDi at www.tditx.com, email questions to info@tditx.com, or > call 972-881-1553. >HJ >  TECSys Development, LP, TDi, and ConsoleWorks are registered trademarks ofJ > TECSys Development, LP.  Product names mentioned herein maybe trademarks= > and/or registered trademarks of their respective companies.  >  >e >e   ------------------------------  # Date: Wed, 26 Jun 2002 13:10:43 GMT . From: skulker@easynews.com.yourpants (skulker)L Subject: BACKUP/INCREMENTAL not parsing directories properly during restores1 Message-ID: <3d19b8ff.55246228@news.easynews.com>s  
 Greetings!  @ I have encountered a problem with the BACKUP/INCREMENTAL command$ during a disk restore. (VMS 7.2-1H1)   My comand (example):  8 $ BACKUP/INCREMENTAL/DENS=TK87 $9$MKA80:saveset.bak/SAVE $1$DUA400:/LOG  D This results in a delete pass prior to the restore pass. All is wellD with files - but NOT directories. It seems BACKUP is not parsing the directory syntax properly.   An error message (example):n  > %BACKUP-E-INCDELERROR, error deleting $1$DUA400:[a.b.c]c.dir;1" -SYSTEM-W-NOSUCHFILE, no such file  B That's a true statement because the directory is $1$DUA400:[a.b.c]* making the filespec $1$DUA400:[a.b]c.dir;1  : Sooooo - I can use  [*...] in the output spec and drop theF /INCREMENTAL but I may fill up the disk device and I need to create anF "exact" copy of the source disk that was originally backed up to tape.C I'm actually cloning a remote system and  don't want/need the extrao1 baggage (files/directories) that no longer exist.t  D Am I missing something, doing something wrong, or just "stoopid"? IsD there a patch/release/fix from COMPAQ (part of the new HP)? Am I out of luck?  E Oh yeah - I have a call into Compaq but I thought I might get a headse
 up here...   TIA!           skulkers   skulker@easynews.com.yourpants   email replies remove .yourpantsp   ------------------------------  # Date: Wed, 26 Jun 2002 13:58:35 GMTc. From: skulker@easynews.com.yourpants (skulker)P Subject: Re: BACKUP/INCREMENTAL not parsing directories properly during restores1 Message-ID: <3d19c710.58847689@news.easynews.com>   0 On Wed, 26 Jun 2002 13:38:17 GMT, "Mark E. Levy"! <mlevy70-nospam@attbi.com> wrote:h     > M >When you're going through the incrementals, are you doing so in the order in K >which they were created, or do you restore the newest first? Yes, you readrM >that right - when doing a volume restore from images/incrementals, you starteL >with the image, and then the incrementals in reverse chronological order. II >don't know if that would help your problem, but it's a common error with~ >incremental restores. > 
 >Mark Levy >SMA     Mark,S   Thanks for the reply!u  B Yeah - I'm aware that you "should" perform incremental restores in< reverse chronological order - but I can't in this particular
 situation.  F The "original" cluster is at a customer's site (we are the outsourcingF company). We have built an exact duplicate (bubble) of this cluster atC our site (2000 miles away). Our task is now to copy all the data on @ the original cluster (14Tbytes) to the bubble. We have a 24 hour outage window.  	 Our plan:k  8 While the "original" cluster is doing Business As Usual:F - Run IMAGE BACKUPs on "original" cluster per schedule (begins Friday)! - Ship IMAGE tapes to bubble siteg  - Restore IMAGEs to bubble disks4 - Run DIFFERENTIAL BACKUPs daily on original cluster3 - Ship DIFFERENTIAL tape to bubble site on Thursdays- - Retore DIFFERENTIAL BACKUPS on bubble disksG    C Shutdown applications/user/etc of original cluster Friday (begin 24m hour outage)0 - Perform INCREMENTAL BACKUP on original cluster" - Ship INCREMENTALs to bubble site - Restore INCREMENTALs  @ OK - We "think" that will work and we can do it with 1 - 24 hourA outage. However, I cannot perform the INCREMENTAL restores in the  traditional way.  ; All that taken into consideration - is there a problem withs8 BACKUP/INCREMENTAL doing directories or it is my method?   TIA!     skulkere   skulker@easynews.com.yourpants   email replies remove .yourpants-   ------------------------------  # Date: Wed, 26 Jun 2002 13:38:17 GMTb/ From: "Mark E. Levy" <mlevy70-nospam@attbi.com>rP Subject: Re: BACKUP/INCREMENTAL not parsing directories properly during restores. Message-ID: <dtjS8.162591$nZ3.74783@rwcrnsc53>  ; "skulker" <skulker@easynews.com.yourpants> wrote in message>+ news:3d19b8ff.55246228@news.easynews.com...w >  > Greetings! >uB > I have encountered a problem with the BACKUP/INCREMENTAL command& > during a disk restore. (VMS 7.2-1H1) >  > My comand (example): >h: > $ BACKUP/INCREMENTAL/DENS=TK87 $9$MKA80:saveset.bak/SAVE > $1$DUA400:/LOG > F > This results in a delete pass prior to the restore pass. All is wellF > with files - but NOT directories. It seems BACKUP is not parsing the > directory syntax properly. >o > An error message (example):- >-@ > %BACKUP-E-INCDELERROR, error deleting $1$DUA400:[a.b.c]c.dir;1$ > -SYSTEM-W-NOSUCHFILE, no such file > D > That's a true statement because the directory is $1$DUA400:[a.b.c], > making the filespec $1$DUA400:[a.b]c.dir;1  L When you're going through the incrementals, are you doing so in the order inJ which they were created, or do you restore the newest first? Yes, you readL that right - when doing a volume restore from images/incrementals, you startK with the image, and then the incrementals in reverse chronological order. IrH don't know if that would help your problem, but it's a common error with incremental restores.s  	 Mark Levyi SMA    ------------------------------  % Date: Wed, 26 Jun 2002 13:00:52 -0400a- From: JF Mezei <jfmezei.spamnot@videotron.ca>t+ Subject: Capellas resigns from Dynegy boarde, Message-ID: <3D19F343.5DF4CF2E@videotron.ca>  K Interesting on how, as CEO and president of Compaq, he had time to do this,IM but now, as a mere civil servant within HP, he doesn't... My guess is that hetJ doesn't want to be associated with those Houston energy firms. It is a badL omen though because I would have prefered for him to keep that job and leave HP :-)    ; Dynegy Says Hewlett-Packard's Capellas Resigned From Board r     6/25/02 9:08am    J   WASHINGTON -(Dow Jones)- Dynegy Inc. (DYN) said that Hewlett-Packard Co. (HPQ) PresidentyG   Michael Capellas told it June 18 that he was resigning from its boardf effective immediately.  D   According to an 8-K filed Tuesday with the Securities and Exchange Commission, CapellasL   resigned "in light of the demands on his time and his new responsibilities at Hewlett-Packard."  I   Dynegy said that Capellas' resignation wasn't based on any disagreement  between it and   Capellas.   P   Capellas, formerly the chief executive at Compaq Computer, become president of7   Hewlett-Packard when the two companies merged in May.-   ------------------------------    Date: 26 Jun 2002 08:15:19 -0600- From: koehler@encompasserve.org (Bob Koehler) ' Subject: Re: Case sensitive identifiersh3 Message-ID: <uuwfxfuLPGs1@eisner.encompasserve.org>i  c In article <3D18600C.9E4902AF@mindspring.com>, Atlant Schmidt <atlantnospam@mindspring.com> writes:o > Bob Koehler wrote: > D >>    I do wish I could setup the voice output under OS X like I didF >>    for error boxes under OS 9.  Bugged the heck out of a PC support@ >>    hack one day while she was trying to alter my Windoze box. >  > Are you sure you *CAN'T*?E  F    Haven't found it.  I do have OS 9 apps speaking to me when they popF    up a box, but the OS 9 settings don't seem to affect that behaviour9    (I added a couple phrases to cycle though under OS 9).    ------------------------------  % Date: Wed, 26 Jun 2002 09:32:00 +0200 + From: "Luca_B" <balzano-spam-avoid-@iol.it>v Subject: dec 3000-300LX mobo( Message-ID: <afbqka$1kr5$1@half.spin.it>   Hi all,   B I have here a dec3000-300LX motherboard with processor d/board and  framebuffer but no power supply.  J anyone that has the same machine or a 300L (and a multimeter) who can readK the voltages on the 12 pin (if I remember well) power connector and post mer	 a pinout?B   tnx in advance   Luca   ------------------------------  + Date: Wed, 26 Jun 2002 11:52:16 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk Subject: Re: HSZ50 and RZ1DF-CBo+ Message-ID: <afc9tg$phq$1@aquila.mdx.ac.uk>r  T In article <k13S8.24101$cE5.17352@nwrddc02.gnilink.net>, dittman@dittman.net writes:= >I've got the latest (last?) firmware in my HSZ50 controllersz< >(V57Z), but the controllers can't use the RZ1DF-CB drives I? >have installed.  Is there any way to get these drives working?r >c  . Unfortunately I don't recognise the disk type. I currently have   DS-RZ1DB-VW    (9GB wide)  DS-RZ1EF-VW    (18GB wide) DS-RZ1FC-VW    (36GB wide)  F disks on BA356 shelves connected to an HSZ50 (V57Z) controller without	 problems.l   I also have some  L DS-RZ1DF-VA  (9GB narrow) disks on a BA350 shelf on another system which I'mM confident would work (on a BA350 or BA356 shelf) with the HSZ50 since on the -C HSZ50 I also have loads of old RZ29 narrow drives on BA350 shelves.m  J Both narrow and wide drives should work on the BA356 shelf but only narrow" drives will work on a BA350 shelf.    M Can you give more details of exactly what this disk is and what type of shelfo you are trying to put it on ?t  
 David Webb VMS and unix team leader CCSS Middlesex University   ------------------------------  % Date: Wed, 26 Jun 2002 10:02:30 +0100h( From: Nic Clews <sendspamhere@127.0.0.1>+ Subject: Re: Intel booting contest - Update-) Message-ID: <3D198326.65B4F0F5@127.0.0.1>M   Peter Weaver wrote:i > L > "Doc.Cypher" <Use-Author-Supplied-Address-Header@[127.1]> wrote in message2 > news:20020625081516.10988.qmail@nym.alias.net...H > > On Tue, 25 Jun 2002, ">>> ^P" <plj@NOSPAM.byron.ext.telia.se> wrote: > > >Sue Skonetski skrev:S > > >lF > > >> Just letting you know that we have received 727 guesses so far. > > >>D > > >> http://www.compaq.com/hps/ipf-enterprise/openvms_contest.html > > = > > >One has to add State even outside the states or Canada ?o > >i > > Check the rules... > > M > > "To be eligible to participate in the contest ("Contest"), you must:  . .n > .i? > >  (ii) be a legal resident of the United States of America;"o > > ...  > C > Didn't notice that before, I usually look at contest rules before 9 > submitting. Better drop the number back down to 726. :(s  H I believe for the purposes of this competition, the rest of the world isA some [sub] state or other within the US of A. I think its to easee" legalities around the competition.  E Your entry is therefore valid, mines wrong cos my guessed date passeda :*)    Sharks here, but no lawyers!   -- d? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciencese nclews at csc dot comr   ------------------------------    Date: 26 Jun 2002 08:19:30 -0600- From: koehler@encompasserve.org (Bob Koehler)c+ Subject: Re: Intel booting contest - Updateo3 Message-ID: <A7YDxoh3sqNo@eisner.encompasserve.org>d  T In article <3D198326.65B4F0F5@127.0.0.1>, Nic Clews <sendspamhere@127.0.0.1> writes: > J > I believe for the purposes of this competition, the rest of the world isC > some [sub] state or other within the US of A. I think its to easen$ > legalities around the competition.  H    No, I think they're simply Territories, but unlike Guam, Puerto Rico,G    and D.C., they haven't been offically recognized yet.  Might get ther!    queen in a ruff, and all that.i    n   ------------------------------  # Date: Wed, 26 Jun 2002 14:27:03 GMTe2 From: "Sue Skonetski" <susan.skonetski@compaq.com>+ Subject: Re: Intel booting contest - Update 2 Message-ID: <XakS8.33$ij6.451674@news.cpqcorp.net>  J The legal dept requires that we add in all the legal stuff.  You can stillK put in your countries.  We would have been required to get a lawyer in each J country in the world to review the contest and by the time we did that the' contest would have been a "moot point".e  K Do you honestly think that while I had breath left in me, I would segregatee any VMS customer?t   suer  = "Sue Skonetski" <susan.skonetski@compaq.com> wrote in messagei, news:o%KR8.30$Zm5.879663@news.cpqcorp.net...A > Just letting you know that we have received 727 guesses so far.  >e? > http://www.compaq.com/hps/ipf-enterprise/openvms_contest.html  >o > suei >s >t >l   ------------------------------  % Date: Wed, 26 Jun 2002 07:56:52 -0400s- From: "Richard D. Piccard" <piccard@ohio.edu>e- Subject: Intel Wall Street Journal Itanium Adt' Message-ID: <3D19AC04.B751DA4@ohio.edu>r  Y The WSJ for Tuesday had a more-than-one-page ad for Itanium (-2, as I recall) that listedeR all sorts of software being developed for it, including in the top section, markedM operating systems, three flavors of Windows, HP-UX, two flavors of Linux, butP   	**** NO LISTING OF VMS ****  < This is perhaps not surprising, but is certainly outrageous.  	 						RDP    -- -B ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  # Date: Wed, 26 Jun 2002 16:44:39 GMTp1 From: "Terry C. Shannon" <terryshannon@attbi.com>t1 Subject: Re: Intel Wall Street Journal Itanium AdS* Message-ID: <XbmS8.1864$Uu2.240@sccrnsc03>  8 "Richard D. Piccard" <piccard@ohio.edu> wrote in message! news:3D19AC04.B751DA4@ohio.edu...i >cG > The WSJ for Tuesday had a more-than-one-page ad for Itanium (-2, as Is recall) that listediD > all sorts of software being developed for it, including in the top section, markedtK > operating systems, three flavors of Windows, HP-UX, two flavors of Linux,  butr >n > **** NO LISTING OF VMS ****o >o> > This is perhaps not surprising, but is certainly outrageous.  H Yep. And the NonStop community no doubt is equally miffed by the lack ofA mention of NSK on Itanium. Kinda dumb on Intel's part to omit two J ENTERPRISE-CLASS operating systems from its list. Unless, of course, folksD up Redmond way had "input" to the collateral generation process. ;-}   ------------------------------    Date: 26 Jun 2002 06:29:20 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)e Subject: IPSEC ?3 Message-ID: <ATmZqQj1A+9I@eisner.encompasserve.org>C  @ Current versions of TCP/IP Services for OpenVMS seem to have theC IPV6 support available at the flip of a parameter (he says, withouti9 actually trying the steps outlined in the documentation).n   But what about IPSEC ?  H Can anyone share any information (with probability factors :-) regardingJ when there might be an accompanying IPSEC implementation to go with TCP/IP Services for OpenVMS ?   ===========e  F No, I am not interested in SSH, etc. at this time.  The customer wants( IPSEC, and the customer is always right.   ------------------------------  % Date: Wed, 26 Jun 2002 12:56:25 +0100e( From: Nic Clews <sendspamhere@127.0.0.1> Subject: Re: IPSEC ?) Message-ID: <3D19ABE9.B6D8CDB1@127.0.0.1>a   Larry Kilgallen wrote: > B > Current versions of TCP/IP Services for OpenVMS seem to have theE > IPV6 support available at the flip of a parameter (he says, withoute; > actually trying the steps outlined in the documentation).n >  > But what about IPSEC ? > J > Can anyone share any information (with probability factors :-) regardingL > when there might be an accompanying IPSEC implementation to go with TCP/IP > Services for OpenVMS ?  D At the recent HP IT forum in the UK, IPSEC was listed as futures for VMS, no timescales as I recall.L  H > No, I am not interested in SSH, etc. at this time.  The customer wants* > IPSEC, and the customer is always right.  5 They pay the bill, and make the investment decisions.y   -- n? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences, nclews at csc dot comd   ------------------------------    Date: 26 Jun 2002 07:33:40 -0700% From: bart.zorn@xs4all.nl (Bart Zorn)t- Subject: Re: Middle European DST change rulesi= Message-ID: <9a924482.0206260633.53886179@posting.google.com>   ^ Bart Zorn <B.Zorn@xs4all.nospam.nl> wrote in message news:<3D124B65.80608@xs4all.nospam.nl>... > Hoff Hoffman wrote:ui > > In article <9a924482.0206182210.5cafb23b@posting.google.com>, bart.zorn@xs4all.nl (Bart Zorn) writes:d > >  > > ..F > > :Maybe the solution is to document (and I mean really document andI > > :not the sorry excuse for documentation that is taken over from Un*x)sG > > :the procedure to implement one's own time zone rules! Part of this/B > > :documentaion should include the way to install this new rule.= > > :I have managed to compile one, but failed to install it.: > > .. > >  > > O > >   Is the documentation on creating a timezone rule for "WhereEverLand" thatiP > >   is included in the current OpenVMS FAQ insufficient?  (If I have not addedO > >   sufficient detail on this topic into the FAQ, I'd like to hear about it.)m > >  > > R > >  ---------------------------- #include <rtfaq.h> -----------------------------R > >       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    R > >  --------------------------- pure personal opinion ---------------------------P > >    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com > >  > ' > I must admit I did not check the FAQ.a > L > Next week I will do that, and again try to install my own TDF change rule. >  > I will let you know. >  > Have a nice weekend! >  > Bart Zornc    D OK, I did have a look at the FAQ, but I must say that it didn't helpA me. It directs you to the C RTL documentation which I already had  found.   I used the source fileF SYS$COMMON:[SYS$ZONEINFO.SYSTEM.SOURCES]EUROPE.;1 as starting point. I@ managed to compile it (taking only the rules applying to the MET( timezone). The compiled file wound up in SYS$COMMON:[SYS$ZONEINFO.USER].uD However, NET$CONFIGURE.COM (or the procedure it calls) does not seemC to look in this directory (I used SET WATCH FILE/CLASS=MAJOR to see = which file got accessed), and in the end nothing has changed.k  D Further observation of said source file reveals that there is a RuleD statement near the end, which seems correct to me. I wonder why this> correct rule does not appear in the logical SYS$TIMEZONE_RULE.  3 We still have over two years to solve this mistery!r  	 Bart Zornt   ------------------------------  / Date: Wed, 26 Jun 2002 08:45:12 +0200 (MET DST):& From: Rudolf Wingert <win@fom.fgan.de> Subject: Re: More good newsW6 Message-ID: <200206260645.IAA10488@sinet1.fom.fgan.de>   Hello,   Sue Skonetski wrote:   >>>e@ Hard to apologize for sending so much good news about VMS today.L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=E =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DiK Positive news about the continued successful growth of Deutsche B=F6rse andy EUREX, <<<I  E Why is this a good news for OpenVMS. AFAIK did EUREX swap out OpenVMSoC from the frontend. If they do groth sinde doing this, this is not aiB good news for OpenVMS. I could not found any positives for OpenVMS in this article.   Regards Rudolf Wingert   ------------------------------    Date: 26 Jun 2002 08:30:46 -0600- From: koehler@encompasserve.org (Bob Koehler)4 Subject: Re: More good newse3 Message-ID: <A3fv$i7K1Xzd@eisner.encompasserve.org>   g In article <2a0S8.21$6P5.549981@news.cpqcorp.net>, "Sue Skonetski" <susan.skonetski@compaq.com> writes:iB > Hard to apologize for sending so much good news about VMS today.  3    Keep it coming.  It's been a long, long, time...n   ------------------------------  % Date: Wed, 26 Jun 2002 09:36:56 -0500D1 From: "Dave Gudewicz" <david.gudewicz@abbott.com>a Subject: Re: More good newsn1 Message-ID: <afcq8v$eol$1@fizban.pprd.abbott.com>r  H We've had a new chap show up at our LUG meetings (Chicagoland) recently.I He's from the bank mentioned in the article and I can tell you that its a / fairly large VMS system w/ multiple sites, etc.r   -- Dave...A  3 More than one cigar at a time is excessive smoking.i -----Mark Twain   5 "Bill Todd" <billtodd@metrocast.net> wrote in messagec< news:aU4S8.125269$_j6.6769239@bin3.nnrp.aus1.giganews.com... >e? > "Sue Skonetski" <susan.skonetski@compaq.com> wrote in message-. > news:2a0S8.21$6P5.549981@news.cpqcorp.net...D > > Hard to apologize for sending so much good news about VMS today. >RH > Would have been nicer if the string 'VMS' had appeared in the article. >g > - bill >1 >9 >Z >4   ------------------------------   Date: 26 Jun 2002 11:55:11 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: Open Letter to HP0 Message-ID: <afca2v$epj$1@pegasus.csx.cam.ac.uk>  , In article <3D06A8F0.88CC5CC6@videotron.ca>,/ JF Mezei <jfmezei.spamnot@videotron.ca> writes:  |> Carl Perkins wrote:L |> > I think the point was missed. Even if the Itanium-3 is the fastest chipL |> > available at the time, HP will no longer have a performance edge simplyO |> > because they will not be the only company selling Itanium-3 based systems.n |> rO |> But if IA64 doesn't performs that well, then HP will be the only one sellingc |> systems based on it.U  = Absolutely.  The Madison is merely a shrunk McKinley, and thei= Montecito is little more.  The first significantly new designa1 is the Chivano, realistically not due until 2006.n  ? Either Intel and HP establish the IA-64 line with the McKinley, > or the IA-64 line sinks the way the Merced did.  They will not= get a second chance with the Madison, unless both AMD and Suni+ make a COMPLETE pig's ear of the next year.v  @ The nightmare scenario for HP is that the McKinley does not sink@ immediately, but fails to take off, and Intel brings out Yamhill# and cans the IA-64 project in 2004.-  > I would expect that 95% of the IA-64 port work could be reused? if the target were changed to any other design, whether x86-64,D@ SPARC, PA-RISC, POWER4, MIPS or even ARM.  The problems would beB (a) delay and (b) executives spending all their time blamestorming, instead of planning a route out of the hole.     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 334679y   ------------------------------  # Date: Wed, 26 Jun 2002 13:36:57 GMTm# From: "John Smith" <a@nonymous.com>g Subject: Re: Open Letter to HPC Message-ID: <ZrjS8.217$MIK.73@news01.bloor.is.net.cable.rogers.com>   5 "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message * news:afca2v$epj$1@pegasus.csx.cam.ac.uk... >S. > In article <3D06A8F0.88CC5CC6@videotron.ca>,1 > JF Mezei <jfmezei.spamnot@videotron.ca> writes:i > |> Carl Perkins wrote:I > |> > I think the point was missed. Even if the Itanium-3 is the fastest  chipG > |> > available at the time, HP will no longer have a performance edgec simplyH > |> > because they will not be the only company selling Itanium-3 based systems. > |>I > |> But if IA64 doesn't performs that well, then HP will be the only one: selling  > |> systems based on it.. > ? > Absolutely.  The Madison is merely a shrunk McKinley, and the-? > Montecito is little more.  The first significantly new design03 > is the Chivano, realistically not due until 2006.s >@A > Either Intel and HP establish the IA-64 line with the McKinley, @ > or the IA-64 line sinks the way the Merced did.  They will not? > get a second chance with the Madison, unless both AMD and Sun - > make a COMPLETE pig's ear of the next year.i >zB > The nightmare scenario for HP is that the McKinley does not sinkB > immediately, but fails to take off, and Intel brings out Yamhill% > and cans the IA-64 project in 2004.t >h  E Of course this assessment does not include any 'palace intrigue' that-- could/is/may take place between HP and Intel.   K Who really controls the IA-64 intellectual property? Seems to me that IntelcD trumps HP on that score. And Intel owns the fabs. Intel can probablyK outspend/price cut AMD into oblivion over the next few years, especially ifb@ Hammer is delayed or comes out with relatively poor performance.  K If AMD is truly marginalized, Intel gets to do what they want to do. And HPeI has no current CPU design or fab at that point to counter any threat that K Intel may cause to their business. Intel may not *want* tpo harm HP throughCK acts of commission, but they may wind up doing so through acts of omission.-   ------------------------------   Date: 26 Jun 2002 14:09:28 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: Open Letter to HP0 Message-ID: <afchuo$lov$1@pegasus.csx.cam.ac.uk>  C In article <ZrjS8.217$MIK.73@news01.bloor.is.net.cable.rogers.com>,l% "John Smith" <a@nonymous.com> writes:v |> rE |> > The nightmare scenario for HP is that the McKinley does not sinklE |> > immediately, but fails to take off, and Intel brings out Yamhill1( |> > and cans the IA-64 project in 2004. |> cH |> Of course this assessment does not include any 'palace intrigue' that0 |> could/is/may take place between HP and Intel.  ? Actually, yes, it does.  But I am not going to talk about that,0 for reasons I won't explain.  N |> Who really controls the IA-64 intellectual property? Seems to me that IntelG |> trumps HP on that score. And Intel owns the fabs. Intel can probablylN |> outspend/price cut AMD into oblivion over the next few years, especially ifC |> Hammer is delayed or comes out with relatively poor performance.u  B I don't know, though I have heard various stories.  But that isn't
 the point.  A HP got into bed with Intel because they didn't have the resources0> to develop the 'PA-RISC 3.0' architecture on their own.  Since@ then, IA-64 has got several times more complex, and HP have well? over doubled their software committments.  There is no way thatl@ HP has the resources to take over IA-64 if Intel and the rest of the industry drops it.  @ Intel has been trying to outspend and outprice AMD over the past@ few years, and has got nowhere.  Yes, if the Hammer range flops,> and Sun fails to take advantage of the gap, the IA-64 line may= win by default.  But my sources indicate that the McKinley is.< slightly more likely to flop or be rejected by OEMs than the
 Sledgehammer.   ? We shall know by the end of January 2003.  OEMs are expected toeA announce support for the Hammer range (if any) in very late 2002,l perhaps January 2003.i     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: Wed, 26 Jun 2002 14:16:50 GMT 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>t Subject: Re: Open Letter to HP2 Message-ID: <m1kS8.30$xi6.427156@news.cpqcorp.net>  " Nick Maclaren wrote in message ... >d- >In article <3D06A8F0.88CC5CC6@videotron.ca>, 0 >JF Mezei <jfmezei.spamnot@videotron.ca> writes: >|> Carl Perkins wrote:-H >|> > I think the point was missed. Even if the Itanium-3 is the fastest chipF >|> > available at the time, HP will no longer have a performance edge simplyG >|> > because they will not be the only company selling Itanium-3 based  systems. >|>hH >|> But if IA64 doesn't performs that well, then HP will be the only one sellinge >|> systems based on it. >u  L System platform vendors will have to differentiate on more than just the CPUI chip.  Price is obviously one aspect.  But in the server space especiallyuJ there are many, many ways to add value.  Nor is performance purely the CPUL chip.  The core logic chipset also will determine memory and IO performance.   ------------------------------  # Date: Wed, 26 Jun 2002 15:28:36 GMTi# From: "John Smith" <a@nonymous.com>c Subject: Re: Open Letter to HPI Message-ID: <E4lS8.38335$71t1.11640@news01.bloor.is.net.cable.rogers.com>t  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message, news:m1kS8.30$xi6.427156@news.cpqcorp.net... >g >aJ > System platform vendors will have to differentiate on more than just the CPUiK > chip.  Price is obviously one aspect.  But in the server space especially L > there are many, many ways to add value.  Nor is performance purely the CPUA > chip.  The core logic chipset also will determine memory and IOg performance. >$  B Sounds to me like we are coming full circle, only this time with aL low-volume, pricey IA-64 vs. a low-volume, pricey Alpha. At least with Alpha. we had confidence that the chip would perform.   ------------------------------  % Date: Wed, 26 Jun 2002 13:14:25 -0400r- From: JF Mezei <jfmezei.spamnot@videotron.ca>u Subject: Re: Open Letter to HP, Message-ID: <3D19F66F.7B72731D@videotron.ca>   Nick Maclaren wrote:@ > I would expect that 95% of the IA-64 port work could be reusedA > if the target were changed to any other design, whether x86-64,n- > SPARC, PA-RISC, POWER4, MIPS or even ARM.  ,  N I am not so sure about that. Consider Tandem that needs lockstep. I wonder howN enthousiastic Tandem ISVs are with regards to the port to IA64. Until they getK functional Tandem IA64 machines available to ISVs, not much native software=L could be written for it. So they are lucky in the sense that ISVs won't haveM wasted much money porting their tandem software IF HP decides to do the rightt1 thing and abandon IA64 a few years down the road.y   ------------------------------  % Date: Wed, 26 Jun 2002 13:41:06 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>m Subject: Re: Open Letter to HP, Message-ID: <3D19FCAF.5EBE9D38@videotron.ca>   Nick Maclaren wrote:A > over doubled their software committments.  There is no way thatAB > HP has the resources to take over IA-64 if Intel and the rest of > the industry drops it.  J My fear is that the rest of the industry drops it (or never adopts it) andI Intel and HP are stuck with it. Then, IA64 will be just as proprietary assJ Alpha and then the same logic used to justify the murder of Alpha could be used for IA64.  L In the end, wouldn't it be interesting if VMS is ported to a 64bit 8086 once; HP realises IA64 is a proprietary dud that won't catch on ?t  M Wouldn't it be the biggest irony if even Tandem migrated to a 64 bit 8086, anoH architecture that started off as 16 bit on 8 bit bus as a glorified game controller ?  K You have to give Intel recognition for the fact that they were able to takeeL the 8086 and over the course of perhaps 15 years, turn it into a respectable, CPU, fast enough to make marketing claims ofK the fastest CPU in the world. (granted they got "inspiration" from Alpha ate1 that time, so the work isn't all "Intel inside").o  M The big question now is where will Intel get the inspiration to give IA64 theeK same type of boost that Alpha gave to the 8086/Pentium. How much of Alpha'sh inspiration applies to EPIC ?i  M If very few of the alpha knowledge and technologies apply to IA64, then InteleK will just have paid to have Alpha murdered (no longer a competitor) withouta, reaping much benefits from its technologies.  I On the other hand, since the 8086 has already adopted Alpha technologies,2N isbn't it more likely that the Alpha knowledge and engineers might be far moreG productive incorporating the lastest alpha knowledge/idea into the 8086  instead of IA64 ?n  M If Intel decides to produce a 64 bit 8086 to compete against Hammer, wouldn'tbF it be logical for Intel to put the ex-Digit engineers on that project,J complete with all the alpha IP that was gained when Compaq donated Alpha's remains to Intel ?    M I think it is more likely to see "Alpha inside" on the 8086 than on the IA64.m  B > Intel has been trying to outspend and outprice AMD over the past" > few years, and has got nowhere.   J Intel is very aware of its near monopoly status. They need AMD to be largeK enough to keep the FTC away. If IA64 were to become wildly succesful, IntelEH may have monopoly problems if it remains the only one making IA64 chips.   ------------------------------    Date: 26 Jun 2002 03:59:28 -0700- From: martin.platts@cdl.co.uk (Martin Platts)d, Subject: OpenVMS Alpha V7.3 - system lockups< Message-ID: <b367fb16.0206260259.b83b1df@posting.google.com>  F I posted a message about V7.3 lockups in the past - but in looking for@ 'leaks' I found on (one of) the affected system(s) the followingF display for the buffer objects - look in the last line "physical pagesF locked by buffer objects" - it shows more in use than the peak (~*4) -! could this cause a crash somehow?l  F Not seen it on other V7.34 systems we have. The system has the lastest@ patches as of a week ago - including TCPIP V5.1 eco 4. All usersE connect by TCP/IP via TELNET clients - the system has RAXCO RAXmastermC V7.6 installed (for PerfectCache - so no XFC/VIOC). The scenario ishF that the machine totally locks up - console dead, no mouse, cursor etc9 - can halt the machine but cannot get crash dump created.   @               System Memory Resources on 26-JUN-2002 11:33:21.83  C Physical Memory Usage (pages):     Total        Free      In Use   ? ModifiedF   Main Memory (2.00Gb)            262144        3959      217540       40645e  C Granularity Hint Regions (pages):  Total        Free      In Use   < ReleasedF   Execlet code region               1024           0        1022           2FF   Execlet data region                512           0         291         221lF   S0/S1 Executive data region       3674           0        3674           0nF   Resident image code region        1024           0         846         178k  D Slot Usage (slots):                Total        Free    Resident     SwappedhF   Process Entry Slots                759         455         304           0ZF   Balance Set Slots                  757         455         302           0   D Dynamic Memory Usage:              Total        Free      In Use     LargestsF   Nonpaged Dynamic Memory (Mb)     28.60       18.76        9.84       16.52nF   Paged Dynamic Memory    (Mb)     14.30       11.44        2.86       11.41i@   Lock Manager Dyn Memory (Mb)     14.55        8.32        6.22  @ Buffer Object Usage (pages):                  In Use        Peak@   32-bit System Space Windows (S0/S1)              5           6@   64-bit System Space Windows (S2)                97         103@   Physical pages locked by buffer objects        102          26  F Memory Reservations (pages):       Group    Reserved      In Use        Type @   Total (0 bytes reserved)                         0           0  F Swap File Usage (8KB pages):                   Index        Free        Size-)   DISK$PCIS_VMS:[SYS0.SYSEXE]SWAPFILE.SYSuF                                                    1        3120        3120c  F Paging File Usage (8KB pages):                 Index        Free        Size )   DISK$PCIS_VMS:[SYS0.SYSEXE]PAGEFILE.SYSdF                                                  254       85622       93744DE   Total committed paging file usage:                                 D 153969  F Of the physical pages in use, 13179 pages are permanently allocated to OpenVMS.  6 The selected file data Cache is DISABLED on this node.  
 Martin Plattsn3 (all opinions are my own, not those of my employer),   ------------------------------  % Date: Wed, 26 Jun 2002 12:53:42 +0100n( From: Nic Clews <sendspamhere@127.0.0.1>0 Subject: Re: OpenVMS Alpha V7.3 - system lockups) Message-ID: <3D19AB46.929DFC39@127.0.0.1>O   Martin Platts wrote: > H > I posted a message about V7.3 lockups in the past - but in looking forB > 'leaks' I found on (one of) the affected system(s) the followingH > display for the buffer objects - look in the last line "physical pagesH > locked by buffer objects" - it shows more in use than the peak (~*4) -# > could this cause a crash somehow?t  / I'm sure I responded to this or a similar post.n  H Along the lines of, if you can't crash the box, I expect you're having a hardware problem.-  E Post a CLUE CONFIG from SDA here... (it may or may not give the clue,e pun not intended).   -- t? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciencesi nclews at csc dot com    ------------------------------    Date: 26 Jun 2002 06:34:09 -0700. From: SPAMSINK2001@YAHOO.COM (Alan E. Feldman) Subject: Re: OpenVMS on CNBC= Message-ID: <343f30ae.0206260534.4a610624@posting.google.com>e  t "Bill Todd" <billtodd@metrocast.net> wrote in message news:<qo8S8.402418$%y.29461674@bin4.nnrp.aus1.giganews.com>...9 > "Frank Sapienza" <sapienza@noesys.com> wrote in messageu( > news:afavl902bgv@enews4.newsguy.com... > >n9 > > "Bill Todd" <billtodd@metrocast.net> wrote in messagePA > > news:hX4S8.437851$Oa1.30871830@bin8.nnrp.aus1.giganews.com...mM > > > It's beginning to appear possible that, while your new company is still  >  runL > > > by scumbags, they may be measurably less incompetent scumbags than the > > > previous lot.n > > 
 > > ROTFL! > >mD > > Bill, you're so cute when you say nice things about people.  :-) > - > I always try to give credit where it's due.  >  > - bill  E Just in case no one else noticed this, a clearly labeled link to thisrE announcement of VMS v7.3-1 is on the home page of www.hp.com. I don't A think I've ever seen the string "VMS" on the home page of Compaq.P   Disclaimer: JMHO Alan E. Feldmang afeldman gfigroup comt   ------------------------------    Date: 26 Jun 2002 08:25:47 -0600- From: koehler@encompasserve.org (Bob Koehler)t Subject: Re: OpenVMS on CNBC3 Message-ID: <JYSkYnbi+BpC@eisner.encompasserve.org>M  g In article <Tr_R8.14$HL5.399507@news.cpqcorp.net>, "Sue Skonetski" <susan.skonetski@compaq.com> writes:aJ > http://famulus.msnbc.com/famuluscom/businesswire06-25-060938.asp?sym=HPQ      R.I.P. Stealth Marketing.   ------------------------------    Date: 26 Jun 2002 14:53:45 -0000= From: Doc.Cypher <Use-Author-Supplied-Address-Header@[127.1]>n Subject: Re: OpenVMS on CNBC6 Message-ID: <20020626145345.18586.qmail@nym.alias.net>  ? On 26 Jun 2002, SPAMSINK2001@YAHOO.COM (Alan E. Feldman) wrote:o   <snip>  F >Just in case no one else noticed this, a clearly labeled link to thisF >announcement of VMS v7.3-1 is on the home page of www.hp.com. I don'tB >think I've ever seen the string "VMS" on the home page of Compaq.  $ OMFG! <dodges flying pig> What next?   Flashing balls marketing out.s   Marketing *with* balls in.     Doc. -- a6 The bigger the humbug, the better people will like it.K ~ Phineas Taylor Barnum.                             https://vmsbox.cjb.nete   ------------------------------  # Date: Wed, 26 Jun 2002 15:07:55 GMT 1 From: LESLIE@JRLVAX.HOUSTON.RR.COM (Jerry Leslie)- Subject: Re: OpenVMS on CNBC: Message-ID: <fNkS8.14042$iU2.618079@typhoon.austin.rr.com>  / Alan E. Feldman (SPAMSINK2001@YAHOO.COM) wrote:g : G : Just in case no one else noticed this, a clearly labeled link to thisrG : announcement of VMS v7.3-1 is on the home page of www.hp.com. I don't.C : think I've ever seen the string "VMS" on the home page of Compaq.F : # Latest weather report from Houston:t  2   http://hogranch.com/files/Bitmaps/FlyingPigs.JPG   In case someone asks...I  )   http://pw2.netcom.com/~mrlucky/pig.htmlb2   What's the origin of the phrase "WHEN PIGS FLY"?   ------------------------------  # Date: Wed, 26 Jun 2002 15:13:42 GMTI# From: "John Smith" <a@nonymous.com>B Subject: Re: OpenVMS on CNBCI Message-ID: <GSkS8.38145$71t1.32861@news01.bloor.is.net.cable.rogers.com>.  : "Bob Koehler" <koehler@encompasserve.org> wrote in message- news:JYSkYnbi+BpC@eisner.encompasserve.org...t >g >    R.I.P. Stealth Marketing.  = Patience partner. One right does not correct a lot of wrongs.a  I Observe. Be vocal. Pu the correct words in their mouth. Continue to steer % them on the path they need to follow.    ------------------------------  % Date: Wed, 26 Jun 2002 13:20:44 -0400C- From: JF Mezei <jfmezei.spamnot@videotron.ca>  Subject: Re: OpenVMS on CNBC, Message-ID: <3D19F7EA.F7912910@videotron.ca>   Bob Koehler wrote: >    R.I.P. Stealth Marketing.  M I would not say that. New VMS versions were twice announced as press releasesiJ under the compaq era. Yet Compaq still killed VMS and ignored VMS from its  official speeches/documents etc.  J Press releases don't cost much, but they also do not garantee you have anyK coverage of them. There are thousands of such corporate releases every day.iL What that release does accomplish is reach those wall street casino analysts who monitor HP.o   ------------------------------   Date: 26 Jun 2002 04:26 CDTw' From: carl@gerg.tamu.edu (Carl Perkins)e( Subject: Re: OpenVMS V7.3-1 Announcement- Message-ID: <26JUN200204264179@gerg.tamu.edu>b  + "Main, Kerry" <Kerry.Main@hp.com> writes...g  ! Not to rain on the parade, but...w   }total conversion to 64-bit F }functionality for more than a decade while some competitors are still }migrating;   E I would point out that this statement isn't actually correct. VMS didgD not have a "total conversion" to 64 bitness until version 7.0, which) came out somewhat less than a decade ago.l   --- Carl   ------------------------------  # Date: Wed, 26 Jun 2002 13:10:34 GMT  From: lbohan@spamless..dbc.com( Subject: Re: OpenVMS V7.3-1 Announcement8 Message-ID: <66fjhu4es5k3dhsj3rs38r1mu9allkuq00@4ax.com>  E On Tue, 25 Jun 2002 11:34:11 -0400, "Main, Kerry" <Kerry.Main@hp.com>p wrote:   >All,h4 >As a fyi, OpenVMS V7.3-1 was officially announced.   8 Are the v7.3-1 release notes available somwhere, online?   ------------------------------  % Date: Wed, 26 Jun 2002 09:38:09 -0400t' From: "Main, Kerry" <Kerry.Main@hp.com>l( Subject: RE: OpenVMS V7.3-1 AnnouncementT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4023D9210@kaoexc01.americas.cpqcorp.net>  > >>>Are the v7.3-1 release notes available somwhere, online?<<<  F Not yet, but WAG is that they should be available within a month or so at:rA http://www.openvms.compaq.com:8000/index.html (V7.3, V7.2.x doc'su
 available)  @ Contact me offline if this is important and I will look into it.   Regards   
 Kerry Main Senior Consultanta Hewlett-Packard Canada! Consulting & Integration Servicess Voice: 613-592-4660  Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----C From: lbohan@spamless..dbc.com [mailto:lbohan@spamless..dbc.com]=20  Sent: June 26, 2002 9:11 AMt To: Info-VAX@Mvb.Saic.Comw( Subject: Re: OpenVMS V7.3-1 Announcement    E On Tue, 25 Jun 2002 11:34:11 -0400, "Main, Kerry" <Kerry.Main@hp.com>t wrote:   >All, 3 >As a fyi, OpenVMS V7.3-1 was officially announced.t  8 Are the v7.3-1 release notes available somwhere, online?   ------------------------------  + Date: Wed, 26 Jun 2002 12:08:17 +0000 (UTC)f From: david20@alpha2.mdx.ac.ukH Subject: Re: Process Software does SSH for TCP/IP Services - new release+ Message-ID: <afcarh$pnt$1@aquila.mdx.ac.uk>   U In article <vkYFz5vHpNOi@elias.decus.ch>, p_sture@elias.decus.ch (Paul Sture) writes: ? >Noticed this today. No idea yet if there's a Hobbyist version.- >-( >http://www.process.com/tcpip/sshds.html >  >SSH FOR OPENVMS >rM >Complete SSH Solution for Alpha and VAX Systems using Compaq TCP/IP Services  >k >See url for further details.e >   N Since the hobbyist has free access to both TCPWARE and Multinet a free version* of this software is probably not required.  J Unfortunately the prices I have been quoted for this software are much tooG expensive. Its much cheaper to buy TCPWARE through Process' University  I Alliance program if you are talking about more than about 2 or 3 systems. M Unfortunately replacing a functioning TCPIP stack (UCX) with another just to oK get SSH functionality is not a realistic political option. An addon such as O SSH for OPENVMS would have been much easier to sell if the cost had not been soa high.t    
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------    Date: 26 Jun 2002 02:18:53 -0700' From: piet@timmers-it.nl (Piet Timmers) / Subject: remote node is not currently reachablea= Message-ID: <be44b12d.0206260118.5ad4e1b1@posting.google.com>2  C We have a serious problem reaching a decnet node wich according the F message is not reachable, but from all other nodes in our network this node is reachable.  
 $ DIR NODE2:: 5 %DIRECT-E-OPENIN, error opening NODE2::*.*;* as inputk/ -RMS-E-FND, ACP file or directory lookup failedy= -SYSTEM-F-UNREACHABLE, remote node is not currently reachableu  $ All other nodes can reach this node.8 From node NODE2 to the node with teh problem works fine.  ; We are running OpenVMS V7.2-1 and decnet DECNET_OSI V7.2-1 t  	 Any idea?p  
 Greetings,   Piet Timmers   ------------------------------    Date: 26 Jun 2002 02:19:01 -0700' From: piet@timmers-it.nl (Piet Timmers) / Subject: remote node is not currently reachable,= Message-ID: <be44b12d.0206260119.4c6cb60e@posting.google.com>c  C We have a serious problem reaching a decnet node wich according theuF message is not reachable, but from all other nodes in our network this node is reachable.  
 $ DIR NODE2::g5 %DIRECT-E-OPENIN, error opening NODE2::*.*;* as input / -RMS-E-FND, ACP file or directory lookup failedr= -SYSTEM-F-UNREACHABLE, remote node is not currently reachablee  $ All other nodes can reach this node.8 From node NODE2 to the node with teh problem works fine.  ; We are running OpenVMS V7.2-1 and decnet DECNET_OSI V7.2-1 h  	 Any idea?d  
 Greetings,   Piet Timmers   ------------------------------  % Date: Wed, 26 Jun 2002 08:14:16 -0400o1 From: Michael Austin <maustin@firstdbasource.com>f3 Subject: Re: remote node is not currently reachable 2 Message-ID: <3D19B018.20C4DED9@firstdbasource.com>   Piet Timmers wrote:h > E > We have a serious problem reaching a decnet node wich according the-H > message is not reachable, but from all other nodes in our network this > node is reachable. >  > $ DIR NODE2:::7 > %DIRECT-E-OPENIN, error opening NODE2::*.*;* as inputd1 > -RMS-E-FND, ACP file or directory lookup failedt? > -SYSTEM-F-UNREACHABLE, remote node is not currently reachabler > & > All other nodes can reach this node.: > From node NODE2 to the node with teh problem works fine. > < > We are running OpenVMS V7.2-1 and decnet DECNET_OSI V7.2-1 >  > Any idea?t >  > Greetings, >  > Piet Timmers  H maybe a router changed or routing table from the "routing node" changed?D or a part of the network is down. Are all of the nodes that see this  node end-nodes or routing nodes?  D A brief network topology would be nice to see. other than that, your guess is as good as mine.    -- n Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163 7 Sr. Consultant            http://www.firstdbasource.com E                           http://www.firstdbasource.com/donation.htmlu/ 704-947-1089 (Office)     704-236-4377 (Mobile)e   ------------------------------    Date: 26 Jun 2002 08:42:32 -0600- From: koehler@encompasserve.org (Bob Koehler) 3 Subject: Re: remote node is not currently reachablen3 Message-ID: <M$iCL$0jbARd@eisner.encompasserve.org>6  g In article <be44b12d.0206260118.5ad4e1b1@posting.google.com>, piet@timmers-it.nl (Piet Timmers) writes:oE > We have a serious problem reaching a decnet node wich according theoH > message is not reachable, but from all other nodes in our network this > node is reachable. >  > $ DIR NODE2::t7 > %DIRECT-E-OPENIN, error opening NODE2::*.*;* as input81 > -RMS-E-FND, ACP file or directory lookup failedt? > -SYSTEM-F-UNREACHABLE, remote node is not currently reachablea >   C    Been there, done that.  Had a typo when I registered that node's8F    address on that host.  Try the address, for a node who's address is
    area.node:t         $ dir area.node::o   ------------------------------    Date: 26 Jun 2002 01:22:47 -0600+ From: young_r@encompasserve.org (Rob Young) < Subject: Re: Reuters test - Itanium II blows away Sparky III3 Message-ID: <NIEXzuSeWTWh@eisner.encompasserve.org>   p In article <NRaS8.441315$Oa1.31163791@bin8.nnrp.aus1.giganews.com>, "Bill Todd" <billtodd@metrocast.net> writes: > : > "Rob Young" <young_r@encompasserve.org> wrote in message       >> >> > J >> >> > Saw a figure of about $30K stated yesterday for a 4-processor 630. >> >>aB >> >> That wasn't a good figure you saw.  A less than loaded 2-way >> >> sells for $28K >> >>- >> >>a >> >N > http://commerce.www.ibm.com/content/home/shop_ShopIBM/en_US/eServer/pSeries/ >> > entry/6306C4.html >> > >> > So it seems.D >>> >> Not "seems."  It "is."  You can order then at those prices. > K > What I meant (but did not state clearly) by 'seems' is that this made the N > number I saw for the 4-processor box appear erroneously low.  I said 'seems'N > because  a) street prices aren't always quite as high as list prices and  b)I > because prices can vary in non-negligible ways with other configuration N > changes (e.g., memory and storage, though since the 4-P box listed by IBM atL > $50K had only 8 GB of memory and three 73.4 GB disks it would be difficult3 > to account for a $20K difference by those alone).d >   @ 	Well yeah.  And the $30K 4-way (sans reference) you referred to? 	is clearly no where to be found and/or a misquote by a zealoust
 	reporter ;-)t   >>@ >> > Of course, a fairly comparable (one less disk) V480 Sun box >> > sells for about $23K. >>
 >> Not 4-way.  > M > The IBM box you described and I responded to is not a 4-way either:  I saidG& > comparable, and that's what I meant. > / > You really need to pay better attention, Rob.) >   D 	I think every single reference I made was a 4-way.  I did point outD 	your so-called $30K 4-way isn't possible as IBM is offering a 2-way' 	for $28K and less than loaded at that.    >> >> > >> > ... >> >: >> >> Intel is competing with HP/Dell.  IA64 boxes will be' >> >> plentiful and relatively "cheap."  >> >H >> > Why do you think they'll be any cheaper than existing Xeon servers, > whichtI >> > both Sun's and IBM's RISC pricing seems pretty competitive with (see ! >> > previous Register reference: J >> >  http://www.theregus.com/content/53/25276.html )?  Given the relative > sales C >> > of Xeons vs. Itanics, one could easily expect the latter to bee > considerably >> > *more* expensive. >> >' >> > I guess you're just full of faith.  >> >> No.  Faith is beyond reason.) > C > That's my point:  all too often *you* appear to be beyond reason.r >   = 	Not exactly.  Seems when presented with facts (i.e. $50K fors% 	a 4-way you go into tap-dance mode).   " >   I'm reasoning above, sometimesD >> incorrectly.  Back to Xeon... we've kicked that around... withoutB >> looking (no time, so feel free) I believe the Dell versus AlphaC >> numbers kicked around a while back had Dell at $27K for a nicelye >> loaded 4 processor box. > K > I'll give you that one, after a quick look at Dell's 6650 Xeon prices:  IlK > think the Register article seriously overestimated them.  However, Dell'sK) > Itanic1 prices are a great deal higher.  >   @ 	Right... but they should come in at or lower than Intel if they 	expect to sell any.  ( >   I believe IA64 will get down to that; >> range in Madison timeframe (shrinky dinks and all that).  > J > USIV (which includes at least a shrink to 130 nm - I'm not familiar withH > what else it might contain) is due at about the same time as Madison,   ? 	No it isn't.  And given a very good opportunity to do anythingl? 	other than handwaving for UltraSparc futures, Mr. Yen admittedoC 	there was nothing to talk about.  That whole program is in obviousf	 	trouble.r  1 http://www.theregister.co.uk/content/3/25890.html   G But unlike the private roadmaps with which Sun briefs its customers and:O partners, the public version has no time commitments. After 2002, the X-Axis is1> blank. a space in which you can write "the future", we guess.   N "I have to apologize again," said Yen, when questioned on this on this lack ofL road in the roadmap. "You and your colleagues were trying to extrapolate andO fill in the missing timeline. The diagram was not intended to be proportional -hH so whether it's a linear or a logarithmic scale, I can't say," he joked.  O Sun has already said it will employ multi-threading (SMT) and multiple cores on M a die in UltraSPARC IV and V respectively, the EE Times reported last August,.J although Yen wouldn't commit to that today. US4 will be a two core CMP, we understand.   M Yen wouldn't commit to a ship date for systems featuring Jalapeno (UltraSPARC-O IIIi), which is crucial to Sun's low-end SPARC strategy, or for a ship date forM anything else. )  N Yen did say that the product family could use some rebranding, particularly atK the low-end. Pressed on whether it was viable to continue with a low-end atoK all, Yen said "you will not see with a chip to compete with PIII or P4 justa+ trying to achieve a lower cost component." a   ---b   	Two observations.  = 		1)  They might as well abandon the low-end.  A $200 P4 willg0 			seriously outperform Jalapeno, so why bother?  7 		2)  The restart on Ultra IV was/is a serious setback.l 			Hand-waving futures.m  B 	So when you say:  "USIV due about the same time as Madison", that> 	certainly isn't the case as the man running the program can't 	say when it is due.     and,H > while POWER5 isn't due until 2005 IIRC, IBM reportedly plans to shrinkI > POWER4 to a 130 nm process next year (and likely again after that).  SocN > process shrinks just maintain the status quo among these three, since Itanic2 > isn't getting any other real boosts before 2005. >   B 	6 MB of on-chip L3 meaning TPC-C will fly and it eats up floating& 	point as it is.  So what's left?  ;-)   > ...- > > >> Regarding not supporting?  Why did you trim the $50K Power4 >> 4 processor box?  > E > Because after I accepted that the figure I had seen might have beenn3 > erroneous it was irrelevant to what I had to say.9 > . >   It clearly shows it is $9K higher than the& >> purported $41K for Intel's Bandera. > K > BFD.  While both boxes had 8 GB of memory, we know nothing more about the  > Itanic box's configuration.  -  < 	Ah... so now we retreat to unknown factors that surely make 	up the $9K difference?  Okay.  , E.g., the HP press release about the ReutersI > application performance described a 4-P Itanic box with two 18 GB disksMM > rather than the three 73 GB disks the 4-P IBM box has:  that's about $2K oreM > more right there (and note that Dell's Itanic1 prices include just *one* 18sL > GB hard drive and it appears only the motherboard controller for it).  AndL > if the Itanic price didn't include 64-bit Win2KAS, that's another $3295 (IG > found that price on a Compaq web page, but I've heard $5K elsewhere - G > possibly the Compaq price was for fewer processors.  IBM's price doesBM > include AIX, and Sun's includes Solaris; I suppose you could purchase HP-UX-F > for the Intel box if you cared to, but I doubt that's cheap either). >  >   I'll bet Dell comes in >> cheaper than that.o > J > Not if its Itanic1 prices are any guide (and since last I knew Intel wasN > charging as much for Itanic2 as for Itanic1, it's not obvious why Dell would > lower them). > 1 >   Manufacturing effeciencies and all that gainsnA >> you.   So maybe you are referring to Sun?  Okay.  But they ares; >> way behind the Itanium price performance curve and theirr >> business managers know it./ > K > More bullshit, Rob.  The only pricing and public third-party test results/D > currently available show USIII ahead of Itanic in both price *and*N > performance, and while Itanic2 will likely close the gap it's far from clear8 > that it will do anything significantly more than that.  D 	Fluff.  Name some numbers and name some percentages.  How to refuteA 	what you say unless you trot out some numbers?  At least numbersg 	are easy to dispute, right?  E 	Finally, back to Mr. Yen. . . look how far Sun has sunk.  Benchmarks C 	don't matter anymore.  He better hope that SPEC2000 isn't part of b 	some savvy tech's RFP.o  2 http://www.eweek.com/article2/0,3959,277705,00.asp  N "In our opinion, many of the processor-oriented benchmarks are being outmoded"O by new chip designs, and therefore don't accurately reflect system performance,c2 Yen said.  [The CPU is part of the system Mr. Yen]  N He cited two popular benchmarks as "misleading," SPECfp and SPECint, which areF used to measure floating point and integer performance, respectively.   L The problem, he said, is that the larger on-die memory caches on some chips,N such as Itanium 2's 3MB cache, skew the results since they can accommodate theJ entire benchmark program, and thus don't have to off-die to access memory, which is unrealistic.d   ---h  ? 	Cache can accomadate the entire benchmark program?  Don't haven# 	to off-die access memory?  Sheesh.-B 	Really a shame there.  He obviously hasn't a clue about Spec2000.9 	Perhaps someone could shoot the following Mr. Yen's way:o  5 http://www.specbench.org/osg/cpu2000/analysis/memory/   O The SPEC CPU2000 benchmarks are intended to exercise the CPU itself, the memorywC hierarcy, and the compilers. How much memory do they actually use? d  O The data collected here show that SPEC met its goals for memory footprint: mosttN benchmarks are larger than common cache sizes, many are larger than 100MB, and none are larger than 200MB.   K It is useful to have benchmarks that are larger than common caches, because-N SPEC would like to differentiate its benchmarks from "toy benchmarks" that are, too easy to run or that simply reflect MHz. J It is useful to keep the benchmarks under 200MB so that the suite leaves aJ reasonable margin on a 256MB machine. The other 56MB are available for theN operating system, graphics system, network daemons, etc, without using 'singleN user mode' on Unix systems, or killing processes on NT systems. (Such measuresA may not be representative of how most people use their systems.)     ---:  < 	Perhaps if the Sun folks had some intellectual penache theyG 	could just admit that they suck at SPEC2000 and come clean and embrace-? 	the fact they are a lot like VAX of the late 80s and push thatG? 	"installed base" angle and other whizziness as their customersp
 	slouch away.c   				Rob0   ------------------------------  % Date: Wed, 26 Jun 2002 02:58:02 -0400s( From: David Froble <davef@tsoft-inc.com>< Subject: Re: Reuters test - Itanium II blows away Sparky III, Message-ID: <3D1965FA.9060509@tsoft-inc.com>   Rob Young wrote:    ? > 	No.  Faith is beyond reason.  I'm reasoning above, sometimesgD > 	incorrectly.  Back to Xeon... we've kicked that around... withoutB > 	looking (no time, so feel free) I believe the Dell versus AlphaC > 	numbers kicked around a while back had Dell at $27K for a nicely:@ > 	loaded 4 processor box.  I believe IA64 will get down to that; > 	range in Madison timeframe (shrinky dinks and all that).     L Talk about inconsistancy?  "Faith is beyond reason".  "I believe IA64 ...". M What factual reasons lead you to 'BELIEVE' anything about IA64?  If you have k9 anything, fess up.  Otherwise, admit that you're wishing.s      ; > 	way behind the Itanium price performance curve and theira  P Rob.  Itanic has no price performance curve until it's in the field and proven. Q   Now if you want to use any data from the existing systems, all 2 or 3 of them, rI go ahead.  But, if you want to talk about Itanium II, lets wait until it nO arrives.  Not in the press releases, like the ones dating back 8 years telling rP us how Intel will outperform everyone else, but arrives as in place and running  at customer locations.  $ I've still got that bridge for sale.   Dave   ------------------------------  # Date: Wed, 26 Jun 2002 08:55:39 GMTv* From: "Bill Todd" <billtodd@metrocast.net>< Subject: Re: Reuters test - Itanium II blows away Sparky IIIC Message-ID: <fkfS8.445169$Oa1.31332002@bin8.nnrp.aus1.giganews.com>n  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:NIEXzuSeWTWh@eisner.encompasserve.org... K > In article <NRaS8.441315$Oa1.31163791@bin8.nnrp.aus1.giganews.com>, "Bills& Todd" <billtodd@metrocast.net> writes: > >M< > > "Rob Young" <young_r@encompasserve.org> wrote in message   ...-   > >> Not 4-way.a > >6J > > The IBM box you described and I responded to is not a 4-way either:  I said( > > comparable, and that's what I meant. > > 1 > > You really need to pay better attention, Rob.  > >h > 4 > I think every single reference I made was a 4-way.   You think wrong.  As usual.e  ) "A less than loaded 2-way sells for $28K"s  J That's what I responded to.  And included (just above my own statement) so6 you could see it.  Are you blind, or just incompetent?   ...e  > > Not exactly.  Seems when presented with facts (i.e. $50K for& > a 4-way you go into tap-dance mode).  H I guess that answers my question above:  you're a fucking idiot.  If youG can't follow a conversation, you accuse the other party of tap-dancing.,   ...t  L > > USIV (which includes at least a shrink to 130 nm - I'm not familiar withI > > what else it might contain) is due at about the same time as Madison,n > @ > No it isn't.  And given a very good opportunity to do anything@ > other than handwaving for UltraSparc futures, Mr. Yen admitted" > there was nothing to talk about.  L Wrong again, Rob:  he said there were no dates *he* would talk about *on theJ record*.  Other sources aren't so reticent, as you could easily have foundH out had you even bothered to follow the link in the article you yourself* referenced before shooting off your mouth:  C http://www.infoworld.com/articles/hn/xml/02/05/07/020507hnsparc.xmlw  B "SUN MICROSYSTEMS EXPECTS to release the next major upgrade to itsJ UltraSPARC line of processors before the middle of next year, according to company documents.  K Sun plans to launch its UltraSPARC IV processor at 1.2GHz between the firstfK and second quarter of 2003, according to processor roadmaps obtained by IDG. News Service."  L Mike's Hardware has more aggressive dates for USIV and USV, but I don't knowL where they got their information or how fresh it is (everyone's dates have a+ tendency to slip out a bit as time passes).a  K I had forgotten that USIV is reported (in the Register article you referrednL to) to be a two-core CMP chip, though.  That's a relatively straight-forwardG extension of USIII and should be quite feasible after the shrink (USIIIeL isn't very big even now):  if it actually is scheduled for USIV, that should$ give it a decided leg up on Madison.   ...D   > Two observations.  > = > 1)  They might as well abandon the low-end.  A $200 P4 willc/ > seriously outperform Jalapeno, so why bother?h  I Duh - to round out a complete product line for people wanting consistency F across their installation, and to offer the kind of inexpensive 64-bitF platform (that can grow to enterprise size) that Itanic may well never provide.   >e7 > 2)  The restart on Ultra IV was/is a serious setback.B  J Huh?  Want to provide a reference for that 'restart'?  It certainly wasn't@ mentioned in the article you referred to:  sounds like just more Rob-trademark FUD.   ...n  J > > while POWER5 isn't due until 2005 IIRC, IBM reportedly plans to shrinkK > > POWER4 to a 130 nm process next year (and likely again after that).  So.I > > process shrinks just maintain the status quo among these three, sincee Itanic4 > > isn't getting any other real boosts before 2005. > >e >1C > 6 MB of on-chip L3 meaning TPC-C will fly and it eats up floatingT' > point as it is.  So what's left?  ;-)b  J Well, given that POWER4 will eat its lunch in SPECint, chip bandwidth, andD multi-thread server use (due to both its dual cores and its superiorI inter-chip MP interconnect), and likely have at least some lead in memory # access speed, I'd say rather a lot.o   >f > > ...  > >E@ > >> Regarding not supporting?  Why did you trim the $50K Power4 > >> 4 processor box?  > >aG > > Because after I accepted that the figure I had seen might have beend5 > > erroneous it was irrelevant to what I had to say.  > > 0 > >   It clearly shows it is $9K higher than the( > >> purported $41K for Intel's Bandera. > >nI > > BFD.  While both boxes had 8 GB of memory, we know nothing more aboutb thea > > Itanic box's configuration.z >W= > Ah... so now we retreat to unknown factors that surely make3 > up the $9K difference?  F And exactly whose fault is that, Rob?  If Intel and cHumPaq weren't soF reticent about revealing quantitative aspects of Itanic2's competitiveL position (or lack thereof), we wouldn't keep having to guess.  Not that it'sJ likely that any difference in cost, even if it really is a full $9K, isn't5 more than justified by the difference in performance..     Okay.t >/. > E.g., the HP press release about the ReutersK > > application performance described a 4-P Itanic box with two 18 GB disksuL > > rather than the three 73 GB disks the 4-P IBM box has:  that's about $2K orL > > more right there (and note that Dell's Itanic1 prices include just *one* 18I > > GB hard drive and it appears only the motherboard controller for it).u AndsK > > if the Itanic price didn't include 64-bit Win2KAS, that's another $3295s (II > > found that price on a Compaq web page, but I've heard $5K elsewhere -hI > > possibly the Compaq price was for fewer processors.  IBM's price doesBI > > include AIX, and Sun's includes Solaris; I suppose you could purchasel HP-UX H > > for the Intel box if you cared to, but I doubt that's cheap either). > >a > >   I'll bet Dell comes in > >> cheaper than that.t > >pL > > Not if its Itanic1 prices are any guide (and since last I knew Intel wasJ > > charging as much for Itanic2 as for Itanic1, it's not obvious why Dell woulde > > lower them). > > 3 > >   Manufacturing effeciencies and all that gainssC > >> you.   So maybe you are referring to Sun?  Okay.  But they are = > >> way behind the Itanium price performance curve and theird > >> business managers know it.4 > >iE > > More bullshit, Rob.  The only pricing and public third-party testd results F > > currently available show USIII ahead of Itanic in both price *and*J > > performance, and while Itanic2 will likely close the gap it's far from clearh: > > that it will do anything significantly more than that. >t > Fluff.  L Not at all.  I just went to the trouble of visiting Dell's site and checkingG out its Itanic1 server prices (which aren't hard to find nor complex tomI understand:  there's only one 4-processor choice).  If you don't like thesG conclusions I drew from them, feel free to go there yourself and gather>I something specific to try to refute them.  As for the performance half ofsG the question, even the older, slower USIIIs already had Itanic1 beat onsL SPECint and, by a larger margin, bandwidth, so I don't think you'll get much
 joy there.  I Of course, until Intel has the guts to let people publicize benchmarks ofyL Itanic2 systems of known configuration, you'll just be whistling in the windE anyway on that score.  As you were with the rest of the drivel I cut.a   - bill   ------------------------------  % Date: Wed, 26 Jun 2002 10:38:47 +0100v( From: Nic Clews <sendspamhere@127.0.0.1>< Subject: Re: Reuters test - Itanium II blows away Sparky III) Message-ID: <3D198BA6.4D91BB37@127.0.0.1>    John Smith wrote:g >  >...F > Let's face the facts.....with no offence to those in this n.g., mostF > customers are dolts. They usually buy the wrong things for the wrongJ > reasons, ie. quality of the golf club their sales rep takes them to, theI > fact that the SVP is the sales reps' brother-in-law, that 'we've alwaystM > bought from Inter-Galactic Computer Corp.', the gullability of their seniorn > execs, and such.  G A correct observation, which is after you consider the anti competitiveuE FUD being thrown around which in itself is not being counter balanced 4 with positive or mainstream advertising / marketing.  7 Few people - where it counts - seem to appreciate that.e   -- p? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciencesv nclews at csc dot comi   ------------------------------  % Date: Wed, 26 Jun 2002 10:34:31 +0100tU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>s< Subject: Re: Reuters test - Itanium II blows away Sparky III0 Message-ID: <afc1pd$7kr$1@new-usenet.uk.sun.com>   John Smith wrote:g  % > "Andrew Harrison SUNUK Consultancy"h@ > <andrew_nospam.harrison_remove_this@sun#.com> wrote in message, > news:af9ccn$b1r$1@new-usenet.uk.sun.com... >  >>B >>perhaps this is also why they are not a sucesses in that market. >> > I > The reason Alpha does not have the market penetration in the commercial I > space has nothing to do with your claimed issues of performance. It hasm" > everything to do with marketing. >     B Quite, but marketing a product as being capable of doing something@ lets say in this case being the fastest Server in the market andF then being comprehensively found out and having your claims publicallyA disproved by your own benchmarking teams is hardly the basis of ad sucessfull campaign.  A You forget the Digital did do marketing of a kind they advertisedt> Alpha systems as being the fastest on the planet, a claim that> sadly they were never able to justify except using SPECint and= SPECfp which no one was interested in in the target group fpr  their marketing.    M > Each of the major computer manufacturers generally make fine hardware. EachSN > has their share of design and manufacturing glitches from time-to-time. EachI > leapfrogs the other in performance and features from time-to-time. Each5L > may/may not have the most competitive offering at a given price-point at aK > specific point-in-time. So on any given day, vendor A may have a 'better'uG > product than vendors B and C at price-point $X. A week later that cannN > change. And all that also presupposes that the software that runs on each of6 > the hardware platforms is 'tuned' for that platform. >     ? But again this is simply untrue in the case of Compaq, the 8400r? was performance follower, it was slower, supported fewer CPU's,c; less memory, had less I/O bandwidth, longer memory latency,u? lower bisectional bandwidth and worse RAS than its competition.o  E Its replacement was WildFire, it is slower, it has less I/O bandwidth C supports less CPU's less memory, has longer local and remote memoryuG latency and a lower bisectional (and local now most are NUMA) bandwidthnE and worse RAS than its competition. Despite the hyperbola surrounding C its launch it didn't leapfrog anything a point made more obvious bycC the revelation that its memory subsystem did not improve on a circa  1995 Origin 2000.   A It helps when marketing something to have a product that has some ? of the attributes you ascribe to it in your marketing campaign.   @ It also helps if you market a set of attributes that your target  customer base thinks have value.  = It is wrong to say Digital didn't market Alpha they did, theyw5 just chose the wrong attributes and the wrong market.e     Regards  Andrew Harrisonc   ------------------------------   Date: 26 Jun 2002 11:29:51 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)< Subject: Re: Reuters test - Itanium II blows away Sparky III0 Message-ID: <afc8jf$djp$1@pegasus.csx.cam.ac.uk>  2 In article <SYHR8.19$075.248925@news.cpqcorp.net>,7 "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:h9 |> Andrew Harrison SUNUK Consultancy wrote in message ...d |> >; |> >Why, a Sun V880 with 8 CPU's costs ~100,000 last time Ia7 |> >looked the Intanium I 4 CPU boxes with 16 GB of RAM 2 |> >being sold by Compaq were listing for >80,000. |> cJ |> To be honest, I have no idea what the Itanium boxes were priced at, letL |> alone Sun's - I'm just an engineer and not in marketing or sales.  But itL |> seems we are not talking about a Compaq Itanium-1 designed (well, I'd sayO |> that *everyone's* Itanium-1 box was really just a repackaged Intel referencegE |> platform) box are we?  I think we are talking about an HP designedpM |> (including it's own core IO chipset) Itanium-2 box - and so you are really N |> making a very big wish in hoping that the price will be 20% higher than the |> Itanium-1 boxes you quote.h  A It will be interesting to see - assuming that the launch actuallyr takes place this time :-)R  O |> So even accepting your figures, it would seem that an Itanium-2 box could be O |> priced 20% higher than an Itanium-1 box, and *still* beat a Sun box that hasdM |> twice the CPU count.  Exactly what is the upside for Sun you are trying tos
 |> point out?s  D Look, tell me any two systems selling for the same price at the sameD time, and a preference, and I can produce a plausible benchmark thatE will make your preferred system outperform the other by 2:1 and quite-
 often 5:1.  D The bias can occur in the choice of benchmark just as much as in the running of it.  J |> If I were you, I'd start hoping that AMD can stop slipping their HammerC |> schedule so that you can migrate off Sparc before it's too late.h  @ In the past 6 months, the Hammer range has slipped only about as? much as the IA-64 range.  Yes, both have slipped, but only by ao couple of months.a     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 334679h   ------------------------------    Date: 26 Jun 2002 20:02:04 +0800, From: Paul Repacholi <prep@prep.synonet.com>< Subject: Re: Reuters test - Itanium II blows away Sparky III- Message-ID: <87ptyeckoz.fsf@prep.synonet.com>e  - young_r@encompasserve.org (Rob Young) writes:h  > > 	Worry and change their minds.  The price performance curves< > 	that Sun business managers are looking at are most likely0 > 	sounding alarm bells.  Prognostication alert:  i- > 		Sun becomes an IA64 partner someday soon.t   7 > 	That are go down like a rock clinging to UltraSparc.   C Like the Fugitsu super computer results? I wish the itanic was such,	 a `rock'!e   -- t< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.p@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Wed, 26 Jun 2002 13:28:42 GMTt5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>h< Subject: Re: Reuters test - Itanium II blows away Sparky III2 Message-ID: <ekjS8.23$jb6.213061@news.cpqcorp.net>   Bill Todd wrote in message ... >-9 >"Rob Young" <young_r@encompasserve.org> wrote in message . >news:KSyEiNqNmBip@eisner.encompasserve.org...G >> In article <Fj2S8.33$dS5.681020@news.cpqcorp.net>, "Fred Kleinsorge"a& ><kleinsorge@star.zko.dec.com> writes: >B >... >oF >> > You can ignore it as "not having enough information" - but even a >cynicalI >> > view of the report still result in the fact that Sun should start toa >worry.r >nL >I'd say that might depend on just how cynical one's view was.  For example,B >considering that this 'report' comes from a lot of the same upper
 managementL >that swore that Alpha couldn't maintain a significant (even just 2:1, whichJ >is now looking like a major under-estimate) performance edge over Itanic,L >suspecting that their performance assertions in this area might be off by a) >factor of 3 or more is hardly difficult.  >n  K Eh?  This is even a reach for you.  The report (and I see nothing that saysfK what if any level of management at HP was involved) seems to be the resultsoC of some application testing.  Unless what you are saying is that HPtK management, in collusion with a customer, completely fabricated the result.l  L But it doesn't suprise me to see you attempt to throw the FUD, after all youJ have wagered a significant amount of what reputation you might have on the+ proposition that IA64 will never be viable.e   ------------------------------  # Date: Wed, 26 Jun 2002 13:20:57 GMTe# From: "John Smith" <a@nonymous.com>u< Subject: Re: Reuters test - Itanium II blows away Sparky IIIC Message-ID: <ZcjS8.147$MIK.34@news01.bloor.is.net.cable.rogers.com>r  5 "Nic Clews" <sendspamhere@127.0.0.1> wrote in messagea# news:3D198BA6.4D91BB37@127.0.0.1...4 > John Smith wrote:8 > >. > >...H > > Let's face the facts.....with no offence to those in this n.g., mostH > > customers are dolts. They usually buy the wrong things for the wrongL > > reasons, ie. quality of the golf club their sales rep takes them to, theK > > fact that the SVP is the sales reps' brother-in-law, that 'we've alwayslH > > bought from Inter-Galactic Computer Corp.', the gullability of their senior > > execs, and such. >oI > A correct observation, which is after you consider the anti competitive G > FUD being thrown around which in itself is not being counter balancedo6 > with positive or mainstream advertising / marketing. > 9 > Few people - where it counts - seem to appreciate that.e >5  ' Alas, few people are critical thinkers.e  K Everyone ought to take at least one university level course in formal logic H before they are allowed to assume any management role. Most MBA programsF don't include this in their curriculum either. And we wonder about the* quality of management decision making.....   ------------------------------  # Date: Wed, 26 Jun 2002 13:42:04 GMTi5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>n< Subject: Re: Reuters test - Itanium II blows away Sparky III1 Message-ID: <MwjS8.27$176.65601@news.cpqcorp.net>   " Nick Maclaren wrote in message ... >a >tG >|> So even accepting your figures, it would seem that an Itanium-2 box  could beL >|> priced 20% higher than an Itanium-1 box, and *still* beat a Sun box that hascK >|> twice the CPU count.  Exactly what is the upside for Sun you are tryingl to >|> point out? >.E >Look, tell me any two systems selling for the same price at the sameiE >time, and a preference, and I can produce a plausible benchmark thatdF >will make your preferred system outperform the other by 2:1 and quite >often 5:1.H >eE >The bias can occur in the choice of benchmark just as much as in thea >running of it.  >.  K Sure.  Of course, we aren't really talking about a "benchmark" here are we? J But testing by a customer.  Perhaps people are excited about the fact thatL it was significantly better than Sun - I can't really blame them.  Does thatL mean that Sun won't be able to find some benchmark that either is slower, orJ more likely where there is no information - to claim otherwise.  Yup, I am absolutely sure of it.  I But when you get down to it, is it faster on *your* application workload,t= and is it cheaper are really the only two metrics that count.    ------------------------------  % Date: Wed, 26 Jun 2002 14:59:31 +0100lU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>h< Subject: Re: Reuters test - Itanium II blows away Sparky III0 Message-ID: <afcha9$cj4$1@new-usenet.uk.sun.com>   Fred Kleinsorge wrote:  8 > Andrew Harrison SUNUK Consultancy wrote in message ... >  >>' >>Wow what else does it do, make toast.h >> >> > K > Let's lead the subject farther away.  Let's ignore performance estimates, M > and what makes a system perform better or worse.  The problem you have here M > is that a real customer, real applications, real systems are not making theeK > Sparc story sound pretty comparing it against the much maligned IA64.  NoeI > matter what way we cut it, it appears on the surface that a system thatmN > costs more (the Sun) and has more CPU's, doesn't meet the performance of the > HP IA64 system.e    ; Interesting, so your reading of the Reuters "benchmark" was 7 real customer, real applications, real systems like forf like comparison !i  = I guess you read the article with an entirely different slantd8 to me, I read benchmarketing and virtually nothing else.       > K > You can ignore it as "not having enough information" - but even a cynical M > view of the report still result in the fact that Sun should start to worry.t >     D The fact that the article contained so little actual information was? in itself an indication that it was a benchmarketing excercise.e  > Without more information I would not put it in the infamous MS8 Scalability day benchmarketing category or the Alpha VLM5 benchmarketing category but its waiting in the wings.h   regardsx Andrew Harrisonm   ------------------------------   Date: 26 Jun 2002 14:16:21 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)< Subject: Re: Reuters test - Itanium II blows away Sparky III0 Message-ID: <afcibl$lvg$1@pegasus.csx.cam.ac.uk>  1 In article <MwjS8.27$176.65601@news.cpqcorp.net>,t7 "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:h% |> Nick Maclaren wrote in message ...s |> >J |> >|> So even accepting your figures, it would seem that an Itanium-2 box |> could beoO |> >|> priced 20% higher than an Itanium-1 box, and *still* beat a Sun box that  |> hasN |> >|> twice the CPU count.  Exactly what is the upside for Sun you are trying |> to  |> >|> point out?  |> >H |> >Look, tell me any two systems selling for the same price at the sameH |> >time, and a preference, and I can produce a plausible benchmark thatI |> >will make your preferred system outperform the other by 2:1 and quiter |> >often 5:1. |> >H |> >The bias can occur in the choice of benchmark just as much as in the |> >running of it. |>  N |> Sure.  Of course, we aren't really talking about a "benchmark" here are we?M |> But testing by a customer.  Perhaps people are excited about the fact thateO |> it was significantly better than Sun - I can't really blame them.  Does thatrO |> mean that Sun won't be able to find some benchmark that either is slower, or>M |> more likely where there is no information - to claim otherwise.  Yup, I amn |> absolutely sure of it.   A NO, WE ARE NOT.  You say you are a technical person - then pleasee post like one.  D The Intel NDA flatly forbids customers to publish benchmark figures,A as you know perfectly well.  These results were selected BY INTELr@ AND HP for publication.  For all I know, they were the ONLY onesB out of a thousand that were favourable to the McKinley; all others% might have been as favourable to Sun.t  A Until and unless Intel launch the McKinley and people can publish ? neutral benchmarks, all published results should be regarded ascB biassed to the point of uselessness.  That applies to ALL selected; benchmarks published by ANY vendor on development machines,s
 incidentally.r  L |> But when you get down to it, is it faster on *your* application workload,@ |> and is it cheaper are really the only two metrics that count.   In context, yes.     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: Wed, 26 Jun 2002 15:02:40 +0100nU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>g< Subject: Re: Reuters test - Itanium II blows away Sparky III0 Message-ID: <afchg6$cph$1@new-usenet.uk.sun.com>   Rob Young wrote:  l > In article <Fj2S8.33$dS5.681020@news.cpqcorp.net>, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes: > 8 >>Andrew Harrison SUNUK Consultancy wrote in message ... >> >>>.( >>>Wow what else does it do, make toast. >>>o >>>aK >>Let's lead the subject farther away.  Let's ignore performance estimates,gM >>and what makes a system perform better or worse.  The problem you have hereoM >>is that a real customer, real applications, real systems are not making theeK >>Sparc story sound pretty comparing it against the much maligned IA64.  NotI >>matter what way we cut it, it appears on the surface that a system thatgN >>costs more (the Sun) and has more CPU's, doesn't meet the performance of the >>HP IA64 system.o >>K >>You can ignore it as "not having enough information" - but even a cynicalhM >>view of the report still result in the fact that Sun should start to worry.i >> >> > C > 	Worry and change their minds.  The price performance curves thatiF > 	Sun business managers are looking at are most likely sounding alarm! > 	bells.  Prognostication alert:i > - > 		Sun becomes an IA64 partner someday soon.  >     : Rob dooms IA-64 to failure and price performance oblivion.  8 Rob, you are forgetting yourself you are the person with9 a 100% failure rate in the prognostication business as we < all know. Based on you sucess rate so far any recommendation< on your part is a close as you can get to the kiss of death.       Regards@   Andrew Harrisonm   ------------------------------  # Date: Wed, 26 Jun 2002 14:22:21 GMTh5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> < Subject: Re: Reuters test - Itanium II blows away Sparky III2 Message-ID: <x6kS8.32$cj6.445485@news.cpqcorp.net>  I Well, I gotta give you high marks on FUDmenship.  Especially since in thenI not-to-distant future I expect to see Sun fare poorly against IA64 as theiJ real systems get into real peoples hands - and it goes beyond your abilityJ to spin things.  You of course can hope that I'm wrong.  But I'm not goingD to argue with you over it, I can wait to see the actual performance.      6 Andrew Harrison SUNUK Consultancy wrote in message ... >y >v >Fred Kleinsorge wrote:s >i9 >> Andrew Harrison SUNUK Consultancy wrote in message ...  >> >>>e( >>>Wow what else does it do, make toast. >>>i >>>  >>L >> Let's lead the subject farther away.  Let's ignore performance estimates,I >> and what makes a system perform better or worse.  The problem you haveh hereJ >> is that a real customer, real applications, real systems are not making the L >> Sparc story sound pretty comparing it against the much maligned IA64.  NoJ >> matter what way we cut it, it appears on the surface that a system thatK >> costs more (the Sun) and has more CPU's, doesn't meet the performance ofv thes >> HP IA64 system. >  > < >Interesting, so your reading of the Reuters "benchmark" was8 >real customer, real applications, real systems like for >like comparison ! > > >I guess you read the article with an entirely different slant9 >to me, I read benchmarketing and virtually nothing else.s >e >s >o >>L >> You can ignore it as "not having enough information" - but even a cynicalG >> view of the report still result in the fact that Sun should start toe worry. >> >i >iE >The fact that the article contained so little actual information wasm@ >in itself an indication that it was a benchmarketing excercise. >t? >Without more information I would not put it in the infamous MSn9 >Scalability day benchmarketing category or the Alpha VLMa6 >benchmarketing category but its waiting in the wings. >b >regards >Andrew Harrison >o >s   ------------------------------  % Date: Wed, 26 Jun 2002 08:20:01 -0700a' From: David Mathog <mathog@caltech.edu>h< Subject: Re: Reuters test - Itanium II blows away Sparky III+ Message-ID: <3D19DBA1.415A99DE@caltech.edu>    Nick Maclaren wrote: > F > Look, tell me any two systems selling for the same price at the sameF > time, and a preference, and I can produce a plausible benchmark thatG > will make your preferred system outperform the other by 2:1 and quite- > often 5:1.  	 Only 5:1?2  7 I had a dataset outgrow physical memory so that instead : of staying resident in the disk cache between program runs1 the whole thing had to be physically read in from 4 disk on each run.  That resulted in a 20x speed hit.  9 I've seen 10x hits when the data processed intensively byA; tight code was incrementally larger than the primary memory 2 cache.  I've seen that 10x hit reduced to .001x by9 changing a single constant (the size of a "chunk" of datao1 processed in the innermost loop) and recompiling.8  : Now if the report had said something like "on systems with? identical memory and disks, and after extensive optimization of B the application on each platform..." it might have had some value,5 but comparing apples to chimpanzees tells us nothing.a   Regards,   David Mathog mathog@caltech.edu   ------------------------------  % Date: Wed, 26 Jun 2002 13:06:24 -0400g- From: JF Mezei <jfmezei.spamnot@videotron.ca>c< Subject: Re: Reuters test - Itanium II blows away Sparky III, Message-ID: <3D19F48F.74574A4E@videotron.ca>  ( Andrew Harrison SUNUK Consultancy wrote:G > Its replacement was WildFire, it is slower, it has less I/O bandwidthhE > supports less CPU's less memory, has longer local and remote memoryuI > latency and a lower bisectional (and local now most are NUMA) bandwidtha% > and worse RAS than its competition.S  L Had wildwires been launched on time (under Digital, before merger), wouldn'tM they have been much more competitive with their peers of the day ? Delaying ahM system/chip while your competitors are still advancing theirs will cause that E delay to make your systems appear slower than originally anticipated.   K And as far as Digital having adverttised Alpha as the fastest system in thetM world, this claim was not credible because they never sued Apple or Intel forMK making claims that their own systems were the fastest in the world. Becauser? everyone is allowed to make that claim, the claim is worthless.e   ------------------------------    Date: 26 Jun 2002 02:45:05 -0700' From: piet@timmers-it.nl (Piet Timmers)a; Subject: Send again: remote node is not currently reachablet< Message-ID: <be44b12d.0206260145.746e47a@posting.google.com>  8 Sorry, but I got a message not accepted, so I try again:  C We have a serious problem reaching a decnet node wich according the F message is not reachable, but from all other nodes in our network this node is reachable.  
 $ DIR NODE2:: 5 %DIRECT-E-OPENIN, error opening NODE2::*.*;* as inputr/ -RMS-E-FND, ACP file or directory lookup failedb= -SYSTEM-F-UNREACHABLE, remote node is not currently reachable   $ All other nodes can reach this node.9 >From node NODE2 to the node with teh problem works fine.   ; We are running OpenVMS V7.2-1 and decnet DECNET_OSI V7.2-1 t  	 Any idea?o  
 Greetings,   Piet Timmers   ------------------------------  # Date: Wed, 26 Jun 2002 16:32:14 GMTe3 From: "Tom Wade" <t.wade@vms.eurokom.ie.removespam>t= Subject: Success Re: Euro symbol, DECterm, Hummingbird Exceed . Message-ID: <i0mS8.10147$04.37155@news.iol.ie>  H > Anyone had any luck getting euro symbol support going in the following > environment ?l >o2 > OpenVMS 7.3, DECWindows 1.2-6 (with Euro patch). > : > On PC (X server) Windows 2000, Hummingbird Exceed 7.1.1. >-G > DECterm windows display the euro character (A4) as a generic currencye symbol > (as per ISO-8859-1).  $ I finally got it working as follows:  , 1. Configure/Enable the Multinet Font ServerK 2. Within Exceed Font config, add the remote font server and move it to the" top of the font list.. 3. Restart Exceed.  I DECterms now start up with euro symbol support (a side effect is that theS< menu bar items are in a larger font, but that's no problem).  K On a side note, I had tried getting euro support with Xcursion, but I couldnI only get a limited euro font going (with great difficulty) which couldn'tuG handle line drawing characters (buggers up SHOW CLUSTER display), and Ih; couldn't get it to talk to the Multinet Font server at all.c  D Given the euro support and the fact that Exceed allows me to use theK wheelmouse to scroll up/down DECterms, I think I'll change over (only thingwI lacking is that I can't use right click to paste into a DECterm buffer, Ia/ need middle click - Xcursion could use either).n  " Many thanks for all who responded.   Tom Wade   ------------------------------  # Date: Wed, 26 Jun 2002 15:29:29 GMT 2 From: "Sue Skonetski" <susan.skonetski@compaq.com>U Subject: support for OpenVMS V7.3 by the Brooks-PRI Automation PROMIS MES applicationt2 Message-ID: <t5lS8.40$Za6.209970@news.cpqcorp.net>   Dear Newsgroup,w  K The following is a message I just received clarifing some questions that we  have recevied.   sueh   -----Original Message----- From: Egolf, Johni' Sent: Wednesday, June 26, 2002 11:17 AMh To: Skonetski, Susan= Subject: Brooks-PRI Automation PROMIS support on OpenVMS V7.3-     Sue,    I Recently I have had a few inquiries about support for OpenVMS V7.3 by thec- Brooks-PRI Automation PROMIS MES application.r  = I've spoken with the head of engineering and product support.o  # PROMIS is supported on OpenVMS V7.3@  G When they released their SP1 they hadn't validated it on OpenVMS 7.3 soSA there is no mention of it in their documentation / release notes.fJ Afterwards they did a full regression and certification test of the PROMISC product on OpenVMS V7.3 and it worked just fine.  They are formallyc  supporting on V7.3 now with SP1.  K If you haven't seen my previous note,  PRI Automation was recently acquiredyG by Brooks Automation.  The new company is called Brooks-PRI Automation.eF I've listed two web pointers below announcing the acquisition and alsoI announcing the strategy of Brooks-PRI to continue to "continue to developnI and support both its FACTORYworks and PROMIS MES products."  FACTORYworkst: runs on various UNIX platforms, including Tru64 and HP-UX.  I The PROMIS application is still planned for the Itanium FastTrack programrK and will be ported to IPF starting day one when the H1 2003 OpenVMS IPF kito
 is available.o   Thanks,m   /Johna  ? ps: feel free to share this info with other interested parties.l  2 http://investor.brooks.com/news/20020515-80628.cfm  L http://www.brooks-pri.com/html/981_june_6,_2002_-_brooks-pri_announces_mes_s- trategy.cfm?contentindexID=69&menucontentID=1e   ------------------------------  % Date: Wed, 26 Jun 2002 10:52:07 +0100aU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>  Subject: Re: TCO study0 Message-ID: <afc2qd$80m$1@new-usenet.uk.sun.com>   Main, Kerry wrote:  	 > Gerard,| >  > Re: TCO Study .. Check out:-G > http://www.openvms.compaq.com/openvms/whitepapers/enterprise_tco.htmlx >     C Sorry its horribly flawed and you know it, putting the GS320 in theoG same class as a bunch of servers that at a minium have 2x its capacity ,0 is hardly going to generate like for like costs.  @ Bang the GS320 back into the mid-range section where it belongs,< re-do the study and hey presto you find that the TCO numbers( don't look any thing like as attractive.  = Do yourself and Compaq/HP a favour and stop trotting out thist> "white paper" every time anyone askes about TCO, its laughable at best.  ? If your remember last time you provided this TCO study you weret> unable to justify the GS320's grouping with the F15000 and the
 SuperDome.  8 For Gerard's information a standard "TCO study" trick if9 the TCO study has been commisioned by a particular vendor 4 is for the vendor sponsoring the study to "help" the6 party doing the study by classifying their products in3 a higher capacity bracket than they should be, this 2 neatly skews the TCO study in favour of the vendor9 sponsoring the "study" and the rest is marketing history.   : Of course this may not have happened in this case but then; if it didn't then how on earth do you explain the inclusionI6 of the GS320 in the large server category. There is no= performance of capacity planning data available that supportsr6 this placement. The only possible metric you could use: to justify this position is floor space, the GS320 despite being rather slow is vast.  9 Sadly this exercise doesn't produce helpfull data and itso ridiculously easy to refute.     Regards  Andrew Harrisonr      	 > Regards  >  > Kerry Main > Senior Consultantr > Hewlett-Packard Canada# > Consulting & Integration Services4 > Voice: 613-592-4660a > Fax   : 613-591-4477 > Email: Kerry.Main@hp.com >  >  > -----Original Message-----, > From: labadie [mailto:labadie_g@decus.fr]  > Sent: June 25, 2002 4:47 AMe > To: Info-VAX@Mvb.Saic.Comh > Subject: TCO study >  >  > Some thoughts about TCO. > > I have been recently to Decus Lyon, and talked to a Vms System Engineer. He works now on Vms and a Unix (I will not say which one). He said that, in his opinion, the TCO of his Unix machines was very, very high compared to Vms. He said that he was called too often during the night or the week-end, and that he could not understand why they were working with that Operating System, not reliable at all, a nightmare as he said. > 2 > I guess a honest study about TCO does not exist.n > If  Ibm (or HP, or ...) has one, it will only reflect the relative power of the Mvs, Aix, OS 400 inside Ibm. >  >  I do not talk about  a study by D H Brown, paid by Microsoft, to show that Linux was more expensive than NT, or something like that.2 > 4 > I guess a honest study about TCO is an oxymoron... > 	 > RegardsR >  > Grard >  >  >    ------------------------------  % Date: Wed, 26 Jun 2002 06:49:18 -0400n' From: "Main, Kerry" <Kerry.Main@hp.com>. Subject: RE: TCO studyT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4026607C4@kaoexc01.americas.cpqcorp.net>   Andrew,   F >>> There is no performance of capacity planning data available that = supports this placement.<<<r  J Geez.. almost exactly what a direct competitor would state ..keep saying =9 it and maybe some day, someone will actually believe you.    :-)   G The fact that the GS320 still has 2 of the top 10 TPC slots while Sun = + has none apparently does not count - right?   
 Reference:J http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=3Dnonclu= ster&version=3D5  G [ok, now its your turn to insert std Sun "yeah, but- but - but " here =  .]   :-)o   Regards,  
 Kerry Main Senior Consultantn Hewlett-Packard Canada! Consulting & Integration Servicesn Voice: 613-592-4660  Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----) From: Andrew Harrison SUNUK Consultancy =r7 [mailto:andrew_nospam.harrison_remove_this@sun#.com]=20a Sent: June 26, 2002 5:52 AMi To: Info-VAX@Mvb.Saic.Come Subject: Re: TCO study         Main, Kerry wrote:  	 > Gerard,t >=20  > Re: TCO Study .. Check out:=20G > http://www.openvms.compaq.com/openvms/whitepapers/enterprise_tco.html  >=20    J Sorry its horribly flawed and you know it, putting the GS320 in the same =D class as a bunch of servers that at a minium have 2x its capacity=200 is hardly going to generate like for like costs.  H Bang the GS320 back into the mid-range section where it belongs, re-do =G the study and hey presto you find that the TCO numbers don't look any =n thing like as attractive.c  F Do yourself and Compaq/HP a favour and stop trotting out this "white =@ paper" every time anyone askes about TCO, its laughable at best.  H If your remember last time you provided this TCO study you were unable =B to justify the GS320's grouping with the F15000 and the SuperDome.  8 For Gerard's information a standard "TCO study" trick if9 the TCO study has been commisioned by a particular vendor 4 is for the vendor sponsoring the study to "help" the6 party doing the study by classifying their products in3 a higher capacity bracket than they should be, this.2 neatly skews the TCO study in favour of the vendor9 sponsoring the "study" and the rest is marketing history.2  : Of course this may not have happened in this case but then; if it didn't then how on earth do you explain the inclusioneG of the GS320 in the large server category. There is no performance of =-I capacity planning data available that supports this placement. The only =@H possible metric you could use to justify this position is floor space, =, the GS320 despite being rather slow is vast.  H Sadly this exercise doesn't produce helpfull data and its ridiculously = easy to refute.d     Regardsf Andrew Harrison'      	 > Regardsn >=20 > Kerry Main > Senior Consultant  > Hewlett-Packard Canada# > Consulting & Integration Services  > Voice: 613-592-4660p > Fax   : 613-591-4477 > Email: Kerry.Main@hp.com >=20 >=20 > -----Original Message-----+ > From: labadie [mailto:labadie_g@decus.fr]a > Sent: June 25, 2002 4:47 AMs > To: Info-VAX@Mvb.Saic.Com> > Subject: TCO study >=20 >=20 > Some thoughts about TCO. >=20C > I have been recently to Decus Lyon, and talked to a Vms System=20eI > Engineer. He works now on Vms and a Unix (I will not say which one).=20 I > He said that, in his opinion, the TCO of his Unix machines was very,=20gJ > very high compared to Vms. He said that he was called too often during =  I > the night or the week-end, and that he could not understand why they=20eD > were working with that Operating System, not reliable at all, a=20 > nightmare as he said.d >=202 > I guess a honest study about TCO does not exist.G > If  Ibm (or HP, or ...) has one, it will only reflect the relative=20n+ > power of the Mvs, Aix, OS 400 inside Ibm.s >=20J >  I do not talk about  a study by D H Brown, paid by Microsoft, to show =  @ > that Linux was more expensive than NT, or something like that. >=204 > I guess a honest study about TCO is an oxymoron... >=20	 > Regardse >=20
 > G=E9rard >=20 >=20 >=20   ------------------------------  % Date: Wed, 26 Jun 2002 08:43:23 -0400k1 From: Michael Austin <maustin@firstdbasource.com>  Subject: Re: TCO study2 Message-ID: <3D19B6EB.41192009@firstdbasource.com>  ( Andrew Harrison SUNUK Consultancy wrote: >  > Main, Kerry wrote: >  > > Gerard,l > >l > > Re: TCO Study .. Check out:rI > > http://www.openvms.compaq.com/openvms/whitepapers/enterprise_tco.htmln > >i > E > Sorry its horribly flawed and you know it, putting the GS320 in the H > same class as a bunch of servers that at a minium have 2x its capacity2 > is hardly going to generate like for like costs. > B > Bang the GS320 back into the mid-range section where it belongs,> > re-do the study and hey presto you find that the TCO numbers* > don't look any thing like as attractive. > ? > Do yourself and Compaq/HP a favour and stop trotting out thisv@ > "white paper" every time anyone askes about TCO, its laughable
 > at best. > A > If your remember last time you provided this TCO study you were @ > unable to justify the GS320's grouping with the F15000 and the > SuperDome. > : > For Gerard's information a standard "TCO study" trick if; > the TCO study has been commisioned by a particular vendor 6 > is for the vendor sponsoring the study to "help" the8 > party doing the study by classifying their products in5 > a higher capacity bracket than they should be, thisr4 > neatly skews the TCO study in favour of the vendor; > sponsoring the "study" and the rest is marketing history.  > < > Of course this may not have happened in this case but then= > if it didn't then how on earth do you explain the inclusion 8 > of the GS320 in the large server category. There is no? > performance of capacity planning data available that supportsf8 > this placement. The only possible metric you could use< > to justify this position is floor space, the GS320 despite > being rather slow is vast. > ; > Sadly this exercise doesn't produce helpfull data and itsi > ridiculously easy to refute. > 	 > Regards  > Andrew Harrison  >  > > Regards- > >- > > Kerry Main > > Senior Consultant0 > > Hewlett-Packard Canada% > > Consulting & Integration Servicesu > > Voice: 613-592-4660o > > Fax   : 613-591-4477 > > Email: Kerry.Main@hp.com > >u > >  > > -----Original Message------ > > From: labadie [mailto:labadie_g@decus.fr]p > > Sent: June 25, 2002 4:47 AMr > > To: Info-VAX@Mvb.Saic.Coml > > Subject: TCO study > >l > >  > > Some thoughts about TCO. > >e> > I have been recently to Decus Lyon, and talked to a Vms System Engineer. He works now on Vms and a Unix (I will not say which one). He said that, in his opinion, the TCO of his Unix machines was very, very high compared to Vms. He said that he was called too often during the night or the week-end, and that he could not understand why they were working with that Operating System, not reliable at all, a nightmare as he said. > >d4 > > I guess a honest study about TCO does not exist.p > > If  Ibm (or HP, or ...) has one, it will only reflect the relative power of the Mvs, Aix, OS 400 inside Ibm. > >  > >  I do not talk about  a study by D H Brown, paid by Microsoft, to show that Linux was more expensive than NT, or something like that.s > >a6 > > I guess a honest study about TCO is an oxymoron... > >  > > Regards  > > 
 > > Grard > >l > >e > >    Andrew,-  B I would put a GS320 or 8400 cluster up against any of the E-seriesD (including E10K) in terms of stablility, scalability, throughput and reliability.    F I built a small 2.5Tb datawarehouse that ftp'ed 6 6GB+ files, massagedH the data, created load files and loaded them into an Rdb database in 2.5= hours processing time with very complicated reports running. rE Unfortunately the company was on a campaign to replace all of the VMSaE with Sun (somebody at Digital/Compaq really pissed them off...).  BTWmG the 8400 was 10*625Mhz-10GB Mem and the E10K was 12 or 24*850Mhz (don'tm  recall exactly) with 10-12G Mem.  A The funny thing is, that they wanted to use Oracle on Sun and themC processing time on the E10K is 3-3.5 hrs.  REAL LIFE EXPERIENCE. NoaE "vendor-sponsored" study. The funny thing was that the E10K has to bed6 rebooted infinately more often than the 8400 ever did.   -- t Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163o7 Sr. Consultant            http://www.firstdbasource.comoE                           http://www.firstdbasource.com/donation.html-/ 704-947-1089 (Office)     704-236-4377 (Mobile)5   ------------------------------  % Date: Wed, 26 Jun 2002 14:35:10 +0100tU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>o Subject: Re: TCO study0 Message-ID: <afcfsk$c5s$1@new-usenet.uk.sun.com>   Main, Kerry wrote:  	 > Andrew,d >  > ` >>>>There is no performance of capacity planning data available that supports this placement.<<< >>>> >  > Geez.. almost exactly what a direct competitor would state ..keep saying it and maybe some day, someone will actually believe you. >     F Well when you can come up with one concrete example of why I shouldn't? make this claim then you might have a point but as you know youe cannot So cut the BS.e     > :-)e > s > The fact that the GS320 still has 2 of the top 10 TPC slots while Sun has none apparently does not count - right?  >     G Fact is very few people think that large TPC-C results have much directe4 value except to keep marketing people like you busy.  8 Fact is all 3 of the benchmarks that Sun and Compaq have7 done show Sun to be faster, in very pathetic attempt atp7 spin you have latched on to the only benchmark that SunM+ hasn't done for obvious but futile reasons.   7 You will note that I havn't bothered to include all the.6 other high end commercial benchmarks that Sun has done6 where we obviously lead Compaq because you havn't done" them, SAP Banking, PeopleSoft etc.       > Reference:W > http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=noncluster&version=5a > J > [ok, now its your turn to insert std Sun "yeah, but- but - but " here .] >     A I don't really need to though I have, your constituency out theres< is sufficiently intelligent to realise that your argument is; bogus, please feel free to keep it up though its always funl& helping you out when you get it wrong.   Regardsd Andrew Harrisonc    '   ------------------------------  # Date: Wed, 26 Jun 2002 13:34:05 GMT / From: "Mark E. Levy" <mlevy70-nospam@attbi.com>s Subject: Re: TCO study? Message-ID: <hpjS8.189428$6m5.158912@rwcrnsc51.ops.asp.att.net>h  > "Michael Austin" <maustin@firstdbasource.com> wrote in message, news:3D19B6EB.41192009@firstdbasource.com...* > Andrew Harrison SUNUK Consultancy wrote:   ..snip..  I Y'know, Andrew, you can keep refuting HPQ's TCO white paper all you like. D Funny thing is, that if once in a while, you admitted that Sun isn'tK superior in every possible way, you'd be far more believable. But to listentL to you, Sun is better/faster/cheaper in every possible application and everyJ possible situation. Your credibility and the great void of space have some& remarkable similarities in this forum.  L That said, many years ago I worked for a national laboratory that was almostE entirely VMS based. Due to some serious missteps on the part of DEC'skJ "salespeople" and for other reasons I won't go into, the decision was madeG to start bringing in various flavors of Unix systems (including Sun) top replace VMS.  G I was a member of a 5-person group charged with the responsibilities ofeH maintaining a significant fraction of the VMS environment, consisting ofG some very large clusters (one with over 100 nodes) and many stand-aloneVI machines. As the Unix systems began to come in and a similar Unix systemssL group was formed, it became apparent that it took many more people (at leastE 50% more) to maintain a smaller number of Unix systems. IIRC, AIX was L considered the worst Unix flavor to work with, Sun was not far behind. OSF-1G (as it was called at the time) was one of the easier to work with. Now,yI staffing requirements are only a part of the TCO, but salaries being whatu! they are, it can be a large part.o  F I'm as much a VMS bigot as anyone here, but I can admit that there areF applications where VMS may not be suitable. Every system and operatingJ enviroment has it's strengths and weaknesses. If you would concede as muchL about your beloved employer once in a while, maybe you wouldn't get quite asK much flak here and your comments might actually gain some credibility. Theno again, maybe not..  	 Mark Levyl   ------------------------------  % Date: Wed, 26 Jun 2002 10:06:08 -0400.1 From: Michael Austin <maustin@firstdbasource.com>o Subject: Re: TCO study2 Message-ID: <3D19CA50.45980A09@firstdbasource.com>  ( Andrew Harrison SUNUK Consultancy wrote: >  > Main, Kerry wrote: >  > > Gerard,u > >2 > > Re: TCO Study .. Check out:rI > > http://www.openvms.compaq.com/openvms/whitepapers/enterprise_tco.htmlj > >R > E > Sorry its horribly flawed and you know it, putting the GS320 in therH > same class as a bunch of servers that at a minium have 2x its capacity2 > is hardly going to generate like for like costs. > B > Bang the GS320 back into the mid-range section where it belongs,> > re-do the study and hey presto you find that the TCO numbers* > don't look any thing like as attractive. >     H So what you are saying is that while the GS320 has half the capacity, itG does the same amount of work and has better TCO than Sun with twice thee7 capacity?  Hmmm. I guess buying Sun is better... NOT!!!l   -- o Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163y7 Sr. Consultant            http://www.firstdbasource.comrE                           http://www.firstdbasource.com/donation.htmle/ 704-947-1089 (Office)     704-236-4377 (Mobile)O   ------------------------------  # Date: Wed, 26 Jun 2002 14:27:40 GMTo5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>e Subject: Re: TCO study2 Message-ID: <wbkS8.34$Wi6.433260@news.cpqcorp.net>  J Andrew, as others have pointed out, it seems to be you that seem to switchF to benchmark dejur if the one you  were touting yesterday is no longerK looking good today.  From what I can tell, Sun is now discounting Spec, and K TPC-C benchmarks (because you look pretty bad).  They are touting a LINPACKcJ benchmark for Fujitsu (even though the high-end space there is pretty well Alpha dominated).e  J Pretty soon, I expect you to come out with a full suite of benchmarks thatG will only run on Solaris.  Then your world will be a nice tidy package.c      6 Andrew Harrison SUNUK Consultancy wrote in message ... >rH >Fact is very few people think that large TPC-C results have much direct5 >value except to keep marketing people like you busy.s >i9 >Fact is all 3 of the benchmarks that Sun and Compaq have 8 >done show Sun to be faster, in very pathetic attempt at8 >spin you have latched on to the only benchmark that Sun, >hasn't done for obvious but futile reasons. > 8 >You will note that I havn't bothered to include all the7 >other high end commercial benchmarks that Sun has doneu7 >where we obviously lead Compaq because you havn't done # >them, SAP Banking, PeopleSoft etc.c >n   ------------------------------  % Date: Wed, 26 Jun 2002 15:19:40 +0100rU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>e Subject: Re: TCO study0 Message-ID: <afcig2$d1h$1@new-usenet.uk.sun.com>   Mark E. Levy wrote:i  @ > "Michael Austin" <maustin@firstdbasource.com> wrote in message. > news:3D19B6EB.41192009@firstdbasource.com... > * >>Andrew Harrison SUNUK Consultancy wrote: >> > 
 > ..snip.. > K > Y'know, Andrew, you can keep refuting HPQ's TCO white paper all you like.iF > Funny thing is, that if once in a while, you admitted that Sun isn'tM > superior in every possible way, you'd be far more believable. But to listendN > to you, Sun is better/faster/cheaper in every possible application and everyL > possible situation. Your credibility and the great void of space have some( > remarkable similarities in this forum. >     9 Where did I say Sun was superior in every other respect ?   < I don't recollect saying, I wouldn't since I don't think its true.t  ; You may have forgotten that I have in the past and recentlya9 said that the ES40 and now the ES45 are competitive boxese vs Sun's equivalent machines.y  < And if your workload is very very like SPECint or SPECfp and= I am sure that some customers apps do fall into this categoryt; then you only have to look at the SPECint and SPECfp tablest4 to realise that Alpha based systems are competitive.  = Perhaps you should try the boot on the other foot, Compaq whob@ you appear to like have marketed their servers as being superiorA in every respect but only have for performance SPECint and SPECfpe to back up these claims.    N > That said, many years ago I worked for a national laboratory that was almostG > entirely VMS based. Due to some serious missteps on the part of DEC'smL > "salespeople" and for other reasons I won't go into, the decision was madeI > to start bringing in various flavors of Unix systems (including Sun) to  > replace VMS. > I > I was a member of a 5-person group charged with the responsibilities ofeJ > maintaining a significant fraction of the VMS environment, consisting ofI > some very large clusters (one with over 100 nodes) and many stand-aloneiK > machines. As the Unix systems began to come in and a similar Unix systemsGN > group was formed, it became apparent that it took many more people (at leastG > 50% more) to maintain a smaller number of Unix systems. IIRC, AIX wastN > considered the worst Unix flavor to work with, Sun was not far behind. OSF-1I > (as it was called at the time) was one of the easier to work with. Now,fK > staffing requirements are only a part of the TCO, but salaries being whats# > they are, it can be a large part.5 >       = Since you refer to OSF-1 then I would agree in the sense that ? Sun did not concentrate on managability with the early releaseso of Solaris 2.x.n  < But Sun has subsequently done a lot of work in that are, SMC= and SunMC being two products which help people manage Solarist boxes.     Regards    Andrew HarrisonO   ------------------------------  % Date: Wed, 26 Jun 2002 10:52:17 -0400e' From: "Main, Kerry" <Kerry.Main@hp.com>h Subject: RE: TCO studyT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4026607C8@kaoexc01.americas.cpqcorp.net>   Andrew, Andrew -  H Now, now - first you ask for industry benchmark data, then I give it and2 then you state "yeah, but that does not matter .."  F The reality here is that everyone in this newsgroup realizes benchmarkB results are a snapshot in time that will always be beat by someone faster over time.=20  F The GS320 systems have very respectable TPC benchmark numbers (not the@ top, but Sun has none) and numerous Customers with very high endG application requirements who are very happy with the performance levels4
 they have.  G Here are some Customer testimonials that include GS Series systems thate  you constantly choose to ignore:2 http://www.openvms.compaq.com/gsseries/quotes.html   Regards,  
 Kerry Main Senior ConsultantT Hewlett-Packard Canada! Consulting & Integration Services  Voice: 613-592-4660  Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----' From: Andrew Harrison SUNUK Consultancy 7 [mailto:andrew_nospam.harrison_remove_this@sun#.com]=20s Sent: June 26, 2002 9:35 AMo To: Info-VAX@Mvb.Saic.Com  Subject: Re: TCO study         Main, Kerry wrote:  	 > Andrew,a >=20 >=20G >>>>There is no performance of capacity planning data available that=20e >>>>supports this placement.<<<i >>>> >=20F > Geez.. almost exactly what a direct competitor would state ..keep=20B > saying it and maybe some day, someone will actually believe you. >=20    F Well when you can come up with one concrete example of why I shouldn'tF make this claim then you might have a point but as you know you cannot So cut the BS.     > :-)h >=20J > The fact that the GS320 still has 2 of the top 10 TPC slots while Sun=20- > has none apparently does not count - right?  >=20    G Fact is very few people think that large TPC-C results have much directi4 value except to keep marketing people like you busy.  8 Fact is all 3 of the benchmarks that Sun and Compaq have7 done show Sun to be faster, in very pathetic attempt ata7 spin you have latched on to the only benchmark that Sund+ hasn't done for obvious but futile reasons.a  7 You will note that I havn't bothered to include all the 6 other high end commercial benchmarks that Sun has done6 where we obviously lead Compaq because you havn't done" them, SAP Banking, PeopleSoft etc.       > Reference:=20t > =eH http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=3Dnoncl > uster&version=3D5d >=20J > [ok, now its your turn to insert std Sun "yeah, but- but - but " here=20 > .] >=20    D I don't really need to though I have, your constituency out there isG sufficiently intelligent to realise that your argument is bogus, pleasetF feel free to keep it up though its always fun helping you out when you
 get it wrong.e   Regards  Andrew Harrisoni   =20    ------------------------------  % Date: Wed, 26 Jun 2002 17:34:19 +0100 U From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>s Subject: Re: TCO study0 Message-ID: <afcqch$fea$1@new-usenet.uk.sun.com>   Michael Austin wrote:o  * > Andrew Harrison SUNUK Consultancy wrote: >  >>Main, Kerry wrote: >> >>
 >>>Gerard, >>>  >>>Re: TCO Study .. Check out:H >>>http://www.openvms.compaq.com/openvms/whitepapers/enterprise_tco.html >>>t >>> E >>Sorry its horribly flawed and you know it, putting the GS320 in the H >>same class as a bunch of servers that at a minium have 2x its capacity2 >>is hardly going to generate like for like costs. >>B >>Bang the GS320 back into the mid-range section where it belongs,> >>re-do the study and hey presto you find that the TCO numbers* >>don't look any thing like as attractive. >> >> >  > J > So what you are saying is that while the GS320 has half the capacity, itI > does the same amount of work and has better TCO than Sun with twice the 9 > capacity?  Hmmm. I guess buying Sun is better... NOT!!!l >  >     / No by capacity I mean its ability to do usefulla& work, what else did you think I ment ?     Regardsu Andrew HarrisonO   ------------------------------  % Date: Wed, 26 Jun 2002 17:44:31 +0100eU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>l Subject: Re: TCO study0 Message-ID: <afcqvl$fp0$1@new-usenet.uk.sun.com>   Fred Kleinsorge wrote:  L > Andrew, as others have pointed out, it seems to be you that seem to switchH > to benchmark dejur if the one you  were touting yesterday is no longerM > looking good today.  From what I can tell, Sun is now discounting Spec, andtM > TPC-C benchmarks (because you look pretty bad).  They are touting a LINPACKpL > benchmark for Fujitsu (even though the high-end space there is pretty well > Alpha dominated).t >     > Sorry Freddy boy I have been dismisive of TPC-C as a benchmark< for some time, mostly because of the Compaq shenanigans with8 shared nothing based configurations but also because its9 an absurdly simple test to use to try to characterise the  performance of an OLTP system.  7 And even you in your challenged state will realise that 7 if you are comparing 2 products where both vendors have < done 3 tests which one vendor easily wins then any arguments9 from the losing vendor based on say another test that thes8 winner of the first 3 didn't do is hardly convincing, it just looks like spin.   < It would be rather like Ford claiming that a Focus is faster8 than a Ferrari on acceleration because while the Ferrari7 creamed it on 0-100 KPH numbers Ferrari which they botht; had done, only Ford had done the 0-60 MPH test and so couldM spin an apparent victory.i  ( You are in the same boat get used to it.     Regardsw   Andrew Harrisone   ------------------------------  # Date: Wed, 26 Jun 2002 09:47:51 GMTe+ From: Roland Barmettler <rob@bbp.ch.remove> # Subject: Trouble with BACKUP/RECORDg7 Message-ID: <20020626114748.759b164d.rob@bbp.ch.remove>a   Hi Guysp  < I have a problem with BACKUP/RECORD or rather /SINCE=BACKUP.  
 If I do a:) $ BACKUP/RECORD/LOG *.TXT;* TEST.BCK/SAVE-  A and have a look at the backup date in the file header afterwards,4& it's correctly recorded (as expected).   But if I then do a: 0 $ BACKUP/LOG *.TXT;*/SINCE=BACKUP TEST1.BCK/SAVE  < I still get all the files backed-up. /SINCE=yesterday works,5 /SINCE=<timestamp> works, only /SINCE=BACKUP doesn't.i   This happens on 7.2-1 and 7.3. What am I missing ?   
 Thanks a lot.  Greetings, Rolandw  F --------------- bbp - Biveroni Batschelet Partners AG ----------------:              Bahnhofstrasse 28, CH-5401 Baden, SwitzerlandF ----------------------------------------------------------------------   ------------------------------   Date: 26 Jun 2002 15:59:51 GMT4 From: "Jim Strehlow" <JimStrehlowNoSpam@data911.com>' Subject: Re: Trouble with BACKUP/RECORD 0 Message-ID: <afcodn$j45@dispatch.concentric.net>  D I ran a quick check and had no problems on both versions of OpenVMS.> Does your v7.3 computer have the DEC-AXPVMS-VMS73_BACKUP-V0100* patch applied?  ($ PRODUCT  SHOW  HISTORY)  & Jim Strehlow, Data911, www.data911.com Alameda, CA, USA    8 "Roland Barmettler" <rob@bbp.ch.remove> wrote in message1 news:20020626114748.759b164d.rob@bbp.ch.remove...h	 > Hi Guysr >T> > I have a problem with BACKUP/RECORD or rather /SINCE=BACKUP. >l > If I do a:+ > $ BACKUP/RECORD/LOG *.TXT;* TEST.BCK/SAVEn >dC > and have a look at the backup date in the file header afterwards,p( > it's correctly recorded (as expected). >a > But if I then do a:n2 > $ BACKUP/LOG *.TXT;*/SINCE=BACKUP TEST1.BCK/SAVE >t> > I still get all the files backed-up. /SINCE=yesterday works,7 > /SINCE=<timestamp> works, only /SINCE=BACKUP doesn't.o >q  > This happens on 7.2-1 and 7.3. > What am I missing ?t >  > Thanks a lot.: > Greetings, Rolandg >cH > --------------- bbp - Biveroni Batschelet Partners AG ----------------< >              Bahnhofstrasse 28, CH-5401 Baden, SwitzerlandH > ----------------------------------------------------------------------   ------------------------------   Date: 26 Jun 2002 11:16:46 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: VMS port delayed!0 Message-ID: <afc7qu$crp$1@pegasus.csx.cam.ac.uk>  9 In article <3d18cea2.1454311168@proxy.news.easynews.com>, 2 prune@ZAnkh-Morpork.mv.com (Paul Winalski) writes:6 |> On Tue, 25 Jun 2002 15:28:50 GMT, "Fred Kleinsorge"' |> <kleinsorge@star.zko.dec.com> wrote:c |> sN |> >I'm not quite sure who they get their information from, but as the projectM |> >leader for the initial bootstrap of VMS on Itanium, I've not been able toaM |> >figure out what exactly this "HAL" thing/problem is.  I would *hope* that  |> >*I* would know about it. |> >2 |> >Perhaps they are referring to our use of ACPI? |> u> |> Yes, I think they're referring to implementing an interface6 |> to ACPI.  In NT this part of the code is called the$ |> Hardware Abstraction Layer (HAL). |> s8 |> And as you say, VMS Engineering has been aware of the: |> need for that code from the get-go.  It's by no means a |> 'snagette'.  @ Eh?  Doesn't that layer date from the port to the Alpha?  If so,? I will bet that they were aware for the need for that work fromp= then - you don't design such an interface without being awaree? that you may want to use it for the same purpose in the future.   > If there are any problems with the delaying of the VMS initial@ boot (and I have no idea whether there are or not), they will be> because the implementation (and perhaps reengineering) of thatA sort of level is harder than was estimated.  Not because the neede
 wasn't known.e  = As many people know, I regard the IA-64 as a nightmare in theb? areas of interrupt and exception handling - both from the point A of view of efficiency and that of reliability.  But I can witnessd= that the VMS people were aware that this area would need very. careful attention.  > Which, of course, doesn't mean that there won't be any delays,= "snagettes" etc., but they will probably be horribly complex.g> As technical people are much less gabby than executives, it is? very common for such issues to get horribly misrepresented whens= they hit the press.  I have seen trivial items made out to bei9 disasters, and disasters made out to be trivial, and ....e     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: Wed, 26 Jun 2002 14:10:28 GMTi5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>: Subject: Re: VMS port delayed!2 Message-ID: <oXjS8.29$Wi6.433260@news.cpqcorp.net>  " Nick Maclaren wrote in message ... > : >In article <3d18cea2.1454311168@proxy.news.easynews.com>,3 >prune@ZAnkh-Morpork.mv.com (Paul Winalski) writes:p7 >|> On Tue, 25 Jun 2002 15:28:50 GMT, "Fred Kleinsorge"y( >|> <kleinsorge@star.zko.dec.com> wrote: >|>hG >|> >I'm not quite sure who they get their information from, but as thei projecthK >|> >leader for the initial bootstrap of VMS on Itanium, I've not been ablet toI >|> >figure out what exactly this "HAL" thing/problem is.  I would *hope*n that >|> >*I* would know about it.a >|> >g3 >|> >Perhaps they are referring to our use of ACPI?i >|>t? >|> Yes, I think they're referring to implementing an interfaceo7 >|> to ACPI.  In NT this part of the code is called thei% >|> Hardware Abstraction Layer (HAL).. >|>T9 >|> And as you say, VMS Engineering has been aware of the ; >|> need for that code from the get-go.  It's by no means an >|> 'snagette'.  > A >Eh?  Doesn't that layer date from the port to the Alpha?  If so, @ >I will bet that they were aware for the need for that work from> >then - you don't design such an interface without being aware@ >that you may want to use it for the same purpose in the future. >s  K On Alpha, VMS loads platform specific code based on information provided by8H the firmware (CPU type, family ID, etc).  This platform code understandsH things like what a Tsunami chip looks like.  It also directly probes for/ devices, and has hardwired motherboard devices.t  I The IA64 firmware environment provides what I'll call "scripts" which arerG byte-coded interpreted code that is excecuted by the AML interpretor in K ACPI.  ACPI started out as a power management thing for laptops, but is nowaL the way that a platform is described to the operating system.  So instead ofI the OS knowing about specifics of the platform, the ACPI firmware scriptsaE knows about it, and the O/S uses the ACPI interfaces to configure the J system.  These interfaces also provide the means to interact with parts of1 the system - without explicit hardware knowledge.s  L We've pretty much understood this from the beginning.  The only real "issue"L with ACPI has been "how much is real".  The Itanium-1 systems, and the O/S'sI that support them only did minimal support of ACPI (the book "ia-64 linuxYI kernal" is a good read if you are interested in one implementation).  ThemI question has been to discover how much is vapor, and how much is real forsE Itanium-2 (our target chip) platforms.  Can we do a single ACPI based-I configuration method (for example) and never have to do another one againrG (platform independence) and if we can, are all the pieces of the puzzlem there *today*?  K If there is anything "new" to report, it's that we have concluded that ACPIoL is there, and is solid, and will be the way we configure the system from dayL 1.  Becoming part of HP, and getting insight from their FW, HW and OS people4 has helped us quite a bit on sorting through things.  L BTW - to make the poor guy at Island feel better - this is one reason why itI would be more difficult to stop VMS from running on generic hardware - weoE are doing our best to not have detailed knowledge of the HW above the E controller level.  And just *try* to find some string or value in thes5 firmware to tell you the vendor and the model number.s  ? >If there are any problems with the delaying of the VMS initialhA >boot (and I have no idea whether there are or not), they will be ? >because the implementation (and perhaps reengineering) of thatoB >sort of level is harder than was estimated.  Not because the need >wasn't known. >t  * Estimates always get better over time ;-).  > >As many people know, I regard the IA-64 as a nightmare in the@ >areas of interrupt and exception handling - both from the pointB >of view of efficiency and that of reliability.  But I can witness> >that the VMS people were aware that this area would need very >careful attention.y >e  E Well, it's not that bad.  In fact, this is an area where we have doneeJ considerable work, and so far nothing really unexpected has come up.  Now,G you don't like modern system approaches to interrupt handling at-all --r Nothings going to change there.o  ? >Which, of course, doesn't mean that there won't be any delays,i> >"snagettes" etc., but they will probably be horribly complex.? >As technical people are much less gabby than executives, it isn@ >very common for such issues to get horribly misrepresented when> >they hit the press.  I have seen trivial items made out to be: >disasters, and disasters made out to be trivial, and .... >   J So, this as about as Gabby as I'll get.  Whoever spread this report to theG Inquirer is unlikely to be an executive, but someone in engineering whomH probably gets his information in the lunchroom, or from status summariesI that don't get deeply into detail, and is not particularly well informed.uL In trying to describe the issue, someone must have tried to "clarify" things( by relating ACPI or CPU_ROUTINES to HAL.   ------------------------------  # Date: Wed, 26 Jun 2002 15:33:24 GMT 1 From: LESLIE@JRLVAX.HOUSTON.RR.COM (Jerry Leslie)  Subject: Re: VMS port delayed!9 Message-ID: <89lS8.15172$PJ.556523@typhoon.austin.rr.com>o  4 Fred Kleinsorge (kleinsorge@star.zko.dec.com) wrote: : L : BTW - to make the poor guy at Island feel better - this is one reason why L : it would be more difficult to stop VMS from running on generic hardware - J : we are doing our best to not have detailed knowledge of the HW above theG : controller level.  And just *try* to find some string or value in the17 : firmware to tell you the vendor and the model number.c : D Perhaps Palladium will supply something that contains the vendor and model numbers designation...  3    Microsoft's Palladium: A New Security Initiatives;    http://www.extremetech.com/article2/0,3973,274309,00.asp   I   "In a move that seeks to extend Microsoft's newfound company-wide focussH    on security to future versions of the Windows operating system and toK    hardware products, Microsoft officials are discussing a new initiative, c    code-named Palladium.  G    Palladium involves new security components to be built into Windows,dF    but it also depends heavily on hardware makers--including Intel andI    AMD--building in Palladium functionality to their products. While nonesE    of the new features and products will arrive this year, the effortmG    appears to be a large-scale push toward a new breed of software- andT)    hardware-driven security standards..."g    ;    http://www.extremetech.com/article2/0,3973,282114,00.aspi4    Palladium Clues May Lie In AMD Motherboard Design  H   "...Wave's EMBedded Application Security System (EMBASSY) is actually G    an embedded microprocessor of undisclosed complexity, which containsiH    secure non-volatile memory, secure I/O, a secure real-time clock, and?    operating system. Wave currently sells the chip as part of a B    "cryptographic service provider kit," which uses a small clientE    terminal to encrypt data like email. However, the chip can be sold "    into a variety of applications.  C    According to the whitepaper, the reference design allows for theo>    running of secure boot, TCPA integrity metrics, strong userF    authentication, and secure BIOS upgrades. "We will also provide theG    Wave EMBASSY metering application to support various commerce modelsh?    for consumer entertainment content," the whitepaper adds..."     2 --Jerry Leslie   (my opinions are strictly my own)9   Note: leslie@jrlvax.houston.rr.com is invalid for email    ------------------------------    Date: 26 Jun 2002 08:22:05 -0600- From: koehler@encompasserve.org (Bob Koehler)t Subject: Re: wow3 Message-ID: <+CFzBitC+3ah@eisner.encompasserve.org>d  a In article <27_R8.51756$db.877815@twister.tampabay.rr.com>, "John N." <JNixon@cfl.rr.com> writes: J > I am going to go have another cup of coffee, and come back and read thisJ > whole article.  I am not sure I read it right and I don't want to get my > hopes up:e >  > From yahoo news: > E > HP Unveils Enhanced OpenVMS Operating System that Is e-Business and& > Internet-Ready. > http://biz.yahoo.com/bw/020625/250215_1.html      Two, we want more!=   ------------------------------   End of INFO-VAX 2002.349 ************************