1 INFO-VAX	Wed, 28 Nov 2001	Volume 2001 : Issue 661       Contents:) %BACKUP-I-BTCROUT, any details available? < RE: analyze/disk crashes with message %system-f-accvio, acce% Another Thing You Won't See In VMS... , Re: Compaq's Secret VMS Plans (The Inquirer), Re: Compaq's Secret VMS Plans (The Inquirer), Re: Compaq's Secret VMS Plans (The Inquirer), Re: Compaq's Secret VMS Plans (The Inquirer), Re: Compaq's Secret VMS Plans (The Inquirer), Re: Compaq's Secret VMS Plans (The Inquirer), Re: Compaq's Secret VMS Plans (The Inquirer)9 Re: Compaqs VMS plans for IPF port ... any doubters left? 9 Re: Compaqs VMS plans for IPF port ... any doubters left? 9 Re: Compaqs VMS plans for IPF port ... any doubters left? 9 Re: Compaqs VMS plans for IPF port ... any doubters left? 9 Re: Compaqs VMS plans for IPF port ... any doubters left? 9 Re: Compaqs VMS plans for IPF port ... any doubters left? 9 Re: Compaqs VMS plans for IPF port ... any doubters left? 9 Re: Compaqs VMS plans for IPF port ... any doubters left? 9 Re: Compaqs VMS plans for IPF port ... any doubters left? : Re: Compaqs VMS plans for IPF port ... any doubters left?y+ Re: DCL minute of the day: DCL$SMG routines + Re: DCL minute of the day: DCL$SMG routines  Re: DECNET task question Re: DECnet timeout? M Re: Disaster Tolerance day organized by Compaq User Group Netherlands (NLCUG) M Re: Disaster Tolerance day organized by Compaq User Group Netherlands (NLCUG) , Re: DSSI VAXcluster manual on line anywhere?+ Re: Graphics cntrlr not recognized by 5.5-2  Re: Invitation... ! Re: logical names novice question ! Re: logical names novice question 2 New product allows VMS to become part of a PC Lan! Re: newsreaders... Re: NTP under TCPIP V5.1/ Re: Obtaining System Serial Number via Software / Re: Obtaining System Serial Number via Software / RE: Obtaining System Serial Number via Software / Re: Obtaining System Serial Number via Software + OpenVMS and minicopy... a note of thanks... - Re: OpenVMS for Itanium: Marketing Suggestion - Re: OpenVMS for Itanium: Marketing Suggestion - Re: OpenVMS for Itanium: Marketing Suggestion  Re: OT Re: AMAZON RAIN FOREST  Re: PATHWORKS Licensing  PGP for OpenVMS  Re: PGP for OpenVMS A Re: RMS file structure internals documentation freely available ?  Re: RWAST problems - Part ... . Re: Security patch multihomes X Display Server9 Re: Solaris: ready for prime time?  Keep your VMS system. 9 Re: Solaris: ready for prime time?  Keep your VMS system. 9 Re: Solaris: ready for prime time?  Keep your VMS system. 9 Re: Solaris: ready for prime time?  Keep your VMS system. 9 RE: Solaris: ready for prime time?  Keep your VMS system. 9 Re: Solaris: ready for prime time?  Keep your VMS system. 9 RE: Solaris: ready for prime time?  Keep your VMS system. 9 Re: Solaris: ready for prime time?  Keep your VMS system.  Some Multia Help needed  RE: Some Multia Help needed  Re: Some Multia Help needed  Re: Some Multia Help needed  Re: Some Multia Help needed E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org ? Re: Using INETACP_FUNC$C_GETHOSTBYNAME using fortran- examples?  Re: XPDF 0.93 - VMS versions  F ----------------------------------------------------------------------    Date: 27 Nov 2001 13:13:57 -0600- From: koehler@encompasserve.org (Bob Koehler) 2 Subject: %BACKUP-I-BTCROUT, any details available?3 Message-ID: <t0E6FWMG8y3C@eisner.encompasserve.org>   G   On image backups of one of my ODS-5 volumes, at the end of the verify    pass, I'm getting multiple  7       %BACKUP-I-BTCROUT, routine ODS-5 RMS SYNTAX ERROR       and  H       %BACKUP-I-BTCROUT, routine *** ODS-5 RMS SYNTAX ERROR *** DISKSCAN  G    OK, so these are Informational.  Still, it's my backups and I'd like &    to know more about what's going on.  F    Anyone have technical details?  Help/message and release notes have    no info.   C    VMS 7.2-1 with VMS721_SYS-V1100 and VMS721_UPDATE-V0300, BACKUP  K    patch VMS721_BACKUP-V0100, lot of other patches that don't look related, !    on a DEC 3000 M600S, RZ28 disk    ------------------------------  % Date: Tue, 27 Nov 2001 14:41:58 -0500 * From: WILLIAM WEBB <WWEBB1@email.usps.gov>E Subject: RE: analyze/disk crashes with message %system-f-accvio, acce - Message-ID: <0033000042853210000002L002*@MHS>   , =0AI'm the one who remembered the 8GB limit-  9 What I'd do if I were in this "situation" (in addition to , being quite nervous until it was corrected):  5 If the 9GB drives haven't gone over 4GB of stuff yet-    1. put a 4 GB drive back in, 2. init it, 9 3. copy/log/read/write the entire disk to the 4 GB drive; : 4. back the 4GB up to tape (or not- this step is optional)7 5. use VDDRIVER to partition up the drives into volumes     smaller than 8.whatever. < 6. copy or restore from tape to the new volume(s), depending9    on whether you're going from the 4 GB disk or from the     saveset on tape. & 7. repeat steps 2-6 until you're done.  > Going on intuition rather than any "hard data", I suspect that= COPY, working on smaller bits at a time than BACKUP, might be 5 less likely to elicit strange behavior resulting from 5 the fact that you're operating beyond the size limit.   = I suspect that doing a 5.5-2 BACKUP/IMAGE on the 9GB would be  asking for trouble.    WWWebb   -----Original Message-----/ From: Info-VAX-Request@Mvb.Saic.Com at INTERNET ( Sent: Tuesday, November 27, 2001 2:06 PMB To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNETE Subject: RE: analyze/disk crashes with message %system-f-accvio, acce     A >The 4 Gb disks were replaced by 9 Gb disks, and than the strange H >behavior of 'anal/disk' seemed to start.. strange errors appeared (and=  
 >disappeared) @ >but now the 'anal/disk' simply crashes and I don't have a means/ >anymore to check the consistency of the disk..  > D >In my search for workarounds or patches (vms 5.5-2h4) I just fopund: >the 'accvio' error in the 'analyze/error' utility, not in >'analyze/disk'   H As someone said, you can't use disks that large on VMS V5.5.  Eventuall= y  they'll become corrupted.  --A Brian Tillman                   Internet: tillman_brian at si.com A Smiths Aerospace                          tillman at swdev.si.com = 3290 Patterson Ave. SE, MS      Addresses modified to prevent < Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"9        This opinion doesn't represent that of my company=    ------------------------------  % Date: Tue, 27 Nov 2001 18:32:15 -0700 % From: Dan O'Reilly <dano@process.com> . Subject: Another Thing You Won't See In VMS...B Message-ID: <5.1.0.14.2.20011127183051.00b0c758@raptor.psccos.com>  F Under the heading of "yet another thing you don't see for VMS", I just got this email:   J ------------------------------cut here------------------------------------  K Red Hat Network has determined that the following advisory is applicable to H one or more of the systems you have registered with the Software Manager service:  $ Security Advisory - RHSA-2001:157-06N ------------------------------------------------------------------------------ Summary:& Updated wu-ftpd packages are available   Description:= An overflowable buffer exists in earlier versions of wu-ftpd. A An attacker could gain access to the machine by sending malicious 	 commands.   B It is recommended that all users of wu-ftpd upgrade to the lastest version.  J ------------------------------cut here------------------------------------     ------I +-------------------------------+---------------------------------------+ I | Dan O'Reilly                  |                                       | I | Principal Engineer            |  "Why should I care about posterity?  | I | Process Software              |   What's posterity ever done for me?" | I | http://www.process.com        |                    -- Groucho Marx    | I +-------------------------------+---------------------------------------+    ------------------------------  # Date: Tue, 27 Nov 2001 19:00:24 GMT * From: "Bill Todd" <billtodd@metrocast.net>5 Subject: Re: Compaq's Secret VMS Plans (The Inquirer) A Message-ID: <cpRM7.76119$8q.10287501@bin2.nnrp.aus1.giganews.com>   : "Warren Spencer" <wspencer@ap.nospam.org> wrote in message1 news:91668821Cwarrenspencer1977@207.126.101.97... - > billtodd@metrocast.net (Bill Todd) wrote in 8 > <D4PM7.70514$uB.11455648@bin3.nnrp.aus1.giganews.com>: >  > > = > >"Warren Spencer" <wspencer@ap.nospam.org> wrote in message 4 > >news:91666EA00warrenspencer1977@207.126.101.97... > >  > >... > > J > >> I wouldn't expect much of this to be spent of OpenVMS marketing.  TheI > >> Intel/Compaq deal is based on processors, not OS's.  I suspect Q can 8 > >> spend the $$ on marketing Tru-64 - and likely will. > > F > >Did I miss a page lately?  Last I thought I knew, the Tru64 port to > >Itanic was cancelled. > > 	 > >- bill  > K > More likely I missed a page Bill.  Did HP cancel it or Q?  The odds of HP / > making the call seem to be dwindling of late.   L Sorry I can't give a citation off the top of my head, but I thought that theL port had been publicly called off (at least in the sense of such a statementK leaked by a Compaq manager in a position to do so authoritatively) in favor I of the proposed post-merger 'convergence' of HP/UX and Tru64 (which seems E likely to mean HP/UX with some Tru64 goodies eventually cobbled on if L possible).  Though I'm not sure how such a decision could be reconciled withC my other impression that HP and Q were nominally supposed to remain D competitors until the merger had been approved and continue on their pre-merger courses.   I Anyone else have a solider recollection?  My guess would be that a stroll K through the Inquirer and Register archives would turn up a hit.  I've added B comp.unix.tru64 to the distribution, since people there are likely* considerably better-informed in this area.   - bill   ------------------------------  % Date: Tue, 27 Nov 2001 21:58:14 +0100 1 From: John McLean <mcleanj@swissonline.delete.ch> 5 Subject: Re: Compaq's Secret VMS Plans (The Inquirer) 5 Message-ID: <3C03FE66.2DEB8AB5@swissonline.delete.ch>    Warren Spencer wrote:  > - > billtodd@metrocast.net (Bill Todd) wrote in 8 > <D4PM7.70514$uB.11455648@bin3.nnrp.aus1.giganews.com>: >  > > = > >"Warren Spencer" <wspencer@ap.nospam.org> wrote in message 4 > >news:91666EA00warrenspencer1977@207.126.101.97... > >  > >... > > J > >> I wouldn't expect much of this to be spent of OpenVMS marketing.  TheI > >> Intel/Compaq deal is based on processors, not OS's.  I suspect Q can 8 > >> spend the $$ on marketing Tru-64 - and likely will. > > F > >Did I miss a page lately?  Last I thought I knew, the Tru64 port to > >Itanic was cancelled. > > 	 > >- bill  > K > More likely I missed a page Bill.  Did HP cancel it or Q?  The odds of HP / > making the call seem to be dwindling of late.  >  > ws    A I don't recall any formal statement of end-of-life but I do reall F various merger documents and seminars talking of the blending of Tru64H and HP Unix to provide something that I think was described as "the bestG of both worlds" or "best of breed" or some such spinmeister's accolade.   D Perhaps Compaq have omitted to formally announce it because CapellasE clearly stated on or shortly after 25 June that Tru64 would be ported 8 (and since that time comments by others have concurred).  E If Compaq don't port Tru64 but presented this as part of the Alpha to G IPF transition, from a legal aspect, aren't they skating on thin ice ??      John McLean    ------------------------------  % Date: Wed, 28 Nov 2001 01:52:47 +0000 + From: John McNulty <knode1@jmtl.com-nospam> 5 Subject: Re: Compaq's Secret VMS Plans (The Inquirer) / Message-ID: <u08hde7tdgp834@corp.supernews.com>   L Any such news (about the Tru64 port) has got to be pure speculation surely. H Haven't hose details got to be kept under wraps by law until the merger # jumps the shareholder vote hurdle ?    John     Bill Todd wrote:   > < > "Warren Spencer" <wspencer@ap.nospam.org> wrote in message3 > news:91668821Cwarrenspencer1977@207.126.101.97... . >> billtodd@metrocast.net (Bill Todd) wrote in9 >> <D4PM7.70514$uB.11455648@bin3.nnrp.aus1.giganews.com>:  >> >> >> >> >"Warren Spencer" <wspencer@ap.nospam.org> wrote in message5 >> >news:91666EA00warrenspencer1977@207.126.101.97...  >> > >> >...  >> >K >> >> I wouldn't expect much of this to be spent of OpenVMS marketing.  The J >> >> Intel/Compaq deal is based on processors, not OS's.  I suspect Q can9 >> >> spend the $$ on marketing Tru-64 - and likely will.  >> >G >> >Did I miss a page lately?  Last I thought I knew, the Tru64 port to  >> >Itanic was cancelled.  >> >
 >> >- bill >>L >> More likely I missed a page Bill.  Did HP cancel it or Q?  The odds of HP0 >> making the call seem to be dwindling of late. > J > Sorry I can't give a citation off the top of my head, but I thought thatH > the port had been publicly called off (at least in the sense of such a= > statement leaked by a Compaq manager in a position to do so H > authoritatively) in favor of the proposed post-merger 'convergence' ofK > HP/UX and Tru64 (which seems likely to mean HP/UX with some Tru64 goodies  > eventually cobbled on ifI > possible).  Though I'm not sure how such a decision could be reconciled J > with my other impression that HP and Q were nominally supposed to remainF > competitors until the merger had been approved and continue on their > pre-merger courses.  > K > Anyone else have a solider recollection?  My guess would be that a stroll G > through the Inquirer and Register archives would turn up a hit.  I've	J > added comp.unix.tru64 to the distribution, since people there are likely, > considerably better-informed in this area. >  > - bill   ------------------------------  # Date: Wed, 28 Nov 2001 02:49:52 GMTM4 From: "Terry C. Shannon" <terryshannon@mediaone.net>5 Subject: Re: Compaq's Secret VMS Plans (The Inquirer)i: Message-ID: <khYM7.269$zX1.664607@typhoon.ne.mediaone.net>  6 "Jerry Leslie" <leslie@clio.rice.edu> wrote in message! news:9turhm$805$2@joe.rice.edu...q, >    http://www.theinquirer.net/27110101.htm >    Compaq's secret VMS plans >    Another mole squeaksq >M  K FWIW I have it on very reliable authority that there's a lot of veracity totL The Inq's latest foray into things VMS-related. The document is a tad dated,> but it is said by One Who Ought to Know to be *very* accurate.   ------------------------------  # Date: Wed, 28 Nov 2001 03:53:12 GMTq1 From: "David J. Dachtera" <djesys.nospam@fsi.net>e5 Subject: Re: Compaq's Secret VMS Plans (The Inquirer) ' Message-ID: <3C045FA3.C91A0842@fsi.net>a   "Terry C. Shannon" wrote:q > 8 > "Jerry Leslie" <leslie@clio.rice.edu> wrote in message# > news:9turhm$805$2@joe.rice.edu... . > >    http://www.theinquirer.net/27110101.htm  > >    Compaq's secret VMS plans > >    Another mole squeakse > >o > M > FWIW I have it on very reliable authority that there's a lot of veracity tonN > The Inq's latest foray into things VMS-related. The document is a tad dated,@ > but it is said by One Who Ought to Know to be *very* accurate.  > *BUT* - does it reflect the attitude and direction(???) of top- management(???) at the Q? ...Curly? ...Carly?e  * ...Dr. Howard? ...Dr. Fine? ...Dr. Howard?   -- n David J. Dachtera  dba DJE SystemsS http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/r   ------------------------------  # Date: Wed, 28 Nov 2001 05:59:14 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>5 Subject: Re: Compaq's Secret VMS Plans (The Inquirer)o: Message-ID: <S2%M7.294$zX1.769798@typhoon.ne.mediaone.net>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3C045FA3.C91A0842@fsi.net...e > "Terry C. Shannon" wrote:i > >r: > > "Jerry Leslie" <leslie@clio.rice.edu> wrote in message% > > news:9turhm$805$2@joe.rice.edu...t0 > > >    http://www.theinquirer.net/27110101.htm" > > >    Compaq's secret VMS plans > > >    Another mole squeaksi > > >? > >pL > > FWIW I have it on very reliable authority that there's a lot of veracity toI > > The Inq's latest foray into things VMS-related. The document is a tady dated,B > > but it is said by One Who Ought to Know to be *very* accurate. >e@ > *BUT* - does it reflect the attitude and direction(???) of top/ > management(???) at the Q? ...Curly? ...Carly??  I Who the hell knows? I sure as heck don't. But the memo renders  it prettyeJ evident what Mark Gorham thinks. Whether what Mark Gorham thinks will have1 much impact on doings at the Q, I haven't a clue.h   ------------------------------  % Date: Wed, 28 Nov 2001 07:33:04 +0100o& From: Bob Marcan <bob.marcan@aster.si>5 Subject: Re: Compaq's Secret VMS Plans (The Inquirer)r( Message-ID: <3C048520.3058B71E@aster.si>   The message was:  / Tru64 port goes on, but will never be released.    -Bob     Bill Todd wrote: > < > "Warren Spencer" <wspencer@ap.nospam.org> wrote in message3 > news:91668821Cwarrenspencer1977@207.126.101.97...o/ > > billtodd@metrocast.net (Bill Todd) wrote in-: > > <D4PM7.70514$uB.11455648@bin3.nnrp.aus1.giganews.com>: > >a > > >n? > > >"Warren Spencer" <wspencer@ap.nospam.org> wrote in message 6 > > >news:91666EA00warrenspencer1977@207.126.101.97... > > >  > > >... > > >eL > > >> I wouldn't expect much of this to be spent of OpenVMS marketing.  TheK > > >> Intel/Compaq deal is based on processors, not OS's.  I suspect Q canh: > > >> spend the $$ on marketing Tru-64 - and likely will. > > >oH > > >Did I miss a page lately?  Last I thought I knew, the Tru64 port to > > >Itanic was cancelled. > > >r > > >- billa > >-M > > More likely I missed a page Bill.  Did HP cancel it or Q?  The odds of HPI1 > > making the call seem to be dwindling of late.  > N > Sorry I can't give a citation off the top of my head, but I thought that theN > port had been publicly called off (at least in the sense of such a statementM > leaked by a Compaq manager in a position to do so authoritatively) in favor K > of the proposed post-merger 'convergence' of HP/UX and Tru64 (which seemsoG > likely to mean HP/UX with some Tru64 goodies eventually cobbled on if N > possible).  Though I'm not sure how such a decision could be reconciled withE > my other impression that HP and Q were nominally supposed to remainoF > competitors until the merger had been approved and continue on their > pre-merger courses.  > K > Anyone else have a solider recollection?  My guess would be that a strollaM > through the Inquirer and Register archives would turn up a hit.  I've addednD > comp.unix.tru64 to the distribution, since people there are likely, > considerably better-informed in this area. >  > - bill   --  @  Bob Marcan                           mailto:bob.marcan@aster.si?  Aster                                tel:    +386 (1) 5894-329 ?  Nade Ovcakove 1                      fax:    +386 (1) 5894-201.@  1000 Ljubljana, Slovenia                    http://www.aster.si   ------------------------------  % Date: Tue, 27 Nov 2001 14:32:05 -05006- From: JF Mezei <jfmezei.spamnot@videotron.ca> B Subject: Re: Compaqs VMS plans for IPF port ... any doubters left?, Message-ID: <3C03EA31.B5ABE50D@videotron.ca>   Bob Ceculski wrote:h > F > this sounds very encouraging ... any doubters left about VMS future?  M If it doesn't come from Winkler or Capellas and written on a contract, it canr be changed. Witness Alpha.    E > what we can work into our test and qualification resource plan. The-0 > need for VAX support is somewhat questionable.  N The wording should have instead been "we will evaluate our customer's need forK VAX support". The wording used implies a decision has already been made and  they will strive to justify it.D  A > We will be porting almost the entire OpenVMS Alpha V7.2 layered   > product portfolio over to IPF.  L "almost" is the keyword here.  Until the specifically announce which productK will NOT be ported, then customers won't be able to know what the murder ofi Alpha will mean to them.  H > qualification. We don|t think we need to port products in retirement,F > product in mature product support, and products that we never ported > to Alpha.S  H Humm, I can think of many products in that category which would make theH customer's port impossible. Consider products such as FMS, DECwrite, CDAM converter library. I suspect there are a great many number of mature software J products that are still in mainstream use. Evertyone which Compaq secretlyN decides not to port will be a very bad surprise for customers late in the game6 and will require a fight to get the redicion reviewed.  K If Compaq were to be honest and produce the list of dead products NOW, thenvO customers could react before it is too late and would make much less of a fuss.y      D > Marketing also has matching funds as part of the agreement, and weD > have put a plan forward to leverage our H2 2001 marketing spending > with Intel funds.a  I Somehow, hearing that aver so annoying intel sound in a Compaq ad for VMS N would make me sick on the one side, but then if it means that Intel will allowJ Compaq to market VMS against Microsoft, then that would be very good and IK might be able to tolerate the intel tune. Somehow though I doubt I will seey" VMS mentioned on TV ads by Compaq.  K Intel likes to subsidize hardware advertising, not software advertising. So I we'll see the Intel logo and "Intel Inside" on the successors of wildfire F systems. Doesn't mean that they will pay for VMS specific advertising.   ------------------------------  % Date: Tue, 27 Nov 2001 14:52:41 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>tB Subject: Re: Compaqs VMS plans for IPF port ... any doubters left?, Message-ID: <3C03EF03.7DD83B68@videotron.ca>   Rob Young wrote:B >                 -- "Our capital plan was approved by management" > G >         John... you and I work with budgets.  The money is set aside.e% >         That is always good, right?n  ' Yep. Both EV7 and EV8 were funded too. s    M >                 -- "Our incremental headcount plan was approved, and we aree2 >                         hiring new developers. "  M But nothing says that when the next quarter comes and Compaq has to give WallyM Street Casino analysts something to bite to ease the pain of the bad numbers,nN Compaq/HP may annoucne a round of employee reductions. Also remember that whenJ Compaq ceases to exist, Carly will will stuck with way too many employees.  N If Intel will be late with a IA64 that is platable, then it would be easy (andN logical) for Compaq to reduce headcount and stretch the porting project over 56 extra years while they wait for a IA64 that beats EV7.  P >                 -- "We will develop and offer Mixed Architecture VMSclusters." > I >         That is for me.  That makes a migration in a cluster relatively . >         easy.  Been there , done that , etc.  N That is one of the most meaningless statement. Mixed architecture VMS clustersI have exsisted since the early 1990s.  And since they have stated that VMSeM would use a common code base for Alpha and IA64, then if Alpha supports mixedhH architecture clusters, IA64 shoudl have no problems doing so unless they4 specifically add compilation flags to disable stuff.  M Lets not forget that the statement then goes on to say that they won't commit-- to VAX being part of clusters involving IA64.a  P >                 -- "We anticipate that we will be able to recompile and relinkL >                    for the great majority of the layered products with theF >                    bulk of the porting effort devoted to testing and* >                         qualification. "    F At least they acknowledge that a port is more than a simple recompile.    M > "Yes, we still feel that a VMS port to Itanium should be cancelled.  First,-H > it would be a complex and probably costly migration that many customer% > business managers would flinch at."  > E >         Not given mixed architecture clusters AND most applications # >         being a simple recompile.     K But even Compaq admits that the bigger part of the port isn't the recompile-! but the testing nd qualification.-   ------------------------------  % Date: Tue, 27 Nov 2001 19:53:34 +0000a4 From: Andrew Swallow <andrew.swallow@baesystems.com>B Subject: Re: Compaqs VMS plans for IPF port ... any doubters left?. Message-ID: <3C03EF3E.6C34ECAD@baesystems.com>   John McLean wrote: >  > Bob Ceculski wrote:e [snip] > >aF > > Marketing also has matching funds as part of the agreement, and weF > > have put a plan forward to leverage our H2 2001 marketing spendingH > > with Intel funds. We have a detailed communication plan rolling out,9 > > and are working a large number of go to market plans.E > D > It sounds like Compaq plucking up the courage to make some kind of/ > commitment to VMS, albeit with Intel's money.e > 6 Intel may be trying to escape from Microsoft, possibly as a contingency plan.    5 Being paranoid, what instruction set does Microsoft's. Box use?  1 Does it have a port that can be used to connect ae2 keyboard and printer?  Or are they waiting for the mark 2?  -- o7 _______________________________________________________T Andrew Swallow   ------------------------------  % Date: Tue, 27 Nov 2001 21:27:36 +0000t% From: Alan Greig <a.greig@virgin.net>uB Subject: Re: Compaqs VMS plans for IPF port ... any doubters left?* Message-ID: <3C040547.FA1FBFCD@virgin.net>   Andrew Swallow wrote:o   >u7 > Being paranoid, what instruction set does Microsoft'sn
 > Box use? >/  J It runs a cut down Windows 2000 on Intel. If MS ever want a 64 bit versionH perhaps Hammer would be the easier route. An IA64 in IA32 emulation modeA would be too slow by miles at running existing XBOX games. Hmm...m --
 Alan Greig   ------------------------------  # Date: Tue, 27 Nov 2001 23:16:39 GMTn2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)B Subject: Re: Compaqs VMS plans for IPF port ... any doubters left?3 Message-ID: <r9VM7.2016$RL6.62420@news.cpqcorp.net>I  i In article <55f85d77.0111270435.1a7bc32a@posting.google.com>, P.Young@unsw.EDU.AU (Patrick Young) writes:i ..C :Given the arguments and "120+ posting" threads on all of this over H :such a long period, I just can't ignore the fact that there are OpenVMSJ :developers, Hoff et al. who post to this newsgroup and are positive aboutB :the port. They are doing the work. Put yourself in their place...  I   Folks here in OpenVMS Engineering will likely be posting somewhat less bF   frequently than usual, as we're all a little busy right now with the'   new Alpha and the new Itanium work.  1  H   Various new boxes have arrived here in Engineering, and the engineers F   are now understandably swarming all over them... (The first goal of E   any engineer has already been achieved: take each of the new boxes >D   apart and then see how it fits back together.  And -- I'm not sureD   if this is a credit to the skills of the hardware or the software @   engineers -- the boxes still worked after the reassembly.  :-)  E   We may soon have to officially close the OpenVMS Itanium bootstrap mH   contest submission window -- after the submission deadline, we can no H   longer accept your guesses for the date when OpenVMS first bootstraps    on Itanium.  :-)  I   We now return y'all to the regularly-scheduled newsgroup discussions..."    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------    Date: 27 Nov 2001 19:14:14 -0600+ From: young_r@encompasserve.org (Rob Young) B Subject: Re: Compaqs VMS plans for IPF port ... any doubters left?3 Message-ID: <hPxy6b$ljw$o@eisner.encompasserve.org>.  = 	[Somehow I posted the wrong thing.  Lately, I have taken to rD 	editing scratch files and then cutting and pasting.  Over the years@ 	I have lost too many posts.... AHHH!  But even given the choice@ 	with GUI/HTML newsreaders... they are just too slow!  Maybe the> 	kids don't care as that is what they grew up with... me?  I'm; 	used to speed and not waiting for Java/graphis to make ther= 	words pretty.  I'm not anti-technology.  I am learning other7 	things.  Enough rambling]    n In article <BvOM7.131154$2w.8427119@bin4.nnrp.aus1.giganews.com>, "Bill Todd" <billtodd@metrocast.net> writes: > : > "Rob Young" <young_r@encompasserve.org> wrote in message   >>A >> This contrasts greatly with what Mr. Peter Kastner of Aberdeent% >> Group wrote in his position paper:n >>F >> "Yes, we still feel that a VMS port to Itanium should be cancelled. > First,I >> it would be a complex and probably costly migration that many customer>& >> business managers would flinch at." >>> >> Not given mixed architecture clusters AND most applications >> being a simple recompile. >>) >> His reasoning is even more flawed now.? > K > Indeed it is.  But he started from the premise that Compaq was performing F > the port in an actual attempt to make continued use of VMS on ItanicK > feasible rather than as a political move to attempt to reduce the rate ofnL > exodus of existing customers, so it's no wonder his conclusion was flawed. >   ? 	I have a hardcopy of his report right here... all two pages ofi< 	it.  Perhaps it is best to quote the whole paragraph to get4 	the feel for the duplicitous nature of his writing:  M "Second, the port of OpenVMS to Itanium should not be completed.  The OpenVMSdH installed base has traditionally been a very loyal group for Digital andH later Compaq, but it will be a hard sell to get that base to port matureL applications to HP-UX or Windows NT/2000 on Itanium.  Thus, HP/Compaq shouldN focus on using its existing customer relationships and service capabilities toL make the new company the preferred platform vendor for OpenVMS customers who. want to jump to a more contemporary platform."  ? 	Your point about maintaining an installed base is borne out in @ 	Peter stating "loyalty."  For those that want to jump to a more@ 	contemporary platform will be helped (we will see how well thatC 	works on the guinea pigs using MPE - hint: track down Ultrix usersiB 	on MIPS and test them for loyalty 10 years after the switcheroo).  = 	But we see:  "it will be a hard sell" and "OpenVMS customerspE 	who want to jump" exists a chasm that won't be broached.  Given that ? 	their platform of choice is going away (suppose it is so), therE 	"existing customer relationships and service capabilities" will helpd" 	ease that transition, yeah right.  B 	And yet.. it may be customers that have run flawlessly for years D 	on VMS and view it as "the rug pulled out from under them."  And asD 	I pointed out in another thread as to why a migration AWAY from VMSA 	VAX to another platform/OS was frowned upon... here is a review:r  7 		1)  Much more costly than a migration to VMS on Alpha92 		2)  Will introduce instability (temporary - days3 			maybe) in mission critical applications.  Takingp 			testing into account.  4 	The same could be said of Alpha VMS to Itanium VMS.  F 	Given an easy migration to Itanium... leaving no option but migratingA 	to other OSes for large VMS shops or applications will not breadb> 	loyalty.  MPE users are a case study.  We are already finding 	quotes like this:  1 http://news.cnet.com/news/0-1003-200-7878763.htmlQ    /       HP tests loyalty with server cancellation   M "In my agency within the U.S. Department of Defense, we make extensive use ofoL HP 3000 systems," said Tim O'Neill, of the U.S. Army's Aberdeen Test Center.N "One certainty for our agency is that if they eliminate the 3000, we will then$ act to eliminate our 9000s as well.   O "If HP thinks we will 'migrate' from MPE to HP-UX, they are mistaken," he said,SI referring to the operating systems associated with the two server lines. .   	---   	The Corallary being:   E 	"If HP thinks VMS users will migrate to Windows 2000 on HP hardware,  	they are mistaken."    N > Instead, what makes sense is for Compaq to continue the porting effort untilL > it feels the resulting decrease in attrition no longer justifies it.  ThatN > *could* actually cause it to be completed (or not - the situation is complexL > and not unlike that with EV7, which may or may not ever be a real product,E > depending on - well, it's not clear what Compaq depends upon in itsdM > decision-making processes, but it's certainly nothing so prosaic as logic).  >   H 	It is a real product and is in the Marvel Mansion.  The port to Itanium 	VMS is well underway also.s   				Rob    cc:  kastner@aberdeen.come     	p   ------------------------------  # Date: Wed, 28 Nov 2001 03:42:31 GMTw1 From: "David J. Dachtera" <djesys.nospam@fsi.net> B Subject: Re: Compaqs VMS plans for IPF port ... any doubters left?& Message-ID: <3C045D20.91D0A68@fsi.net>   Patrick Young wrote: > b > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message news:<3C030A5F.D2CF45B8@fsi.net>... > > Bob Ceculski wrote:  > > > - > > > http://www.theinquirer.net/27110101.htm  > > > H > > Sorry, but this hardly constitutes being VMS's future being "cast inL > > stone". It purports great hope, granted. Wonder if something similar was > F > I've noticed that there has been a lot of "Compaq will kill OpenVMS"I > in this newsgroup even before the Alpha announcement. I only really gotsK > back to this newsgroup in June (used to read it around 8 or 9 years ago).. > D > Given the arguments and "120+ posting" threads on all of this overI > such a long period, I just can't ignore the fact that there are OpenVMS K > developers, Hoff et al. who post to this newsgroup and are positive about H > the port. They are doing the work. Put yourself in their place: if youK > even *suspected* "your baby" was to be canned, would you not be "spitting F > the dummy" BIG TIME? - I know I, and perhaps many people here would?  	 Um, Paul?e  C Isn't that *EXACTLY* what I've been doing since I got laid off fromh) Advocate almost *TWO* *YEARS* *AGO*???!!!   G *WE* - You, me and many of the others here - *ARE* in their place, justt somewhat less directly.n  C Time to face facts, man - once they find a way to weasel out of theeH gov't contracts (probably just lie their way out, like they've done with4 all their other "commitments"), VMS is history, man!  F I'm training to teach Solaris Administration, and come Springtime, I'mG looking at training to be an Oracle DBA. I still have 18 years before I B can even think about retiring, I'm dead broke (but my net worth isH almost back up to zero!) and if you don't have that Oracle cert., VMS is9 little more than a fond memory in the Chicago job market.h   Get real, man!   -- r David J. Dachterap dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/m   ------------------------------  # Date: Wed, 28 Nov 2001 03:44:30 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> B Subject: Re: Compaqs VMS plans for IPF port ... any doubters left?' Message-ID: <3C045D99.5A02D89D@fsi.net>.   Patrick Young wrote:  ) Yes, PATRICK! I know - I screwed that up!    -- - David J. Dachtera- dba DJE Systems2 http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/p   ------------------------------  # Date: Wed, 28 Nov 2001 03:47:53 GMTv1 From: "David J. Dachtera" <djesys.nospam@fsi.net>uB Subject: Re: Compaqs VMS plans for IPF port ... any doubters left?' Message-ID: <3C045E64.ED5712A8@fsi.net>n   Patrick Young wrote: > b > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message news:<3C030A5F.D2CF45B8@fsi.net>... > > Bob Ceculski wrote:s > > >i- > > > http://www.theinquirer.net/27110101.htmh > > >tH > > Sorry, but this hardly constitutes being VMS's future being "cast inL > > stone". It purports great hope, granted. Wonder if something similar was > F > I've noticed that there has been a lot of "Compaq will kill OpenVMS"I > in this newsgroup even before the Alpha announcement. I only really gottK > back to this newsgroup in June (used to read it around 8 or 9 years ago).s > D > Given the arguments and "120+ posting" threads on all of this overI > such a long period, I just can't ignore the fact that there are OpenVMSrK > developers, Hoff et al. who post to this newsgroup and are positive aboutaH > the port. They are doing the work. Put yourself in their place: if youK > even *suspected* "your baby" was to be canned, would you not be "spittingAF > the dummy" BIG TIME? - I know I, and perhaps many people here would?   Um, Patrick?  C Isn't that *EXACTLY* what I've been doing since I got laid off frome) Advocate almost *TWO* *YEARS* *AGO*???!!!s  G *WE* - You, me and many of the others here - *ARE* in their place, justi somewhat less directly.   C Time to face facts, man - once they find a way to weasel out of thetH gov't contracts (probably just lie their way out, like they've done with4 all their other "commitments"), VMS is history, man!  F I'm training to teach Solaris Administration, and come Springtime, I'mG looking at training to be an Oracle DBA. I still have 18 years before IsB can even think about retiring, I'm dead broke (but my net worth isH almost back up to zero!) and if you don't have that Oracle cert., VMS is9 little more than a fond memory in the Chicago job market.I   Get real, man!   -- t David J. Dachterao dba DJE Systemsu http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/n   ------------------------------    Date: 27 Nov 2001 15:49:40 -0600+ From: young_r@encompasserve.org (Rob Young)DC Subject: Re: Compaqs VMS plans for IPF port ... any doubters left?y-3 Message-ID: <Bzp8v9h+Xf56@eisner.encompasserve.org>:  n In article <BvOM7.131154$2w.8427119@bin4.nnrp.aus1.giganews.com>, "Bill Todd" <billtodd@metrocast.net> writes: > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:85N6JnxNa56b@eisner.encompasserve.org...aD >> In article <3C0331C2.5BED3103@swissonline.delete.ch>, John McLean) > <mcleanj@swissonline.delete.ch> writes:  >> > >> > >> > Bob Ceculski wrote: >> >>.J >> >> this sounds very encouraging ... any doubters left about VMS future? > N > Well, yuh.  But in a way it's nice to see that some absolute innocence still > exists in the universe.  > # > And kudos for capitalizing 'VMS'.  >  > ...t >  >> How about, Mark writes: >>3 >> -- "Our capital plan was approved by management"s >>@ >> John... you and I work with budgets.  The money is set aside. >> That is always good, right? > 2 > Ah, yes - just as EV8 was 'fully funded', right? >  >>> >> -- "Our incremental headcount plan was approved, and we are >> hiring new developers. "a >> >> Now that says a few things. > L > In particular, that they're willing to spend a small amount of money rightK > now hiring developers to perform a port no one requested in the hope thateF > they'll lose enough fewer sales as a result to more than pay for it. >  >>A >> -- "We will develop and offer Mixed Architecture VMSclusters."  >>B >> That is for me.  That makes a migration in a cluster relatively' >> easy.  Been there , done that , etc.c > H > It's called 'the minimum effort necessary to make this even marginally( > acceptable to any current users', Rob. >  >>A >> -- "We anticipate that we will be able to recompile and relinky= >>    for the great majority of the layered products with thet7 >>    bulk of the porting effort devoted to testing and- >> qualification. "f >>F >> Uh-oh... he didn't say >> all << !  But come on... I'll take "great
 >> majority".e > N > Well, a little truth is better than none at all.  But given the thousands ofJ > layered products (unless he's just talking about internal DECpaq layeredM > products) that run on VMS, expecting that 'the great majority' will even beeC > ported at all let alone with minimal effort seems more than a tadl > over-optimistic. >  >> >>H >> > I have some reservations about some of the document and it would beI >> > interesting to have more detail but maybe - just maybe - Compaq have L >> > seen a light.  One snowflake doesn't make a winter and I hope there's a, >> > lot more follow-up to this Gorham paper > G > Wasn't Gorham the Fairy Godmother who assured Alphaman that Intel waseD > purchasing the rights to Alpha so that it could replace the ItanicM > architectural innards with Alpha architecture (*not* just Alpha engineering.L > expertise applied in an attempt to streamline the Itanic pig)?  I'm afraid) > his credibility isn't what it might be.  >  >> > >> >H >> > I did notice a couple of interesting sentences and here they are .. >> >J >> >> The Compaq/Intel deal has matching funds from Intel for ISV porting, > and I >> >> we will leverage this to bring significantly increased resources toi >> >> our ISVs.n >> >> H >> >> Marketing also has matching funds as part of the agreement, and weH >> >> have put a plan forward to leverage our H2 2001 marketing spendingJ >> >> with Intel funds. We have a detailed communication plan rolling out,; >> >> and are working a large number of go to market plans.d >> > >> >G >> > It sounds like Compaq plucking up the courage to make some kind of 2 >> > commitment to VMS, albeit with Intel's money. > K > Once again, the minimum necessary to prevent even greater loss of current_N > business.  And *please* don't talk about 'commitment' from Compaq (let aloneM > mere minimal support for an unpopular transition) as if it had any meaning.m >  >> > >>D >> But Intel for IPF has money just for situations such as Compaq's. >>A >> This contrasts greatly with what Mr. Peter Kastner of Aberdeenr% >> Group wrote in his position paper:? >>F >> "Yes, we still feel that a VMS port to Itanium should be cancelled. > First,I >> it would be a complex and probably costly migration that many customerl& >> business managers would flinch at." >>> >> Not given mixed architecture clusters AND most applications >> being a simple recompile. >>) >> His reasoning is even more flawed now.s > K > Indeed it is.  But he started from the premise that Compaq was performinglF > the port in an actual attempt to make continued use of VMS on ItanicK > feasible rather than as a political move to attempt to reduce the rate ofiL > exodus of existing customers, so it's no wonder his conclusion was flawed. > N > Instead, what makes sense is for Compaq to continue the porting effort untilL > it feels the resulting decrease in attrition no longer justifies it.  ThatN > *could* actually cause it to be completed (or not - the situation is complexL > and not unlike that with EV7, which may or may not ever be a real product,E > depending on - well, it's not clear what Compaq depends upon in itslM > decision-making processes, but it's certainly nothing so prosaic as logic).g >  > - bill >  >  >    ------------------------------  % Date: Tue, 27 Nov 2001 21:43:25 -0600 + From: Shael Richmond <ksrich@bellsouth.net>e4 Subject: Re: DCL minute of the day: DCL$SMG routines- Message-ID: <3C045D5D.9736C3D2@bellsouth.net>t  ; Could you post the delete_symbol.com routine?  I noticed it  was called from from the demos?r  < I tried playing around with the routines but quickly ran out@ of symbols space.  I upped my clisymtbl to the max but it didn't% help much.  I was logging out a lot!!e   Thanks,    Shaelc   ------------------------------  % Date: Wed, 28 Nov 2001 06:44:36 +0100 , From: Didier Morandi <Didier.Morandi@gmx.ch>4 Subject: Re: DCL minute of the day: DCL$SMG routines& Message-ID: <3C0479C5.B957C147@gmx.ch>  	 Et voil.-   Shael Richmond wrote:d > / > Could you post the delete_symbol.com routine?o  
 $ v=f$v(0)
 $ set noon' $ if p1 .eqs. "" then inq p1 "_Symbols"- $ if p1 .eqs. "" then exit  $ p1 = f$edit(p1,"upcase") - "*" $ delete="delete"a $ say = "write sys$output", $ symbol_file = "sys$login:save_symbols.dat"? $ if f$search(symbol_file) .nes. "" then delete 'symbol_file';*u! $ define sys$output 'symbol_file'F $ show symbol/global 'p1'* $ deass sys$output $ close/nolog ch $ open/read ch 'symbol_file' $LOOP: $ read/end=EOF ch line $ line=f$edit(line,"trim")" $ if line .eqs. "$" then goto LOOP. $ delete/symbol/global 'f$element(0," ",line)'K $ if p2 .eqs. "" then say "global symbol ",f$element(0," ",line)," deleted"h $ goto LOOPo $! $EOF:y
 $ close ch
 $ v=f$v(v) $    D. -- tG   ---------------------------------------------------------------------rE MORANDI Consulting.  WEB: http://Didier.Morandi.Free.fr/index_us.htmlnE Pflanzschulstrasse 53, 8004 Zurich, Switzerland. GSM: +41 79 705 4670./ 19, chemin de la Butte, 31400 Toulouse, France.   I Disaster Recovery Plans, Computer Security Audits, DEC OpenVMS ExpertisegH On parle franais, Man spricht Deutsch, Habla Castellano, English spoken   ------------------------------  % Date: Wed, 28 Nov 2001 06:41:39 +0100 , From: Didier Morandi <Didier.Morandi@gmx.ch>! Subject: Re: DECNET task question & Message-ID: <3C047914.191AD2B0@gmx.ch>   JF Mezei wrote:e  J > Now, inside CHOCOLATE.EXE, what happens when the client process on node1) > closes the link (or decnet goes down). a  M You get %RMS-EOF on input from DCL on the remote system when reading from theiG test channel (I suggest you call it netlink for easy debugging when you 1 procedure will reach more than a thousand lines);V   D. t --  G   ---------------------------------------------------------------------oE MORANDI Consulting.  WEB: http://Didier.Morandi.Free.fr/index_us.htmlsE Pflanzschulstrasse 53, 8004 Zurich, Switzerland. GSM: +41 79 705 4670p/ 19, chemin de la Butte, 31400 Toulouse, France.h  I Disaster Recovery Plans, Computer Security Audits, DEC OpenVMS Expertise H On parle franais, Man spricht Deutsch, Habla Castellano, English spoken   ------------------------------  % Date: Tue, 27 Nov 2001 21:56:30 +0100a, From: Didier Morandi <Didier.Morandi@gmx.ch> Subject: Re: DECnet timeout?& Message-ID: <3C03FDFF.9A524E65@gmx.ch>   Oswald Knoppers wrote:  H > I think you can twist this with the outgoing timer on session control.H > However if you want to know immediately you will need to configure oneA > or more of your systems as a router. If i understand your setup"D > correctly you have only end systems. As there are no routers theseH > systems will just send the packet away. With routers they will ask theD > router and the router will know if the remote system is reachable.   Thanks, will try.P  O Do you know how to enable TCP/IP RPC proxy? I had a look at the doc and did note find it.  O I have a C program which accesses another C program defined as a TCP/IP servicenN on a remote node and I do not want anyone to be able to do so. With the DECnetO task to task stuff it was easy to set up an access control via a proxy. I wouldp- like to do the same with a TCP/IP connection.h   D.   ------------------------------    Date: 27 Nov 2001 12:00:23 -08001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)uV Subject: Re: Disaster Tolerance day organized by Compaq User Group Netherlands (NLCUG)= Message-ID: <cf15391e.0111271200.6811b142@posting.google.com>p  d "Gerrit Woertman" <gerrit.woertman@hccnet.nl> wrote in message news:<9snu48$42p$1@news.hccnet.nl>...N > The Compaq User Group Netherlands (NLCUG, a combination of DECUS and BENTUG)L > organizes on November, 29, in Soest, the Netherlands, a day about Disaster > Tolerance.  > How did this go?  Did many attend?  Is there still much active2 interest in VMS-based disaster-tolerant solutions?C -------------------------------------------------------------------aC Keith Parris | parris at encompasserve dot org | VMS consulting on:3C Clusters, Disaster Tolerance, Internals, Performance, Storage & I/Oo   ------------------------------  % Date: Tue, 27 Nov 2001 23:34:41 +0100e, From: "Bart Zorn" <B.Zorn@TrueBit.nospam.nl>V Subject: Re: Disaster Tolerance day organized by Compaq User Group Netherlands (NLCUG)* Message-ID: <9u14el$rpr$1@news1.xs4all.nl>  > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message7 news:cf15391e.0111271200.6811b142@posting.google.com...o@ > "Gerrit Woertman" <gerrit.woertman@hccnet.nl> wrote in message% news:<9snu48$42p$1@news.hccnet.nl>...HH > > The Compaq User Group Netherlands (NLCUG, a combination of DECUS and BENTUG)nE > > organizes on November, 29, in Soest, the Netherlands, a day aboutn Disaster > > Tolerance. >e@ > How did this go?  Did many attend?  Is there still much active4 > interest in VMS-based disaster-tolerant solutions?E > -------------------------------------------------------------------yE > Keith Parris | parris at encompasserve dot org | VMS consulting on:tE > Clusters, Disaster Tolerance, Internals, Performance, Storage & I/Ot   Hello Keith!  I You are a little bit early with your question! However, I appreciate yourn	 interest!   F I can tell you that we have 86 preregistered attendants, and we expect
 several more!p  L I will make sure that we (the NLCUG board) will publish a short report after	 Thursday.    Regards,  	 Bart Zornf   ------------------------------  % Date: Tue, 27 Nov 2001 23:00:01 +0000?% From: "a.carlini" <arcarlini@iee.org>>5 Subject: Re: DSSI VAXcluster manual on line anywhere?e' Message-ID: <3C041AF1.3B16E083@iee.org>:   "B.Eckstein" wrote:n& > Do you remember the exact commands ?/ > It would be nice to connect my 3190 over DSSI  > to my 4500 and 4600.  - When (if!) I track them down, I'll post them.c  % I don't have a MicroVAX 3100-90 handye" otherwise I could probably work it out by trial and error.d   At the console, type:t >>> T 9E   This gives you a list of tests& that can be used. It does not tell you$ how to use them and it does not list$ anything that looks like it might be the conversion you want.  1 9D looks like a possible candidate, try that one.o  - When you do find the right test, the requiredc- parameter is the model you wish to switch to. / So if you are a KA50 (uVAX 3100-90) and wish top, become a KA52 (VAX 4000-100) you feed in 52.  ) It sits there for a while, re-writing its & flash to do this. Don't switch off !!!  ) I'll go search my email properly tomorrow / to see if I can dig out the exact instructions.n Don't hold your breath!m   Antonio    -- h   ---------------'- Antonio Carlini             arcarlini@iee.orga   ------------------------------  # Date: Tue, 27 Nov 2001 23:41:30 GMTh2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)4 Subject: Re: Graphics cntrlr not recognized by 5.5-23 Message-ID: <KwVM7.2018$RL6.62491@news.cpqcorp.net>a  k In article <E3QM7.1999$RL6.61746@news.cpqcorp.net>, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes: K :Are you using the built-in LCG, or the SPX?  Sounds like whatever you havetH :isn't supported on V5.5-2 - the message you are getting happens when noJ :graphics device driver is loaded during DECwindows startup.  This usually? :means that the graphics support is not present for the option.r  L   Tom was previously running V7.1 (not V7.1-2), and the graphics controller G   identified by the VAXstation 4000 model 60 console is the 4-plane LCGfJ   (Low Cost Graphics) controller.  Other than the various troubleshooting J   details in the OpenVMS FAQ -- the WINDOW_SYSTEM settings and such -- andK   excluding a weird hardware problem with the graphics controller -- I knowrJ   of no reason why a VAXstation 4000 model 60 (with OpenVMS VAX V5.5-2 andL   DECwindows licensed and loaded) would not recognize and would not utilize    the LCG controller.t  I   The contents of the system disk here were originally in use on another pJ   VAX system and were transfered to this VAXstation 4000 model 60 series, K   so the status and the particular configuration of the OpenVMS VAX V5.5-2 u6   system disk here could arguably be somewhat suspect.    :Tom Linden wrote in message ...< :>HW 4000/60 with B/W graphics controller attached to VR319. ..C :>Previously had 7.1-2 running on this and it worked, but installedf1 :>5.5-2 and now the last message after booting is  :>< :>%DECW-W-NODEVICE, No graphics device found on this system.8 :>-DECW-I-NODECW, DEC-Windows drivers will not be loaded ..    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  + Date: Wed, 28 Nov 2001 00:16:46 +0000 (UTC)u From: david20@alpha1.mdx.ac.uk Subject: Re: Invitation...+ Message-ID: <9u1ade$7ip$1@aquila.mdx.ac.uk>d  T In article <3C039C3A.D21EE147@127.0.0.1>, Nic Clews <sendspamhere@127.0.0.1> writes: >Larry Kilgallen wrote:* >> r >b) >> There are several basic rules of spam:t >>   >>         0. Spam is theft. >>         1. Spammers lie.hE >>         2. If a spammer seems to be telling the truth, see rule 1. # >>         3. Spammers are stoopid.a >sI >While it is off topic, last night I discovered my home email address has-C >been used in a spamming operation (return-to address and resultanteI >postmaster and mail admin error messages to me) for some German speakingp# >messages about some site in Spain.t >'E >Tracing has led me to a possible admin of the web site, but short of'F >changing my email address I'm not sure how I can avoid further abuse. >Shape of things to come?O >l >Not happy.l >-- ) >Regards, Nic Clews CSC Computer Sciencest >nclews at csc dot com  H This has become a fairly common spammer tactic recently. UK universities2 suffered massively from this about a year ago. See  ; http://www.ja.net/CERT/JANET-CERT/mail/junk/collateral.htmlc    O More recently the incidents have been on a much smaller scale. There appears toeM be at least one bulk mailer program which randomly picks one of the addressesaI it will be sending to and uses that as the forged reply address for say aDM hundred messages and then picks another one of the addresses for the next one- hundred etc.N This causes less problems for mail administrators since you don't get hundredsL and hundreds of bounces and complaints. (In some cases the number of bounces9 was such that the victim's mail account became unusable).8G However it can still cause consternation for the user when they receive3J complaints about the spam they supposedly sent especially given the sexual nature of some of the spam.c      
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  % Date: Tue, 27 Nov 2001 15:01:49 -0500h- From: JF Mezei <jfmezei.spamnot@videotron.ca>h* Subject: Re: logical names novice question, Message-ID: <3C03F128.74E999B1@videotron.ca>   Pino Gargiulo wrote:E > Any body care to give me an example of sofisticate use of logicals?r  J There are many examples of logicals which are defined in executive mode to! prevent users from abusing them. f  J For instance, an application which allows you to add your own functions byJ tagging on a shareable image would require that the image be installed andJ that a logical pointing to its location be defined in executive mode. ThisH would prevent a simple user of defining his own "normal" logical name toL supercede the executive version and redirect the application to use a trojan/ horse shareable image that does something else.d  L Another really neat one is the ability to have a logical name defined on oneF node but it automatically becomes available on all nodes of a cluster.  K There is also a way to define a logigal so that it appears as a device namebH and isn't translated in displays etc.  So you can place your users loginM directories below a tree on a specific disk but have the users think they arerH located on "USERDISK:". This allows you to move the users to a different; physical disk or dorectory without any impact on the users.<   ------------------------------  # Date: Wed, 28 Nov 2001 03:02:48 GMTe3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk>u* Subject: Re: logical names novice question/ Message-ID: <3C045269.A6989062@cableinet.co.uk>c   Pino Gargiulo wrote: >   t > E > Any body care to give me an example of sofisticate use of logicals?m >   rE OK, Nic has expounded on the benefits of being able to setup multipleoH instances of environments (eg development, test, production) on a singleH machine and be damn sure that they won't interact. Search lists are very: useful when developing with CMS using reference libraries.  F I quite like using logicals to control detached processes. Either use E group, system or a custom shareable name table. Control the behavioureG of the detached process by shared changing logical names that are read aF in the program loop. Great for daemon like processes that do a little = processing but mostly hibernate. Its quite nice to be able tod enable/disableH verify mode without restarting the process all the time, especially when developing DCL.   E You have to use carefully though, I do remember helping sort out somegB physics code once that was limited by the logical name translationH capablity of the hardware, because a name was being tralated in an inner
 program loop.t  ! there are many more applications.f regardse --   Tim.Llewellyn@cableinet.co.uk  w  C Standard disclaimer applies. My views in no way represent those of  ! my employers or service provider.a   ------------------------------    Date: 27 Nov 2001 15:09:38 -0800( From: bob@instantwhip.com (Bob Ceculski); Subject: New product allows VMS to become part of a PC Lan!i= Message-ID: <d7791aa1.0111271509.4f1bf490@posting.google.com>   C Just ran across this amazing product as we were looking to make our  Alphal? VMS system part of our local PC Lan and ran across this amazinge product ...oE they also have a product that allows VMS pc disk access ... amazing! > here isI$ the link if anyone is interested ...  A Disclaimer:  I do not work for the following company, but am onlye	 trying to @               assist other VMS users in their quest for neat new	 products.e  1 http://www.vector-networks.com/lanprint/index.htm   , LANprint for OpenVMS to Windows NT Printing  OPENVMS SOLUTIONS  LANutil for OpenVMSs  + LANprint for OpenVMS to Windows NT Printingv  ! Download Free Evaluation Softwares  & Online Documentation for VMS Solutions  > LANprint enables you to print from OpenVMS to Windows and OS/2= printers using their native LAN Manager Print Server support.n  D It offers improved TCP/IP functionality and support for OpenVMS v7.    Key Features@ No LAT needed: uses standard Microsoft SMB protocol, over either TCP/IP or DECnet.gF The shared printers are accessed transparently to applications through standard OpenVMS print queues.D The OpenVMS host shares printers just as if it was another client on the LAN.? NetWare server printers can be accessed through the LANprint/PCo bridge.eA Each Print Symbiont is capable of supporting sixteen print queuesE simultaneously.m? Queues may be directed to the same remote network printer or tol several different printers.iB Remote printers can be distributed across numerous remote servers,@ including when they are part of a wide area network environment. Pricing and MediaeF LANprint is priced by the number of standalone VMS nodes and/or entireE VMS Clusters that are to be supported. All nodes in a VMS Cluster are-& covered by a single 'Cluster' license.  E LANprint is sold in electronic download form only. No paper manual isdB provided. You can download a fully-functioning evaluation kit thatD will work for 30 days from the installation date. This allows you to6 evaluate LANprint in your environment before purchase.  D Standalone VMS Node Pricing - $895 per system, plus $134.25 per year maintenance.  E VMS Cluster Pricing - $1340 for the entire Cluster (regardless of theL7 number of nodes in it), plus $201 per year maintenance.C  F Please contact Vector for discounted prices if you wish to purchase 10 or more licenses at once.m   ------------------------------  % Date: Tue, 27 Nov 2001 15:12:14 -0500s; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>" Subject: Re: newsreaders... " Message-ID: <3c03f3a1@news.si.com>  / >I'm looking for a good newsreader for OpenVMS.l  A I like BULLETIN from ftp://psfc.mit.edu/bulletin/ and Mosaic fromm  ftp://wvnvms.wvnet.edu/mosaic/ . --A Brian Tillman                   Internet: tillman_brian at si.com'A Smiths Aerospace                          tillman at swdev.si.coml= 3290 Patterson Ave. SE, MS      Addresses modified to prevent(< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  % Date: Tue, 27 Nov 2001 18:37:44 -0500-0 From: Jason Fountain <Jason.Fountain@compaq.com>! Subject: Re: NTP under TCPIP V5.1r* Message-ID: <3C0423C8.AC1604AA@compaq.com>  J Try deleting the drift file, running ntpdate to the server (without -q) to! set the time, and restarting NTP.c  G Also make sure that DTSS isn't running on the system....mcr ncl disablea dtss.M   -jac   Martin Hunt wrote:  G > On Thu, 22 Nov 2001 21:23:23 GMT, martin.hunt@inl.co.nz (Martin Hunt)o > wrote: >3G > >I have recently upgraded a VAX from TCPIP services V4.2 to V5.1 (ECOE> > >3). NTP was working fine before, but now is having problems$ > >synchronising with an NTP server. >XH > I have now logged a call with Compaq, and have sent heaps of output toC > them, but we haven't got very far yet. Any further ideas would bee > appreciated. >g > ---h
 > Martin Huntl > Systems Administratore  > Independent Newspapers Limited > Wellington
 > New Zealandh   ------------------------------  # Date: Tue, 27 Nov 2001 19:12:53 GMT-F From: lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman)8 Subject: Re: Obtaining System Serial Number via Software3 Message-ID: <VARM7.2005$RL6.61830@news.cpqcorp.net>9  9 I'm going to pass on a question about the help message toc9 the documentation people to find out if there's somethinge7 I don't know about the command, or if the message needsa- to be changed.  Thanks for pointing this out.-  < The only really reliable way to get the system serial number< on all possible systems that I know of is to read the actual< number printed or stamped on the cabinet.  I understand that; this isn't always convenient when the system is in a remotee= location, or when there are many systems to check, but if thei< number needs to be completely reliable for contract purposes that is the way I'd obtain it.   -- c(  B. Z. Lederman   Personal Opinions Only  8  Posting to a News group does NOT give anyone permission8  to send me advertising by E-mail or put me on a mailing  list of any kind.  5  Please remove the "DISABLE-JUNK-EMAIL" if you have ak5  legitimate reason to E-mail a response to this post.    ------------------------------  # Date: Tue, 27 Nov 2001 19:47:08 GMT 8 From: hammond@not@peek.ppb.cpqcorp.net (Charlie Hammond)8 Subject: Re: Obtaining System Serial Number via Software3 Message-ID: <05SM7.2008$RL6.61883@news.cpqcorp.net>c  * In article <3C03CF0D.B4AE51BB@UIowa.EDU>, ) Rick Dyson <Rick-Dyson@UIowa.EDU> writes:-   >$ Help Show CPU >SHOW  >a >  CPU >2L >      Displays the current state of the processors in a VMS multiprocessing >      system. >eL >      Applies only to VMS multiprocessing systems. Requires change mode  to! >      kernel (CMKRNL) privilege.o >eL >From an example system like what I needed the number for, a VAX/VMS v5.3-1:   Lots has changed since V5.3-1!2 Among other things, SHOW CPU and its help entry...  
 $help sho cpud   SHOW     CPUi  A        Displays the current state of the processors in an OpenVMS         system.  
        Format   !          SHOW CPU  [cpu-id[,...]]  ..  F It does appear to work on both VAX and Alpha uni-processors in currentF version of OpenVMS.  "Current" means V7.2-1 and later -- probably some? earlier too, but I don't know exactly when the change was made.t  3 ..all of which is not much help for V5.3-1.  {sigh}    -- -K     Charlie Hammond -- Compaq Computer Corporation -- Pompano Beach  FL USA H        (hammond@not@peek.ppb.cpqcorp.net -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------  # Date: Tue, 27 Nov 2001 23:19:57 GMTm2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)8 Subject: RE: Obtaining System Serial Number via Software3 Message-ID: <xcVM7.2017$RL6.62493@news.cpqcorp.net>n  | In article <gMNM7.1987$RL6.61572@news.cpqcorp.net>, lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman) writes:  A :As others have noted, not all systems have a fixed serial numberoA :programmed into them.  In some cases, you can set something thate2 :will act as a serial number with the SRM console. ..  K   The FAQ section "How do I get a unique system ID for licensing purposes?"|   will be of interest...    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Tue, 27 Nov 2001 20:56:18 -0500d4 From: "Mark Buda" <buda@tabasco.zko.dec.no.spam.com>8 Subject: Re: Obtaining System Serial Number via Software, Message-ID: <9u1g84$9bam$1@lead.zk3.dec.com>  H In one of the more recent releases you can get the serial number via theE $GETSYI lexical and the standard system service SYS%GETSYI interface.dD This does not go back very far, so has limited ability.  It works onH wildfire systems with all patches and V7.3 on, from what I can remember.  0 star> write sys$output f$getsyi("serial_number")  00000000000000000000000000000000  F As has been repeated many times, some machines have serial number someD don't.  Some you can change, some you cannot.  I would not depend on this cell from day to day...     --  	 Mark Budan Compaq Computer Corporatione VMS Engineeringh 110 Spitbrook Road
 MS: ZK3-4/X57g Nashua, NH 03062 Voice: (603) 884-1969m FAX: (603) 884-3451c   ------------------------------  % Date: Tue, 27 Nov 2001 14:29:10 -0500X> From: "Koska, John C. (LNG-MBC)" <John.C.Koska@lexisnexis.com>4 Subject: OpenVMS and minicopy... a note of thanks...M Message-ID: <3D35AD137AAAD411A6BA0008C7B1B12D016025A3@MBCALBEXC03.BENDER.COM>t  6 I would just like to take a moment to thank those who 3 did the work on including the minicopy feature intol volume shadowing of OpenVMS.  8 For my site, we typically see 6 to 8 hours to accomplish9 full shadow copies.  With the minicopy feature, our testsR8 thus far have shown that it only takes 15 to 30 minutes  for remaking our shadowsets.  ; Thanks go to OpenVMS Engineering for continuing to provide  ( a superior product, and on enhancing it.   Back To Lurking,   :) jck
 John Koska Matthew Bender & Co., Inc. -"   A Member of the LexisNexis Group
 1275 Broadwayt Albany, NY  12204g USAg 518-487-3255 John.C.Koska@lexisnexis.coms  ) I post personal opinion only, and all thel* disclaimers one could imagine apply.  That( includes, I speak for myself only and my) views in no way represent my employer(s).r+ One should also take note of the Electronica) Communications Privacy Act of 1986, whichC+ imposes civil and criminal liability on anyt( person who intentionally intercepts "any( wire, oral or electronic communication."   ------------------------------  % Date: Tue, 27 Nov 2001 19:27:50 -0500p  From: John Santos <JOHN@egh.com>6 Subject: Re: OpenVMS for Itanium: Marketing Suggestion6 Message-ID: <1011127192655.16710B-100000@Ives.egh.com>  ) On Tue, 27 Nov 2001, Fabio Cardoso wrote:   0 > I dont know if do you agree, but I feel a lack > of identity in OpenVMS.n > 0 > In the lauch of  OpenVMS for Itanium I suggest) > to create an official logo for OpenVMS.s > 4 > Should be a new "Shark" or even a Intel like logo: > % > "Itanium powers OpenVMS"... etc ...  > 4 > What do you think ? In these times of Penguins and1 > "Windows" logos, I believe it is important for t6 > OpenVMS : even a standard font to write OpenVMS - no > Coca Cola fonts please ! :). > 	 > Regards  >  > FC e  ) Hmmm...  Sharks eat penguins, don't they?o   -- c John Santosd Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Wed, 28 Nov 2001 02:11:00 GMTt# From: ualski <ualski@earthlink.net> 6 Subject: Re: OpenVMS for Itanium: Marketing Suggestion- Message-ID: <3C0447A8.229A6DCA@earthlink.net>-   John Santos wrote:+ > On Tue, 27 Nov 2001, Fabio Cardoso wrote:e2 > > In the lauch of  OpenVMS for Itanium I suggest+ > > to create an official logo for OpenVMS.- > >a6 > > Should be a new "Shark" or even a Intel like logo:6 > > What do you think ? In these times of Penguins and2 > > "Windows" logos, I believe it is important for8 > > OpenVMS : even a standard font to write OpenVMS - no > > Coca Cola fonts please ! :)w > + > Hmmm...  Sharks eat penguins, don't they?s  : Seems to me that penguins are smellier and make more noise. too.  But they are cute and have wider appeal.   -- Aaron Sliwinski   ------------------------------  % Date: Tue, 27 Nov 2001 20:37:36 -0600f% From: Keith Brown <kbrown780@isd.net> 6 Subject: Re: OpenVMS for Itanium: Marketing Suggestion/ Message-ID: <u08jb877nk2b67@corp.supernews.com>    John Santos wrote:  + > On Tue, 27 Nov 2001, Fabio Cardoso wrote:  > 1 >> I dont know if do you agree, but I feel a lacka >> of identity in OpenVMS. >> b1 >> In the lauch of  OpenVMS for Itanium I suggestr* >> to create an official logo for OpenVMS. >> s5 >> Should be a new "Shark" or even a Intel like logo:  >> o& >> "Itanium powers OpenVMS"... etc ... >> h5 >> What do you think ? In these times of Penguins andU1 >> "Windows" logos, I believe it is important fora7 >> OpenVMS : even a standard font to write OpenVMS - noj >> Coca Cola fonts please ! :) >> l
 >> Regards >> a >> FC  > + > Hmmm...  Sharks eat penguins, don't they?  >   " Sharks eat just about anything ;-)   -- s Keith Brownd kbrown780@isd.nete   ------------------------------  # Date: Wed, 28 Nov 2001 04:03:38 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>s& Subject: Re: OT Re: AMAZON RAIN FOREST' Message-ID: <3C046214.764DA352@fsi.net>r   Fabio Cardoso wrote: >  > Davidu > 5 > Like DRUGS, there is the producer and the consumer. 7 > If countries like England, USA and Japan dont buy oure > woods....   E So, it's the consumer's fault if a supplier commits unethical acts to 1 acquire and provide a legitimate product?? (Wood)c  7 Maybe in South American countries, but not in the U.S.!   B ...and the U.S. is *VERY* *ACTIVELY* working to deal with the drug traffic problem.  C I doubt very seriously that military action could be justified justfE because South American countries aren't doing enough within their ownnC borders to stop the cutting and burning (be careful where you point:F fingers!). If one country invaded another's territory to cut and burn,? then UN intervention might be requested and the U.S. might wellu
 participate. r   -- s David J. Dachterae dba DJE Systemsn http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/r   ------------------------------  % Date: Tue, 27 Nov 2001 15:24:23 -0500t% From: Thomas Wirt <twirt@kittles.com>   Subject: Re: PATHWORKS Licensing* Message-ID: <3C03F677.1000303@kittles.com>  G You would only need a PW 32 license for the PC that is running DECNET. oF DECNET for Windows is the main thing that you are paying for when you G buy PW32 for a PC.  The operation that you describe should not consume a or require a server license.   Thomas Wirtl   Manfred Friedrich wrote:   > Hello, > ? > a have a question about PATHWORKS licensing  which could alsoi > be a question for a FAQ: > 9 > Do I need a license for a NT workstation if I only wantd< > to do DECNET task-to-task communication to our VMS server?6 > I don't need access to file, disk od print services. >  > Thanks for your answer.a > 	 > Manfrede >    ------------------------------  % Date: Tue, 27 Nov 2001 14:12:10 -0700M0 From: "Mike O'Malley" <mike.l.omalley@intel.com> Subject: PGP for OpenVMS* Message-ID: <9u0v9n$dk4@news.or.intel.com>  E Can someone please point me to the location of a PGP port to OpenVMS.    thanks,o     ...Mikex ------------ mike.omalley@mail.comm   ------------------------------  # Date: Tue, 27 Nov 2001 23:49:01 GMTl2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: PGP for OpenVMS3 Message-ID: <NDVM7.2019$RL6.62489@news.cpqcorp.net>a  ] In article <9u0v9n$dk4@news.or.intel.com>, "Mike O'Malley" <mike.l.omalley@intel.com> writes:iF :Can someone please point me to the location of a PGP port to OpenVMS.  A   According to google, some of the following will be of interest:e  .     http://finerty.net/pjf/crypto/vms-pgp.html)     http://www.pl.pgpi.org/platforms/vms/e8     http://www.radiusnet.net/crypto/archive/pgp/vax-vms/+     http://www.antinode.org/dec/sw/pgp.htmlnJ     http://www.funet.fi/pub/crypt/cryptography/pgp/OLD/vax-vms/README.html     ...n  I   Various of the existing (busted) PGP links in the FAQ and these new PGP J   URLs were recently forwarded to the clown that is currently maintaining J   the OpenVMS FAQ, so that folks (well, those folks that do actually read @   the FAQ :-) don't encounter this (particular) confusion again.  K   You'll also want to look at/for GnuPG, as well.  I do not know if a port i&   of that tool exists for OpenVMS yet.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Tue, 27 Nov 2001 22:29:18 +0100o( From: Paul Sture <paul.sture@bluewin.ch>J Subject: Re: RMS file structure internals documentation freely available ?- Message-ID: <VA.000004d0.a206814d@bluewin.ch>   K In article <HKwM7.38283$xS6.62850@www.newsranger.com>, Simon Clubley wrote: 0 > On Sun, 25 Nov 2001 11:24:22 +0100, in article6 > <VA.000004cc.95590456@bluewin.ch>, Paul Sture wrote: > >eN > >In article <BrbL7.34376$xS6.59300@www.newsranger.com>, Simon Clubley wrote:3 > >> On Wed, 21 Nov 2001 22:44:48 +0100, in articleT9 > >> <VA.000004c6.832e8c0f@bluewin.ch>, Paul Sture wrote:D > >> >T > >> >I did manage to dig up a reference to an RMS-11 Internals manual in old DECUS U > >> >SIGtapes. How to get hold of them in readable format I don't know (did I see a d  > >> >mention of BRU in there?). > >> >T > >> >http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/decus/11s1 > >> >01.html      t > >> > > >> p > >> Found it. :-) > >> aS > >> Noting that the document at the above URL is from the RSX SIG Spring Symposiume7 > >> Collection for 1988, digging around further gives:  > >>  l > >> http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/rsx/decus/rsx88a/373310/rmsint2.doc > >> eP > >Well, er, yes. Here's a question: Out of that 140 pages did you find anything > >of practical use? > N > Well, er, yes. :-) Although I have not had the time to study the document inJ > detail yet, I was after an RMS version of the ODS-2 McCoy book, which isM > what this document is. My main interest was in seeing how indexed files areaL > stored on disk, and although the document is very dated (ie: no Prolog 3), > it is at least a start.  > N Got you. I was a bit disappointed because it deliberately assumed that you hadK the various other manuals to hand, and I suspect the ones I read were later  versions than those referenced.s   ___o
 Paul Sture Switzerlando   ------------------------------  % Date: Tue, 27 Nov 2001 21:00:18 -0500N4 From: "Mark Buda" <buda@tabasco.zko.dec.no.spam.com>& Subject: Re: RWAST problems - Part ..., Message-ID: <9u1gff$9adq$1@lead.zk3.dec.com>  ; "Fabio Cardoso" <fabiopenvms@yahoo.com.br> wrote in messagel: news:20011126154717.29796.qmail@web20201.mail.yahoo.com...+ .Last week I discovered another thing about- .my rwast problem:  C With the very limited amount of information provided, it could be atB process that has been deleted, it could be a process that is beingF activated, it could that the system manager has the quotas set too low for the process and it hangs.I  E More information would be required to figure out what is going on.  Ie3 would suggest contacting the CSC to look into this.e     --  	 Mark Budat Compaq Computer Corporation  VMS Engineering  110 Spitbrook Road
 MS: ZK3-4/X57P Nashua, NH 03062 Voice: (603) 884-1969i FAX: (603) 884-3451    ------------------------------  % Date: Tue, 27 Nov 2001 16:20:22 -0500 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>-7 Subject: Re: Security patch multihomes X Display Server 3 Message-ID: <CtTM7.2012$RL6.61942@news.cpqcorp.net>j  K My "guess" is that the patch was built from the mainline, and so you pickedrL up any recent fixes as well as the security fix.  That is typically what the DECwindows maintainers do.    ( bart@CTI01.COMVERSE.COM wrote in message8 <3bf98f48$0$20890$724ebb72@reader2.ash.ops.us.uu.net>...> > Recently I was stewing once again from the fact that the VMSD >X display server would not (easily) handle requests for displays on	 secondaryPJ >and tertiary interfaces present on the system. When I asked in this forumK >a year or so ago, Hoff had suggested I contact The Colorado support centerg onL >this. I did and the disappointing answer from them was that this was indeedI >an area in which VMS was inferior to Unix and even the lowly PC. Today I J >downloaded and installed the mandatory security patch which was discussedB >recently here. Afterwards, on a whim, I decided to try once againK >to try opening an X window directly via the secondary interface and, to myMI >amazement, it now works! I am wondering if this was actually part of the @ >change implemented by the patch per se or perhaps was inheritedF >funtionality added to the corresponding images in a later VMS version >(I have V7.1-2)?d > Steve Bart >o   ------------------------------    Date: 27 Nov 2001 13:26:49 -0600- From: koehler@encompasserve.org (Bob Koehler) B Subject: Re: Solaris: ready for prime time?  Keep your VMS system.3 Message-ID: <FGs3d6SCzeKP@eisner.encompasserve.org>l  B In article <01112710282103@antinode.org>, sms@antinode.org writes:? > From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>  >> e@ >> Solaris are probably one of the worst unixes around seen from >> a technical point of view ! >> p, >> Tru64 or FreeBSD or AIX are much better ! > I >    Unless you want to add some swap space without adding a disk drive. i > From "man swapon":  G    You can always add swap space without adding a disk drive.  You just.    have to reparition. 8-(  J >    Maybe better as a whole, but not uniformly better.  (Tru64 also lacksH > the SMIT dude, which I always believed to be one of the best things in > AIX.)   D    Everybody's UNIX has it's own.  SMIT is strictly AIX and can't doE    half the things I've needed to do.  SMIT is OK for routine things,.C    but learning the appropriate commands is, too.  I don't care for E    system admins who don't know that much about the system, but then	 A    the AIX commands are maximially different from all other UNIX.rB    (All UNIX are different, but AIX is the most different of all).   ------------------------------  % Date: Tue, 27 Nov 2001 21:16:47 +0000K% From: Alan Greig <a.greig@virgin.net>sB Subject: Re: Solaris: ready for prime time?  Keep your VMS system.* Message-ID: <3C0402BE.D4B300D7@virgin.net>   Bob Koehler wrote:   >rF >    system admins who don't know that much about the system, but thenC >    the AIX commands are maximially different from all other UNIX.aD >    (All UNIX are different, but AIX is the most different of all).   I recall a cookie:  ; "You are in a maze of twisty little Unixes. All Different."s  0 "ADVENT" players will know where this came from.   --
 Alan Greig   ------------------------------  % Date: Tue, 27 Nov 2001 16:22:55 -050015 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>tB Subject: Re: Solaris: ready for prime time?  Keep your VMS system.3 Message-ID: <%vTM7.2013$RL6.61788@news.cpqcorp.net>   4 Where is Andrew?  Come on?  We need the expert here.  J Seriously, I'm getting quite worried about his dissapearance.  Does anyoneK actually know him?  I'd love to chuckle about his being right sized, but amt. concerned that he may have done a Carl Lydick.        Bob Koehler wrote in message ...G >In article <3BF9BC2B.7561FAEE@prodigy.net>, cjt <cheljuba@prodigy.net>a writes:c >> Bob Koehler wrote:  >>> I >>> In article <3BF94D2E.15FB@c-lab.de>, Michael Joosten <joost@c-lab.de>  writes:m >>> >p( >>> > What do you mean with 'wiped out'? >>>tJ >>>    As in kernel starts generating messages claiming the file system is >>>    full. >>- >> That seems appropriate -- not 'wiped out.'p >oI >   The users have no files after the crash, but the file system is full.eF >   That's what I mean by wiped out.  After all I was listening to theB >   beeps that came with the kernel messages and neither I nor theE >   actuall users were particularly worried.  After all, Solaris is aS >   modern UNIX, right?  >i   ------------------------------  # Date: Tue, 27 Nov 2001 21:35:20 GMT * From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Solaris: ready for prime time?  Keep your VMS system.A Message-ID: <sGTM7.134684$2w.8640172@bin4.nnrp.aus1.giganews.com>l  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message- news:%vTM7.2013$RL6.61788@news.cpqcorp.net...h6 > Where is Andrew?  Come on?  We need the expert here. > L > Seriously, I'm getting quite worried about his dissapearance.  Does anyoneJ > actually know him?  I'd love to chuckle about his being right sized, but am0 > concerned that he may have done a Carl Lydick.  J It's entirely possible that he's merely decided that Compaq's actions haveK succeeded in making VMS sufficiently irrelevant that spending any more time K here would be a waste.  If I weren't both outraged at Compaq's behavior andoJ personally fond of some of the products it has savaged I might well decide	 the same.)   - bill   ------------------------------  % Date: Tue, 27 Nov 2001 15:41:09 -0600o+ From: Christopher Smith <csmith@amdocs.com> B Subject: RE: Solaris: ready for prime time?  Keep your VMS system.L Message-ID: <3B55D7F383B0D31197D9009027541CBF1170DEE2@cmiexch1.cmi.itds.com>   > -----Original Message-----1 > From: Bill Todd [mailto:billtodd@metrocast.net]h  B > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message/ > news:%vTM7.2013$RL6.61788@news.cpqcorp.net... 8 > > Where is Andrew?  Come on?  We need the expert here.  3 > > Seriously, I'm getting quite worried about his i > dissapearance.  Does anyone < > > actually know him?  I'd love to chuckle about his being  > right sized, but > am2 > > concerned that he may have done a Carl Lydick.  @ > It's entirely possible that he's merely decided that Compaq's  > actions have@ > succeeded in making VMS sufficiently irrelevant that spending  > any more timeK8 > here would be a waste.  If I weren't both outraged at  > Compaq's behavior and ; > personally fond of some of the products it has savaged I   > might well decidea > the same.y  L Or he might have gone on vacation(honeymoon, etc, etc).  Given the amount ofE civility he's seen from some of our regulars, I can understand why he * wouldn't have bothered to post a warning.    Regards,   Chrisc  ! Christopher Smith, Perl Developer- Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");f 'I  i   ------------------------------   Date: 27 Nov 2001 22:51:21 GMT) From: leslie@clio.rice.edu (Jerry Leslie)CB Subject: Re: Solaris: ready for prime time?  Keep your VMS system.' Message-ID: <9u15d9$7f0$1@joe.rice.edu>l  4 Fred Kleinsorge (kleinsorge@star.zko.dec.com) wrote:6 : Where is Andrew?  Come on?  We need the expert here.  D Email to andrew@uk.sun.com bounces with a "550, user unknown" error.   --Jerry Leslie   ------------------------------  % Date: Tue, 27 Nov 2001 17:01:57 -0600s+ From: Christopher Smith <csmith@amdocs.com> B Subject: RE: Solaris: ready for prime time?  Keep your VMS system.L Message-ID: <3B55D7F383B0D31197D9009027541CBF1170DEE3@cmiexch1.cmi.itds.com>  # But have you tried andrew.harrison?    Chris6  ! Christopher Smith, Perl Developer- Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");I 'i      > -----Original Message-----: > From: leslie@clio.rice.edu [mailto:leslie@clio.rice.edu]* > Sent: Tuesday, November 27, 2001 4:51 PM > To: Info-VAX@Mvb.Saic.ComSC > Subject: Re: Solaris: ready for prime time? Keep your VMS system.  >  > 6 > Fred Kleinsorge (kleinsorge@star.zko.dec.com) wrote:8 > : Where is Andrew?  Come on?  We need the expert here. > F > Email to andrew@uk.sun.com bounces with a "550, user unknown" error. >  > --Jerry Leslie >    ------------------------------  # Date: Wed, 28 Nov 2001 04:06:29 GMT 3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk>rB Subject: Re: Solaris: ready for prime time?  Keep your VMS system./ Message-ID: <3C0460A2.D6C32573@cableinet.co.uk>-   Fred Kleinsorge wrote: > 6 > Where is Andrew?  Come on?  We need the expert here. > L > Seriously, I'm getting quite worried about his dissapearance.  Does anyoneM > actually know him?  I'd love to chuckle about his being right sized, but amo0 > concerned that he may have done a Carl Lydick.   G a lot of contractors were shed in the UK at then end of sept by various @ large orgs. This does coincide roughly with his "disappearance". However,G it is pure speculation, I have no hard facts. Did he ever post in othert groups?e  D He could be too busy rebuilding systems that used to be in the WTC I guess. n  F Or using all the knowledge he gets here to knock Suns cluster s/w into shape.  D Or just decided he doesn't need to bother working on ways to compete with> VMS, because Compaq higher management are doing it for him ...     --   Tim.Llewellyn@cableinet.co.uk  )  C Standard disclaimer applies. My views in no way represent those of -! my employers or service provider.3   ------------------------------   Date: 27 Nov 2001 19:59:28 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)6  Subject: Some Multia Help needed, Message-ID: <9u0rb0$1vvl$1@info.cs.uofs.edu>  B After a long wait, the price of parity memory has suddenly droppedA and it looks like I will get to try running the Multia I got from' island some time ago.o  9 But, I have some hardware questions if nobody here minds.o  F The PCI riser in my box has no connectors on it.  It looks like it hadE a 50 pin cable, which likely went to the internal hard disk, but that E was apparently pulled off at some point. There appear to be locationseA on the riser for a mini-scsi connector and even for a PCI socket.u  B Now the questions.  can I assume that if I soldered a cable to theB mini-scsi spot on the board and mounted a connector on the back of@ the case it would work??  Can I also assume that if I soldered aB PCI socket on the riser I could use something like an Adaptec scsi, card to give me external SCSI capabilities??  @ One last question.  I read somewhere that the SRM can be updatedA using MOP.  Can I also assume this machine can be booted from the13 network if I have a suitable MOP server available??   ? Thanks for any help.  I look forward to seeing what this littlei box can actually do.   bill   -- WJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Tue, 27 Nov 2001 16:37:06 -0500O* From: WILLIAM WEBB <WWEBB1@email.usps.gov>$ Subject: RE: Some Multia Help needed- Message-ID: <0033000042872956000002L062*@MHS>o  ( =0A sold mine to Pete Sneddon's son Tim-% (and it survived the US =3D> AU trip)f  0 To save you time, Multias only like 60ns memory.( They'll start booting with 70, but hang.  5 You've gotta have a floppy for the foreign boot, too.0  2 (Check used computer shops that do a lot of laptop2  work- that's what else those little floppy drives:  were used for- I got mine used for $15 instead of $70...)  . I recall using an adapter to put a SCSI-2 port/ on the back of the box, but don't remember what  the other end hooked up to.-  1 It may have been a short cable that terminated ina a 50-pin Berg.  3 Here are some of the Multia links from my archives:e  4 This one contains a link to a manual in .PDF format-0 http://www.brouhaha.com/~eric/computers/udb.html   This one has good instructions.r. http://www.djesys.com/vms/hobbyist/multia.html  $ This one has parts, although pricey.@ http://www.starshipcorp.com/starshipcomputers/multia/multia.html  7 I also highly recommend doing the fan upgrade mentionedw2 in the following link to reduce the possibility of2 "thermal seppuku" to which Multias are vulnerable.  8 McMaster-Carr still carries the fan in question and they
 ship quickly.y  0 http://www.netbsd.org/Ports/alpha/multiafaq.html  7 Getting these puppies to run is fun, but do not confuse 8 fun with simple.  A fair amount of kludgery is required.  
 Good luck.   WWWebb     -----Original Message-----/ From: Info-VAX-Request@Mvb.Saic.Com at INTERNET ( Sent: Tuesday, November 27, 2001 3:28 PMB To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET  Subject: Some Multia Help needed    B After a long wait, the price of parity memory has suddenly droppedA and it looks like I will get to try running the Multia I got froml island some time ago.S  9 But, I have some hardware questions if nobody here minds.-  F The PCI riser in my box has no connectors on it.  It looks like it hadE a 50 pin cable, which likely went to the internal hard disk, but that-E was apparently pulled off at some point. There appear to be locationslA on the riser for a mini-scsi connector and even for a PCI socket.e  B Now the questions.  can I assume that if I soldered a cable to theB mini-scsi spot on the board and mounted a connector on the back of@ the case it would work??  Can I also assume that if I soldered aB PCI socket on the riser I could use something like an Adaptec scsi, card to give me external SCSI capabilities??  @ One last question.  I read somewhere that the SRM can be updatedA using MOP.  Can I also assume this machine can be booted from the 3 network if I have a suitable MOP server available??   ? Thanks for any help.  I look forward to seeing what this littleI box can actually do.   bill   --H Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wol= ves D bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |? Scranton, Pennsylvania   |         #include <std.disclaimer.h>=N   ------------------------------  # Date: Wed, 28 Nov 2001 00:41:35 GMTs1 From: Ed Wensell III <ewensell3@yahoo.commercial>h$ Subject: Re: Some Multia Help needed0 Message-ID: <3C0432A6.CD6C7CA3@yahoo.commercial>    See my responses intermingled...   Bill Gunshannon wrote: > D > After a long wait, the price of parity memory has suddenly droppedC > and it looks like I will get to try running the Multia I got frome > island some time ago.n  A Funny that, eh? I just bought four 32MB SIMMs for $13/each for mykD AlphaStation 255/233... Worked without question. An AS255 with 192MB* runs much better than an AS255 with 64MB.   H Now to find a decent Seagate ST3[4|9]xxxxN drive at a decent price. eBay: and Yahoo! auctions have had some interesting ones lately.  D > Now the questions.  can I assume that if I soldered a cable to theD > mini-scsi spot on the board and mounted a connector on the back ofB > the case it would work??  Can I also assume that if I soldered aD > PCI socket on the riser I could use something like an Adaptec scsi. > card to give me external SCSI capabilities??  G Truly odd. IIRC, the Multia came with either a SCSI riser OR a PCI slotCH riser.  There might have been a later combined riser, but I haven't seen1 one. To have a 'blank' riser with neither is odd.I  H Best guess, I'd say no... However, it might be worth a try. The riser is2 doing you little good at this point anyway, right?  sB > One last question.  I read somewhere that the SRM can be updatedC > using MOP.  Can I also assume this machine can be booted from the 5 > network if I have a suitable MOP server available??   @ If you do a search on Dejanews, you'll see I was asking the same question in 1999... :)  D The answer is yes, but don't ask me how. Long long ago I was able toD update the SRM on a Multia via MOP followed by installing RedHat viaG MOP/TFTP. Used a NetBSD/i386 system as the boot host. However, I didn'ta@ take notes on how I did it. What follows is mostly babbling, but# hopefully there is something there:R  C One part I do remember was fiddling with the 'qsbypass.scr' script.$" Changing all instances of 'fat' to9 [mop|tftp|ewa?|something-else-which-I-cannot-rememeber]. o  G Hmmmmmmm.... I think it went something like this. You'll need to switchi' the machine to SRM mode if not already:.  C 0. Check the current firmware. 3.8 is the latest (last) version. Ifb- you're already there, then this is pointless.w  D 1. Get the Multia firmware update and create the floppies 'normally'B (ftp://ftp.digital.com/pub/Digital/Alpha/firmware/archive/multia/)  F 2. Copy the files from the udp-created floppy to the intended MOP/TFTPC boot directory on your boot host. I think the fsl (FailSafe Loader)g image is corrupted.d  7 3. Setup MOP/TFTP to use fwupdate.exe as the boot file.d  @ 4. Modify the 'qsbypass.scr' file as noted... This may take some hacking.  . 5. boot ewa? (whatever the ethernet device is)  
 6. Pray...  , Or did I give up on that and hack this bit??  2 >>> update -path fat:srm.exe/dva0 -target srmflash! -----------------^^^---------^^^^t  F Perhaps some former DEC Multia engineer can help by cleaning this up a bit? :)a  F All else fails, get your hands on an appropriate laptop floppy and theF appropriate cable. I think the floppy+cable from a Dell/Compaq/similar 1U server would work.   A > Thanks for any help.  I look forward to seeing what this little0 > box can actually do. >  > bill >  > --L > Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesF > bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. > University of Scranton   |@ > Scranton, Pennsylvania   |         #include <std.disclaimer.h>   --
 Ed Wensell8 E-mail address munged, but should be easy to figure out.   ------------------------------  % Date: Tue, 27 Nov 2001 18:06:33 -0700o% From: Dan O'Reilly <dano@process.com> $ Subject: Re: Some Multia Help neededB Message-ID: <5.1.0.14.2.20011127180558.070aa200@raptor.psccos.com>  - At 05:41 PM 11/27/2001, Ed Wensell III wrote:d! >See my responses intermingled...t >. >Bill Gunshannon wrote:  > >wF > > After a long wait, the price of parity memory has suddenly droppedE > > and it looks like I will get to try running the Multia I got frome > > island some time ago.  >IB >Funny that, eh? I just bought four 32MB SIMMs for $13/each for myE >AlphaStation 255/233... Worked without question. An AS255 with 192MBm* >runs much better than an AS255 with 64MB.  , Say what????   Where did you get that price?   ------I +-------------------------------+---------------------------------------+(I | Dan O'Reilly                  |                                       |-I | Principal Engineer            |  "Why should I care about posterity?  |GI | Process Software              |   What's posterity ever done for me?" |eI | http://www.process.com        |                    -- Groucho Marx    |eI +-------------------------------+---------------------------------------+m   ------------------------------  # Date: Wed, 28 Nov 2001 01:55:31 GMT 1 From: Ed Wensell III <ewensell3@yahoo.commercial>e$ Subject: Re: Some Multia Help needed0 Message-ID: <3C0443F8.6C187A2E@yahoo.commercial>   Dan O'Reilly wrote:  > / > At 05:41 PM 11/27/2001, Ed Wensell III wrote:  > >lD > >Funny that, eh? I just bought four 32MB SIMMs for $13/each for myG > >AlphaStation 255/233... Worked without question. An AS255 with 192MBu, > >runs much better than an AS255 with 64MB. > . > Say what????   Where did you get that price? >   D Correction... According to my invoice it was $16/ea plus $8 CA-to-TN6 shipping on 10/26/2001 from http://www.memory4less.com   Same part is now $21.45:7 http://www.memory4less.com/itemdetail.asp?itemid=331205    16MB part is going for $13:h7 http://www.memory4less.com/itemdetail.asp?itemid=331202n  E The latter might be what I was thinking. I originally set out to findpC 16MB chips and found the 32MB parts for only $3 (at the time) more.<' Probably should have ordered more... :)<  F Note the links are for 60ns parts. The original DEC spec for the AS255G stated it used 70ns. The original SIMMs that came with my system appeareF to be 60ns. Also, the original SIMMs were 2x33 (??in name only??), theE ones I bought are 2x36. NetBSD has no problems with this, but I don'tt" know how Tru64 or OVMS would fare.  . They appear to have all speeds/sizes in stock:H http://www.memory4less.com -> Memory (left bar) -> Generic Memory (lower	 left bar)    Hope it helps...   --
 Ed Wensell   ------------------------------   Date: 27 Nov 2001 19:05:38 GMT& From: peter@abbnm.com (Peter da Silva)N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org% Message-ID: <9u0o62$ifs@web.nmti.com>e  7 In article <jeBM7.2212$zf.215408@typhoon2.gnilink.net>,a% Jeff Killeen <Jeff@IDM-IO.com> wrote:oC > At the risk of being setup - OK what is the "nine woman" mistake?s  G If one woman can produce one baby in nine months, surely nine women can  do it in one month.t  C Come on, folks, two wrong followups already. I thought this was THEoJ canonical dramatization of Amdahl's Law. I guess something an IBM engineerE came up with in 1967 is ancient history, not of interest to the younge bucks around today.t   -- '+  `-_-'   In hoc signo hack, Peter da Silva.cE   'U`    "A well-rounded geek should be able to geek about anything." L                                                        -- nicolai@esperi.org          Disclaimer: WWFD?   ------------------------------  % Date: Tue, 27 Nov 2001 14:23:24 -0500-  From: John Santos <JOHN@egh.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org/ Message-ID: <1011127141042.16710A@Ives.egh.com>s  $ On Sat, 24 Nov 2001, JF Mezei wrote:   > Terry C Shannon wrote: > > > F > > > WARNING: 'Mixed Cluster' may not mean Vax+Alpha+itanic... It wasD > > > used to mean Alpha+IPF, and when asked, the Q people passed on > > > that one...T > > >$ > > F > > That would seem to be a reasonable assumption from a CPQ financialJ > > standpoint. Perhaps not so reasonable to the ~150K VAX users still out > > there, though. > M > What would be so difficult in allowing VAX to cluster with an IA64 ? If thetP > VMS code on IA64 is to be common with that of Alpha, and alpha supports VMS asO > a fellow cluster member, I don't see why it would be such a big deal to allown& > IA64 to support VAX cluster members.  F We discussed this before.  It's not a big deal.  It just requires lotsI of qualification testing, which they don't want to do.  The semi-official G answer (from Steve Hoffman, IIRC), was that they wouldn't intentionallyeF break anything, and if any problems were discovered, they would try toF fix them, but they weren't going to make any legally binding promises.  C When you think about it, they still have to support VAX-Alpha mixedmC clusters, and if they are also supporting Alpha-IPF mixed clusters,rA either it has to work, or the clustering software needs to behave A differently depending on what other nodes are in the cluster.  ToGB make the clustering software sensitive to the other nodes would be1 a fair amount of work for no conceivable benefit.s  C Imagine this situation:  1) Boot up a cluster consisting of a bunchrB of Alpha nodes.  2) Boot a VAX into the cluster.  Works fine.  NowA imagine a second situation:  1) Boot up a cluster consisting of akD bunch of Alpha nodes.  2) Boot an IPF into the cluster.  Should also> work fine.  So how do all the Alphas at initial boot time know@ which situation will prevail, and start doing all the stuff that won't work with VAXes?  G The only gotcha's I can think of are things like mixed cluster caching, I where they use the lowest common denominator.  They could make VAX'es not H recognize that IPF's should be treated like Alphas, (but why bother?) orE they could remove the Alpha's code that makes it play nice with VAXesiC from the IPF version, but they have said they are aiming for commoncJ sources with Alpha and IPF, and this would be needless conditionalization.  4 I think that there are bigger things to worry about.   -- M John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Tue, 27 Nov 2001 19:24:08 GMT * From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.orgA Message-ID: <sLRM7.76176$8q.10299019@bin2.nnrp.aus1.giganews.com>t  F I'd thank you privately, if your email address weren't fabricated, forJ taking the time to present in detail what I often haven't had the patienceK to.  Given your 20+ years in the DECpaq world, do we know each other?  YourtD prose (and pseudonym) reminds me a bit of one RH I once worked with.   - bill  0 "Dr. Dweeb." <Dweeb@nospam.com> wrote in message) news:6NQM7.98$G53.9276@news.get2net.dk...c   ------------------------------  # Date: Tue, 27 Nov 2001 19:24:47 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org5 Message-ID: <3MRM7.48$h24.14723@typhoon1.gnilink.net>e  5 "Paul Sture" <paul.sture@bluewin.ch> wrote in messageb' news:VA.000004cd.a168314c@bluewin.ch...CG > it only takes one piece of 3rd party software not being ported or nots# quite working as expected after thee1 > port to cause a great deal of customer expense.e   No disagreementu   ------------------------------  # Date: Tue, 27 Nov 2001 19:22:15 GMTl& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org5 Message-ID: <HJRM7.44$h24.14442@typhoon1.gnilink.net>7  H The below is amusing but like Todd full of unproven assumptions taken as fact.:  J For the record I was a dual History and CS major and I run my own businessG that is based on Digital/Compaq technology since 1970.  A business thatoK still that still generates significant revenue from application written foro
 Digital OS's.v  K Yours and Todd's arguments are all based on a fundamental assumption that I I don't agree with it, and apparently like Todd you believe that people whonF disagree with your fundamental assumption are idiots.  The fundamentalL assumption is that the market place values on a chip rather than a solution.J Even Todd at this point will acknowledge that a multi-IA64 processor couldH achieve the same performance level as a multi-Alpha processor system.  IL believe the statement he made was enough low performance processors could beJ made to equal the performance of a high performance processor.  His way ofL phrasing it not mine.  Given that what does the debate come down to assumingG Compaq delivers on its promise that conversion will only be a recompileiF away?  It comes down to economics.  Both Todd and I agree that it willK require more IA64 processors to equal the performance of given set of Alpha J processors.  So what that boils the argument down to is can Compaq deliverD equal, better, or cheaper performance with IA64.  Todd believes theyJ absolutely cannot -  and because of the fundamental assumption above aboutH the chip that the customer base will abandon Compaq in droves.  I on theJ other hand believe that once Compaq makes the conversion to IA64 OVMS willH have a better future in the market because the question of the long termH viability, which has haunted Alpha since day one, will go away.  That inI fact the customer loyality is to OVMS.  Unlike Todd who won't acknowledgeaK the high risks with EV8 I will acknowledge that for the current strategy tog5 succeed it will require Compaq to execute flawlessly.k  I I choose not to debate Todd's opinion's as fact.  That is a fruitless andiI foolish use of one's time.  They are just opinions and his opinion and my.L opinion at this point in time are not fact but unproven supposition.  AnyoneF who ascribes such absolutes as right or wrong to them has questionable
 judgement.  L At age 48 the way I have found to detect to the true idiots in this world isH to find the people who label those who disagree with them as idiots.  ItJ demonstrates the objective and open minded attitude they have to ideas andG perspectives other than their own.  It also means that they tend to seep  their opinions as equaling fact.  K The technical side of this debate is pointless for the most part - what hasnH driven the issues around Alpha in the marketplace haven't been technicalK issues but issues of economics and business.  Digital's strategy always hadCK the flaw of assuming that if they built a chip so superior  the world wouldnB beat a path to its door.  It is based on the false assumption thatI businesses buy technology (e.g. processor architectures) rather than thats businesses buy solutions...W  K Let me wrap-up with this  - assume Compaq delivers on its promise that IA64TL is only a compile away and delivers IA64 based servers running OVMS or Tru64L that is equal to or better than the competition in price performance.  GrantL the assumption for the moment.  Do you think many will care that OVMS is nowG running on IA64 versus Alpha.  If it is only a  recompile away, and theeC price performance is there, what rational business reason would any > unemotional person have for caring it is not running on Alpha?      0 "Dr. Dweeb." <Dweeb@nospam.com> wrote in message) news:6NQM7.98$G53.9276@news.get2net.dk...l > Jeff,t >mH > I predict, after careful reading of this entire thread, that you are aF > liberal arts major (or maybe a business major) and you never studiedL > philosophy or logic (or were on the debating team), while bill is probablyI > an engineer.  Watching you and bill go at it is hilarious, entertaining  andrB > *informative*.  Reading both sides of this bizarre discussion isG > informative, because it gives insight into how many people in general  think.H > Indeed, I believe that the faulty thought processes that are exhibited hereK > (particularly, but not only by you) are in fact precisely those exhibited L > (albeit with more dire results for our careers and our ability to feed ourK > families) by the PHBs at CompaQ, and thus add to an overall understanding  ofK > the diabolical mess that the ComapaQ/VMS/Alphs/HP/Intel soup actually is.hB > The failing is of course in societys obsession with "vocational
 education"G > rather than "education of the mind", leaving the world populated with  highly? > trained morons - but that is a discussion for another thread.m >i > Cutting to the chase,u >aL > I am in agreement with Bill when he says "you are an idiot", though not in asF > general, but a specific sense.  Remember, it is in fact one of Scott AdamsH > guiding premises, that we are all in fact idiots at various times, and thus6 > we have Dilbert.  This is not an ad hominem comment. >nJ > Specifically, in the sense that you are unable to respond intellectually toL > any reasoned response to your arguments.  Specifically, any assertion thatL > the dubious tenets you purport to be truths, and from which you build yourK > reasoning, are in fact not truths (or at least not true in the sense that K > this discussion understands them) results in an emotional response.  Thisi isI > intellectual bankruptcy and deserving of the out of hand dismissal thato BillH > regularly hands out.  That you cannot *see* the connection between hisH > responses and your own postings, says a great deal more about you than Bill.i >sI > Your model of argument assumes that your propositions are valid per se.o; > When these are bought into question you start kicking and B > screaming.  If the result seems intuitively dubious, examine the > propositions.  > J > (Also, your technical knowledge is clearly not surpassed by your command ofG > reasoned logical argument.  Expect to have your position corrected in  areas 3 > where your knowledge is limited.  Learn from it.)m >iH > Also, the previous suggestions (by whom I cannot recall) that personalJ > interest is somehow related to quality of argument or access to truth isK > both fallacious and odious.  While in the legal sphere, personal interestgJ > will dismiss an adjudicator as biased, it certainly does not dismiss oneJ > from being an antagonist (the only form represented here) or confer uponK > either antagonist a monopoly of truthor vice versa.  There is no logical I > difference between Bills ex-DEC credential and non-current user status,  andtG > Jeffs non-ex-DEC credential and current user status - they are simple|J > attributes of the antagonists, fundamental (but not all encompassing) to thesG > purpose at hand - discussion/argument of opposing analyses of currentt eventsJ > and facts.  While they may form a point of departure, they do not in anyI > logical sense say anything about argument quality or ability to discerne thetK > truth from available sources.  The use of such a response is intellectuala
 > bankruptcy.v >u> > Such ad hominem commentary should be eschewed in this forum. >n > K > As for me, I have a personal interest that VMS continue forever, it is mygL > career.  I have no interest in whether CompaQ lives or dies, whether AlphaI > is dead (and possibly buried) and I have previously worked for DEC.  Toa the.H > extent that my interest (VMS life span)may be determined by the things withF > which I have no interest per se (CompaQ lifespan etc), then I have a > specific interest. >- >-L > And to the issue at hand.  It is really about integrity.  Those of us withL > 20+ years in the DECpaQ world, remember a different corporate culture.  ItG > died when GQ Palmer took over.  I have been waiting for things to getaK > better, but tragically this has not happened.  Basically, CompaQ, throughkK > the actions and words of its responsible executives, has demonstrated the F > integrity of a gutter rat and has displayed a level of duplicity and deceitJ > (tautological I know, but ...) to which I wish I had not been a witness.H > Nothing less than the heads of the BoD, Capellas and his "windoze will ruleL > the world" fixated lackeys is called for.  Were I a shareholder I would beJ > demanding nothing less than economic restitution for the losses directlyF > caused by the gross incompetence of the individuals charged with the< > fiduciary duty of managing and safeguarding my investment. >0E > The sophistry with which the CompaQ spiel has been spun has clearly E > convinced/duped (your choice) a great number of people.  However, I  predict I > that when all the information on this tawdry affair becomes public, andoH > historians analyse the irrefutable facts, we will see Capellas and his oposH > for what they are - tawdry little nobodies with egos larger than theirI > intellectual and professional capabilities could bare demonstrating how  easyE > it is to make a monumental fuck-up without really trying if you cant convince< > equally mindless power mongers to let you have a go at it. >-K > Nearly all the discussion in this thread really boils down to whether the J > poster is convinced/duped or apalled/unconvinced by the CompaQ spin.  It is3 > vastly entertaining and interesting one the less.  >t6 > I return you now to regular programming in progress. >m >  >    ------------------------------  % Date: Tue, 27 Nov 2001 14:45:27 -0500-- From: JF Mezei <jfmezei.spamnot@videotron.ca>-N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org, Message-ID: <3C03ED52.BBA0DC3A@videotron.ca>   Rob Young wrote:G >         Maybe being 5 GHz behind in 3 years may have been part of thee+ >         reasons behind ditching of Alpha.d  G Since Compaq can have the Alpha fab wherever it wants, then if Intel issH capable of producing 5ghz chips, Comapq should be able to have its AlphsI fabbed with the same technology by Intel. If by that time, IBM is able toaM generate 6ghz chips, the Compaq could go and have its Alpha fabbed by IBM etc  etc etc.  M Consider that while Intel has been able to boost the clock speed of its 8086,cM the others have been able to follow. Obviously, if Compaq chooses to continuedG to have Alpha fabbed with older technology and slower speeds instead ofdN generating a subversion that makes use of higher clock speeds, then Alpha will lag during that time period. a  L Compaq paid for the DESIGN of Alpha. It then paid whomever to fab the chip.   K Furthermore, is it cirrect to state that IBM is generally ahead of Intel infI terms of fabbing technology while Intel focuses more on being able to fabt3 greater quantities with slightly older technology ?    ------------------------------  % Date: Tue, 27 Nov 2001 14:46:15 -0500s5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>fN Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org3 Message-ID: <o5SM7.2009$RL6.61702@news.cpqcorp.net>t  K It isn't worth arguing with Bill.  If you suggest SMT wasn't solving single H stream performance in EV8, he'll tell you that single stream performance' isn't interesting, but multi-stream is.S  H The truth is that there is a small segment of users that will pay nearlyI anything for the fastest raw performance.  Often their workload cannot be<I helped by multiple processors/threads.  For them, IA64 in the short term,nF will not be able to compete with Alpha.  There are also users where MPJ performance tops out at a specific CPU count, and the only thing that willL help them isn't more CPUs, but faster CPUs... again, short term, IA64 is notE a substitute for Alpha.  For them - EV7&EV79/Marvel will get them the  performance and scaling.  H But a great deal of people will be very happy with IA64 performance.  ItF will get significantly better over time.  And yes, throwing additionalL IA64's at the problem will equal the performance they "might" have gotten on Alpha.      L Jeff Killeen wrote in message <4tdM7.1687$zf.155977@typhoon2.gnilink.net>... > 6 >"Bill Todd" <billtodd@metrocast.net> wrote in message< >news:AbdM7.94305$qx2.5969798@bin5.nnrp.aus1.giganews.com...F >> Without attempting to imbue you with the technical education you so sorely@ >> lack, I'll simply point out the fallacy of suggesting that 2N= >> half-performance processors can equal the performance of Nt >full-performance L >> processors on any work-load that does not partition into some multiple of >2N - >> roughly equal and nearly-independent taskss >t5 >Don't put words in mouth - I have never said that...o >a >a >    ------------------------------  % Date: Tue, 27 Nov 2001 20:49:03 +0100o( From: Paul Sture <paul.sture@bluewin.ch>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org- Message-ID: <VA.000004ce.a1aabada@bluewin.ch>,  D In article <3C02EC7A.82C37BC8@cableinet.co.uk>, Tim Llewellyn wrote: > Jeff Killeen wrote:  >  dP > > Here is a simple test if you want to expand OVMS's market.  Write an ad thatN > > would appeal the CEO of the company who knows little about computers.  AdsO > > that appeal to fear only tend to work if the person first has that fear andyL > > second believes that the fear can be mitigated.  Just saying your systemL > > will crash less won't appeal to someone who believes the systems stay upL > > enough now or that every computer is going to crash.  Ads that appeal toJ > > gaining advantage are most effective e.g. putting your business on theN > > Internet will double your income.  A good example of the gaining advantageM > > type ad is the IBM ad where buyers are in a mom and pop shop and the shoprL > > owners check their handheld and point out they "have 10,000 units in the > > warehouse in New Jersey".  > >  > J > Have you seen IBM's "Cheddar Cheese" ad or are they only showing that inK > the UK? How about the web designers are snowboarding one? Surely that ones > went out in the US?t >  uI Just seen it on CNN. IMHO it gave a very clear message, about _services_.m ___w
 Paul Sture Switzerlande   ------------------------------  % Date: Tue, 27 Nov 2001 20:58:22 +0100y% From: "Dr. Dweeb." <Dweeb@nospam.com>eN Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org1 Message-ID: <kfSM7.128$G53.10721@news.get2net.dk>e  I Indeed, the making of the 360, The Mythical Man-Month, should be REQUIREDe< reading for all would be project managers in EVERY industry.   p.   Should be required reading3 "Peter da Silva" <peter@abbnm.com> wrote in messageb news:9u0o62$ifs@web.nmti.com... 9 > In article <jeBM7.2212$zf.215408@typhoon2.gnilink.net>,M' > Jeff Killeen <Jeff@IDM-IO.com> wrote:nE > > At the risk of being setup - OK what is the "nine woman" mistake?, > I > If one woman can produce one baby in nine months, surely nine women can: > do it in one month.  >uE > Come on, folks, two wrong followups already. I thought this was THE.L > canonical dramatization of Amdahl's Law. I guess something an IBM engineerG > came up with in 1967 is ancient history, not of interest to the youngw > bucks around today.  >  > --- >  `-_-'   In hoc signo hack, Peter da Silva.lG >   'U`    "A well-rounded geek should be able to geek about anything."o; >                                                        --@ nicolai@esperi.org >          Disclaimer: WWFD?   ------------------------------  # Date: Tue, 27 Nov 2001 20:03:10 GMT * From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.orgA Message-ID: <2kSM7.76249$8q.10317432@bin2.nnrp.aus1.giganews.com>k  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messagei/ news:HJRM7.44$h24.14442@typhoon1.gnilink.net....   ...t  K > Yours and Todd's arguments are all based on a fundamental assumption thatk I K > don't agree with it, and apparently like Todd you believe that people who 7 > disagree with your fundamental assumption are idiots.e  J Not at all:  I (and from appearances the Good Dr. Dweeb) just believe thatD people who can't respond on-point or understand the material they'reD responding to (your choice), after repeated corrections, are idiots.     The fundamentalkD > assumption is that the market place values on a chip rather than a	 solution.a  G Wrong.  One of several fundamental assumptions is that the power of theC> processor has significant effects upon the ability to create a cost-effective solution.  L > Even Todd at this point will acknowledge that a multi-IA64 processor couldG > achieve the same performance level as a multi-Alpha processor system.a  D As 'could' a multi-IA32-processor, or even a multi-PDP-11-processor,L configuration - for *some* but definitely not *all* uses.  You've ignored myB very explicit clarification of this, with is either incompetent or
 dishonest.     IoK > believe the statement he made was enough low performance processors coulda beL > made to equal the performance of a high performance processor.  His way ofE > phrasing it not mine.  Given that what does the debate come down tog assumingI > Compaq delivers on its promise that conversion will only be a recompile  > away?m  J That's your problem:  'given that' does not apply, because we won't 'give'E you that at all.  Go back and reread the existing responses you're soeC diligently ignoring before wasting our time any more on this point.    ...n  H > Let me wrap-up with this  - assume Compaq delivers on its promise that IA64H > is only a compile away and delivers IA64 based servers running OVMS or Tru64bG > that is equal to or better than the competition in price performance.  GrantpJ > the assumption for the moment.  Do you think many will care that OVMS is noweI > running on IA64 versus Alpha.  If it is only a  recompile away, and theuE > price performance is there, what rational business reason would anyi@ > unemotional person have for caring it is not running on Alpha?  B 1.  They will care because *verifying* that the recompile of theirJ applications (and any recompiled components they obtained from others) was( all it took takes non-negligible effort.  J 2.  They will care because Compaq will have spent 3 years preoccupied withH the porting effort rather than adding *real* value to VMS (and ISVs will- have been diverted by such activity as well).   H 3.  They will care because the risk that the transition will *not* be asJ smooth as you posit and/or that Itanic will continue to suck so badly that? cost-effective platforms simply cannot be based on it will havenI significantly reduced VMS's market (and ISV base) over the 3 years beforerL such risks have been proved not to exist (*if* we accept your assumptions toI this effect) and therefore VMS will have a significantly smaller customeroI base to fund its future development (if there is such) or even existence.t  I And, of course, for some non-zero number of installations, recompiling isaK not an option in any event - and even if running via a binary translator is D effective that too will require verification effort.  And some otherD non-zero number of installations will have to choose between runningG unsupported cluster mixes that include VAXen and reconfiguring to avoidhL them.  And I'm sure there are some other minorities that will be affected inF other ways that don't pop into my mind (but likely can be filled in byJ others here):  for a system with as small a user population as VMS alreadyD has, it doesn't take too many such minorities to add up to something significant.  F Those are the down-sides when we *grant* your assumptions.  The actualL potential down-sides are far worse.  And there's *no* real up-side:  at bestL (and again granting your assumptions rather than using a less biased crystalH ball), by 2005 - 6 people will be able to buy hardware to run VMS that'sJ somewhat less expensive for the same performance than would otherwise haveG been available, but hardware cost is not (at least according to severalaJ surveys that used to be on the Compaq Web site) a dominant concern for VMSK customers anyway (very-low-end applications possibly excepted, but *that's*y a whole 'nother subject).y   - bill   ------------------------------  % Date: Tue, 27 Nov 2001 21:20:25 +0100h1 From: John McLean <mcleanj@swissonline.delete.ch>,N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org5 Message-ID: <3C03F589.F05D039D@swissonline.delete.ch>b   Jeff Killeen wrote:a >  ...n > J > Mass advertising either product at this point would be a unwise businessN > move.  To create brand identity through mass marketing for a sub-brand costsJ > hundreds of millions of dollars.  There is only mass advertising for theF > most part for the corporate brand these days.  IBM doesn't advertiseL > AS/400's or z/390 systems.  The market the primary brand identity with theK > exception of true consumer brands like ThinkPad's.  You don't market OVMSeL > like a $200 Microsoft personal operating system.  People in the OVMS priceG > range buy solutions and market penetration depends upon ISV's (see myt > comments below).  B Firstly I don't believe that Compaq have ever tried any reasonableF amount of advertising of VMS.  You might think diferently if you think5 advertsisements at Polish bus-stops is the way to go.a  H (I can just imagine it.  Two Polish women talking about buying groceriesF and one says to the other "That sign reminds me.  I must buy a new VMS# system while I'm down the street.")h  F If Compaq were truly interested in anything by their PCs then we wouldD see plenty of press releases about the other products.  Fact is thatF more than 90% of CPQ press releases are about windows products and the? other 10 or so % are about deals Compaq does with its finances.o  G Contrast this with IBM, Sun, HP, Microsoft, Dell, Cisco .. (et al).  IfsB they don't produce at least 3 press releases per week then there'sF something wrong.  If they don't mention most of their product lines at least once a week, ditto.i  E These companies know that there is more to marketing than advertising ? and one of these things is to be highly visible.  Compaq's onlyuH visibility is the PC sector and then they complain that no-one sees them as anything but a PC company.c  F If you think I'm wrong, show me 11 press releases his year from CompaqH that mention VMS in any positive light.  Go on.  One a month.  Shouldn't be that difficult...     John McLeany   ------------------------------  % Date: Tue, 27 Nov 2001 15:18:25 -0500i- From: JF Mezei <jfmezei.spamnot@videotron.ca>lN Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org, Message-ID: <3C03F50A.D211E72A@videotron.ca>   Rob Young wrote:G >         aka MVS.  Makes sense.  MVS is in some nice verticals too and C >         VMS has kicked out MVS in a few places.   I wouldn't callo% >         MVS a mainstream OS either.E  J MVS is far more mainstream than VMS. It is the de-facto standard mainframeI operating system that you will find in almost all large corporations, andtJ there is a good reason for this: IBM has managed to retain those customersN which, in the past, didn't have a choice but to go MVS because it was the only" big enough thing to do their work.  J One the the things which Gerstner did was to wake IBM to the lower cost ofM computing and IBM went on a a pricing restructure to make their products moresM competitive against the smaller players such as SUN. Prior to doing that, MVSeJ was on a  downward spiral which did prompt the folks such as DATAMATION to predict it death.e   ------------------------------  % Date: Tue, 27 Nov 2001 21:29:22 +0100,% From: "Dr. Dweeb." <Dweeb@nospam.com> N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org1 Message-ID: <kISM7.137$G53.11422@news.get2net.dk>    below.  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messaget/ news:HJRM7.44$h24.14442@typhoon1.gnilink.net... J > The below is amusing but like Todd full of unproven assumptions taken as > fact.n >e  B Please point to them for me.  I would like a demonstration of yourH deconstrunction skills, so that I might benefit from them are refine the' quality of my thought and written work.s  L > For the record I was a dual History and CS major and I run my own businessI > that is based on Digital/Compaq technology since 1970.  A business thateI > still that still generates significant revenue from application writtenh ford > Digital OS's.s >   K This is an interesting statement for what it does not say.  It is brilliant  !!  K The casual reader (read idiot) will fallaciously assume from this statementaF (a function of spontaneous idiocy) that you have been working with DECJ technology since 1970.  You may have started this company as a 17 year oldH (great work if you did btw).  It does not really matter, because it is aK perfect example of how to communicate misinformation, by exploiting a humany7 predilection for not actually reading what is writtenn.c  B And absolute pearl.  Hats off.  You should work at the CompaQ spin department.i  K > Yours and Todd's arguments are all based on a fundamental assumption thato IhK > don't agree with it, and apparently like Todd you believe that people whouH > disagree with your fundamental assumption are idiots.  The fundamentalD > assumption is that the market place values on a chip rather than a	 solution.qL > Even Todd at this point will acknowledge that a multi-IA64 processor couldJ > achieve the same performance level as a multi-Alpha processor system.  IK > believe the statement he made was enough low performance processors couldt beL > made to equal the performance of a high performance processor.  His way ofE > phrasing it not mine.  Given that what does the debate come down toe assumingI > Compaq delivers on its promise that conversion will only be a recompileuH > away?  It comes down to economics.  Both Todd and I agree that it willG > require more IA64 processors to equal the performance of given set of  AlphaaL > processors.  So what that boils the argument down to is can Compaq deliverF > equal, better, or cheaper performance with IA64.  Todd believes theyL > absolutely cannot -  and because of the fundamental assumption above aboutJ > the chip that the customer base will abandon Compaq in droves.  I on theL > other hand believe that once Compaq makes the conversion to IA64 OVMS willJ > have a better future in the market because the question of the long termJ > viability, which has haunted Alpha since day one, will go away.  That inK > fact the customer loyality is to OVMS.  Unlike Todd who won't acknowledge J > the high risks with EV8 I will acknowledge that for the current strategy to7 > succeed it will require Compaq to execute flawlessly.g >a  J I forgot to mention you unique ability to completely miss the point, whichF you have, at least in respect to my post, done here.  I do not have anK opinion of the relative strengths or weaknesses of the arguments - at leastoL none that you or anyone else on this list is aware. I have made no assertionE in my post on this matter at all.  Please point me at it in case I am0 overlooking something.  L I do have an opinion on the level of integrity of CompaQ executives - it wasI articulated rather succintly (and unsupported as pure opinion) I thought,sH and it was absent for ruminations on strategic defensibility or logic ofK CompaQs executives actions and statements.  The closest I get to a positiontG is the convinced/duped comment, which might be construed to exclude thes# probability that the spin is truth.r  K > I choose not to debate Todd's opinion's as fact.  That is a fruitless andwK > foolish use of one's time.  They are just opinions and his opinion and my F > opinion at this point in time are not fact but unproven supposition. AnyoneH > who ascribes such absolutes as right or wrong to them has questionable > judgement. >tK > At age 48 the way I have found to detect to the true idiots in this worlds isJ > to find the people who label those who disagree with them as idiots.  ItL > demonstrates the objective and open minded attitude they have to ideas andI > perspectives other than their own.  It also means that they tend to seei" > their opinions as equaling fact. >t  E The escape of the intellectually bankrupt is the resort to ad hominemoK argument.  While I think that neither of you are wealthy in this respect, I"J think Bill still has a few more chips, but I am not really counting.  ThisD is an unfounded assertion on my part. I could define it and find theI information necessary to support it (it exists), but I am just too damnedf lazy.o  E I am quite happy to define people as "idiots" if the quality of theirmK thought as communicated by the written and spoken word is of a sufficientlypC incoherent nature, so long as I am able to clearly demonstrate thateI incoherense.  This is Bills unstated but clearly obvious position by the  way.  I > The technical side of this debate is pointless for the most part - what0 hasrJ > driven the issues around Alpha in the marketplace haven't been technicalI > issues but issues of economics and business.  Digital's strategy alwaysd hadeG > the flaw of assuming that if they built a chip so superior  the world  would D > beat a path to its door.  It is based on the false assumption thatK > businesses buy technology (e.g. processor architectures) rather than thatp > businesses buy solutions...u >s  " Have I commented on this at all ??  H > Let me wrap-up with this  - assume Compaq delivers on its promise that IA64H > is only a compile away and delivers IA64 based servers running OVMS or Tru64tG > that is equal to or better than the competition in price performance.c Grant J > the assumption for the moment.  Do you think many will care that OVMS is noweI > running on IA64 versus Alpha.  If it is only a  recompile away, and thegE > price performance is there, what rational business reason would anyu@ > unemotional person have for caring it is not running on Alpha? >h  K Now for an opinion.  I think this will be proven to be correct.  In fact, Ie really hope it will be correct.B  ! However, I will add the modifier.n  L I think it will only happen for the class of customer for which  there is noK choice, and that has not already executed an exit strategy from VMS.  It isgH likely that the group of customers who depart from VMS and perceive thatL departure as having been imposed on them by CompaQ will choose ABC (AnythingJ But CompaQ) as a replacement.  Remember, a large part of the customer baseI has been smelling the coffee that GQ Bob and Mikey have brewed for a long7I time.  Sometimes it is not an event that finally forces the hand, but thet  weight of many that is to blame. >l >o2 > "Dr. Dweeb." <Dweeb@nospam.com> wrote in message+ > news:6NQM7.98$G53.9276@news.get2net.dk...<	 > > Jeff,. > >wJ > > I predict, after careful reading of this entire thread, that you are aH > > liberal arts major (or maybe a business major) and you never studiedE > > philosophy or logic (or were on the debating team), while bill ise probablyK > > an engineer.  Watching you and bill go at it is hilarious, entertainingo > andoD > > *informative*.  Reading both sides of this bizarre discussion isI > > informative, because it gives insight into how many people in generali > think.J > > Indeed, I believe that the faulty thought processes that are exhibited > hereC > > (particularly, but not only by you) are in fact precisely those 	 exhibited J > > (albeit with more dire results for our careers and our ability to feed our ? > > families) by the PHBs at CompaQ, and thus add to an overalle
 understanding  > ofI > > the diabolical mess that the ComapaQ/VMS/Alphs/HP/Intel soup actually2 is.1D > > The failing is of course in societys obsession with "vocational > education"I > > rather than "education of the mind", leaving the world populated with. > highlyA > > trained morons - but that is a discussion for another thread.o > >  > > Cutting to the chase,. > >@K > > I am in agreement with Bill when he says "you are an idiot", though notd in > adH > > general, but a specific sense.  Remember, it is in fact one of Scott > AdamsJ > > guiding premises, that we are all in fact idiots at various times, and > thus8 > > we have Dilbert.  This is not an ad hominem comment. > >eL > > Specifically, in the sense that you are unable to respond intellectually > toI > > any reasoned response to your arguments.  Specifically, any assertion  thatI > > the dubious tenets you purport to be truths, and from which you builda yourH > > reasoning, are in fact not truths (or at least not true in the sense thatG > > this discussion understands them) results in an emotional response.e This > isK > > intellectual bankruptcy and deserving of the out of hand dismissal thats > BillJ > > regularly hands out.  That you cannot *see* the connection between hisJ > > responses and your own postings, says a great deal more about you than > Bill.  > > K > > Your model of argument assumes that your propositions are valid per se.f= > > When these are bought into question you start kicking and D > > screaming.  If the result seems intuitively dubious, examine the > > propositions.a > > L > > (Also, your technical knowledge is clearly not surpassed by your command > ofI > > reasoned logical argument.  Expect to have your position corrected ind > areasn5 > > where your knowledge is limited.  Learn from it.)  > >yJ > > Also, the previous suggestions (by whom I cannot recall) that personalL > > interest is somehow related to quality of argument or access to truth isD > > both fallacious and odious.  While in the legal sphere, personal interestL > > will dismiss an adjudicator as biased, it certainly does not dismiss oneL > > from being an antagonist (the only form represented here) or confer uponE > > either antagonist a monopoly of truthor vice versa.  There is nom logicalrK > > difference between Bills ex-DEC credential and non-current user status,  > andeI > > Jeffs non-ex-DEC credential and current user status - they are simpleuL > > attributes of the antagonists, fundamental (but not all encompassing) to > theaI > > purpose at hand - discussion/argument of opposing analyses of currentb > eventsL > > and facts.  While they may form a point of departure, they do not in anyK > > logical sense say anything about argument quality or ability to discern  > theh@ > > truth from available sources.  The use of such a response is intellectual > > bankruptcy.h > >d@ > > Such ad hominem commentary should be eschewed in this forum. > >v > >sJ > > As for me, I have a personal interest that VMS continue forever, it is myH > > career.  I have no interest in whether CompaQ lives or dies, whether Alpha K > > is dead (and possibly buried) and I have previously worked for DEC.  Tol > theeJ > > extent that my interest (VMS life span)may be determined by the things > withH > > which I have no interest per se (CompaQ lifespan etc), then I have a > > specific interest. > >t > >aI > > And to the issue at hand.  It is really about integrity.  Those of usv withJ > > 20+ years in the DECpaQ world, remember a different corporate culture. ItI > > died when GQ Palmer took over.  I have been waiting for things to getlE > > better, but tragically this has not happened.  Basically, CompaQ,e throughoI > > the actions and words of its responsible executives, has demonstratedr thelH > > integrity of a gutter rat and has displayed a level of duplicity and > deceitL > > (tautological I know, but ...) to which I wish I had not been a witness.J > > Nothing less than the heads of the BoD, Capellas and his "windoze will > ruleK > > the world" fixated lackeys is called for.  Were I a shareholder I wouldn beL > > demanding nothing less than economic restitution for the losses directlyH > > caused by the gross incompetence of the individuals charged with the> > > fiduciary duty of managing and safeguarding my investment. > >sG > > The sophistry with which the CompaQ spiel has been spun has clearlylG > > convinced/duped (your choice) a great number of people.  However, I 	 > predicteK > > that when all the information on this tawdry affair becomes public, andnJ > > historians analyse the irrefutable facts, we will see Capellas and his > oposJ > > for what they are - tawdry little nobodies with egos larger than theirK > > intellectual and professional capabilities could bare demonstrating how- > easyG > > it is to make a monumental fuck-up without really trying if you cana
 > convince> > > equally mindless power mongers to let you have a go at it. > >nI > > Nearly all the discussion in this thread really boils down to whethere thetL > > poster is convinced/duped or apalled/unconvinced by the CompaQ spin.  It > is5 > > vastly entertaining and interesting one the less.e > >d8 > > I return you now to regular programming in progress. > >e > >  > >o >o >o   ------------------------------  % Date: Tue, 27 Nov 2001 21:33:14 +0100t% From: "Dr. Dweeb." <Dweeb@nospam.com>iN Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org1 Message-ID: <XLSM7.138$G53.11501@news.get2net.dk>'   Bill,o  ; I do not believe we are acquainted.  The world is very big.s   I have responeded to Jeff.  H I apologise for the pseudonym.  I thought it better to be nameless while# inserting myself into the "debate".    p.  5 "Bill Todd" <billtodd@metrocast.net> wrote in messaged; news:sLRM7.76176$8q.10299019@bin2.nnrp.aus1.giganews.com...dH > I'd thank you privately, if your email address weren't fabricated, forL > taking the time to present in detail what I often haven't had the patienceG > to.  Given your 20+ years in the DECpaq world, do we know each other?h YourF > prose (and pseudonym) reminds me a bit of one RH I once worked with. >w > - bill >n2 > "Dr. Dweeb." <Dweeb@nospam.com> wrote in message+ > news:6NQM7.98$G53.9276@news.get2net.dk...  >  >u >i   ------------------------------  # Date: Tue, 27 Nov 2001 20:38:02 GMT * From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.orgA Message-ID: <KQSM7.133299$2w.8604194@bin4.nnrp.aus1.giganews.com>   @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message- news:o5SM7.2009$RL6.61702@news.cpqcorp.net...r# > It isn't worth arguing with Bill.t  
 Au contraire.   F It's worth it when I'm wrong, because I'll cheerfully (or occasionallyH sheepishly) admit it as soon as you've succeeded in explaining why.  And@ it's worth it when I'm right as long as you're willing to learn.  K The only times it's not worth it are when you're both wrong and ineducable.t  *   If you suggest SMT wasn't solving singleJ > stream performance in EV8, he'll tell you that single stream performance) > isn't interesting, but multi-stream is.c  C While single-stream performance isn't exactly something that can begL 'solved', it can certainly be 'improved' - and EV8's extension from 4-way toB 8-way issue did exactly that (I think there were a couple of otherD applicable tweaks as well).  The fact that its performance impact inH multi-threaded environments was more dramatic doesn't detract from that.  A (There's also some interesting research going on into decomposinglA single-threaded code into multiple independent - or speculative -nI micro-threads that can be scheduled concurrently on an SMT platform.  ButiD I'm not sufficiently familiar with it to suggest that EV8 could have< achieved even better single-thread performance in this way.)   > J > The truth is that there is a small segment of users that will pay nearlyK > anything for the fastest raw performance.  Often their workload cannot be K > helped by multiple processors/threads.  For them, IA64 in the short term,r) > will not be able to compete with Alpha.c  J There's every indication that IA64 would *never* (at least as far into theH future as one can see from here) have been able to compete with Alpha inK such situations, save perhaps for FP-style regular code.  So adding 'in the1) short term' above is typical Compaq spin.      There are also users where MPoL > performance tops out at a specific CPU count, and the only thing that will/ > help them isn't more CPUs, but faster CPUs...i  L Perhaps you'll pay more attention to Fred's formulation of this concept thanF you've been willing to pay to mine:  his is a bit more restricted, but otherwise the same.u    again, short term, IA64 is notk > a substitute for Alpha.s  I And again, there's no reason to believe it would have become an effectiveg# substitute in the long-term either.   .   For them - EV7&EV79/Marvel will get them the > performance and scaling.  J *If* they're willing to run on a dead-end architecture that won't continueK to ride the industry performance curve.  Some existing Alpha users may welloK do that and plan to jump to POWER4 when EV7x runs out of steam.  New users,iH however, will opt for POWER4 up front to avoid the need to migrate there later.   >dJ > But a great deal of people will be very happy with IA64 performance.  It* > will get significantly better over time.  D If it didn't, the product would vanish without a trace.  If it does,J performance might actually rise to the level of mediocrity (as long as youK don't mind the power dissipation) - and indeed some people will probably besK 'very happy' with that (just as they are with Windows, not knowing anything  better).     And yes, throwing additionalK > IA64's at the problem will equal the performance they "might" have gottenT on > Alpha.  K As long as they're not interested in any of the activities you noted above.n  E Even given that, there's still the question of whether you can sell arH 2N-processor Itanic system for noticeably less than an N-processor AlphaE system.  The answer for N = 1 is likely 'yes'.  For N = 2 I'd be moreoJ inclined to say 'maybe', and the more N rises the more skeptical I become.  I And that's just the *hardware* pricing.  Unless Compaq starts giving awayeF large-N VMS licenses, when you add that to the hardware price whatever= difference existed just became considerably less significant.c   - bill   ------------------------------  % Date: Tue, 27 Nov 2001 21:53:29 +0100e( From: Paul Sture <paul.sture@bluewin.ch>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org- Message-ID: <VA.000004cf.a1e5b914@bluewin.ch>d  I In article <HJRM7.44$h24.14442@typhoon1.gnilink.net>, Jeff Killeen wrote:i   [snip]. > Do you think many will care that OVMS is nowI > running on IA64 versus Alpha.  If it is only a  recompile away, and theeE > price performance is there, what rational business reason would anyt@ > unemotional person have for caring it is not running on Alpha? >dO "it is only a recompile away" is one heck of an assumption. We've already seen OL comments on this forum that VAX C support is unlikely, and Ada might not be H ported. The latter is already of direct concern to me since I currently O support an application written in it. If I have to switch compilers, something e- tells me it won't be "only a recompile away".i  O But this is still before we get to _testing_. Most of the former testing teams hL have long since moved onto other projects or pastures new. To retrain a new M set of folks in the applications concerned and perform adequate testing is a  
 mammoth task.e  N And we haven't yet got onto the subject of those faced with re-certification  M by official bodies if they change the CPU. It's _very_ expensive. That's one n7 good reason a lot of those folks are still using VAXes.  ___u
 Paul Sture Switzerlandf   ------------------------------   Date: 27 Nov 2001 20:55:42 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org0 Message-ID: <9u0uke$t75$1@pegasus.csx.cam.ac.uk>  , In article <3C03ED52.BBA0DC3A@videotron.ca>,/ JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:  >nL >Furthermore, is it cirrect to state that IBM is generally ahead of Intel inJ >terms of fabbing technology while Intel focuses more on being able to fab4 >greater quantities with slightly older technology ?  D Roughly, yes.  Intel has tended to lead (in recent years) with beingB earlier than IBM into getting process shrinks into production, butA IBM's technology uses more advanced techniques.  Exactly how muchh@ Intel uses the process shrinks to up the quantity and keep price= down, and how much to increase the performance, don't ask me.c     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679    ------------------------------  # Date: Tue, 27 Nov 2001 21:02:23 GMTi* From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.orgA Message-ID: <zbTM7.71173$uB.11593685@bin3.nnrp.aus1.giganews.com>m  - "John Santos" <JOHN@egh.com> wrote in messages) news:1011127141042.16710A@Ives.egh.com...    ...l  E > When you think about it, they still have to support VAX-Alpha mixed E > clusters, and if they are also supporting Alpha-IPF mixed clusters,dC > either it has to work, or the clustering software needs to behaveeC > differently depending on what other nodes are in the cluster.  TotD > make the clustering software sensitive to the other nodes would be3 > a fair amount of work for no conceivable benefit.u >iE > Imagine this situation:  1) Boot up a cluster consisting of a bunchfD > of Alpha nodes.  2) Boot a VAX into the cluster.  Works fine.  NowC > imagine a second situation:  1) Boot up a cluster consisting of aaF > bunch of Alpha nodes.  2) Boot an IPF into the cluster.  Should also@ > work fine.  So how do all the Alphas at initial boot time knowB > which situation will prevail, and start doing all the stuff that > won't work with VAXes?  J Not that I have the slightest clue in this area, but now that you've posedL the question the following kludge just popped into my head (though far be it from me to endorse it...):  J People a while ago mentioned a likely problem with existing DCL usage thatE might assume that if something was not an Alpha then it must be a VAXoJ (IIRC).  If one prohibited fully-integrated clusters than such usage couldG be made to work transparently in either an Alpha-Itanic or an Alpha-VAX F cluster.  Of course, a different (and I'd say cleaner) way would be toH define an Itanic as an Alpha for that purpose and establish a new way to differentiate between them.i  ? That kind of thing *could* possibly motivate the non-support ofhK fully-integrated clusters.  But it's hard to imagine that there wouldn't beiJ cleaner ways around it, and as I said initially this is speculation of theE most ignorant kind (to a degree which would be deplorable if I hadn'taI already apologized twice for it - but it's pleasant to do something otheru% than argue at least once in a while)..   - bill   ------------------------------  % Date: Tue, 27 Nov 2001 16:10:38 -050065 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>aN Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org3 Message-ID: <ukTM7.2011$RL6.62015@news.cpqcorp.net>    Ah, but not fair -  F How are we to tell if your self importance, and compulsion to show how$ intellectual you are - is justified?  I So far your argument is based on your belief that Jeff isn't competent toh* argue with you on some intellectual level.         Dr. Dweeb. wrote in message ...p >Bill, >a< >I do not believe we are acquainted.  The world is very big. >s >I have responeded to Jeff.e > I >I apologise for the pseudonym.  I thought it better to be nameless whilee$ >inserting myself into the "debate". >r >p.c >e6 >"Bill Todd" <billtodd@metrocast.net> wrote in message< >news:sLRM7.76176$8q.10299019@bin2.nnrp.aus1.giganews.com...I >> I'd thank you privately, if your email address weren't fabricated, forlD >> taking the time to present in detail what I often haven't had the patienceH >> to.  Given your 20+ years in the DECpaq world, do we know each other? >YourdG >> prose (and pseudonym) reminds me a bit of one RH I once worked with.e >>	 >> - bill  >>3 >> "Dr. Dweeb." <Dweeb@nospam.com> wrote in message , >> news:6NQM7.98$G53.9276@news.get2net.dk... >> >> >> >  >    ------------------------------  # Date: Tue, 27 Nov 2001 21:25:13 GMT * From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org< Message-ID: <ZwTM7.53419$YD.4806179@news2.aus1.giganews.com>  0 "Dr. Dweeb." <Dweeb@nospam.com> wrote in message) news:6NQM7.98$G53.9276@news.get2net.dk...e   ...p   > Basically, CompaQ, throughK > the actions and words of its responsible executives, has demonstrated the F > integrity of a gutter rat and has displayed a level of duplicity and deceitJ > (tautological I know, but ...) to which I wish I had not been a witness.  H While I heartily agree with the sentiment expressed above (and virtuallyI everything else you posted along with it), I must take minor exception tohL your parenthetical phrase above.  Compaq has not only misled by obfuscation,J misdirection, and cunning (duplicity) but lied outright (deceit), and both are worthy of note.    - bill   ------------------------------  # Date: Tue, 27 Nov 2001 22:36:25 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org6 Message-ID: <JzUM7.107$s06.27180@typhoon2.gnilink.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in messageo; news:2kSM7.76249$8q.10317432@bin2.nnrp.aus1.giganews.com...i >e3 > "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messageg1 > news:HJRM7.44$h24.14442@typhoon1.gnilink.net...    >   The fundamentaleF > > assumption is that the market place values on a chip rather than a > solution.W >eI > Wrong.  One of several fundamental assumptions is that the power of thes@ > processor has significant effects upon the ability to create a > cost-effective solution.  K Maybe Todd is finally getting it.  Are you willing to acknowledge that whateL the market values is the amount of computing punch for the dollars expended?J If your answer is no then why would the market care about your assumption?   ------------------------------  # Date: Tue, 27 Nov 2001 22:46:00 GMTf& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org6 Message-ID: <IIUM7.128$h24.22327@typhoon1.gnilink.net>  K Worry not Fred - if Dr. Dweeb won't reveal himself there will be no furthermH responses to me from him.  For all we know Bill Todd may have created an alter ego...  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message- news:ukTM7.2011$RL6.62015@news.cpqcorp.net...i > Ah, but not fair - > H > How are we to tell if your self importance, and compulsion to show how& > intellectual you are - is justified? >rK > So far your argument is based on your belief that Jeff isn't competent to , > argue with you on some intellectual level. >  >x >t >a! > Dr. Dweeb. wrote in message ...  > >Bill, > >h> > >I do not believe we are acquainted.  The world is very big. > >n > >I have responeded to Jeff.f > >tK > >I apologise for the pseudonym.  I thought it better to be nameless whilet& > >inserting myself into the "debate". > >D > >p.o > >r8 > >"Bill Todd" <billtodd@metrocast.net> wrote in message> > >news:sLRM7.76176$8q.10299019@bin2.nnrp.aus1.giganews.com...K > >> I'd thank you privately, if your email address weren't fabricated, foroF > >> taking the time to present in detail what I often haven't had the
 > patienceJ > >> to.  Given your 20+ years in the DECpaq world, do we know each other? > >Your I > >> prose (and pseudonym) reminds me a bit of one RH I once worked with.  > >> > >> - billa > >>5 > >> "Dr. Dweeb." <Dweeb@nospam.com> wrote in messagee. > >> news:6NQM7.98$G53.9276@news.get2net.dk... > >> > >> > >> > >  > >n >e >    ------------------------------  # Date: Tue, 27 Nov 2001 23:13:20 GMTy& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org6 Message-ID: <k6VM7.140$h24.23231@typhoon1.gnilink.net>   Read carefully folks...u  5 "Bill Todd" <billtodd@metrocast.net> wrote in message ; news:2kSM7.76249$8q.10317432@bin2.nnrp.aus1.giganews.com...  > 3 > "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messagen  H > > Even Todd at this point will acknowledge that a multi-IA64 processor couldsI > > achieve the same performance level as a multi-Alpha processor system.r > F > As 'could' a multi-IA32-processor, or even a multi-PDP-11-processor,K > configuration - for *some* but definitely not *all* uses.  You've ignoredo myD > very explicit clarification of this, with is either incompetent or > dishonest.  E The reality is that the number of applications this applies to is theeF minority, and not the majority, in the typical commercial environment.L Being one who saw the magic of clusters when they first came out understandsF what they can do for a typical commercial mixed workload requirements.  L When Todd is giving his examples sanity check them against the work load mixI in your environment.  Remember also the examples are based on much fasterIF Alpha processors.  When you are thinking about your applications todayF remember the IA64 processors 2-3 generations out will be _faster_ thanH today's Alpha processors.  So the applications that fit Todd's exceptionI would be ones that require more processor power than you have today.  HoweA many of your application fit that model if we buy his assumption?r  L > > commercial me wrap-up with this  - assume Compaq delivers on its promise that > IA64J > > is only a compile away and delivers IA64 based servers running OVMS or > Tru64tI > > that is equal to or better than the competition in price performance.n > Grant L > > the assumption for the moment.  Do you think many will care that OVMS is > nowiK > > running on IA64 versus Alpha.  If it is only a  recompile away, and the<G > > price performance is there, what rational business reason would any.B > > unemotional person have for caring it is not running on Alpha? >oD > 1.  They will care because *verifying* that the recompile of theirL > applications (and any recompiled components they obtained from others) was* > all it took takes non-negligible effort. >sL > 2.  They will care because Compaq will have spent 3 years preoccupied withJ > the porting effort rather than adding *real* value to VMS (and ISVs will/ > have been diverted by such activity as well).i  K No matter how you attempt to cut it the pain of doing this will be at leasttL a magnitude less than (a likely many magnitude less than) porting to another	 platform.g  H The decision on Alpha is final.  Even if Compaq changed its mind at thisH point the tenuous credibility that Alpha had in the marketplace is gone.- The best course of action is to move forward.o  D The alternative is you can take the Todd approach which is to try toG discredit his ex-employer and try to destroy the viability of OVMS.  OfbH course it would be a little hard to claim one is trying to save OVMS but8 trashing it to the point where everyone migrates off it.  J > 3.  They will care because the risk that the transition will *not* be asL > smooth as you posit and/or that Itanic will continue to suck so badly thatA > cost-effective platforms simply cannot be based on it will havepK > significantly reduced VMS's market (and ISV base) over the 3 years beforeiK > such risks have been proved not to exist (*if* we accept your assumptions  toK > this effect) and therefore VMS will have a significantly smaller customereK > base to fund its future development (if there is such) or even existence.   D Again Todd stating his opinion as fact.  IA64 will suck badly 2 to 3J generations out - how do we know this as fact?  Because of course the sage Todd has said so...   K > And, of course, for some non-zero number of installations, recompiling is J > not an option in any event - and even if running via a binary translator isF > effective that too will require verification effort.  And some otherF > non-zero number of installations will have to choose between runningI > unsupported cluster mixes that include VAXen and reconfiguring to avoidwK > them.  And I'm sure there are some other minorities that will be affectedt inH > other ways that don't pop into my mind (but likely can be filled in byL > others here):  for a system with as small a user population as VMS alreadyF > has, it doesn't take too many such minorities to add up to something > significant.  H Folks neither need to take my opinion or your opinion on this.  They canK contact Compaq and start getting "Golden Blanket" written guarantees on theg conversion.   H > Those are the down-sides when we *grant* your assumptions.  The actualI > potential down-sides are far worse.  And there's *no* real up-side:  att bestF > (and again granting your assumptions rather than using a less biased crystaltJ > ball), by 2005 - 6 people will be able to buy hardware to run VMS that'sL > somewhat less expensive for the same performance than would otherwise haveI > been available, but hardware cost is not (at least according to severalcL > surveys that used to be on the Compaq Web site) a dominant concern for VMSD > customers anyway (very-low-end applications possibly excepted, but *that's* > a whole 'nother subject).l  K The upside is not doing a far more painful conversion.  If folks wonder whybD I say it highly relevant that some in this discussion have no vestedJ interest in a OVMS code base here is your reason why.  One who has to do aJ conversion would pause and think carefully about the alternative knowing a& steady state is no longer an option...   ------------------------------  # Date: Tue, 27 Nov 2001 23:20:12 GMTl* From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.orgA Message-ID: <McVM7.76408$8q.10415768@bin2.nnrp.aus1.giganews.com>l  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messagee0 news:JzUM7.107$s06.27180@typhoon2.gnilink.net...7 > "Bill Todd" <billtodd@metrocast.net> wrote in message = > news:2kSM7.76249$8q.10317432@bin2.nnrp.aus1.giganews.com...f > >e5 > > "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message 3 > > news:HJRM7.44$h24.14442@typhoon1.gnilink.net..., >  > >   The fundamentaleH > > > assumption is that the market place values on a chip rather than a
 > > solution.n > >oK > > Wrong.  One of several fundamental assumptions is that the power of the B > > processor has significant effects upon the ability to create a > > cost-effective solution. >mH > Maybe Todd is finally getting it.  Are you willing to acknowledge that whatD > the market values is the amount of computing punch for the dollars	 expended?rL > If your answer is no then why would the market care about your assumption?  K That's been an important part of my thesis from the start - not that you'veeJ shown any ability to understand much of what's been under discussion here,J so it's not too surprising you missed it.  If you're just catching up now, don't blame me.r  F Come back when (if ever) Itanic starts to offer server computing powerJ comparable to Alpha's at the same price.  Or, if you'd like to try to lookL forward, find some indication from the pre-June25th road maps of when such aL time would ever have occurred - remembering your own statement (which echoedK earlier ones of mine) that the cost of the processor doesn't contribute too J much to the cost of a mid-range or better server, the implication of whichK is that higher-performance Alphas will be more cost-effective in the comingoK Blades until such time as they fall behind the technology curve due to lacku of continued development.-   - bill   ------------------------------  # Date: Tue, 27 Nov 2001 23:27:33 GMT(& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org6 Message-ID: <FjVM7.111$s06.30313@typhoon2.gnilink.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in message>; news:McVM7.76408$8q.10415768@bin2.nnrp.aus1.giganews.com...s >n3 > "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messagey2 > news:JzUM7.107$s06.27180@typhoon2.gnilink.net...9 > > "Bill Todd" <billtodd@metrocast.net> wrote in message,? > > news:2kSM7.76249$8q.10317432@bin2.nnrp.aus1.giganews.com...l > > >n7 > > > "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messageB5 > > > news:HJRM7.44$h24.14442@typhoon1.gnilink.net...h > >c > > >   The fundamentalsJ > > > > assumption is that the market place values on a chip rather than a > > > solution.o > > > I > > > Wrong.  One of several fundamental assumptions is that the power ofc theeD > > > processor has significant effects upon the ability to create a > > > cost-effective solution. > >1J > > Maybe Todd is finally getting it.  Are you willing to acknowledge that > whatF > > the market values is the amount of computing punch for the dollars > expended?FB > > If your answer is no then why would the market care about your assumption?u >1F > That's been an important part of my thesis from the start - not that you'veL > shown any ability to understand much of what's been under discussion here,L > so it's not too surprising you missed it.  If you're just catching up now, > don't blame me.n  J Granting that you do not believe it will happen - will you grant that if aH IA64 server delivered the same price performance punch as a Alpha serverG that most people would not care which chip was in there?  Please do notoJ dodge the question by talking about the conversion issue.  The question in: this case applies to someone buying a new OVMS solution...   ------------------------------  # Date: Tue, 27 Nov 2001 23:20:34 GMTN& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org6 Message-ID: <6dVM7.144$h24.23578@typhoon1.gnilink.net>  K Of course I will NEVER defend any advertising campaign from Digital/Compaq.o The PR is even worse...   > "John McLean" <mcleanj@swissonline.delete.ch> wrote in message/ news:3C03F589.F05D039D@swissonline.delete.ch...t >f >o > Jeff Killeen wrote:  > >m > ...( > >hL > > Mass advertising either product at this point would be a unwise businessJ > > move.  To create brand identity through mass marketing for a sub-brand costslL > > hundreds of millions of dollars.  There is only mass advertising for theH > > most part for the corporate brand these days.  IBM doesn't advertiseJ > > AS/400's or z/390 systems.  The market the primary brand identity with thewH > > exception of true consumer brands like ThinkPad's.  You don't market OVMSH > > like a $200 Microsoft personal operating system.  People in the OVMS priceiI > > range buy solutions and market penetration depends upon ISV's (see myi > > comments below). >iD > Firstly I don't believe that Compaq have ever tried any reasonableH > amount of advertising of VMS.  You might think diferently if you think7 > advertsisements at Polish bus-stops is the way to go.  >dJ > (I can just imagine it.  Two Polish women talking about buying groceriesH > and one says to the other "That sign reminds me.  I must buy a new VMS% > system while I'm down the street.")o >cH > If Compaq were truly interested in anything by their PCs then we wouldF > see plenty of press releases about the other products.  Fact is thatH > more than 90% of CPQ press releases are about windows products and theA > other 10 or so % are about deals Compaq does with its finances.u >rI > Contrast this with IBM, Sun, HP, Microsoft, Dell, Cisco .. (et al).  IfuD > they don't produce at least 3 press releases per week then there'sH > something wrong.  If they don't mention most of their product lines at > least once a week, ditto.e >eG > These companies know that there is more to marketing than advertising A > and one of these things is to be highly visible.  Compaq's onlyTJ > visibility is the PC sector and then they complain that no-one sees them > as anything but a PC company.  >IH > If you think I'm wrong, show me 11 press releases his year from CompaqJ > that mention VMS in any positive light.  Go on.  One a month.  Shouldn't > be that difficult... >a >i
 > John McLeanr   ------------------------------  # Date: Tue, 27 Nov 2001 23:20:33 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org6 Message-ID: <5dVM7.143$h24.23578@typhoon1.gnilink.net>  5 "Paul Sture" <paul.sture@bluewin.ch> wrote in message1' news:VA.000004cf.a1e5b914@bluewin.ch...dK > "it is only a recompile away" is one heck of an assumption. We've alreadya seenJ > comments on this forum that VAX C support is unlikely, and Ada might not beI > ported. The latter is already of direct concern to me since I currently.F > support an application written in it. If I have to switch compilers,	 somethingi/ > tells me it won't be "only a recompile away".   G If Compaq induces significant pain into this game over - OVMS will die.e  J > But this is still before we get to _testing_. Most of the former testing teamslI > have long since moved onto other projects or pastures new. To retrain at neweL > set of folks in the applications concerned and perform adequate testing is al > mammoth task.o  J Question - I will grant you this is a unwarranted cost to the customer butG what is the alternative?  A port to another platform would be even more 
 painful...   ------------------------------  # Date: Wed, 28 Nov 2001 01:46:23 GMTi* From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.orgB Message-ID: <PlXM7.149549$dk.11004922@bin1.nnrp.aus1.giganews.com>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message40 news:5dVM7.143$h24.23578@typhoon1.gnilink.net... >e7 > "Paul Sture" <paul.sture@bluewin.ch> wrote in message2) > news:VA.000004cf.a1e5b914@bluewin.ch... E > > "it is only a recompile away" is one heck of an assumption. We'ver alreadyn > seenL > > comments on this forum that VAX C support is unlikely, and Ada might not > beK > > ported. The latter is already of direct concern to me since I currentlytH > > support an application written in it. If I have to switch compilers, > somethingg1 > > tells me it won't be "only a recompile away".m >iI > If Compaq induces significant pain into this game over - OVMS will die.  >kL > > But this is still before we get to _testing_. Most of the former testing > teams0K > > have long since moved onto other projects or pastures new. To retrain al > newsK > > set of folks in the applications concerned and perform adequate testing4 is > ap > > mammoth task.  >oL > Question - I will grant you this is a unwarranted cost to the customer butI > what is the alternative?  A port to another platform would be even moree > painful...  L The alternative is to force no port at all:  rather, take the Alpha decision- and shove it right back down Compaq's throat.a   - bill   ------------------------------  # Date: Wed, 28 Nov 2001 01:46:38 GMT * From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org< Message-ID: <2mXM7.54560$YD.4934129@news2.aus1.giganews.com>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messageI0 news:k6VM7.140$h24.23231@typhoon1.gnilink.net... > Read carefully folks...e >n7 > "Bill Todd" <billtodd@metrocast.net> wrote in messageI= > news:2kSM7.76249$8q.10317432@bin2.nnrp.aus1.giganews.com...n > >e5 > > "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messaged >tJ > > > Even Todd at this point will acknowledge that a multi-IA64 processor > could.K > > > achieve the same performance level as a multi-Alpha processor system.d > >oH > > As 'could' a multi-IA32-processor, or even a multi-PDP-11-processor,E > > configuration - for *some* but definitely not *all* uses.  You'ven ignoredt > myF > > very explicit clarification of this, with is either incompetent or > > dishonest. > G > The reality is that the number of applications this applies to is theeH > minority, and not the majority, in the typical commercial environment.B > Being one who saw the magic of clusters when they first came out understands H > what they can do for a typical commercial mixed workload requirements.  > If you believe that cluster behavior is directly applicable toH tightly-coupled MP systems, you're even more incompetent than I thought.  K As far as characterizing the conditions under which more, slower processors4F cannot effectively substitute for fewer, faster processors, to a firstL approximation it's simple:  if the typical number of runnable threads in theK system is less than the number of processors in the system, you'd be better-F off with fewer, faster processors.  After that, you start getting intoG second-order effects that tend to make processing power scale less than I linearly as the number of processors increases, which again favors fewer,,H faster processors (in all cases, not just special ones) but usually only	 slightly.l   >oJ > When Todd is giving his examples sanity check them against the work load mixcK > in your environment.  Remember also the examples are based on much fastereH > Alpha processors.  When you are thinking about your applications todayH > remember the IA64 processors 2-3 generations out will be _faster_ thanJ > today's Alpha processors.  So the applications that fit Todd's exceptionK > would be ones that require more processor power than you have today.  HowlC > many of your application fit that model if we buy his assumption?   B More to the point, how many will fit that model *then*?  While VMSJ applications may not suck up as many more processor cycles each release asL MS bloatware, there's still a noticeable tendency to use more as they become
 available.   > F > > > commercial me wrap-up with this  - assume Compaq delivers on its promise  > that > > IA64L > > > is only a compile away and delivers IA64 based servers running OVMS or	 > > Tru64aK > > > that is equal to or better than the competition in price performance. 	 > > GrantfK > > > the assumption for the moment.  Do you think many will care that OVMS  is > > nowsI > > > running on IA64 versus Alpha.  If it is only a  recompile away, ands theeI > > > price performance is there, what rational business reason would any D > > > unemotional person have for caring it is not running on Alpha? > >yF > > 1.  They will care because *verifying* that the recompile of theirJ > > applications (and any recompiled components they obtained from others) was., > > all it took takes non-negligible effort. > > I > > 2.  They will care because Compaq will have spent 3 years preoccupieda withL > > the porting effort rather than adding *real* value to VMS (and ISVs will1 > > have been diverted by such activity as well).n >hG > No matter how you attempt to cut it the pain of doing this will be at  leastoF > a magnitude less than (a likely many magnitude less than) porting to anotherh > platform.d  J Don't change the question you posed and I answered:  you asked for reasonsF people would care, not reasons why staying with VMS on Itanic would be easier than porting elsewhere.  L But to take up your new implied question:  reasons people would port includeD a) they believed that some time soon they could no longer obtain theG performance they needed on the platforms (stagnant EV7, relatively slowiL Itanic) VMS ran on,  b) they had no confidence that Compaq would continue toD provide the support or new development they needed, or  c) they wereL sufficiently disgusted with Compaq's corporate behavior that it seemed worth	 the pain.c   > ! > The decision on Alpha is final.   J Only death is final, and aren't you one of those whe's been asserting that Alpha isn't dead?i  )   Even if Compaq changed its mind at thislJ > point the tenuous credibility that Alpha had in the marketplace is gone.  K Your opinion, of course.  The predominant reaction here suggests otherwise, H though in terms of *momentum* (as distinct from credibility) it would ofA course have been far better had Compaq not screwed up so royally.,  / > The best course of action is to move forward.n  G Your opinion again, at least from what I'd infer you mean by 'forward'.aD Others believe that the best course of action is to replace Compaq'sL incompetent management (without which action *no* course of action will haveL much chance of success) and 'move forward' in the direction that should have been taken in the first place.   >rF > The alternative is you can take the Todd approach which is to try toE > discredit his ex-employer and try to destroy the viability of OVMS.s  L You're a real shithead, Jeff.  1.  I've never worked for Compaq.  2.  CompaqG has discredited itself to a degree that would be extremely difficult tonB increase.  3.  VMS's viability has already been destroyed, and I'mE advocating the only course that shows any promise of resurrecting it.u     OfJ > course it would be a little hard to claim one is trying to save OVMS but: > trashing it to the point where everyone migrates off it. >AL > > 3.  They will care because the risk that the transition will *not* be asI > > smooth as you posit and/or that Itanic will continue to suck so badlyi thatC > > cost-effective platforms simply cannot be based on it will have F > > significantly reduced VMS's market (and ISV base) over the 3 years beforeA > > such risks have been proved not to exist (*if* we accept yourb assumptionsa > toD > > this effect) and therefore VMS will have a significantly smaller customerB > > base to fund its future development (if there is such) or even
 existence. > F > Again Todd stating his opinion as fact.  IA64 will suck badly 2 to 3L > generations out - how do we know this as fact?  Because of course the sage > Todd has said so...e  L And cited the evidence to support it.  One generation out is McKinley, whichF Intel is already suggesting will be about 1.6 times the performance ofJ Merced (i.e., pretty much the same improvement one would expect from otherF architectures given the year between their introductions, and thus notL noticeably improving Itanic's relative position in the speed sweeps).  IntelF has also indicated that Madison (two generations out from now) will beJ McKinley with a process-shrink and more cache, which also promises only toG follow the normal speed-improvement curve and thus again not noticeably0J improve Itanic's industry position.  And either the generation beyond thatK is not yet even publicly defined or it's Deerfield, which is a cost-reduced,F Madison with less cache (and hence won't improve things at all, unless$ another process-shrink is involved).  G By contrast, EV7 will not only complete the Alpha move to a 0.18 microntG process but add dramatic improvements in memory latency, bandwidth, andtL on-chip MP support - thus increasing performance faster than industry norms.A And EV8 would have added SMT and other tweaks to, again, increase G performance (certainly in server-style use) faster than industry norms.nK Which means that 2 - 3 generations out, Alpha would be significantly fastere$ relative to Itanic than it is today.  H Just because you're abysmally ignorant of the available data surrounding. this discussion doesn't mean that everyone is.   >iJ > > And, of course, for some non-zero number of installations, recompiling isL > > not an option in any event - and even if running via a binary translator > isH > > effective that too will require verification effort.  And some otherH > > non-zero number of installations will have to choose between runningK > > unsupported cluster mixes that include VAXen and reconfiguring to avoidoD > > them.  And I'm sure there are some other minorities that will be affected > inJ > > other ways that don't pop into my mind (but likely can be filled in byF > > others here):  for a system with as small a user population as VMS already H > > has, it doesn't take too many such minorities to add up to something > > significant. >-J > Folks neither need to take my opinion or your opinion on this.  They canI > contact Compaq and start getting "Golden Blanket" written guarantees ona theK
 > conversion.w  K You're trying to change the question you asked again:  people don't want tooJ have to exercise such 'guarantees', they want smooth evolution - which had9 the Alpha development path continued they would have had.f   >IJ > > Those are the down-sides when we *grant* your assumptions.  The actualK > > potential down-sides are far worse.  And there's *no* real up-side:  at7 > bestH > > (and again granting your assumptions rather than using a less biased	 > crystaloL > > ball), by 2005 - 6 people will be able to buy hardware to run VMS that'sI > > somewhat less expensive for the same performance than would otherwise  haveK > > been available, but hardware cost is not (at least according to severalrJ > > surveys that used to be on the Compaq Web site) a dominant concern for VMSfF > > customers anyway (very-low-end applications possibly excepted, but
 > *that's* > > a whole 'nother subject).  > 8 > The upside is not doing a far more painful conversion.  H No, you idiot:  you asked why people would care that they were no longerE running on Alpha, not whether that would make them mad enough to movep
 elsewhere.  L I'll spell out the current problem once more, because you still seem to have2 no grasp of it (let alone the associated details):  G It's the cancellation of Alpha.  Period.  This was an incredibly stupidoJ move, because it  a) immediately turned one of the most profitable productK lines Compaq has into yet another struggling one,  b) in the process likelyaK cost more money than eliminating development will save over the same period F (let alone the cost in future sales),   c) cut VMS's its nascent salesJ up-turn off at the knees (thus putting yet another stake into the heart ofH its already-fragile long-term viability)  d) did similar damage to Tru64K (though the merger now shows signs of turning that lingering illness into a:B more precipitous demise), and  e) highlighted the fact that CompaqK management are incompetent weasels with whom at least many people would notl7 choose to do business given any reasonable alternative.q  K The future 'blade' architecture you've described does not change any of therG above in the slightest - in fact, it supports it.  Because Compaq *has* K elected to make the blades support both Alpha and Itanic engines, they willcI indeed benefit from any volume market that Itanic might provide, and thustF the only difference in cost between an Alpha-based blade server and anB Itanic-based blade server will be the per-processor cost, which weI apparently both agree is not a major contributor to overall server price.s  K (I said 5 months ago when this brouhaha began that there was no reason thattL Alpha-based platforms couldn't take advantage of all the 'industry-standard'L components that comparable Itanic platforms used, and this bi-sexual 'blade'E design just takes that to its logical extreme.  As long as the design F doesn't cripple Alpha's strengths, it's win-win for both, and the onlyI reason I suggested earlier that it *would* cripple Alpha was because thatfJ was the only explanation for your assertion that somehow for a given levelH of performance the Itanic version would be less expensive than the Alpha	 version.)   I Let's go over that once again, so that there's at least a chance you willtK understand it:  Compaq has ensured that the only difference in cost betweenyH an Alpha blade system and an Itanic blade system will be the cost of theK processors (or even less, if the Itanic system requires extra glue elementsuH that the Alpha system by virtue of its on-chip features does not).  ThatL difference will be only a small percentage of overall server cost - assumingK that both systems have the same number of processors.  But in that case theeL Alpha-based system will have about twice the performance of the Itanic-basedJ system - or, if you prefer, will require only about half the blades of theJ Itanic system and therefore cost considerably *less* than the Itanic-based! system of comparable performance.   L I have no problem if Compaq can sell zillions of Itanic systems of that typeL (though strongly doubt that it will, because I doubt that they will turn outL to be competitive with the other options that will be out there, principallyL POWER4 and Hammer).  What I have a problem with is not maintaining the AlphaG development that would have allowed them to offer right alongside thoserD Itanic systems the option of buying more cost-effective (though lessI 'industry-standard') Alpha systems - *even though each Alpha processor in2F those systems carried the full burden of its development cost and thusI funded it fully*.  *That's* what's so stupid - not only because it's lostoF opportunity for Compaq, but because the other effects of killing AlphaH *will* be felt by customers (as described previously) and the incrediblyH sleazy and perfidious manner in which the murder was handled *will* have+ consequences on Compaq's future in general.h  G None of those are marginal calls.  Alpha's per-processor performance isiJ superior and would have only become more so over the time period for whichL any real information is available.  Significant percentages of customers areG already significantly upset at  a) the disruption they foresee in theire? operations and  b) the way Compaq went about this.  And Alpha'snG profitability was well-established and relatively constant, despite the-L neglect of its owner (so this argument doesn't depend on an expansion of itsE markets, though such expansion was without doubt eminently possible)..  K Compaq was stupid.  Compaq was sleazy.  Compaq was wrong.  And it's time tom fix it.o   - bill   ------------------------------  # Date: Wed, 28 Nov 2001 02:44:48 GMTs4 From: "Terry C. Shannon" <terryshannon@mediaone.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org: Message-ID: <AcYM7.268$zX1.661028@typhoon.ne.mediaone.net>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messagei0 news:6dVM7.144$h24.23578@typhoon1.gnilink.net...= > Of course I will NEVER defend any advertising campaign fromp Digital/Compaq.e > The PR is even worse...o   Well stated, Jeff!   ------------------------------    Date: 27 Nov 2001 19:00:35 -0800/ From: Brannon_Batson@yahoo.com (Brannon Batson)nN Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org= Message-ID: <4495ef1f.0111271900.4e79ba98@posting.google.com>m  e "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message news:<8EFM7.2348$zf.223065@typhoon2.gnilink.net>...lM > > Then either Fenwick is wrong or the Alpha engineering team is wrong. ThisnB > > might make for an interesting debate between the two factions. > N > It is likely a case of the direction each group in looking at the data from.   Perhaps.  M > Also history has shown the Alpha engineering team has the underdog attitude N > of being very protective of their baby - few people placed in that situation/ > wouldn't react they way the Alpha team has...t  A Everyone has a vested personal interest in their technical claimstB during this debate.  What may be non-obvious is that this includes both sides.    Brannon2 not speaking for Intel   ------------------------------  # Date: Wed, 28 Nov 2001 03:01:40 GMTs$ From: Ric Werme <werme@mediaone.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org: Message-ID: <osYM7.271$zX1.671504@typhoon.ne.mediaone.net>  ( peter@abbnm.com (Peter da Silva) writes:  8 >In article <jeBM7.2212$zf.215408@typhoon2.gnilink.net>,& >Jeff Killeen <Jeff@IDM-IO.com> wrote:D >> At the risk of being setup - OK what is the "nine woman" mistake?  H >If one woman can produce one baby in nine months, surely nine women can >do it in one month.  D >Come on, folks, two wrong followups already. I thought this was THEK >canonical dramatization of Amdahl's Law. I guess something an IBM engineercF >came up with in 1967 is ancient history, not of interest to the young >bucks around today.  ? Worse, it shows that the young bucks haven't read _The Mythical F Man-Month_.  While I confess to not keep up with similar literature (IJ did buy the second edition when it came out), I'd be surprised if anything7 has supplanted Brooks' book.  Or even joined its class..   	-Ric Wermeh --K "When we allow fundamental freedoms to be sacrificed in the name of real oraD perceived emergency, we invariably regret it.   -- Thurgood MarshallC    Ric Werme                            | werme@nospam.mediaone.nete>    http://people.ne.mediaone.net/werme  |       ^^^^^^^ delete   ------------------------------  # Date: Wed, 28 Nov 2001 03:29:41 GMT4& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org6 Message-ID: <FSYM7.172$s06.38481@typhoon2.gnilink.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in message < news:PlXM7.149549$dk.11004922@bin1.nnrp.aus1.giganews.com...  E > The alternative is to force no port at all:  rather, take the Alphat decision/ > and shove it right back down Compaq's throat.   K Bill all barbs aside - there is no way this is going to happen and all thatuL will happen from this Jihad of yours is the potential to inflict significant collateral damage on OVMS.  K I suspect response will be OVMS is dead anyway unless the world sees thingsfH your way so you are doing no damage.  Unfortunately I have found zealotsL will rationalize their destructive behaviors in the context of saving peopleG from their ultimate destruction so they can justify all means given thep ends.   I I honestly and truly wish you would cut through all the bull of attacking K everyone here who disagrees with you and clearly state that your goal is to D totally discredit this decision by all means possible.  It certainlyK explains why you have taken the position no IA64 path forward is viable ande: every Alpha path forward is virtual risk and problem free.  J I think if people understood you believe this decision can be reverse they/ would have a honest context to your postings...    ------------------------------  # Date: Wed, 28 Nov 2001 03:29:24 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org6 Message-ID: <oSYM7.171$s06.38481@typhoon2.gnilink.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in message 6 news:2mXM7.54560$YD.4934129@news2.aus1.giganews.com... >r3 > "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messagen2 > news:k6VM7.140$h24.23231@typhoon1.gnilink.net... > > Read carefully folks...  > > 9 > > "Bill Todd" <billtodd@metrocast.net> wrote in messagee? > > news:2kSM7.76249$8q.10317432@bin2.nnrp.aus1.giganews.com...  > > >h7 > > > "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message  > > L > > > > Even Todd at this point will acknowledge that a multi-IA64 processor	 > > could E > > > > achieve the same performance level as a multi-Alpha processor  system.e > > >tJ > > > As 'could' a multi-IA32-processor, or even a multi-PDP-11-processor,G > > > configuration - for *some* but definitely not *all* uses.  You'vel	 > ignoredi > > myH > > > very explicit clarification of this, with is either incompetent or > > > dishonest. > > I > > The reality is that the number of applications this applies to is the J > > minority, and not the majority, in the typical commercial environment.D > > Being one who saw the magic of clusters when they first came out
 > understandsmJ > > what they can do for a typical commercial mixed workload requirements. >s@ > If you believe that cluster behavior is directly applicable toJ > tightly-coupled MP systems, you're even more incompetent than I thought.  B No that is you putting words in my mouth - I believe the number ofL applications that would benefit from tightly coupled MP of EV8 class are farL more limited than you are portraying here.  That you are using the exceptionJ to justify the rule.  Note I was very careful in the QuickBlade postings IJ made to clarify the processors where group and not all tightly coupled.  IL never said that tightly couple MP and clusters were the same - but for given, work loads there are two ways to skin a cat.  B > As far as characterizing the conditions under which more, slower
 processorsH > cannot effectively substitute for fewer, faster processors, to a firstJ > approximation it's simple:  if the typical number of runnable threads in theaF > system is less than the number of processors in the system, you'd be better$ > off with fewer, faster processors.  E We actually agree on that point.  Here is where I think we disagree -'L typical commercial interactive job mixes have lots of threads to be run.  MyK point is the reader here should think about their actual production mix andiI that the IA64 processors we are talking about will at least equal today'saK Alpha processor.  The make up there own mind about the relevancy of the EV8i4 to IA64 gap as it applies to them in the real world.  % >  After that, you start getting intosI > second-order effects that tend to make processing power scale less than K > linearly as the number of processors increases, which again favors fewer,lJ > faster processors (in all cases, not just special ones) but usually only > slightly.f   I don't disagree  L > > When Todd is giving his examples sanity check them against the work load > mixoF > > in your environment.  Remember also the examples are based on much fasterJ > > Alpha processors.  When you are thinking about your applications todayJ > > remember the IA64 processors 2-3 generations out will be _faster_ thanL > > today's Alpha processors.  So the applications that fit Todd's exceptionH > > would be ones that require more processor power than you have today. HowtE > > many of your application fit that model if we buy his assumption?  > D > More to the point, how many will fit that model *then*?  While VMSL > applications may not suck up as many more processor cycles each release asG > MS bloatware, there's still a noticeable tendency to use more as theyr become > available.  K I think in a Alpha -> IA64 context we should stay focused on OVMS and Tru64   H > > > > commercial me wrap-up with this  - assume Compaq delivers on its	 > promisee > > that
 > > > IA64K > > > > is only a compile away and delivers IA64 based servers running OVMSp or > > > Tru64e@ > > > > that is equal to or better than the competition in price performance. > > > GrantcH > > > > the assumption for the moment.  Do you think many will care that OVMS > is	 > > > now-K > > > > running on IA64 versus Alpha.  If it is only a  recompile away, ando > the K > > > > price performance is there, what rational business reason would anytF > > > > unemotional person have for caring it is not running on Alpha? > > >tH > > > 1.  They will care because *verifying* that the recompile of theirL > > > applications (and any recompiled components they obtained from others) > wasd. > > > all it took takes non-negligible effort. > > >nK > > > 2.  They will care because Compaq will have spent 3 years preoccupiedm > withI > > > the porting effort rather than adding *real* value to VMS (and ISVs  will3 > > > have been diverted by such activity as well).n > >cI > > No matter how you attempt to cut it the pain of doing this will be ate > least H > > a magnitude less than (a likely many magnitude less than) porting to	 > anothera
 > > platform.  >sL > Don't change the question you posed and I answered:  you asked for reasonsH > people would care, not reasons why staying with VMS on Itanic would be  > easier than porting elsewhere. >bF > But to take up your new implied question:  reasons people would port include F > a) they believed that some time soon they could no longer obtain theI > performance they needed on the platforms (stagnant EV7, relatively slownK > Itanic) VMS ran on,  b) they had no confidence that Compaq would continueh toF > provide the support or new development they needed, or  c) they wereH > sufficiently disgusted with Compaq's corporate behavior that it seemed worthp > the pain.V  2 B and C are business decisions and not a technical  # > > The decision on Alpha is final.i >fL > Only death is final, and aren't you one of those whe's been asserting that > Alpha isn't dead?o  F Not me - I believe on June 25th Alpha was irrevocably destroyed in theI marketplace.  The reason why is that if the decision was reversed the ISV K community would never trust that it would stick.  It is the same reason whynI I feel Tru64 suffered an irrevocable death in mid September.  Even if the K merger never happens the ISV community would never trust in the marketplacelC viability of Tru64 again after the way Compaq justified the merger.i  + >   Even if Compaq changed its mind at thisaL > > point the tenuous credibility that Alpha had in the marketplace is gone. >oB > Your opinion, of course.  The predominant reaction here suggests
 otherwise,J > though in terms of *momentum* (as distinct from credibility) it would ofC > course have been far better had Compaq not screwed up so royally.h  J Perception is reality and the perception of the ISV's is what drives theseL markets.  Few ISV's will bet major dollars on Alpha and Tru64 after what has	 happened.t  1 > > The best course of action is to move forward.o >pI > Your opinion again, at least from what I'd infer you mean by 'forward'.tF > Others believe that the best course of action is to replace Compaq'sI > incompetent management (without which action *no* course of action willo haveI > much chance of success) and 'move forward' in the direction that shouldi have  > been taken in the first place.  K I believe whatever anyone feels about replacing Compaq's management at thiseI point is a side issue. The damage to marketplace credibility of Alpha hasuL been done.  ISV's will say yea right - what happens the next time management changes.  H > > The alternative is you can take the Todd approach which is to try toG > > discredit his ex-employer and try to destroy the viability of OVMS.h >sF > You're a real shithead, Jeff.  1.  I've never worked for Compaq.  2. CompaqI > has discredited itself to a degree that would be extremely difficult toiD > increase.  3.  VMS's viability has already been destroyed, and I'mG > advocating the only course that shows any promise of resurrecting it.a  1 More unemotional professionalism from our friend.    Did you not work for Digital?u   >   OfL > > course it would be a little hard to claim one is trying to save OVMS but< > > trashing it to the point where everyone migrates off it. > >oK > > > 3.  They will care because the risk that the transition will *not* ben asK > > > smooth as you posit and/or that Itanic will continue to suck so badlye > thatE > > > cost-effective platforms simply cannot be based on it will haveeH > > > significantly reduced VMS's market (and ISV base) over the 3 years > beforeC > > > such risks have been proved not to exist (*if* we accept yourb
 > assumptionsh > > toF > > > this effect) and therefore VMS will have a significantly smaller
 > customerD > > > base to fund its future development (if there is such) or even > existence. > >dH > > Again Todd stating his opinion as fact.  IA64 will suck badly 2 to 3I > > generations out - how do we know this as fact?  Because of course thee sage > > Todd has said so...t >oH > And cited the evidence to support it.  One generation out is McKinley, which H > Intel is already suggesting will be about 1.6 times the performance ofL > Merced (i.e., pretty much the same improvement one would expect from otherH > architectures given the year between their introductions, and thus notG > noticeably improving Itanic's relative position in the speed sweeps).  InteliH > has also indicated that Madison (two generations out from now) will beL > McKinley with a process-shrink and more cache, which also promises only toI > follow the normal speed-improvement curve and thus again not noticeablycL > improve Itanic's industry position.  And either the generation beyond that@ > is not yet even publicly defined or it's Deerfield, which is a cost-reducedH > Madison with less cache (and hence won't improve things at all, unless& > another process-shrink is involved). >tI > By contrast, EV7 will not only complete the Alpha move to a 0.18 micronyI > process but add dramatic improvements in memory latency, bandwidth, andlG > on-chip MP support - thus increasing performance faster than industry, norms.C > And EV8 would have added SMT and other tweaks to, again, increasetI > performance (certainly in server-style use) faster than industry norms.aF > Which means that 2 - 3 generations out, Alpha would be significantly faster& > relative to Itanic than it is today. >cJ > Just because you're abysmally ignorant of the available data surrounding0 > this discussion doesn't mean that everyone is.  L There is an interesting POV you keep ignoring.  Your arguments are all basedG on IA64 performance relative to Alpha - I am far more concerned at thissI point whether IA64 can do the job for me instead of theoretical argumentsp about the gap.  L > > > And, of course, for some non-zero number of installations, recompiling > isC > > > not an option in any event - and even if running via a binaryp
 translator > > isJ > > > effective that too will require verification effort.  And some otherJ > > > non-zero number of installations will have to choose between runningG > > > unsupported cluster mixes that include VAXen and reconfiguring too avoideF > > > them.  And I'm sure there are some other minorities that will be
 > affected > > inL > > > other ways that don't pop into my mind (but likely can be filled in byH > > > others here):  for a system with as small a user population as VMS	 > alreadydJ > > > has, it doesn't take too many such minorities to add up to something > > > significant. > >iL > > Folks neither need to take my opinion or your opinion on this.  They canK > > contact Compaq and start getting "Golden Blanket" written guarantees on2 > the0 > > conversion.  >mJ > You're trying to change the question you asked again:  people don't want toL > have to exercise such 'guarantees', they want smooth evolution - which had; > the Alpha development path continued they would have had..  C No I am facing reality - you believe that the Alpha decision can be.H reversed - I do not believe so.  If you don't believe it can be reversed: than the options you are placing on the table don't exist.  L > > > Those are the down-sides when we *grant* your assumptions.  The actualI > > > potential down-sides are far worse.  And there's *no* real up-side:u at > > bestJ > > > (and again granting your assumptions rather than using a less biased > > crystalmG > > > ball), by 2005 - 6 people will be able to buy hardware to run VMSz that'sK > > > somewhat less expensive for the same performance than would otherwisei > haveE > > > been available, but hardware cost is not (at least according tot severalcL > > > surveys that used to be on the Compaq Web site) a dominant concern for > VMSfH > > > customers anyway (very-low-end applications possibly excepted, but > > *that's* > > > a whole 'nother subject).c > >o: > > The upside is not doing a far more painful conversion.  J > No, you idiot:  you asked why people would care that they were no longerG > running on Alpha, not whether that would make them mad enough to movev > elsewhere.  H I was responding to your claim there is no upside.  Once again Bill yourH calling someone an idiot because you believe your assumption to be fact.K You assume, as proven by the statements below, that Alpha business was justoK humming along fine.  I do not believe that was the case.  Most, if not all,aL of the major industry analyst were questioning how long Compaq could justifyI its investment in Alpha given the potential return.  I know to you we are : all idiots - I feel in good company with my fellow idiots.  I > I'll spell out the current problem once more, because you still seem tom have4 > no grasp of it (let alone the associated details): >oI > It's the cancellation of Alpha.  Period.  This was an incredibly stupidLL > move, because it  a) immediately turned one of the most profitable productF > lines Compaq has into yet another struggling one,  b) in the process likelyF > cost more money than eliminating development will save over the same periodH > (let alone the cost in future sales),   c) cut VMS's its nascent salesL > up-turn off at the knees (thus putting yet another stake into the heart ofJ > its already-fragile long-term viability)  d) did similar damage to Tru64K > (though the merger now shows signs of turning that lingering illness intog a D > more precipitous demise), and  e) highlighted the fact that CompaqI > management are incompetent weasels with whom at least many people would  not^9 > choose to do business given any reasonable alternative.   J "A" above is flat out not true.  I have seen the internal numbers and whatI the Alpha servers have been contributing in profits over the last severalDK years is significantly below two other groups.  Sorry but the information Is saw I can't release.  8 "B" is an assumption reasonable people will disagree on.  K "C" is likely a 12 month window unless Compaq fails to develop strong proof = points about the conversion - yes it is a risk but not a facti  . "D" - Tru64 has been given a serious 1-2 punch   "E" is opinion  L Re: "E" BTW if you want to see what a real weasel manager is look at this...  F http://computerworld.com/nlt/0%2C3590%2CNAV47_STO66102_NLTPM%2C00.html  I > The future 'blade' architecture you've described does not change any of  thetI > above in the slightest - in fact, it supports it.  Because Compaq *has*iH > elected to make the blades support both Alpha and Itanic engines, they willK > indeed benefit from any volume market that Itanic might provide, and thushH > the only difference in cost between an Alpha-based blade server and anD > Itanic-based blade server will be the per-processor cost, which weK > apparently both agree is not a major contributor to overall server price.n  I But the flip side is required the extra processors shouldn't have a majorkE effect on the overall cost of a IA64 system either - Acknowledging wei1 disagree about the value of the extra processors.x  H > (I said 5 months ago when this brouhaha began that there was no reason that: > Alpha-based platforms couldn't take advantage of all the 'industry-standard'IF > components that comparable Itanic platforms used, and this bi-sexual 'blade'3G > design just takes that to its logical extreme.  As long as the designiH > doesn't cripple Alpha's strengths, it's win-win for both, and the onlyK > reason I suggested earlier that it *would* cripple Alpha was because that1L > was the only explanation for your assertion that somehow for a given levelJ > of performance the Itanic version would be less expensive than the Alpha > version.)s  D Actually no - for the record I always felt there wouldn't be a priceH difference.  Meaning that it was going to require extra IA64 processors.C What my contention has been is Compaq should be able to deliver thenK competitive price/performance while avoiding the R&D costs of Alpha.  NeverlJ was that meant to imply same performance for less dollars.  The issue withJ avoiding the R&D costs is NOT to lower the price but to mitigate the risk.  K > Let's go over that once again, so that there's at least a chance you willhE > understand it:  Compaq has ensured that the only difference in costp betweeniJ > an Alpha blade system and an Itanic blade system will be the cost of theD > processors (or even less, if the Itanic system requires extra glue elementsJ > that the Alpha system by virtue of its on-chip features does not).  ThatE > difference will be only a small percentage of overall server cost -p assuming7 > that both systems have the same number of processors.e  J Lets try it again to see if we can get you to see the business dimensions.I Assume that with the added processors there is no cost advantage.  I knowc= you claim the added IA64 processors won't achieve competitiveyL price/performance but humor me.  What the issue here is risk.  If Compaq canL achieve the same competitive price performance without the R&D risk of AlphaH the text book business decision to make is to avoid the risk because theL added reward is not there.  I suspect you believe people who see things thisI way are idiots but it is the way the investment world works.  I also knowsJ you believe that they have taken a far greater risk with the loss of theirD customer base - we choose to disagree on that point - I suspect your$ response will be well your an idiot.   > But in that case theA > Alpha-based system will have about twice the performance of the  Itanic-basedL > system - or, if you prefer, will require only about half the blades of theL > Itanic system and therefore cost considerably *less* than the Itanic-based# > system of comparable performance.p  K We will disagree on that - I don't claim you are wrong - what I do claim is < you don't have the data to prove Compaq wrong at this point.  I > I have no problem if Compaq can sell zillions of Itanic systems of that  typeJ > (though strongly doubt that it will, because I doubt that they will turn outaB > to be competitive with the other options that will be out there, principallyeH > POWER4 and Hammer).  What I have a problem with is not maintaining the AlphacI > development that would have allowed them to offer right alongside thosedF > Itanic systems the option of buying more cost-effective (though lessK > 'industry-standard') Alpha systems - *even though each Alpha processor intH > those systems carried the full burden of its development cost and thusK > funded it fully*.  *That's* what's so stupid - not only because it's losthH > opportunity for Compaq, but because the other effects of killing AlphaJ > *will* be felt by customers (as described previously) and the incrediblyJ > sleazy and perfidious manner in which the murder was handled *will* have- > consequences on Compaq's future in general.f  H I suspect no matter how the interment of Alpha was handled it would have" caused a strong negative reaction.  K Understand Bill I see your judgement call on this that Compaq won't be ableeC to compete.  I see the judgement call of the chief architect of theoH TurboLaser and the Wildfire coming to a different conclusion.  I _known_F that the conclusion he came to originated in his group and effectivelyI killed his own project.  If you can objectively look at it for a moment - I and understanding that we are all idiots who see legitimacy in the Compaq J POV - if you were a bystander who's judgement would you tend to place moreL credibility in?  Or to put it another way, not to be nasty, as bright as youH are how many TurboLaser and Wildfire class systems have you delivered to market?   K Bill I respect your opinion but I find the way you treat it as fact and thehL way you treat people who challenge you truly distastefully.  I have actuallyD used some of your POV's in discussing issue with Compaq on behalf of; Encompass but I took great care to remove the bitterness...d  I > None of those are marginal calls.  Alpha's per-processor performance is L > superior and would have only become more so over the time period for whichJ > any real information is available.  Significant percentages of customers arebI > already significantly upset at  a) the disruption they foresee in theirpA > operations and  b) the way Compaq went about this.  And Alpha'snI > profitability was well-established and relatively constant, despite the J > neglect of its owner (so this argument doesn't depend on an expansion of itskG > markets, though such expansion was without doubt eminently possible).I >iJ > Compaq was stupid.  Compaq was sleazy.  Compaq was wrong.  And it's time to	 > fix it.n  K Can't be changed - when it comes to marketplace perception you can't unringt	 a bell...o   ------------------------------  # Date: Wed, 28 Nov 2001 03:45:10 GMTE3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk>hN Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org/ Message-ID: <3C045D09.72A8587B@cableinet.co.uk>c   Paul Sture wrote:   pK > Just seen it on CNN. IMHO it gave a very clear message, about _services_.u  1 its been showing here on and off for some months.i  A There was a Compaq one about services too, but I havn't seen that 	 recently.eE I didn't like the tone of that one. IMHO the IBM ads are what VMS adsu should have been like a decade ago :-(n   regardst  c   --   Tim.Llewellyn@cableinet.co.uk  n  C Standard disclaimer applies. My views in no way represent those of .! my employers or service provider.l   ------------------------------   Date: 27 Nov 2001 21:48 CSTh' From: carl@gerg.tamu.edu (Carl Perkins)yN Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org- Message-ID: <27NOV200121484900@gerg.tamu.edu>p  / young_r@encompasserve.org (Rob Young) writes... X }In article <26NOV200123190199@gerg.tamu.edu>, carl@gerg.tamu.edu (Carl Perkins) writes:1 }> "Bill Todd" <billtodd@metrocast.net> writes... 5 }> }"Jeff Killeen" <Jeff@IDM-IO.com> wrote in messagel) }> }> I know enough of Fenwick to know...t }> }> : }> }> 1) He had the data and folks outside of Compaq don't }> }  L }> }But the Alpha engineering team certainly did, and without exception they5 }> }have said that Compaq's assertions were bullshit.t }>  @ }> Not only that, but he also clearly didn't have all the data.  }> aA }> Half of the info involved is about the IPF. The information hebC }> had on this must have been what *Intel* told him, as I seriouslyp> }> doubt that he was given unrestricted access to their actual@ }> detailed design information, status reports, etc. It is clear@ }> that Intel has been spewing huge quantities of misinformation@ }> about the IPF for a long time (like, say, when the processorsC }> would actually be available, what the clock speeds would be, ando; }> what the performance at any given clock speed would be).p }> h }  }	Misinformation?  So what!   ( So anybody who believes them is a moron.  E }	Maybe they only hit 15 GHz in a few years instead of 20.  But InteldH }	is openly talking about 20 GHz in their Terahertz project... Terahertz }	by decade end.  B So what? First, see my response just up above. Note that they wereE "openly talking" about the Itanium several years before they actuallyaE managed to build one. Talk is cheap (or perhaps you still beleive the C roadmaps Compaq talked about for the Alpha prior to the Alphacide - F when is EV8 coming out again?). Also, Intel has no monopoly on processI technology (IBM often demonstrates new things before Intel does). BesidesgE which, Alpha doesn't have to match them. It doesn't match them *now*,wE and it is faster than the Itanium. What technology (as in things like F process size, SOI, copper interconnect, etc.) is EV68 built with? WhatH technology is Itanium built with? You'll find that the Alpha is at leastG a full generation behind, I think it's probably more like 2 behind. Yety
 it is faster.   G }	What might have taken place was serious NDA with process technologiesu@ }	, nevermind other things.  Take any CPU out there and pump GHz; }	at it , hang fast caches off it and you have a contender.t }				Rob  B Ah, I see. That's all you have to do. So tell us: if it is so easyC to do this, why is it that Itanium came out at such a low MHz leveliC and why is it that McKinley has had the speed it will be introduced C at reduced from the originally talked about 1.4GHz down to probably < 1.0GHz? Do you really think 1.0GHz is pumping the GHz at it?  ? And while you're at it, tell us this: if it is so easy, why was.D Merced some 5 years late (and, even with an extra 5 years to work on it, still slow)?  E Perhaps the reason is this: it is easy to post messages to newsgroupsID saying "all you have to do is...", but it is not easy to actually doD it. Intel's record with the IPF is pitifully bad. Their demonstratedC ability to acurately indicate how well it will do in the future has C been pitifully bad. Anybody who uses what Intel says about how fastaH their chips will be years in the future to make decisions in the present is a moron.s  C As long as you're believing people who tell you things that are notcD believable, here's another one for you. In 6 years I will personallyC invent a CPU that will outperform anything Intel makes at that time7D by a factor of 17 times and it will use a quarter the power and costC less than half as much to produce. Now you should go tell everybodycE that Intel is doomed since they won't be able to keep up - after all,mD somebody you have no reason to believe, and plenty of reason not to, told you so.   --- Carl   ------------------------------  # Date: Wed, 28 Nov 2001 04:13:30 GMT2. From: "aaron spink" <aaronspink@earthlink.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.orgF Message-ID: <KvZM7.10527$WC1.1306358@newsread2.prod.itd.earthlink.net>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messagen1 news:8gLM7.2434$zf.233455@typhoon2.gnilink.net...sL > The issue isn't whether Alpha would have stayed ahead.  The issue is wouldL > have Alpha stayed ahead by enough so that the business reward equaled bothD > the business risk and the business investment that went along with > continuing Alpha.g >   H Oh, that is simple.  Look at Intel pricing for Itanium or high end xeon.K Now calculate what the Compaq cost per part was for Alpha.  You may come up  with interesting numbers.e   Aaron Spinks  not speaking for Compaq or Intel   ------------------------------  % Date: Wed, 28 Nov 2001 07:25:25 +0100i1 From: John McLean <mcleanj@swissonline.delete.ch> N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org4 Message-ID: <3C048355.AB52308@swissonline.delete.ch>   Jeff Killeen wrote:  > 7 > "Paul Sture" <paul.sture@bluewin.ch> wrote in messaged) > news:VA.000004cf.a1e5b914@bluewin.ch...h ...rR > > But this is still before we get to _testing_. Most of the former testing teamsO > > have long since moved onto other projects or pastures new. To retrain a newtP > > set of folks in the applications concerned and perform adequate testing is a > > mammoth task.  > L > Question - I will grant you this is a unwarranted cost to the customer butI > what is the alternative?  A port to another platform would be even morea > painful...  @ But maybe management will bite the bullet and make the shift ...@ - is there a similar application available on another platform ?F - VMS people are in short supply, what's the point in keeping a box if# they can't get the people to run itr  F You can alienate someone only very slightly and that's enough for themE to go elsewhere.  That's why any transition has to be very very easy.      John   ------------------------------  % Date: Wed, 28 Nov 2001 07:31:53 +0100 1 From: John McLean <mcleanj@swissonline.delete.ch> N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org5 Message-ID: <3C0484D9.67E5714F@swissonline.delete.ch>e   Carl Perkins wrote:a   > In 6 years I will personallyE > invent a CPU that will outperform anything Intel makes at that time F > by a factor of 17 times and it will use a quarter the power and cost$ > less than half as much to produce.  8 Why didn't you tell Compaq about this 6 months ago ???     ;-)o     John McLeane   ------------------------------  # Date: Tue, 27 Nov 2001 19:35:47 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)H Subject: Re: Using INETACP_FUNC$C_GETHOSTBYNAME using fortran- examples?3 Message-ID: <nWRM7.2007$RL6.61640@news.cpqcorp.net>B  U In article <3BF1FCBD.90503@tsoft-inc.com>, David Froble <davef@tsoft-inc.com> writes:s :John Gemignani, Jr. wrote:e : H : > Why are you asking the ACP for this information?  You are better off. : >  calling the DECC function to do the work. : >r	 : > -Johnn :s :e- :Only if you can get yourself to work in 'C'.t :n :t? : > "Jamie Stallwood" <jamie@project76.co.uk> wrote in message  3 :news:cta3vt88o4qklv44mr1fn84adori2ldrul@4ax.com...i : >  :  : >s@ : >> If anybody has any examples in FORTRAN of using the INETACP= : >> functions with QIO in FORTRAN, I would receive them mosto; : >> gratefully! Especially if they use the function above!r : >> : >> Thanks Jamie P Stallwood) :mE :Been way too many years since I did Fortran.  I've implemented some iG :socket communications in Basic using the system service interface. ...o    )   TCPIP$EXAMPLES:TCPIP$TCP_CLIENT_QIO.MAR     N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Tue, 27 Nov 2001 14:33:46 -0500 ; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>p% Subject: Re: XPDF 0.93 - VMS versionsn$ Message-ID: <3c03ea9d$1@news.si.com>  J >I've updated the DECwindows archive with Xpdf version 0.93 (xpdf is a PDF file >viewer). Take a look at url:u >g( >http://decwarch.free.fr/pspdf.html#XPDF  J The link ftp://ftp2.cnam.fr/decwindows/xpdf-093-vaxbin.zip doesn't seem to
 work, though.  --A Brian Tillman                   Internet: tillman_brian at si.comkA Smiths Aerospace                          tillman at swdev.si.com = 3290 Patterson Ave. SE, MS      Addresses modified to prevent < Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------   End of INFO-VAX 2001.661 ************************