1 INFO-VAX	Mon, 27 Aug 2001	Volume 2001 : Issue 475       Contents:) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) RE: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) RE: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update  Digital Storage Works cabinet ! Re: Digital Storage Works cabinet  DS10 and boot from fabric  Re: DS10 and boot from fabric   Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium Re: Hello !  Hello ! ' Re: Hex dump-and-lookatit-in-themorning ' Re: Hex dump-and-lookatit-in-themorning 9 How to delete mail messages after retrieval by POP client = Re: How to delete mail messages after retrieval by POP client ; Re: Looking for Digital Serial Number Identication Resource ; Re: Looking for Digital Serial Number Identication Resource 	 Node Name 
 Re: Node Name 
 Re: Node Name 5 Re: Nuts-n-bolts in News (was: Re: Nits in Slides...) 5 Re: Nuts-n-bolts in News (was: Re: Nits in Slides...) 7 Re: RWMBX - What to do, What to do! Help me if you can.  Re: V5.5-2 Password Recovery Re: V5.5-2 Password Recovery  F ----------------------------------------------------------------------  % Date: Sun, 26 Aug 2001 14:12:13 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 2 Subject: Re: Conference: CETS-2001 Detailed Update+ Message-ID: <3B893BF9.9BAD258@videotron.ca>    Jeff Killeen wrote: I > If memory serves me the transition from System 3 -> System 36 -> System I > 38 -> AS/400 was not without quirks and did require notable source code 	 > changes   N Yes, and this was where Digital made big progress because VMS ran from desktopK to datacentre on the same OS, same procedures, same executable, whereas IBM G had a mismash of various architectures from desktop to datacentre, each % totally incompatible with each other.   N Now, Compaq has Windows on 8086 for desktop and small servers, Windows on IA64H for midrange servers,  Tru64 on Alpha for slightly higher range servers,T Tandem on MIPS for fault tolerant servers, and VMS on Alpha for a few niche markets.  N While this 180 day restructuring announcement may have simplified the hardwareJ component by eliminating MIPS and Alpha from Compaq's product line, the OSH disparity remains. As soon as NT matures, I fully expect another 180 dayI programme to happen to simplify the OS offering with the ultimate goal of 8 having a single OS from desktop to datacentre at Compaq.  M > of Access will cease working.  It is because, for reasons only known to the N > idiots at Microsoft, they replaced system DLL's with the same version number1 > that were incompatible with the older software.   M Reasons are simple: you are expected to upgrade all your software at the same L time.  FORMAT C: and then load the new OS and then load the new applicationsN from scratch. The concept of a Windows system living for more than a couple ofL years is foreign to them. (many VMS systems live on for decades, having goneM through many system and app upgrades without restarting from scratch, and you I can easily tell because these systems accumulate some interesting lint in - SYS$MANAGER , SYS$SYSTEM, SYS$UPDATE etc etc.    ------------------------------  % Date: Sun, 26 Aug 2001 14:07:18 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> 2 Subject: Re: Conference: CETS-2001 Detailed Update( Message-ID: <9mbdrn$1gn$1@pyrite.mv.net>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message 2 news:un4i7.1903$Ia1.338158@typhoon1.gnilink.net...   ...   I > If memory serves me the transition from System 3 -> System 36 -> System I > 38 -> AS/400 was not without quirks and did require notable source code 	 > changes   G Which is why I didn't include S/3 or S/36 in my comments (IIRC they had K significantly different software architectures as well, so they didn't seem H relevant anyway - sort of like migrating from RSTS to VMS), and includedK S/38 only conditionally.  But something I probably should have mentioned is L that when AS/400 migrated to a completely new (Power) hardware platform, the> change was made absolutely invisible to existing applications.   ...   F > > Because of the *way* in which they handled such transitions.  Even > Microsoft H > > and Intel (which I'm not otherwise presuming to compare with VMS and > Alpha)E > > have managed to keep early-1980s software running - natively - on  current I > > platforms right up through Win98 (and possibly through 'ME' - I'm not J > > acquainted with it).  NT had (and Win2K has) more restrictions, but itK > > *supplemented* rather than *replaced* DOS's descendents.  XP is finally G > > (IIRC) ringing down the curtain on real-mode DOS programs, but only  many, F > > many years after the development of and need for such programs has ceased.  > : > Bill boy have you had  little experience with Microsoft.  I I'd suggest that you stick with topics about which you have at least some  minimal level of knowledge.      Yes what you sayI > is true if you look at the kernel level but if you have ever dealt with J > Microsoft at the applications development level Microsoft is the king of? > "just kidding" technical shifts (lies as you would call them)   I No, I wouldn't call them lies at all - unless you can point to statements B Microsoft has offered (similar to those in the Heil/Lipcon letter): guaranteeing the stability of its development environment.  J There's a big difference between breaking existing applications (even justE to the point where they must be recompiled - if possible - to perform J acceptably) and requiring developers to acquire new skills if they want toI upgrade to a new development environment (rather than just continue using K their existing development environment, which continues to work just fine).     in the 4 years J > I have been using Microsoft development tools they have come out with noK > less than 5 data interfaces.  Think of it like 5 different flavors of RMS K > where they are slightly and insidiously incompatible.  Basically you need  toB > move to the flavor of the quarter data interface because key newI > functionality isn't added to the older ones. Microsoft has zero problem  withI > dead ending a API because of lack of market acceptance or because it is D > easier to produce a new API than fix the old one.  If you bet on a	 Microsoft # > API you really are taking a risk.   L Sort of like the risk one took betting that Alpha development would continueH as the main-line vehicle for VMS use, in fact.  Though the risk that VMSL will later be similarly dead-ended seems to be greater than either of these,9 since that would require a *complete* environment change.    > C > Additionally when you get above the kernel to the DLL (RTL) level 	 Microsoft L > breaks applications all over the place.  It is known as DLL hell.  You canJ > install a new application on Windows and have the old application break.I > This is not just sloppy 3rd party products.  For example if you install D > Microsoft Outlook 2000 on a system running Microsoft Access 97 key featuresI > of Access will cease working.  It is because, for reasons only known to  the G > idiots at Microsoft, they replaced system DLL's with the same version  number@ > that were incompatible with the older software.  Microsoft has consistently > done this.  K That's called incompetence:  while it's certainly a major problem for users G of multiple mutually-exclusive versions of their software (which adding I applications can require, though they *try* not to let this happen and at G least often succeed), it's not the same as casually (and intentionally) @ jerking the customer base around without demonstrable necessity.   > H > Maybe some nitty gritty exposure to other conversions and the businessB > habits of other manufactures might cause one to rethink Compaq's behavior...   E I doubt it:  Microsoft may be incompetent, but it at least *tries* to L satisfy its customers (its behavior with competitors and even 'partners', of- course, is of an entirely different quality).   K And you're once again attempting to paint *all* alternatives to Compaq with G the Microsoft brush, even though I was careful to limit the comments to G which you're responding to a very specific area of upward-compatibility D (which limited area does not actually extend to the difficulties you+ mentioned, real though they certainly are).   H There *are* good alternatives out there to VMS, especially when you takeJ VMS's owner into account.  And because of the recent Alpha decision, a lotE of people are now looking at them a lot more seriously than they were  earlier.   - bill   ------------------------------   Date: 26 Aug 2001 17:11:51 GMT( From: dek@cgl.ucsf.edu (David Konerding)2 Subject: Re: Conference: CETS-2001 Detailed Update7 Message-ID: <slrn9oiben.eokc.dek@socrates.cgl.ucsf.edu>   G On Sun, 26 Aug 2001 10:12:40 GMT, Jeff Killeen <Jeff@IDM-IO.com> wrote:  > 4 > "Bill Todd" <billtodd@foo.mv.com> wrote in message$ > news:9ma8al$6ap$1@pyrite.mv.net... > J >> But while on the subject of performance, in later posts you've asserted > thatL >> performance isn't an issue because Compaq will be able to substitute 2 or > 3 B >> IA64 processors for each Alpha chip.  That seems a fairly naive
 > suggestion, E >> since the difference in cost between building a uniprocessor and a G >> dual-processor system, or between a dual-processor and a 4-processor 	 > system, G >> is usually considerably greater than the mere cost of the additional I >> processors (i.e., SMP scaling increases the expense of the surrounding G >> hardware as well - especially when the IA64 chips don't have as much ( >> built-in SMP glue as, say, EV7 does). > M > Naive?  The statement makes me wonder if anything you say is constrained by 
 > facts... > 9 > http://www.cdw.com/shop/products/default.asp?EDC=250574  > J > ...in the Intel world the the typical cost preminum for a dual processorK > system board is about $400.  A dual processor systemboard and another IPF I > chip at volume pricing would be about the same as the extra cost of the  > Alpha chip with overhead.  >   E This is growing somewhat off-topic, but there's a very big difference A between a low-end dual processor system and a good dual processor D system.  A lot of people got excited about the Abit BP6 motherboard,A because you could put two celerons in it, which Intel didn't want C anybody to do.  So, lots of people were able to have dual processor E machines and feel really important for it.  But I've worked with such G machines, as well as better-engineered dual processor workstation class D machines, and I can ensure you that the Abit was a pretty lousy dualB processor.  The memory controller could not feed both CPU's demandD simultaneously, which meant that if you ran two STREAM benchmarks at> the same time, you wouldn't get 2X scaling.  On dual processor? workstations with better memory throughput, you get 2X scaling. I STREAM is just a benchmark, but for some of my jobs I am RAM bound as the G CPUs are pulling in 2 big floating point matrices and performing fairly G simple operations like Z=X+Y.  In that case, I found that having 2 cpus J did not allow me to run 2 jobs at the same time and achieve 2X throughput.D It was more like 1.6 throughput, but then again, it only cost me 1.6* as much to get the dual processor machine.  @ Where it gets really interesting is 4 cpus or higher on the sameD board.  I gained some enlightenment when I ran stream on our ES40 (4D 667MHz cpus, I think), and it scaled linearly up to 4 cpus.  I guessG that crossbar switch to the memory where each switch port is really fat  makes a difference.    Dave   ------------------------------  % Date: Sun, 26 Aug 2001 14:11:51 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> 2 Subject: Re: Conference: CETS-2001 Detailed Update( Message-ID: <9mbe47$28m$1@pyrite.mv.net>  F "Bob Kaplow" <kaplow_r@eisner.encompasserve.org.mars> wrote in message- news:uo$2ZckA3OHi@eisner.encompasserve.org... K > In article <TRXvRPfOKbnn@eisner.encompasserve.org>, Kilgallen@SpamCop.net  (Larry Kilgallen) writes:    ...   E > > If a conversion will not buy you a performance increase you need, < > > you should stick with Alpha !  The same is true for VAX. >  > I > I'd love to. When and where can I buy the Alpha EV8 Marvel box? The one  withL > 3x the CPU performance and 4x CPU count than the one we bought a year ago.  J I think you may be underestimating (by a factor of at least 2) EV8's levelD of per-processor performance improvement, unless your application isH strictly single-threaded.  Unless your comparison was a hypothetical oneE between EV8 and an EV7 system you might have purchased in the future.    - bill   ------------------------------  % Date: Sun, 26 Aug 2001 14:16:57 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <3B893D14.22985F12@videotron.ca>   "Main, Kerry" wrote:; > As a fyi, CA did make a statement on this Alpha-IPF port.  >  > Reference:? > http://www.compaq.com/hps/ipf-enterprise/customer_quotes.html   G The text you included in your port contained no reference to VMS. Since M companies such as Oracle have made commitments to IA64, but circumcribed them N to Tru64 only (with VMS decisions not yet made supposedly), you can understandJ that VMS customers see statements such as the one you quoted to be totallyN without value to a VMS customers. We need to see VMS specifically mentioned onL anything coming out of compaq in order for it to register as something whichU affects us, otherwise, it is assumed to affect only wintel or sometimes unix systems.    ------------------------------  % Date: Sun, 26 Aug 2001 14:29:17 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <3B893FF8.1024E876@videotron.ca>   "Main, Kerry" wrote:D > Do you mean like what when IBM abruptly dropped NT on the PowerPC?  N The impression I had was that it was Microsoft who didn't see anyone marketingE NT on MIPS and dropped support, and later dropped support on PowerPC.   N However, consider that Compaq was, at the time it acquired Digital, the leaderI in wintel solutions and had a lot of clout in the industry. Consider that O Digital had been working for 3 years to reshape Digital to suit Compaq wishes.    N It is not unreasonable to think that Bill Gates knew that Compaq would acquireK Digital and Alpha. As a result, Gates would have kept NT-Alpha alive to see N what Compaq was going to do with it. Gates probably saw a big chance of CompaqK using its marketing clout to push Alpha-NT as an industry standard platform D and move NT into the high performance area on Alpha, giving Compaq a& significant edge over its competitors.  L Alas, Compaq decided to kill Alpha, first by not bothering with NT on Alpha,L then calling the 8086 industry-standard and telling the world it would focusI on industry standard solutions and now cashing in on the bounty Intel had 5 reserved for anyone willing to kill Alpha completely.   N Look at it from Gates' point of view. He was probably very happy to see CompaqN take Alpha and had high hopes that Compaq would market Alpha big time and turnL it into the success it deserved. But when Microsoft realised that Compaq hadK acquired the bad-marketing-disease from Digital, it probably told Compaq it N was on its own with NT-Alpha and this wa what made Compaq drop support for NT.  J I have a strong suspicion that if Compaq had presented Gates with a strongJ marketing plan to boost alpha to "insustry standard" for high end systems,I that microsoft would have made it very easy to constinue to support NT on 5 Alpha and provided more applications native on Alpha.e      J > Or when IBM decided to focus its PowerPC chips away from the Mac market?  @ Funny, the powerPC on the MAC is still alive and kicking though.   ------------------------------  % Date: Sun, 26 Aug 2001 14:39:25 -0400d' From: "Bill Todd" <billtodd@foo.mv.com>l2 Subject: Re: Conference: CETS-2001 Detailed Update( Message-ID: <9mbfnt$39l$1@pyrite.mv.net>  6 "Main, Kerry" <Kerry.Main@compaq.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF4D495F2@kaoexc01.americas.cpqcorp.net... > Tim, >rI > >>> You can say what you want about IBM and Sun (I'm no fan of Sun, theaL > SPARC, or Solaris) or IBM (I'm ok with them), but IT Managers can at leastI > really believe that neither of those two companies is going to abruptly L > change course or suddenly ditch a critical component of the solutions they > provide to customers.>>> >lD > Do you mean like what when IBM abruptly dropped NT on the PowerPC?2 > http://www.zdnet.com/eweek/news/1216/17amot.htmlA > http://www.microsoft.com/PressPass/press/1997/Feb97/PowerPr.aspaJ > Many seem to think it was only Alpha that dropped out of the NT market - IBMuL > and Motorola(and MIPS) were the first to make that decision to drop NT for > their RISC platforms ...  F I suspect he does *not* mean 'like when IBM abruptly dropped NT on theE PowerPC':  that may (or may not - I don't know whether IBM vigorouslymH promoted NT on PPC right up to the moment of cancellation, as Compaq didL with NT on Alpha) be comparable to Compaq's NT on Alpha debacle, but I thinkC the magnitude of the reaction to the complete cancellation of AlphaeB indicates that the two debacles differ by an order of magnitude in importance.    >-J > Or when IBM decided to focus its PowerPC chips away from the Mac market?= > http://news.cnet.com/news/0,10000,0-1003-200-339870,00.html@J > " The reasons for IBM's slow retreat is tied to a shrinking market, saidI > analysts. Had Apple continued to allow Macintosh clones to be produced,e them& > outlook might have been different.."  - Let's look at the details of this comparison:i  F Apple isn't interested in moving Mac to a 64-bit platform, so wants toK continue using 32-bit PPC.  IBM isn't interested in continuing to *enhance*nJ 32-bit PPC for a smallish market (which Apple just made smaller by cuttingI off the clones) - though seems willing to continue to sell Apple existingtB 32-bit PPC versions, and Motorola remains a second source of them.  L Exactly how does this constitute any kind of betrayal by IBM?  E.g., can youB point to any "We'll *always* be there for you, at the forefront ofI technology!" commitments similar to those in the Heil/Lipcon letter?  AndrG even if it did constitute some kind of betrayal, it would not be to itsi *own* customer base.   >CK > One can say what they want about the Compaq decision (good, bad or ugly),lL > but they should also consider that other companies like IBM have also made* > decisions like this in the past as well.  ( If they have, you've yet to present them   - bill   >a
 > Regards, >  > Kerry Main > Senior Consultantt > Compaq Canada Corp.r > Professional Servicese > Voice: 613-592-4660e > Fax  :  819-772-7036 > Email: Kerry.Main@Compaq.com   ------------------------------  % Date: Sun, 26 Aug 2001 14:39:11 -0400r+ From: "Main, Kerry" <Kerry.Main@compaq.com>d2 Subject: RE: Conference: CETS-2001 Detailed UpdateR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4D495F6@kaoexc01.americas.cpqcorp.net>   JF,n  H >>> The impression I had was that it was Microsoft who didn't see anyoneF marketing NT on MIPS and dropped support, and later dropped support on PowerPC.<<<a  < Nope. IBM dropped NT for the PowerPC, followed by Motorola.   L http://www.zdnet.com/eweek/news/1216/17amot.html (Dec 16/96 IBM AnnouncementL press article) "Motorola Corp. has followed IBM's lead and dropped its plans@ for support of Windows NT on the PowerPC because of poor sales."  % MS then had no choice in the matter. e  J http://www.microsoft.com/PressPass/press/1997/Feb97/PowerPr.asp (Feb 7/97)I "Today's news follows recent decisions by key industry partners including-L IBM Corp. and Motorola Inc. to limit the breadth of their PowerPC efforts.."   Regards,  
 Kerry Main Senior Consultantw Compaq Canada Corp./ Professional Servicess Voice: 613-592-4660n Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----4 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca] Sent: August 26, 2001 2:29 PMl To: Info-VAX@Mvb.Saic.Comy2 Subject: Re: Conference: CETS-2001 Detailed Update     "Main, Kerry" wrote:D > Do you mean like what when IBM abruptly dropped NT on the PowerPC?  D The impression I had was that it was Microsoft who didn't see anyone	 marketing E NT on MIPS and dropped support, and later dropped support on PowerPC.e  G However, consider that Compaq was, at the time it acquired Digital, they leaderI in wintel solutions and had a lot of clout in the industry. Consider thatWF Digital had been working for 3 years to reshape Digital to suit Compaq wishes.   F It is not unreasonable to think that Bill Gates knew that Compaq would acquire'K Digital and Alpha. As a result, Gates would have kept NT-Alpha alive to seeoG what Compaq was going to do with it. Gates probably saw a big chance ofo CompaqK using its marketing clout to push Alpha-NT as an industry standard platformiD and move NT into the high performance area on Alpha, giving Compaq a& significant edge over its competitors.  L Alas, Compaq decided to kill Alpha, first by not bothering with NT on Alpha,L then calling the 8086 industry-standard and telling the world it would focusI on industry standard solutions and now cashing in on the bounty Intel had 5 reserved for anyone willing to kill Alpha completely.e  G Look at it from Gates' point of view. He was probably very happy to seel CompaqI take Alpha and had high hopes that Compaq would market Alpha big time andn turnL it into the success it deserved. But when Microsoft realised that Compaq hadK acquired the bad-marketing-disease from Digital, it probably told Compaq itrJ was on its own with NT-Alpha and this wa what made Compaq drop support for NT.p  J I have a strong suspicion that if Compaq had presented Gates with a strongJ marketing plan to boost alpha to "insustry standard" for high end systems,I that microsoft would have made it very easy to constinue to support NT on 5 Alpha and provided more applications native on Alpha.       J > Or when IBM decided to focus its PowerPC chips away from the Mac market?  @ Funny, the powerPC on the MAC is still alive and kicking though.   ------------------------------  % Date: Sun, 26 Aug 2001 16:01:08 -0400o- From: JF Mezei <jfmezei.spamnot@videotron.ca> 2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <3B895578.FED536F8@videotron.ca>   Bill Todd wrote:I > Since you've just admitted (complete with corroborating example) that a H > dual-processor motherboard (without processors) costs $400 more than aG > uniprocessor motherboard (without processor), exactly what part of mytF > statement that the surrounding hardware for an SMP system costs more   Actually, this is moot.d  N Consider that IA64 will offer more than half the performance of an Alpha. LetsT say, for the sake of discussion that IA64 offets 75% of the performance of an Alpha.  M So, you now have to switch to IA64. If you switch to a single processor IA64,aN you lose some performance (25%). So you end up with two IA64s. But Compaq willK claim that you are then upgrading from 100% to 150% of performance (since 2MK IA64 give you 150% of raw CPU power of a single Alpha), so they will find au4 way to charge you an arm and a leg for that upgrade.  C The other danger is that Compaq will use benchmarks to measure IA64tN performance which are useless to your application and will claim that the IA64N offers better performance than the Alpha, but when you put it into production,K you find that it offers less performance. So you'll have to pay mucho extranW for additional processors since Compaq's legal side is protected by those "benchmarks".e   ------------------------------   Date: 26 Aug 2001 21:01:44 GMT& From: peter@abbnm.com (Peter da Silva)2 Subject: Re: Conference: CETS-2001 Detailed Update% Message-ID: <9mbo3o$19d@web.nmti.com>   8 In article <ueTh7.1044$tS5.948324@typhoon2.gnilink.net>,% Jeff Killeen <Jeff@IDM-IO.com> wrote:bH > I do get frustrated when I see the discussion focusing on the esotericI > aspects of the chips - one way or another those will be solved - eithereF > though elegant engineering or brute force (n-way processor systems).  6 186000 MPS -- it's not just a good idea, it's the law!   -- r+  `-_-'   In hoc signo hack, Peter da Silva.oE   'U`    "A well-rounded geek should be able to geek about anything."oL                                                        -- nicolai@esperi.org          Disclaimer: WWFD?   ------------------------------  % Date: Sun, 26 Aug 2001 18:42:20 -0400s+ From: "Main, Kerry" <Kerry.Main@compaq.com>u2 Subject: RE: Conference: CETS-2001 Detailed UpdateR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4D495F7@kaoexc01.americas.cpqcorp.net>   Bill,   E >>> Exactly how does this constitute any kind of betrayal by IBM? <<<    It doesn't.   H Both of the examples simply shows that IBM is not afraid of making toughD decisions that it feels is in the best interest of its shareholders.  K IBM continues to be an excellent company with a very good track record withb. respect to support of the solutions it offers.   Regards,  
 Kerry Main Senior Consultanto Compaq Canada Corp.o Professional Servicesy Voice: 613-592-4660t Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----, From: Bill Todd [mailto:billtodd@foo.mv.com] Sent: August 26, 2001 2:39 PMs To: Info-VAX@Mvb.Saic.Come2 Subject: Re: Conference: CETS-2001 Detailed Update      6 "Main, Kerry" <Kerry.Main@compaq.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF4D495F2@kaoexc01.americas.cpqcorp.net... > Tim, >tI > >>> You can say what you want about IBM and Sun (I'm no fan of Sun, theuL > SPARC, or Solaris) or IBM (I'm ok with them), but IT Managers can at leastI > really believe that neither of those two companies is going to abruptlyaL > change course or suddenly ditch a critical component of the solutions they > provide to customers.>>> >uD > Do you mean like what when IBM abruptly dropped NT on the PowerPC?2 > http://www.zdnet.com/eweek/news/1216/17amot.htmlA > http://www.microsoft.com/PressPass/press/1997/Feb97/PowerPr.aspoJ > Many seem to think it was only Alpha that dropped out of the NT market - IBM L > and Motorola(and MIPS) were the first to make that decision to drop NT for > their RISC platforms ...  F I suspect he does *not* mean 'like when IBM abruptly dropped NT on theE PowerPC':  that may (or may not - I don't know whether IBM vigorouslywH promoted NT on PPC right up to the moment of cancellation, as Compaq didL with NT on Alpha) be comparable to Compaq's NT on Alpha debacle, but I thinkC the magnitude of the reaction to the complete cancellation of AlpharB indicates that the two debacles differ by an order of magnitude in importance.t   >aJ > Or when IBM decided to focus its PowerPC chips away from the Mac market?= > http://news.cnet.com/news/0,10000,0-1003-200-339870,00.htmlEJ > " The reasons for IBM's slow retreat is tied to a shrinking market, saidI > analysts. Had Apple continued to allow Macintosh clones to be produced,E the & > outlook might have been different.."  - Let's look at the details of this comparison:i  F Apple isn't interested in moving Mac to a 64-bit platform, so wants toK continue using 32-bit PPC.  IBM isn't interested in continuing to *enhance*oJ 32-bit PPC for a smallish market (which Apple just made smaller by cuttingI off the clones) - though seems willing to continue to sell Apple existing B 32-bit PPC versions, and Motorola remains a second source of them.  L Exactly how does this constitute any kind of betrayal by IBM?  E.g., can youB point to any "We'll *always* be there for you, at the forefront ofI technology!" commitments similar to those in the Heil/Lipcon letter?  And G even if it did constitute some kind of betrayal, it would not be to itsu *own* customer base.   >0K > One can say what they want about the Compaq decision (good, bad or ugly),0L > but they should also consider that other companies like IBM have also made* > decisions like this in the past as well.  ( If they have, you've yet to present them   - bill   > 
 > Regards, >< > Kerry Main > Senior Consultantr > Compaq Canada Corp.e > Professional Servicest > Voice: 613-592-4660a > Fax  :  819-772-7036 > Email: Kerry.Main@Compaq.com   ------------------------------  % Date: Sun, 26 Aug 2001 19:39:52 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>l2 Subject: Re: Conference: CETS-2001 Detailed Update+ Message-ID: <3B8988C6.9FB43AC@videotron.ca>g   "Main, Kerry" wrote:J > Both of the examples simply shows that IBM is not afraid of making toughF > decisions that it feels is in the best interest of its shareholders.  M There is a big difference between IBM and Compaq however in that regards. IBM L has always and continues to be seen as an enterprise corporation with littleK dependancy on Intel/Microsoft. I would say that IBM's PC business is just aiK side order of business and not its main dish, whereas for Compaq, wintel is  its core business.  D Furthermore, consider the type of ties that IBM has with its largestL customers. They are much closer financially than Compaq could ever dream of.M In canada for instance, when IBM built its big building in downtown Montral,nM large customers such as a montreal based bank got to lease some of the ground E level spaces. And IBM would do its banking with all its large bankingMM customers. It is good business because the bank has pressure to choose an IBMeK solution otherwise they stand to loose large deposits and business that IBMc brings to that bank.  D So when IBM makes a strategic decision, it isn't to please anonymousM shareholders, but large institutional corporations most of which happen to be F large customers of IBM. But Compaq makes strategic decisions to pleaseM Microsoft and Intel in the belief that such decisions will make Compaq appearmI better in front of its anonymous shareholders who consider Compaq to be as wintel company..   ------------------------------    Date: 26 Aug 2001 19:33:34 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) 2 Subject: Re: Conference: CETS-2001 Detailed Update3 Message-ID: <0BdXhDOuFU1Z@eisner.encompasserve.org>s  Z In article <3B891D30.8C3D651@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes: > Larry Kilgallen wrote: >> dr >> In article <EdNHw0aJZJ1l@eisner.encompasserve.org>, kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow) writes: >> eQ >> > One question I've had from the beginning is what it will cost us, the users, O >> > to convert? Particularly with software licenses, which these days can cost R >> > more than the hardware. Will my license transfer from Alpha to IPF ***WITHOUTQ >> > COST***? I already spent lots of money to convert VAX licences to Alpha. NFWsQ >> > will customers pay again, especially when this conversion doesn't buy us the / >> > huge performance increases that Alpha did.  >> sD >> If a conversion will not buy you a performance increase you need,  >> you should stick with Alpha ! > @ > Great! So, Alpha *WILL* live forever! That's *WONDERFUL* news!  E If the customers buy enough of them in preference to IA64, certainly.    >>  The same is true for VAX.  > J > ...and we can still get next generation VAXes??!! That's wonderful too!!  B The customers decidedly did _not_ buy enough of those to cause DEC@ to even get more chips fabricated, much less to get new versions( designed.  Somehow they preferred Alpha.  ? Compaq is implicitly predicting the same will be true for IA64.n   ------------------------------  % Date: Sun, 26 Aug 2001 21:42:54 -0400 3 From: mike & cheryl marshall <tmarshall04@snet.net>d& Subject: Digital Storage Works cabinet( Message-ID: <3B89A59E.86953500@snet.net>  G I'm not sure if this is the right forum for this but thought I'd take a F chance. I came across a Storage Works cabinet for the DLT tapes but itH looks like a caddy or something is missing from the unit. The unit seemsH functional but there is nothing for the tapes to sit in to be fed to theF machine. any ideas? I'm new to most of this stuff so any help would be appreciated...thanks   ------------------------------  % Date: Sun, 26 Aug 2001 21:21:45 -0500e1 From: "David J. Dachtera" <djesys.nospam@fsi.net>,* Subject: Re: Digital Storage Works cabinet' Message-ID: <3B89AEB9.8992907A@fsi.net>F   mike & cheryl marshall wrote:. > I > I'm not sure if this is the right forum for this but thought I'd take aaH > chance. I came across a Storage Works cabinet for the DLT tapes but itJ > looks like a caddy or something is missing from the unit. The unit seemsJ > functional but there is nothing for the tapes to sit in to be fed to theH > machine. any ideas? I'm new to most of this stuff so any help would be > appreciated...thanks  C Any model numbers or something else you can tell us? "StorageWorks". "DLT" isn't much to go on.   -- e David J. Dachterae dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/M   ------------------------------  % Date: Mon, 27 Aug 2001 19:45:16 -0400f! From: "Airnews" <Kuff@Tessco.Com> " Subject: DS10 and boot from fabricO Message-ID: <2940E6CAFB4E0B87.788548224C3DFF93.D40DF3BA954AF271@lp.airnews.net>m  L Anyone booting a ds10 from fabric? The wwidmgr quickset commands do not seem to work on the ds10a   ------------------------------  % Date: Mon, 27 Aug 2001 07:08:10 +0200a2 From: "Thomas H. Pauli" <thomaspauli@arcormail.de>& Subject: Re: DS10 and boot from fabric+ Message-ID: <3B89D5BA.4040303@arcormail.de>r  ' Did you try a >>> SET MODE DIAG before?s   Airnews wrote:  N > Anyone booting a ds10 from fabric? The wwidmgr quickset commands do not seem > to work on the ds10r >  >  >      -- h9 Thomas H. Pauli, Hammersteinstr.19, 14199 Berlin, Germanyl   ------------------------------  % Date: Sun, 26 Aug 2001 20:00:31 -0400r- From: Jack Patteeuw <jjpatteeuw@peoplepc.com>p) Subject: Re: Feeling Better about Itaniumg, Message-ID: <3B898D9F.B33E65F7@peoplepc.com>   JF Mezei wrote:. > P > Compaq should have just outright admitted that it was not in the chip businessK > and wanted the most money for its Alpha copyrights and engineers and thatiL > while IA64 was an inferior platform, Compaq could be more profitable usingL > Intel's junk instead of the high quality Alpha. Decision may not have beenL > popular, but at least Compaq would have been honest with its customers and! > would have retained some trust.c    T They have.  Maybe not loudly, but a "very high" management person at Compaq admittedT to me the other day that they "blew it" (actual quote) with the Alpha chip.  WithoutP going into the "why's", he admitted that they did not generate enough revenue toO continue it's development.  (IMHO, it was another case of "stealth" marketing.)i  U Their only hope now is that their "high end system engineers" (i.e. Alpha Systems andaU Tandem) will be able to build computers based on Itanium that are more desirable thanr% their competitors to their customers.:  N Dumping Alpha has given Compaq a few more years (months ?) of breathing room. T Frankly, I think that in 3 - 5 years I will have a hard time explaining to my bossesP (who don't know and don't care about anything computer related except $$$) why I- would pay a premium for a system from Compaq.r  N It is now a "race to the bottom" and the last man standing (in business) wins.  
 Jack Patteeuwn   ------------------------------  % Date: Sun, 26 Aug 2001 20:12:22 -0400a- From: Jack Patteeuw <jjpatteeuw@peoplepc.com>w) Subject: Re: Feeling Better about Itaniume, Message-ID: <3B899066.D79FAF90@peoplepc.com>   Bill Todd wrote: > L > If VMS becomes available on IA64 in 3 years, as projected, the platform itN > will run on won't have any measurable contribution from Alpha, since it willN > either be McKinley (already in silicon) or its follow-on (Madison?) which is > already pretty well-defined.  T Almost true. A "high level" Compaq manager said their "target" for these systems wasP end of 2003.  This will be an "early adopters" systems for ISV to use in portingU their code.  We should all hold our collective breathes that the porting applications-P from Alpha VMS to IA64 VMS goes as smoothly as the the VAX -> Alpha conversions.  U Intel (former Compaq) engineers are working hard at porting BLISS and the VMS versionMU of DEC C to IA64.  Rumor has it that the Unix boys were able to recompile using a GNUt, IA64 compiler and already have booted Tru64.    / > The earliest you could expect even peripheralsN > features (such as the on-chip glue for RAMBUS and SMP) is some time in 2005,M > and the earliest you could expect fundamental architectural impact (such asa > SMT) is some time in 2006.  < Actually they are hoping for a little bit earlier than that.    
 Jack Patteeuw    ------------------------------  % Date: Sun, 26 Aug 2001 20:25:06 -0400s- From: Jack Patteeuw <jjpatteeuw@peoplepc.com>t) Subject: Re: Feeling Better about Itaniumu, Message-ID: <3B899362.7FAEFD19@peoplepc.com>   Bill Todd wrote:" > truly convincing "Mea culpa:  weL > really screwed up this operation and are doing the best we can to recover.  T As I said before, I received my "mea culpa".  That does not mean that I believe thatS Compaq will still be in the "high end systems" (VMS/Unix/NSK) business in 5 years. tF Hell, the way the economy is going they may not be in business at all.  U Am I going to continue recommending Alpha systems to my management ?  For VMS systemscS running 100's of thousands of lines for custom code, yes.  For Unix systems runningv* mostly third party software, probably not.    L > Please help us understand what else we can do to compensate for the damageM > we've done" from current leadership.  Again, I'm not holding my breath, butn+ > don't wholly discount such possibilities.t  P I hate to agree with you on this point, but your right.  IMHO, Compaq managementS still "doesn't get it".  The first rule of sales is, "Don't do anything to piss offeP your existing customer base in your attempt to get new customers or improve your
 bottom line."t    
 Jack Patteeuwn   ------------------------------  % Date: Sun, 26 Aug 2001 20:38:07 -0400c- From: Jack Patteeuw <jjpatteeuw@peoplepc.com>e) Subject: Re: Feeling Better about Itanium , Message-ID: <3B89966F.76DB2B29@peoplepc.com>   JF Mezei wrote:c >iH > Do you seriously beleive that ? The IA64 architecture has already beenO > designed. While the Digits may help improve that architecture and improve itsuG > performance, they aren't going to be able to dramatically change that.B > architecture because that architecture has now be cast in stone.  T Yes, the architecture has now be cast in stone, but the IMPLEMENTATION is wide open.S The 6 in EV6 does mean the sixth generation.  I believe, the Alpha Architecture wasc' "expanded" between 4 and 5 and 5 and 6.e    O > Compaq realises that it needs to spin this bad technological decision. CompaqsM > knows that Alpha was better, but its had no choice because killing Alpha in > > exchange for a wad of money was part of its strategic plan.   K I never heard Compaq admit that money changed hands.  It was just no longerf7 economically feasible for them to continue development.4    P > And if the Digital engineers were truly needed to make IA64 a viable platform,; > that says a lot about the current crop of Intel engineerse  S Actually I pity the management at Intel.  They now have a third development team onoM the East Coast in addition to the existing teams on the West Coast and in thegR Rockies.  Getting them to communicate and exchange technical ideas without any NIH will be an enormous challenge.  S Hopefully Intel won't "waste" that East Coast talent, but only time will tell.  Thet0 problem is, how many of us are willing to wait ?    
 Jack Patteeuwr   ------------------------------  % Date: Sun, 26 Aug 2001 22:31:53 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca> ) Subject: Re: Feeling Better about Itanium-, Message-ID: <3B89B118.50507FB5@videotron.ca>   Jack Patteeuw wrote:U > Actually I pity the management at Intel.  They now have a third development team on$O > the East Coast in addition to the existing teams on the West Coast and in theeT > Rockies.  Getting them to communicate and exchange technical ideas without any NIH  > will be an enormous challenge.    M If that is the case then I guess Intel was after the patents more that it wastL after the engineers. And for Compaq, it is probably much cheaper to transferM the engineers to Intel (no fancy severance packages). And it will probably beaL cheaper for Intel to offer jobs in the west coast and if the ex-Digits don't; like it, then can quit on their own (no severance package).    ------------------------------    Date: 26 Aug 2001 21:44:30 -0500+ From: young_r@encompasserve.org (Rob Young) ) Subject: Re: Feeling Better about Itaniump3 Message-ID: <EzdFwRUb9XZh@eisner.encompasserve.org>   \ In article <3B898D9F.B33E65F7@peoplepc.com>, Jack Patteeuw <jjpatteeuw@peoplepc.com> writes: > JF Mezei wrote:  >> oQ >> Compaq should have just outright admitted that it was not in the chip business L >> and wanted the most money for its Alpha copyrights and engineers and thatM >> while IA64 was an inferior platform, Compaq could be more profitable usingeM >> Intel's junk instead of the high quality Alpha. Decision may not have been M >> popular, but at least Compaq would have been honest with its customers andd" >> would have retained some trust. >  > V > They have.  Maybe not loudly, but a "very high" management person at Compaq admittedV > to me the other day that they "blew it" (actual quote) with the Alpha chip.  WithoutR > going into the "why's", he admitted that they did not generate enough revenue toQ > continue it's development.  (IMHO, it was another case of "stealth" marketing.)B > W > Their only hope now is that their "high end system engineers" (i.e. Alpha Systems and W > Tandem) will be able to build computers based on Itanium that are more desirable than)' > their competitors to their customers.b > P > Dumping Alpha has given Compaq a few more years (months ?) of breathing room. V > Frankly, I think that in 3 - 5 years I will have a hard time explaining to my bossesR > (who don't know and don't care about anything computer related except $$$) why I/ > would pay a premium for a system from Compaq.w > P > It is now a "race to the bottom" and the last man standing (in business) wins. >   D 	Actually, it is more than that.  IBM's "deep thinkers" have decided= 	to give Linux a big push.  When servers across the board are G 	nasty commodities and Dell keeps ripping share, they (HP, IBM, Compaq,yE 	bye-bye Sun) all need to focus on different segments... the segmentsh 	are:v  
 		1)  Storaget 		2)  Software 		3)  Services  ? 	to complement their declining margins in servers (margins that 7 	will follow similar curves that PCs left as examples).d  @ 	IBM's hope of course is to get Linux API across their platformsD 	to cut down on development and porting costs.  Scandanavian company; 	recently was a first to use an IBM mainframe to host Linux + 	"instances" to run their phone app on. . .n   				Rob,   ------------------------------  % Date: Sun, 26 Aug 2001 23:58:32 -0400t' From: "Bill Todd" <billtodd@foo.mv.com>a) Subject: Re: Feeling Better about Itanium ( Message-ID: <9mcgge$sg1$1@pyrite.mv.net>  : "Jack Patteeuw" <jjpatteeuw@peoplepc.com> wrote in message& news:3B89966F.76DB2B29@peoplepc.com...   ...c  F > I never heard Compaq admit that money changed hands.  It was just no longer9 > economically feasible for them to continue development.a  I So they say.  But there's fairly ample evidence (which I won't repeat yetsH again - you can read most of it in a post of mine from July 19th, thoughG there's a tad more spread around elsewhere) that this statement is puree	 bullshit.f   - bill   ------------------------------  % Date: Mon, 27 Aug 2001 00:00:37 -0400h' From: "Bill Todd" <billtodd@foo.mv.com>s) Subject: Re: Feeling Better about Itanium ( Message-ID: <9mcgk7$sgd$1@pyrite.mv.net>  : "Jack Patteeuw" <jjpatteeuw@peoplepc.com> wrote in message& news:3B898D9F.B33E65F7@peoplepc.com...   ...a  F > They have.  Maybe not loudly, but a "very high" management person at Compaq admitted G > to me the other day that they "blew it" (actual quote) with the Alpha  chip.  WithoutG > going into the "why's", he admitted that they did not generate enoughC
 revenue toE > continue it's development.  (IMHO, it was another case of "stealth"a marketing.)1  J That's certainly part of the Compaq party line, but it doesn't explain whyE funding levels that had been planned years in advance suddenly becameoI 'excessive'.  And Compaq's financial numbers indicate that not only *did*gK the Alpha system business generate sufficient profit to continue funding at J those levels, but that even without expansion of its market (and even withK these 'excessive' development costs) those systems have been generating thefJ bulk of Compaq's annual profits (the service business also looks good whenK you break it out as a separate area - but of course breaking it out assumes F that it would exist without the Alpha sales, an assumption which seems- likely to be tested in the very near future).o   ...q  I > Dumping Alpha has given Compaq a few more years (months ?) of breathinga room.a  K Whereas capitalizing on its strengths would have removed the breathing rooml< issue entirely and placed Compaq on a many-year growth path.   ...d  J > It is now a "race to the bottom" and the last man standing (in business) wins.e  L IBM will now be the test of that.  The current Power series of chips has notD too much less potential than Alpha had (as of 2 months ago; if AlphaL development hadn't seriously stumbled under Compaq's management, it would beL farther ahead), and a lot more than IA64 appears to have:  if it (plus SPARCJ for the Sun adherents) can hold onto the upper range of the server market,J IA64 may yet be corralled in the low end (exactly where Intel doesn't wantD it to be, since there it competes - not cost-effectively - with IA32	 servers).c  I Unless x86-64 blows IA64 out of the water completely - a hope that may beo$ remote, but not entirely impossible.   - bill   >  > Jack Patteeuw-   ------------------------------  % Date: Mon, 27 Aug 2001 00:02:49 -0400.' From: "Bill Todd" <billtodd@foo.mv.com>e) Subject: Re: Feeling Better about ItaniumD( Message-ID: <9mcgoa$t7u$1@pyrite.mv.net>  : "Jack Patteeuw" <jjpatteeuw@peoplepc.com> wrote in message& news:3B899066.D79FAF90@peoplepc.com... > Bill Todd wrote: > > K > > If VMS becomes available on IA64 in 3 years, as projected, the platforma itK > > will run on won't have any measurable contribution from Alpha, since ite willG > > either be McKinley (already in silicon) or its follow-on (Madison?)h which is  > > already pretty well-defined. > J > Almost true. A "high level" Compaq manager said their "target" for these systems wasCJ > end of 2003.  This will be an "early adopters" systems for ISV to use in portingl
 > their code.   K That time-table referred to a generally-useful release of VMS on IA64 (as IcK think others have been doing):  I'd (SWAG) expect reasonably functional VMSfL systems to boot on IA64 in not much over a year, and early 'beta' systems toI make it into the field (some for those 'early adopters) well before 2004,yC but still suspect that a polished, high-quality port, complete with B third-party applications, will take most of the projected 3 years.  G And I don't think any of that modifies my suggestion that when VMS doesoL appear, it will be on an IA64 platform with no discernible Alpha influence -7 unless the port takes quite a bit longer than expected.p   ...m  1 > > The earliest you could expect even peripheral J > > features (such as the on-chip glue for RAMBUS and SMP) is some time in 2005,iL > > and the earliest you could expect fundamental architectural impact (such as > > SMT) is some time in 2006. >s> > Actually they are hoping for a little bit earlier than that.  I I'm sure they are, but doubt that they have any reasonable basis for suchLG hope.  They must either try to modify EPIC as it is (and it seems to be I pretty complex, and hence difficult to make major unplanned-for additionsbI to), or start largely from scratch with a new implementation of EPIC that I might be easier to integrate with planned Alpha-style additions but whichu0 would entail even more from-scratch development.  H Consider Paul DeMone's recent statement that VMS had been running on EV7J silicon since (I think) June - but the EV7 release date is still projectedI to be over a year away.  If it takes 1.5 years to get a chip from runningkG the system to general availability, that means that availability of anyuJ major Alpha enhancements to IA64 before 2005 would require running silicon less than 2 years from now.i  I I'm sure that Alpha engineers will make a major difference to the rate of I IA64 development (which has been absolutely abysmal to date:  without thenL Alpha influx, I doubt they'd *ever* get a lot of this stuff done), but sinceE the dates I'm using above already reflect their (rather than Intel's)wE development rate expecting anything dramatically faster would seem tod require divine intervention.   - bill   >- >- > Jack Patteeuw,   ------------------------------  % Date: Mon, 27 Aug 2001 00:24:03 -0400D- From: JF Mezei <jfmezei.spamnot@videotron.ca>F) Subject: Re: Feeling Better about Itaniump, Message-ID: <3B89CB59.ADD292AB@videotron.ca>   Bill Todd wrote:K > Unless x86-64 blows IA64 out of the water completely - a hope that may be-& > remote, but not entirely impossible.  # I do not beleive this to be likely.a  K 1- the 8086 is an old architecture. While Intel has worked wonders to bringDM this toy chip to a state where it is considered the world's fastest processorwL (according to Intel marketing), aren't there some limits  ? Seems to me likeN Intel will only capable of small incremental improvements on it now. Is that a correct interpretation ?  M 2- even if Intel might be capable of increasing the 8086's performance, it is H quite likely that Intel will take whatever marketing/pricing measures toN ensure that IA64 has its large enough market and that the 8086 is relegated toK desktop and low end servers. And with the help of microsoft, I would not benN surpsised to see new versions of "enterprise" software available only on IA64,L something which would be great to jump-start the economy since all companiesN would be forced to change their fleet of servers overnight just to be uptodate with their software.   ------------------------------  % Date: Mon, 27 Aug 2001 00:21:06 -0400o' From: "Bill Todd" <billtodd@foo.mv.com>h) Subject: Re: Feeling Better about Itaniuma( Message-ID: <9mchql$1fi$1@pyrite.mv.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:EzdFwRUb9XZh@eisner.encompasserve.org...a   ...   # > When servers across the board areu > nasty commoditiese  H Same mistaken assumption Compaq made.  There will certainly be commodityJ servers, but they'll be in the lower end of the server spectrum and mostlyH 32-bit (since IA32 systems will continue to be *far* more cost-effectiveH when adequate, and adequate they will be for most lower-end server use).  J Higher-end servers won't be 'commodities' in anything like the same sense:G they're far lower volume, often require the 64-bit processor and/or SMP J and/or robust I/O support that lower-end servers (and desktops) don't, andD hence can't profit to anything like the same degree from many of theH components whose quality is entirely adequate for the desktop or low-endH server space but not for a more enterprise-critical machine.  Higher-endK server prices *will* continue to drop for a given level of performance, buti not to commodity levels.  C Application developers would certainly like something approaching a J 'standard' application execution environment across the various higher-endI server platforms, but the hardware itself needn't be uniform at all - andiE will leave plenty of room for proprietary jockeying for advantages in?L cost-effectiveness.  Alpha would have been a perfect fit (with EV7's on-chipL glue for memory and SMP, and EV8's SMT), and Power doesn't look too bad (itsH CMP will help).  IA64 will suck, at least relatively:  it uses much more= power for a given performance level (fast single-threading ofaA highly-regular, FP-style code is its forte, which may be nice for-L supercomputing and high-end workstations but is a poor fit for servers), and' it will come late to the SMT/CMP party.C   - bill   ------------------------------  # Date: Sun, 26 Aug 2001 21:49:07 GMT4. From: Burnie M <burniem.NOSPAM@ozemail.com.au> Subject: Re: Hello !8 Message-ID: <9nriot49ji7l49tdcvlctoqkn0ed06h87r@4ax.com>   What about Compaq.club  8 (it does not seem to be a .ltd or .inc or .shop anymore)    7 On Sun, 26 Aug 2001 11:09:25 -0000, "futuredomains.org"  <info@futuredomains.org> wrote:i  8 >There are new domain names awalable on the Internet !!! >- >Compaq.ltd- >Compaq.inc- >Compaq.shop >Williams.club >Williams-f1.club  >Williams.love >Formula1.club >Ferrari-f1.club
 >Mclaren.clubt >Mclaren-f1.club >e >AND MANY MANY MORE !!!D >p	 >Info on:> >http://www.futuredomains.orgo >n >Good Luck !   ------------------------------  % Date: Mon, 27 Aug 2001 00:06:59 +0000 2 From: "futuredomains.org" <info@futuredomains.org> Subject: Hello !- Message-ID: <0GIP008819O3BS@mx.west.saic.com>e  .                                  Goodmorning !  5 There are new domain names awalable on the Internet !a   JacquesVilleneuve.club JacquesVilleneuve.love JacquesVilleneuve.amoury
 Jacques.amoura Jordan.club 
 Honda.love OliverPanis.club OliverPanis.love
 Honda.club
 Compaq.inc Compaq.shopt
 Williams.clubo Williams-f1.club
 Williams.lovel
 Formula1.clubl Ferrari-f1.clubr Mclaren.club Mclaren-f1.clubm Minardi.inch Minardi.club Prost-Peugeot.club =2E....s =2E....i AND MANY MANY MORE !!!   Info on: http://www.futuredomains.org   Good Luck !       & P.S.Dans le leanguge fran=E7ais =C3=A0   ------------------------------  % Date: Sun, 26 Aug 2001 22:53:53 +0100l From: nic <junk@127.0.0.1>0 Subject: Re: Hex dump-and-lookatit-in-themorning' Message-ID: <3B896FF1.203744@127.0.0.1>r   "David J. Dachtera" wrote: > H > Hhmmm... Maybe just a cultural thing. In American slang, "take a dump"  > is a euphemism for "defecate".  F UK as well. I'm not sure if I'll regret this or not, but I taught my 2A year old daughter to say "big dump" after she'd filled her nappy.    -- u Regards, Nic Clews (from home), nic at python dot demon dot co dot uk (play) nclews at csc dot com (work)   ------------------------------  % Date: Sun, 26 Aug 2001 20:58:29 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>e0 Subject: Re: Hex dump-and-lookatit-in-themorning' Message-ID: <3B89A945.AF89DE60@fsi.net>s  
 nic wrote: >  > "David J. Dachtera" wrote: > > J > > Hhmmm... Maybe just a cultural thing. In American slang, "take a dump"" > > is a euphemism for "defecate". > H > UK as well. I'm not sure if I'll regret this or not, but I taught my 2C > year old daughter to say "big dump" after she'd filled her nappy.i  G At one place I worked, a "big dump" consumed 2-1/2 cases of xerographic D paper (13,750 sheets, portrait quadruplex, two-sided - eight printed pages per sheet of paper).   -- c David J. Dachterah dba DJE Systemsv http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/h   ------------------------------  % Date: Sun, 26 Aug 2001 17:38:15 -0700 # From: "Tom Linden" <tom@kednos.com>vB Subject: How to delete mail messages after retrieval by POP client9 Message-ID: <CIEJLCMNHNNDLLOOGNJIIEOADCAA.tom@kednos.com>n  J on 7.3 with tcpip5.1?  Running pop server, which is accessed by Outlook on W2K.I Outlook has a switch to tell POP server to either save or delete messages  aftermF they have been retrieved, but they aren't being deleted.  How does one effect this?   ------------------------------  % Date: Sun, 26 Aug 2001 21:26:43 -040002 From: rdeininger@mindspring.com (Robert Deininger)F Subject: Re: How to delete mail messages after retrieval by POP clientL Message-ID: <rdeininger-2608012126450001@user-2ive7b8.dialup.mindspring.com>  F In article <CIEJLCMNHNNDLLOOGNJIIEOADCAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> wrote:a  L > on 7.3 with tcpip5.1?  Running pop server, which is accessed by Outlook on > W2K.K > Outlook has a switch to tell POP server to either save or delete messages  > aftersH > they have been retrieved, but they aren't being deleted.  How does one > effect this?  H I assume the messages are being moved to the wastebasket folder, but not@ deleted.  They normally get deleted when you exit interactive orB decwindows mail, but a pure POP user doesn't ever do those things.  I If you define this logical name before tcpip starts at boot time, the POP-I server will delete the messages rather than move them to the wastebasket:e  /  define/system tcpip$pop_purge_reclaim anythingb  G I don't recall whether this will get rid of messages already sitting int8 the wastebasket.  You may need to do that manually once.   -- p Robert Deininger rdeininger@mindspring.como   ------------------------------  # Date: Sun, 26 Aug 2001 20:58:02 GMTp; From: "Stuart R. Fuller" <stu@c49395-a.wodhvn1.mi.home.com>gD Subject: Re: Looking for Digital Serial Number Identication Resource0 Message-ID: <tflbm9.2qb.ln@dadsys1.fuller.local>   No, "NI" means Nashua.  K In comp.unix.tru64 D.B. Turner, islandco.com <dbturner@islandco.com> wrote: ( : NI means Northern Ireland doesn't it ?     : -- : David Turner   : We sell Alpha's & Alpha Partsb : http://www.islandco.comi : sales@islandco.com : Island Computers US Corp.h : 2700 Gregory Streetb : Savannah GA 31404) : Tel: 912 447 6622  : Fax: 912 201 0096o  2 : Peter Barone <barone1@HOME.COM> wrote in message7 : news:bYXh7.24234$qc.2808941@news1.rdc1.az.home.com... 
 :> NI63900016e :>I :> The leading 6 stands for 1996 and the 39 is the 39th work week.  Thatsy : whenL :> it was manufactured.  This is a valid serial number.  It's to old to giveJ :> you any more info.  I think the NI means it was manufactured in Nashua, : News
 :> Hampshire.n :>
 :> Regards :> Peter Baroner :> Compaq Services :>@ :> "John Fredrickson" <jafred@bellatlantic.net> wrote in message4 :> news:JCVh7.477$Ia1.113227@typhoon1.gnilink.net...4 :> > Dear Digital Equipment Corporation Aficionados, :> >H :> > Does anyone know of a resource on the web where you supply a serial : numberI :> > for a Digital product and get the model number, date of manufacture,, : etc.?r :> >K :> > I've found an old Digital Alphastation and I'd like to know more abouts : it.aK :> > It seems to be in the Alphastation 600 series box, but the front labelH : has D :> > been removed. It has two numbers on the back: the serial number : NI63800016L :> > and another number 041-56514. It also has a label on it that identifies : it< :> > as a prototype that is not for sale outside of Digital. :> > :> > Thanks in advance.) :> > :> > --p :> > John Fredricksoni :> > Washington, DCp :> > :> > :> > :> > :> :>   ------------------------------  # Date: Sun, 26 Aug 2001 23:37:41 GMTu2 From: "John Fredrickson" <jafred@bellatlantic.net>D Subject: Re: Looking for Digital Serial Number Identication Resource6 Message-ID: <9Lfi7.192$td.103954@typhoon1.gnilink.net>   Hans,   I I have yet to get the box booted up so I can work with the console or theDK OS. I attached a couple of standard non-DEC (PS2 keyboard and mouse, 15-pinrK VGS/SVGA monitor) parts up to it but I could not get it to display anythingeK on the monitor (the monitor was not detecting any video signal. I even wentcL so far as to disconnect the console keyboard and monitor and connect a VT420E to the serial ports, but again nothing was displayed at power-up. Anym suggestions?   John  < "Hans Bachner" <Hans.Bachner@altavista.net> wrote in message" news:9mb4nv.b9.1@hans.myfqdn.de...3 > John Fredrickson (jafred@bellatlantic.net) wrote:- >- > <snip>I > >I've found an old Digital Alphastation and I'd like to know more about  it.cI > >It seems to be in the Alphastation 600 series box, but the front labele has  > >been removed. > <snip> >p5 > How does the console software identify the machine?l >. > Hans.    ------------------------------  % Date: Mon, 27 Aug 2001 12:30:44 +1200 & From: A Bonaveidogo <Asena@fsc.com.fj> Subject: Node Name2 Message-ID: <01C12EF4.1865B0A0@PATRICK.FSC.COM.FJ>  & How to change a node name in Open VMS?   ------------------------------  % Date: Sun, 26 Aug 2001 21:11:01 -0500I1 From: "David J. Dachtera" <djesys.nospam@fsi.net>1 Subject: Re: Node Name' Message-ID: <3B89AC35.6D40B232@fsi.net>t   A Bonaveidogo wrote: > ( > How to change a node name in Open VMS?   If you mean the SCSNODE name:    $ MC SYSMANi PARAM USE CURRENT  PARAM SET SCSNODE "nodename" PARAM WRITE CURRENTe EXIT  
 Then, reboot.t  $ If you mean the DECnet-IV node name:   $ NC NCP DEFINE EXECUTOR NAME nodename  SET EXECUTOR STATE OFF EXIT $ @SYS$MANAGER:STARTNETo  + If you mean the DECnet-V node name, invoke:o   $ @SYS$MANAGER:NET$CONFIGr  H ...and follow the prompts. Don't deal with it much (don't have to), so I- don't know the sequence of prompts by memory.o  F If you mean the TCP/IP nodename, see the documentation for your TCP/IPG stack. My require a coordinated effort with someone else if you are noto( the one responsible for your site's DNS.   -- o David J. Dachterai dba DJE Systemst http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/h   ------------------------------  % Date: Mon, 27 Aug 2001 05:56:37 +0200i2 From: martin@radiogaga.harz.de (Martin Vorlaender) Subject: Re: Node Name; Message-ID: <3b89c4f5.524144494f47414741@radiogaga.harz.de>p  ' A Bonaveidogo (Asena@fsc.com.fj) wrote:o( > How to change a node name in Open VMS?  G Please see the OpenVMS FAQ, MGMT9. "How do I change the node name of ana OpenVMS System?"  9   The OpenVMS FAQ is archived in the following locations:r  "     http://www.openvms.compaq.com/.     ftp://rtfm.mit.edu/pub/usenet/comp.os.vms/,     comp.answers and news.answers newsgroups  ?   User-created HTML versions of the OpenVMS FAQ are located at:6       http://www.kjsl.com/vmsfaq'     http://eisner.decus.org/vms/faq.htm    cu,i   Martin -- .F                           | Martin Vorlaender  |  VMS & WNT programmer3  Cetero censeo            | work: mv@pdv-systeme.deoF  Redmondem delendam esse. |   http://www.pdv-systeme.de/users/martinv/:                           | home: martin@radiogaga.harz.de   ------------------------------  % Date: Sun, 26 Aug 2001 23:44:36 +0100. From: nic <junk@127.0.0.1>> Subject: Re: Nuts-n-bolts in News (was: Re: Nits in Slides...)) Message-ID: <3B897BD4.FFF23098@127.0.0.1>'   Bill Todd wrote:  D > > > Perhaps you're confused about Alpha's bread-and-butter market  [...]sG > Jan Vorgrueggen mentioned recently a March 2001 presentation in whicheL > VMS-related revenue was stated as being $4 billion annually and Tru64's asK > $3 billion annually.  My strong impression is that virtually all of VMS'seL > revenue is non-HPTC-related, plus at least a large chunk of Tru64's.  ThatK > leaves Alpha Linux (plus a smidgeon of Alpha *BSD), but I doubt that theygM > constitute too much of a market compared with the above $7 billion (if theyt1 > did, Compaq's revenue numbers wouldn't add up).e  H Surely by that then, speed is not the issue. If most of the VMS money isC NOT made by those wanting the fastest machines available, then theyr1 don't need speed. Or have I misread the analysis?e   > > A programmer can optimisen8 > > their code before it even hits the compiler (as if). > >tG > > I don't practice martial arts, but I believe, in Judo, you use yoursL > > oponents 'attack' as their weakness. Even if Alpha had proven advantagesJ > > over IA64, it is not unfeasible that one could change the way you workL > > with your chip to take advantage of its features. Alpha was not designedK > > as VMS's chip, VMS just happens to work quite well on it. As I've said,.F > > some kernel tweaks have been made for NUMA, I expect when the dustL > > settles, it'll be tweaked for IA64 (though your and my interpretation of > > 'tweak' may differ). > K > I'd suggest changing the word 'unfeasible' above to 'inconceivable'.  But ) > even then I'd still take issue with it.,  D Fact: 7.3 kernel has LESS [required] spinlocks, is nonpageable, lock; manager and IO performance improvements for SMP systems. MynB understanding is that these improvements were made in the light ofF customer experience and data. 7.3 has tools to gather performance dataB which can be analysed by engineering. There is no committment fromH engineering to make kernel changes, but it also doesn't mean they won't.A Past evidence shows that have though (the NUMA reference I made).a  G VMS on itanium isn't even in field test, yet you're making declarationsrH about its performance [well the implications are the 'chip' is not up toG it]. VMS could operate faster, lower OS overheads. I think you're being ) unfair writing it off before it's booted.u  K > Alpha already does have proven advantages over IA64, in their two currentsI > instantiations - save in the area of highly-regular floating-point codewC > where EPIC's approach to ILP does manage to keep up with Alpha's.t > [...]r > K > So Alpha's advantages aren't spotty - they're nearly pervasive.  As such,-M > one can't 'tweak' one's code to get around IA64's disadvantages (unless you.N > can convert all your applications to regular floating-point-intensive ones -L > something that seems likely 'unfeasible' in the example of Apache that you > present below).   D How much of the 'bread and butter' *relies* on Alpha's features, yetF would be *unable* to use Itanium's features? From the presentation youH mention above, I would hazard a guess that floating point operations areF not often required in those type of applications, well, not beyond twoF decimal points. Heck, if I were program lead, I'd tell the programmingH crew to multiply by 100, run with that, and convert back to the required; units on the display. Does that count as code optimization?i  E On the subject of Apache, I believe it is well known, or if it isn't,kG try it for yourself, that the performance of the OSU webserver is abovee that of Apache.t  
 Fast = OSU Sheep = Apache  > To further my argument. Lets say you wrote a very large memoryF application, manipulating, for arguments sake, a two dimensional arrayH of floating point numbers. As programmer in sequential operations I haveH the choice of processing row by row or column by column. Knowing how VMSC works, and how my strucure is laid out is vital to getting the best- perfomance.-  H In other words, I could cripple my application by writing it incorectly,@ and the speed of performing those floating point operations just wouldn't even enter into it   H Extrapolating to an Itanium processor, I could write an application thatD pretended there were just 32 floating point registers, and stuff theH remainder of the results in that oh-so-slow memory in huge calculations,E or, take advantage of those extra registers and even if that floatingeG point operation was slower, it would be a darn site quicker than havingt to involve off chip memory.f  D Some people [co-incidentally that use VMS systems as the developmentH platform] do this sort of programming for a living. Saving a byte or twoE in a tight loop and generally being imaginitive while writing code iss# the sort of thing I'm referring to.p  E > > Nope, I'm talking big servers. Take the Apache code base. Its nottL > > optimised for anything. ISVs typically will try to have a 'similar' codeF > > base with the necessary '.H' files. Optimised for what? OK to someH > > degree its up to the compiler writers, but they can't work miracles.   -- d Regards, Nic Clews (from home), nic at python dot demon dot co dot uk (play) nclews at csc dot com (work)   ------------------------------  % Date: Mon, 27 Aug 2001 01:45:45 -0400e' From: "Bill Todd" <billtodd@foo.mv.com>p> Subject: Re: Nuts-n-bolts in News (was: Re: Nits in Slides...)( Message-ID: <9mcmpd$5te$1@pyrite.mv.net>  K "nic" <junk@127.0.0.1> wrote in message news:3B897BD4.FFF23098@127.0.0.1...p >e > Bill Todd wrote: >hE > > > > Perhaps you're confused about Alpha's bread-and-butter market  > [...] I > > Jan Vorgrueggen mentioned recently a March 2001 presentation in whichoK > > VMS-related revenue was stated as being $4 billion annually and Tru64's  asG > > $3 billion annually.  My strong impression is that virtually all ofn VMS'stH > > revenue is non-HPTC-related, plus at least a large chunk of Tru64's. ThatH > > leaves Alpha Linux (plus a smidgeon of Alpha *BSD), but I doubt that theyJ > > constitute too much of a market compared with the above $7 billion (if they3 > > did, Compaq's revenue numbers wouldn't add up).> > J > Surely by that then, speed is not the issue. If most of the VMS money isE > NOT made by those wanting the fastest machines available, then theyi3 > don't need speed. Or have I misread the analysis?i  L You have mis-read the analysis.  Speed translates to cost-effectiveness in a> server, since the steps from uniprocessor to dual-processor toH quad-processor to 8-processor systems each entail increases in ancillaryB component costs and overall system costs.  If you can get the sameJ performance out of fewer processors (even if each processor costs somewhatJ more) your ability to field a smaller, less expensive server with the sameG performance/load capacity gives you an advantage over your competition.    ...   I > VMS on itanium isn't even in field test, yet you're making declarations J > about its performance [well the implications are the 'chip' is not up toI > it]. VMS could operate faster, lower OS overheads. I think you're being.+ > unfair writing it off before it's booted.i  I Unfortunately, Compaq eliminated the option of waiting until side-by-sideuF systems could be compared before deciding on one's long-term plans, soD people now just have to go on the best projections that can be made.  A The kinds of optimizations you're suggesting require line-by-lineeI hand-restructuring of assembly-level code - by definition well beyond the0L kinds of things the compilers should be doing normally (since the things theJ compilers do normally are the basis for the projected SPECint numbers thatI support the comparisons I've been making).  There are *very* few areas ofnH VMS where this has been done for Alpha, and expecting significantly moreL work to be done for IA64 (to make its performance more competitive with thatJ on Alpha) is not realistic (and in any event wouldn't help the performanceL of many applications unless they too were so optimized - and for that matterB in the majority of instances wouldn't help much no matter how much8 additional effort was expended, as expanded upon later).   ...u  F > How much of the 'bread and butter' *relies* on Alpha's features, yet. > would be *unable* to use Itanium's features?  G I think you still don't understand the differences very well.  The only J Merced 'feature' is its ability to execute highly-regular, single-threadedL code (the kind somewhat typical of many FP number-crunching applications andI measured by SPECfp, but decidedly atypical for most code executed on most,J servers) just as fast as the latest EV6 Alphas can (though with far higherL power consumption).  For typical server code (the kind measured by SPECint),K Merced executes at only about half the latest EV6 speed (but still with farl higher power consumption).  J When McKinley and EV7 arrive, the SPECint/SPECfp situation isn't projectedL to change much (at least in Paul DeMone's estimates, which are the only onesF I've seen) :  both improve in speed over their predecessors in similarL amounts, though McKinley's SPECint speed moves up to 70% of EV7's.  However,L EV7 introduces *major* improvements in memory bandwidth and latency (and SMPH glue) that I haven't heard of anything similar to in McKinley:  the SPECJ tests don't tend to be very sensitive to the benefits of these, but serverG applications should see them as very significant real-world performance0H improvements, so EV7 servers should have a major per-processor advantageD over McKinley servers.  (Power consumption is more equal than in theJ Merced/EV6 comparison, but since the EV7's consumption includes the memoryJ controller that is a separate chip with McKinley it should still have some advantage in that area.)  L And EV8 would have continued the increase in performance leadership with itsI SMT features (again, with nothing similar publicly projected for the IA64sF architecture, to the best of my knowledge).  For multi-threaded serverI applications, it's not unreasonable to expect that a single EV8 processorkH would have had the performance of between 2 and 3 processors of whateverL IA64 version was competing with it at the time - while using less power than even one of them.h   ...c  G > On the subject of Apache, I believe it is well known, or if it isn't,mI > try it for yourself, that the performance of the OSU webserver is abovep > that of Apache.y  G I referred to Apache only because you brought it up as an example.  TheiJ advantages Alpha has apply equally to OSU code or any other typical server> application code, so the relevance of your comment escapes me.   ...-  @ > To further my argument. Lets say you wrote a very large memoryH > application, manipulating, for arguments sake, a two dimensional array > of floating point numbers.  F Let's say you did:  are you suggesting that this would in any way be a typical server application?D  @ Oracle is a typical server application.  SAP is a typical serverK application.  Web servers of whatever flavors you prefer are typical server I applications.  There are plenty of other examples too - but none of them,CL AFAIK, make heavy use of the kind of code you're offering above as something! you seem to feel may be relevant.   @ Server code (and typical application code in general, aside fromK number-crunching code) is fairly irregular:  frequent branches that may notsE predict (or even profile) very effectively, and most importantly high H degrees of concurrency (multi-threading, or equivalent) with often shortI instruction sequences between thread 'wait' points and very irregular and J typically short code sequences between references to often-uncached memoryL contents.  IA64 just isn't nearly as efficient at executing such code as theK better current out-of-order processors - and would fall even farther behindp a design like EV8.   ...   J > Extrapolating to an Itanium processor, I could write an application thatF > pretended there were just 32 floating point registers, and stuff theJ > remainder of the results in that oh-so-slow memory in huge calculations,G > or, take advantage of those extra registers and even if that floatingoI > point operation was slower, it would be a darn site quicker than havingw > to involve off chip memory.a  G This example does not seem consistent with having understood what I wasbJ saying.  And in any event this is the kind of thing the compiler should beB doing for you (and is expected to be doing by the SPEC performance
 projections).k   > F > Some people [co-incidentally that use VMS systems as the developmentJ > platform] do this sort of programming for a living. Saving a byte or twoG > in a tight loop and generally being imaginitive while writing code isu% > the sort of thing I'm referring to.   J Saving a byte or two in a loop is the kind of thing I did 20+ years ago onF the PDP-11, and (in some ways to my sorrow) has very little to do withJ optimizing code for current architectures.  Big wins can still be found inG algorithm optimization, but bit-level twiddling is to a large degree notK longer an important skill, save for the additional insights it can give youoH into algorithms (so you don't write something ridiculously inefficient).C Virtually nobody, including the VMS engineers, devotes much time tosG lowest-level code *optimization* in 99.99% of their code any more, bothsI because compilers have gotten very good at that kind of thing and becauselJ newer ISAs have added a great deal more complexity to optimization at thatL level (complexity of kinds that compilers handle far more easily than humansJ do, which is almost the exact opposite of the situation back before 1980 -7 at least for the more competent instances of 'humans')..  L If you still don't understand why 'optimizating for the IA64 platform' won'tI help much of any, check out the infamous alpha_ia64.pdf paper from Compaq-F and Paul DeMone's various write-ups at realworldtech.com, which likelyL explain the situation better than I have managed to (especially this late atF night - hope I didn't say anything excessively silly in the process of trying).   - bill   ------------------------------   Date: 26 Aug 2001 21:40:47 GMT' From: dashw459@aol.comeatspam (Doug W.) @ Subject: Re: RWMBX - What to do, What to do! Help me if you can.9 Message-ID: <20010826174047.01577.00004268@mb-ch.aol.com>    JF Mezei wrote:   K << Seems to me that RWMBX is just a thorttling mechanism for processes that  writeXL to mailboxes. Does RWMBX cause process context drawbacks that are much worse than a process going to LEF ?N  >>N  F I suppose you could define throttling this way.  You might also defineL throttling as slowing down something that could occur to gain some benefit. B There is nothing like this for a mailbox, its completely realtime.  L Newer system services (sometimes said to replace mbxs) do offer throttling. N Msg reception is stopped until the reader drains the buffer to some predefinedI level.  When the buffer is drained, senders resume and have a much betteryF chance of getting a msg (messages) thru before being context switched.  O Don't know how RWMBX compares to LEF in efficiency.  However throttling the wayRN I have defined it, offers a large increase in thruput on a busy system.  It is/ however not realtime, but it can be very close.c   ------------------------------  % Date: Sun, 26 Aug 2001 22:44:35 +0200o, From: Didier Morandi <Didier.Morandi@gmx.ch>% Subject: Re: V5.5-2 Password Recoveryt& Message-ID: <3B895FB3.83250BF5@gmx.ch>   Malcolm Dunnett wrote: >  ../..m > I used "stole"L > to suggest that there was no public acknowledgement of how much NT owes to > VMS in terms of "heritage".A  ( Please post references for your sources.  0 > I suspect from your email address that EnglishM > may not be your first language, so perhaps you're not familiar with the use < > of "stole" in this context, but it's quite a common usage.   You suspected well :-)   D.  B ==================================================================1 Poor Consultancy (un)limited and Poor ltd English-   ------------------------------  % Date: Sun, 26 Aug 2001 22:51:10 +0200n, From: Didier Morandi <Didier.Morandi@gmx.ch>% Subject: Re: V5.5-2 Password Recovery-& Message-ID: <3B89613D.6A5A0505@gmx.ch>   Paul Sture wrote:  > E > In article <hz5FWuprFW4d@malvm5.mala.bc.ca>, Malcolm Dunnett wrote:  > >oI > >    I suppose, assuming such an ACL exists, but that's not part of theaH > > "out of the box" VMS setup - whereas recording the date the passwordL > > was last changed by authorize ( or $setuai ) is. Wouldn't all the normalI > > things that write the UAF (such as every login) trigger the ACL also?eJ > > With all that noise you'd have to be pretty sure what you were lookingI > > for ( or have a good analysis tool ) to spot the suspicious activity.t > >i > P > No, LOGIN doesn't trigger alarms for SYSUAF in this way. Use of AUTHORIZE doesP > (and it's useful to see who is changing passwords by AUTHORIZE rather than SETA > PASSWORD. But you are correct, it's not there "out of the box".n  D Paul, I think Malcolm was talking of an access=R+W+S+F ACL, which ofG course is triggered each time any VMS program (loginout.exe and others)t open the file in R+W mode.   D.   ------------------------------   End of INFO-VAX 2001.475 ************************A64, it is not unfeasible that one could change the way you workL > > with your chip to take advantage of its features. Alpha was not designedK > > as VMS's chip, VMS just happens to work quite well on it. As I've said,.F > > some kernel tweaks have been made for NUMA, I expect w