1 INFO-VAX	Sun, 26 Aug 2001	Volume 2001 : Issue 474       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 ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update   Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium Re: GNU screen for AXP/VMS Hello ! ; Re: Looking for Digital Serial Number Identication Resource ; RE: Looking for Digital Serial Number Identication Resource ; RE: Looking for Digital Serial Number Identication Resource  Re: V5.5-2 Password Recovery Re: V5.5-2 Password Recovery Re: V5.5-2 Password Recovery Re: V5.5-2 Password Recovery, RE: VMS high reliability needed by Air Force: Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?  F ----------------------------------------------------------------------  % Date: Sun, 26 Aug 2001 03:15:10 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> 2 Subject: Re: Conference: CETS-2001 Detailed Update( Message-ID: <9ma7l0$5ot$1@pyrite.mv.net>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message 2 news:yoSh7.1028$tS5.909512@typhoon2.gnilink.net...4 > "Bill Todd" <billtodd@foo.mv.com> wrote in message$ > news:9m8q7m$o56$1@pyrite.mv.net...C > > Of course, if you instead choose one of the mature and reliable 
 non-CompaqL > > Unix platforms out there, or something similarly mature and reliable butL > > non-Unixy from IBM, this straw-man argument collapses:  there really areJ > > dependability differences among vendors, just as there are differences > among J > > OSs, and the safety of your 'bet' heavily depends on such differences. > L > Are you suggesting AIX or Linux is as robust and as mature as OpenVMS when4 > it comes to being a solid enterprise class server?  J Though what you've quoted above seems pretty clear to me, I'll try to find< another set of words that you may find easier to understand:  E The 'safety' of betting one's business on an OS rests not only on the H characteristics of the OS but also on the characteristics of the vendor.L VMS may be at just about the top of the OS dependability list, but Compaq isK at just about the bottom of the (major) vendor dependability list, at least 0 for non-Wintel (and perhaps non-Tandem) systems.  F So a much more dependable vendor, even with a slightly less dependableJ system, may overall be a much safer bet.  There are several such much moreD dependable vendors (including IBM, Sun, and HP), and they offer onlyH slightly less dependable systems:  z-Series, i-Series, and p-Series fromG IBM, Solaris from Sun, and HP/UX from HP, all of which are considerably I closer to VMS than to Windows in dependability (hence my observation that K your suggesting Windows as the alternative to VMS was somewhat misleading).    - bill   ------------------------------  % Date: Sun, 26 Aug 2001 03:26:43 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> 2 Subject: Re: Conference: CETS-2001 Detailed Update( Message-ID: <9ma8al$6ap$1@pyrite.mv.net>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message 2 news:ueTh7.1044$tS5.948324@typhoon2.gnilink.net...   ...   $ > IMHO debates about esoteric issuesK > around the fine points of chip architectures miss the point.  Technically J > this is a doable transition.  The questions really are related to Compaq asI > partner.  IMO the test to see how firm a public commitment Compaq makes * > about certain aspects of the conversion.  L It is hard to imagine any firmer public statements of commitment than CompaqF made about its long-term commitments to Alpha.  If you don't thereforeI understand that Compaq's public commitments are utterly worthless, you're ! completely divorced from reality.    ...   H > 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 - either K > though elegant engineering or brute force (n-way processor systems).  The L > real issues IMO are the non-technical issues that relate to doing business > with Compaq.  L Exactly.  But you don't seem to understand that these 'esoteric aspects' areK very relevant to such issues of doing business with Compaq - in particular,  issues of trust.  I That's because Compaq itself made these 'fine points' issues when it lied L about Alpha's performance potential compared with IA64's.  It's these *lies*I that are important to most people perhaps more than even a factor of 2 in C per-processor performance (though that's not exactly chopped liver, L either) - but to establish that they were in fact lies, one must examine theL details of the chip architectures to see why Compaq's assertions were wholly
 unbelievable.   L But while on the subject of performance, in later posts you've asserted thatK performance isn't an issue because Compaq will be able to substitute 2 or 3 K IA64 processors for each Alpha chip.  That seems a fairly naive suggestion, B since the difference in cost between building a uniprocessor and aL dual-processor system, or between a dual-processor and a 4-processor system,D is usually considerably greater than the mere cost of the additionalF processors (i.e., SMP scaling increases the expense of the surroundingD hardware as well - especially when the IA64 chips don't have as much% built-in SMP glue as, say, EV7 does).   K You've said that a $500 - $1000 difference (should extra IA64 processors be J required to compensate for a loss in performance) in the price of a serverH system isn't important, and I agree.  But this difference is at least asJ much as the per-processor development-cost overhead that Compaq complainedK was so burdensome that it couldn't afford to continue developing Alpha (and H part of the argument I've used to assert that this was yet another lie).   - bill   ------------------------------  % Date: Sun, 26 Aug 2001 03:28:56 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> 2 Subject: Re: Conference: CETS-2001 Detailed Update( Message-ID: <9ma8f1$6as$1@pyrite.mv.net>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message 0 news:KiTh7.295$Ia1.66096@typhoon1.gnilink.net...   ...   K > I am firm believer that Compaq's (Digital's) most painful wounds are self K > inflicted.  I do not claim to be expert on other platforms an but haven't J > both IBM and SUN put their customers through major hardware and software. > changes that forced source level recompiles?  J I'm no expert either, but my strong impression is that executables createdK to run on S/360 30+ years ago will run, with today's native performance, on K todays mainframe z-Series platforms, and that executables created to run on K early AS/400 systems (and possibly even back to S/38 systems from the early K '80s) will run untranslated (and perhaps also with native performance - I'm F unsure of the details of AS/400's 'microarchitecture' in this area) onK today's i(?)-Series systems.  And when AIX - p(?)-Series - grew to a 64-bit D system, I believe their 32-bit executables continued to run as well.  J Since I'm even less familiar with Sun's record in this area, I'll leave itC to others to comment there - save to note that Sun's 64-bit Solaris ) environment executes 32-bit applications.       If so technically how are they* > any less reliable as a business partner?  L Because of the *way* in which they handled such transitions.  Even MicrosoftK and Intel (which I'm not otherwise presuming to compare with VMS and Alpha) I have managed to keep early-1980s software running - natively - on current E platforms right up through Win98 (and possibly through 'ME' - I'm not F acquainted with it).  NT had (and Win2K has) more restrictions, but itG *supplemented* rather than *replaced* DOS's descendents.  XP is finally I (IIRC) ringing down the curtain on real-mode DOS programs, but only many, J many years after the development of and need for such programs has ceased.  "  I think the answer is technicallyJ > they aren't any less reliable but the did it with a lot more finesse and > didn't self-inflict wounds...   H I think you meant that Compaq's competitors did it with more finesse and fewer self-inflicted wounds...  G Compaq is less reliable (I'd use the word dependable, but close enough) F because Compaq doesn't seem to take the wounds it's dealing out to itsL customers into account in its decisions.  Or perhaps it's just as unaware ofG the wounds it's giving them as it seems to be of the wounds it's giving J itself.  In any event, it seems to make decisions in a vacuum (and withoutG such consideration, nor any feeling of obligation to commitments it has K made) and then implement them no matter what - to a degree that's decidedly < *not* the same as other major vendors like IBM, Sun, and HP.  G People have already pointed out the indecent haste of the Alpha-to-IA64 K migration compared with the VAX-to-Alpha migration, as well as the contrast I between the obvious major benefits of the latter and the lack of any such A obvious major benefits (and indeed the expectation of performance J down-sides) of the former.  It would have been infinitely more sensible toF continue developing EV8 while adding IA64 to VMS's and Tru64's list ofF supported hardware and *then* see what the relative demand for the twoF hardware platforms was - and I suspect most of the companies that some? people feel are more 'dependable' would have done exactly that.    - bill   ------------------------------  # Date: Sun, 26 Aug 2001 10:12:40 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update8 Message-ID: <sY3i7.1836$Ia1.330432@typhoon1.gnilink.net>  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9ma8al$6ap$1@pyrite.mv.net...  I > But while on the subject of performance, in later posts you've asserted  thatK > performance isn't an issue because Compaq will be able to substitute 2 or  3 A > IA64 processors for each Alpha chip.  That seems a fairly naive  suggestion, D > since the difference in cost between building a uniprocessor and aF > dual-processor system, or between a dual-processor and a 4-processor system, F > is usually considerably greater than the mere cost of the additionalH > processors (i.e., SMP scaling increases the expense of the surroundingF > hardware as well - especially when the IA64 chips don't have as much' > built-in SMP glue as, say, EV7 does).   K Naive?  The statement makes me wonder if anything you say is constrained by  facts...  7 http://www.cdw.com/shop/products/default.asp?EDC=250574   H ...in the Intel world the the typical cost preminum for a dual processorI system board is about $400.  A dual processor systemboard and another IPF G chip at volume pricing would be about the same as the extra cost of the  Alpha chip with overhead.   J > You've said that a $500 - $1000 difference (should extra IA64 processors beL > required to compensate for a loss in performance) in the price of a serverJ > system isn't important, and I agree.  But this difference is at least asL > much as the per-processor development-cost overhead that Compaq complainedH > was so burdensome that it couldn't afford to continue developing Alpha (andJ > part of the argument I've used to assert that this was yet another lie).  K This statement really makes me wonder if there any objective examination of I the data.  The extra cost of dual processor systems almost all components L and not development costs on the scale of chip design.  The problem with theK extra cost of the Alpha is it came from 400-500 million dollars per year in L overhead.  It doesn't cost anywhere near 400-500 million dollars per year inH overhead to develop a dual processor motherboards.  The risk from havingK sunk development cost of 400-500 million dollars per year is very different - than the cost of purchasing extra components.   I As I said Compaq has penance it must do on the business partner front but K Bill you just appear to be lashing out at everything.  Those of us who were L around in mid-1980's when Digital killed the followed to the DECsystem-10/20I saw this happen.  This was the ECL Jupiter project.  There were folks who K had gone to bat for Digital with their management.  In one case I know they L had actually taped out on the machine floor where the Jupiters were going toK go and had effectively pre-ordered them.  After the cancellation there were H folks who dammed everything about Digital, and for them its inferior VAXL replacements for the DECsystem-10/20.  Rational discussion became impossibleG because Digital could do no right.  Even in cases where VMS was clearly F better than Tops-10/20 they wouldn't hear of it.  It is understandableL reaction if someone went had made a strong commitment and had the rug pulledH out from under them with a major coversion now required.  For the recordJ Digital retained 80 percent of those DECsystem-10/20 customers but most of6 those other 20 percent became Digital haters for life.  K The thing I don't understand about this one is while Compaq is changing the E hardware they aren't changing the OS.  As being someone who had to go E through a painful platform switch of RSTS to VAX, where in my case my J software that ran well without virtual memory but had to be redesigned forL VMS with no performance gain, this conversion is a snap if Compaq deals withK certain business issues.  As someone who has had to do a close, but not the K same, platform switch IMO anyone would be nuts to do it just because Compaq J lied them.  One has lead a sheltered life in this industry if they haven't= gone through a "just kidding" technology shift from a vendor.   L REMEMBER I BELIEVE COMPAQ HAS A LOT TO ANSWER FOR AT THIS POINT AND NEEDS TOF DO REAL PENANCE AS A BUSINESS PARTNER.  For example if Compaq tries inL anyway to recover development costs through license transfer games then theyA should be shot.  But we don't know yet and I willing to listen...    ------------------------------  # Date: Sun, 26 Aug 2001 10:41:30 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update8 Message-ID: <un4i7.1903$Ia1.338158@typhoon1.gnilink.net>  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9ma8f1$6as$1@pyrite.mv.net...  L > I'm no expert either, but my strong impression is that executables createdJ > to run on S/360 30+ years ago will run, with today's native performance, onJ > todays mainframe z-Series platforms, and that executables created to run onG > early AS/400 systems (and possibly even back to S/38 systems from the  early I > '80s) will run untranslated (and perhaps also with native performance -  I'm H > unsure of the details of AS/400's 'microarchitecture' in this area) onF > today's i(?)-Series systems.  And when AIX - p(?)-Series - grew to a 64-bitF > system, I believe their 32-bit executables continued to run as well.  G If memory serves me the transition from System 3 -> System 36 -> System G 38 -> AS/400 was not without quirks and did require notable source code  changes   L > Since I'm even less familiar with Sun's record in this area, I'll leave itE > to others to comment there - save to note that Sun's 64-bit Solaris + > environment executes 32-bit applications.   G There was a major OS switch in Sun's history where they branched on the K flavor of Unix.  I know Sun customers who were not happy about this feeling L the had been forced to make a switch they did not like but needed to keep up# with Sun was heading in the future.   D > Because of the *way* in which they handled such transitions.  Even	 Microsoft F > and Intel (which I'm not otherwise presuming to compare with VMS and Alpha)K > have managed to keep early-1980s software running - natively - on current G > platforms right up through Win98 (and possibly through 'ME' - I'm not H > acquainted with it).  NT had (and Win2K has) more restrictions, but itI > *supplemented* rather than *replaced* DOS's descendents.  XP is finally0K > (IIRC) ringing down the curtain on real-mode DOS programs, but only many,eL > many years after the development of and need for such programs has ceased.  J Bill boy have you had  little experience with Microsoft.  Yes what you sayG is true if you look at the kernel level but if you have ever dealt with0H Microsoft at the applications development level Microsoft is the king ofL "just kidding" technical shifts (lies as you would call them) in the 4 yearsH I have been using Microsoft development tools they have come out with noI less than 5 data interfaces.  Think of it like 5 different flavors of RMSrL where they are slightly and insidiously incompatible.  Basically you need to@ move to the flavor of the quarter data interface because key newL functionality isn't added to the older ones. Microsoft has zero problem withG dead ending a API because of lack of market acceptance or because it isnL easier to produce a new API than fix the old one.  If you bet on a Microsoft! API you really are taking a risk.P  K Additionally when you get above the kernel to the DLL (RTL) level Microsoft J breaks applications all over the place.  It is known as DLL hell.  You canH install a new application on Windows and have the old application break.G This is not just sloppy 3rd party products.  For example if you installmK Microsoft Outlook 2000 on a system running Microsoft Access 97 key featuresiK of Access will cease working.  It is because, for reasons only known to theIL idiots at Microsoft, they replaced system DLL's with the same version numberK that were incompatible with the older software.  Microsoft has consistently@
 done this.  F Maybe some nitty gritty exposure to other conversions and the businessL habits of other manufactures might cause one to rethink Compaq's behavior...   ------------------------------    Date: 26 Aug 2001 07:09:33 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)n2 Subject: Re: Conference: CETS-2001 Detailed Update3 Message-ID: <TRXvRPfOKbnn@eisner.encompasserve.org>   o In article <EdNHw0aJZJ1l@eisner.encompasserve.org>, kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow) writes:t  N > One question I've had from the beginning is what it will cost us, the users,L > to convert? Particularly with software licenses, which these days can costO > more than the hardware. Will my license transfer from Alpha to IPF ***WITHOUTeN > COST***? I already spent lots of money to convert VAX licences to Alpha. NFWN > will customers pay again, especially when this conversion doesn't buy us the, > huge performance increases that Alpha did.  A If a conversion will not buy you a performance increase you need,h8 you should stick with Alpha !  The same is true for VAX.   ------------------------------  % Date: Sun, 26 Aug 2001 08:58:08 -0400e+ From: "Main, Kerry" <Kerry.Main@compaq.com>e2 Subject: RE: Conference: CETS-2001 Detailed UpdateR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4D495F3@kaoexc01.americas.cpqcorp.net>   JF -  L >>> And since CA is currently under close scrutiny of shareholders, it wouldK not be seen as very good for CA to start spending on a VMS port to IA64 nowtI if the remaining customer base won't start converting for another 4 years G and especially if customers will resist migration from Alpha as long as  possible.>>>  : As a fyi, CA did make a statement on this Alpha-IPF port.   
 Reference:= http://www.compaq.com/hps/ipf-enterprise/customer_quotes.html"D "Computer Associates International, Inc., Russ Artzt, Executive ViceL President, Research and Development:    "The decision by Compaq and Intel toD collaborate on a single 64-bit platform is a good signal to ComputerL Associates and our customers. CA's partnership with Compaq spans every levelB of the enterprise, from iPAQ Pocket PCs to the largest clusters ofJ high-performance multiprocessor systems. A unified processor strategy willH speed our collaborations to create solutions that address customer needs throughout an enterprise..  I "Customers of CA's Infrastructure Management, Information Management, andeF Process Management products will benefit from Compaq's single compilerK strategy through shorter product enhancement cycles and streamlined supporteH for CA solutions on all Compaq platforms. CA will also work closely withJ Compaq to assure that the migration from high-performance Alpha systems toD Itanium and McKinley-based systems will be smooth and trouble-free."  J And by the way, while I know some folks have had some issues with CA, I do) feel they are trying improve this image. c   On the OpenVMS side, check out:p) http://ca.com/solutions/platform/openvms/h6 http://ca.com/solutions/platform/openvms/promotion.htm   Regards,  
 Kerry Main Senior Consultanto Compaq Canada Corp.  Professional Servicese Voice: 613-592-4660t Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----4 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca] Sent: August 26, 2001 12:00 AM To: Info-VAX@Mvb.Saic.Comi2 Subject: Re: Conference: CETS-2001 Detailed Update     Bob Kaplow wrote:rG > One question I've had from the beginning is what it will cost us, thea users,L > to convert? Particularly with software licenses, which these days can costD > more than the hardware. Will my license transfer from Alpha to IPF
 ***WITHOUT
 > COST***?  J This goes beyond Compaq though. Consider a big company such as CA. BecauseJ Compaq isn't marketing VMS, CA has to view the market for its VMS software as) a closed one for existing customers only.o  J But if CA spends money to port a piece of software, it will expect returnsG within a certain number of years as dictated by Wall Street Casino. Anda sinceuJ CA is currently under close scrutiny of shareholders, it would not be seen asC very good for CA to start spending on a VMS port to IA64 now if ther	 remainingpJ customer base won't start converting for another 4 years and especially if? customers will resist migration from Alpha as long as possible.e  H And now, you would want that port to be free to customers ? How would CA costI justify the costs of porting the software to its shareholders if it can't  seet( short term revenus to pay for the port ?  I And it is a vicious circle: the more software vendors will charge for the I switch of licences, the more customers will delay the port. The more they18 delay, the harder it is for CA to cost justify the port.   ------------------------------    Date: 26 Aug 2001 08:20:05 -05009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow)e2 Subject: Re: Conference: CETS-2001 Detailed Update3 Message-ID: <4P$sE1$q7aqV@eisner.encompasserve.org>   R In article <9ma8al$6ap$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes:N > It is hard to imagine any firmer public statements of commitment than CompaqH > made about its long-term commitments to Alpha.  If you don't thereforeK > understand that Compaq's public commitments are utterly worthless, you'reo# > completely divorced from reality.d  K I'd like to see written guarantees with financial penalties attached. Let'saK see Compaq REALLY bet their business on ALpha to IPF. Mikie, put your moneya where your mouth is.  K > That's because Compaq itself made these 'fine points' issues when it liedaN > about Alpha's performance potential compared with IA64's.  It's these *lies*K > that are important to most people perhaps more than even a factor of 2 iniE > per-processor performance (though that's not exactly chopped liver,tN > either) - but to establish that they were in fact lies, one must examine theN > details of the chip architectures to see why Compaq's assertions were wholly > unbelievable.b  J Which lies. The one several years ago when they told us that Alpha will beH better than IA64? Or the one now where they tell us that IA64 would haveK soon surpassed Alpha. From what I heard from folks INSIDE EV8, the priginala= statements are still accurate, and the recent ones are bogus.s  N > But while on the subject of performance, in later posts you've asserted thatM > performance isn't an issue because Compaq will be able to substitute 2 or 3PM > IA64 processors for each Alpha chip.  That seems a fairly naive suggestion,lD > since the difference in cost between building a uniprocessor and aN > dual-processor system, or between a dual-processor and a 4-processor system,F > is usually considerably greater than the mere cost of the additionalH > processors (i.e., SMP scaling increases the expense of the surroundingF > hardware as well - especially when the IA64 chips don't have as much' > built-in SMP glue as, say, EV7 does).n > M > You've said that a $500 - $1000 difference (should extra IA64 processors betL > required to compensate for a loss in performance) in the price of a serverJ > system isn't important, and I agree.  But this difference is at least asL > much as the per-processor development-cost overhead that Compaq complainedM > was so burdensome that it couldn't afford to continue developing Alpha (andnJ > part of the argument I've used to assert that this was yet another lie).  L Many applications just don't decompose into SMP threads. Having 30 IPF chipsK instead of 10 much faster Alpha chips just doesn't do any good if I've only- got 10 threads to run.  J I can't believe the DOJ or FTC or whomever regulates monopolies like IntelJ is allowing them to bury Alpha to get rid of the competiton. It's obscene.   ------------------------------    Date: 26 Aug 2001 08:25:32 -05009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow) 2 Subject: Re: Conference: CETS-2001 Detailed Update3 Message-ID: <uo$2ZckA3OHi@eisner.encompasserve.org>d  c In article <TRXvRPfOKbnn@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:oq > In article <EdNHw0aJZJ1l@eisner.encompasserve.org>, kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow) writes:r > O >> One question I've had from the beginning is what it will cost us, the users,aM >> to convert? Particularly with software licenses, which these days can costlP >> more than the hardware. Will my license transfer from Alpha to IPF ***WITHOUTO >> COST***? I already spent lots of money to convert VAX licences to Alpha. NFWrO >> will customers pay again, especially when this conversion doesn't buy us thep- >> huge performance increases that Alpha did.i > C > If a conversion will not buy you a performance increase you need, : > you should stick with Alpha !  The same is true for VAX.    L I'd love to. When and where can I buy the Alpha EV8 Marvel box? The one withJ 3x the CPU performance and 4x CPU count than the one we bought a year ago.   ------------------------------    Date: 26 Aug 2001 08:23:30 -05009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow)a2 Subject: Re: Conference: CETS-2001 Detailed Update3 Message-ID: <ycCUWUCY1c9k@eisner.encompasserve.org>   a In article <sY3i7.1836$Ia1.330432@typhoon1.gnilink.net>, "Jeff Killeen" <Jeff@IDM-IO.com> writes:oJ > ...in the Intel world the the typical cost preminum for a dual processorK > system board is about $400.  A dual processor systemboard and another IPFaI > chip at volume pricing would be about the same as the extra cost of theh > Alpha chip with overhead.(  K Is that dual processor board engineered like one of my Wildfire CPU boards.mH or like the PC I bought a few years back at Best Buy? Is it up to 24x365 reliability?   ------------------------------  % Date: Sun, 26 Aug 2001 09:33:45 -0400h+ From: "Main, Kerry" <Kerry.Main@compaq.com>t2 Subject: RE: Conference: CETS-2001 Detailed UpdateR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4D495F2@kaoexc01.americas.cpqcorp.net>   Tim,  G >>> You can say what you want about IBM and Sun (I'm no fan of Sun, theaJ SPARC, or Solaris) or IBM (I'm ok with them), but IT Managers can at leastG really believe that neither of those two companies is going to abruptlyrJ change course or suddenly ditch a critical component of the solutions they provide to customers.>>>  C Do you mean like what when IBM abruptly dropped NT on the PowerPC?  0 http://www.zdnet.com/eweek/news/1216/17amot.html? http://www.microsoft.com/PressPass/press/1997/Feb97/PowerPr.asprL Many seem to think it was only Alpha that dropped out of the NT market - IBMJ and Motorola(and MIPS) were the first to make that decision to drop NT for their RISC platforms ...  H 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.htmlsH " The reasons for IBM's slow retreat is tied to a shrinking market, saidK analysts. Had Apple continued to allow Macintosh clones to be produced, theo$ outlook might have been different.."  I One can say what they want about the Compaq decision (good, bad or ugly),lJ but they should also consider that other companies like IBM have also made( decisions like this in the past as well.   Regards,  
 Kerry Main Senior Consultanto Compaq Canada Corp.a Professional Servicesv Voice: 613-592-4660  Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----& From: mooney@dogbert.cc.ndsu.NoDak.edu) [mailto:mooney@dogbert.cc.ndsu.NoDak.edu]  Sent: August 25, 2001 3:11 PMv To: Info-VAX@Mvb.Saic.Comh2 Subject: Re: Conference: CETS-2001 Detailed Update    8 In article <41Ph7.1114$A83.489040@typhoon1.gnilink.net>,% Jeff Killeen <Jeff@IDM-IO.com> wrote:    J > In the end I want to know that Compaq will deliver systems with the same orK > better performance for the same of less cost.  I don't care if they do itt > with 1, 2, or 4 chips...   Jeff-m  F You made some interesting points, and although I'm a fan of the Alpha,E overall I agree with your statement that it's the total solution thatf matters.  E The problem is that Compaq has now changed directions enough times in K the last few years that people are really questioning whether *any* currentcJ enterprise product (or solution) from Compaq has long-term viability.  WhyF deploy a solution that involves OpenVMS or Tru64 on any chip, when theG company delivering the solution may end the long-term viability of thatN solution in a couple years?S  I We both know that superior technology is rarely the deciding factor (i.e.oD inferior technology often outlasts and eventually kills off superiorI technology for various reasons), so when companies like IBM and Sun offer-I a competing solution, why would any enterprise IT Manager choose Compaq'sfG solution, these days?  You can say what you want about IBM and Sun (I'm-G no fan of Sun, the SPARC, or Solaris) or IBM (I'm ok with them), but IT@H Managers can at least really believe that neither of those two companiesI is going to abruptly change course or suddenly ditch a critical componento+ of the solutions they provide to customers.d  D I've been a fan of Digital products for a few years, and I liked the	 directiontI I saw Tru64 UNIX going in the last year -- additional market penetration, J which improves app availability.  It was hard for me to write the previousC two paragraphs, but even fans of Digital's and now Compaq's product0	 offeringsr- have to be asking themselves, "What's next?".r  G As a side note, one of the trade rags that I read recently rumored thateI a precipitous drop in sales of Alpha systems after the omega announcementsI was likely the final nail in the coffin for Midwest Systems, which closednK its doors recently. The current economy certainly was the major factor, but'H the uncertainty with Compaq is a big one too.  Customers, even customersD that look, are having a hard time finding a reason to buy enterpriseH solutions from Compaq, when the solution-provider's committment to those solutions is questionable.   Timo --  H Tim Mooney                              mooney@dogbert.cc.ndsu.NoDak.edu> Information Technology Services         (701) 231-1076 (Voice)< Room 242-J6, IACC Building              (701) 231-8541 (Fax)3 North Dakota State University, Fargo, ND 58105-5164i   ------------------------------  % Date: Sun, 26 Aug 2001 11:00:48 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>p2 Subject: Re: Conference: CETS-2001 Detailed Update& Message-ID: <3B891D30.8C3D651@fsi.net>   Larry Kilgallen wrote: > q > In article <EdNHw0aJZJ1l@eisner.encompasserve.org>, kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow) writes:l > P > > One question I've had from the beginning is what it will cost us, the users,N > > to convert? Particularly with software licenses, which these days can costQ > > more than the hardware. Will my license transfer from Alpha to IPF ***WITHOUTrP > > COST***? I already spent lots of money to convert VAX licences to Alpha. NFWP > > will customers pay again, especially when this conversion doesn't buy us the. > > huge performance increases that Alpha did. > C > If a conversion will not buy you a performance increase you need,o > you should stick with Alpha !t  > Great! So, Alpha *WILL* live forever! That's *WONDERFUL* news!   >  The same is true for VAX.  H ...and we can still get next generation VAXes??!! That's wonderful too!!  @ Gee - and I thought those were EOL'd platforms! I must have been misinformed.   -- r David J. Dachteras dba DJE Systemsh http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/P   ------------------------------  % Date: Sun, 26 Aug 2001 13:24:25 -0400n' From: "Bill Todd" <billtodd@foo.mv.com>b2 Subject: Re: Conference: CETS-2001 Detailed Update( Message-ID: <9mbbba$sbt$1@pyrite.mv.net>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messaget2 news:sY3i7.1836$Ia1.330432@typhoon1.gnilink.net... >s4 > "Bill Todd" <billtodd@foo.mv.com> wrote in message$ > news:9ma8al$6ap$1@pyrite.mv.net... > K > > But while on the subject of performance, in later posts you've assertedi > thatJ > > performance isn't an issue because Compaq will be able to substitute 2 or > 3 C > > IA64 processors for each Alpha chip.  That seems a fairly naivel
 > suggestion,MF > > since the difference in cost between building a uniprocessor and aH > > dual-processor system, or between a dual-processor and a 4-processor	 > system,eH > > is usually considerably greater than the mere cost of the additionalJ > > processors (i.e., SMP scaling increases the expense of the surroundingH > > hardware as well - especially when the IA64 chips don't have as much) > > built-in SMP glue as, say, EV7 does).c ><J > Naive?  The statement makes me wonder if anything you say is constrained by
 > facts... >t9 > http://www.cdw.com/shop/products/default.asp?EDC=250574i >iJ > ...in the Intel world the the typical cost preminum for a dual processorK > system board is about $400.  A dual processor systemboard and another IPFfI > chip at volume pricing would be about the same as the extra cost of theo > Alpha chip with overhead.N  G Since you've just admitted (complete with corroborating example) that a F dual-processor motherboard (without processors) costs $400 more than aE uniprocessor motherboard (without processor), exactly what part of mytL statement that the surrounding hardware for an SMP system costs more (to addI to the cost of the additional processors) are you debating?  I'll refraincJ (with some difficulty) from commenting on your own competence, but suggest# you withdraw your comments on mine.e  D And the step in cost of ancillary hardware from 2 to 4 processors isH typically a larger one, and the step from 4 to 8 larger yet.  Which alsoK ignores the question of exactly how much cheaper than Alpha an IA64 will ineJ fact turn out to be, and how much vigorous competition would have affectedE that differential cost (by significantly increasing Alpha volumes andA- possibly noticeably decreasing IA64 volumes).    >eL > > You've said that a $500 - $1000 difference (should extra IA64 processors > beG > > required to compensate for a loss in performance) in the price of aa serverL > > system isn't important, and I agree.  But this difference is at least asC > > much as the per-processor development-cost overhead that Compaqo
 complainedJ > > was so burdensome that it couldn't afford to continue developing Alpha > (andL > > part of the argument I've used to assert that this was yet another lie). >eJ > This statement really makes me wonder if there any objective examination ofK > the data.  The extra cost of dual processor systems almost all components 8 > and not development costs on the scale of chip design.  E Exactly how would you like to differentiate between added cost due tosG development and added cost due to the additional components required tooH compensate for decreased per-component performance?  (I do so below, but$ it's not to the latter's advantage.)     The problem with theJ > extra cost of the Alpha is it came from 400-500 million dollars per year in > overhead.   H ZZZTT!  Wrong answer!  Even Winkler stated that the annual cost was onlyJ $300 million, Terry (another individual with some reason to lean toward anJ overestimate) pegged it at $250 million, and eetimes (which has no obviousH axe to grind) estimated it at $150 million.  Compaq's own annual reportsK estimate only $500 million annually for *all* development of the technologyyJ they acquired from DEC (including storage, which they at least suggest may5 be the single largest component of that expenditure).   C   It doesn't cost anywhere near 400-500 million dollars per year iniJ > overhead to develop a dual processor motherboards.  The risk from havingC > sunk development cost of 400-500 million dollars per year is veryw	 differente/ > than the cost of purchasing extra components.   L Leaving aside the major inaccuracy in your numbers, you should note that theD potential reward for that development is also very different:  extraF component costs decrease only very slowly with increased volume, while- per-unit development costs decrease linearly.t   ...n  I > The thing I don't understand about this one is while Compaq is changingt the ' > hardware they aren't changing the OS.t  I The thing you clearly don't understand is that while reactions range fromoB mild-to-mad about the varying levels of unnecessary pain that thisF unnecessary hardware change will entail, what many people are *really*L pissed off about is the cavalier manner in which Compaq felt it could simplyL walk away from repeated, explicit, and apparently sincere commitments to theD Alpha platform - plus the lies it then spread to try to give it some justification for the move.s  K To many, this attitude and behavior from a vendor is flat-out unacceptable.nI If Compaq does nothing of *major* significance to compensate for it, thatwL business (and likely not only Alpha business) will find a vendor more to its liking.r   - bill   ------------------------------  % Date: Sun, 26 Aug 2001 13:44:12 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>e2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <3B893569.2134DDDE@videotron.ca>   Bill Todd wrote:G > The 'safety' of betting one's business on an OS rests not only on theiJ > characteristics of the OS but also on the characteristics of the vendor.  ' I wouldn't quite put it in these words.   J What happens if a vendor produces a very high quality product but fails toM market it. Those who buy into the product and invest in that architecture maypH have a superior product, but what happens to them when the vendor either/ disapears, or drops support for that platform ?R  H Companies need to evolve to keep up with the rest of the economy. And toK evolve, they need to have an IT vendor that moves its products forwards andw: makes available the latest and greatest piece of software.  I Compaq seems very happy to keep VMS in a status quo situation with no new N markets (eg: restricted set of applications to a few targetted niche markets).J Compaq has begun the cycle of losing money, is being accused of being fat,M having a bad/inefficient distribution network and has stated that it wouldn'tmI undercut its rivals so it can keep its margins high enough. Remind you ofa Digital ??????????  L In 1996, I lost a contract because I had pitched a VMS solution, and the NewL York bankers had told me that their analysts said that VMS was dead and thatD Digital wouldn't survive. At the time, I thought of such comments asL "Gartneresque" and didn't put much weight. I knew that they wanted to have aL Lotus Notes solution because that is what their banks had chosen as the then: current trendy product. But in hindsight, they were right.  N What happens when a vendor and/or a product has an image of "won't last" (evenL if such image is not warranted) and the vendor ignores this ? Customers tendF to avoid that vendor because of those fears it will disapear. And whenJ customers avoid a vendor, it certaintly helps realise those early rumours.  L Dell , being a pure wintel player, exposes itself completely when it revealsN its financials every quarter. But Compaq has decided to keep its underwear on,K hiding the (supposedly) biggest generator of profit.  So analysts don't seer the non-wintel part of Compaq.  L Now, factor in the premature announcement of the Alpha murder,  It would notH be surprising to see a very large drop of Alpha related sales during theM period between the Alpha murder announcement and a time where Compaq allows ar3 clear picture to emerge with real hard information.r  K Now, what will happen to Compaq's financials during that time ? How will it M explain a sharp drop it profits (or growing loss) if its PC business is doingf the same ? h  K If Compaq is forced to admit that Alpha sales have dried up, that will onlyeG re-enforce customer's fears of commiting to that platform and will makew matters worse.  J Will Compaq be able to hide the drop in Alpha sales by laundering some the) money Intel paid Compaq to murder Alpha ?     H Note that the drop in Alpha sales may not be immediatly visible. PerhapsL Compaq will put that air force contract into this quarter so that a previousL sale of Alpha will be accounted into a quarter that had very low alpha salesV to hide the trend. But the following quarter, it wouldn't be able to hide the problem.  M UNLESS: by that time, Compaq will have found additional sources of profits ino$ its 180 day restructuring programme.  H One big danger for Compaq though is that the big wad of money Intel gaveN Compaq to execute Alpha will be used to hide the losses, instead of being usedK to invest in those companies that were supposed to allow Compaq to grow its 4 software/solutions/service business by 40% per year.  I Compaq used to be the world'd 2nd largest computer company. Now, when youeN watch the financial news, it is rarely mentioned and instead, they always showJ Dell, HP, IBM on the screens when comparing daily stock performance. WhileL this , by itself, isn't that significant, it does worry me that Compaq isn'tL included in the list of "leaders" in the computer industry. This contributesM to an image that Compaq is fat and heavy and in its way out, instead of being0G the lean and mean agressive company that is out to take over the world.c    N When PSION recently announced it was pulling out of the *consumer* PDA market,H its statement included commitments for continued support/service for itsK devices, as well as including minimum commitments (I think it was 4 years).yM Compaq this to Compaq's handling of the storage products designed for serious E *enterprise* applications that pay big bucks for support, and you seeb! something really wrong at Compaq.o  G What can be said of a company that starts to immediatly cut support foreK enterprise products ? Is the company so desparate that these cuts had to be J made ASAP ? Do you really want to invest in a company's products when thisE company appears to be so desperate to cut costs that it is willing to F sacrifice support of enterprise products with essentially no warning ?   ------------------------------  % Date: Sun, 26 Aug 2001 14:03:16 -0400.- From: JF Mezei <jfmezei.spamnot@videotron.ca>u2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <3B8939E1.BC04FB3B@videotron.ca>   Jeff Killeen wrote:aJ > ...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.w   OK, naive question here:  D Compaq sells a 32 processor wintel thing (built by someone else). SoN ovbviously, it is possible to build these things. But would/could VMS run on a0 32 processor box designed/built to run windows ?  N eg: are the hardware requirements to run VMS on a multi processor box the same as those needed by Windows ?  M Does VMS have any limitations on the number of CPUs it can handle as a singlesL instance ? What happens if VMS has, say, a 16 CPU limit, while Windows has a' 32 processor limit. (speculation here).nJ Compaq would definitely pitch its 32 CPU machines with Windows as its high performance machines.t  D (On paper, 32 CPUs looks so much better , even though I realise thatU performance wise, after a certain number of CPUs, performance increases are minimal).s    M > The thing I don't understand about this one is while Compaq is changing thei' > hardware they aren't changing the OS.   K Actually, by twisting your intented meaning, it is exactly the problem. VMS L has essentially been put in hiatus for 4 years while it is being ported.  SoL whatever technological edge VMS had against Unix and NT will be reduced by 4H years. And in 4 years, the clustering of Unix and even NT might be closeM enough to that of VMS *for most applications* that VMS will have lost its lste remaining big edge.h  N And in 4 years, Microsoft will probably have released 2 new versions of NT and? that will proabbly bring NT much closer to being acceptable forhM stability/security purposes. Remember that those windows weenies at Microsoft : will have grown up and gained experience during that time.   ------------------------------  % Date: Sun, 26 Aug 2001 19:58:50 +0010g% From: paddy.o'brien@zzz.tg.nsw.gov.aut) Subject: Re: Feeling Better about Itaniumn5 Message-ID: <01K7LOHNCA76004D6A@tgmail.tg.nsw.gov.au>o   Didier Morandi wrote:e   >"Doug W." wrote:e >> a >> Don Sykes wrote:eF >> << B) The EV6 & EV7 teams are still at Compaq and will continue to  deliver E >> improvements for the next few (~3) years. So even if the new InteltK >> design doesn't deliver, they could extend the Alpha line until the Intelr >> does deliver. >>l >> aJ >> Will Compaq also continue to improve the compilers or are these people  nowi >> working for Intel?e > B >Th announcement stated that the Alpha Engineering Group *and* the7 >Compilers Group went to Intel. Which is what happened.a  L I don't think they have quite gone yet.  Steve Lionel has mentioned that he K and his (Fortran) team would be one of the first to go (in August).  Steve t still has a Compaq address.u  I To me, I would happily (well ?) forget Alpha versus IA64.  What I do not tM understand is how this compiler cross-dressing will work.  My main job is as rM a Fortran programmer for electrical engineering applications.  I have beta'd tC all of Digital/Compaq F90 compilers (including CXML) and have seen hK compiler/library enhancements in speed regardless of the chip.  Techniques a in the Fortran compiler.  L I could understand some of the GEM technicians being "ported" to Intel, but F GEM is compiler independent.  But why the language specific engineers?  J Will there no longer be compiler enhancements for Fortran/Pascal/C on the I Alpha platform?  Will there be no more upgrades on the Condist for these yM products?  Will the Fortran team only be enhancing CVF (which must be a cash h> cow) at the total loss of VMS Alpha until VMS IA64?  Will ...?  J Why does Compaq seem to be throwing away everything it acquired and which M could have given it a good reputation (CVF seems to have done in the Fortran lM world -- from now on, the world will remember Intel -- IVF :-) -- not DVF or uF CVF for being about the best compiler) just to be a little Wintel box J supplier again.  Something they are seemingly failing at along with their K failure at being a service organisation.  Poor service performance (versus  M good from Digital) has just lost them a contract with our organisation.  Why pK did they even bother to buy Digital when they could have stayed exactly as  I they have reverted to being -- a failing Wintel box supplier with little H else to offer.  K My best regards to the magnificent engineers who have, and are, weathering l
 the storm.   >D.iC >==================================================================  >Poor Consultancy (un)limited   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^d   :-)    Regards, Paddy   ------------------------------  % Date: Sun, 26 Aug 2001 12:33:04 +0200 , From: Didier Morandi <Didier.Morandi@gmx.ch>) Subject: Re: Feeling Better about Itaniums& Message-ID: <3B88D061.5433607B@gmx.ch>  & paddy.o'brien@zzz.tg.nsw.gov.au wrote: > M > I don't think they have quite gone yet.  Steve Lionel has mentioned that hemL > and his (Fortran) team would be one of the first to go (in August).  Steve > still has a Compaq address.O  E "To go" does not necessarily mean that they actually physically moved F but rather than they became INTEL employees. Ask Steve off-line if youI want details. I am not authorized to speak on behalf of COMPAQ nor INTEL..   D.   ------------------------------    Date: 26 Aug 2001 07:18:51 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)/) Subject: Re: Feeling Better about Itanium 3 Message-ID: <MrqV8vmuc58V@eisner.encompasserve.org>o  ] In article <01K7LOHNCA76004D6A@tgmail.tg.nsw.gov.au>, paddy.o'brien@zzz.tg.nsw.gov.au writes:b  N > I could understand some of the GEM technicians being "ported" to Intel, but H > GEM is compiler independent.  But why the language specific engineers? > L > Will there no longer be compiler enhancements for Fortran/Pascal/C on the K > Alpha platform?  Will there be no more upgrades on the Condist for these  O > products?  Will the Fortran team only be enhancing CVF (which must be a cash  @ > cow) at the total loss of VMS Alpha until VMS IA64?  Will ...?  D As I understood what was said, language-specific transfers depend onB the language.  Steve Lionel said they were particularly anxious toE get the Fortran folks, perhaps because their current Fortran offeringr is weak.  E I would point out that since the introduction of PowerPC, the leadingaE vendor of C/C++ on Macintosh has been Metrowerk, who do a much betterh6 job (but not perfect) than Apple had done in the past.   ------------------------------  % Date: Sun, 26 Aug 2001 12:11:32 -0400y2 From: rdeininger@mindspring.com (Robert Deininger)# Subject: Re: GNU screen for AXP/VMSuL Message-ID: <rdeininger-2608011211330001@user-2ivebno.dialup.mindspring.com>  H In article <Pine.GSO.4.32.0108252059400.18980-100000@mars.its.yale.edu>,- James Metcalf <sdn6@pantheon.yale.edu> wrote:g  H > Does anyone if it's possible to port GNU screen to VMS? Has it already) > been done? If so where I can I find it?e  H Never heard of it.  What does it do?  Is it something along the lines of the SMG library on VMS?   J Have you looked in the VMS freeware archives?  Pointers to various archiveJ locations are in the VMS FAQ, which is linked from www.openvms.compaq.com.  I Bill Gunshannon has been posting here, requesting suggestions for portingcG projects appropriate for students.  Maybe this is a possibility, thougheB you'd likely not see the result for the better part of a semester.   -- r Robert Deininger rdeininger@mindspring.coml   ------------------------------  % Date: Sun, 26 Aug 2001 11:09:25 -0000h2 From: "futuredomains.org" <info@futuredomains.org> Subject: Hello !9 Message-ID: <iss.1954.3b88d8e8.36b21.1@mx2.east.saic.com>h  7 There are new domain names awalable on the Internet !!!e  
 Compaq.ltd
 Compaq.inc Compaq.shopc
 Williams.clubg Williams-f1.club
 Williams.lovee
 Formula1.club0 Ferrari-f1.clubn Mclaren.club Mclaren-f1.clubs   AND MANY MANY MORE !!!   Info on: http://www.futuredomains.org   Good Luck !e   ------------------------------  % Date: Sun, 26 Aug 2001 10:05:28 -0400e9 From: "D.B. Turner, islandco.com" <dbturner@islandco.com>hD Subject: Re: Looking for Digital Serial Number Identication Resource/ Message-ID: <toi03d1lrpcra4@news.supernews.com>a  & NI means Northern Ireland doesn't it ?     -- David Turner   We sell Alpha's & Alpha Partsl http://www.islandco.come sales@islandco.com Island Computers US Corp.e 2700 Gregory Streetr Savannah GA 31404o Tel: 912 447 6622  Fax: 912 201 0096n  0 Peter Barone <barone1@HOME.COM> wrote in message5 news:bYXh7.24234$qc.2808941@news1.rdc1.az.home.com...t > NI63900016 >nH > The leading 6 stands for 1996 and the 39 is the 39th work week.  Thats whenK > it was manufactured.  This is a valid serial number.  It's to old to givesI > you any more info.  I think the NI means it was manufactured in Nashua,e New  > Hampshire. >o	 > Regardse > Peter Barone > Compaq Servicesn >n? > "John Fredrickson" <jafred@bellatlantic.net> wrote in messagel3 > news:JCVh7.477$Ia1.113227@typhoon1.gnilink.net...e3 > > Dear Digital Equipment Corporation Aficionados,, > >eG > > Does anyone know of a resource on the web where you supply a serial  numberH > > for a Digital product and get the model number, date of manufacture, etc.?f > >tJ > > I've found an old Digital Alphastation and I'd like to know more about it.tJ > > It seems to be in the Alphastation 600 series box, but the front label has C > > been removed. It has two numbers on the back: the serial numbere
 NI63800016K > > and another number 041-56514. It also has a label on it that identifies5 it; > > as a prototype that is not for sale outside of Digital.  > >r > > Thanks in advance. > >  > > -- > > John Fredrickson > > Washington, DC > >  > >d > >  > >t >  >e   ------------------------------  % Date: Sun, 26 Aug 2001 15:20:56 +0100 5 From: "Steeples, Oliver" <Oliver.Steeples@compaq.com>wD Subject: RE: Looking for Digital Serial Number Identication ResourceP Message-ID: <F498D199EDB12D468CD2C66680D3080101DDE545@reoexc04.emea.cpqcorp.net>  8 The serial number can be broken into 3 areas...         8                                                         8 The first two digits indicate the country of Manufacture8                                                         8 AY = Ayr, Scotland                                      8 BK = Germany                                            8 GA = Galway, Ireland                                    8 IQ = Somewhere else                                     8 NI = Salem, New Hampshire, USA                          8 PC = Irvine, Scotland                                   8 The 3rd Digit indicates the year                        8                                                         : 7 = 1997       8 = 1998        9 = 1999        etc.       :                                                           : The 4th & 5th digits indicate the week of manufacture from: January.                                                  :                                                           : 01 = 1st week in January                                  : 12 = 12th week after January 1st (End of March)           : 20 = Mid April                                            : For a rough calculate take 4 weeks to the month           :                                                           : The remaining digits indicate the run number.             :                                                           : 00005 =        The 5th one made at this plant             : 00100 =        The 100th one made at this plant                                          + There is CX too but not sure where this is.d   	Oliverd   -----Original Message-----> From: D.B. Turner, islandco.com [mailto:dbturner@islandco.com]% Sent: Sunday, August 26, 2001 3:05 PMi To: Info-VAX@Mvb.Saic.ComsD Subject: Re: Looking for Digital Serial Number Identication Resource    & NI means Northern Ireland doesn't it ?     -- David Turner   We sell Alpha's & Alpha Partsr http://www.islandco.comt sales@islandco.com Island Computers US Corp.i 2700 Gregory Streets Savannah GA 31404d Tel: 912 447 6622? Fax: 912 201 0096,  0 Peter Barone <barone1@HOME.COM> wrote in message5 news:bYXh7.24234$qc.2808941@news1.rdc1.az.home.com...n > NI63900016 >VH > The leading 6 stands for 1996 and the 39 is the 39th work week.  Thats whenK > it was manufactured.  This is a valid serial number.  It's to old to givedI > you any more info.  I think the NI means it was manufactured in Nashua,n Newh > Hampshire. >r	 > Regardst > Peter Barone > Compaq Services. > ? > "John Fredrickson" <jafred@bellatlantic.net> wrote in messaget3 > news:JCVh7.477$Ia1.113227@typhoon1.gnilink.net... 3 > > Dear Digital Equipment Corporation Aficionados,e > >bG > > Does anyone know of a resource on the web where you supply a serialr numberH > > for a Digital product and get the model number, date of manufacture, etc.?e > >sJ > > I've found an old Digital Alphastation and I'd like to know more about it.dJ > > It seems to be in the Alphastation 600 series box, but the front label hasoC > > been removed. It has two numbers on the back: the serial numberf
 NI63800016K > > and another number 041-56514. It also has a label on it that identifiess it; > > as a prototype that is not for sale outside of Digital.t > >t > > Thanks in advance. > >a > > -- > > John Fredrickson > > Washington, DC > >g > >h > >  > >i >r >i   ------------------------------    Date: 26 Aug 2001 10:11:23 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett) D Subject: RE: Looking for Digital Serial Number Identication Resource, Message-ID: <Kx5WwmFBSZ6d@malvm5.mala.bc.ca>  Q In article <F498D199EDB12D468CD2C66680D3080101DDE545@reoexc04.emea.cpqcorp.net>, i<      "Steeples, Oliver" <Oliver.Steeples@compaq.com> writes:  : > The serial number can be broken into 3 areas...         : >                                                         : > The first two digits indicate the country of Manufacture: >                                                         : > AY = Ayr, Scotland                                      : > BK = Germany                                            : > GA = Galway, Ireland                                    : > IQ = Somewhere else                                     : > NI = Salem, New Hampshire, USA                          : > PC = Irvine, Scotland                                     D   There also used to be KA ( Kanata, Ontario, Canada ) before CompaqC saw fit to close the plant ( yet another benefit of "free" trade ).m  9   A number of VAX models were built there over the years.p   ------------------------------  % Date: Sun, 26 Aug 2001 08:57:17 -0400,) From: "Neil Rieck" <n.rieck@sympatico.ca> % Subject: Re: V5.5-2 Password Recoveryy8 Message-ID: <jo6i7.1107$zP.102954@news20.bellglobal.com>  > "Malcolm Dunnett" <nothome@spammers.are.scum> wrote in message& news:RjMp$E95XjDZ@malvm6.mala.bc.ca...' > In article <3B87EBAC.5D7E310@gmx.ch>,m4 >     Didier Morandi <Didier.Morandi@gmx.ch> writes: >  > > Malcolm Dunnett wrote: > >>	 > > ../..oL > >>    I certainly hope not. Given how much Microsoft stole from VMS for NT	 > > ../..h > >IL > > This sentence does not make sense. The principal engineer for NT is DaveJ > > Cutler, who used to be one of the creators of VMS (remember: VMS + 1 = WNT) > > F >     What doesn't make sense about it? Cutler knew how VMS worked andL > used many of those same techniques in NT. Reading the NT internals book isL > surprisingly similar to reading the VMS internals manual. You'd think thatJ > having worked on VMS Cutler would know better than to use case sensitive, > passwords ( which was my original point ). >m  > > Choose your words carefully. > >o > E >     Would you prefer I use the word "copied" rather than "stole"? I 	 certainlynI > didn't mean to imply any criminal action on Microsofts part ( I believe  DigitalfH > and MS long ago settled their legal disputes in this area ) but I used "stole"-L > to suggest that there was no public acknowledgement of how much NT owes toL > VMS in terms of "heritage". I suspect from your email address that EnglishI > 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. >dF I was lead to believe that Dave Cutler worked on the cancelled EmeraldG project at Digital which was attempting to port VMS onto PC technology.hI People I know thought that Cutler was a traitor for taking is know-how tocK Microsoft, but in view of recent events at Compaq (like Intel paying Compaq I for the assassination of Alpha), it looks like Cutler was a visionary. In/H hind site, if you want your work to change the world and efforts by yourF employer seem to be holding you back, you just might move to a younger company.  D Anyway, all this stuff is conjecture. If you're really interested in+ history, check out the following few links:,   Gordon Bell's DECmuseum:? http://research.microsoft.com/users/gbell/Digital/DECMuseum.htm  Compaq vs. Digital Timeline:G http://research.microsoft.com/users/gbell/Digital/timeline/compaq-d.htmh" A rare interview with Dave Cutler:G http://research.microsoft.com/users/gbell/Digital/timeline/compaq-d.htm  Culter biography at Microsoft A http://www.microsoft.com/PressPass/exec/de/default.asp#DaveCutler   
 Neil Rieck Kitchener/Waterloo/Cambridge,c Ontario, Canada.! http://www3.sympatico.ca/n.rieck/t   ------------------------------  % Date: Sun, 26 Aug 2001 09:08:54 -0400i) From: "Neil Rieck" <n.rieck@sympatico.ca>c% Subject: Re: V5.5-2 Password Recoveryl8 Message-ID: <cz6i7.1232$zP.109611@news20.bellglobal.com>  > "Malcolm Dunnett" <nothome@spammers.are.scum> wrote in message& news:78ewRlvoTJA1@malvm5.mala.bc.ca...   [snip]  G >     Sure you did. Open the SYSUAF file for write access ( it's just a  normalL > RMS indexed file ). Find the relevant record ( you can search by key basedH > on username ). Read the record into your program. In BASIC I think the; > module to get the record definition is UAF070DEF so you'dh >tH >   %include "$UAF070DEF" %from %library "SYS$LIBRARY:BASIC$STARLET.TLB" >1J >   ( this assumes you built the optional system definition files when you > installed BASIC ). >0A >    Change the quadword at offset UAF070$Q_PWD to your new value A > ( as determined by encoding it with SYS$HASH_PASSWORD ), saving&K > the old value somwhere else ( outside the SYSUAF ). Write UAF the record.t You H > can now log into that user with the new password. When your evil deedsJ > are done reverse the process, writing the saved quadword value back intoK > the UAF record. Voila, instant password change - no audit trail, no "lastoH > password change" information. Of course the victims old password won'tL > work during the time you have your new password enabled, so make sure he's2 > not likely to try logging in during that window. > I >     I don't think any of the above counts as giving secrets away - it'sf allf@ > pretty clearly documented ( the basic data structures, not the technique ). >p  I I didn't realize that stuff was documented, but this is "Open" VMS right?h :-)m   [snip]   >sL >    The number of valid 8 character passwords is actually 38^8 (4.34e+12)?. >r  H You are correct. In my haste I interchanged the base and exponent. Also,D drinking a Heineken while checking out the news groups on a SaturdayG afternoon is probably OK as long as you don't try to reply until Monday  morning :-)m   ------------------------------  % Date: Sun, 26 Aug 2001 19:04:12 +0200e  From: Paul Sture <paul@sture.ch>% Subject: Re: V5.5-2 Password Recoveryr+ Message-ID: <VA.0000042c.0a5021ec@sture.ch>C  M In article <5kPh7.56502$wX5.4465432@news20.bellglobal.com>, Neil Rieck wrote:eL > Watching you people debate this got me thinking that I should at least try > it. I wrote thisE > http://www3.sympatico.ca/n.rieck/demo_vms/basic-password-search.zipmJ > DEC-BASIC program in a little more than an hour using two OpenVMS systemM > calls (sys$getjpi and sys$hash_password) which are publicly documented heren> > http://www.openvms.compaq.com:8000/72final/4527/4527pro.html1 > so I guess OpenVMS really is open after all :-)t > L > I estimate that the runtime on an Alpha (EV5/300 MHz) is between 10 and 20I > days for a 6 character password (it depends on whether the password waseM > AAAAAA, ZZZZZZ, 111111  or 999999). You would need to multiply this time byi3 > 38 for each additional character in the password.t  M Umm, not sure what you mean here. Having read about the phenomenal number of eN passwords which could be tested per minute on non_VMS systems, I too had a go  at this a few months ago.a  H Feeding every number from 000001 to 999999 into sys$hash_password I was L getting 500,000 guesses a minute on my PWS 600au, using COBOL. (I had a UAF K username/password validation program already, so this was just a 10 minute   quicky).  N IOW: If I know that a password is length 6 and numeric**, I can crack it in a  couple of minutes.  N ** Not so many years ago, a colleague had a bitter argument with an IBMer who G was trying to enforce a company wide policy of numeric-only passwords, L/ specifically of length 6, so this _can_ happen.    > Since better skilledI > programmers could probably come up with a more efficient solution, I'veoM > decided to change the minimum password length from 6 to 8 on all my OpenVMSh1 > systems via the following command in authorize:u >  > uaf>mod * /PWDMINIMUM=8i > 8 Likewise, I lengthened my passwords after that exercise.  I Something else I discovered in all this, which will be relevant to those p running Samba.  B At http://support.microsoft.com/support/kb/articles/q147/7/06.asp H recommendations are given to use NTLM or NTLMv2 password authentication K rather than just the LM flavour (they claim that LM is insecure, but don't  H mention NTLM's limitations, but we have to assume they exist, hence why  NTLNv2?). In that article:  L "LM authentication is not as strong as NTLM or NTLMv2 because the algorithm H allows passwords longer than 7 characters to be attacked in 7 character  chunks."  M I don't know whether Pathworks suffers from similar problems, although since e3 (at least older versions) use LANMAN, I suspect so.o  M You may be happy with the length of your passwords from a VMS point of view, ,K but if Windows knows valid VMS username/password combinations, you need to  B consider that fact that the crack could come from the Windows end.   ___c
 Paul Sture Switzerland    ------------------------------  % Date: Sun, 26 Aug 2001 19:04:13 +0200e  From: Paul Sture <paul@sture.ch>% Subject: Re: V5.5-2 Password Recoveryt+ Message-ID: <VA.0000042d.0a5024fa@sture.ch>n  C In article <hz5FWuprFW4d@malvm5.mala.bc.ca>, Malcolm Dunnett wrote:0) > In article <3B881315.4CF69B25@gmx.ch>, r3 >    Didier Morandi <Didier.Morandi@gmx.ch> writes:o >  > >> Write UAF the record. YouK > >> can now log into that user with the new password. When your evil deeds4M > >> are done reverse the process, writing the saved quadword value back intonN > >> the UAF record. Voila, instant password change - no audit trail, no "last" > >> password change" information. > > J > > A system mangler concerned by security would of course have a securityJ > > acl on the sysuaf.dat file and would wonder the day after why s/he hadL > > "something" write into this file without having an AUDIT alarm triggered > > (assuming it is enabled) > G >    I suppose, assuming such an ACL exists, but that's not part of the F > "out of the box" VMS setup - whereas recording the date the passwordJ > was last changed by authorize ( or $setuai ) is. Wouldn't all the normalG > things that write the UAF (such as every login) trigger the ACL also?-H > With all that noise you'd have to be pretty sure what you were lookingG > for ( or have a good analysis tool ) to spot the suspicious activity.i >   O No, LOGIN doesn't trigger alarms for SYSUAF in this way. Use of AUTHORIZE does tO (and it's useful to see who is changing passwords by AUTHORIZE rather than SET s? PASSWORD. But you are correct, it's not there "out of the box".e  G >   Your earlier suggestion about just copying the UAF would also work,fK > but there could be traces of that in other users records ( eg other usersuI > log in while your copied UAF is active, their last login dates won't be@M > recorded when you restore the original file, any password change they mighto! > have made would be lost, etc ).e >sN Not devious enough :-) You can EDIT the original UAF, leaving only the record L you have knobbled, then CONVERT both files to a new one, so that the record N you changed is rejected with a duplicate key. The other user records are left O as up to date. This does assume that you have the system in a pretty quiescent e state at that point. ___4
 Paul Sture Switzerland.   ------------------------------  % Date: Sun, 26 Aug 2001 13:05:20 -0400h+ From: "Main, Kerry" <Kerry.Main@compaq.com>e5 Subject: RE: VMS high reliability needed by Air ForcesR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4D56090@kaoexc01.americas.cpqcorp.net>   re: system crash messages ..  B Actually, I kind of always thought the UNIX "panic" message was an6 interesting approach to describe this type of event...   :-)y   Regardsi  
 Kerry Main Senior Consultantp Compaq Canada Corp.i Professional Servicess Voice: 613-592-4660o Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----1 From: WILLIAM WEBB [mailto:WWEBB1@email.usps.gov]  Sent: August 23, 2001 10:19 PM To: Info-VAX@Mvb.Saic.Com 5 Subject: RE: VMS high reliability needed by Air Forceh       Don't forget about DEADBEEF.   WWWebb   > -----Original Message-----1 > From: Info-VAX-Request@Mvb.Saic.Com at INTERNET0) > Sent: Thursday, August 23, 2001 9:14 PMsF > To: Webb, William W - Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET7 > Subject: RE: VMS high reliability needed by Air Forcec >  > 5 > Michael D. Ober <mdo.@.wakeassoc.com.nospam> wrote: ; > > My favorite was when our Honeywell systems crashed, the  > first four hex7 > > characters in the crashdump were frequently "DEAD".S > > -- > > Mike Ober. >c8 > A department here used to have a Wang VS45 system that > crashed during aG > thunderstorm.  When it came back up, its LED status display also read  >i >         DE >         AD >aG > I looked it up once, and there on the last page of the list of status E > codes it was listed.  Of course the suggested action was to contact G > Wang Service.  I remember it of course, that got me a job on overtime F > doing regular backups since what had happened was the disks table ofG > contents had been scrambled.  And they did not have a current backup. G > The Wang service guy managed to recover and restore almost all of the G > data on the disk, but that involved copying it all off to 8" floppies  > and back.  > 
 > Joe Heimann  >i > heimann@ecs.umass.edu  > < > > "Brendan Welch" <brendan_welch@uml.edu> wrote in message% > > news:3B850517.A8B385E8@uml.edu...  > >>> > >> > Besides, computer language is already too violent (kill' > >> > the process, abort, crash, etc.)s > >> >F > >> You forgot the obvious,  EXECUTE  the program !   We execute both+ > >> directives and living things.  tee hee  > >> > >> -- D > >> Brendan Welch, system analyst, Univ. of Massachusetts - Lowell,
 > >> W1LPG >t   ------------------------------   Date: 25 Aug 2001 20:43:52 CDT= From: wayne@tachysoft.xxx.374515.killspam.015f (Wayne Sewell)tC Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically? . Message-ID: <1UkZnXVymVWy@tachxxsoftxxconsult>  c In article <YBBKTGNGOdO4@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:0p > In article <uy9$+Z2W3M$5@tachxxsoftxxconsult>, wayne@tachysoft.xxx.580099.killspam.0160 (Wayne Sewell) writes: > K >> And also the files on them.  The history database is one of the greatest O >> features of tapesys.   It can keep track of every file on every tape and you:O >> can do a lookup in seconds.  If a user comes to you and says "I accidentallySK >> deleted my login com and I want it back", you don't have to wade throughe= >> listings or anything else to determine what tape it is on.n > J > While that is a good feature, I don't understand why that implementation= > is any better than the journal files made by Backup itself.G >  > But I am ready to be taught.    N Me, too.  :-)  In order to contrast history and journal files intelligently, IM need to understand more about how journal files work.  I've never used them. fL I've had tapesys all the time I've been consulting (software partners was myN first client, in april of 92), and before that, when I worked for a company, IN was a system programmer, not a system manager.  Backups and such were somebodyA else's job.  So I really don't know anything about journal files."  4 I will read up on it and formulate a response later.  N I will mention one brief point, however -- speed of access.  The journal filesM appear to be organized by saveset, while the history database is organized byuJ file.  Instead of telling you which files are in a particular saveset, theK history database tells you which savesets contain a particular file.   EachnM file record contains an array of pointers to the saveset records that contain6L that file.   This can make a big time difference in searching, especially ifN the file existed only for a brief period and you have no idea which saveset(s)K it is stored in.  Organized by file, it doesn't matter because there's onlyt: *one* record for a particular file in the entire database.     Wayne    --  O ===============================================================================-M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxs: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-).O ===============================================================================oH Randolph Duke (in Trading Places): "Mother always said you were greedy.". Mortimer Duke: "She meant it as a compliment!"   ------------------------------    Date: 26 Aug 2001 07:05:19 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically? 3 Message-ID: <HzRR7oO1N22w@eisner.encompasserve.org>   n In article <1UkZnXVymVWy@tachxxsoftxxconsult>, wayne@tachysoft.xxx.374515.killspam.015f (Wayne Sewell) writes:  P > I will mention one brief point, however -- speed of access.  The journal filesO > appear to be organized by saveset, while the history database is organized by L > file.  Instead of telling you which files are in a particular saveset, theM > history database tells you which savesets contain a particular file.   EachfO > file record contains an array of pointers to the saveset records that contain-N > that file.   This can make a big time difference in searching, especially ifP > the file existed only for a brief period and you have no idea which saveset(s)M > it is stored in.  Organized by file, it doesn't matter because there's onlye< > *one* record for a particular file in the entire database.  H That sounds like a reasonable distinction, and a selling point for thoseB who have a frequent need for single-file retrievals from uncertain dates.   ------------------------------   End of INFO-VAX 2001.474 ************************