1 INFO-VAX	Sun, 27 Apr 2003	Volume 2003 : Issue 232       Contents:8 Announcing May 13th Meeting of WRUG LUG (Cleveland area) Re: Fortel go bye-bye! Re: Gordon Bell interview  Re: Gordon Bell interview  RE: Gordon Bell interview = Re: How Alpha will save Itanium - must reading for Bill Todd! = Re: How Alpha will save Itanium - must reading for Bill Todd! = RE: How Alpha will save Itanium - must reading for Bill Todd! H Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyH Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyH Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyH Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyH Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyP Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopoly monopol  Re: Johnny English is a VMS user Location of ANUNUEWS Re: Location of ANUNUEWS6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham!G Re: [DECnet-Plus V7.3-1 ECO2] What has happened to the DECNET_VERSION ? G Re: [DECnet-Plus V7.3-1 ECO2] What has happened to the DECNET_VERSION ? G Re: [DECnet-Plus V7.3-1 ECO2] What has happened to the DECNET_VERSION ? J Re: [DECnet-Plus V7.3-1 ECO2] What has happened to the DECNET_VERSION ? ??7 Re: [SYSMAN, TCPIP] Unprintable Chars switches terminal   F ----------------------------------------------------------------------  % Date: Sun, 27 Apr 2003 09:39:27 -0400 / From: "Joe H. Gallagher" <dtrwiz@ix.netcom.com> A Subject: Announcing May 13th Meeting of WRUG LUG (Cleveland area) - Message-ID: <3EABDD82.144C5336@ix.netcom.com>    Announcing May 13th Meeting -                   Western Reserve Users Group .                  Local User Group of Encompass                   L               (different time and different place)                           ' Topic: Alpha, VAX, and OpenVMS Roadmaps   8    Rich will discuss the Alpha, IPF and OpenVMS roadmaps<    including some of the newly announced systems such as the     DS25, ES47, ES80, and GS1280.  :    HP is announcing end of service life plans for some VAX>    systems. Some details of these plans and their implications    will be discussed.   <    The OpenVMS Operating system continues to be enhanced and@    updated.  The latest news, update, and features of OpenVMS as?    well as the current status of Itanium migration will also be 
    discussed.   * Speaker: Richard Pearlman, Hewlett-Packard  ?    Richard Pearlman is a veteran of HP/Compaq/Digital with more 5    than 25 years of experience.  He is the Tru64 UNIX =    Ambassador and OpenVMS Ambassador for western Pennsylvania =    and Eastern Ohio.  Rich is the Counterpart for WRUG; he is "    based in the Pittsburgh office.  5 Topic: Secure Email and Document Handling Environment   6    This presentation will discuss HIPAA infrastructure>    mitigation guidelines and introduce a solution alternative;=    the product, Probix, and the new Microsoft XrML standard.  ;    With the new HIPAA requirements and GLB audits, document >    security is a continuing and increasingly important issue. ?    The goal is to provide a secure email infrastructure and the /    means to protect your intellectual property.     : Speakers: Stephen Decatur, Trend Consulting Services, Inc."           Tom Barrett, Probix Inc.
           <    Steve Decatur has more than 26 years in operating systems=    and networking.  Steve holds CCIE Cisco Certified Internet ?    Engineer CNX Certified Network expert (Sniffer Technologies) 6    CISSP, CISSA Certified Information Systems Security;    Professional and Analyst MCSE+I 2000 Microsoft Certified ;    Systems Engineer (plus Internet) GIAC Certified Firewall =    Analyst (GCFW)GIAC Certified Intrusion Analyst (GCIA) GIAC >    Certified Incident Handler (GCIH), CCIPT Cisco Certified IP=    Telephony certifications and is active in the WRUG as well :    as FIRST, SANs, CSI, the ACM and IEEE Computer Society.6    Steve is President and co-owner of Trend Consulting<    Services, and specializes in network design, security and    engineering.      /    Tom Barrett is Vice President of Probix Inc.       Note:   :    All who attend LUG meetings during April and May have a?    chance (raffle) at a significant door prize.  Attendees will >    automatically be entered in a nation-wide raffle for one or<    more free registrations to HP World in August in Atlanta,=    Georga.  Exact details of eligibility and transferability  =    will be available at the meeting.  The raffle is sponsored     by Encompass.      Topic:  =    We will also have a brief discussion about future meeting      times and dates.                            Date:     Tuesday, May 13, 2003   Time:     4:00 to 7:00 PM 
 Location: %    in the building with the HP office     ParK Center Plaza III    Lower Level conference room    6050 Oak Tree Blvd.    Independence, OH 44131 ;    (Call Rich's cell phone at 412-999-6427 if you get lost)  Map:   http://maps.yahoo.com/py/maps.py?Pyt=Tmap&ed=fHlg.Op_0Tp8cAk9FEnXFaJqwLrgHNEVHj2ZCgpRheC5zhYBRpY17CQ9e.8MEG4Q_RbNxpVrgvTpiJ6tD1A.32U6&csz=Independence,+OH+44131-6927&country=us&cs=9&name=&desc=&poititle=&poi=&uz=44131&ds=n&BFKey=&BFCat=&BFClient=&mag=9&ne        Directions: C    From the area of the interchange of I-480 and I-77, go south and !    take the Rockside Road exit.    >    At the bottom of the ramp, turn right (west) on Rockside.   L    Go west two blocks (second light); turn left (south) on Oak Tree Blvd.     See the LUG's web page at   &     http://eisner.decus.org/lugs/wrug/      See you at the meeting.    Joe H. Gallagher WRUG LUG Chair0 dtrwiz at ix dot netcom dot com                   ------------------------------   Date: 27 Apr 03 15:15:03 +0200) From: p_sture@elias.decus.ch (Paul Sture)  Subject: Re: Fortel go bye-bye! ) Message-ID: <KnjjHhKgxE7w@elias.decus.ch>   V In article <3EAAD5FA.11E94C5F@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes: > "prosullivan@aol.com" wrote:A >> Which does not quite tally with the website: www.fortel.com...  > M > But www.fortel.com's front page sure doesn't look like a company which will O > continue to exist.  Looks like divestcap called one guy told him he was fired O > in 20 minutes and his last task was to put up that message on the fortel web   > site.  >   J Not even 20 minutes at my guess. A copy and paste into MS Word. The sourceE shows a TotalTime field of 2, though I don't know what the units are.   N > Interestingly, I haven't seen any press releases. DivestCap's web site makesO > no mention of Fortel. DivestCap's web site is all about getting rid of assets , > (divestiture). Nothing about growing them.  # The original Press Release is here:   2 http://www.fortel.com/Press/Releases/Acquired.html  # And if that should disappear, here:   @ http://news.findlaw.com/prnewswire/20030318/18mar2003025906.html   --  
 Paul Sture   ------------------------------  # Date: Sun, 27 Apr 2003 13:09:20 GMT " From:   VAXman-  @SendSpamHere.ORG" Subject: Re: Gordon Bell interview0 Message-ID: <00A1F025.2AB55C12@SendSpamHere.ORG>  _ In article <slrnbamkpt.clk.dsf@gaia.roc2.gblx.net>, Dan Foster <dsf@globalcrossing.net> writes:  {...snip...}K >Not meant to badmouth the engineers' hard work; in fact, I find their work L >to be incredible and pretty well done. But overall direction seems to oftenO >be determined by higher-level human beings who may be somewhat less influenced - >by technical factors than personal dynamics?     There are levels of human being?   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  # Date: Sun, 27 Apr 2003 13:19:42 GMT 3 From: wallacethinmintr@eircom.net (Russell Wallace) " Subject: Re: Gordon Bell interview0 Message-ID: <3eabd819.143207208@news.eircom.net>  4 On Sun, 27 Apr 2003 03:49:14 +0000 (UTC), Dan Foster <dsf@globalcrossing.net> wrote:   I >So... maybe folks are looking at the Alpha vs Itanium/Opteron debates in J >the entirely wrong light? That perhaps a lot of personalities 'behind the& >scenes' are driving this whole thing?  D Well, yes. The decision to replace Alpha with Itanium had nothing toF do with technical merit (Alpha is probably the better design) but withB the fact that neither Capellas nor Fiorina wanted to be in the CPUE business. And the single most important reason for preferring Opteron A over Itanium in turn, is that standardizing on Itanium would give E Intel a government-enforced monopoly whereas AMD have declared x86-64  an open standard.    --   "Sore wa himitsu desu."  To reply by email, remove  the small snack from address. ! http://www.esatclear.ie/~rwallace    ------------------------------  % Date: Sun, 27 Apr 2003 10:01:02 -0700 # From: "Tom Linden" <tom@kednos.com> " Subject: RE: Gordon Bell interview9 Message-ID: <CIEJLCMNHNNDLLOOGNJIAEDAHBAA.tom@kednos.com>   H Yes, it was interesting.  Egos are a tremendous obstacle to progress andK I think that Digital is a good example of that axiom.  The RISC/CISC debate K was always foolish, because it lost sight of the mission.  CISC development J suffered during the fat years and wrt to the Fundemental Law of Computers:  J Computers are never fast enough.  If an archticture doesn't follow Moore's. Law it will be replace by something that does.  L RISC offered some advances, but it did require more sophisticated compilers.J Much of the mini computer industry was launched on the 2901 bit slice from
 AMD (1975)H and that was a micro-coded architecture in which various companies builtK their own instruction sets, Prime even had two. one based on an accumulator  architectureJ (V-mode) and the other on a general set of registers (I-mode)  RISC is theI modern equivalent.  But now the pendulum has swung again and CISC is fast  again.  At the core G of the Pentium is a micro-coded RISC-like machine based on an 801 style 
 architecture, K or at least it was a few years ago.  I think that micro-coding is a seminal  event I in this history.  Probably shouldn't leave out the TI 74181/2, which were  ubiquitouslyL used in minis.  I think the real value of Itanium for HP is that it puts the focus H on the software as the core asset.  Unfortunately, there is no installed base to sellL into but HP has to grow the market.  If it were me, I would also have ported VMS to Pentium, maybe even Opteron.  H I took over Translation Systems from Bob Freiburghouse in 1981, which at	 that time E had as assets a sophisticated compiler technology that included PL/I,  Fortran and C Pascal, and later expanded to include Cobol, Basic and C.  PL/I had  previously been I licensed to Digital in 1978 for the VAX and was implemented by Cutler and  his teamG and resulted in a book "Engineering a Compiler: VAX code generation and 
 Optimization" K We set about to port the compilers by building code generators intially for  the NationalF 16032 (later renamed 32032, upon my suggestion).  We needed a delivery vehicle for the L compilers, so in February of 1982 I wrote a letter to Ken Olsen requesting a
 license toH VMS, which we would port.  I cited as arguments the advent of the PC and Unix, which atH that time ran on just under 10% of all VAXes, with the prognosis that it would be 50%L in a few years.  Several months later I received a letter back, from Knowles (IIRC) that K it had provoked strong discussion, but in the end nixed by KO.  We ended up 
 using BSD 4.1    Tom    >-----Original Message----- 1 >From: Dan Foster [mailto:dsf@globalcrossing.net] ' >Sent: Saturday, April 26, 2003 8:49 PM  >To: Info-VAX@Mvb.Saic.Com >Subject: Gordon Bell interview  >  > 4 >http://americanhistory.si.edu/csr/comphist/bell.htm > I >A quite interesting one from someone who, as you know, was very involved J >with the VAX design and with Digital in general. Has a lot of interestingK >things to say about Mr. Olsen, about the company (and others), about forks I >in design paradigms (RISC vs CISC for one), about what Alpha represented  >compared to the VAX.  > L >I found it interesting and timely in face of the current hullaboo about the* >Alpha vs Itanium (vs Opteron) transition. > I >A lot of the current discussion is somewhat framed in technical issues - G >which I would expect no less from engineers, and somewhat in political K >issues. But Mr. Bell's statements makes me think that a lot of the changes J >in computing are more attributable to human dynamics as the driving force5 >rather than any reasoned technical arguments per se.  > I >So... maybe folks are looking at the Alpha vs Itanium/Opteron debates in J >the entirely wrong light? That perhaps a lot of personalities 'behind the& >scenes' are driving this whole thing? > K >Not meant to badmouth the engineers' hard work; in fact, I find their work L >to be incredible and pretty well done. But overall direction seems to often? >be determined by higher-level human beings who may be somewhat  >less influenced- >by technical factors than personal dynamics?  >  >-Dan  >  >---' >Incoming mail is certified Virus Free. ; >Checked by AVG anti-virus system (http://www.grisoft.com). A >Version: 6.0.471 / Virus Database: 269 - Release Date: 4/10/2003  >  --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.471 / Virus Database: 269 - Release Date: 4/10/2003   ------------------------------  % Date: Sun, 27 Apr 2003 02:23:13 -0400 * From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: How Alpha will save Itanium - must reading for Bill Todd!2 Message-ID: <i42cnRPk-rjJ6jajXTWcqw@metrocast.net>  3 >"Main, Kerry" <Kerry.Main@hp.com> wrote in message L news:BE56C50EA024184DAF48F0B9A47F5CF4040ECFF2@kaoexc01.americas.cpqcorp.net. ..A > > By George, Bob, you've finally come around to the conclusions  >> I reached= >> nearly two years ago when people like you, Kerry, and Mark  >> Gorham (the last I >> as reported by Alphaman) were spewing nonsense about an Alpha-enhanced > >> 'IA64-2' or 'combined Alpha/IA64' (that would be *required* >> for VMS to run I >> on) appearing by the time the VMS port was completed (i.e., clearly by = >> 2004), thus avoiding the need for an EV7 shrink to 130 nm.  >  > Bill,  >   > Rewriting history are we know?  L No, nor will I allow you to do so.  BTW, your news messages still seem to be screwed up, in terms of being K formated in a manner that Outhouse Express doesn't quote well in responses.    > :-)  > I > I never stated anywhere that that an IPF design with "Alpha influenced" I > features would be *required* for VMS to run when it was first ported to  > IPF. > G > Go for it - do your google stuff and try and find a post from me that D > stated it was a *requirement* that had to be there by 2004 for the > initial OpenVMS release.  J While my statement above was to some degree an amalgamation of some of theL nonsense being spewed at the time, I think I can find sufficient quotes fromC you to make me more than comfortable with it in your specific case.   
 Let's see:   6/25/01 (c.o.v. post):   quote:  G Alpha --> IA64-2 (or whatever the enhanced IA64 + Alpha architecture is  called)   
 end quote.  I The above was your characterization of the port customers would be making K with VMS - i.e., a port to some combined 'IA64 + Alpha' architecture rather ) than to the existing Itanic architecture.   J 6/25/01 - message to our VMS advocacy group (don't complain about exposureH of a semi-private communication:  you asserted above that you never made? such statements *anywhere*, and invited evidence to refute it):    quote:  L As a fyi, and again pure personal opinion, one needs to keep in mind that itJ is not IA64 that OpenVMS and Tru64 and NSK will be ported to, but rather a@ follow-on flavor of IA64 ie. IA64-2 (for lack of a better name).  F So, will IA64-2 more closely resemble IA64 or Alpha EV8? The answer isH likely somewhere in between, but it will almost certainly be a different9 chip architecture than what is available today as "IA64".   
 end quote.  I So while you don't say a new chip will be 'required' for VMS, you clearly B state that the chip it will be ported to will not be the same IA64K architecture known at that time, with the clear implication that the target 5 of the port will contain significant Alpha influence.   ! 6/25/01 (advocacy group message):    quote:  J Certainly, one advantage of going with IA64-2 (not current stuff), is thatD Compaq is re-affirming long term support for OpenVMS, Tru64 and NSK.  
 end quote.  H Again suggesting that the target of the port will be an Alpha-influenced Itanic.   ! 6/26/01 (advocacy group message):    quote:  G There is no way anyone in the newsgroup could have predicted that Intel I would adopt whatever Alpha features are required to make OpenVMS, NSK and K Tru64 work with its IA64-2 (or whatever they plan to call it) architecture.   
 end quote.  5 Note especially the use of the word 'required' above.   ! 6/26/01 (advocacy group message):    quote:  J As I've stated and as the press release has noted .. the IA64 architecture; will be updated to enable Tru64, OpenVMS and NSK to use it.   
 end quote.  H Note 'to enable' above (sounds like a 'requirement' to me), and your own9 reference to previous statements of yours to that effect.    6/27/01 (c.o.v. post):   quote:  I The reference to IA64-2 is simply to reflect the fact that OpenVMS, Tru64 K and NSK are not slated to be ported and run on todays intial release of the A IA64 platform, but rather a followon version of the architecture.   J As stated numerous times in the releases, todays IA64 technologies will beI integrated and upgraded with Alpha technologies to allow these OS's to be  ported.   
 end quote.  G Note especially the last sentence's clear indication that Alpha-related L upgrading would 'allow these OSs to be ported' (implying rather clearly that% the existing architecture would not).   ! 7/10/01 (advocacy group message):    quote:  K I obviously have only slightly (and emphasize slightly) more info / insight K than anyone on this list, however, given that the EV8 team is going to work J on the IA64+ (whatever flavour) that VMS, Tru64 and NSK runs on, it is notJ really  a big stretch to surmise that a good amount of EV8 technology (VMS: friendly?) will show up in subsequent generations of IA64.  
 end quote.  I Again, clearly indicating that the Itanic that the Compaq OSs will run on D will be the result of work by the EV8 team, not the earlier flavors.  ! 7/10/01 (advocacy group message):    quote:  G Again pure speculation on my part, but imho, given the short timeframes K announced to do the VMS/Tru64/NSK ports, one can only assume that MC either J does not realize how long it takes to do this stuff or the target platform will be very EV8'ish.   
 end quote.  L Speculation or not, it certainly makes it clear what you were suggesting the+ Itanic that VMS would run on would be like.   ! 7/13/01 (advocacy group message):    quote:  < Apologies if you this group has already seen this, but fyi -' http://www.theinquirer.org/13070103.htm J "SOURCES IN THE US suggest that current designs of of IA-64 processors mayI now be garotted to death inside Intel, to be replaced by Alpha technology ( masquerading under the Itanic cognomen."  J "The move may make the job of porting all those applications and operatingI systems Compaq will hang onto much easier, being as future generations of B the Itanic will really be the Alpha in disguise, the sources add."  
 end quote.  F You certainly seemed to be suggesting that the article at The InquirerI reflected some degree of reality (else why on earth would you have called H our attention to it?).  Note the implication that the new hardware wouldH appear in time to make the porting easier (i.e., that the software would require it to run).    ...   5 > My view has not changed from the beginning on this.   E It seems that your memory of your views may not be as accurate as you J imagine it to be.  Or that you were simply lying outright in the hope thatF I'd be too lazy to call you on it.  Regardless, do us all the favor ofH refraining from escalating this into an embarrassing public spectacle byJ further attempting to spin away your own words that I've taken the time to9 resurrect above:  they speak very clearly for themselves.    - bill   ------------------------------    Date: 27 Apr 2003 04:58:37 -0700( From: bob@instantwhip.com (Bob Ceculski)F Subject: Re: How Alpha will save Itanium - must reading for Bill Todd!= Message-ID: <d7791aa1.0304270358.297a22b9@posting.google.com>   d "Bill Todd" <billtodd@metrocast.net> wrote in message news:<7uCcnbVJT-JYXDWjXTWcpw@metrocast.net>...7 > "Bob Ceculski" <bob@instantwhip.com> wrote in message 9 > news:d7791aa1.0304241633.5f5d516e@posting.google.com... , > > here is how Alpha will save Itanium Bill > I > By George, Bob, you've finally come around to the conclusions I reached M > nearly two years ago when people like you, Kerry, and Mark Gorham (the last H > as reported by Alphaman) were spewing nonsense about an Alpha-enhancedL > 'IA64-2' or 'combined Alpha/IA64' (that would be *required* for VMS to runH > on) appearing by the time the VMS port was completed (i.e., clearly byJ > 2004), thus avoiding the need for an EV7 shrink to 130 nm.  See a c.o.v.N > post of 7/14/01 of mine for some specific references to that nonsense (CathyK > Stockwell was still spewing the same crap at a Diamond Forum over a month & > later - see c.o.v. post of 8/24/01). > N > In August, 2001, I predicted that the first possible appearance of any AlphaK > technology in Itanic would be in 2005:  still the same old McKinley-style H > core, but perhaps getting EV7-style on-chip glue to help it out (firstE > expressed in a private note on 8/19/01, then in multiple c.o.v. and L > comp.arch posts on 8/24/01).  This turned out to be over-optimistic, sinceL > the target procuct for 2005 is now Montecito, in a package compatible withN > McKinley/Madison and therefore clearly not containing any EV7-style goodies. > M > I also predicted that the first possible appearance of any Alpha technology N > such as OoO and SMT in the Itanic *core* would be in 2006 -7 (mentioned in aG > c.o.v. post of 7/20/01, and in multiple c.o.v. and comp.arch posts on K > 8/24/01).  These are indeed the dates now starting to be talked about for A > 'Tanglewood', the first product of the transplanted Alpha team.  > D > So, Bob, the only thing that's changed is *your* perception of theI > situation.  If you'd paid attention two years ago, you'd have seemed at 1 > least somewhat less of an idiot in the interim.  >  > - bill  B it will still use alpha technology ... if they can better the riscA 8 instructions by using epic with 4 or 8 bundles x 3 instructions ; per bundle, then that would be an improvement over risc ... < oopsteron is also using alpha technology, and Intel would be@ stupid not to do the same, use it or lose it ... and if you readB carefully, alpha may come back, a small chance, but still possibleA if Intel doesn't do the perscribed alpha enhancements to Itanium.    ------------------------------  % Date: Sun, 27 Apr 2003 11:19:17 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> F Subject: RE: How Alpha will save Itanium - must reading for Bill Todd!T Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4040ECFF4@kaoexc01.americas.cpqcorp.net>  
 Ahhh Bill,  F Still resorting to slimy tactics like pulling private conference notes into public forums eh?  H Ah well, others should make note of this great example of your integrity; when considering membership for future private discussions.   C Question - when you joined that forum that included a number of the D current active cov readers, did you or did you not agree to keep all$ conversations in that forum private?   Never mind - you did.=20  	 Right?=20   1 There are others in cov that will attest to this.   4 Question - what does the word *private* mean to you?  F You did *not* join that discussion group by saying "well, I'll keep itH private as long as I don't see an opprtunity to further my own agenga byC extracting information and posting it to a public areana like cov."   B I asked you to "do your google stuff .." and since that was not an? option which would support your agenda, you resorted to private 5 discussions (which still don't prove your assertion).   % And you are questioning my integrity?    ROTFL.  D Having stated this, there is nothing in the attached which quotes meB saying an Alpha inflence was *required* for OpenVMS to ship in the initial releases of OpenVMS.=20   G In addition, my involvement in that group was 100% above board as I did C not state anything there that could not have been stated on cov. In C fact, I did not even change my regular .sig file for all responses.   E Keep in mind that IPF at the time that newsgroup was going on was the G Merced release (IPF-1 in my words). We are now seeing Madison (IPF-2 in A my attached words) based systems. In all likelihood, most regular H OpenVMS Customers will actually be testing a post-Madison version of IPFH (IPF-3 using my words). In addition, for larger production environments,H most will likely be implementing on a Montecito and Tanglewood chip sets! (IPF-4, IPF-5 using my words).=20   G Given that it will take time for most OpenVMS Customers to migrate (how H many VAX Customers are there today?), the 2006-2008+ timeframe is likelyB when most of the real Customer OpenVMS porting activity will startG happening. At that time, the Montecito and Tanglewood chip sets will be 
 available.  G This is not unlike Customers porting / testing their applications on an E Alpha EV56, but planning to implement them on an Alpha EV68 or EV7 in  their production environment.   
 Reference:=20 1 http://www.theregister.co.uk/content/3/30411.html + "Tanglewood to run 10x faster than Madison" ? (ok, even if not 10 times, significantly faster is likely true)   D Again, if you take the time to read the attached replies without theG rose coloured glasses on, there is nothing in the attached which states " anything that I have to take back.  C However, feel free to keep pulling out those private notes from the  private forum.   Regards   
 Kerry Main Senior Consultant  Hewlett-Packard (Canada) Co.! Consulting & Integration Services  Voice: 613-592-4660  Fax   : 613-591-4477 Email: kerryDOTmain@hpDOTcom-     (remove the DOT's and replace with "."'s)  OpenVMS DCL - the original .COM    > -----Original Message-----4 > From: Bill Todd [mailto:billtodd@metrocast.net]=20 > Sent: April 27, 2003 2:23 AM > To: Info-VAX@Mvb.Saic.Com H > Subject: Re: How Alpha will save Itanium - must reading for Bill Todd! >=20 >=20 >=205 > >"Main, Kerry" <Kerry.Main@hp.com> wrote in message @ > news:BE56C50EA024184DAF48F0B9A47F5CF4040ECFF2@kaoexc01.america > s.cpqcorp.net. > ..C > > > By George, Bob, you've finally come around to the conclusions  > >> I reached? > >> nearly two years ago when people like you, Kerry, and Mark  > >> Gorham (the last ? > >> as reported by Alphaman) were spewing nonsense about an=20  > Alpha-enhanced@ > >> 'IA64-2' or 'combined Alpha/IA64' (that would be *required* > >> for VMS to run < > >> on) appearing by the time the VMS port was completed=20 > (i.e., clearly by ? > >> 2004), thus avoiding the need for an EV7 shrink to 130 nm.  > > 	 > > Bill,  > > " > > Rewriting history are we know? >=20@ > No, nor will I allow you to do so.  BTW, your news messages=20 > still seem to be > screwed up, in terms of being B > formated in a manner that Outhouse Express doesn't quote well=20 > in responses.  >=20 > > :-)  > > B > > I never stated anywhere that that an IPF design with "Alpha=20
 > influenced" > > > features would be *required* for VMS to run when it was=20 > first ported to  > > IPF. > > ? > > Go for it - do your google stuff and try and find a post=20  > from me thatF > > stated it was a *requirement* that had to be there by 2004 for the > > initial OpenVMS release. >=20@ > While my statement above was to some degree an amalgamation=20 > of some of the: > nonsense being spewed at the time, I think I can find=20 > sufficient quotes fromE > you to make me more than comfortable with it in your specific case.  >=20 > Let's see: >=20 > 6/25/01 (c.o.v. post): >=20 > quote: >=20< > Alpha --> IA64-2 (or whatever the enhanced IA64 + Alpha=20 > architecture is 	 > called)  >=20 > end quote. >=20> > The above was your characterization of the port customers=20 > would be making < > with VMS - i.e., a port to some combined 'IA64 + Alpha'=20 > architecture rather + > than to the existing Itanic architecture.  >=20@ > 6/25/01 - message to our VMS advocacy group (don't complain=20 > about exposureB > of a semi-private communication:  you asserted above that you=20 > never madeA > such statements *anywhere*, and invited evidence to refute it):  >=20 > quote: >=20A > As a fyi, and again pure personal opinion, one needs to keep=20  > in mind that it B > is not IA64 that OpenVMS and Tru64 and NSK will be ported to,=20 > but rather aB > follow-on flavor of IA64 ie. IA64-2 (for lack of a better name). >=20H > So, will IA64-2 more closely resemble IA64 or Alpha EV8? The answer isA > likely somewhere in between, but it will almost certainly be=20 
 > a different ; > chip architecture than what is available today as "IA64".  >=20 > end quote. >=20B > So while you don't say a new chip will be 'required' for VMS,=20
 > you clearly D > state that the chip it will be ported to will not be the same IA64@ > architecture known at that time, with the clear implication=20 > that the target 7 > of the port will contain significant Alpha influence.  >=20# > 6/25/01 (advocacy group message):  >=20 > quote: >=20? > Certainly, one advantage of going with IA64-2 (not current=20  > stuff), is that F > Compaq is re-affirming long term support for OpenVMS, Tru64 and NSK. >=20 > end quote. >=20< > Again suggesting that the target of the port will be an=20 > Alpha-influenced	 > Itanic.  >=20# > 6/26/01 (advocacy group message):  >=20 > quote: >=20A > There is no way anyone in the newsgroup could have predicted=20  > that Intel= > would adopt whatever Alpha features are required to make=20  > OpenVMS, NSK andB > Tru64 work with its IA64-2 (or whatever they plan to call it)=20 > architecture.  >=20 > end quote. >=207 > Note especially the use of the word 'required' above.  >=20# > 6/26/01 (advocacy group message):  >=20 > quote: >=20B > As I've stated and as the press release has noted .. the IA64=20 > architecture= > will be updated to enable Tru64, OpenVMS and NSK to use it.  >=20 > end quote. >=20@ > Note 'to enable' above (sounds like a 'requirement' to me),=20 > and your own; > reference to previous statements of yours to that effect.  >=20 > 6/27/01 (c.o.v. post): >=20 > quote: >=20? > The reference to IA64-2 is simply to reflect the fact that=20  > OpenVMS, Tru64A > and NSK are not slated to be ported and run on todays intial=20  > release of theC > IA64 platform, but rather a followon version of the architecture.  >=20: > As stated numerous times in the releases, todays IA64=20 > technologies will be= > integrated and upgraded with Alpha technologies to allow=20  > these OS's to be	 > ported.  >=20 > end quote. >=20> > Note especially the last sentence's clear indication that=20 > Alpha-related = > upgrading would 'allow these OSs to be ported' (implying=20  > rather clearly that ' > the existing architecture would not).  >=20# > 7/10/01 (advocacy group message):  >=20 > quote: >=20A > I obviously have only slightly (and emphasize slightly) more=20  > info / insightB > than anyone on this list, however, given that the EV8 team is=20 > going to work A > on the IA64+ (whatever flavour) that VMS, Tru64 and NSK runs=20  > on, it is not ? > really  a big stretch to surmise that a good amount of EV8=20  > technology (VMS < > friendly?) will show up in subsequent generations of IA64. >=20 > end quote. >=20B > Again, clearly indicating that the Itanic that the Compaq OSs=20
 > will run on F > will be the result of work by the EV8 team, not the earlier flavors. >=20# > 7/10/01 (advocacy group message):  >=20 > quote: >=20A > Again pure speculation on my part, but imho, given the short=20u > timeframesA > announced to do the VMS/Tru64/NSK ports, one can only assume=20  > that MC either? > does not realize how long it takes to do this stuff or the=20  > target platforme > will be very EV8'ish.v >=20 > end quote. >=20B > Speculation or not, it certainly makes it clear what you were=20 > suggesting the- > Itanic that VMS would run on would be like.l >=20# > 7/13/01 (advocacy group message):  >=20 > quote: >=20> > Apologies if you this group has already seen this, but fyi -) > http://www.theinquirer.org/13070103.htmD@ > "SOURCES IN THE US suggest that current designs of of IA-64=20 > processors may= > now be garotted to death inside Intel, to be replaced by=20D > Alpha technology* > masquerading under the Itanic cognomen." >=20A > "The move may make the job of porting all those applications=20l > and operatingi? > systems Compaq will hang onto much easier, being as future=20  > generations ofD > the Itanic will really be the Alpha in disguise, the sources add." >=20 > end quote. >=20H > You certainly seemed to be suggesting that the article at The InquirerB > reflected some degree of reality (else why on earth would you=20
 > have called > > our attention to it?).  Note the implication that the new=20 > hardware would> > appear in time to make the porting easier (i.e., that the=20 > software would > require it to run).l >=20 > ...2 >=207 > > My view has not changed from the beginning on this.P >=20G > It seems that your memory of your views may not be as accurate as you-A > imagine it to be.  Or that you were simply lying outright in=202 > the hope thatJH > I'd be too lazy to call you on it.  Regardless, do us all the favor of@ > refraining from escalating this into an embarrassing public=20 > spectacle by= > further attempting to spin away your own words that I've=20e > taken the time to ; > resurrect above:  they speak very clearly for themselves.  >=20 > - bill >=20 >=20 >=20 >=20   ------------------------------  % Date: Sun, 27 Apr 2003 00:27:43 -0700a) From: Lars Poulsen <lars@beagle-ears.com>PQ Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolye. Message-ID: <3EAB866F.1010703@beagle-ears.com>   jmfbahciv@aol.com wrote:! >> [The FTC should pass a ruling]o> > GOOD GOD, NOOOO!!!!  Have you taken a look at your telephoneA > bill lately?  That's what happens when you get an entity of thed > FTC flavor involved.  C Expecting to gain educational insights from reading telephone billss@ is sheer folly. For example, if the bill in question was written? by an Incumbent Local Exchange Carrier, it will probbly containv? a line item with a title like "FCC Mandated Charge". The chargeiA in question is not mandated by the FCC (although it is explicitlyfC ALLOWED by the FCC. The amount is determined at its sole discretionrC by the LLEC, and all the meney is kept by the ILEC. None of it goesr to the FCC.o -- tH / Lars Poulsen        +1-805-569-5277   http://www.beagle-ears.com/lars/I    125 South Ontare Rd, Santa Barbara, CA 93105 USA  lars@beagle-ears.comt   ------------------------------  ! Date: Sun, 27 Apr 03 09:52:27 GMT  From: jmfbahciv@aol.comdQ Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolye+ Message-ID: <b8gfv7$72l$7@bob.news.rcn.net>i  . In article <3EAB866F.1010703@beagle-ears.com>,-    Lars Poulsen <lars@beagle-ears.com> wrote:e >jmfbahciv@aol.com wrote:v" >>> [The FTC should pass a ruling]? >> GOOD GOD, NOOOO!!!!  Have you taken a look at your telephonenB >> bill lately?  That's what happens when you get an entity of the >> FTC flavor involved.e >ND >Expecting to gain educational insights from reading telephone bills >is sheer folly.  B <grin>  Exactly.  That's why allowing extra gouging with the tacit? approval of a government entity is nonsense but very lucrative.r  6 > ... For example, if the bill in question was written@ >by an Incumbent Local Exchange Carrier, it will probbly contain6 >a line item with a title like "FCC Mandated Charge".    IIRC, there are three of those.N   > ..The chargeB >in question is not mandated by the FCC (although it is explicitlyD >ALLOWED by the FCC. The amount is determined at its sole discretionD >by the LLEC, and all the meney is kept by the ILEC. None of it goes >to the FCC.  = One of them is a 10% tax.  If it had been called a tax, therea= would have been a revolt.  But it's called a "fee for hunger"sA or something stupid like that to falsely portray that the gouging @ supposedly goes to schools or something educational or something else.g  ? Now, if you call the company who is levying that tax, they willa< give you a percentage and say that it's mandated by the FCC.8 If you call another company, they will give you another 9 percentage but still claim it is mandated by the FCC.  If > you listen to a Congress critter, they will say that it's good< for the country.  I'm talking about the augmentation of long> distance, and not the line use charges (that are also mandated7 by the FCC..or so it's claimed by the phone company).     ? As far as I'm concerned, this is getting very close to taxation without representation.  /   /BAH    ' Subtract a hundred and four for e-mail.j   ------------------------------   Date: 27 Apr 03 14:05:39 +0200) From: p_sture@elias.decus.ch (Paul Sture)sQ Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolys) Message-ID: <A$8W3kQvfRF4@elias.decus.ch>I  h In article <DSvqa.19184$q02.962632@twister.austin.rr.com>, LESLIE@JRLVAX.HOUSTON.RR.COM (leslie) writes: > jmfbahciv@aol.com wrote: > : E > : VMS is an OS that can do the skyscraper and feeding an army jobs. C > : It takes money to keep it in shape, adjust to new hardware, and C > : stop up leaks.  The PC mentality doesn't account for this cost.t7 > : Shit...the PC mentality doesn't believe in backups.- > :  > : /BAH > :  >  > 	 > Amen !!  > @ > The FTC should pass a ruling that no software can be called anA > "operating system' unless it includes a backup/retore tool that A > can handle the "bare metal" restore, such as when the boot disko" > has suffered a hardware failure. > ? > Of course it helps to have a device to back up to, which many.& > PCs don't have, other than a floppy. >  > VMS   has a bootable CD  > AIX   has mksysb > HP-UX has Ignite-UXx >   @ It is interesting to note that a couple of command files I wroteD about 6 years ago to perform weekly and daily backups using ntbackup> on NT 4.0 were still up and being downloaded (somewhere in the2 Compuserve Windows Forums) the last time I looked.  B I used to have a separate directory with a minimal NT installation@ which I would boot to restore my working version of NT when thatG screwed up (every 3-4 weeks the 16 bit stuff would screw up, and nobodyaI could offer a working fix). Back up and running in just less than an hourR every time.e  D I honestly do not know if either my command files or the alternativeC boot method work on later versions of NT, though I recall reading a1A an article in which the author described the inability to restore-? using the Personal Edition of either W2K or XP, I forget which.    -- p
 Paul Sture   ------------------------------  ! Date: Sun, 27 Apr 03 10:25:15 GMTS From: jmfbahciv@aol.comeQ Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolys+ Message-ID: <b8ghsn$fc8$1@bob.news.rcn.net>e  0 In article <j7k88b.4ta1.ln@via.reistad.priv.no>,.    Morten Reistad <mrr@reistad.priv.no> wrote:# >According to  <jmfbahciv@aol.com>:m/ >>In article <b8644r$11p8$1@godfrey.mcc.ac.uk>,w. >>   Geoff Lane <zzassgl@zoe.mcc.ac.uk> wrote:5 >>>In alt.folklore.computers jmfbahciv@aol.com wrote:? >>>> It was inH >>>> our best interests to get the high security bugs identified, fixed,B >>>> and distributed WITHOUT TELLING ANYBODY HOW TO EXERCISE THEM. >>>-; >>>How could anybody confirm that the fix worked? It's all 4 >>>very well testing onm6 >>>in-house systems, but out in the wild all kinds of  >>>crazy configurations may3 >>>exist that break the fix. >>: >>In our case, we couldn't on in-house systems because we = >>couldn't run field image software _and_ get the developmentg >>work done. >>? >>To answer your question, I think one of the reasons the fixesp? >>worked as well as they did is because it was the bit gods (wehA >>had many) did the work.  To watch those guys think was awesome. F >>Somebody would ask one a question about "what would happen if I...".H >>The bit god would go (and I could see them do this) kachunk..kachunk..B >>kachunk...ding! and answer the question.  IOW, a gazillion linesA >>of code essential got executed as a thought experiment with themD >>proposed patch applied.  I get sudders down my spine just thinking, >>of the ability and agility those guys had. >>C >>What was even more awesome...every single one of those guys coulda
 >>do this. >/: >The best Open Source people still do this. But code today: >needs to scale a couple of magnitudes further than in the. >hayday of operating systems around 1972-1985. >t= >It has just fallen to the wayside of commercial programming.m  > I think I'm going to respectfully disagree :-).  I worked with< a guy who could do the same thing with data base management < systems.  I never did watch him enough to understand how he = thought but he did the ka-chunk processing at that level.  HehB was also one of the very few who was able to do ka-chunking at theA exec level, user level, compiler level and data base level.  From A my experience (which is not extensive) these types are very rare.    >c: >It seems the corporate world hasn't managed to handle the >world of programming at all.s  : If people don't hone their skills over decades on the same> flavor, there isn't going to be experts in any computing area.  B Look at how science does their biz.  It is expected to stay within? an area of expertise.  An astronomy advisor doesn't do a careerg= review of a grad student and fail him/her because the studente; didn't get majors in biology and chemistry and physics and  > economics and business management and art and  basket weaving.A On the contrary, the kid would get told to pick one and ONLY one.t And even that's too general.  > To become an expert, one does need to spend years and years in< an area.  Programming these days spends so much time getting* swapped in and out, nothing gets improved.     >t< >These teams tend to follow the sociological rules laid downE >by Brooks in his "Man Month" books (there is a revised one out now).t  >The PHBs never understand this.  9 Some do.  Stock markets don't.  There is no such thing as 9 long term investment, where long term means more than onet year.t      > < >All the major teams in Open Source tend to follow a similar% >model, with either a "Boss-Sidekick"x  > Nope.  Boss-Umbrella.  If there ain't an umbrella the project 
 is doomed.   > .. or a tight 3-4 person teama8 >on top, and tight communication with 5-10 other people. >k< >This is exactly the "surgical team" Brooks suggested in the >"Man Month".  >t0 >When this model breaks down, the project forks.  9 I didn't see projects forking.  I did see projects takingm6 double the time.  No matter how large the group, there9 are only three workers.  If you have a really good group,lC the worker role gets picked up by another person when someone needsr a break. >d= >We have seen this in BSD, which is now forked in three, with 7 >some possible further fragmentation. XFree86 is in the%; >process of forking right now, but Linus has so far manageda< >to aviod a major fork in the OS that almost bears his name.  = That's what happens when the project control isn't "owned" by < one entity who is NOT an individual with serious prima donna8 problems (it always seems to boil down to NIH syndrome).   <snip>   /BAH  ' Subtract a hundred and four for e-mail.    ------------------------------  # Date: Sun, 27 Apr 2003 14:24:02 GMT ) From: Charles Richmond <richmond@ev1.net>hQ Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyl' Message-ID: <3EAC0396.97C5F895@ev1.net>y   jmfbahciv@aol.com wrote: > 7 >         [snip...]         [snip...]         [snip...]C > A > As far as I'm concerned, this is getting very close to taxation  > without representation.n > = Tell that to the people who live in New Hampshire and work int Massassassassassachusetts.....   --B +----------------------------------------------------------------+B |   Charles and Francis Richmond     richmond at plano dot net   |B +----------------------------------------------------------------+   ------------------------------  # Date: Sun, 27 Apr 2003 17:41:36 GMTc+ From: Anne & Lynn Wheeler <lynn@garlic.com>oY Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopoly monopolm) Message-ID: <uznmb7ry7.fsf@earthlink.net>i   jmfbahciv@aol.com writes:rE > One of them is a 10% tax.  If it had been called a tax, there wouldtF > have been a revolt.  But it's called a "fee for hunger" or somethingF > stupid like that to falsely portray that the gouging supposedly goes8 > to schools or something educational or something else.  F there was article in today's paper about some amount of PUCCs mandated> tariffs for telephone company is in support of social programs  A ... aka rather than having it show up as a gov. tax ... that then E subsidizes/grants in support of social programs (service for schools, B service for old people, rural service, etc) ... various PUCCs (notD just FCC) ... mandate certain tariffs such that telephone company isC deliverying support for various social programs ... w/o it actually  showing up on the gov. ledgers.0  C the point of the article was a lot of the excess charges were beingaC made on long distance service in order to underwrite various of thePF social programs ... and that over the last couple years there has beenD a big shift from traditional long distance phone company to wirelessF from other providers (article claimed 12 percent per annum decrease inE traditional long distance with a minimum 2 percent per annum increaselB in demand for social program services). As long as it was a singleD legal entity that PUCC & FCC were dictating to charge excessive feesF on certain services in order to underwrite social programs ... then it" could be kept off the gov.  books.  F with different legal entities starting to be involved in long distanceC service and the mandated local social program supports .... then it > becomes much more difficult to keep the funding of such social programs off the gov. books. c  D Eventual solution is that each business has to charge the full goingD rate for service ... regardless of social program objectives ... andB then the governemnt has to underwrite certain services .... biggerB allotments to schools, tax rebate for elderly, subsidies for rural? operations, etc. ... along with necessary increases in gov. taxtE collections to directly cover the social programs being underwritten.   F WIth single legal entity ... the gov. could mandate certain funds moveF from one part of the operation to another part of the operation w/o itF directly showing up on gov. books. It is when different legal entities< are involved that taditionally the gov. needs to be involved9 ... shifting money from one entity to a different entity.r   -- e3 Anne & Lynn Wheeler | http://www.garlic.com/~lynn/  A Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htmu   ------------------------------  + Date: Sun, 27 Apr 2003 12:45:22 +0000 (UTC) . From: "Insomnee" <robert.heyes@btinternet.com>) Subject: Re: Johnny English is a VMS userr/ Message-ID: <b8gjd2$qrm$1@titan.btinternet.com>e  7 Ive just got rid of some orange ones he could have had.   3 "Per Schrder" <pesc@bredband.net> wrote in message . news:H1kqa.17872$hS2.262@news2.bredband.com..., > I just saw "Johnny English" at the cinema." > http://us.imdb.com/Title?0274166 >OC > If you go to this movie, keep your eyes open for the book shelveslA > in Johnny's office in the first couple of minutes. I'm sure you64 > will recognize the grey wall of VMS documentation! >s> > This proves that the secret agents of MI7 are VMS users! ;-) > -- e > /Per Schrdert > http://developer.mimer.sed   ------------------------------   Date: 27 Apr 03 13:16:59 +0200) From: p_sture@elias.decus.ch (Paul Sture)t Subject: Location of ANUNUEWSe) Message-ID: <dhrTSBXWrjaV@elias.decus.ch>e  c In article <oyccz$2bconj@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:Am > In article <4b6ec350.0304251333.a3e1856@posting.google.com>, JimStrehlow@data911.com (Jim Strehlow) writes:-; >> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in messagee >> ...H >>> Are you perhaps using some Microsoft news client rather than ANUNEWS >>> on VMS ? >> w >> eJ >> Is that on the FREEWARE CD-ROM; else where is the download for ANUNEWS? > ' > I hope someone else will answer that.   E It is on disk 1 of FREEWARE40 in the [ANU-NEWS] directory. It is also  available online at:  7 http://h71000.www7.hp.com/freeware/freeware40/ANU-NEWS/p  D > From my perspective, it is installed on DECUServe by someone else. >   * The same here, but on the decus.ch system.  E > If you don't get an answer in the next few days, send me mail and Ia > will post the question there.      -- p
 Paul Sture   ------------------------------  % Date: Sun, 27 Apr 2003 14:52:39 +0200oB From: Michiel Erens <I.dont.want.spam@this.mailaddress.is.invalid>! Subject: Re: Location of ANUNUEWS 7 Message-ID: <3EABD297.598B@this.mailaddress.is.invalid>e   Paul Sture wrote:l >  > >>D > >> Is that on the FREEWARE CD-ROM; else where is the download for 
 > >> ANUNEWS?y > >i > G > It is on disk 1 of FREEWARE40 in the [ANU-NEWS] directory. It is alsot > available online at: > 9 > http://h71000.www7.hp.com/freeware/freeware40/ANU-NEWS/    The latest version is on : p!  ftp://ftp.arnes.si/software/VMS/    --   ME Posted by news://news.nb.nup   ------------------------------  % Date: Sun, 27 Apr 2003 02:52:44 -0400 * From: "Bill Todd" <billtodd@metrocast.net>? Subject: Re: OpenVMS Itanium port progressing well says Gorham! 2 Message-ID: <D9KcnZ2oX5ej4zajXTWcpQ@metrocast.net>  : "Dave Weatherall" <djweath@attglobal.net> wrote in message/ news:DTiotGxQ0bj6-pn2-MuUErke9ylPS@localhost...v, > On Thu, 24 Apr 2003 18:07:57 UTC, JF Mezei* > <jfmezei.spamnot@vl.videotron.ca> wrote:   ...u  J > > Consider this: Had they not killed Alpha, how much further ahead would VMSlL > > have been today, and how much further ahead VMS would have bveen 1 and 2 years K > > down the road with the resources allocated to improvements instead of ai port ? > >uF > > The port should be viewed as a necessary evil caused by a mistaken decision togK > > kill alpha. It should not be viewed as something good for VMS. There ist@ > > nothing outstanding about IA64, nothing that will give VMS a
 technologicalCH > > edge over competitors such as HP-UX or Tandem, something it had with Alpha. > E > Hang on JF. Porting VMS to another platform is _not_ a/the mistake.y  H I'm afraid JF's vision is closer to reality than yours is here:  you areB responding with abstractions without evaluating actual trade-offs.    It  > would be good for VMS.  I Abstractions such as that one.  In some ways, even a port to a completelyIL irrelevant platform 'would be good for VMS', in the sense that it would help2 clean up the code to make additional ports easier.  E But would it be a good use of resources?  No way:  there are far moreeJ important things to do, and as JF noted if it weren't for the port (and inK particular the immediacy of its need, because the Alpha boats *are* burninglK and the sooner VMS can stop depending on them the safer it will be) some of K those more important things could be being done (e.g., material OS advanceseJ that would both help VMS compete and demonstrate its owner's commitment toI its long-term future), while porting work could proceed more leisurely ineL the background just in case supporting additional platforms became important down the road.  /  Dave D. and others have been asking for it fors > a long time now.  E Not quite.  What people have been asking for is a port to a commoditytK platform - in particular, IA32.  That is not what you're getting:  whatever J market share Itanic may slowly acquire, its volumes won't be a drop in theL bucket compared with IA32's (or AMD64's) - and consequently its pricing willJ be closer to Alpha's (remember, a DS10 cost only about $6K, and API proved3 that it could be considerably less) than to a PC's.-  4  I would like to be using at home but then I'm a VMSF > bigot so we can't map that desire onto the Home computing populationH > at large. As you point out below, the mistake is setting alight to the1 > boats before you've reached the opposite shore.e  K Again, not quite on target.  It's not sufficient merely to reach shore, you L then have to determine that said shore is so attractive that there's no need. for all the things you were used to back home.  G If Compaq had kept the Alpha team and actually backed Alpha, that nevermJ would have happened:  Intel would have been stuck with a power-inefficientG architecture that it had no idea how to push forward and that thereforerJ would never have looked attractive compared with Alpha (though AMD64 stillF might, for the low end), and EV8 would be coming next year to solidifyH Alpha's high-end leadership.  The current situation with the engineering+ forced-march port is no favor to customers..   - bill   ------------------------------  % Date: Sun, 27 Apr 2003 05:36:37 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>? Subject: Re: OpenVMS Itanium port progressing well says Gorham!/) Message-ID: <3EABA465.34375DB1@istop.com>a   Bill Todd wrote:I > If Compaq had kept the Alpha team and actually backed Alpha, that neverhK > would have happened:   ......  The current situation with the engineeringe- > forced-march port is no favor to customers.e  K Ideally, Digital/Compaq/HP would have continued full steam ahead with Alpha M for VMS. And depending on how far along the Tandem port to Alpha was, perhapsn even Tandem.  I once IA64 would have established itself as a "industry standard" low costnM solution, then HP could have *at its leasure* begun to port VMS to IA64 whileaL agressively continuing software development on VMS. With no edn in sight for Alpha, there would be no rush.  J Right now, it is harder to justify any marketing for VMS because it existsN only on dead platforms (VAX/Alphas) so to compound the Alpha murder by Compaq,M HP is forced to keep its lips shut on VMS for a few years, at least until VMSoM is commercially available on that IA64 thing. By that time, the silence abouty VMS may have been fatal.  N Had Alpha been alive and well, HP would have had one less excuse not to marketQ VMS since it would have been on a healthy platform with no official end in sight.c  K Had Alpha been kept alive, HP could have edged its bets by keeping both theeM Alpha and IA64 optiosn opened. If one emerges as a clear winner than HP couldh then focus on that one.o  N But HP/Compaq chose to kill its options and litterally bet their business (andL our businesses) on some unproven Intel technology that Digital engineers hadT consistently called a real dog with technical arguments to support their assertions.  ' Imagine this scenario: (one can dream).m  N Sept 7 2001: carly, in front of worlwide press: "Today, we are announcing thatJ HP will buy Compaq, not for its PC business, but for the enterprise assetsL which Compaq did not know how to leverage. Under HP, we will grow and expandB the industry leading Alpha architecture which will give HP a clearL technological edge for our enterprise products, we will focus our enterpriseJ business on a combined Tru64 and HP-UX platform on Alpha, the VMS platformL which has been a tremendously underused asset under both Digital and Compaq,N and the Tandem Non Stop kernel which si so key to fault tolerant applications.  M Because Compaq had so mismanaged the enterprise assets purchased from DigitaltD and Tandem, HP feels that the purchase cost is extremely low, and inK inheriting the Alpha architecture for such a low price, HP feels that it iseM the best business decision to abandon the bloated, delayed and expensive IA64 M venture that isn't quite ready yet and jump into the Alpha bandwagon which is ? a mature, establihed chip with real hardware and real software.n  K At HP, we had begun to realise that the IA64 project was a failure and thatsJ the only way to compete against IBM's power architecture was to get Alpha.M Anbd because Alpha is available today, we can begin today to leverage the new . standard platfor for HP's enterprise products.   HP HAS IT NOW.   </dream mode off>s   ------------------------------  # Date: Sun, 27 Apr 2003 10:52:28 GMTo6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)? Subject: Re: OpenVMS Itanium port progressing well says Gorham!r3 Message-ID: <MDOqa.34756$v62.350859@news.chello.at>t  g In article <DTiotGxQ0bj6-pn2-MuUErke9ylPS@localhost>, "Dave Weatherall" <djweath@attglobal.net> writes:eT >On Thu, 24 Apr 2003 18:07:57 UTC, JF Mezei <jfmezei.spamnot@vl.videotron.ca> wrote:Q >> The port should be viewed as a necessary evil caused by a mistaken decision toFJ >> kill alpha. It should not be viewed as something good for VMS. There isM >> nothing outstanding about IA64, nothing that will give VMS a technological-N >> edge over competitors such as HP-UX or Tandem, something it had with Alpha. >oG >Hang on JF. Porting VMS to another platform is _not_ a/the mistake. ItfG >would be good for VMS. Dave D. and others have been asking for it for iF >a long time now. I would like to be using at home but then I'm a VMS F >bigot so we can't map that desire onto the Home computing population G >at large. As you point out below, the mistake is setting alight to the 1 >boats before you've reached the opposite shore. e  F Yes, porting is not the bad thing. But then again, IA64 is (still) notK for home computing and killing Alpha before the IA64 is ready and ontrack -gE in performance, price and available applications - (despite having ana) advantage over Alpha) _is_ the bad thing.l  M So, JF may be telling the bad truth far too often, but it is still the truth.    --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialistn E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Sun, 27 Apr 2003 09:25:30 -0500-1 From: "David J. Dachtera" <djesys.nospam@fsi.net> ? Subject: Re: OpenVMS Itanium port progressing well says Gorham!O' Message-ID: <3EABE85A.CF9ADD32@fsi.net>m   Dave Weatherall wrote: > [snip]H > Hang on JF. Porting VMS to another platform is _not_ a/the mistake. ItG > would be good for VMS. Dave D. and others have been asking for it for  > a long time now.  H Well, not quite. "The world" is IA32. So long as that remains true, that* will continue to be where VMS needs to be.  H "The world" could have been (coulda, woulda, shoulda) a mix of Alpha andG IA32, but for certain issues which are discussed at a site indicated ini my sig.e  5 > I would like to be using at home but then I'm a VMSbF > bigot so we can't map that desire onto the Home computing populationH > at large. As you point out below, the mistake is setting alight to the1 > boats before you've reached the opposite shore.    Quite.   > [snip]F > HP are in a bit of a quandary on many fronts and are in great dangerE > of pi**ing all (but the MS/PC platform) customers off. VMS, Tru-64,  > MPE and maybe even HP-UX.y  F Again, quite. The $64 giga-buck question remains: how to get that idea8 across at the levels at which it truly matters the most.  E Could opteron pre-empt Itanic? Will either eventually take over where D IA32 is today? These are the questions that will shape the future of computing as we know it.   --   David J. Dachterat dba DJE Systems= http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/2   ------------------------------   Date: 27 Apr 03 13:23:08 +0200) From: p_sture@elias.decus.ch (Paul Sture) P Subject: Re: [DECnet-Plus V7.3-1 ECO2] What has happened to the DECNET_VERSION ?) Message-ID: <PlTqU03tqXwA@elias.decus.ch>t  l In article <Qquqa.15248$v62.143762@news.chello.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:K > It seems that the ECO2 of DECnet-Plus V7.3-1 (which is, as you can see on N > the version number, for the Alpha platform) did make the DECNET_VERSION some > kind of bogus: > . > 	$ write sys$output f$gets("decnet_version") > 	00050500t > F > I vaguely remember, with ECO1 the version number was slightly higher > (like 00050E05 or similar).A >   > Can anyone confirm this and/or: > does anyone know what has happened and/or how to fix it? >    Here's what I have:    $ tcpip show version  ?   Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 1d;   on a Digital Personal WorkStation  running OpenVMS V7.3-1*  . $  $ write sys$output f$gets("decnet_version") 00050E04     -- f
 Paul Sture   ------------------------------  # Date: Sun, 27 Apr 2003 11:49:37 GMTn6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)P Subject: Re: [DECnet-Plus V7.3-1 ECO2] What has happened to the DECNET_VERSION ?3 Message-ID: <ltPqa.35409$v62.366397@news.chello.at>   U In article <PlTqU03tqXwA@elias.decus.ch>, p_sture@elias.decus.ch (Paul Sture) writes:i >Here's what I have: >  >$ tcpip show versionh >w@ >  Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 1< >  on a Digital Personal WorkStation  running OpenVMS V7.3-1  & Was hat TCPIP mit DECnet-Plus zu tun ? Richtiger wre   	$ ncl sho imp 	Node 04% 	at 2003-04-27-13:45:54.580+02:00Iinft   	Characteristics  ( 	    Implementation                    =	 	       {s 	          [ 	          Name = OpenVMS AXP ,a 	          Version = "V7.3-1  "  	          ] , 	          [2 	          Name = Compaq DECnet-Plus for OpenVMS ,; 	          Version = "V7.3-1 ECO01 16-SEP-2002 10:33:00.25"f 	          ]	 	       }.  E Hier sieht man auch einen Fehler. Es ist nmlich ECO02 installiert...t   Oder $ PROD SHO PROD DECNET_OSI/FUt ----------------------------------- ----------- ------------ ----------------------------------- -----------------------------------f PRODUCT                             KIT TYPE    STATE        MAINTENANCE                 REFERENCED BY ----------------------------------- ----------- ------------ ----------------------------------- -----------------------------------z DEC AXPVMS DECNET_OSI V7.3-1        Full LP     Installed    DEC AXPVMS DNVOSIECO01 V7.3-1       DEC AXPVMS OPENVMS V7.3-1Z                                                              DEC AXPVMS DNVOSIECO02 V7.3-1 ----------------------------------- ----------- ------------ ----------------------------------- -----------------------------------   1 item found  P VMSINSTAL history file DISK$VMSSYS:[VMS$COMMON.][SYSUPD]VMSINSTAL.HISTORY;1 cont ains additional informationh  / >$  $ write sys$output f$gets("decnet_version") 	 >00050E04   1 Das ist anscheinend DECnet-Plus V7.3-1 ohne ECOs.    --   Peter "EPLAN" LANGSTOEGERe% Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------   Date: 27 Apr 03 16:28:46 +0200) From: p_sture@elias.decus.ch (Paul Sture)eP Subject: Re: [DECnet-Plus V7.3-1 ECO2] What has happened to the DECNET_VERSION ?) Message-ID: <GlnDjqA5VjrO@elias.decus.ch>p  l In article <ltPqa.35409$v62.366397@news.chello.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:W > In article <PlTqU03tqXwA@elias.decus.ch>, p_sture@elias.decus.ch (Paul Sture) writes:u >>Here's what I have:( >> >>$ tcpip show version >>A >>  Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 1 = >>  on a Digital Personal WorkStation  running OpenVMS V7.3-1f > ( > Was hat TCPIP mit DECnet-Plus zu tun ?   Gar nichts. :-( :-( :-(i   > Richtiger wre >  > 	$ ncl sho imp	 > 	Node 0 ' > 	at 2003-04-27-13:45:54.580+02:00Iinfu >  > 	Characteristics > * > 	    Implementation                    = > 	       {c > 	          [! > 	          Name = OpenVMS AXP ,l! > 	          Version = "V7.3-1  "o > 	          ] , > 	          [4 > 	          Name = Compaq DECnet-Plus for OpenVMS ,= > 	          Version = "V7.3-1 ECO01 16-SEP-2002 10:33:00.25"t > 	          ] > 	       }    So...s  f $ PRODUCT INSTALL DNVOSIECO02DEC AXPVMS DNVOSIECO02 V7.3-1: DECnet-Plus V7.3-1 for OpenVMS Alpha ECO 2  /     Copyright 2003 Compaq Computer Corporation.a  7 * This product does not have any configuration options..   Execution phase starting ...  7 The following product will be installed to destination:eF     DEC AXPVMS DNVOSIECO02 V7.3-1          DISK$ALPHASYS:[VMS$COMMON.]l %PCSI-I-OBJSKP, file [SYSEXE]DNS$SERVER.EXE pertains to an option that was not selected; file update skipped   ^^^^^^??????? was ist das?  / Portion done: 0%...10%...20%...30%...90%...100%n  ) The following product has been installed: E     DEC AXPVMS DNVOSIECO02 V7.3-1          Patch (maintenance update)e  R %PCSI-I-IVPEXECUTE, executing test procedure for DEC AXPVMS DNVOSIECO02 V7.3-1 ...9 %PCSI-I-IVPSUCCESS, test procedure completed successfully   I DEC AXPVMS DNVOSIECO02 V7.3-1: DECnet-Plus V7.3-1 for OpenVMS Alpha ECO 2n  I     Release notes are available in SYS$HELP:DNVOSI0731ECO02.RELEASE_NOTES=     Nach ECO 2 / reboot:     $ mc ncl show impl   Node 0$ at 2003-04-27-16:08:46.108+02:00Iinf   Characteristicsg  '     Implementation                    ==        {           [u           Name = OpenVMS AXP ,           Version = "V7.3-1  "
           ] ,            [e1           Name = Compaq DECnet-Plus for OpenVMS ,o:           Version = "V7.3-1 ECO02  7-MAR-2003 18:34:05.05"           ]         }- $ write sys$output f$getsyi("decnet_version")s 00050500   > G > Hier sieht man auch einen Fehler. Es ist nmlich ECO02 installiert...h >  > Oder > $ PROD SHO PROD DECNET_OSI/FUh > ----------------------------------- ----------- ------------ ----------------------------------- -----------------------------------h > PRODUCT                             KIT TYPE    STATE        MAINTENANCE                 REFERENCED BY > ----------------------------------- ----------- ------------ ----------------------------------- -----------------------------------| > DEC AXPVMS DECNET_OSI V7.3-1        Full LP     Installed    DEC AXPVMS DNVOSIECO01 V7.3-1       DEC AXPVMS OPENVMS V7.3-1\ >                                                              DEC AXPVMS DNVOSIECO02 V7.3-1 > ----------------------------------- ----------- ------------ ----------------------------------- ----------------------------------- >  > 1 item found >    Nach ECO 2:    $ PROD SHO PROD DECNET_OSI/FU  ----------------------------------- ----------- ------------ ----------------------------------- -----------------------------------n PRODUCT                             KIT TYPE    STATE        MAINTENANCE                         REFERENCED BY ----------------------------------- ----------- ------------ ----------------------------------- -----------------------------------z DEC AXPVMS DECNET_OSI V7.3-1        Full LP     Installed    DEC AXPVMS DNVOSIECO02 V7.3-1       DEC AXPVMS OPENVMS V7.3-1 ----------------------------------- ----------- ------------ ----------------------------------- -----------------------------------   1 item found  0 >>$  $ write sys$output f$gets("decnet_version")
 >>00050E04 > 3 > Das ist anscheinend DECnet-Plus V7.3-1 ohne ECOs.: >    Genau.   -- d
 Paul Sture   ------------------------------  % Date: Sun, 27 Apr 2003 16:47:01 +0200s) From: Bart Zorn <B.Zorn@xs4all.nospam.nl>bS Subject: Re: [DECnet-Plus V7.3-1 ECO2] What has happened to the DECNET_VERSION ? ??w6 Message-ID: <3eabed66$0$49113$e4fe514c@news.xs4all.nl>   Paul Sture wrote:tJ > In article <ltPqa.35409$v62.366397@news.chello.at>, peter@langstoeger.a=% t (Peter 'EPLAN' LANGSTOEGER) writes:n >=20J >>In article <PlTqU03tqXwA@elias.decus.ch>, p_sture@elias.decus.ch (Paul = Sture) writes: >> >>>Here's what I have: >>>y >>>$ tcpip show versioni >>>eA >>> Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 1i= >>> on a Digital Personal WorkStation  running OpenVMS V7.3-1  >>( >>Was hat TCPIP mit DECnet-Plus zu tun ? >=20 >=20 > Gar nichts. :-( :-( :-(  >=20 >=20 >>Richtiger w=E4re >> >>	$ ncl sho imp	 >>	Node 0o' >>	at 2003-04-27-13:45:54.580+02:00Iinfo >> >>	Characteristics >>, >>	    Implementation                    =3D >>	       {t >>	          [# >>	          Name =3D OpenVMS AXP , # >>	          Version =3D "V7.3-1  "f >>	          ] , >>	          [6 >>	          Name =3D Compaq DECnet-Plus for OpenVMS ,? >>	          Version =3D "V7.3-1 ECO01 16-SEP-2002 10:33:00.25"r >>	          ] >>	       }o >=20 >=20 > So...  >=20J > $ PRODUCT INSTALL DNVOSIECO02DEC AXPVMS DNVOSIECO02 V7.3-1: DECnet-Plus=  V7.3-1 for OpenVMS Alpha ECO 2a >=201 >     Copyright 2003 Compaq Computer Corporation.t >=209 > * This product does not have any configuration options.o >=20 > Execution phase starting ... >=209 > The following product will be installed to destination:tH >     DEC AXPVMS DNVOSIECO02 V7.3-1          DISK$ALPHASYS:[VMS$COMMON.]J > %PCSI-I-OBJSKP, file [SYSEXE]DNS$SERVER.EXE pertains to an option that =% was not selected; file update skippedF >=20 > ^^^^^^??????? was ist das?  F DECdns is the naming service for DECnet-Plus. Up to VMS V7.3 DECdns=20F server was only available for VAX (or on Tru64 Unix). Starting with=20I V7.3-1 it is on Alpha, too. If you install or upgrade DECnet-Plus, and=20:J you accept the default configuration options, DECdns server will not be=20
 installed.  F Most sites use the Local name database in stead of DECdns. However,=20B DECdns was one of big advantages of DECnet-Plus over DECnet IV,=20 especially for large networks.   >=201 > Portion done: 0%...10%...20%...30%...90%...100%  >=20+ > The following product has been installed:eG >     DEC AXPVMS DNVOSIECO02 V7.3-1          Patch (maintenance update)e >=20J > %PCSI-I-IVPEXECUTE, executing test procedure for DEC AXPVMS DNVOSIECO02=  V7.3-1 ...t; > %PCSI-I-IVPSUCCESS, test procedure completed successfullyB >=20J > DEC AXPVMS DNVOSIECO02 V7.3-1: DECnet-Plus V7.3-1 for OpenVMS Alpha ECO=  2 >=20J >     Release notes are available in SYS$HELP:DNVOSI0731ECO02.RELEASE_NOT= ES >=20 >=20 > Nach ECO 2 / reboot: >=20 >=20 > $ mc ncl show impl >=20 > Node 0& > at 2003-04-27-16:08:46.108+02:00Iinf >=20 > Characteristicsp >=20+ >     Implementation                    =3Do
 >        {
 >           [t" >           Name =3D OpenVMS AXP ," >           Version =3D "V7.3-1  " >           ] ,t
 >           [m5 >           Name =3D Compaq DECnet-Plus for OpenVMS , > >           Version =3D "V7.3-1 ECO02  7-MAR-2003 18:34:05.05"
 >           ](
 >        }/ > $ write sys$output f$getsyi("decnet_version")l
 > 00050500 >=20 >=20J >>Hier sieht man auch einen Fehler. Es ist n=E4mlich ECO02 installiert...=   >> >>Oder >>$ PROD SHO PROD DECNET_OSI/FUeJ >>----------------------------------- ----------- ------------ ----------== ------------------------- -----------------------------------hJ >>PRODUCT                             KIT TYPE    STATE        MAINTENANC= E                 REFERENCED BYoJ >>----------------------------------- ----------- ------------ ----------== ------------------------- -----------------------------------EJ >>DEC AXPVMS DECNET_OSI V7.3-1        Full LP     Installed    DEC AXPVMS=3  DNVOSIECO01 V7.3-1       DEC AXPVMS OPENVMS V7.3-11J >>                                                             DEC AXPVMS=  DNVOSIECO02 V7.3-1yJ >>----------------------------------- ----------- ------------ ----------== ------------------------- -----------------------------------r >> >>1 item found >> >=20 >=20
 > Nach ECO 2:@ >=20 > $ PROD SHO PROD DECNET_OSI/FU@J > ----------------------------------- ----------- ------------ ----------== ------------------------- -----------------------------------nJ > PRODUCT                             KIT TYPE    STATE        MAINTENANC=' E                         REFERENCED BYOJ > ----------------------------------- ----------- ------------ ----------== ------------------------- -----------------------------------,J > DEC AXPVMS DECNET_OSI V7.3-1        Full LP     Installed    DEC AXPVMS=3  DNVOSIECO02 V7.3-1       DEC AXPVMS OPENVMS V7.3-1 J > ----------------------------------- ----------- ------------ ----------== ------------------------- -----------------------------------I >=20 > 1 item found >=20 >=201 >>>$  $ write sys$output f$gets("decnet_version")t >>>00050E04w >>3 >>Das ist anscheinend DECnet-Plus V7.3-1 ohne ECOs.w >> >=20 >=20 > Genau.  	 Bart Zorna   ------------------------------   Date: 27 Apr 03 14:29:50 +0200) From: p_sture@elias.decus.ch (Paul Sture)c@ Subject: Re: [SYSMAN, TCPIP] Unprintable Chars switches terminal) Message-ID: <Mney1fxF1Dty@elias.decus.ch>a  l In article <aFzqa.21561$v62.214285@news.chello.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes: > I recently noted that with a >  > $ TCPIP SH CONF COMM >  > Communication Configurationo > B > Local host:      ns                     Domain:   langstoeger.at >   > Cluster timer:               0 > ; > Interfaces:                  0          Type:     Defaults  > Device_sockets:              0  > Routes:                      0  > Services:                    0  > Proxies:                     0 > 6 >                           Free     Maximum   Minimum6 > Large buffers                0           0         06 > Small buffers                0           0         0, > IRPs                         0           0  > Non TCPIP buffers            0 >  > Remote Terminale  >   Large buffers:             0  >   UCBs:                      0 >   Virtual term:     disabled > L > everything seems right (besides the missing Minimum IRPs) but same command1 > done within SYSMAN behaves strange/incorrectly:s >  > SYSMAN> DO TCPIP SH CONF COMM 0 > %SYSMAN-I-OUTPUT, command execution on node NS >  > Communication Configuratione > B > Local host:      ns                     Domain:   langstoeger.at >   > Cluster timer:               0 > ; > Interfaces:                  0          Type:     Defaulti  > Device_sockets:              0  > Routes:                      0  > Services:                    0  > Proxies:                     0 > 6 >                           Free     Maximum   Minimum6 > Large buffers                0           0         05 > Small buffers                0           0       = >                                                           g   Reproduced here,   $ tcpip show version  ?   Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 1l;   on a Digital Personal WorkStation  running OpenVMS V7.3-1i                          > F > Obviously a SI (^N ASCII 14) switched the terminal into graphic modeH > (and a $ so[0,8]=15 $ WRITE SYS$OUTPUT so fixes it again) and the rest. > of the display is in garbage^Wgraphics mode. >   F A faster method of resetting is to go into either EVE or EDT in screen mode, and exit.   M > Where does the garbage (^N) come from ? From TCPIP display or from SYSMAN ?n> > If from TCPIP then why not also without SYSMAN in pure DCL ?, > So it seems to come from SYSMAN, but why ? >  > A usable workaround is > - > SYSMAN> DO TCPIP SH CONF COM/OUT=SYS$OUTPUTc0 > %SYSMAN-I-OUTPUT, command execution on node NS >  > Communication Configurationm > B > Local host:      ns                     Domain:   langstoeger.at >   > Cluster timer:               0 > ; > Interfaces:                  0          Type:     Defaultr  > Device_sockets:              0  > Routes:                      0  > Services:                    0  > Proxies:                     0 > 6 >                           Free     Maximum   Minimum6 > Large buffers                0           0         06 > Small buffers                0           0         0, > IRPs                         0           0  > Non TCPIP buffers            0 >  > Remote Terminalo  >   Large buffers:             0  >   UCBs:                      0 >   Virtual term:     disabled > 0 > But why does this work ? It is still SYSMAN...? > Does anyone have an idea why this happens and how to fix it ?R< > Is this a bug (in SYSMAN) someone should make a call for ? >    --  
 Paul Sture   ------------------------------   End of INFO-VAX 2003.232 ************************