1 INFO-VAX	Fri, 21 Jul 2006	Volume 2006 : Issue 402       Contents:! Re: 2 CPU's in timeout on my ES40 ! Re: 2 CPU's in timeout on my ES40  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day . Re: C or DCL routine to examine EXE$GQ_CPUTYPE Re: DYNDNS client for OpenVMS?" e: HP to cut down on telecommuting6 Re: equivalent of MAIL>SET FORWARD/USER=ME YOU on unix2 equivalent of MAIL>SET FORWARD/USER=ME YOU on unix6 Re: equivalent of MAIL>SET FORWARD/USER=ME YOU on unix6 Re: equivalent of MAIL>SET FORWARD/USER=ME YOU on unix Re: gnu gmp on OpenVMS/Alpha ? Re: http://h71000.www7.hp.com/? ) 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: 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: Pathworks V6.1 browser in pending state % Re: PIPE redirection as stream file ? $ Re[2]: 2 CPU's in timeout on my ES40( Re: Tomcat user authentication question.A Re: Under VMS, on an HSG80, can Raid Partition Size be Increased? A Re: Under VMS, on an HSG80, can Raid Partition Size be Increased? E Re: VMS and HPVM (was: Parsec webinar (2006-07-12) OpenVMS Licensing)   F ----------------------------------------------------------------------    Date: 20 Jul 2006 13:47:45 -0700" From: dave.baxter@bannerhealth.com* Subject: Re: 2 CPU's in timeout on my ES40B Message-ID: <1153428465.241137.282440@75g2000cwc.googlegroups.com>   Syltrem wrote:D > Has anyone experienced CPU's ceasing to be in service on an ES40 ? > L > 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   D Strangely enough, I had a similar event last week.     I had an ES40G crash and reboot on Saturday Afternoon.    Since it was not critical, I E didn't get to it until Monday, however I found a situation similar to G that described above, (one I had never seen before either!).    One CPU B (#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   A Interestingly, although the crash occurred on Saturday Afternoon, A checking back showed that the CPU had assumed this state sometime B overnight Thursday/Friday, however the system didn't crash at thatF time.     Also the system rebooted and ran through to Tuesday evening,G 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.   G I mention this only so that the poster doesnt feel so bad about it, and F also to show that although this seemed to be clearly a hardware issue,@ 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: 9         CPU 00 -- CPUSPINWAIT, CPU spinwait timer expired >         2 others -- CPUEXIT, Shutdown requested by another CPU  - CPU 02 failed to service the bugcheck request    Dave   ------------------------------    Date: 20 Jul 2006 22:32:19 -0700/ From: "Volker Halle" <volker_halle@hotmail.com> * Subject: Re: 2 CPU's in timeout on my ES40A Message-ID: <1153459939.848158.62810@i3g2000cwc.googlegroups.com>    Dave,   C once a CPU has entered the active set, it should not be able to get A into a TIMEOUT state all by itself, except through a STOP/CPU and ( START/CPU, which would fail to start it.  F If a CPU ceases operation while in the active set, you'll either get aC CPUSANITY or a CPUSPINWAIT bugcheck.From the dump, SDA> CLUE CONFIG   will show the state of the CPUs.  B In your CPUSPINWAIT case, the fact that CPU #2 did not service theG bugcheck request, may be enough evidence to have a look at the state of E that CPU. Note that if AUTO_ACTION is not set to RESTART, you may get F strange CPUSPINWAIT crashes instead of HALT-crashes (like MCHECKPAL or> KRNLSTAKNV). Look at the state of CPU #2 with SDA> CLUE CONFIG (especially the HALT code).     	 Valentin,   F once your ES40 was hung, did you try to press the HALT button ? If the@ system would not react when pressing HALT, this is most likely aG hardware hang, otherwise it could be software and you can force a crash  entering >>> CRASH.    Volker.    ------------------------------    Date: 20 Jul 2006 09:45:05 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayA Message-ID: <1153413904.648766.3460@m73g2000cwd.googlegroups.com>    Bill Todd wrote: > Andrew wrote:  > > Bill Todd wrote:  > >> etmsreec@yahoo.co.uk wrote: > >>> Well, that's one view. > >  > >>    Can M > >>> you say "lack of applications"?  Can you say "lack of operating systems  > >>> to run on it"?M > >> Can you say "incompetent blowhard?"  I think David addressed that latter C > >> chimera adequately, and given that one of said OSs was Windows J > >> (including support of x86 application binaries) I'd say that puts theF > >> former to rest as well (not to say that VMS and Tru64 didn't haveA > >> adequate application support in their own right, of course).  > >> > > A > > I read this post with some amusement for a number of reasons.  > H > Unfortunately, overlooking probably the best one - for which you would, > have had to have been looking in a mirror. >    Really.   C And you follow that by rolling out the same old blame it on Palmer, . Curly and Carly nonsense. How hugely ammusing.  E The sad reality is that Alphas woes and eventual demise may have been D exacerbated or at least allowed to get worse by Palmer/Curly etc but> the seeds for Alphas decline were sown by DEC and their seniorD management in the 80's before any of your favourite culprits were in
 the frame.  C 1. DEC failed to catch the RISC wave first time around, not through C lack of projects but through lack of direction. Not 1 but 4 and bit G projects were started and cancelled by DEC, Titan, SAFE, HR-32, CASCADE E and finally PRISM which metamophosed out of CASCADE. This is one of a F number of examples which illustrate what a massive understatement your2 "(though not always ideally-focused) " comment is.  8 This lost DEC market share to Sun, HP, IBM and SGI/MIPS.  A 2. Having belatedly realised that VAX wasn't going to survive the C onslaught of the RISC processors DEC initiated the short lived MIPS E platform running Ultrix a plaform seriously hampered by the fact that E DEC had not only missed catching the RISC wave but had also failed to F catch the UNIX wave as well. DEC sales people prefered selling VMS/VAXD and senior management openly denigrated UNIX while funding a product' division to develop it. Sounds mad now.   B This lost DEC market share to Sun, HP, IBM and SGI who had no such qualms about selling UNIX.  D 3. Having managed to create an ecosystem for Ultrix/MIPS DEC started@ the Alpha development project in 1989 with no real intentions ofD porting Ultrix to Alpha or providing any remotely sensible migration path from Ultrix to Tru64.  E The Alpha introduction in 1992 with the inevitable Ultrix demise that = followed left all DEC's partners in the Ultrix/MIPS ecosystem E floundering, customers ran for the hills hotly pursued by sales teams @ from Sun, IBM, HP, SGI etc waving blank order forms.  (See sales peoples commision later)  C 4. DEC started out as an alternative to IBM but ended up becoming a A mini IBM without the deep pockets or market share. DEC history is D littered with strategies that apparently had nothing to do with whatC customers were asking for and everything to do with what DEC though  customers wanted.   G Phase V DECNet being a classic example. Perhaps it is indicative of how G bad this strategy was that the ICL were only company apart from DEC who A invested so much time and effort trying to get customers to use a A largely paper OSI standard as opposed to a completely real set of  de-facto standards.   B One major utility in the UK an ICL mainframe/DEC mid tier customerE pinned their platform interoperability standards to the Phase V/OSLAN C mast only to discover that when both vendors finaly shipped working 5 versions (years late) that they did not interoperate.   F Result more customers defect and ISV's who are asked to support DECNETB as opposed to TCP/IP by DEC because of what apears to be religious conviction simply don't bother.   C 5.  TCP/IP vs DECNET. Lunacy on DEC's part resulting in a number of F small companies such as TGV making good money supplying a key platformD component which DEC through mistaken religious conviction refused to support.  D 6. DEC refused to pay salespeople commision cutting DEC off from theE brightest and most creative technology sales people and leading to an G exodus of skilled DEC sales reps to companies like HP, Sun, IBM etc who D were quite happy to reward large sales with large commission checks.E Sun, IBM, HP etc also rewarded ISV sales teams in the same way giving F sales teams an incentive to work vary closely with their ISV partners.  F Every single one of these decisions was made prior to Palmer, Curly orE Carly and every single one had the effect of reducing DEC's relevance F with ISV's and direcly impacting DEC's third party software portfolio.  E The net of this and a whole load of other struggling projects such as E the 9000 series was that by 1992 when Palmer took over  the reins DEC @ were a shambles. They had just posted their first quarterly loss$ followed by their first annual loss.  F ISV's didn't trust them.  Key partners such as Oracle who had used DECG platforms for development and as a primary port had moved mostly to Sun F and the ISV landscape had changed from an environment where most ISV'sD used DEC platforms for development to one where 60+% were using Sun.  2 HP woed SAP and excluded VMS from the R3 platform.  D New entrants to the market such as Baan, Seibel, Retek either simply@ didn't bother with the new improved Digital corporation or had a@ Digital platform as a second or third tier port. Digital throughD indecision, poor market awareness and simple hubris had ceased to be relevant to most ISV's.   G Had Alpha been introduced with a sensible Ultrix migration plan or even C running Ultrix as Sun had done with SunOS and SPARC and had DEC not B apparently wilfully shrunk their ISV software portfolio then it isC possible that Alpha/UNIX could have captured the 20-30% of the UNIX   market once commanded by Ultrix.  F NT on Alpha is and was a red herring, Digital with its track record ofC losing ground in the ISV community was never going to create enough F momentum/interest to get x86/NT ISV's to port to Alpha. FX!32 far fromB being the solution became part of the problem because it ment thatD Digital apparently didn't need to bother. Curly's axing of the Win64> program was inevitable and without a doubt the right decision.  F It is fashionable to blame Palmer, Curly etc for the demise of DEC andE Alpha but the reality is that the hole had already been dug they just  made it slightly deeper.  F Why keep on rolling out the same trite challenged arguments to try andE blame the Alpha demise on more recent managment when it is clear that 2 they simply made an dire situation slightly worse.   Regards  Andrew Harrison  > > K > > 1.     One of the key reasons for the decline in the Alpha business was E > > as the previous poster quite rightly stated the lack of software.  > J > Ah, well - taking a week off from debating with uninformed morons can beG > very relaxing, but they're usually right where you left them when you  > come back. > J > For the edification of the educable (a group which history suggests doesN > not number you as a member), the main reasons for the decline of Alpha were: > D > 1. The Great Palmer Contraction - the transformation of DEC from a@ > forward-looking aggressive (though not always ideally-focused)H > competitor to a multiple-amputee just trying to remain afloat.  No oneF > on the inside mistook this for anything but what it was, so it seems5 > unlikely to have been missed by a lot of customers.  > H > 2.  The infamous mid-'90s 'affinity' program (a Wes Melling ProductionH > IIRC), which encouraged the VMS community to switch to NT on Alpha - aC > great way to turn much of a loyal and robust customer base into a E > combination of skittish stalwarts and disenchanted ex-users, and to J > stall the growth of a leading OS without much compensating return (NT onB > Alpha never having come close to taking up the resulting slack). > I > 3.  The drastic loss of VMS development momentum at the end of the '90s G > (more handwriting on the wall for Alpha's primary OS for those paying I > attention).  When 'supporting new hardware' becomes the main attraction H > of new releases rather than vigorous evolution of OS features in theirH > own right to keep pace with the evolving OS competition, the new trend > line is clear. > I > 4.  The Slough of Despond which Alpha entered immediately after Curly's B > ascension to the throne, when both performance increases and newJ > releases slowed to a crawl and allowed other platforms to challenge whatI > had until then been the unquestioned industry performance leader.  What J > better way to get people wondering about the real level of commitment of> > a corporation to an architecture?  Well, one could have been > J > 5.  The butchering of Win64 (and Windows in general) on Alpha in August,F > 1999 - another Curly brain-fart which managed to call Alpha's futureJ > into such question that the infamous "Commitment to Alpha" letter had to3 > be written in an attempt to quell customer fears.  > F > 6.  The Unix vacillations which first embraced MIPS as the corporateJ > Unix platform and then haltingly switched to Alpha after that damage hadF > been done.  It took Digital Unix sales years to recover, but recoverJ > they eventually did:  while Tru64 had only about 1/3 the market share ofI > AIX, or HP-UX, or Solaris as of Y2K, it was growing far faster than any 8 > of them and threatening to overtake VMS revenues until > F > 7.  The Alphacide, of course - a fine way to kill such a resurgence. > G > The fact that DECpaq's Alpha system business remained one of its most I > profitable hardware franchises despite those first six major handicaps, E > and that its Tru64 business eventually attained robust growth, is a G > testament to Alpha's (and its OSs') continuing perceived strength and D > potential in the eyes of customers and their willingness to try toG > leverage them.  Perhaps a 'lack of applications' was some part (along I > with the other problems noted above) of what kept Tru64 from growing at G > *more* than the 30% annual rate it was achieving shortly prior to the @ > Alphacide, but it sure as hell wasn't contributing to anythingB > resembling a 'decline' in either absolute or market-share terms. >  > - bill   ------------------------------  % Date: Thu, 20 Jul 2006 19:54:22 +0200 ( From: Michael Kraemer <M.Kraemer@gsi.de>" Subject: Re: Alpha remembrance day/ Message-ID: <e9ofvr$onl$02$1@news.t-online.com>    Andrew schrieb:    > F > 3. Having managed to create an ecosystem for Ultrix/MIPS DEC startedB > the Alpha development project in 1989 with no real intentions ofF > porting Ultrix to Alpha or providing any remotely sensible migration > path from Ultrix to Tru64. > G > The Alpha introduction in 1992 with the inevitable Ultrix demise that ? > followed left all DEC's partners in the Ultrix/MIPS ecosystem G > floundering, customers ran for the hills hotly pursued by sales teams B > from Sun, IBM, HP, SGI etc waving blank order forms.  (See sales > peoples commision later) > I > Had Alpha been introduced with a sensible Ultrix migration plan or even E > running Ultrix as Sun had done with SunOS and SPARC and had DEC not D > apparently wilfully shrunk their ISV software portfolio then it isE > 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 happenedF if DEC never started alpha development. If they'd just bought half of F Mips and continued with Ultrix/MIPS, making it a more viable platform.= Could have saved them loads of $$$ which could have been used 8 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. 8 Certainly not a nice vision for VMS bigots, but it might have saved DEC as a company.   ------------------------------    Date: 20 Jul 2006 16:22:33 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) " Subject: Re: Alpha remembrance day3 Message-ID: <zJaVHA1hg4vR@eisner.encompasserve.org>   Z In article <e9ofvr$onl$02$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes: > < > One might be tempted to speculate what would have happenedH > 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. > G    Selecting a different hardware platforms to manufacture would never  F    have saved DEC.  They didn't learn what Billy knew:  the money was     in the software.   B    DEC would have stayed alive only if they had kept VMS customersE    happy by putting VMS on cheaper platforms instead of letting cheap D    UNIX RISC and Windows Intel system steal all their VMS customers.  D    DEC didn't have to manufacture those platforms to make money.  KO    just thought he did.    ------------------------------  % Date: Thu, 20 Jul 2006 20:59:17 -0400 ( From: Bill Todd <billtodd@metrocast.net>" Subject: Re: Alpha remembrance dayG Message-ID: <hdednUyRIr97u13ZnZ2dnUVZ_tSdnZ2d@metrocastcablevision.com>   
 Andrew wrote:  > Bill Todd wrote: >> Andrew wrote: >>> Bill Todd wrote:  >>>> etmsreec@yahoo.co.uk wrote: >>>>> Well, that's one view. >>>>    Can M >>>>> you say "lack of applications"?  Can you say "lack of operating systems  >>>>> to run on it"?M >>>> Can you say "incompetent blowhard?"  I think David addressed that latter C >>>> chimera adequately, and given that one of said OSs was Windows J >>>> (including support of x86 application binaries) I'd say that puts theF >>>> former to rest as well (not to say that VMS and Tru64 didn't haveA >>>> adequate application support in their own right, of course).  >>>>A >>> I read this post with some amusement for a number of reasons. I >> Unfortunately, overlooking probably the best one - for which you would - >> have had to have been looking in a mirror.  >> > 	 > Really.   C Of course, Andrew:  unlike you, I don't bluster interminably about  < things I know little or nothing about - I rely more on fact.   > E > And you follow that by rolling out the same old blame it on Palmer, 0 > Curly and Carly nonsense. How hugely ammusing.  A I sincerely hope that your spelling ability (or lack thereof) as  G evidenced over your years here is not characteristic of the quality of  H England's educational system:  it's discouraging enough that the U.S.'s 
 is so bad.   > G > The sad reality is that Alphas woes and eventual demise may have been F > exacerbated or at least allowed to get worse by Palmer/Curly etc but@ > the seeds for Alphas decline were sown by DEC and their seniorF > management in the 80's before any of your favourite culprits were in > the frame.  G Now, that would be quite a feat, wouldn't it?  Since Alpha didn't even  G *appear on the scene* until Palmer was in charge (1992), and obviously  G didn't reach its peak market penetration until considerably thereafter  C (I suspect not long before the Alphacide), dating the start of its  H *decline* earlier than its birth is - well, pretty typical of the level 2 of intelligence that you usually display, I guess.   > E > 1. DEC failed to catch the RISC wave first time around, not through E > lack of projects but through lack of direction. Not 1 but 4 and bit I > projects were started and cancelled by DEC, Titan, SAFE, HR-32, CASCADE G > and finally PRISM which metamophosed out of CASCADE. This is one of a H > number of examples which illustrate what a massive understatement your4 > "(though not always ideally-focused) " comment is. > : > This lost DEC market share to Sun, HP, IBM and SGI/MIPS.  F But of course (as I already noted above, but since you're both rather H slow on the uptake and obstinate in your ignorance it bears repeating), C this could not possibly have caused Alpha's *decline*, since Alpha  ) wouldn't even appear for a few years yet.    > C > 2. Having belatedly realised that VAX wasn't going to survive the E > onslaught of the RISC processors DEC initiated the short lived MIPS G > platform running Ultrix a plaform seriously hampered by the fact that G > DEC had not only missed catching the RISC wave but had also failed to H > catch the UNIX wave as well. DEC sales people prefered selling VMS/VAXF > and senior management openly denigrated UNIX while funding a product) > division to develop it. Sounds mad now.  > D > This lost DEC market share to Sun, HP, IBM and SGI who had no such > qualms about selling UNIX.  I But (yet again) this couldn't possibly have contributed to the *decline*  B of a product which had not even been introduced yet.  In fact, if H anything it gave Alpha a lower starting point from which regaining lost C market share might have been easier than beginning with more of it.    > F > 3. Having managed to create an ecosystem for Ultrix/MIPS DEC startedB > the Alpha development project in 1989 with no real intentions ofF > porting Ultrix to Alpha or providing any remotely sensible migration > path from Ultrix to Tru64.  I So what?  Once again, this (debatable) intent at Alpha's birth could not  F possibly have caused it to *decline* - it could at worst have limited C its growth (and indeed did for years in the Unix marketplace, as I   already observed).  Idiot.   > G > The Alpha introduction in 1992 with the inevitable Ultrix demise that ? > followed left all DEC's partners in the Ultrix/MIPS ecosystem G > floundering, customers ran for the hills hotly pursued by sales teams B > from Sun, IBM, HP, SGI etc waving blank order forms.  (See sales > peoples commision later)  G Since I already observed that the Unix vacillations you describe above  F contributed to a slow ramp-up for Tru64 on Alpha, I'm really not sure G what your regurgitation was meant to accomplish (though it seems clear  ? that whatever it may have been, it had nothing to do with your  H ridiculous contention that Alpha 'declined' due to lack of applications H rather than simply had an up-hill battle to fight on the Unix front due  to earlier missteps by DEC).   > E > 4. DEC started out as an alternative to IBM but ended up becoming a C > mini IBM without the deep pockets or market share. DEC history is F > littered with strategies that apparently had nothing to do with whatE > customers were asking for and everything to do with what DEC though  > customers wanted.   E Actually, most of 'DEC history' (up through at least the early '80s,  H which is well over half of its 40-year span) is a testament to how well G one can succeed by listening to customers and trying to give them what  G they need.  And the suggestion that DEC 'started out as an alternative  D to IBM' simply reflects your own ignorance (or possibly incompetent @ exposition):  DEC began life as a module vendor, not a computer B manufacturer at all, blossomed by addressing smaller, interactive G computing markets that IBM largely ignored, and only began encroaching  I significantly on IBM's territory after VAX appeared (while DEC's earlier  C 36-bit mainframes overlapped IBM's offerings in capabilities, they  < tended to be sold with a significantly different viewpoint).  I I've snipped a good deal of your subsequent babble, since it's even less  G related to the subject at hand than your earlier drivel was.  But I've  K left your summary paragraph for the opportunity to remind you once again...   H > Every single one of these decisions was made prior to Palmer, Curly orG > Carly and every single one had the effect of reducing DEC's relevance H > with ISV's and direcly impacting DEC's third party software portfolio.  E ... that events such as these which predated Alpha's debut could not  E possibly have precipitated some subsequent *decline* (a 'decline' by  * definition starting from some high point).   > G > The net of this and a whole load of other struggling projects such as G > the 9000 series was that by 1992 when Palmer took over  the reins DEC B > were a shambles. They had just posted their first quarterly loss& > followed by their first annual loss.  A And Alpha was their hope for recovery - as it turned out quite a  I reasonable hope (given the industry's admiration for it) until Palmer et  D al. additionally screwed things up rather than set things straight. I Only Pfeiffer, during his very brief ownership of the product, attempted   to realize its potential.    > H > ISV's didn't trust them.  Key partners such as Oracle who had used DECI > platforms for development and as a primary port had moved mostly to Sun H > and the ISV landscape had changed from an environment where most ISV'sF > used DEC platforms for development to one where 60+% were using Sun.  D Yup - nothing like a bottom-of-the-barrel starting-point to give an B architecture the opportunity to make impressive gains:  Alpha had G nowhere to go but up, and indeed did so (despite being hobbled in many  6 respects) for most of its life prior to the Alphacide.   ...   I > Had Alpha been introduced with a sensible Ultrix migration plan or even E > running Ultrix as Sun had done with SunOS and SPARC and had DEC not D > apparently wilfully shrunk their ISV software portfolio then it isE > possible that Alpha/UNIX could have captured the 20-30% of the UNIX " > market once commanded by Ultrix.  I But as it was, it had to recover the ground solely on its merits against  I significant odds.  So it took a while, but (as I already noted but which  I you seem eager to ignore) eventually Alpha and Tru64 proved sufficiently  H compelling that they were considered the premier Unix platform from the I standpoints of both leading-edge implementation and performance (as well  F as offering very competitive costs of ownership) and were growing far B faster than their larger competition right up until the Alphacide.  H That's not a 'decline', Andrew:  that's *growth*, and impressive (up to C 30% annual) growth at that.  Too bad DEC's $3 billion annual Tru64  B system business in Y2K (plus the existing, though more static, $4 E billion annual VMS system business) doesn't fit the myth that you're   attempting to promulgate.   A And that, of course, pretty much says it all:  in order to blame  G something for a 'decline', one must first establish that a decline was  G in fact taking place.  And while its owners placed plenty of obstacles  C in Alpha's path between the mid-'90s and the Alphacide, they never  B managed to send it into the dive that you're so blithely assuming < occurred:  it took a final act of murder to accomplish that.   - bill   ------------------------------    Date: 20 Jul 2006 09:25:12 -0700 From: "R Boyd" <bob@hax.com>7 Subject: Re: C or DCL routine to examine EXE$GQ_CPUTYPE C Message-ID: <1153412712.393456.211470@s13g2000cwa.googlegroups.com>    Thanks for that link Hoff!D That routine is perfect.   I'll see what I can do to adapt it to the config scripts.    Hoff Hoffman wrote:  > R Boyd wrote: G > > The gnu config.sub and related routines have various strategies for I > > determining what model of cpu they are running on.  I'm trying to fix I > > one for the GMP kit so that it can distinguish which variant of Alpha F > > it's running on.  As of now the routine blows up when it fails theH > > attempt to compile the assembler routine that works for Tru64 and/or > > Linux on Alpha.  > E > The C code available via the following URL works on OpenVMS, and is . > known to be portable to at least Tru64 UNIX: > 7 >   http://h71000.www7.hp.com/wizard/swdev/implver.html    ------------------------------  % Date: Thu, 20 Jul 2006 21:03:18 -0500 6 From: "David J. Dachtera" <djesys.no@spam.comcast.net>' Subject: Re: DYNDNS client for OpenVMS? 0 Message-ID: <44C035E6.2CD9210D@spam.comcast.net>   Julian Wolfe wrote:  >  > HI there,  > G > I'm looking at putting my Alpha on the front end of my network for my H > own general usage and web serving some small sites.  Is there a client& > around for using the DYNDNS service? >   > Any help would be appreciated. > 	 > Thanks!  >  > Julian  A Take a look at: http://www.djesys.com/freeware/vms/dyndns_vms.dcl   E This is a "sanitized" version of the one I run. I originally got from D Aaron Sakovich, possibly from the OpenVMS.org forums. Note that this! requires WGET from Steve Schweda.   ; I run a jacket around it so it runs nightly in a batch job.   E I'm still hoping to someday make some freeware stuff available off my 2 hobbyist Alpha via anonymous FTP. Not there yet...   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------    Date: 20 Jul 2006 11:01:08 -0500% From: frey@encompasserve.org (Sharon) + Subject: e: HP to cut down on telecommuting 3 Message-ID: <OD3EDgMyy5VS@eisner.encompasserve.org>   f In article <qi7jb2prp7d2prqjnjruolhrb2i7e0uam7@4ax.com>, Steve Matzura <number6@speakeasy.net> writes:E > This is a trend I'm finding is taking hold across the VMS board.  I C > was just recently let go from a job where I'd been asking for the H > ability to telecommute since '99. Unfortunately, it was 9/11 that gaveD > me that ability when the building in which my ofice was housed wasG > closed for three months thereafter while they cleaned it up. After it G > reopened in January, 2002, I worked at home at first two days a week, E > then three, then I got a new supervisor who permitted me to work at G > home full time.  It was the best possible situation for both sides--I G > was available for more hours per day, which was good for the company, F > and I got to lose a commute with which I really couldn't deal due toH > physical limitations, which was good for me.  Since my separation fromF > this company earlier this year, I've been looking for VMS work whereF > telecommuting is embraced, but there's a trend going on out there toF > bring everybody back into the ofice that very well may spell the endH > of this 25-year VMS professional's work life. And here I thought I had( > at least another decade or more to go.  H 	IME, even when corporate policy says they're fine with it, they really O aren't.  For example, my company policy is that telecommuting is acceptable as  N long as your supervisor is okay with it.  That makes perfect sense, you don't O want everybody doing it because some people have no space at home, or no quiet  - time, or just need to be directly supervised. = 	The "legacy" portion of our group is all old-timers who are  H unsupervised anyway.  We travel a fair bit, and the company strives for I paperless operations, so we have internet or dialup access to everything  < corporate.  And yet our division boss says "no flippin way".C 	It's frustrating at times because we're in the D.C. area with the  P horrendous traffic and they don't seem to care that they're contributing to it. M A couple years ago my husband got a job at a company about 2 blocks down the  K street from my office, so we've been carpooling.  Early next year, they're  ? moving our office to another nearby town...  Great... thanks...   	  - Sharon " "Gravity...  is a harsh mistress!"   ------------------------------  + Date: Thu, 20 Jul 2006 20:42:12 +0000 (UTC) . From: klewis@LUMINA.MITRE.ORG (Keith A. Lewis)? Subject: Re: equivalent of MAIL>SET FORWARD/USER=ME YOU on unix . Message-ID: <e9opr4$l9c$1@newslocal.mitre.org>  v VAXman-  @SendSpamHere.ORG writes in article <00A58F9D.7E2226AC@SendSpamHere.ORG> dated Thu, 20 Jul 2006 19:56:14 GMT:H >I can forward mail to YOU if account ME exists using the .forward file. > I >How can I create and "alias" name such as ME without creating an account  >and forward it to you?   & It depends what mail-server you run.    J IIRC there is a file called "aliases" which is read by sendmail, if you're
 running that.   C It would probably be better to ask on a Unix newsgroup, without the  reference to VMSmail.   0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------  # Date: Thu, 20 Jul 2006 19:56:14 GMT " From:   VAXman-  @SendSpamHere.ORG; Subject: equivalent of MAIL>SET FORWARD/USER=ME YOU on unix 0 Message-ID: <00A58F9D.7E2226AC@SendSpamHere.ORG>  G I can forward mail to YOU if account ME exists using the .forward file.   H How can I create and "alias" name such as ME without creating an account and forward it to you?   --  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: Thu, 20 Jul 2006 17:48:48 -0400 3 From: "Richard B. Gilbert" <rgilbert88@comcast.net> ? Subject: Re: equivalent of MAIL>SET FORWARD/USER=ME YOU on unix : Message-ID: <yvudndc_AszcZyLZnZ2dnUVZ_u6dnZ2d@comcast.com>   Bob Koehler wrote:  W > In article <00A58F9D.7E2226AC@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:  > I >>I can forward mail to YOU if account ME exists using the .forward file.  >>J >>How can I create and "alias" name such as ME without creating an account >>and forward it to you? >  > E >    Most UNIX have a system-level forward file.  It may be called an  >    alias file. > 2 >    Try man sendmail, man forward, and man alias. >   ? It might work better if he said man -k forward and man -k alias   F Man -k may not work until someone does, as root, "catman -w" to build 
 the index.   ------------------------------    Date: 20 Jul 2006 16:23:42 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ? Subject: Re: equivalent of MAIL>SET FORWARD/USER=ME YOU on unix 3 Message-ID: <mshghqsaWrce@eisner.encompasserve.org>   U In article <00A58F9D.7E2226AC@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes: I > I can forward mail to YOU if account ME exists using the .forward file.  > J > How can I create and "alias" name such as ME without creating an account > and forward it to you?  C    Most UNIX have a system-level forward file.  It may be called an     alias file.  0    Try man sendmail, man forward, and man alias.   ------------------------------    Date: 20 Jul 2006 09:22:30 -0700 From: "R Boyd" <bob@hax.com>' Subject: Re: gnu gmp on OpenVMS/Alpha ? C Message-ID: <1153412550.806460.126040@h48g2000cwc.googlegroups.com>    Thanks for the links Ian.   E I found some interesting bits on the O.O port to VMS site.  The other  seems to be down still   Robert   Ian Miller wrote: E > the forums on the VAMP site is can be helpful but I think its still  > down& > http://www.issinoho.com:8080/phpbb2/ >   > Try the O.O port to VMS people  > http://www.oooovms.dyndns.org/   ------------------------------    Date: 20 Jul 2006 09:05:59 -0700 From: "w_tom" <w_tom1@usa.net>( Subject: Re: http://h71000.www7.hp.com/?A Message-ID: <1153411558.962183.60010@75g2000cwc.googlegroups.com>    Bud-- wrote: > ... H > A 'collar' would not likely increase the wire inductance significantlyJ > and the increased inductance wouldn't block a lightning induced surge. AJ > collar wouldn't provide a path to ground unless there was a conductor to >   grounded collar arc.  D   One who routinely follows me around to represent plug-in protector? manufacturers even denies what is routinely done in some higher D reliability facilities that do not suffer damage.  Routing each wire? through the bulkhead does increase wire impedance and therefore ? enhances protection.  It is one solution discussed in legendary A application notes from Polyphaser where even coax cable is routed , through the bulkhead to increase protection:,  http://www.polyphaser.com/ppc_ptd_home.aspx  D   The bulkhead solution was also installed to eliminate surge damage4 from Orange County emergency response centers in FL:$   http://www.psihq.com/AllCopper.htm  B   A bulkhead (collar) can increase wire impedance.  But where that1 impedance is increased or minimized is important.   B   What did professionals do to eliminate damage?  Did they installA plug-in protectors as Bud claims?  Of course not.  They corrected C earthing AND they installed other solutions so that lightning would A find earth on non-destructive paths; not inside the building.  Of C course, plug-in protectors don't do this well proven technique.  So F plug-in protector manufacturers do not even claim to provide effective? protection in their own numerical specifications.  Instead, Bud @ promotes those ineffective and so much more expensive solutions.  G   The bulkhead is effective because so much transient energy is outside ? the wire.  But this bulkhead (collar), alone, is not sufficient E protection.  It is an enhancement after THE most essential protection G device is installed. Lightning will find paths to earth via electronics C if not provided a many times shorter earthing path.  After THE most C critical component in a protection 'system' is installed, only then = should other enhancements such as the bulkhead be considered.   @   Making a path to earth as low impedance as possible is why theE earthing wire must be 'less than 10 feet'.  Other considerations that @ enhance earthing beyond post 1990 National Electrical Code (NEC)A requirements include no sharp bends, no splices, all wires routed > separated from non-earthing wires (so as to not create inducedF transients), AND routed not through metallic conduits.  Remember, thatG collar, conduit, or bulkhead causes a wire impedance increase.  Whereas G increased wire impedance is desirable after the earth ground, that same A wire impedance is very undesirable in connection TO earth ground.   C   Making earthing connection low impedance is also what that Orange G County solution accomplished.  Earthing is the most essential part of a @ protection 'system'.  Plug-in protectors represented by Bud justC totally forget the whole concept.  They don't provide the dedicated ? earthing wire so necessary to make those MOVs effective. So Bud C completely ignores such earthing to promote the more profitable and  ineffective solution.   G   Meanwhile, where is transient's energy absorbed?  In MOV as Bud would ? have you believe?  Of course not.  Numbers of joules in plug-in F protectors are woefully too small to absorb that energy.  Surge energy> is dissipated in earth.  Again, earthing is the most essentialD component in a protection system which is why responsible protectorsA manufacturers provide a dedicated earthing wire.  We earth direct ; strikes so that protection already inside appliances is not D overwhelmed. Ineffective protectors have no such earthing, and avoidE earthing discussions.  No earth ground means no effective protection. E So those who represent plug-in protector manufacturers hope to ignore D the entire concept - as if those MOVs will somehow absorb what three miles of sky could not stop.  E   Earthing is the most critical component in any protection system as C professionals will routinely note - as Ben Franklin demonstrated in B 1752.  As demonstrated in this figure from but another responsible industry professional:?   http://www.erico.com/public/library/fep/technotes/tncr002.pdf    ------------------------------   Date: 20 Jul 2006 19:13:56 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)2 Subject: Re: New itaniums out at 2.5x perform gain+ Message-ID: <4ia2vkF2rms8U1@individual.net>   , In article <44BFC335.32AEF7E8@teksavvy.com>,0 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > Bill Gunshannon wrote:I >> And exactly why wold they announce that they were moving VMS to x86-64 H >> rather than just announcing that they are concentrating on their real8 >> business, Windows boxes, and pulling the plug on VMS? >  > Pride and money.   > I > Lets look at pride: HP has to admit IA64 was a big mistake, but to make H > up for it, it promises to port all its IA64 based systems to the 8086.  G Too late for that.  Intel already publicly admited it was a mistake and G if they had the chance to go back they wouldn't have done it.  And they 8 have never promised to port VMS to anything beyond IA64.   >  > Lets look at money: G > First, porting VMS to the 8086 should be less expensive than Alpha to J > IA64. They now have setup the abililty to have common code base, cleanedE > up the code to make porting easier, AND have already gotten the EFI J > stuff installed and running on VMS.  So the port to the 8086 should cost > less and take less time.    J Your smokin' again.  There is little that has been made public so far thatH would lead one to believe that because they ported VMS to IA64 it is nowH somehow easier to port it to x86-64.  The two have little if anything in common, architecturally.   > J > Also, while the IA64 port may have been a surprise to all but a very fewH > VMS engineers, the writing has been on the wall for years now that the( > 8086 is (unfortunatly) the way to go,   D And yet HP has never even hinted at th possibility of porting VMS toC x86-64.  As a matter of fact, HP people here have constantly stated  it was not going to happen.   K >                                        and I would be very disapointed if I > nobody within VMS engineering had taken a serious look at what it would  > take.   D My guess is they would look at it as soon as HP paid them to.  BeingE as they have repeatedly stated, right here, that there is no x86 port E in the works, why would any of them take the time to" look at what it  would take"?   > F > I would also not be surprised if the folks at HP-UX, NSK and VMS hadG > talks with Intel on what features they might need in the 8086 to make P > porting much easier. Such features are likely to appear in the 2007 timeframe.  D Why would Intel care?  Their only interest right now is figuring out? how to catch back up to AMD.  If VMS, HP-UX and NSK go belly up A tomorrow, it doesn't affect Intel's bottom line.  Of course, that  IA64 boat anchor does!!    > D >> I fail to see the logic int his.  IA64 is costing them buckets ofE >> money.  Cance3ling it would end stop the bleeding and let them cut F >> even more jobs making them look even better to the Casino Analysts. > H > It all ddpends on what sort of contracts were signed. Remember that HPJ > sent 3 billion bucks to Intel not too long ago (along with its remainingI > chip engineers), and is also building that 10 billion fund allegedly to I > help port software to that IA64 contraption.  This may be structured in ? > such a way that you cannot cancel IA64 until a certain date.    F Still smokin'.  No one knows what this mythical agreement said or evenE if there really is one.  Of course, it could just as easily have been C an agreement to pay Intel the 10 billion dollars as reparations for < the damage keeping that IA64 thing alive this long has done.  : My theory is just as believable (and verifiable) as yours.   > F > Also, in 2004 when Carly would have set this in motion, it is likelyF > that she would have wanted to keep the door open should, by miracle,C > IA64 become popular. "Give it a couple of years and then can it".   = Sure glad they don't let that weed you smoke over the border.    > G > Should Intel kill IA64 prematurely, it might cost Intel mega bucks to J > compensate HP, much more than paying a few engineers to thinker with the= > contraption and produce a faster one every couple of years.   H Not knowing what was in any of the agreements between them, it is reallyB impossible to say who would end out owing who if IA64 gets killed.   >  > J >> You keep assuming that they have any plan or even desire to migrate VMSI >> any further.  If that were likely, considering how long it can take to M >> go from desire to a viable commercial product, the work would have already  >> begun.    > E > Yes, it had begun and was happening in the basement of ZKO, until I B > uncovered it and they quickly replaced the office furniture withF > sporting equipment, removing any traces that there was ever a covert% > porting effort going on :-) :-) ;-)    Keep smokin'......   > J > The VMS engineers have all the tools already to manage a porting effort.  D Now there's another big assumption on your part.  Being as they haveB repeatedly said there is no port to x86-64, why would HP have paid for all these tools?  F > If, in 2007, Intel/HP announce the end of the line for IA64, it willD > probably includd one more iteration of that "thing" and last a few > years,  D Nobody is buying it now, who would buy it if they announced it was aF deadend?  Any further "iteration" would just be money down the toilet.  + >         during which VMS can be ported.     J And during all this time you think the IT and business world is just goingI to stand still?  You thhink MS won't be out there raiding what is left of @ HP's customers?  Or Sun?  Or IBM? Or any of dozen Linux brokers?  G >                                         (this is where the killing of = > Alpha sales at this point in time is a very wrong mistake).   % Maybe, but it is a done deal as well.    >  > G > Face it, toy controller or high end chip, the 8086 is solid as a rock G > with no rumours of it going away anytime soon.  Move VMS to the 8086, J > and you all once and for all any rumours of VMS's demise because as longJ > as it is profitable, there is no reason to kill it. And customers havingF > more confidence in a VMS rejuvenation will stay or buy in to VMS and > you'll see real growth.    Keep on smokin'......    >  > E > Right now, the sad reality is that a weakened VMS is using its last J > energies to try to support IA64. Move to  8086 and it is the strong 8086F > (in the marketplace) that will help and support VMS and let it grow. > < > IA64 is a liability to VMS. 8086 would be an asset to VMS.  G Probably way too little, way too late.  But in any event, it isn't even F a blip on the radar and businesses are not going to wait around to seeF what comes next.  If we are truly seeing the last hurrah for IA64 then4 we should be very concerned about the future of VMS.   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: Thu, 20 Jul 2006 06:28:48 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> 2 Subject: Re: New itaniums out at 2.5x perform gain< Message-ID: <44bf5a0e$0$18489$9a6e19ea@news.newshosting.com>  6 "Bill Gunshannon" <bill@cs.uofs.edu> wrote in message % news:4i830qF2k5j6U1@individual.net... H > In article <koGdncJoyNPrViPZnZ2dnUVZ_qudnZ2d@metrocastcablevision.com> [...snip...] > I > In the corporate world isn't swallowing your ego and admitting that you K > made a mistake the first and in most cases the hardest step to correcting  > that mistake?  >   I Yes but on this side of Y2K, corporate execs have "rock star" egos. They  ; almost never admit they make mistakes (even when in court).   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/    ------------------------------  % Date: Thu, 20 Jul 2006 06:56:31 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> 2 Subject: Re: New itaniums out at 2.5x perform gain< Message-ID: <44bf608d$0$18520$9a6e19ea@news.newshosting.com>  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  & news:44BEE63D.311660E0@teksavvy.com... > Doug Phillips wrote: >  [...snip...] >  > H > What I found more telling is the admission that that IA64 thing is not > profitable for Intel.  > H > Me thinks that the second the contract runs out with HP, Intel will be; > more than happy to put that IA64 thing out of its misery.  > I > So far, I have seen nothing to indicate that such an announcement won't 2 > come in 2007. The path was set in February 2004. >   I Sometimes investors and upper management have different agendas than the  M rest of a company (or deals they've made with other companies). Look at what  ! is happening with General Motors: R http://www.mercurynews.com/mld/mercurynews/business/financial_markets/15066113.htmJ Billionaire investor Kirk Kerkorian buys more than 10% of the shares then J "suggests" that GM do a deal with Nissan and Renault. In this context the E billionaire investor doesn't care about jobs, corporate prestige, GM  7 engineering, etc. He just wants to increase his wealth.   G Although no big investor has raided Intel, upper management is already  I making noise about AMD's market share doubling from 10% to 20% (although  K Intel's market share has only dropped from 90% to 80%). Intel has just cut  J 1000 jobs and is considering cutting another 5000. They've sold off their J communications business and I keep wondering what else will end up on the  chopping block.   
 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: 20 Jul 2006 04:26:46 -0700 From: etmsreec@yahoo.co.uk2 Subject: Re: New itaniums out at 2.5x perform gainB Message-ID: <1153394806.593540.97060@m73g2000cwd.googlegroups.com>   I like the quote:   C 'For that reason, Itanium is more strategic to HP than Intel today, F says Gordon Haff, an analyst at research firm Illuminata. "Their Unix,G OpenVMS, and NonStop business goes 'poof' if Itanium goes 'poof'," says = Haff. "HP can not afford to put its customers through another  instruction-set transition." '  G That makes the most sense of any of this discussion.  Everything within F HP's high end relies on Itanium.  HP can't let that happen, whether itE means signing blank cheques to Intel or buying them and dropping them - in the bottom of the bay to increase volumes.   C Porting the enterprise operating environments to a 32-bit chip with D 64-bit extensions ain't gonna happen any time soon in my view.  ThatA would spell the end of HP as anything but a PC and printer maker.    Steve      Neil Rieck wrote: < > "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message( > news:44BEE63D.311660E0@teksavvy.com... > > Doug Phillips wrote: > >  > [...snip...] > >  > > J > > What I found more telling is the admission that that IA64 thing is not > > profitable for Intel.  > > J > > Me thinks that the second the contract runs out with HP, Intel will be= > > more than happy to put that IA64 thing out of its misery.  > > K > > So far, I have seen nothing to indicate that such an announcement won't 4 > > come in 2007. The path was set in February 2004. > >  > J > Sometimes investors and upper management have different agendas than theN > rest of a company (or deals they've made with other companies). Look at what# > is happening with General Motors: T > http://www.mercurynews.com/mld/mercurynews/business/financial_markets/15066113.htmK > Billionaire investor Kirk Kerkorian buys more than 10% of the shares then K > "suggests" that GM do a deal with Nissan and Renault. In this context the F > billionaire investor doesn't care about jobs, corporate prestige, GM9 > engineering, etc. He just wants to increase his wealth.  > H > Although no big investor has raided Intel, upper management is alreadyJ > making noise about AMD's market share doubling from 10% to 20% (althoughL > Intel's market share has only dropped from 90% to 80%). Intel has just cutK > 1000 jobs and is considering cutting another 5000. They've sold off their K > communications business and I keep wondering what else will end up on the  > chopping block.  >  > Neil Rieck > Kitchener/Waterloo/Cambridge,  > Ontario, Canada.: > http://www3.sympatico.ca/n.rieck/links/cool_openvms.html; > http://www3.sympatico.ca/n.rieck/links/openvms_demos.html    ------------------------------    Date: 20 Jul 2006 11:52:06 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 2 Subject: Re: New itaniums out at 2.5x perform gain3 Message-ID: <p4PGeWuL5orZ@eisner.encompasserve.org>   f In article <44beb1c0$0$989$9a6e19ea@news.newshosting.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:   > <quote-on>I > "We're working pretty hard to get it to a profitable product," said Pat K > Gelsinger, senior VP of Intel's digital enterprise group, in an interview L > following a press conference in San Francisco Tuesday. "If we could unwindH > the clock, I would have just built a RAS version of Xeon to attack theK > market," he said, using an industry term for "reliable, highly available, H > and scalable" chips, and referring to Intel's Xeon server chips, whichI > employ the widely used x86 instruction set. Itanium uses a less popular  > design called EPIC. 
 > <quote-off>  > M > When a company makes this kind of statement in public, they are testing the F > waters. Now let's see what the investment community says about this.  F    Hopefully it will be "let's port everything to x86".  In which caseE    the decision to not bother with Galaxy on IA-64 would be fine with D    me.  HP can stop all development on IA-64 if they port EVERYTHING    Alpha could run to x86.   ------------------------------    Date: 20 Jul 2006 11:54:47 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 2 Subject: Re: New itaniums out at 2.5x perform gain3 Message-ID: <+VsvlB6+v25f@eisner.encompasserve.org>   h In article <44bf5a0e$0$18489$9a6e19ea@news.newshosting.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes: > K > Yes but on this side of Y2K, corporate execs have "rock star" egos. They  = > almost never admit they make mistakes (even when in court).   >    This side of Y2K corporate managers should wake up to AOL'sE    problem with the 2038 "bug".  I just read in the Risks Digest that     it hit them already.    ------------------------------  % Date: Thu, 20 Jul 2006 13:35:23 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: Re: New itaniums out at 2.5x perform gain, Message-ID: <44BFBEDA.EEE63B3A@teksavvy.com>   etmsreec@yahoo.co.uk wrote: ? > Haff. "HP can not afford to put its customers through another   > instruction-set transition." ' > I > That makes the most sense of any of this discussion.  Everything within H > HP's high end relies on Itanium.  HP can't let that happen, whether itG > means signing blank cheques to Intel or buying them and dropping them / > in the bottom of the bay to increase volumes.       F There is one big caveat to that Haff statement: most HP customers haveE not transitioned to that IA64 thing. So announce that HP is moving to G 8086 today, and customers will then migrate from MIPS, Alpha and PaRisc 1 to the 8086, totally bypassing that IA64 mistake.   # Customers do not like uncertainty.    G As he said, HP's enterirpise products currently rely on a product whose B future is uncertain and performance curve starting to lag the 8086; simply because the 8086 is being upgraded at a faster rate.     D Personally, I think that the HPUX HPVM thing is a base for somethingF greater. They will get that machine to run on the 8086 and give it theE dynamic codd translation abilities like Apple's Rosetta to run PaRisc H code in big endian. This way, customers will be able to run 80-86 nativeE apps direct on the base HPUX instance, and run older code on emulated # HPUX running on that base instance.    ------------------------------  % Date: Thu, 20 Jul 2006 13:53:59 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: Re: New itaniums out at 2.5x perform gain, Message-ID: <44BFC335.32AEF7E8@teksavvy.com>   Bill Gunshannon wrote:H > And exactly why wold they announce that they were moving VMS to x86-64G > rather than just announcing that they are concentrating on their real 7 > business, Windows boxes, and pulling the plug on VMS?    Pride and money.    G Lets look at pride: HP has to admit IA64 was a big mistake, but to make F up for it, it promises to port all its IA64 based systems to the 8086.   Lets look at money: E First, porting VMS to the 8086 should be less expensive than Alpha to H IA64. They now have setup the abililty to have common code base, cleanedC up the code to make porting easier, AND have already gotten the EFI H stuff installed and running on VMS.  So the port to the 8086 should cost less and take less time.    H Also, while the IA64 port may have been a surprise to all but a very fewF VMS engineers, the writing has been on the wall for years now that theH 8086 is (unfortunatly) the way to go, and I would be very disapointed ifG nobody within VMS engineering had taken a serious look at what it would  take.   D I would also not be surprised if the folks at HP-UX, NSK and VMS hadE talks with Intel on what features they might need in the 8086 to make N porting much easier. Such features are likely to appear in the 2007 timeframe.  C > I fail to see the logic int his.  IA64 is costing them buckets of D > money.  Cance3ling it would end stop the bleeding and let them cutE > even more jobs making them look even better to the Casino Analysts.   F It all ddpends on what sort of contracts were signed. Remember that HPH sent 3 billion bucks to Intel not too long ago (along with its remainingG chip engineers), and is also building that 10 billion fund allegedly to G help port software to that IA64 contraption.  This may be structured in = such a way that you cannot cancel IA64 until a certain date.    D Also, in 2004 when Carly would have set this in motion, it is likelyD that she would have wanted to keep the door open should, by miracle,A IA64 become popular. "Give it a couple of years and then can it".   E Should Intel kill IA64 prematurely, it might cost Intel mega bucks to H compensate HP, much more than paying a few engineers to thinker with the; contraption and produce a faster one every couple of years.     I > You keep assuming that they have any plan or even desire to migrate VMS H > any further.  If that were likely, considering how long it can take toL > go from desire to a viable commercial product, the work would have already
 > begun.    C Yes, it had begun and was happening in the basement of ZKO, until I @ uncovered it and they quickly replaced the office furniture withD sporting equipment, removing any traces that there was ever a covert# porting effort going on :-) :-) ;-)   H The VMS engineers have all the tools already to manage a porting effort.D If, in 2007, Intel/HP announce the end of the line for IA64, it willB probably includd one more iteration of that "thing" and last a fewE years, during which VMS can be ported.  (this is where the killing of ; Alpha sales at this point in time is a very wrong mistake).     E Face it, toy controller or high end chip, the 8086 is solid as a rock E with no rumours of it going away anytime soon.  Move VMS to the 8086, H and you all once and for all any rumours of VMS's demise because as longH as it is profitable, there is no reason to kill it. And customers havingD more confidence in a VMS rejuvenation will stay or buy in to VMS and you'll see real growth.     C Right now, the sad reality is that a weakened VMS is using its last H energies to try to support IA64. Move to  8086 and it is the strong 8086D (in the marketplace) that will help and support VMS and let it grow.  : IA64 is a liability to VMS. 8086 would be an asset to VMS.   ------------------------------    Date: 20 Jul 2006 16:14:15 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 2 Subject: Re: New itaniums out at 2.5x perform gain3 Message-ID: <4aUla1x9DxRo@eisner.encompasserve.org>   \ In article <44BFBEDA.EEE63B3A@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > F > Personally, I think that the HPUX HPVM thing is a base for somethingH > greater. They will get that machine to run on the 8086 and give it theG > dynamic codd translation abilities like Apple's Rosetta to run PaRisc J > code in big endian. This way, customers will be able to run 80-86 nativeG > apps direct on the base HPUX instance, and run older code on emulated % > HPUX running on that base instance.   D    Yeah, they're going to have a problem porting HP-UX to x86 unless"    someone builds a bi-endian x86.  H    Which is fine.  They just port Tru64 UNIX to x86, ship the previouslyG    optional SVID package as standard and make it the default interface.   B    Then everyboy's happy except the customers who wrote big-endianD    dependant code.  They either jump to Sun or port to little endian    machines from somebody.  G    And VMS still doesn't crash, or get hacked, or go non-deterministic.    ------------------------------  % Date: Thu, 20 Jul 2006 19:21:24 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 2 Subject: Re: New itaniums out at 2.5x perform gain9 Message-ID: <yvWdnR1hv-4ek13ZnZ2dnUVZ_rednZ2d@libcom.com>    Bill Gunshannon wrote:. > In article <44BFC335.32AEF7E8@teksavvy.com>,2 > 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: >> Bill Gunshannon wrote: J >>> And exactly why wold they announce that they were moving VMS to x86-64I >>> rather than just announcing that they are concentrating on their real 9 >>> business, Windows boxes, and pulling the plug on VMS?  >> Pride and money.  >>J >> Lets look at pride: HP has to admit IA64 was a big mistake, but to makeI >> up for it, it promises to port all its IA64 based systems to the 8086.  > I > Too late for that.  Intel already publicly admited it was a mistake and I > if they had the chance to go back they wouldn't have done it.  And they : > have never promised to port VMS to anything beyond IA64.  E That one statement from Intel is the worst thing I've seen since the  H killing of Alpha.  As the desire in Intel grows to dump the itanic, the 1 arguments to do so will grow, and it will happen.    >> Lets look at money:H >> First, porting VMS to the 8086 should be less expensive than Alpha toK >> IA64. They now have setup the abililty to have common code base, cleaned F >> up the code to make porting easier, AND have already gotten the EFIK >> stuff installed and running on VMS.  So the port to the 8086 should cost  >> less and take less time.    > L > Your smokin' again.  There is little that has been made public so far thatJ > would lead one to believe that because they ported VMS to IA64 it is nowJ > somehow easier to port it to x86-64.  The two have little if anything in > common, architecturally.  C There have been more than a few things mentioned.  Moving hardware  7 capabilities into code within VMS and things like that.   K >> Also, while the IA64 port may have been a surprise to all but a very few I >> VMS engineers, the writing has been on the wall for years now that the ) >> 8086 is (unfortunatly) the way to go,   > F > And yet HP has never even hinted at th possibility of porting VMS toE > x86-64.  As a matter of fact, HP people here have constantly stated  > it was not going to happen.   G Small correction, they have stated that it was not currently happening  I or in planning.  They don't have the authority to state that it will not   happen.   L >>                                        and I would be very disapointed ifJ >> nobody within VMS engineering had taken a serious look at what it would	 >> take.   > F > My guess is they would look at it as soon as HP paid them to.  BeingG > as they have repeatedly stated, right here, that there is no x86 port G > in the works, why would any of them take the time to" look at what it  > would take"?  4 Such a port is far from a 'midnight projects' thing.  G >> I would also not be surprised if the folks at HP-UX, NSK and VMS had H >> talks with Intel on what features they might need in the 8086 to makeQ >> porting much easier. Such features are likely to appear in the 2007 timeframe.  > F > Why would Intel care?  Their only interest right now is figuring outA > how to catch back up to AMD.  If VMS, HP-UX and NSK go belly up C > tomorrow, it doesn't affect Intel's bottom line.  Of course, that  > IA64 boat anchor does!!   @ Gee, sounds like many of my posts from the 2001-2004 time frame.  E >>> I fail to see the logic int his.  IA64 is costing them buckets of F >>> money.  Cance3ling it would end stop the bleeding and let them cutG >>> even more jobs making them look even better to the Casino Analysts. I >> It all ddpends on what sort of contracts were signed. Remember that HP K >> sent 3 billion bucks to Intel not too long ago (along with its remaining J >> chip engineers), and is also building that 10 billion fund allegedly toJ >> help port software to that IA64 contraption.  This may be structured in@ >> such a way that you cannot cancel IA64 until a certain date.  > H > Still smokin'.  No one knows what this mythical agreement said or evenG > if there really is one.  Of course, it could just as easily have been E > an agreement to pay Intel the 10 billion dollars as reparations for > > the damage keeping that IA64 thing alive this long has done.   That's correct.   < > My theory is just as believable (and verifiable) as yours. > G >> Also, in 2004 when Carly would have set this in motion, it is likely G >> that she would have wanted to keep the door open should, by miracle, D >> IA64 become popular. "Give it a couple of years and then can it". > ? > Sure glad they don't let that weed you smoke over the border.    None left after JF gets to it.  H >> Should Intel kill IA64 prematurely, it might cost Intel mega bucks toK >> compensate HP, much more than paying a few engineers to thinker with the > >> contraption and produce a faster one every couple of years. > J > Not knowing what was in any of the agreements between them, it is reallyD > impossible to say who would end out owing who if IA64 gets killed. >  >>K >>> You keep assuming that they have any plan or even desire to migrate VMS J >>> any further.  If that were likely, considering how long it can take toN >>> go from desire to a viable commercial product, the work would have already >>> begun.  F >> Yes, it had begun and was happening in the basement of ZKO, until IC >> uncovered it and they quickly replaced the office furniture with G >> sporting equipment, removing any traces that there was ever a covert & >> porting effort going on :-) :-) ;-) >  > Keep smokin'......   You can count on it.  :-)   K >> The VMS engineers have all the tools already to manage a porting effort.  > F > Now there's another big assumption on your part.  Being as they haveD > repeatedly said there is no port to x86-64, why would HP have paid > for all these tools? > G >> If, in 2007, Intel/HP announce the end of the line for IA64, it will E >> probably includd one more iteration of that "thing" and last a few 	 >> years,  > F > Nobody is buying it now, who would buy it if they announced it was aH > deadend?  Any further "iteration" would just be money down the toilet. > , >>         during which VMS can be ported.   > L > And during all this time you think the IT and business world is just goingK > to stand still?  You thhink MS won't be out there raiding what is left of B > HP's customers?  Or Sun?  Or IBM? Or any of dozen Linux brokers? > H >>                                         (this is where the killing of> >> Alpha sales at this point in time is a very wrong mistake). > ' > Maybe, but it is a done deal as well.   I This is a business decision.  If the decision was changed, continuing to  D manufacture and sell the current Alphas is definitely doable from a  technical perspective.  H >> Face it, toy controller or high end chip, the 8086 is solid as a rockH >> with no rumours of it going away anytime soon.  Move VMS to the 8086,K >> and you all once and for all any rumours of VMS's demise because as long K >> as it is profitable, there is no reason to kill it. And customers having G >> more confidence in a VMS rejuvenation will stay or buy in to VMS and  >> you'll see real growth. >  > Keep on smokin'......  >  >>F >> Right now, the sad reality is that a weakened VMS is using its lastK >> energies to try to support IA64. Move to  8086 and it is the strong 8086 G >> (in the marketplace) that will help and support VMS and let it grow.  >>= >> IA64 is a liability to VMS. 8086 would be an asset to VMS.  > I > Probably way too little, way too late.  But in any event, it isn't even H > a blip on the radar and businesses are not going to wait around to seeH > what comes next.  If we are truly seeing the last hurrah for IA64 then6 > we should be very concerned about the future of VMS.   Very!    --  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 00:26:33 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)2 Subject: Re: New itaniums out at 2.5x perform gain+ Message-ID: <4ial9oF2tbisU1@individual.net>   9 In article <yvWdnR1hv-4ek13ZnZ2dnUVZ_rednZ2d@libcom.com>, * 	Dave Froble <davef@tsoft-inc.com> writes: > Bill Gunshannon wrote:/ >> In article <44BFC335.32AEF7E8@teksavvy.com>, 3 >> 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes:  >>> Bill Gunshannon wrote:K >>>> And exactly why wold they announce that they were moving VMS to x86-64 J >>>> rather than just announcing that they are concentrating on their real: >>>> business, Windows boxes, and pulling the plug on VMS? >>> Pride and money.   >>> K >>> Lets look at pride: HP has to admit IA64 was a big mistake, but to make J >>> up for it, it promises to port all its IA64 based systems to the 8086. >>  J >> Too late for that.  Intel already publicly admited it was a mistake andJ >> if they had the chance to go back they wouldn't have done it.  And they; >> have never promised to port VMS to anything beyond IA64.  > G > That one statement from Intel is the worst thing I've seen since the  J > killing of Alpha.  As the desire in Intel grows to dump the itanic, the 3 > arguments to do so will grow, and it will happen.  >  >>> Lets look at money: I >>> First, porting VMS to the 8086 should be less expensive than Alpha to L >>> IA64. They now have setup the abililty to have common code base, cleanedG >>> up the code to make porting easier, AND have already gotten the EFI L >>> stuff installed and running on VMS.  So the port to the 8086 should cost >>> less and take less time.   >>  M >> Your smokin' again.  There is little that has been made public so far that K >> would lead one to believe that because they ported VMS to IA64 it is now K >> somehow easier to port it to x86-64.  The two have little if anything in  >> common, architecturally.  > E > There have been more than a few things mentioned.  Moving hardware  9 > capabilities into code within VMS and things like that.   A Maybe so, but after years of hearing how the x86 architecture was E unsuitable for running VMS it seems highly unlikely that the addition B of 64 bit extensions has somehow corrected all those shortcomings.@ Not saying it can't be done, just that the idea that porting VMSA to IA64 somehow made it easier to port to x86 is quite a stretch.    > L >>> Also, while the IA64 port may have been a surprise to all but a very fewJ >>> VMS engineers, the writing has been on the wall for years now that the* >>> 8086 is (unfortunatly) the way to go,  >>  G >> And yet HP has never even hinted at th possibility of porting VMS to F >> x86-64.  As a matter of fact, HP people here have constantly stated >> it was not going to happen. > I > Small correction, they have stated that it was not currently happening  K > or in planning.  They don't have the authority to state that it will not  	 > happen.   E True, but JF has always had this pipe dream that a bunch of engineers ? are kept chained up in the basement of ZKO working 24/7 on some I mystery x86 port.  Many people from HP (in a better position to know than E JF) have repeatedly stated there are no plans, at this time, to do an 	 x86 port.    > M >>>                                        and I would be very disapointed if K >>> nobody within VMS engineering had taken a serious look at what it would 
 >>> take.  >>  G >> My guess is they would look at it as soon as HP paid them to.  Being H >> as they have repeatedly stated, right here, that there is no x86 portH >> in the works, why would any of them take the time to" look at what it >> would take"?  > 6 > Such a port is far from a 'midnight projects' thing.  H When (and if) such a port is to be attempted it will likely get the sameH fanfare as all the other ports.  It is not the kind of thing that can beF kept hidden away, even if there was some business reason for doing so.   > H >>> I would also not be surprised if the folks at HP-UX, NSK and VMS hadI >>> talks with Intel on what features they might need in the 8086 to make R >>> porting much easier. Such features are likely to appear in the 2007 timeframe. >>  G >> Why would Intel care?  Their only interest right now is figuring out B >> how to catch back up to AMD.  If VMS, HP-UX and NSK go belly upD >> tomorrow, it doesn't affect Intel's bottom line.  Of course, that >> IA64 boat anchor does!! > B > Gee, sounds like many of my posts from the 2001-2004 time frame.  H You and many other people here who were not required to toe the HP-line.   > F >>>> I fail to see the logic int his.  IA64 is costing them buckets ofG >>>> money.  Cance3ling it would end stop the bleeding and let them cut H >>>> even more jobs making them look even better to the Casino Analysts.J >>> It all ddpends on what sort of contracts were signed. Remember that HPL >>> sent 3 billion bucks to Intel not too long ago (along with its remainingK >>> chip engineers), and is also building that 10 billion fund allegedly to K >>> help port software to that IA64 contraption.  This may be structured in A >>> such a way that you cannot cancel IA64 until a certain date.   >>  I >> Still smokin'.  No one knows what this mythical agreement said or even H >> if there really is one.  Of course, it could just as easily have beenF >> an agreement to pay Intel the 10 billion dollars as reparations for? >> the damage keeping that IA64 thing alive this long has done.  >  > That's correct.  > = >> My theory is just as believable (and verifiable) as yours.  >>  H >>> Also, in 2004 when Carly would have set this in motion, it is likelyH >>> that she would have wanted to keep the door open should, by miracle,E >>> IA64 become popular. "Give it a couple of years and then can it".  >>  @ >> Sure glad they don't let that weed you smoke over the border. >   > None left after JF gets to it.  D Good thing too.  We already have enough spaced-out people down here.- Some of them running major corporations.  :-)    > I >>> Should Intel kill IA64 prematurely, it might cost Intel mega bucks to L >>> compensate HP, much more than paying a few engineers to thinker with the? >>> contraption and produce a faster one every couple of years.  >>  K >> Not knowing what was in any of the agreements between them, it is really E >> impossible to say who would end out owing who if IA64 gets killed.  >>   >>> L >>>> You keep assuming that they have any plan or even desire to migrate VMSK >>>> any further.  If that were likely, considering how long it can take to O >>>> go from desire to a viable commercial product, the work would have already 
 >>>> begun.   G >>> Yes, it had begun and was happening in the basement of ZKO, until I D >>> uncovered it and they quickly replaced the office furniture withH >>> sporting equipment, removing any traces that there was ever a covert' >>> porting effort going on :-) :-) ;-)  >>   >> Keep smokin'......  >  > You can count on it.  :-)  > L >>> The VMS engineers have all the tools already to manage a porting effort. >>  G >> Now there's another big assumption on your part.  Being as they have E >> repeatedly said there is no port to x86-64, why would HP have paid  >> for all these tools?  >>  H >>> If, in 2007, Intel/HP announce the end of the line for IA64, it willF >>> probably includd one more iteration of that "thing" and last a few
 >>> years, >>  G >> Nobody is buying it now, who would buy it if they announced it was a I >> deadend?  Any further "iteration" would just be money down the toilet.  >>  - >>>         during which VMS can be ported.    >>  M >> And during all this time you think the IT and business world is just going L >> to stand still?  You thhink MS won't be out there raiding what is left ofC >> HP's customers?  Or Sun?  Or IBM? Or any of dozen Linux brokers?  >>  I >>>                                         (this is where the killing of ? >>> Alpha sales at this point in time is a very wrong mistake).  >>  ( >> Maybe, but it is a done deal as well. > K > This is a business decision.  If the decision was changed, continuing to  F > manufacture and sell the current Alphas is definitely doable from a  > technical perspective.  D Again, I have to defer to the HP people who are in a better positionB to know and they have repeatedly stated here that the resources noD longer exist at HP to revive the Alpha line.  And, we have been toldB that there was also some agreement regarding Alpha in the HP-IntelD deal.  It is equally possible that the agreement was that they couldC no longer continue development of the Alpha.  If that turned out to D be so, what incentive would Intel have to release HP from it?  No, IA think as the HP denizens here have stated, Alpha is a dead issue.    > I >>> Face it, toy controller or high end chip, the 8086 is solid as a rock I >>> with no rumours of it going away anytime soon.  Move VMS to the 8086, L >>> and you all once and for all any rumours of VMS's demise because as longL >>> as it is profitable, there is no reason to kill it. And customers havingH >>> more confidence in a VMS rejuvenation will stay or buy in to VMS and >>> you'll see real growth.  >>   >> Keep on smokin'...... >>   >>> G >>> Right now, the sad reality is that a weakened VMS is using its last L >>> energies to try to support IA64. Move to  8086 and it is the strong 8086H >>> (in the marketplace) that will help and support VMS and let it grow. >>> > >>> IA64 is a liability to VMS. 8086 would be an asset to VMS. >>  J >> Probably way too little, way too late.  But in any event, it isn't evenI >> a blip on the radar and businesses are not going to wait around to see I >> what comes next.  If we are truly seeing the last hurrah for IA64 then 7 >> we should be very concerned about the future of VMS.  >  > Very!  >    So, Dave, how's the injury?    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: Thu, 20 Jul 2006 21:31:45 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: Re: New itaniums out at 2.5x perform gain, Message-ID: <44C02E7F.418AFACE@teksavvy.com>   Bill Gunshannon wrote:C > Maybe so, but after years of hearing how the x86 architecture was G > unsuitable for running VMS it seems highly unlikely that the addition D > of 64 bit extensions has somehow corrected all those shortcomings.    F Remember that the 8086 has gone from a 16 bit toy controller with 640kG memory limit and segment registers into a 32 bit CPU with full features ? and now 64 bit machine. In the process, it has gained many more G features. So while the 8086 circa 1990 was definitely ill suited to run J VMS, the CPUs made today for that architecture have gained respectability.  B > Not saying it can't be done, just that the idea that porting VMSC > to IA64 somehow made it easier to port to x86 is quite a stretch.   G Posting to IA64 specifically gave VMS the ability to do EFI. That meant D tweaking the file system to allow a FAT partition-in-a-VMS-file with. updates to BACKUP, INIT etc to support this.    C But the port just made, no matter what the target was, game VMS the G ability to have a common code base supporting multiple architectures at D the same time, and this allowed engineers to continue to work on VMSG while the port was being done. And a lot fo stuff was cleaned up and as F someone else said, many hardware features were moved to software, thus& making VMS less dependant on hardware.    So the next port will be easier.    G > True, but JF has always had this pipe dream that a bunch of engineers A > are kept chained up in the basement of ZKO working 24/7 on some  > mystery x86 port.   & I never said they were chained :-) :-)  8 > Many people from HP (in a better position to know thanG > JF) have repeatedly stated there are no plans, at this time, to do an  > x86 port.   A Yes, and that is perfectly normal. Until the second when HP/Intel E announce the end of IA64, expect everyone within HP/Intel to deny any H plans to abandon IA64. Announcing plans to port VMS to the 8086 would be) tantamount to announcing the end of IA64.   G And while I may be hoping for a Covert port of VMS to the 8086 going on E right now, (the faster, the better), I think it would be realistic to = think that someone within VMS engineering has looked into the E feasability of porting VMS to a 64 bit 8086 based on EFI and reported 9 back to very high management and kept this very discreet.   F Note that this had happened prior to the announcement of the prematireC euthanasia of Alpha. I think it was 2 engineers that were tasked to F secretely make a feasability study of porting VMS to IA64. The rest of5 the engineers were totally oblivbious to those plans.     J > When (and if) such a port is to be attempted it will likely get the sameJ > fanfare as all the other ports.  It is not the kind of thing that can beH > kept hidden away, even if there was some business reason for doing so.  E Once it is announced, you are right. But until that time, it is quite @ possible to see VMS engineers talk to Intel engineers about whatG features they may want in the generation of chips that would come circa F 2007.  Also, someone would also be talking about the types of featuresJ that would allow one to build an 8086 based Wildfire/Galaxy class machine.    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 no. > longer exist at HP to revive the Alpha line.  B Horse manure. Where there is a will, there is a way.  But there isG clearly no will at HP to revive Alpha, no will to even postpone the end G of sales date. And if the will existed, it would take a lot of creative A accounting to cost justify restarting Alpha with a huge amount of  resources to catch up.   ------------------------------    Date: 20 Jul 2006 18:40:57 -0700 From: perfnerd@yahoo.com2 Subject: Re: New itaniums out at 2.5x perform gainC Message-ID: <1153446057.266977.322720@i42g2000cwa.googlegroups.com>    Bill Todd wrote: > bob@instantwhip.com wrote:M > > http://www.informationweek.com/news/showArticle.jhtml?articleID=190500823  > I > Ah, me - even an article that starts by bending over backward to try to H > make Itanic look good has a lot of difficulty doing so these days - atD > least if it doesn't play somewhat fast and loose with its wording. >  > Examples:  > I > "Say this for Intel-after five years of [initially negligible and later G > only] modest sales and [dramatically] scaled-down ambitions, it's not C > [at least not yet] giving up on Itanium [at least not publicly]." " > (bracketed clarifications added) > @ > "The chips deliver more than twice the database performance ofI > previous-generation Itaniums [at the *chip* level, though only slightly J > more *per-core* performance despite years of new development, 5x as muchH > L2 cache and 1.33x as much L3 cache, and significant core enhancementsD > like multi-threading:  the rest comes from having two cores on theB > chip], and draw 2.5 times less electric power [if you nimbly andI > ever-so-tacitly switch the subject from the *chip* to *per-core* power: 3 >   the per-chip power is only moderately reduced]"   G You are right, but it does really depend on whether you want to look at A the differences on a per core, per socket, per box, or per dollar  basis.  F Montecito does draw less per socket than Mad9M.  The Mad9M is rated atF 130Watts, while the Montecito is rated at 104Watts.   That is 26% lessF wattage on a per socket basis.  Which is significant if you are buyingA based on a core count, since the same number of CPUs draw 40% the  power.  G At the box level, the new Montecito SuperDome is shown on the SPEC site F as being able to achieve a SPECint_rate2000 base of 2367 with 128 CPUsF / 64 sockets (Jul 2006), vs 1108 for the 64/64 for the Mad9M Superdome9 (Jan 2005) and 1063 for the  64/32 IBM P5 595 (Oct 2004).   L > "But..." it then continues, and actually isn't all that biased thereafter. >  > - bill   ------------------------------  % Date: Thu, 20 Jul 2006 21:44:09 -0400 ( From: Bill Todd <billtodd@metrocast.net>2 Subject: Re: New itaniums out at 2.5x perform gainG Message-ID: <yOudnZMu0un3rF3ZnZ2dnUVZ_sKdnZ2d@metrocastcablevision.com>    Bill Gunshannon wrote:; > In article <yvWdnR1hv-4ek13ZnZ2dnUVZ_rednZ2d@libcom.com>, , > 	Dave Froble <davef@tsoft-inc.com> writes: >> Bill Gunshannon wrote: 0 >>> In article <44BFC335.32AEF7E8@teksavvy.com>,4 >>> 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes:   ...   J >>>> First, porting VMS to the 8086 should be less expensive than Alpha toM >>>> IA64. They now have setup the abililty to have common code base, cleaned H >>>> up the code to make porting easier, AND have already gotten the EFIM >>>> stuff installed and running on VMS.  So the port to the 8086 should cost  >>>> less and take less time.   N >>> Your smokin' again.  There is little that has been made public so far thatL >>> would lead one to believe that because they ported VMS to IA64 it is nowL >>> somehow easier to port it to x86-64.  The two have little if anything in >>> common, architecturally.F >> There have been more than a few things mentioned.  Moving hardware : >> capabilities into code within VMS and things like that. > C > Maybe so, but after years of hearing how the x86 architecture was  > unsuitable for running VMS  1 Wow - some people will believe anything, I guess.   I Given that active investigation of porting VMS to x86 was actually under  B way in the early '90s, suggesting that there's any insurmountable G obstacle (beyond major amounts of mostly-standard grunt work) involved  E seems a bit unreasonable - especially now that x86 has become 64-bit.   ,   it seems highly unlikely that the additionD > of 64 bit extensions has somehow corrected all those shortcomings.  F All *what* shortcomings?  Please be specific.  x86-64 now has as many E registers as VAX did (not that the earlier investigation I mentioned  H above seemed to have considered having only 32-bit x86's eight register D to be a show-stopper).  The 'number of modes' issue has been pretty * thoroughly shown to be a non-issue AFAICT.  B > Not saying it can't be done, just that the idea that porting VMSC > to IA64 somehow made it easier to port to x86 is quite a stretch.   G You don't think that, e.g., rewriting assembler routines in HLLs makes  E porting easier?  ISTR one or more of the associated engineers making  I precisely this point a while ago - and explicitly stating that they took  G advantage of the Itanic port to make a possible subsequent port easier.    ...   9    Many people from HP (in a better position to know than G > JF) have repeatedly stated there are no plans, at this time, to do an  > x86 port.   I Many people at Intel (in an excellent position to have known the truth -  E from the CEO on down) repeatedly stated that there were no plans for  G extending x86 to support 64-bit operation - at a time when the support  2 already existed (albeit fuse-disabled) in silicon.  B Companies tell customers what they want customers to believe:  it ? doesn't necessarily bear any close relationship with the truth.    ...    >>> J >>>>                                         (this is where the killing of@ >>>> 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 no. > longer exist at HP to revive the Alpha line.  G Had you read more carefully you would have noticed that neither JF nor  G Dave was talking about continuing Alpha development in any significant  G sense:  they were (quite explicitly, even in the material you yourself  E quoted above) talking only about continuing manufacture and sales of   existing product.       And, we have been told D > that there was also some agreement regarding Alpha in the HP-Intel > deal.   H We have?  When, and where, and what were the details, and was there any ' reason to consider the source credible?   E Assuming that you're in fact referring to the Compaq-Intel deal, the  H only direct assertion that *I* recall in this area was that Compaq sold D Intel only the rights to *use* the Alpha intellectual property, not E control over that property - retaining the right to do with it as it   pleased.  @    It is equally possible that the agreement was that they could. > no longer continue development of the Alpha.  E Not IIRC according to the only people here who purported to know the   facts of the matter.   - bill   ------------------------------  % Date: Fri, 21 Jul 2006 00:17:02 -0400 ( From: Bill Todd <billtodd@metrocast.net>2 Subject: Re: New itaniums out at 2.5x perform gainG Message-ID: <_KidnYKtVoyiyF3ZnZ2dnUVZ_q6dnZ2d@metrocastcablevision.com>    perfnerd@yahoo.com wrote:  > Bill Todd wrote: >> bob@instantwhip.com wrote: M >>> http://www.informationweek.com/news/showArticle.jhtml?articleID=190500823 J >> Ah, me - even an article that starts by bending over backward to try toI >> make Itanic look good has a lot of difficulty doing so these days - at E >> least if it doesn't play somewhat fast and loose with its wording.  >> >> Examples: >>J >> "Say this for Intel-after five years of [initially negligible and laterH >> only] modest sales and [dramatically] scaled-down ambitions, it's notD >> [at least not yet] giving up on Itanium [at least not publicly]."# >> (bracketed clarifications added)  >>A >> "The chips deliver more than twice the database performance of J >> previous-generation Itaniums [at the *chip* level, though only slightlyK >> more *per-core* performance despite years of new development, 5x as much I >> L2 cache and 1.33x as much L3 cache, and significant core enhancements E >> like multi-threading:  the rest comes from having two cores on the C >> chip], and draw 2.5 times less electric power [if you nimbly and J >> ever-so-tacitly switch the subject from the *chip* to *per-core* power:4 >>   the per-chip power is only moderately reduced]" > I > You are right, but it does really depend on whether you want to look at C > the differences on a per core, per socket, per box, or per dollar  > basis.  F That was not the problem:  the problem was that the article's wording H first referred explicitly to per-chip performance measurements and then F went on to state that power drain was down 2.5x *in the same context* 8 (when in fact it was down only 1.25x at the chip level).  ; That's called either linguistic incompetence or deliberate  1 misinformation, not mere difference of viewpoint.    > 1 > Montecito does draw less per socket than Mad9M.    As I noted above.       The Mad9M is rated atH > 130Watts, while the Montecito is rated at 104Watts.   That is 26% less  > wattage on a per socket basis.  I That is in fact 20% less wattage on a per-socket basis the way I learned   arithmetic.   )    Which is significant if you are buying C > based on a core count, since the same number of CPUs draw 40% the  > power.  F Absolutely:  you can either get similar performance at less than half G the power, or over twice the performance at about the same power.  But  C you cannot (as the article's wording suggested) get over twice the  ( performance at less than half the power.  B The bottom line is that the only really impressive achievement in C Montecito is its power reduction for a given level of performance:  E doubling up the cores as a result of the process shrink is certainly  6 useful, but relatively straight-forward by comparison.   > I > At the box level, the new Montecito SuperDome is shown on the SPEC site H > as being able to achieve a SPECint_rate2000 base of 2367 with 128 CPUsH > / 64 sockets (Jul 2006), vs 1108 for the 64/64 for the Mad9M Superdome > (Jan 2005)  H Hmmm.  Assuming that the results scale pretty linearly (which they seem E to these days for SPECint_rate), that's not that much of a boost per  F core over Mad9M considering Montecito's L2 and L3 cache improvements, A the significantly reduced memory latency that the sx2000 chipset  I supposedly provides (the 533 MHz bus speed does imply that the sx2000 is  G being used, does it not?), and whatever compiler improvements occurred.   0 > and 1063 for the  64/32 IBM P5 595 (Oct 2004).  A One might suspect that the POWER5+ when IBM sees fit to submit a  G large-system configuration will enjoy a modest per-core advantage over  C Montecito, given the minimal per-core advantage that Montecito and  G sx2000 appear to enjoy over Mad9M and sx1000.  Perhaps zx2 will uphold  ' Itanic's small-system honor in SPECint.    - bill   ------------------------------    Date: 20 Jul 2006 13:59:56 -0700- From: "mb301@hotmail.com" <mb301@hotmail.com> 4 Subject: Re: Pathworks V6.1 browser in pending stateC Message-ID: <1153429196.500368.170680@i42g2000cwa.googlegroups.com>    tomarsin2015@comcast.net wrote:  > Hello G > After a reboot my PDC (VAX 3100-85 VMS 7.3 Pathworks 6.1) or for that G > matter any system when Pathworks starts the browser goes into a start E > pending state. I search the net for possible solutions and it seems ; > nothing applies here. The system is not part of a cluster G > and I have more then eough licenses (400+). This problem also started  > after downloading  > some windows update. > AFRICA> pwshowB > OpenVMS V7.3  on node AFRICA  19-JUL-2006 09:19:45.77  Uptime  0
 > 08:44:08H >   Pid    Process Name    State  Pri      I/O       CPU       Page flts > Pages H > 00000294 NETBIOS         HIB      4      255   0 00:00:00.61       751 >   144 H > 000002A3 PWRK$ADMIN_0    LEF      6       38   0 00:00:00.61       505 >    62 H > 00000298 PWRK$KNBDAEMON  HIB     12      336   0 00:00:02.93      2352 >   455 H > 0000029A PWRK$LICENSE_R  HIB     11      200   0 00:00:03.36      3790 >   244 H > 000002A7 PWRK$LMBROWSER  HIB      9      299   0 00:00:07.86     14967 >   247 H > 0000029F PWRK$LMMCP      HIB     11      984   0 00:00:09.33      8894 >   799 H > 000002A5 PWRK$LMSRV      HIB     11     1408   0 00:00:29.35     24158 >  2579 H > 0000029D PWRK$MASTER     HIB      6      345   0 00:00:04.87      2761 >   137 H > 000002A1 PWRK$MONITOR    HIB      6       57   0 00:00:05.08      6598 >   360 H > 00000296 PWRK$NBDAEMON   HIB     10       32   0 00:00:00.53       516 >   192 H > I checked the logs and nothing seems strange or out of place. I should > state thatE > I can ping any system and I can even do a dir on some of the shares & > Shared resources on server "AFRICA": > & > Name          Type       Description > ------------  --------- 9 > -------------------------------------------------------  > PCFILES       Directory  >     Path: DPA100:[PCFILES]E >     Connections:  Current: 3, Maximum: No limit <------so users can  > stil connect >     RMS file format: Stream D >     Directory Permissions: System: RWED, Owner: RWED, Group: RWED, > World: RE E >     File Permissions: System: RWD, Owner: RWD, Group: RWD, World: R  >     Share Permissions:6 >         Everyone                        Full Control >  >   Total of 1 share > C > If I do a net view only 2 computers will show up - a windows 2003  > server and a win2kH > system. I am totally at a lost - I even tried rebooting everything but  > nothing works. I cannot beliveE > that downloading some updates and rebooting a system would cause so  > much trouble.  > thanks     Try:-  $ pwstop $ samcheck -sv     Anything under   $ admin/ana/sin=today ??   Regards  Mark   ------------------------------  % Date: Thu, 20 Jul 2006 21:07:00 -0500 6 From: "David J. Dachtera" <djesys.no@spam.comcast.net>. Subject: Re: PIPE redirection as stream file ?0 Message-ID: <44C036C4.5DAB9FAF@spam.comcast.net>   "Keith A. Lewis" wrote:  >  > "Pierre" <pierre.bru@gmail.com> writes in article <1153353100.976519.4720@m79g2000cwm.googlegroups.com> dated 19 Jul 2006 16:51:41 -0700:  > > A > >PIPE redirection are "Record format: VFC, 2 byte header" files  > > D > >I got a program the output some text followed by <CR><LF> and theB > >result is the the redirected output contains 2 records: the 1st) > >contains the data and the 2nd is empty  > > + > >is it possible to change this behavior ?  >  > I don't think so.  > M > What you can do is keep an empty stream_lf file around, then convert with a  > copy command.  > 7 > $ copy empty_stmlf.txt,your_vfc.txt stmlf_product.txt    Here's another approach:   $ copy nla0: empty.dat! $ set file/attr=rfm=stm empty.dat * $ pipe command | append sys$pipe empty.dat   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------  % Date: Fri, 21 Jul 2006 08:22:20 +0500 4 From: Valentin Likoum <valentin.likoum@ncc.volga.ru>- Subject: Re[2]: 2 CPU's in timeout on my ES40 2 Message-ID: <07012136.20060721082220@ncc.volga.ru>  N On 21/07/06 dave.baxter@bannerhealth.com <dave.baxter@bannerhealth.com> wrote:     > Syltrem wrote:E >> Has anyone experienced CPU's ceasing to be in service on an ES40 ?  >>M >> 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  <   Last week seems to be unlucky for ES40s woldwide. Our ES40A encountered stange hangs. No crash dump, no error entries, no SRM F prompt - nothing at all, the machine just hangs. Very stange behaviour for this iron.    --  
 Best regards, #  Valentin                           (  valentin.likoum at ncc dot volga dot ru   ------------------------------  % Date: Thu, 20 Jul 2006 05:45:10 -0700 # From: "Tom Linden" <tom@kednos.com> 1 Subject: Re: Tomcat user authentication question. ) Message-ID: <op.tczm1kvzzgicya@hyrrokkin>   H On Wed, 19 Jul 2006 14:04:46 -0700, Rick Barry <richard.barry@hp.com>  =   wrote:  F > CSWS_JAVA (Tomcat) does not yet contain a built-in authentication  =   > mechanism I > for OpenVMS. You could architect such a mechanism using JAAS and Tomca=  t's I > JAAS Realm plug-in, but you'll need to do a bit of coding using the JN=  I E > interface. We may add this to a future version of CSWS_JAVA. In the & > meantime, you need to roll your own. > Rick Barry > OpenVMS System Software Group   : Alternatively, you use a web server designed for VMS, WASD   ------------------------------  # Date: Thu, 20 Jul 2006 23:05:17 GMT % From: "The KGB" <kgb@tampabay.rr.com> J Subject: Re: Under VMS, on an HSG80, can Raid Partition Size be Increased?7 Message-ID: <N_Tvg.759$Ch5.441@tornado.tampabay.rr.com>   F I didn't see any replies so here's my 2 centz!  Once it's set you can K INcrease it but not DEcrease the size of the RAID.  Somebody may know of a  K commercial product that will accomodate you but why not just copy the data  ' off, create what you need then restore? 3 "syslost" <wm.reynolds@gmail.com> wrote in message  = news:1153327789.196166.104250@s13g2000cwa.googlegroups.com...  > Alpha DS25 VMS 7.2-1 > ? > Under VMS, on an HSG80, can Raid Partition Size be Increased?  > I > I want to increase the size of one of the partitions in a raid 5 set on  > an HSG80.  >  > Current config:  >  > NPCtop> show r3 G > Name          Storageset                     Uses             Used by P > ------------------------------------------------------------------------------ > D > R3            raidset                        D36_10200        D101C >                                             D36_20200        D108 C >                                             D36_30200        D109 7 >                                             D36_40200 7 >                                             D36_50200 7 >                                             D36_60200  >        Switches:6 >          POLICY (for replacement) = BEST_PERFORMANCE* >          RECONSTRUCT (priority) = NORMAL! >          CHUNKSIZE = 256 blocks  >        State:  >          NORMAL * >          D36_10200 (member  0) is NORMAL* >          D36_20200 (member  1) is NORMAL* >          D36_30200 (member  2) is NORMAL* >          D36_40200 (member  3) is NORMAL* >          D36_50200 (member  4) is NORMAL* >          D36_60200 (member  5) is NORMAL+ >        Size:             355486275 blocks  >        Partitions:D >          Partition number        Size               Starting Block	 > Used by  > G > --------------------------------------------------------------------- D >            1                117309435 (  60062.43 MB)            0 > D101D >            2                117309435 (  60062.43 MB)    117309440 > D108D >            3                117309435 (  60062.43 MB)    234618880 > D109D >                               3557950 (   1821.67 MB)    351928320 > <free> > H > I want to move d101 to another raid set, destroy it's partition (1) on2 > r3, and double the size of d109.  Can I do this? >    ------------------------------  % Date: Thu, 20 Jul 2006 21:35:01 -0400 / From: "William Webb" <william.w.webb@gmail.com> J Subject: Re: Under VMS, on an HSG80, can Raid Partition Size be Increased?I Message-ID: <8660a3a10607201835w25961c7bkc665fcfac340040f@mail.gmail.com>   0 On 7/20/06, The KGB <kgb@tampabay.rr.com> wrote:G > I didn't see any replies so here's my 2 centz!  Once it's set you can L > INcrease it but not DEcrease the size of the RAID.  Somebody may know of aL > commercial product that will accomodate you but why not just copy the data) > off, create what you need then restore? 4 > "syslost" <wm.reynolds@gmail.com> wrote in message? > news:1153327789.196166.104250@s13g2000cwa.googlegroups.com...  > > Alpha DS25 VMS 7.2-1 > > A > > Under VMS, on an HSG80, can Raid Partition Size be Increased?  > > K > > I want to increase the size of one of the partitions in a raid 5 set on 
 > > an HSG80.  > >  > > Current config:  > >  > > NPCtop> show r3 I > > Name          Storageset                     Uses             Used by R > > ------------------------------------------------------------------------------ > > F > > R3            raidset                        D36_10200        D101E > >                                             D36_20200        D108 E > >                                             D36_30200        D109 9 > >                                             D36_40200 9 > >                                             D36_50200 9 > >                                             D36_60200  > >        Switches:8 > >          POLICY (for replacement) = BEST_PERFORMANCE, > >          RECONSTRUCT (priority) = NORMAL# > >          CHUNKSIZE = 256 blocks  > >        State:  > >          NORMAL , > >          D36_10200 (member  0) is NORMAL, > >          D36_20200 (member  1) is NORMAL, > >          D36_30200 (member  2) is NORMAL, > >          D36_40200 (member  3) is NORMAL, > >          D36_50200 (member  4) is NORMAL, > >          D36_60200 (member  5) is NORMAL- > >        Size:             355486275 blocks  > >        Partitions:F > >          Partition number        Size               Starting Block > > Used by  > > I > > --------------------------------------------------------------------- F > >            1                117309435 (  60062.43 MB)            0 > > D101F > >            2                117309435 (  60062.43 MB)    117309440 > > D108F > >            3                117309435 (  60062.43 MB)    234618880 > > D109F > >                               3557950 (   1821.67 MB)    351928320
 > > <free> > > J > > I want to move d101 to another raid set, destroy it's partition (1) on4 > > r3, and double the size of d109.  Can I do this? > >  >  >  >   B Not meaning to give you a red-ass, but If you're not Kevin Barkes,5 then you're not *the* KGB as far as VMS is concerned.   
 ref:  kgb.com    WWWebb     --  C NOTE: This email address is only used for noncommerical VMS-related  correspondence. C All unsolicited commercial email will be deemed to be a request for 8 services pursuant to the terms and conditions located at# http://bellsouthpwp.net/w/e/webbww/    ------------------------------  # Date: Thu, 20 Jul 2006 10:00:45 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) N Subject: Re: VMS and HPVM (was: Parsec webinar (2006-07-12) OpenVMS Licensing)[ Message-ID: <rdeininger-2007060600480001@dialup-4.233.173.228.dial1.manchester1.level3.net>   I In article <44beaef9$0$18476$9a6e19ea@news.newshosting.com>, "Neil Rieck"  <n.rieck@sympatico.ca> wrote:   J >"Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message . >news:qaNR1gfLz$I7@eisner.encompasserve.org...   ...    >I agree with you. > M >Doing the HP-VM thing is OK for people who want that product but the recent  L >revelation that "Galaxy is not being ported to Itanium" makes me wonder if M >HP is committed to supporting OpenVMS. After reading this (and also hearing  M >that Intel management is now more focused on loss of market share to AMD) I  F >now wonder whether the whole Itanium thing was ever worth the effort.  - Does anyone here actually use OpenVMS Galaxy?    ------------------------------   End of INFO-VAX 2006.402 ************************