1 INFO-VAX	Fri, 28 Nov 2003	Volume 2003 : Issue 659       Contents:$ Re: Bugcheck in SYSMAN.EXE on reboot Re: Can Pagefile be too big?8 Re: DCL Enhancements: Error messages for OPEN and DEFINE# Re: First FutureVAX benchmark tests  Openvms client for Netbackup9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday A Re: Thanksgiving in France (was: First FutureVAX benchmark tests) > Re: VEST bug (or VEST feature, depending on one's perspective) Re: [OT] For David CATHEY - [OT] The President of the USA in Bagdad today 1 Re: [OT] The President of the USA in Bagdad today 1 Re: [OT] The President of the USA in Bagdad today 1 Re: [OT] The President of the USA in Bagdad today   F ----------------------------------------------------------------------  # Date: Fri, 28 Nov 2003 00:17:26 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) - Subject: Re: Bugcheck in SYSMAN.EXE on reboot L Message-ID: <rdeininger-2711031918530001@user-105n8oe.dialup.mindspring.com>  : In article <20031126114102.00773.00001113@mb-m28.aol.com>,& ejheller@aol.com.com (EJHeller) wrote:  N >Thanks for all the responses. It appears to be a parity error from one of the! >PCI boards. HP is addressing it. N >My next question is - If this is the problem and the error log can record it,O >why can't the displayed message reflect this instead of pointing to a program?   C The hardware and firmware are reporting that an uncorrectible error F occured.  Since it occured in kernel mode, any of the fundamental dataG structures in the OS _might_ have been affected.  VMS doesn't know what H parts of the system it can still trust.  In this environment, it doesn't< make sense to attempt detailed error analysis and reporting.  J The bugcheck environment is small, simple, and stupid.  All it wants to do2 it write memory contents to the dump file on disk.  I When you analyze the dump file (which includes the error log information) ? after the fact, you can often find the root cause of the crash.   8 From the previous posts, here's what I think happened...  I While VMS is booting, the STARTUP process eventually exectues SYSMAN.EXE, G and does an IO AUTOCONFIGURE command.  Up until this point, most of the F I/O hardware in the system has been idle.  The only active devices are1 generally the boot device and the console device.   D SYSMAN IO AUTOCONFIGURE loads device driver software, and the driverG initialization routines typically start accessing real hardware -- like H your unhealthy PCI card.  The device drivers are not part of the STARTUPH process or any other process (they are part of the OS kernel).  When theI machine check happens, STARTUP is the active process, running SYSMAN, and E that is captured in the crash dump.  STARTUP didn't cause the machine G check, but it did launch the driver that caused  it.  So SYSMAN.EXE was  probably a very good clue.     -- Robert    >Edward. >  >>SYSMAN.EXE on reboot& >>From: "Mike Naime" mnaime@kc.rr.com 1 >>Date: 11/20/2003 10:44 PM Eastern Standard Time : >>Message-id: <kSfvb.58023$Eq1.1453@twister.rdc-kc.rr.com> >>G >>If you are seeing  the following, this means that you have a hardware N >>problem and need to get it fixed!  Sending (FTP) the ERRLOG.SYS file that isM >>in the SYS$ERRLOG: directory to HP will let the hardware group diagnose the  >>exact problem. >>C >>**** OpenVMS (TM) Alpha Operating System V7.3-1   - BUGCHECK ****  >>M >>** Bugcheck code = 00000215: MACHINECHK, Machine check while in kernel mode  >>N >>INITing the box is only masking the problem.  If it is a NEW DS10, it should >>still be under warranty. >> >>Mike Naime >>2 >>EJHeller <ejheller@aol.com.com> wrote in message6 >>news:20031120144834.10071.00000629@mb-m01.aol.com...G >>> We have a new DS10 with OVMS 7.3.1 with all the latest and greatest 
 >>criticalJ >>> patches. Since we turned it on, every time we do a shutdown/reboot the >>systemL >>> bugchecks in SYSMAN.EXE with a code of 215 (process = STARTUP). The onlyG >>> recovery is to manually halt the machine and issue an INIT from the 
 >>maintenance @ >>> prompt, then boot the computer. We could work around by do a >>shutdown/noreboot 7 >>> and the issue the boot from the maintenance prompt. I >>> In looking at the patch site, I saw there is a patch for MANAGER. So,  >>being the I >>> psuedo-adventurous sort, I installed this patch. Now any boot after a 
 >>shutdown. >>> requires an INIT before a successful boot.1 >>> Has anyone seen this problem and resolved it?  >>> Thanks for your input, >>> Edward Heller  >>> TransCore ITS, Inc# >>> edward.heller@transcore-.-com..    ------------------------------  # Date: Thu, 27 Nov 2003 22:51:07 GMT 9 From: Alan Adams <alan.adams@orchard-way.freeserve.co.uk> % Subject: Re: Can Pagefile be too big? ? Message-ID: <935b23584c.Alan.Adams@orchard-way.freeserve.co.uk>   / In message <3FB35FBD.6B68EACE@sture.homeip.net> 5           Paul Sture <nospam@sture.homeip.net> wrote:    > Keith A. Lewis wrote:  > >  > > hoff@hp.nospam (Hoff Hoffman) writes in article <Gowsb.8902$py6.7256@news.cpqcorp.net> dated Wed, 12 Nov 2003 20:05:58 GMT: j > > >In article <Xns943177A5EFCA9falkarcabca@198.161.157.145>, Alfred Falk <falk@arc.REMOVE.ab.ca> writes:N > > >:Some recent problems that we had were mis-diagnosed as insufficient pageN > > >:file size, so now I have a pagefile of more than 7 GB.  1.5 GB is likelyK > > >:large enough.  Is there a significant cost to having the larger file? 9 > > >:That is, would it be worthwhile to shrink it again?  > > > N > > >  Other than the disk storage involved (and the usual risks of disk blockO > > >  errors that might arise underneath the pagefile), having a pagefile that M > > >  is larger than current requirements should not have any particular nor 3 > > >  any particularly noticeable adverse effects.  > > L > > Hmmm, that doesn't agree with what I learned in "OpenVMS Performance andP > > Tuning" back in the day.  The instructor said yes a pagefile can be too big,P > > and cited a couple of reasons, I'm not sure if they are as relevant today as: > > they were back then, or even if I remember them right. > >  > H > In a similar vein, mor than 20 years ago a colleague was experimentingE > with working set sizes and found a distinct overhead with too large I > working sets (the application in question did lots of remapping of data   > structures, so paged heavily). > H > That was then, and there have been many improvements along the way, soJ > you are right to question the relevance of stuff taught a long time ago. > J > One of my favourite discoveries all those years ago was that GBLSECTIONS > and GBLPAGESH > carried very little overhead, certainly so when running systems with 4F > or more MB, so I used to be pretty generous in their allocation, and% > thus saved myself many a reboot :-)  > K > > * Virtual pages are indexed in RAM, and the size is proportional to the J > > total amount of virtual memory.  Changing the page size from 512 to 8K6 > > (as in VAX-Alpha transition) helps here, I'm sure. > > O > > * A larger pagefile spans more disk cylinders, which increases your average 3 > > seek time when you're fetching a bunch of them.  > >   F In a similar vein, I seem to recall once setting a very large value ofF VIRTUALPAGECNT on a somewhat memory limited VAX, and having the systemE unable to boot, because the system page tables exceeded the available  memory.    >    --  
 Alan Adams& alan.adams@orchard-way.freeserve.co.uk http://www.nckc.org.uk/    ------------------------------  % Date: Thu, 27 Nov 2003 15:18:05 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>A Subject: Re: DCL Enhancements: Error messages for OPEN and DEFINE ) Message-ID: <3FC65BFC.5743AC8A@istop.com>    Paul Sture wrote: G > CONTINUE didn't work when trying to restart command procedures at one  > time.   K Is continue supposed to work for command procedures ? I thought it was only N for images ? (obviously, if the command procedure is executing an image at the time of ctrl-y ....)   ------------------------------  # Date: Thu, 27 Nov 2003 23:53:52 GMT 4 From: brad@.gateway.2wire.net (Bradford J. Hamilton), Subject: Re: First FutureVAX benchmark tests0 Message-ID: <k8wxb.240174$9E1.1308477@attbi_s52>  S In article <00A2985C.E4285BBC@SendSpamHere.ORG>, VAXman-  @SendSpamHere.ORG writes: g !In article <rlnxb.324979$Fm2.335226@attbi_s04>, brad@.gateway.2wire.net (Bradford J. Hamilton) writes:  !snip! !>Hi Brian,  !>% !>Having a problem sending to tmesis:  !>4 !>554_5.7.1_Message_rejected_due_to_header_contents.@ !>Diagnostic-Code: smtp: Permanent Failure: Other address status !>4 !>Would it be OK if I posted the code here, instead? !>L !>__________________________________________________________________________C !>Bradford J. Hamilton                    "All opinions are my own" M !>bMradAhamiPltSon-at-coMmcAast.nPeSt     "Lose the MAPS, and replace '-at-'  2 !>                                         with @" ! ( !The subject has THANK YOU in it??? Why? !   F Dunno how that got in there - the subject (from my end) actually says,  3 "Here you go...Happy Thanksgiving to you and yours"   M Oh, *now* I understand...it's the "Here you go" phrase...I forgot that phrase  is poison.		:-)   ? Oh well, so much for being polite and pleasant on the 'Net		:-)   M In any case, others have posted the same code here, so I won't clutter up the  wires any further.  9 [OT] - I hope you and you family had a good Turkey-Day...    !snip!  J __________________________________________________________________________A Bradford J. Hamilton                    "All opinions are my own" K bMradAhamiPltSon-at-coMmcAast.nPeSt     "Lose the MAPS, and replace '-at-'  0                                          with @"   ------------------------------    Date: 27 Nov 2003 22:08:45 -0800$ From: michaeltlk@lycos.com (Michael)% Subject: Openvms client for Netbackup = Message-ID: <790c9c99.0311272208.7a694551@posting.google.com>   B I hit a problem during installation of Openvms client. When invoke4 NBU> show client, its show client is not responding.  9 invoke $ ucx sh serv bpcd, it show the following messages 3 %DCL-W-ACTIMAGE, error activating image UCX$CFS_SHR  -CLI-E-IMGNAME, image file/ DSA0:[SYS0.SYSCOMMON.][SYSLIB]UCX$CFS_SHR.EXE;1 A -SYSTEM-F-PROTINSTALL, protected images must be installed           D Any Openvms gurus able to help explain what the above error messages mean ?? C Is the ucx service necessary when i'm using the TGV Multinet tcp/ip  stack. OS:APHA OpenVMS 7.1-2   2 Anyone go through this kind of error, Please help.   ------------------------------  % Date: Thu, 27 Nov 2003 20:20:00 +0100 * From: Paul Sture <nospam@sture.homeip.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday0 Message-ID: <3FC65C70.5D24BCC5@sture.homeip.net>   John Smith wrote:  >  >    <snip>  $ > The bottom line with Alpha was/is: > M > Had Digital/Compaq done serious marketing of the operating systems that ran H > on top of Alpha, then there would have been sufficient sales volume to1 > justify further funding & development of Alpha.  > N > On a technical basis alone, the fact that the 'guts' of EV79 & EV8 are goingM > to be incorporated in whole or in part into forthcoming generations of IA64 K > variants is sufficient proof that Alpha was more than technically viable.  > I > The 'failure' of Alpha is strictly a failure in marketing & advertising N > caused by a failure of executive decision making. And those same advertisingN > & marketing failures of the Digital/Compaq era continue to be evident in theI > HP regieme, also caused by the same root problem - failure of executive I > decision making. However this time around it probably won't be the chip 3 > which is killed....it'll be the operating system.   B An interesting article from 1997 predicting the demise of Alpha in favour of IA64:   !     the conversion to Pentium II.   >      Another use for the new fab could be for Intel's graphics?      initiative. Intel's initial 0.25-micron fab plans may have D      neglected graphics chips, assuming they could be built on olderE      fabs. It is now apparent that competitive 3D graphics chips will D      require 0.25-micron technology. If Intel is able to grab 10% ofD      the PC graphics market in 1999, these chips could consume up toE      half the capacity of the Hudson plant, with at least some of the %      rest devoted to Digital's needs.   A      In any case, the new plant gives Intel an enormous amount of F      0.25-micron capacity. The plan now includes five fabs running theG      0.25-micron process (Santa Clara, Chandler, Albuquerque, Leixslip, F      and Hudson), compared with just three for the current 0.35-micronB      process. One benefit of the Hudson purchase is that Intel canG      delay the build-out of its planned Ft. Worth (Texas) fab from 1999 D      to 2000. That plant was originally planned as a 0.25-micron fab1      but will now start at the 0.18-micron level.    Getting Approval May Be Dicey   D      The settlement is on hold until it is approved by both the U.S.E      Federal Trade Commission (FTC) and the judges presiding over the D      suits. To gain FTC approval, the parties must show that the newD      arrangement does not diminish competition in the microprocessorG      market. If Digital were to admit that it plans to phase out Alpha, F      the FTC would almost certainly refuse to let the deal go through.  @      Thus, the dichotomy between Digital's public statements and>      private comments. In particular, Palmer and other DigitalC      executives have taken a strong public position that Alpha will G      continue well into the future and is actually helped by this deal. C      Of course, this stance is necessary to protect Digital's Alpha F      business until Merced systems are available, but it also paints a=      picture that the FTC wants to see. Similarly, Intel will F      undoubtedly refuse to make any negative comments about the future@      of StrongArm until the deal is complete, a process that the1      companies expect will take up to six months.   D      The FTC is already investigating Intel's business practices, inD      part because of the heavy-handed way it originally responded toB      the Digital suit, and has a separate investigation of Intel'sF      agreement to purchase Chips and Technologies (see MPR 8/25/97, p.F      4). Its examination of the new agreement may take several months,F      but given the agency's unwillingness to hold up such deals in theA      past, this one seems likely to ultimately get a green light.   D      Although Intel will not admit guilt, of course, the form of theD      settlement implies the company was concerned that Digital couldE      prove patent infringement. Typically, patent cross-license deals E      are not royalty bearing: both companies simply exchange patents. G      In this case, however, Intel reportedly agreed to pay Digital $200 @      million over four years in addition providing access to itsC      patents. Intel has also granted Digital the prestigious Tier 1 F      discount status; because of its moderate x86 volumes, Digital hasF      been in Tier 2, although the companies would not confirm any suchE      details of the agreement. Intel doesn't want any royalty payment =      to be reported, since it might encourage other lawsuits.   D      The settlement clearly weakens a threat to Intel's product line@      and strengthens IA-64's hold on the high-end system market.E      Digital characterizes the change as a win for Alpha, but in fact A      it is likely to ultimately remove Digital from the processor >      business, a tragic fall for the company that invented theD      The settlement clearly weakens a threat to Intel's product line@      and strengthens IA-64's hold on the high-end system market.E      Digital characterizes the change as a win for Alpha, but in fact A      it is likely to ultimately remove Digital from the processor >      business, a tragic fall for the company that invented theB      minicomputer more than 30 years ago. And so, we move one stepC      closer to a world in which all significant computers are built !      using Intel microprocessors.   2                             The Making of The Deal  E        When Digital first sued Intel (see MPR 6/2/97, p. 26), Intel's @        motivations were obvious: make the suit go away before itG        jeopardized the enormous revenue stream from Intel's Pentium and >        Pentium II products. Yet the company was eager to avoidG        appearing to make a large payment to settle the suit, since that >        might seem to be giving in to patent blackmail and thus        encourage similar suits.   G        Digital's motivations for its suit were less apparent. Obtaining G        some payment from Intel is clearly a benefit for the financially @        weak company. The patent cross-license gives Digital moreF        flexibility in its future processor designs and settles Intel's+        counterclaim of patent infringement.   E        At some point in the talks, Digital's semiconductor operations B        came into play. Digital has long maintained its own fabs toE        build high-performance chips for its computer systems, but the C        Hudson fab was too large for the modest number of chips that C        Digital currently requires. Digital set up its semiconductor E        business in 1993 to develop and sell chips on the open market, E        hoping to create enough demand to fill the fab. Unfortunately, D        neither the Alpha processors nor Digital's other chips becameF        big sellers, leaving the semiconductor operation losing as much7        as $100 million a year, according to one report.   A        Furthermore, Digital's board of directors, along with some <        executives in the systems group, had allegedly becomeB        disenchanted with Alpha. Despite its technical superiority,C        Alpha has not caused Digital's system sales to surge, and no @        other large computer vendor has adopted the architecture.@        Substituting Intel's IA-64 technology for Alpha would cutB        Digital's costs while providing access to industry-standard        hardware and software.   E        Digital can't convert to IA-64 immediately, since Merced won't D        ship for two years, and Digital has a large installed base ofC        Alpha customers. Thus, Intel had to commit to building Alpha 7 [MicroDesign Resources] [Site Index] [Search] [Contact] L ----------------------------------------------------------------------------2                            [Microprocessor Report]:                  Volume 11, Number 15    November 17, 1997  6                        Digital Sells Its Chip Business  B            Intel Gets Fab, StrongArm in Settlement of Legal Battle  H  This document and the complete issue [910K] are also available in Adobe PDF -                               format. [Image]         by Linley Gwennap  D      As part of an agreement to settle the patent litigation between@      the two companies, Intel has agreed to buy Digital's entireC      semiconductor operation, including its Hudson (Mass.) fab, for F      approximately $700 million. Intel will also pay Digital a smallerD      amount to set up a 10-year patent cross-license between the twoF      companies, effectively ending the litigation. The deal reportedly>      improves Digital's discounts on future purchases of Intel      processors as well.  C      Under the agreement, Intel will build Alpha chips for Digital, F      since the latter will no longer have a fab. Digital will continue9      to be responsible for developing and marketing Alpha F      microprocessors; Intel's role will be solely as a foundry. But asE      part of the deal, Digital has endorsed Intel's IA-64 technology, E      and we believe that, over time, IA-64 will supplant Alpha within !      Digital's product offerings.   @      In addition to the fab, Intel gets Digital's non-Alpha chip?      business, including the company's networking chips and its C      StrongArm microprocessor family; Digital will no longer market B      these products. Intel says it will offer jobs to all affectedD      Digital employees, but it isn't clear how long it will maintainG      these product lines. Intel plans to fit out the Hudson fab for its B      new 0.25-micron process and to manufacture a variety of IntelG      products there, but it must await government approval, which could       take months.   ' Alpha Products Remain on Track--For Now   F      Digital claims it remains committed to the Alpha architecture andG      that the Intel deal has no effect on its Alpha plans. Like Silicon G      Graphics and Sun, Digital will simply have its processors built by       an external fab.   F      Relying on Intel as a foundry could have advantages. In the shortD      term, the Hudson fab will continue to run Digital's 0.35-micronE      process, and in the future, Digital's 0.25-micron process. Under B      Intel's management, the fab will also run Intel's 0.25-micronA      process, which is slightly different from Digital's (see MPR D      9/16/97, p. 11). Intel believes that both 0.25-micron processesE      will run on the same production line, however, so it will simply C      switch from one process to the other, depending on the type of       chip being manufactured.   E      In the 0.18-micron generation, Digital will design its chips for E      Intel's process, eliminating this bifurcation. Digital has often A      lagged Intel by as much as a year in deploying a new process G      generation; the deal could allow Digital to ship 0.18-micron Alpha E      processors well before it could have without Intel. On the other E      hand, Intel's process may lack some of the performance-enhancing @      features included in Digital's current designs, but Intel'sE      0.18-micron process will unquestionably be faster than Digital's       0.25-micron process.   F      The downside for Digital may be a lack of responsiveness from the@      fab. Today, the Hudson fab can tweak the process to achieveG      maximum clock speed and select a handful of parts from the far end E      of the yield curve to fill Digital's fastest speed grades. Under C      Intel, the fab will be managed to achieve high volume, not the E      maximum possible performance, and exceptions for the Alpha parts C      may be more difficult to make. Digital says it has contractual F      guarantees that Intel will produce Alpha chips at the same speedsD      they are today, but we would not be surprised if the transitionC      made it more difficult for Digital to achieve industry-leading        clock speeds in the future.   Interest in Alpha Will Wane   B      In the long term, we suspect Digital will phase out its AlphaB      line. Once the company begins selling Merced systems in 1999,C      interest in the Alpha boxes is likely to wane. Digital said it ?      will port Digital Unix to IA-64, and Microsoft has already ?      announced plans for Windows NT on Merced, so nearly all of D      Digital's workstation customers and at least half of its serverA      customers will be able to move easily to the new Intel-based @      systems. (Digital's other customers use OpenVMS, which will$      probably remain on Alpha only.)  E      Digital insists its Alpha chips will maintain a performance edge G      over Merced on at least some applications, and this may be true at E      the very high end. But we expect Merced to match or beat Alpha's G      performance on most applications (see MPR 10/27/97, p. 1), leaving C      little space for Alpha. With Merced in the mix, sales of Alpha B      systems have nowhere to go but down from their already modest      levels.  C      Digital could ease its customers' conversions by developing an F      Alpha-to-IA-64 binary translator. This would be much simpler thanG      the company's current x86-to-Alpha product, FX!32 (see MPR 3/5/96, F      p. 11), because of the more straightforward nature of Alpha code.F      Digital executives would not commit to developing such a product,8      but the company clearly has the expertise to do so.  D      Digital denies any plans to phase out Alpha and in fact has notE      given up its quest to move Alpha into the high-volume PC market. D      But the company's inability to deliver the low-cost 21164PC andD      the market's unenthusiastic response to FX!32 have left DigitalD      unable to sign any significant PC makers for Alpha, despite theC      support of chip makers Mitsubishi and Samsung. Without Digital E      Semiconductor, the company will have no sales force dedicated to @      Alpha chips, making it even more difficult to find new chip      customers.   C      Intel must be counting on Digital to move away from Alpha: the F      company has agreed to provide leading-edge fabrication technology;      to a chip that will be Merced's toughest competitor on D      performance, an arrangement that doesn't make sense in the long?      term. Although Digital CEO Robert Palmer has been an Alpha E      champion, Digital's board of directors is reportedly in favor of E      jettisoning Alpha, a stance that may have enabled the settlement %      (see sidebar at end of article).   ( StrongArm May Slip Through Intel's Grasp  G      Since Digital dumped its entire semiconductor operation in Intel's C      lap, Intel is now trying to decide what to do with the various F      pieces. Digital's lesser-known products include PCI-to-PCI bridgeB      chips and 10/100-Mbit Ethernet interfaces, some of which haveD      become popular in some circles. These devices should easily fitF      into Intel's existing product lines and support Intel's objective=      of supplying silicon for high-end systems based on Intel       processors.  C      StrongArm is a different story. This inexpensive chip (see MPR =      2/12/96, p. 1) is one of the fastest embedded processors @      available, but its power consumption is low enough for manyF      portable devices. As such, it is a perfect complement for Intel'sG      current embedded offering, the i960, which is expensive, slow, and G      power hungry. Whereas the i960 made its name in laser printers and A      other office equipment, StrongArm is ideal for PDAs, set-top "      boxes, and network computers.  F      There's the rub. Intel's corporate strategy is that every productE      should enhance the PC. Even the i960 has recently been recast as G      an I/O processor for high-end x86 servers. Adding another embedded G      processor that isn't PC compatible could be a needless distraction       for Intel.   A      Worse yet, StrongArm conflicts with some of Intel's existing D      PC-based initiatives. For example, Intel is promoting x86-based?      reference designs for network computers and set-top boxes, F      products where StrongArm-based chips such as the SA-1100 (see MPRB      9/15/97, p. 1) are technically superior to the x86 offerings.  ?      A third strike against StrongArm is its use of a non-Intel >      architecture. Among the assets being acquired by Intel isD      Digital's ARM license; although Intel says some details must be@      worked out, we expect ARM would be happy to let Intel buildD      StrongArm chips. But Intel has never used an instruction set it>      didn't own, and NIH (not invented here) is the prevailing+      mentality at the microprocessor giant.   C      If Intel decides it is interested in making an aggressive move F      into emerging consumer-electronics markets, however, StrongArm isA      the perfect vehicle. An Intel StrongArm (two words that seem ?      natural together) could dominate the market for Windows CE D      devices, creating a new Wintel axis. These products could offerC      incremental revenue growth to the company, albeit with smaller B      margins than for x86 processors. Intel must decide whether toC      maintain its shaky position that the PC is the solution to all F      problems, or take advantage of a fortuitous opportunity to launch"      a new processor product line.  - New Fab Could Aid Intel's Graphics Initiative   ?      Intel plans its fab capacity years in advance, so a sudden ?      decision to buy a fab is unusual. In fact, Intel has never ?      purchased a fab before, although it has relied on external E      foundries for cache and other peripheral chips. The initial idea E      for Intel to purchase the Hudson fab probably came from Digital, G      but Intel could have simply resold the excess fab capacity or used G      it as-is for older products (chip sets, etc.). Instead, Intel says E      it hopes to ramp the Hudson fab to full capacity after upgrading :      it to the company's leading-edge 0.25-micron process.  ?      One theory is that Intel underestimated the demand for its F      0.25-micron capacity during its initial planning cycle and neededF      a quick fix. Certainly, the company has been capacity constrainedF      recently (see MPR 4/21/97, p. 3), but those limitations appear toE      be easing already. The Hudson fab probably won't start producing E      0.25-micron Intel chips before 3Q98, too late to help accelerate "      the conversion to Pentium II.  >      Another use for the new fab could be for Intel's graphics?      initiative. Intel's initial 0.25-micron fab plans may have D      neglected graphics chips, assuming they could be built on olderE      fabs. It is now apparent that competitive 3D graphics chips will D      require 0.25-micron technology. If Intel is able to grab 10% ofD      the PC graphics market in 1999, these chips could consume up toE      half the capacity of the Hudson plant, with at least some of the %      rest devoted to Digital's needs.   A      In any case, the new plant gives Intel an enormous amount of F      0.25-micron capacity. The plan now includes five fabs running theG      0.25-micron process (Santa Clara, Chandler, Albuquerque, Leixslip, F      and Hudson), compared with just three for the current 0.35-micronB      process. One benefit of the Hudson purchase is that Intel canG      delay the build-out of its planned Ft. Worth (Texas) fab from 1999 D      to 2000. That plant was originally planned as a 0.25-micron fab1      but will now start at the 0.18-micron level.    Getting Approval May Be Dicey   D      The settlement is on hold until it is approved by both the U.S.E      Federal Trade Commission (FTC) and the judges presiding over the D      suits. To gain FTC approval, the parties must show that the newD      arrangement does not diminish competition in the microprocessorG      market. If Digital were to admit that it plans to phase out Alpha, F      the FTC would almost certainly refuse to let the deal go through.  @      Thus, the dichotomy between Digital's public statements and>      private comments. In particular, Palmer and other DigitalC      executives have taken a strong public position that Alpha will G      continue well into the future and is actually helped by this deal. C      Of course, this stance is necessary to protect Digital's Alpha F      business until Merced systems are available, but it also paints a=      picture that the FTC wants to see. Similarly, Intel will F      undoubtedly refuse to make any negative comments about the future@      of StrongArm until the deal is complete, a process that the1      companies expect will take up to six months.   D      The FTC is already investigating Intel's business practices, inD      part because of the heavy-handed way it originally responded toB      the Digital suit, and has a separate investigation of Intel'sF      agreement to purchase Chips and Technologies (see MPR 8/25/97, p.F      4). Its examination of the new agreement may take several months,F      but given the agency's unwillingness to hold up such deals in theA      past, this one seems likely to ultimately get a green light.   D      Although Intel will not admit guilt, of course, the form of theD      settlement implies the company was concerned that Digital couldE      prove patent infringement. Typically, patent cross-license deals E      are not royalty bearing: both companies simply exchange patents. G      In this case, however, Intel reportedly agreed to pay Digital $200 @      million over four years in addition providing access to itsC      patents. Intel has also granted Digital the prestigious Tier 1 F      discount status; because of its moderate x86 volumes, Digital hasF      been in Tier 2, although the companies would not confirm any suchE      details of the agreement. Intel doesn't want any royalty paymentc=      to be reported, since it might encourage other lawsuits.   D      The settlement clearly weakens a threat to Intel's product line@      and strengthens IA-64's hold on the high-end system market.E      Digital characterizes the change as a win for Alpha, but in facttA      it is likely to ultimately remove Digital from the processoro>      business, a tragic fall for the company that invented theB      minicomputer more than 30 years ago. And so, we move one stepC      closer to a world in which all significant computers are built !      using Intel microprocessors.n  2                             The Making of The Deal  E        When Digital first sued Intel (see MPR 6/2/97, p. 26), Intel's @        motivations were obvious: make the suit go away before itG        jeopardized the enormous revenue stream from Intel's Pentium and8>        Pentium II products. Yet the company was eager to avoidG        appearing to make a large payment to settle the suit, since that >        might seem to be giving in to patent blackmail and thus        encourage similar suits.a  G        Digital's motivations for its suit were less apparent. ObtainingnG        some payment from Intel is clearly a benefit for the financiallyt@        weak company. The patent cross-license gives Digital moreF        flexibility in its future processor designs and settles Intel's+        counterclaim of patent infringement.   E        At some point in the talks, Digital's semiconductor operations B        came into play. Digital has long maintained its own fabs toE        build high-performance chips for its computer systems, but thehC        Hudson fab was too large for the modest number of chips that C        Digital currently requires. Digital set up its semiconductoraE        business in 1993 to develop and sell chips on the open market,hE        hoping to create enough demand to fill the fab. Unfortunately,eD        neither the Alpha processors nor Digital's other chips becameF        big sellers, leaving the semiconductor operation losing as much7        as $100 million a year, according to one report./  A        Furthermore, Digital's board of directors, along with some <        executives in the systems group, had allegedly becomeB        disenchanted with Alpha. Despite its technical superiority,C        Alpha has not caused Digital's system sales to surge, and noo@        other large computer vendor has adopted the architecture.@        Substituting Intel's IA-64 technology for Alpha would cutB        Digital's costs while providing access to industry-standard        hardware and software.a  E        Digital can't convert to IA-64 immediately, since Merced won'tiD        ship for two years, and Digital has a large installed base ofC        Alpha customers. Thus, Intel had to commit to building AlphaeD        chips during a potentially lengthy transition period. SourcesG        indicate Intel is required to supply Alpha chips for up to sevend
        years.>  C        Thus, the agreement lets Digital get rid of its unprofitablerB        semiconductor operation and focus on its primary mission ofC        providing high-performance computer systems and service. ThedB        lawsuit had chilled Digital's relations with Intel, but nowF        Digital has unfettered access to all of Intel's products again.  B        Intel has managed to both eliminate a threat to its revenueE        stream and bring Digital on board as an IA-64 customer, a moveuF        that, before the first IA-64 chip even ships, almost guaranteesD        Merced will become the leading processor for high-end systemsC        (see MPR 11/17/97, p. 28). Intel also gains a useful fab forhF        merely book value. Compared with Intel's $8 billion cash hoard,>        the cost of settling the suit is, in the words of Intel/        president Craig Barrett, "not material."U  H ------------------------------------------------------------------------     --  
 Paul Sture   ------------------------------  % Date: Thu, 27 Nov 2003 20:32:10 +0100h* From: Paul Sture <nospam@sture.homeip.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday0 Message-ID: <3FC65F4A.6026054B@sture.homeip.net>   <snip>    $ > The bottom line with Alpha was/is: > M > Had Digital/Compaq done serious marketing of the operating systems that ranoH > on top of Alpha, then there would have been sufficient sales volume to1 > justify further funding & development of Alpha.c > N > On a technical basis alone, the fact that the 'guts' of EV79 & EV8 are goingM > to be incorporated in whole or in part into forthcoming generations of IA64eK > variants is sufficient proof that Alpha was more than technically viable.n > I > The 'failure' of Alpha is strictly a failure in marketing & advertisingeN > caused by a failure of executive decision making. And those same advertisingN > & marketing failures of the Digital/Compaq era continue to be evident in theI > HP regieme, also caused by the same root problem - failure of executiveII > decision making. However this time around it probably won't be the chipa3 > which is killed....it'll be the operating system.t  G This is what Linley Gwennap (always predicting that Alpha wouldn't make 7 it as far as I recall) was predicting in November 1997:   9 http://www.ife.ee.ethz.ch/~baerti/generalinfo/111501.htmll  H Just a snippet follows, as the article is long. Read the rest for a more complete story.r   "    Interest in Alpha Will Wanet  H In the long term, we suspect Digital will phase out its Alpha line. OnceH the company begins selling Merced systems in 1999, interest in the AlphaB boxes is likely to wane. Digital said it will port Digital Unix toB IA-64, and Microsoft has already announced plans for Windows NT onE Merced, so nearly all of Digital's workstation customers and at least.C half of its server customers will be able to move easily to the new G Intel-based systems. (Digital's other customers use OpenVMS, which willy probably remain on Alpha only.)e  E Digital insists its Alpha chips will maintain a performance edge overcF Merced on at least some applications, and this may be true at the veryF high end. But we expect Merced to match or beat Alpha's performance onD most applications (see MPR 10/27/97, p. 1), leaving little space forH Alpha. With Merced in the mix, sales of Alpha systems have nowhere to go* but down from their already modest levels.  > Digital could ease its customers' conversions by developing anE Alpha-to-IA-64 binary translator. This would be much simpler than the F company's current x86-to-Alpha product, FX!32 (see MPR 3/5/96, p. 11),A because of the more straightforward nature of Alpha code. DigitalhA executives would not commit to developing such a product, but thee+ company clearly has the expertise to do so.h  H Digital denies any plans to phase out Alpha and in fact has not given up? its quest to move Alpha into the high-volume PC market. But the D company's inability to deliver the low-cost 21164PC and the market'sE unenthusiastic response to FX!32 have left Digital unable to sign any C significant PC makers for Alpha, despite the support of chip makers G Mitsubishi and Samsung. Without Digital Semiconductor, the company willmA have no sales force dedicated to Alpha chips, making it even morea% difficult to find new chip customers.s  F Intel must be counting on Digital to move away from Alpha: the companyH has agreed to provide leading-edge fabrication technology to a chip thatH will be Merced's toughest competitor on performance, an arrangement thatG doesn't make sense in the long term. Although Digital CEO Robert PalmermF has been an Alpha champion, Digital's board of directors is reportedlyA in favor of jettisoning Alpha, a stance that may have enabled thek, settlement (see sidebar at end of article)."      -- g
 Paul Sture   ------------------------------  % Date: Thu, 27 Nov 2003 16:34:41 -0800.* From: "Jack Peacock" <peacock@simconv.com>J Subject: Re: Thanksgiving in France (was: First FutureVAX benchmark tests)2 Message-ID: <fLCdnY4gMNa_BVui4p2dnA@mpowercom.net>  / "Didier Morandi" <no@spam.com> wrote in message_. news:3fc63e2a$0$27031$626a54ce@news.free.fr...  K > I went to my Harraps and found that Thanksgiving is a national holiday in2 thetL > USA and Canada. I thought it was on the 4th of July, the Independence Day. Youn& > have more than one national holiday? >sI A national holiday means it's a federal holiday in every state.  It's notCI the same as the national day (our July 4th).  Individual states also have J their own holidays.  In Nevada we have Admission Day (on Halloween), which@ celebrates Nevada becoming a state during the Civil War.  In theI southeastern US there are War Between The States (another name for the US.E Civil War) holidays for Confederate Memorial Day and Jefferson Davis' / Birthday (President of the Confederate States).T  F US Thanksgiving is the traditional start of Christmas shopping season.K Canada has their Thanksgiving a month earlier...they need the extra time tou* drive through the snow to reach the malls.  I My Xmas shopping is already complete, an authentic DEC RZ26 drive for theuF old VAX 3100, to replace the 3rd party drive and restore it to all DEC parts.    Jack Peacockd   ------------------------------    Date: 27 Nov 2003 18:03:40 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) G Subject: Re: VEST bug (or VEST feature, depending on one's perspective)_3 Message-ID: <4G9zUNWFAQ5m@eisner.encompasserve.org>   Y In article <3fc63ab1$0$27026$626a54ce@news.free.fr>, Didier Morandi <no@spam.com> writes:c > Larry Kilgallen wrote: > 9 >> What makes you think any of those messages are wrong ?- > F > Wrong? Who said so? The question is: "why do I have these messages".  H To me the title "VEST bug" sounds like you are saying something is wrong
 with VEST.  J >> Have you read the documentation and created the Hints files correctly ?H >> In particular, if those are data areas VEST will issue those messages8 >> until you have properly constructed your hints files. > R > I did not read the doc. I thought VEST will translate or not translate. I never 0 > heard of the HINTS files. I will read the doc.  E VEST is very far from being a simple program, and the VESTing of TECOuG would not have been possible without explicit hints.  On the other handuH attempting to build TECO with AMACRO had parts that just would not work.   ------------------------------  + Date: Thu, 27 Nov 2003 21:55:55 +0000 (UTC)-P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)" Subject: Re: [OT] For David CATHEY$ Message-ID: <bq5rtb$4si$1@online.de>  O > In light of SPAM, operating your own SMTP server really does require that youi, > understand what goes on behind the scenes. > O > The problem with VMS (and its documentation) is that it assumes that you haveiP > a "real" internet connection with fixed line that is always up, same fixed IP,K > at least 2 nodes running your own DNS server accessible to the world etc.t > L > In reality, small business is behind a NAT firewall (which means local DNSO > can't be used because VAX-VMS doesn't support BIND 9), so it makes thing veryiK > interesting since the SMTP server doesn't quite exist on the internet, itfN > exists in your intranet and you need to fiddle with a few more things to get
 > it to work.e  G There ARE companies which, for a reasonable fee (well within the budgetoG of any business), offer really good DNS services, even for dynamic IPs.oC The company I use offers an SMTP relay server as part of their moremC expensive (but still cheap, in absolute terms) packages, which doesc> authentication based on IP.  Other schemes, such as using SMTPB authentification or using a certain type of From: address, are notG acceptable for me, for a variety of reasons.  Since they of course knowfC who has a given IP address at any time, and log their SMTP servers,2E spammers can be immediately identified.  The outside world sees emailhF coming from their SMTP server, which as far as I know is on know blackG list (certainly I've never had any problems with it).  They also have a @ really nice domain-hosting service.  They also off a "heartbeat"H service: if you go offline for more than X seconds, your DNS entry will H go to an "offline" IP.  As far as I know, web pages only in German, but H they're such a good company it's worth learning German just to become a / customer, I can't recommend them highly enough:n      http://www.dynaccess.de/e   ------------------------------  % Date: Thu, 27 Nov 2003 20:51:58 +0100r" From: Didier Morandi <no@spam.com>6 Subject: [OT] The President of the USA in Bagdad today4 Message-ID: <3fc65608$0$27027$626a54ce@news.free.fr>    In case you did not watch CNN...  2 That's a piece of joice for these poor GI fellows.   D.   ------------------------------  % Date: Thu, 27 Nov 2003 15:21:57 -0500t$ From: Hein <hein_cov@eps.zk.dec.com>: Subject: Re: [OT] The President of the USA in Bagdad today. Message-ID: <3FC65CE5.CC9BA35E@eps.zk.dec.com>  H Oh please, not an other [OT] , what makes you think that any reader here cares?G And if even if they do care, why annoy the rest of us with reminders ofo that soap-opera.  F No disrespect intended Didier, but please stick to VMS (and future vax if you really have to.) E The noice level is bad enough now with this 'JF Mezei' crap going on,D that and the endless,nE relentless, TPC - AMD - SUN threads (threats!)  with the same players  and arguments over and over.  1 Please folks, let's all try to ignore the noise.. E ( yes, please do not reply to this reply either, You probably know myr& Email if you desperatly need to flame)   Sorry... couldn't help myself. Cheers,d Hein.s   Didier Morandi wrote:s  " > In case you did not watch CNN...4 > That's a piece of joice for these poor GI fellows. >f > D.   ------------------------------  % Date: Thu, 27 Nov 2003 22:04:59 +0100e" From: Didier Morandi <no@spam.com>: Subject: Re: [OT] The President of the USA in Bagdad today4 Message-ID: <3fc66724$0$27043$626a54ce@news.free.fr>  
 I promise.   D.   Hein wrote:h  J > Oh please, not an other [OT] , what makes you think that any reader here > cares?I > And if even if they do care, why annoy the rest of us with reminders ofs > that soap-opera. > H > No disrespect intended Didier, but please stick to VMS (and future vax > if you really have to.)l   ------------------------------  # Date: Thu, 27 Nov 2003 21:15:20 GMT 3 From: Jack Patteeuw <jjpatteeuw@earthlink.nospamme> : Subject: Re: [OT] The President of the USA in Bagdad todayC Message-ID: <IPtxb.24694$Wy4.6886@newsread2.news.atl.earthlink.net>e  E Yep, pretty cool.  Take Air Force One out for a little "joy ride" to t9 boost moral.  Best thing I've seen W do in a long time !!    ------------------------------   End of INFO-VAX 2003.659 ************************r four years in addition providing access to itsC      patents. Intel has also granted Digital the prestigious Tier 1 F      discount status; because of its moderate x86 volumes, Digital hasF      been in Tier 2, although the companies would not S/TR`>3b'Kbsh'6R]5@9o)U,TsHb|>eo3q`Q]VNCcY6$L	uf&|ȍcpE-Ɛ$#m48bծb#ye{~n
BFQhyS̀]^]}~ < 銋G8v,|woH`TG/qRX2"b(DGdpB8?}岐A}p!b'	4LΉHK_! \S|B2>f
\W[^EH\^&A=Fμ1mWlC^_ya-ЧDv)ӋOD*!R1]i@gcN_j#艩k-MQ`x諸 
ş_}F-
11kHS{jmB_y;4.3\wןopJReQ5Ӛ
,bsi|v%"q-H;/>9L)APALw
h{:\QL	IFEIL֟_0Y12F~,9:eHFNf'$n#~4Ϩi)|[SԞ59bY*lÌ_u;Rf;htvHU$[$j~r7'Rw{'zoKؙ.+>*%MMZ\j8U͹ !Y]UfߜX[WMrrϫޣ~U46ECQ~sg(ٮb瘆r@,P@smHiٹE+tJ
?jޜɸOg.03.V]eP XiK@U["|uиú