1 INFO-VAX	Fri, 21 Jul 2006	Volume 2006 : Issue 403       Contents:! Re: 2 CPU's in timeout on my ES40  Re: Alpha remembrance day  Re: Alpha remembrance day & Re: Alpha Server Parts - Charleston SC6 Re: equivalent of MAIL>SET FORWARD/USER=ME YOU on unix) Re: New itaniums out at 2.5x perform gain ) Re: New itaniums out at 2.5x perform gain ) Re: New itaniums out at 2.5x perform gain ) Re: New itaniums out at 2.5x perform gain ) Re: New itaniums out at 2.5x perform gain ) Re: New itaniums out at 2.5x perform gain ) Re: New itaniums out at 2.5x perform gain ) Re: New itaniums out at 2.5x perform gain $ Re[2]: 2 CPU's in timeout on my ES40 Re: XML on Expat Re: XML on Expat Re: XML on Expat Re: XML on Expat Re: XML on Expat  F ----------------------------------------------------------------------  % Date: Fri, 21 Jul 2006 10:18:13 -0400 * From: "Syltrem" <syltremzulu@videotron.ca>* Subject: Re: 2 CPU's in timeout on my ES400 Message-ID: <12c1odgd5b0dneb@corp.supernews.com>  0 <dave.baxter@bannerhealth.com> wrote in message < news:1153428465.241137.282440@75g2000cwc.googlegroups.com... >  > Syltrem wrote:E >> Has anyone experienced CPU's ceasing to be in service on an ES40 ?  >>E >> I've never seen this before, there are no errors on the system or   >> reported 
 >> by DIAG- >> 2 CPUs out of 4 are not working right now.  >> >> $ sh cpu  >># >> System: HELIOS, AlphaServer ES40  >> >> CPU ownership sets: >>    Active               0,2 >>    Configure            0-3 >> >> CPU state sets: >>    Potential            0-3 > F > Strangely enough, I had a similar event last week.     I had an ES40I > crash and reboot on Saturday Afternoon.    Since it was not critical, I G > didn't get to it until Monday, however I found a situation similar to I > that described above, (one I had never seen before either!).    One CPU D > (#2) was in a "TIMEOUT" state.    For me, the command above showed >  > CPU ownership sets:  >     Active        0,1,3  >     Configure    0-3 >  > A "show CPU 2 /full" showed  >  > CPU 2      State  TIMEOUT  > C > Interestingly, although the crash occurred on Saturday Afternoon, C > checking back showed that the CPU had assumed this state sometime D > overnight Thursday/Friday, however the system didn't crash at thatH > time.     Also the system rebooted and ran through to Tuesday evening,I > when it was taken down for repair.    The diagnostics run on the system ? > by the FE showed that the CPU was toast, and it was replaced.  > I > I mention this only so that the poster doesnt feel so bad about it, and H > also to show that although this seemed to be clearly a hardware issue,B > neither HP nor I was able to find any errors in system error log > relating to it.  > % > The crash dump indicated a BUGCHECK  >  > System crash information > ------------------------ > CPU bugcheck codes: : >        CPU 00 -- CPUSPINWAIT, CPU spinwait timer expired? >        2 others -- CPUEXIT, Shutdown requested by another CPU  > / > CPU 02 failed to service the bugcheck request  >  > Dave >    Interesting.  G My reason for the crash was the high temperature. I didn't even bother   looking at the crash dump.E But the technician could not find any evidence of an error in any log K Replacing CPU 1 fixed both 1 and 3 (3 possibly could not be seen when 1 is   dead?)K I don't know for sure what happened at boot time (preceding the finding of  J the problem). We do not have a hardcopy of the console. I presume VMS did K not start those 2 CPUs, because if they had stopped inadvertantly when VMS  > is up, it would have known and complained about it, certainly.   Syltrem    ------------------------------    Date: 21 Jul 2006 06:07:28 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayC Message-ID: <1153487248.545264.272620@b28g2000cwb.googlegroups.com>    Bill Todd wrote: > Andrew wrote:  > > Bill Todd wrote: > >> Andrew wrote: > >>> Bill Todd wrote:" > >>>> etmsreec@yahoo.co.uk wrote: > >>>>> Well, that's one view.
 > >>>>    Can O > >>>>> you say "lack of applications"?  Can you say "lack of operating systems  > >>>>> to run on it"?O > >>>> Can you say "incompetent blowhard?"  I think David addressed that latter E > >>>> chimera adequately, and given that one of said OSs was Windows L > >>>> (including support of x86 application binaries) I'd say that puts theH > >>>> former to rest as well (not to say that VMS and Tru64 didn't haveC > >>>> adequate application support in their own right, of course).  > >>>>C > >>> I read this post with some amusement for a number of reasons. K > >> Unfortunately, overlooking probably the best one - for which you would / > >> have had to have been looking in a mirror.  > >> > >  > > Really.  > D > Of course, Andrew:  unlike you, I don't bluster interminably about> > things I know little or nothing about - I rely more on fact. >  > > G > > And you follow that by rolling out the same old blame it on Palmer, 2 > > Curly and Carly nonsense. How hugely ammusing. > B > I sincerely hope that your spelling ability (or lack thereof) asH > evidenced over your years here is not characteristic of the quality ofI > England's educational system:  it's discouraging enough that the U.S.'s  > is so bad. >  > > I > > The sad reality is that Alphas woes and eventual demise may have been H > > exacerbated or at least allowed to get worse by Palmer/Curly etc butB > > the seeds for Alphas decline were sown by DEC and their seniorH > > management in the 80's before any of your favourite culprits were in > > the frame. > H > Now, that would be quite a feat, wouldn't it?  Since Alpha didn't evenH > *appear on the scene* until Palmer was in charge (1992), and obviouslyH > didn't reach its peak market penetration until considerably thereafterD > (I suspect not long before the Alphacide), dating the start of itsI > *decline* earlier than its birth is - well, pretty typical of the level 4 > of intelligence that you usually display, I guess. >   E What a truly ludicrous point. By the time Palmer came on the scene in F 1992 Alpha had been a fully funded project since 1989 and was itself aD followon from PRISM. The decisions to design and build Alpha and theE decisions about what OS platforms it would support and what migration E options would be offered to existing customers had already been made. E The only thing Palmer could have done at that point was cancelled the  project.  G As a perspective on Alpha from a rather better informed source than you F read the comments made by Michael Slater in an interview in 1992 after Alpha's announcement.   E UPSIDE: We didn't talk much about the Alpha chip. Is it going to be a 
 world-beater?   F SLATER: I don't think so. Alpha is an outstanding piece of technology.E It is probably superior architecture to the architectures that exist, G but I don't believe the differences are big enough to overcome the fact E that it is very late entering the market. There is an enormous amount F of inertia and software base that DEC has to fight. Every company thatE DEC goes out to convince to make Alpha chips or to build systems with D Alpha, every one of those companies over the last few years has beenD pitched by Sun for Sparc, pitched by Mips, then HP for PA RISC, then pitched by IBM for RS/6000.   C How precient of him the reasons for the death of Alpha spelt out in  1992 just after its launch.    > > G > > 1. DEC failed to catch the RISC wave first time around, not through G > > lack of projects but through lack of direction. Not 1 but 4 and bit K > > projects were started and cancelled by DEC, Titan, SAFE, HR-32, CASCADE I > > and finally PRISM which metamophosed out of CASCADE. This is one of a J > > number of examples which illustrate what a massive understatement your6 > > "(though not always ideally-focused) " comment is. > > < > > This lost DEC market share to Sun, HP, IBM and SGI/MIPS. > G > But of course (as I already noted above, but since you're both rather I > slow on the uptake and obstinate in your ignorance it bears repeating), D > this could not possibly have caused Alpha's *decline*, since Alpha+ > wouldn't even appear for a few years yet.  >   G Lack of velocity seems to be a trait that you are suffering from. DEC's E inability to choose a project and stick to it, their lateness and the B stop gap tactic of doing a MIPS based platform lost them momentum,F market share, customer and ISV loyalty. When Alpha came out it was tooE late entering as it did a market that was now crowded with other RISC G processors competing for ISV and design wins, DEC were unprofitable and > had lost their status as the alternative to IBM to Sun and HP.  ) Ever heard of the phrase Honeymoon Period   C Alpha benefited from a relatively brief honeymoon influenced by its C newness, its support for 64bit and its speed. The honeymoon quickly B ended when the underlying issues of ISV support, customer loyalty,F market share etc which were all caused by Digitals actions in the 7 or) so years leading up to the Alpha release.  > > E > > 2. Having belatedly realised that VAX wasn't going to survive the G > > onslaught of the RISC processors DEC initiated the short lived MIPS I > > platform running Ultrix a plaform seriously hampered by the fact that I > > DEC had not only missed catching the RISC wave but had also failed to J > > catch the UNIX wave as well. DEC sales people prefered selling VMS/VAXH > > and senior management openly denigrated UNIX while funding a product+ > > division to develop it. Sounds mad now.  > > F > > This lost DEC market share to Sun, HP, IBM and SGI who had no such > > qualms about selling UNIX. > J > But (yet again) this couldn't possibly have contributed to the *decline*C > of a product which had not even been introduced yet.  In fact, if I > anything it gave Alpha a lower starting point from which regaining lost E > market share might have been easier than beginning with more of it.  >   D Of course it could see above. When customers, partners etc no longer? see you as a safe pair of hands because of previous product and E strategy mishaps then the chances of your latest and greatest product ? in this case Alpha being a sucess are significantly diminished.    > > H > > 3. Having managed to create an ecosystem for Ultrix/MIPS DEC startedD > > the Alpha development project in 1989 with no real intentions ofH > > porting Ultrix to Alpha or providing any remotely sensible migration > > path from Ultrix to Tru64. > J > So what?  Once again, this (debatable) intent at Alpha's birth could notG > possibly have caused it to *decline* - it could at worst have limited D > its growth (and indeed did for years in the Unix marketplace, as I > already observed).  Idiot.   Trust, momentum, idiot.  >  > > I > > The Alpha introduction in 1992 with the inevitable Ultrix demise that A > > followed left all DEC's partners in the Ultrix/MIPS ecosystem I > > floundering, customers ran for the hills hotly pursued by sales teams D > > from Sun, IBM, HP, SGI etc waving blank order forms.  (See sales > > peoples commision later) > H > Since I already observed that the Unix vacillations you describe aboveG > contributed to a slow ramp-up for Tru64 on Alpha, I'm really not sure H > what your regurgitation was meant to accomplish (though it seems clear@ > that whatever it may have been, it had nothing to do with yourI > ridiculous contention that Alpha 'declined' due to lack of applications I > rather than simply had an up-hill battle to fight on the Unix front due  > to earlier missteps by DEC). >  > > G > > 4. DEC started out as an alternative to IBM but ended up becoming a E > > mini IBM without the deep pockets or market share. DEC history is H > > littered with strategies that apparently had nothing to do with whatG > > customers were asking for and everything to do with what DEC though  > > customers wanted.  > F > Actually, most of 'DEC history' (up through at least the early '80s,I > which is well over half of its 40-year span) is a testament to how well H > one can succeed by listening to customers and trying to give them whatH > they need.  And the suggestion that DEC 'started out as an alternativeE > to IBM' simply reflects your own ignorance (or possibly incompetent A > exposition):  DEC began life as a module vendor, not a computer C > manufacturer at all, blossomed by addressing smaller, interactive H > computing markets that IBM largely ignored, and only began encroachingJ > significantly on IBM's territory after VAX appeared (while DEC's earlierD > 36-bit mainframes overlapped IBM's offerings in capabilities, they> > tended to be sold with a significantly different viewpoint). >   A Of course it did, but by the mid 80's when the events that sealed B Alpha's fate started to unfold Digital was the alternative to IBM.  F I have snipped the rest of your response because you clearly don't get> the point and sadly you never will. Regretably this means thatF unsuspecting readers in 10 years time are likely to be subject to moreA Gound Hog Day type ramblings on your part about the Alphacide and ' Palmer, Curly's and Carly's part in it.    Regards  Andrew Harrison    ------------------------------    Date: 21 Jul 2006 06:16:25 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayC Message-ID: <1153487785.694199.112040@m79g2000cwm.googlegroups.com>    Michael Kraemer wrote: > Andrew schrieb:  >  > > H > > 3. Having managed to create an ecosystem for Ultrix/MIPS DEC startedD > > the Alpha development project in 1989 with no real intentions ofH > > porting Ultrix to Alpha or providing any remotely sensible migration > > path from Ultrix to Tru64. > > I > > The Alpha introduction in 1992 with the inevitable Ultrix demise that A > > followed left all DEC's partners in the Ultrix/MIPS ecosystem I > > floundering, customers ran for the hills hotly pursued by sales teams D > > from Sun, IBM, HP, SGI etc waving blank order forms.  (See sales > > peoples commision later) > > K > > Had Alpha been introduced with a sensible Ultrix migration plan or even G > > running Ultrix as Sun had done with SunOS and SPARC and had DEC not F > > apparently wilfully shrunk their ISV software portfolio then it isG > > possible that Alpha/UNIX could have captured the 20-30% of the UNIX $ > > market once commanded by Ultrix. > >  > < > One might be tempted to speculate what would have happenedG > if DEC never started alpha development. If they'd just bought half of H > Mips and continued with Ultrix/MIPS, making it a more viable platform.? > Could have saved them loads of $$$ which could have been used : > for VAX performance boosts. This might have bought a few > more years for VAX/VMS, = > during which Ultrix could have picked up some VMS features, ' > enough to let VMS slip into oblivion. : > Certainly not a nice vision for VMS bigots, but it might > have saved DEC as a company.  F When Alpha was launched one analyst I think it was Michael Slater madeD exactly that point about MIPS. One view at the time was that DigitalD had done Alpha instead of partnering with Motorola, IBM, MIPS or SunF because designing and building their own processor because this fitted< with Digitals view of its position in the technology market.  C One thing is pretty clear doing Alpha had a huge impact on Digitals B financial viability. Working with MIPS would have avoided the huge? outlays required to design Alpha and the even bigger outlays of @ building and running the Hudson and Scottish Fabrication plants.   Regards  Andrew Harrison    ------------------------------    Date: 20 Jul 2006 23:03:28 -0700! From: roland@logikalsolutions.com / Subject: Re: Alpha Server Parts - Charleston SC C Message-ID: <1153461808.817341.285530@s13g2000cwa.googlegroups.com>    Chuck Aaron wrote:2 > What is Daves contact info in Charleston SC that > provides Alpha server parts? > 	 > Thanks,  > Chuck   D If you mean David Turner you can find his contact information at the$ company Web site.  www.islandco.com.   Roland   ------------------------------  # Date: Fri, 21 Jul 2006 15:36:51 GMT " From:   VAXman-  @SendSpamHere.ORG? Subject: Re: equivalent of MAIL>SET FORWARD/USER=ME YOU on unix 0 Message-ID: <00A59042.6C7A296E@SendSpamHere.ORG>  _ In article <1153433450.936925.301620@p79g2000cwp.googlegroups.com>, davidc@montagar.com writes:  >  >  >   >VAXman-@SendSpamHere.ORG wrote:J >> I can forward mail to YOU if account ME exists using the .forward file. >>K >> How can I create and "alias" name such as ME without creating an account  >> and forward it to you?  >> >> -- N >> VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM >>7 >>   "Well my son, life is like a beanstalk, isn't it?"  > ? >On most unix systems, edit the file "/etc/aliases" and add the  >line: >  >me: you > F >Then you may have to run the command "newaliases" in order to rebuild4 >and have the mail server reload the alias database.    C Thanks David, that was it...  Slowly all this is coming back to me.   H FWIW, an internet radio station web site is now being hosted on a serverH in my VAXcave.  It's running on Linux at the moment but my plan, once it8 is all moved in and cozy, is to move and host it on VMS.     --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  % Date: Fri, 21 Jul 2006 06:52:32 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> 2 Subject: Re: New itaniums out at 2.5x perform gain; Message-ID: <44c0b117$0$4147$9a6e19ea@news.newshosting.com>   ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  & news:44C02E7F.418AFACE@teksavvy.com... > Bill Gunshannon wrote:
 [...snip....]  > H > Remember that the 8086 has gone from a 16 bit toy controller with 640kI > memory limit and segment registers into a 32 bit CPU with full features A > and now 64 bit machine. In the process, it has gained many more I > features. So while the 8086 circa 1990 was definitely ill suited to run L > VMS, the CPUs made today for that architecture have gained respectability. >   F Despite what Intel + AMD marketing folks would have us believe, these L product lines you are referring to are not 64-bit. It may seem so, to some, I because CPU and "memory management" functions have been integrated (read  . blurred) but these CPUs are only 32 bits wide.  L To understand this better, think about the PDP-11 system which was a 16 bit J CPU. The memory management system allowed the CPU to address memory using G 18-bit, 22-bit, and 24-bit access. This worked by having the CPU first  G initialize MMU registers which were later combined (added) with 16-bit  K addresses coming from the CPU to generate a wider address going to memory.  K But there was "no way" any single process could "see" more than 16-bits of  J memory at a time without first asking the OS to manipulate the associated  memory management registers.  K p.s. I remember the same thing with VAX. Memory management registers would  F allow the CPU of some larger machines to access 40-bit (and 46-bit ?)  memory.   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html9 http://www3.sympatico.ca/n.rieck/links/openvms_demos.html    ------------------------------   Date: 21 Jul 2006 11:49:05 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)2 Subject: Re: New itaniums out at 2.5x perform gain+ Message-ID: <4ibt9gF33i7gU1@individual.net>   , In article <44C02E7F.418AFACE@teksavvy.com>,0 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > Bill Gunshannon wrote:D >> Maybe so, but after years of hearing how the x86 architecture wasH >> unsuitable for running VMS it seems highly unlikely that the additionE >> of 64 bit extensions has somehow corrected all those shortcomings.  >  > H > Remember that the 8086 has gone from a 16 bit toy controller with 640kI > memory limit and segment registers into a 32 bit CPU with full features A > and now 64 bit machine. In the process, it has gained many more I > features. So while the 8086 circa 1990 was definitely ill suited to run L > VMS, the CPUs made today for that architecture have gained respectability.  C We aren't talking about 1990.  It was as recently as 2004-2005 that C we were once again reminded that the x86 architecture was deficient @ and unsuitable for VMS.  They weren't talking about your beloved? 8086 (which has been dead for decades!) they were talking about C current x86 architecture.  Again, I am not saying it can't be done, B only that if you were waiting for VMS Engineering to "look" at it,@ they have and repeatedly said it didn't meet their requirements.   > C >> Not saying it can't be done, just that the idea that porting VMS D >> to IA64 somehow made it easier to port to x86 is quite a stretch. > I > Posting to IA64 specifically gave VMS the ability to do EFI. That meant F > tweaking the file system to allow a FAT partition-in-a-VMS-file with0 > updates to BACKUP, INIT etc to support this.    I EFI, FAT, etc. are not the CPU.  It was the CPU they said were deficient, G not systems designed around it which could certainly have been changed.    > E > But the port just made, no matter what the target was, game VMS the I > ability to have a common code base supporting multiple architectures at  > the same time,    B Common code base between two architectures.  Alpha and IA64.  WhatE good did that do for the VAX?  If these changes don't help an already C existing architecture what possible effect could they have on an as C yet none existant architecture?  And, if as they have stated in the B past, the x86 architecture is deficient how can a common code base cure the hardware problems?     F >                and this allowed engineers to continue to work on VMSI > while the port was being done. And a lot fo stuff was cleaned up and as H > someone else said, many hardware features were moved to software, thus( > making VMS less dependant on hardware.  G But the CPU has been declared deficient.  All the software in the world  can't fix that.      > " > So the next port will be easier.  G Yeah, the Linux guys thought that too.  Have you seen VAX Linux lately?    >  > H >> True, but JF has always had this pipe dream that a bunch of engineersB >> are kept chained up in the basement of ZKO working 24/7 on some >> mystery x86 port.   > ( > I never said they were chained :-) :-) > 9 >> Many people from HP (in a better position to know than H >> JF) have repeatedly stated there are no plans, at this time, to do an >> x86 port. > C > Yes, and that is perfectly normal. Until the second when HP/Intel G > announce the end of IA64, expect everyone within HP/Intel to deny any J > plans to abandon IA64. Announcing plans to port VMS to the 8086 would be+ > tantamount to announcing the end of IA64.   8 "Two people can keep a secret.  If one of them is dead."   > I > And while I may be hoping for a Covert port of VMS to the 8086 going on G > right now, (the faster, the better), I think it would be realistic to ? > think that someone within VMS engineering has looked into the G > feasability of porting VMS to a 64 bit 8086 based on EFI and reported  > back to very high management    A If they reported to management the same thing they reported here, # well, you should get the picture...   < >                               and kept this very discreet.  8 "Two people can keep a secret.  If one of them is dead."   > H > Note that this had happened prior to the announcement of the prematireE > euthanasia of Alpha. I think it was 2 engineers that were tasked to H > secretely make a feasability study of porting VMS to IA64. The rest of7 > the engineers were totally oblivbious to those plans.  >  > K >> When (and if) such a port is to be attempted it will likely get the same K >> fanfare as all the other ports.  It is not the kind of thing that can be I >> kept hidden away, even if there was some business reason for doing so.  > G > Once it is announced, you are right. But until that time, it is quite B > possible to see VMS engineers talk to Intel engineers about whatI > features they may want in the generation of chips that would come circa 	 > 2007.     F And exactly why would Intel give a rat's patootie?  If it ain't neededG to run Windows, it is not sound business practice.  If VMS is to run on G x86 and survive, it has to run on the same x86 exeryone else is running C on.  If it is going to require modification of the CPU, it is dead.   H >        Also, someone would also be talking about the types of featuresL > that would allow one to build an 8086 based Wildfire/Galaxy class machine.  . Why?  Didn't we just hear that Galaxy is dead?   >  > G >> Again, I have to defer to the HP people who are in a better position E >> to know and they have repeatedly stated here that the resources no / >> longer exist at HP to revive the Alpha line.  > 8 > Horse manure. Where there is a will, there is a way.    E Only up to a point.  These are businesses.  All the will in the world H won't change business realities.  I used to own a 1979 Triumph Spitfire.E There is a company in England that bought the factory where they used C to be made at the bankruptcy auction.  They now manufacture all the G parts themselves.  So, why don't they just manufacture and sell the car G again to meet the demand of enthusiasts?  A breand new Triumph Spitfire F made from their parts would cost over $100,000.  There are people withK the will and this company provides a way.  Still doesn't make it practical.   C >                                                      But there is I > clearly no will at HP to revive Alpha, no will to even postpone the end I > of sales date. And if the will existed, it would take a lot of creative C > accounting to cost justify restarting Alpha with a huge amount of  > resources to catch up.  F So you basicly just supported what I said in the first place, Alpha is
 a dead issue.   E People need to go back and remember what Carly said.  "We have burned G our boats."  What does that mean for VMS?  It means that HP put all its H eggs in the IA64 basket and did it very deliberately.  They did all theyF could to make sure there was no way to turn back.  If that bodes badlyF for people here, there really isn't a lot to be done about it.  Unless> you know a real good boat-builder here in the brave new world.   bill --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Fri, 21 Jul 2006 08:17:34 -0400 ( From: Bill Todd <billtodd@metrocast.net>2 Subject: Re: New itaniums out at 2.5x perform gainG Message-ID: <AaqdnTvfisVCWF3ZnZ2dnUVZ_tudnZ2d@metrocastcablevision.com>    Neil Rieck wrote: = > "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  ( > news:44C02E7F.418AFACE@teksavvy.com... >> Bill Gunshannon wrote:  > [...snip....] I >> Remember that the 8086 has gone from a 16 bit toy controller with 640k J >> memory limit and segment registers into a 32 bit CPU with full featuresB >> and now 64 bit machine. In the process, it has gained many moreJ >> features. So while the 8086 circa 1990 was definitely ill suited to runM >> VMS, the CPUs made today for that architecture have gained respectability.  >> > H > Despite what Intel + AMD marketing folks would have us believe, these N > product lines you are referring to are not 64-bit. It may seem so, to some, K > because CPU and "memory management" functions have been integrated (read  0 > blurred) but these CPUs are only 32 bits wide. > N > To understand this better, think about the PDP-11 system which was a 16 bit L > CPU. The memory management system allowed the CPU to address memory using I > 18-bit, 22-bit, and 24-bit access. This worked by having the CPU first  I > initialize MMU registers which were later combined (added) with 16-bit  M > addresses coming from the CPU to generate a wider address going to memory.  M > But there was "no way" any single process could "see" more than 16-bits of  L > memory at a time without first asking the OS to manipulate the associated  > memory management registers.  @ The above is complete and utter horseshit.  The most charitable C explanation I can come up with is that you're confusing the 32-bit  G 'programmable address extension' (PAE) mechanisms - which have existed  G for a decade or so and which indeed resemble the PDP-11 memory-mapping  G facilities you refer to in that they allow an IA32 process to use more  G than 4 GB of physical RAM but not to see any more than 4 GB at any one  F time - with the new x86-64 extensions which beyond question *do* make H x86-64 every bit as much a 64-bit architecture as the earlier x86s were E 32-bit architectures.  In x86-64 the registers are 64-bits wide, the  E internal data paths are 64-bits wide (the first Intel variant used a  G double-pumped 32-bit ALU to perform 64-bit operations, but this was as  I much an optimization - in that it allowed narrower operations to execute  G at twice the CPU speed - as a band-aid), and programs have access to a  G flat 64-bit virtual address space without requiring any memory-mapping   assistance from software.    - bill   ------------------------------  % Date: Fri, 21 Jul 2006 08:06:01 -0500 % From: Dan Foster <usenet@evilphb.org> 2 Subject: Re: New itaniums out at 2.5x perform gain5 Message-ID: <slrnec1k9p.rt3.usenet@zappy.catbert.org>   d In article <44c0b117$0$4147$9a6e19ea@news.newshosting.com>, Neil Rieck <n.rieck@sympatico.ca> wrote:B >> and now 64 bit machine. In the process, it has gained many moreJ >> features. So while the 8086 circa 1990 was definitely ill suited to runM >> VMS, the CPUs made today for that architecture have gained respectability.  > H > Despite what Intel + AMD marketing folks would have us believe, these N > product lines you are referring to are not 64-bit. It may seem so, to some, K > because CPU and "memory management" functions have been integrated (read  0 > blurred) but these CPUs are only 32 bits wide.  G Er... no, the latest 64-bit processors in that family _are_ true 64 bit H processors. I'll explain in a moment, if you'll bear with me, please. :)  N > To understand this better, think about the PDP-11 system which was a 16 bit L > CPU. The memory management system allowed the CPU to address memory using I > 18-bit, 22-bit, and 24-bit access. This worked by having the CPU first  I > initialize MMU registers which were later combined (added) with 16-bit  M > addresses coming from the CPU to generate a wider address going to memory.  M > But there was "no way" any single process could "see" more than 16-bits of  L > memory at a time without first asking the OS to manipulate the associated  > memory management registers.  D Right: the PDP-11 had a 16-bit data bus and 16 to 22 bit address bus6 depending on what memory access scheme was being used.  A The data bus width is why the PDP-11 is considered to be a 16 bit 
 processor.  C Same deal with the 65816 which was used in the Apple IIGS and Super G Nintendo systems: 16-bit data bus, 24-bit address bus, considered to be  a 16-bit processor.   E However, the EM64T and AMD64 processors *are* full 64 bit internally.   E They are at least 64 bits wide for the _data_ bus (as well as for the E various registers including all of the GPRs), which is the big thing.   E All pointers are 64-bit. All pushes and pops for the stack is 64-bit. G (The operands are 32-bit wide, but then again, do they really need more $ than ~4.2 billion defined operands?)  H Accessing data in the registers and memory is not a matter of internallyF stringing up two adjacent 32-bit registers or 32-bit memory addresses.E (First version of this stuff may have done that, but current versions + don't. It's a full and true 64-bit access.)   H The address bus is not quite 64-bit wide in current implementations, butB likely eventually will either reach 64-bit or come closer to it --G today's implementations are still much wider than terrible 32-bit hacks 6 like PAE to squeeze an extra 4 bits out of addressing.  J On AMD64 64-bit processors, 32-bit is available as a _compatibility mode_.= I'm not sure if it's considered to be a compat mode on EM64T.   < For more detailed information about these two architectures:  " http://en.wikipedia.org/wiki/AMD64" http://en.wikipedia.org/wiki/EM64T  I (The EM64T page is rather sparse, admittedly. AMD64 page is pretty good.)   ? One of the big things distinguishing EM64T and AMD64 from other D traditional 64-bit implementations such as Alpha, UltraSPARC, POWER3H (and later), Itanium, etc. is that EM64T/AMD64 has *much* fewer GPRs due5 to their precedessors originally being a CISC design.    Cheers,    -Dan   ------------------------------  % Date: Fri, 21 Jul 2006 10:32:13 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 2 Subject: Re: New itaniums out at 2.5x perform gain9 Message-ID: <3OWdnWCHTZRhfl3ZnZ2dnUVZ_vednZ2d@libcom.com>    Bill Gunshannon wrote:  @ >>>> Alpha sales at this point in time is a very wrong mistake).) >>> Maybe, but it is a done deal as well. L >> This is a business decision.  If the decision was changed, continuing to G >> manufacture and sell the current Alphas is definitely doable from a   >> technical perspective.  > F > Again, I have to defer to the HP people who are in a better positionD > to know and they have repeatedly stated here that the resources noF > longer exist at HP to revive the Alpha line.  And, we have been toldD > that there was also some agreement regarding Alpha in the HP-IntelF > deal.  It is equally possible that the agreement was that they couldE > no longer continue development of the Alpha.  If that turned out to F > be so, what incentive would Intel have to release HP from it?  No, IC > think as the HP denizens here have stated, Alpha is a dead issue.   G Read again what I wrote.  "Current Alphas".  HP could continue to have  G the EV6, EV7, and EV7z CPUs fabbed and build and sell the systems that  J are CURRENTLY being sold.  Wasn't talking about new Alpha CPU development.  E Ok, such is a short term (relatively) solution, and in several years  D such systems would be overpriced and far from competitive.  But for H several years such would allow customers to run their current VMS based 
 applications.   H Note that there are customers running older hardware.  Why?  Because it H just keeps working.  That's what it's all about.  Getting the job done. I   If you have a VMS based application, that isn't easily portable, being  G able to continue to run that application is a very BIG issue.  Look at  H the CHARON/VAX product.  What it's about is allowing people to continue H to run their applications.  If you believe Stan and others, it's rather J successful.  Why?  Because customers need to continue to get the job done.  H HP's current line is, "You can continue to get the job done on itanic". C   If, note, I write IF, that changes, HP would need to address the  E issue, or just drop VMS.  If they would choose to address the issue,  G continuing to sell Alphas for a while is one possible thing they could  ' do.  Not a solution, a stopgap measure.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------    Date: 21 Jul 2006 09:52:16 -0700 From: perfnerd@yahoo.com2 Subject: Re: New itaniums out at 2.5x perform gainB Message-ID: <1153500736.794685.277750@i3g2000cwc.googlegroups.com>   Bill Todd wrote: > perfnerd@yahoo.com wrote:  > > Bill Todd wrote:   >    The Mad9M is rated atJ > > 130Watts, while the Montecito is rated at 104Watts.   That is 26% less" > > wattage on a per socket basis. > J > That is in fact 20% less wattage on a per-socket basis the way I learned
 > arithmetic.  >   G Oh, grumble, grumble, grumble.  You are right, it is 20% even the way I @ learned arithmetic.  Either I fat fingered the calculator or theD keyboard. In either case I didn't catch it on my abysmal proof of my	 response.     I > Hmmm.  Assuming that the results scale pretty linearly (which they seem F > to these days for SPECint_rate), that's not that much of a boost perG > core over Mad9M considering Montecito's L2 and L3 cache improvements, B > the significantly reduced memory latency that the sx2000 chipsetJ > supposedly provides (the 533 MHz bus speed does imply that the sx2000 isI > being used, does it not?), and whatever compiler improvements occurred.   E It doesn't surprise me, SPEC is just to well understood and tuned for G increases in cache and memory speed to show a significant difference in G performance.  I would expect all the compiler efficiecies were rung out F of SPEC type workloads long ago.  Since both processors are running atF 1.6GHz, the small to negligible per CPU increase in performance  (<5%)C for half the tests implies that they were already running mostly in  registers or existing cache.   ------------------------------  # Date: Fri, 21 Jul 2006 17:22:03 GMT ( From: Alan Greig <greigaln@netscape.net>2 Subject: Re: New itaniums out at 2.5x perform gain8 Message-ID: <%28wg.932$b9.128@fe1.news.blueyonder.co.uk>   Bill Gunshannon wrote:   > E > We aren't talking about 1990.  It was as recently as 2004-2005 that E > we were once again reminded that the x86 architecture was deficient B > and unsuitable for VMS.  They weren't talking about your belovedA > 8086 (which has been dead for decades!) they were talking about E > current x86 architecture.  Again, I am not saying it can't be done, D > only that if you were waiting for VMS Engineering to "look" at it,B > they have and repeatedly said it didn't meet their requirements.  G In his last interview with Terry Shannon, Mark Gorham said that a port  E to X64 was feasable but not in current plans. Terry pointed that out  2 explicitly as a change in previously used wording.   --  
 Alan Greig   ------------------------------  % Date: Fri, 21 Jul 2006 13:26:22 -0400 ( From: Bill Todd <billtodd@metrocast.net>2 Subject: Re: New itaniums out at 2.5x perform gainG Message-ID: <q9ydnZbYmOWik1zZnZ2dnUVZ_q6dnZ2d@metrocastcablevision.com>    perfnerd@yahoo.com wrote:    ...   /   SPEC is just to well understood and tuned for I > increases in cache and memory speed to show a significant difference in  > performance.  F Hmmm.  While I don't have time to check right now, my recollection is E that Madison II submissions differing only in cache size (same clock  ? speed, same hardware, same software, and I think even the same  I submission date) achieved noticeably (though not dramatically) different   SPECint scores.   <    I would expect all the compiler efficiecies were rung out" > of SPEC type workloads long ago.  I Intel's compilers have been gaining relatively on HP-UX's Itanic SPECint  D scores for 4 years now:  while the HP-UX compiler may not have been E making any advances in this area (though one prominent Itanic fanboy  E over at RealWorldTech has harped on this potential for a long time),   others seem to have.   - bill   ------------------------------  % Date: Fri, 21 Jul 2006 11:37:08 +0500 4 From: Valentin Likoum <valentin.likoum@ncc.volga.ru>- Subject: Re[2]: 2 CPU's in timeout on my ES40 3 Message-ID: <595255325.20060721113708@ncc.volga.ru>   : On 21/07/06 Volker Halle <volker_halle@hotmail.com> wrote:     > Valentin,   H > once your ES40 was hung, did you try to press the HALT button ? If theB > system would not react when pressing HALT, this is most likely aI > hardware hang, otherwise it could be software and you can force a crash  entering >>>> CRASH.    A   No reaction to HALT button. Yes, it's hardware problem and most E likely culprit is somewhere around memory (we change memory back from C field-installed BIG memory option to factory-installed SMALL memory B and system is working 3 days now). The things what makes me wonderF are the hang without diagnostic what is unusual for this class of iron7 and the bad luck of ES40s around the world this week :)    --  
 Best regards, #  Valentin                             valentin.likoum@ncc.volga.ru    ------------------------------    Date: 21 Jul 2006 04:27:40 -0700  From: "Barry" <dysert@gmail.com> Subject: Re: XML on Expat B Message-ID: <1153481260.015760.191950@75g2000cwc.googlegroups.com>  G Thanks, Hoff.  No, I don't specifically need Expat -- just that most of A the stuff I've seen raves about it.  I'll try the pointers you've 
 specified.   Hoff Hoffman wrote:  > Barry wrote:G > > (I figured it's better to piggyback on this one than to start a new 
 > > topic) > > J > > I'm aware of the XML parser for VMS from Expat.  I recently downloadedF > > the files and used the supplied descrip.mms file to build the OLB.J > > However, I haven't been able to figure out what else has to be done inH > > order to build an executable that will in fact parse an XML file.  IH > > have 15 years experience with VMS (and MMS) so that's not a problem.J > > If anyone can tell me what's necessary to get a runnable program builtG > > from the Expat sources I'll gladly create an MMS file to do it all.  > G >    If you don't specifically need the expat XML parser, a port of the J > libxml2 environebt is available at the Freeware V8.0 staging area, FWIW. > * > <http://www.hp.com/go/openvms/freeware/> > <http://www.xmlsoft.org/>  > 3 > The Freeware port includes build procedures, etc.  > F > I have finished a libxml2 2.6.24 port not to long ago, with yet moreF > pieces, and that'll be the newest version that ships on the Freeware > V8.0 distro. >  > -- > I > And one question I ask myself when dealing with my own or the makefiles J > of others (and whether based on DECset mms, mmk, or otherwise) centrallyI > involves the speed of a brute-force build on newer hardware as compared D > with the effort involved in maintaining and debugging and using anI > incremental build.  Incremental builds are obviously beneficial and can J > be really speedy, but brute-force builds on the hardware I regularly useH > can be very fast, too, and are obviously rather less involved than theH > makefiles, and the brute-force build can obviously entirely avoid someJ > of the "fun" of the more subtle bugs that I and others have occasionallyH > managed to introduce into our makefiles.  There are always trade-offs, > of course.   ------------------------------    Date: 21 Jul 2006 04:38:52 -0700  From: "Barry" <dysert@gmail.com> Subject: Re: XML on Expat C Message-ID: <1153481932.261289.209190@p79g2000cwp.googlegroups.com>   F Thanks for the pointer to the example, Martin.  What I want to do withE the XML is eventually get parts of it (i.e., only certain data items) E imported into Excel for subsequent processing.  I know that Excel can E import XML directly, but these files I'm dealing with are too big for G Excel (42MB), so I figured a VMS utility might be better able to let me D manipulate the data and create a smaller file that Excel can handle.   Martin Vorlaender wrote: > Barry wrote:J > > I'm aware of the XML parser for VMS from Expat.  I recently downloadedF > > the files and used the supplied descrip.mms file to build the OLB.J > > However, I haven't been able to figure out what else has to be done inE > > order to build an executable that will in fact parse an XML file.  > F > Expat is not a complete XML parser, but a library that offers an APII > to parse XML files. What you do with the API really depends on what you , > want to do with the information extracted. > J > > I have 15 years experience with VMS (and MMS) so that's not a problem.J > > If anyone can tell me what's necessary to get a runnable program builtG > > from the Expat sources I'll gladly create an MMS file to do it all.  > 9 > A simple program showing how to use the expat API is at / > http://www.xml.com/1999/09/expat/src/line.c .  > 6 > So, what do you want to do with the XML information? >  > cu,  >    Martin  > I > P.S.: Sorry for not having answered your email. My private account went " > offline just after receiving it. > --F > One OS to rule them all       | Martin Vorlaender  |  OpenVMS rules!9 > One OS to find them           | work: mv@pdv-systeme.de L > One OS to bring them all      |   http://www.pdv-systeme.de/users/martinv/@ > And in the Darkness bind them.| home: martin@radiogaga.harz.de   ------------------------------  % Date: Fri, 21 Jul 2006 13:52:36 +0200 1 From: =?ISO-8859-1?Q?Jean-Fran=E7ois_Pi=E9ronne?=  Subject: Re: XML on Expat 4 Message-ID: <44c0c00c$0$998$ba4acef3@news.orange.fr>   Barry,H > Thanks for the pointer to the example, Martin.  What I want to do withG > the XML is eventually get parts of it (i.e., only certain data items) G > imported into Excel for subsequent processing.  I know that Excel can G > import XML directly, but these files I'm dealing with are too big for I > Excel (42MB), so I figured a VMS utility might be better able to let me F > manipulate the data and create a smaller file that Excel can handle. >   F Python on OpenVMS has interface to expat and libxml2, latest kits also? include pyExcelerator which allow to read/write Excel document.   H IMHO, it is much easier (faster) to write this using Python than using C code.      JF   ------------------------------    Date: 21 Jul 2006 08:35:16 -0700 From: davidc@montagar.com  Subject: Re: XML on Expat C Message-ID: <1153496116.764190.203690@m79g2000cwm.googlegroups.com>    Barry wrote:I > Thanks, Hoff.  No, I don't specifically need Expat -- just that most of C > the stuff I've seen raves about it.  I'll try the pointers you've  > specified.  G I've used libxml2, and prefer it over Expat.  Maybe I was just using it E wrong, but Expat works better if you can stream through the document. A I found navigating a document tree more convenient using libxml2. E Since this is a "spreadsheet", libxml2 will make it easier for you to A evaluate a cell, and then quickly locate a related cell (due to a  forumla, for example).   ------------------------------  # Date: Fri, 21 Jul 2006 16:58:49 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com> Subject: Re: XML on Expat 0 Message-ID: <dJ7wg.898$rS5.859@news.cpqcorp.net>   Barry wrote: > What I want to do withG > the XML is eventually get parts of it (i.e., only certain data items) G > imported into Excel for subsequent processing.  I know that Excel can G > import XML directly, but these files I'm dealing with are too big for I > Excel (42MB), so I figured a VMS utility might be better able to let me F > manipulate the data and create a smaller file that Excel can handle.  0    Tried the OpenOffice.Org spreadsheet package?   ------------------------------   End of INFO-VAX 2006.403 ************************                                                                                                                                                                                                                                                                                                                                        /k)DI!b`غQ L?zG,0&Zz4bDg$()r䵙f:)/e:Tߛzv'nғكR>A0Fv3+_\Bf7@$iT ,3eץ<~d@8:&-F\kj_	=nI߲CM)`w#cg.ZN_k
~$!D_@w_qJ<rڋ4=c"֬z%CW[s}XZ'$sƑM'4-י|X{[ji12ShcǼ
bOC35zCt{A2-hJh8 HR˘ w Q<'Li)inVIyҹR,]ʩM>lꂊBC%\~Ҧv{~7AƢ#tZ?g3#N0E@o-vEj
-}Oy?u%PZkQ[DԪ%Q77I]ѫ)̑'N5nub{	c_"LWW[QI	 {իVR{۝+r.{W[k1M+gbҚǊ9&INzi[Y~+˅g[iMo.		;Ц(S%	[B/\g} pq
qƾ&Bwٓ|Y$Tx믈E)x=`ᰩ?1TiI:vyRk^M9+g,xU񀛄`h$P^t2	Pw_(;
W}h۲B狅,Fk{,1]WRu/OމeH	m(0\I]k,l.J8 BB aGYVG ]&昙p4&	o:\/wNeJa@Nr]RR+@&+U}^,QϾQd5E":r"5,Ht:"D?m}W^y &7閵P褂[O/KDl\nt+Cd6CX", v䈵T?xg+=| .Wh󈘷E̻Ol+jb./7E!z R7+MF.V%a&G&'-csċ<67dT7hXE5Am7LgXdc+Fh$J=ɺ5=3㛮i=]<QKWPErNya~ԣ(.Ays,-8(y  &iߔU,LlhH8>(*mA(EYRћCCRH0W9&ߞА5qg(E'>JO@~_ uCq0~#z5%EF6N/ٹO+@k X,C[