1 INFO-VAX	Fri, 24 Oct 2003	Volume 2003 : Issue 589       Contents:- Re: DECUS: "C" stands for Computer, not Corp. + DHCP serving more than one subnet (longish) / Re: DHCP serving more than one subnet (longish) / Re: DHCP serving more than one subnet (longish)  Re: Dial-out PPP on GS140e/8400  Re: Dial-out PPP on GS140e/8400 E Re: DNPG products also through a partner (was: DNPG - No DEC anymore)  EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: EV79 CANCELED !!!!!!!!!  Re: FTP From a Program. High-end SUN servers to be produced by Fujitsu2 Re: High-end SUN servers to be produced by Fujitsu2 Re: High-end SUN servers to be produced by FujitsuP Re: HP announces new AlphaServer systems and enhancements to Tru64 UNIX and OpenP Re: HP announces new AlphaServer systems and enhancements to Tru64 UNIX and OpenP Re: HP announces new AlphaServer systems and enhancements to Tru64 UNIX and Open2 Re: HP offers WebLogic on OpenVMS, NonStop servers2 Re: OpenVMS I64 ISV application count now over 5002 RE: OpenVMS I64 ISV application count now over 5002 Re: OpenVMS I64 ISV application count now over 5002 Re: OpenVMS I64 ISV application count now over 500 Re: OpenVMS Roadmap  Re: OpenVMS Roadmap  Re: OpenVMS Roadmap  Re: OpenVMS Roadmap  Re: OpenVMS Roadmap , Re: OT: Why Scott McNeally is not worried..., Re: OT: Why Scott McNeally is not worried..., Re: OT: Why Scott McNeally is not worried... Re: problem with CXX patch?  Re: Product problem  Re: Spam from Hewlett-Packard  Re: Spam from Hewlett-Packard  Re: Spam from Hewlett-Packard  Re: Spam from Hewlett-Packard  Re: Spam from Hewlett-Packard  Re: Spam from Hewlett-Packard  Re: Spam from Hewlett-Packard  Re: Spam from Hewlett-Packard  Re: Spam from Hewlett-Packard * Sun and the high cost of SPARC development. RE: Sun and the high cost of SPARC development. Re: Translating to I64 (was: We buy Alpha ...)@ Tru64 unix Layeredproducts won't install on my OpenVMS machines!D Re: Tru64 unix Layeredproducts won't install on my OpenVMS machines!D Re: Tru64 unix Layeredproducts won't install on my OpenVMS machines!D Re: Tru64 unix Layeredproducts won't install on my OpenVMS machines!D Re: Tru64 unix Layeredproducts won't install on my OpenVMS machines!$ RE: User permissions vs. volume ACLs VMS Text Files --> Unix  Re: VMS Text Files --> Unix  Re: VMS Text Files --> Unix  Re: VMS Text Files --> Unix  Re: VMS Text Files --> Unix  Re: VMS Text Files --> Unix ) Re: We buy Alpha  - URGENT - DS10 systems ) Re: We buy Alpha  - URGENT - DS10 systems   F ----------------------------------------------------------------------    Date: 23 Oct 2003 22:16:06 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris) 6 Subject: Re: DECUS: "C" stands for Computer, not Corp.; Message-ID: <cf15391e.0310232116.da7704@posting.google.com>   h Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<LZa0As0scfbf@eisner.encompasserve.org>...D > > http://www2.openvms.org/kparris/f2003_intro_vms.ppt presentation > D > Which does not really matter to those of us not running Microsoft. > N > Why can't those who _do_ use Microsoft publish in a non-proprietary format ?  @ Because it's been difficult to find a substitute non-proprietaryE format, or to convert.  PowerPoint theoretically outputs in HTML, but B not well; and it can't output in .PDF by itself (you have to buy aD driver like PDFwriter to do that).  You can buy Distiller from Adobe$ for a high price.  Not good options.  F But with a little web searching, I've found a workable solution.  I've/ now made all the HP World 2003 presentations at > http://www2.openvms.org/kparris/ also available in .PDF formatE (proprietary to Adobe, but at least with a free reader available).  I D used the free service at 2convert.com, which seems to work amazingly well for this type of stuff.  A I have a friend who doesn't use Microsoft software at all for his D work, and yet doesn't complain about Microsoft attachments.  He usesD OpenOffice, and gave me a demo.  I was amazed as it sucked in a hugeA 60 MB PowerPoint file that I had e-mailed to him and displayed it C correctly.  I'm cheering on the folks in The Netherlands working on F porting this software to OpenVMS (and fervently hoping that StarOffice< being owned by the imploding Sun won't hurt OpenOffice.org).   ------------------------------   Date: 23 Oct 2003 20:12:34 GMT6 From: DAVISM@er6.eng.ohio-state.edu (Michael T. Davis)4 Subject: DHCP serving more than one subnet (longish): Message-ID: <bn9cni$kip$1@charm.magnus.acs.ohio-state.edu>  > 	I posted this a short while ago and received a few responses.I I'm hoping that someone has a kind of "cookbook recipe" for this process. ? Since my original posting, we upgraded TCP/IP Services and VMS.    ** updated original posting **    Server Information   ?   Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2 3   on a AlphaServer 800 5/500 running OpenVMS V7.2-2   ;   JOIN Server Release 4.1.0f-DECsrc  for Alpha with OpenVMS H   Copyright 1992-1998 Competitive Automation, Inc.  All Rights Reserved.    Problem  ? 	We recently acquired a /24 subnet (net. mask 255.255.255.0) to D dedicate to our DHCP clients.  We still need to DHCP serve our "old"F subnet, a /22 (net. mask 255.255.252.0).  All of the potential clientsG are on the same physical network segment.  How might I configure things C to allow our VMS system to serve both subnets?  Would I need to get A folks higher up in the support chain (who manage the router which - provides our Internet connectivity) involved?    ** end of original posting **   > 	While we want to maintain DHCP service for the old subnet, weI only need to provide for "permanent" leases there.  We'd like to move all F dynamically assigned IP addresses to the new subnet.  I managed to getC things to almost work, but the DHCP server wouldn't assign a client D system to the old subnet, even if there's a permanent lease assignedH for the system.  (From my testing, it appears that the DHCP server won'tH consider a subnet for service unless the server is configured to provideF at least one IP address from that subnet as a dynamic address; is thisD correct?)  In fact, while the DHCP server doesn't complain about theH specification of the old subnet in its configuration, it doesn't seem toB want to serve out _any_ addresses from it, unless a client alreadyB managed to acquire a lease from the old subnet before the server's configuration is changed.   @ 	FWIW, the information below describes the configuration that atG least approached our goal.  (We use "public" addresses in practice, but E I've specified "private" addresses, here.)  192.168.0.0/22 represents J our old subnet and 192.168.4.0/24 represents our new subnet.  If any otherI information would be helpful, please let me know.  With the configuration J described, below, clients acquire an address, albeit in the 192.168.4.0/24G subnet, even if there's a permanent lease defined for the client in the J 192.168.0.0/22 subnet (as described, above).  For kicks, I tried setting aL permanent lease outside of the IP pool in the new subnet for a client system8 and that worked, but this won't help us in the long-run.  
  NETS file  % 192.168.0.0	192.168.0.5	192.168.2.253 3 192.168.4.0	192.168.0.5	192.168.4.128-192.168.4.254     NETMASKS file   192.168.0.0	255.255.252.0  192.168.4.0	255.255.255.0     DHCPCAP file (two "groups")   fixed:\          :nw=192.168.0.0:\ )         :ds=name-server-1 name-server-2:\          :gw=192.168.0.1:\          :sm=255.255.252.0:\          :ba=192.168.3.255:\          :nt=192.168.0.5:\  	:sv=192.168.0.5:  dhcp:\         :nw=192.168.4.0:\ )         :ds=name-server-1 name-server-2:\          :gw=192.168.4.1:\          :sm=255.255.255.0:\          :ba=192.168.4.255:\          :nt=192.168.4.5:\  	:sv=192.168.4.5:  mynode:\ 	:ht=ether:\ 	:ha=000a27ab9fd6:\  	:ip=192.168.0.15:\  	:tc=fixed:     Interfaces     WE0: (physical interface)F   IP = 192.168.0.5  Netmask = 255.255.252.0  Broadcast = 192.168.3.255   (Gateway = 192.168.0.1)   WEA1: (pseudo-interface) F   IP = 192.168.4.5  Netmask = 255.255.255.0  Broadcast = 192.168.4.255   (Gateway = 192.168.4.1)   L "dhcpdbshow a" reports the following information for a system that we'd likeI to have a permanent lease in the 192.168.0.0/22 (old) subnet ("mynode" in  the above DHCPCAP file):   IP address       192.168.0.15  owner            192.168.0.56 expires          01/18/2038 22:14:07 ("-1" equivalent)$ granted on       10/21/2003 19:56:03$ last modified    10/21/2003 19:56:03 network          192.168.0.0& client id        1,6,00:0a:27:ab:9f:d6  K When this system is booted, it acquires an IP address from the defined pool F in the 192.168.4.0/24 subnet, rather than 192.168.0.15, though various5 options appear to designate the correct (old) subnet:   < ============================================================? 1066932656.894 Packet arrived   on Thursday October 23 14:10:56   ! received on address 192.168.3.255 ; xid=0xbbbd916f secs=0 flags=000000 chaddr=00:0a:27:ab:9f:d6  unpacked payload: F ht=1:ha=00.0a.27.ab.9f.d6:ci=0.0.0.0:gi=0.0.0.0:sa=0.0.0.0:yi=0.0.0.0:K  vm=rfc1048:ho=mynode:lt=1073741823:mm=1500:ct=Mac OS...:ck=01000a27ab9fd6: E  mt=1 (DHCPDISCOVER):rv=1,3,6,15,33,42,44,45,46,47,69,70,71,74,78,79:   < seeking client (1,6,00:0a:27:ab:9f:d6) on subnet 192.168.4.0K DHCPDISCOVER from HW 00:0a:27:ab:9f:d6 : provisional lease on 192.168.4.128    Reply Host structure: C ht=1:ha=00.0a.27.ab.9f.d6:ci=0.0.0.0:gi=192.168.4.5:sa=192.168.4.5: 2  yi=192.168.4.128:sm=255.255.252.0:gw=192.168.0.1:H  ds=name-server-1 name-server-2:ba=192.168.3.255:nt=192.168.0.5:lt=3600:.  sv=192.168.4.5:ct=Mac OS...:mt=2 (DHCPOFFER):< ============================================================B 1066932656.750837 Packet arrived   on Thursday October 23 14:10:56  ! received on address 192.168.3.255 ; xid=0xbbbd916f secs=1 flags=000000 chaddr=00:0a:27:ab:9f:d6  unpacked payload: F ht=1:ha=00.0a.27.ab.9f.d6:ci=0.0.0.0:gi=0.0.0.0:sa=0.0.0.0:yi=0.0.0.0:K  vm=rfc1048:ho=myhost:ip=192.168.4.128:sv=192.168.4.5:mm=1500:ct=Mac OS...: &  ck=01000a27ab9fd6:mt=3 (DHCPREQUEST):1  rv=1,3,6,15,33,42,44,45,46,47,69,70,71,74,78,79:   " client wants address 192.168.4.128 secondary net=192.168.4.0   mask=255.255.255.0    primary_net=192.168.4.0 J DHCPREQUEST(selecting) from HW 00:0a:27:ab:9f:d6 for IP 192.168.4.128: new  lease   Reply Host structure: C ht=1:ha=00.0a.27.ab.9f.d6:ci=0.0.0.0:gi=192.168.4.5:sa=192.168.4.5: 2  yi=192.168.4.128:sm=255.255.252.0:gw=192.168.0.1:H  ds=name-server-1 name-server-2:ba=192.168.3.255:nt=192.168.0.5:lt=3600:<  sv=192.168.4.5:t1=1800:t2=3150:ct=Mac OS...:mt=5 (DHCPACK):< ============================================================  H If the "mynode" entry is removed from DHCPCAP, all of the options servedF to the same client are consistent with the "dhcp" subnet...again, evenN though the permanent lease is given as above (see output from "dhcpdbshow a").  A 	Please, someone tell me what I'm doing wrong, or what it is that   I might be assuming incorrectly.  B 	By the way, now that www.join.com has apparently been assigned toI some purpose other than the support of the JOIN DHCP server, where are we D supposed to find the documentation that used to be referenced there?   Thanks,  Mike --K              Michael T. Davis              |    Systems Specialist: ChE,MSE N   E-mail: davism@er6.eng.ohio-state.edu    | Departmental Networking/ComputingJ            -or- DAVISM+@osu.edu            |     The Ohio State UniversityJ http://www.er6.eng.ohio-state.edu/~davism/ |     197 Watts, (614) 292-6928   ------------------------------  # Date: Thu, 23 Oct 2003 21:43:22 GMT < From: "John E. Malmberg" <Malmberg@dskwld.zko.dec.compaq.hp>8 Subject: Re: DHCP serving more than one subnet (longish)2 Message-ID: <_XXlb.7723$Rd6.6703@news.cpqcorp.net>   Michael T. Davis wrote: @ > 	I posted this a short while ago and received a few responses.K > I'm hoping that someone has a kind of "cookbook recipe" for this process. A > Since my original posting, we upgraded TCP/IP Services and VMS.  >   > ** updated original posting ** >  >  Server Information  > A >   Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2 5 >   on a AlphaServer 800 5/500 running OpenVMS V7.2-2  > = >   JOIN Server Release 4.1.0f-DECsrc  for Alpha with OpenVMS J >   Copyright 1992-1998 Competitive Automation, Inc.  All Rights Reserved. > 
 >  Problem > A > 	We recently acquired a /24 subnet (net. mask 255.255.255.0) to F > dedicate to our DHCP clients.  We still need to DHCP serve our "old"H > subnet, a /22 (net. mask 255.255.252.0).  All of the potential clientsI > are on the same physical network segment.  How might I configure things E > to allow our VMS system to serve both subnets?  Would I need to get C > folks higher up in the support chain (who manage the router which / > provides our Internet connectivity) involved?  >  > ** end of original posting **  > @ > 	While we want to maintain DHCP service for the old subnet, weK > only need to provide for "permanent" leases there.  We'd like to move all H > dynamically assigned IP addresses to the new subnet.  I managed to getE > things to almost work, but the DHCP server wouldn't assign a client F > system to the old subnet, even if there's a permanent lease assigned > for the system.   F I have not worked with such things for at least three years now, so I & could have some of the concepts wrong.  D Even if all the addresses are on one physical link, if you have two D discontigous subnets, all packets between them need to go through a H router.  The configuration is sometimes called a router on a stick, and I it doubles the amount of traffic on the segment any time that systems in  E the two subnets need to communicate with each other.  If they do not  = need to communicate with each other, then everything is fine.   ? Now the DHCP server needing to serve both subnets is a problem.   I And I could very well be mistaken on this, but from what I can remember,  H when a DHCP server is handling two subnets, it expects one subnet to be C behind a router.  When the router forwards the DHCP packets (not a  G default configuration) to the DHCP server, this is what tells the DHCP  I server what subnet to allocate the addresses from, because it knows that  G it came from the router.  As I was not doing this, I did not study the   techniques in detail.   G But with both subnets on the same segment as the DHCP server, the DHCP  H broadcast packets are going directly between the client and the server, F and even if the router was also relaying them, it would lose the race  with the direct packets.  E DHCP clients do not know their subnet until after they have received  H that information from the DHCP server once.  After they get an address, F they will continue to ask for it from the same DHCP server, and since I they will be using their designated address to make the request, it will    go through the router if needed.  9 > (From my testing, it appears that the DHCP server won't J > consider a subnet for service unless the server is configured to provideH > at least one IP address from that subnet as a dynamic address; is thisF > correct?)  In fact, while the DHCP server doesn't complain about theJ > specification of the old subnet in its configuration, it doesn't seem toD > want to serve out _any_ addresses from it, unless a client alreadyD > managed to acquire a lease from the old subnet before the server's > configuration is changed.   H My guess is that you have set the old subnet to go through a router and 2 back to your segment, and the new subnet does not.  G Since all the new DHCP requests come in directly, they get sent to the   DHCP zone for the new subnet.   E Renewals use the I.P. and subnet they were issued, so they go to the   expected place.   F There may be a way to do what you want, but it would require studying @ the rules for DHCP assignment much closer than what I have done.  I It probably involves making the DHCP server think that all the addresses  A are in one larger subnet, but to give out to the fixed addresses  C different information than for the dynamic ones for the subnet and   network masks.  D And I do not know if the DHCP server you are using has that ability H because I never had to study that when I used to work with DHCP servers.   > D > 	By the way, now that www.join.com has apparently been assigned toK > some purpose other than the support of the JOIN DHCP server, where are we F > supposed to find the documentation that used to be referenced there?  D I have no idea what the JOIN DHCP server is or what the URL is, and & never heard of it before your posting.  
 Good luck, -John ! malmberg@dskwld.zko.dec.compaq.hp  Personal Opinion Only    ------------------------------  + Date: Thu, 23 Oct 2003 22:17:13 +0000 (UTC) ? From: Graham Burley <burley.not-this@encompasserve-or-this.org> 8 Subject: Re: DHCP serving more than one subnet (longish)9 Message-ID: <3F986062.4A413E9F@encompasserve-or-this.org>    Michael T. Davis wrote:  >  [snip]  H >         We recently acquired a /24 subnet (net. mask 255.255.255.0) toF > dedicate to our DHCP clients.  We still need to DHCP serve our "old"H > subnet, a /22 (net. mask 255.255.252.0).  All of the potential clientsI > are on the same physical network segment.  How might I configure things 0 > to allow our VMS system to serve both subnets?  F I don't think you can. For DHCP to allocate an address to a network itD needs to be able to identify the packet as coming from that network.B This is done by inspecting the BOOTP relay address recorded in theD packet. If the client is on the same physical network then the relay address is clear (0.0.0.0).    [snip]    
 > mynode:\ >         :ht=ether:\  >         :ha=000a27ab9fd6:\ >         :ip=192.168.0.15:\ >         :tc=fixed: >   B Here mynode is a BOOTP configuration since it specifies a hardwareF address, you have to explicitly enable BOOTP support for this to work.    
 >  Interfaces  >  >  WE0: (physical interface)H >   IP = 192.168.0.5  Netmask = 255.255.252.0  Broadcast = 192.168.3.255 >   (Gateway = 192.168.0.1)  >  WEA1: (pseudo-interface) H >   IP = 192.168.4.5  Netmask = 255.255.255.0  Broadcast = 192.168.4.255 >   (Gateway = 192.168.4.1)    Same physical network.   [snip]  > > ============================================================A > 1066932656.894 Packet arrived   on Thursday October 23 14:10:56  > # > received on address 192.168.3.255 = > xid=0xbbbd916f secs=0 flags=000000 chaddr=00:0a:27:ab:9f:d6  > unpacked payload: H > ht=1:ha=00.0a.27.ab.9f.d6:ci=0.0.0.0:gi=0.0.0.0:sa=0.0.0.0:yi=0.0.0.0:  # gi = relay = 0.0.0.0 = local subnet    [snip]     Graham   ------------------------------  % Date: Thu, 23 Oct 2003 13:30:19 -0500 / From: Chris Scheers <chris@applied-synergy.com> ( Subject: Re: Dial-out PPP on GS140e/84003 Message-ID: <3F981E3B.401D8C60@applied-synergy.com>    Bob Baxter wrote: F > 1.  It doesn't look like there is a serial port included with a baseD > 8400/GS140e.  If we add a KFE72-BA, would this provide us with theD > serial port we need for a dial-out modem?  Anyone have other ideas( > about adding a serial port to an 8400?  G In general, I would recommend using a terminal server instead of adding F ports.  There are various reasons for this, but two of the biggies areH that multiple machines can share a terminal server and you don't have to8 rethink your serial cabling if you upgrade your machine.  G I don't know what would be the best server for your particular problem, ; but you might start by looking at the DECserver 700 family.   
 Good luck!  G ----------------------------------------------------------------------- $ Chris Scheers, Applied Synergy, Inc.  C Voice: 817-237-3360            Internet: chris@applied-synergy.com     Fax: 817-237-3074    ------------------------------  % Date: Thu, 23 Oct 2003 13:32:20 -0500 / From: Chris Scheers <chris@applied-synergy.com> ( Subject: Re: Dial-out PPP on GS140e/84003 Message-ID: <3F981EB4.6EDA536D@applied-synergy.com>    Bob Baxter wrote: F > 1.  It doesn't look like there is a serial port included with a baseD > 8400/GS140e.  If we add a KFE72-BA, would this provide us with theD > serial port we need for a dial-out modem?  Anyone have other ideas( > about adding a serial port to an 8400?  G In general, I would recommend using a terminal server instead of adding F ports.  There are various reasons for this, but two of the biggies areH that multiple machines can share a terminal server and you don't have to8 rethink your serial cabling if you upgrade your machine.  G I don't know what would be the best server for your particular problem, ; but you might start by looking at the DECserver 700 family.   
 Good luck!  G ----------------------------------------------------------------------- $ Chris Scheers, Applied Synergy, Inc.  C Voice: 817-237-3360            Internet: chris@applied-synergy.com     Fax: 817-237-3074    ------------------------------  # Date: Thu, 23 Oct 2003 21:00:14 GMT " From:   VAXman-  @SendSpamHere.ORGN Subject: Re: DNPG products also through a partner (was: DNPG - No DEC anymore)0 Message-ID: <00A27D0F.983F7825@SendSpamHere.ORG>  g In article <f496ee6a.0310221833.41108488@posting.google.com>, majikas@dnpg.com (Dennis Majikas) writes: G >Digital Networks (aka DNPG) is alive and well. We are still designing, C >shipping and supporting the DECserver products. Most of the legacy G >products (MS900, GIGAswitch/FDDI, etc.) are distributed through Vnetek F >Communications. We are in the same building, and we still answer many; >questions about the legacy DNPG products on a daily basis.  > 	 >Regards,  >  >Dennis Majikas  >Digital Networks 
 >603-216-6026   J It would be *nice* if there was away to find these products at either siteJ you've mentioned.  If I can't find them, I must assume you've discontinuedJ them...  The search functions on both sitea do not return any links to the1 items I've queried to know if they still exist.      Can't find it, can't buy it!   --  L VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)COM             5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  % Date: Thu, 23 Oct 2003 20:13:28 +0200  From: Dirk Munk <munk@home.nl>  Subject: EV79 CANCELED !!!!!!!!!2 Message-ID: <bn95r9$b07$1@news4.tilbu1.nb.home.nl>  2 Take a deep breath Bill, and 10 tablets of Valium.  O Today we had some HP reps visiting us to teel us about Alpha, Tru64 Linux etc.  M They told us that about two weeks ago it was decided NOT to produce the EV79. B The reason they gave us is that "IBM can not produce the chip" !?!  P Most likely the Sahara is covered in 10 feet of snow and ice, so that IBM can't 8   dig enough sand to produce the silicon for the wafers.   ------------------------------  % Date: Thu, 23 Oct 2003 20:26:49 +0200  From: Dirk Munk <munk@home.nl>$ Subject: Re: EV79 CANCELED !!!!!!!!!2 Message-ID: <bn96k9$acl$1@news1.tilbu1.nb.home.nl>   Dirk Munk wrote:4 > Take a deep breath Bill, and 10 tablets of Valium. > F > Today we had some HP reps visiting us to teel us about Alpha, Tru64 I > Linux etc. They told us that about two weeks ago it was decided NOT to   > produce the EV79. D > The reason they gave us is that "IBM can not produce the chip" !?! > H > Most likely the Sahara is covered in 10 feet of snow and ice, so that C > IBM can't  dig enough sand to produce the silicon for the wafers.  >  Sorry, I forgot something.  L There will be a EV7z, that is about 15% faster then the present EV7 (higher  clock rate).   ------------------------------  % Date: Thu, 23 Oct 2003 20:44:57 +0200 $ From: Michael Unger <unger@decus.de>$ Subject: Re: EV79 CANCELED !!!!!!!!!9 Message-ID: <bn97sb$u0dq3$1@ID-152801.news.uni-berlin.de>   ' On 2003-10-23 20:13, "Dirk Munk" wrote:   4 > Take a deep breath Bill, and 10 tablets of Valium.  1 I don't think just 10 tablets would be enough ...   Q > Today we had some HP reps visiting us to teel us about Alpha, Tru64 Linux etc.  O > They told us that about two weeks ago it was decided NOT to produce the EV79. D > The reason they gave us is that "IBM can not produce the chip" !?!  E Wasn't the reason to sell the own (Digital) fab to allow for multiple E sources of chips? Can't Intel, Motorola, Texas Instruments -- to name - just a few "major players" -- produce either?   R > Most likely the Sahara is covered in 10 feet of snow and ice, so that IBM can't : >   dig enough sand to produce the silicon for the wafers.  @ Usually chip makers don't produce the silicon wafers themselves.4 (Wacker, e.g., is one of the major wafer suppliers.)   Michael    --  ; Real names enhance the probability of getting real answers. @ Please do *not* send "Security Patch Notifications" or "SecurityA Updates"; this system isn't running a Micro$oft operating system. = And don't annoy me <mailto:postmaster@[127.0.0.1]> please ;-)    ------------------------------  % Date: Thu, 23 Oct 2003 12:09:39 -0700 + From: "Barry Treahy, Jr." <Treahy@MMaz.com> $ Subject: Re: EV79 CANCELED !!!!!!!!!% Message-ID: <3F982773.20401@MMaz.com>    Dirk Munk wrote:  4 > Take a deep breath Bill, and 10 tablets of Valium. > F > Today we had some HP reps visiting us to teel us about Alpha, Tru64 I > Linux etc. They told us that about two weeks ago it was decided NOT to   > produce the EV79. D > The reason they gave us is that "IBM can not produce the chip" !?!  = Can't or don't want to, due to lack of economic incentive or  H rustication?  With IBM's technical abilities, I seriously doubt it is a  lack of ability.   Barry    --    > Barry Treahy, Jr                       E-mail: Treahy@MMaz.com> Midwest Microwave                          Phone: 480/314-1320> Vice President & CIO                         FAX: 480/661-7028                            ------------------------------  % Date: Thu, 23 Oct 2003 14:46:19 -0400 * From: "Bill Todd" <billtodd@metrocast.net>$ Subject: Re: EV79 CANCELED !!!!!!!!!2 Message-ID: <ZfCdnYWLuPZovAWiU-KYiQ@metrocast.net>  + "Dirk Munk" <munk@home.nl> wrote in message , news:bn96k9$acl$1@news1.tilbu1.nb.home.nl... > Dirk Munk wrote:6 > > Take a deep breath Bill, and 10 tablets of Valium.  L No need:  The Inquirer broke the story a few days ago - and it really didn'tL come as a great surprise, given how much HP had gutted EV79 already (so muchH for its repeated promises to stick with its 'plan of record', but we all+ know what a promise from cHumPaq is worth).    > > G > > Today we had some HP reps visiting us to teel us about Alpha, Tru64 J > > Linux etc. They told us that about two weeks ago it was decided NOT to > > produce the EV79. F > > The reason they gave us is that "IBM can not produce the chip" !?! > > I > > Most likely the Sahara is covered in 10 feet of snow and ice, so that E > > IBM can't  dig enough sand to produce the silicon for the wafers.   I Indeed.  IBM is having so much difficulty with SOI that AMD has partnered H with it to advance this technology.  Just because it's producing POWER4+H cores that use half the power of Itanics while clocking faster shouldn'tJ fool anyone into believing that they have a clue about what they're doing.   > >  > Sorry, I forgot something. > E > There will be a EV7z, that is about 15% faster then the present EV7  (higher  > clock rate).  J Ah - I guess HP figures that with Madison out it's now safe to release EV7I at the speed it should have had right from the start (though clearly they K don't want to have comparisons made with even an emasculated EV79:  must be ) that 'Heloise and Abelard' thingy again).    - bill   ------------------------------  % Date: Thu, 23 Oct 2003 14:45:45 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>$ Subject: Re: EV79 CANCELED !!!!!!!!!( Message-ID: <3F9821D4.DA7B796@istop.com>   Dirk Munk wrote:M > There will be a EV7z, that is about 15% faster then the present EV7 (higher  > clock rate).  H So much for "commitments", "road maps", "plan of record". A company thatL should have been working to build trust is doing everything it can to worsen the situation.  N Since HP had not commited to performance for EV79, it could have just producedA an EV79 that was just 15% faster then EV7 and still call it EV79.   I But by officially cancelling EV79, HP has shot itself in the foot, mouth, $ brain and where the sun don't shine.  L Such moves to prevent Alpha to have its last hurrah also lead one to believeK that HP knows full well that IA64 isn't up to snuff and that it must muzzle - other chips so that IA64 doesn't look so bad.   I Honesty and trust are qualities customers wnat from an enterprise vendor.   I HP should have allowed, no, it should have PUSHED EV7 and EV79 to go full L speed and take full advantage of its technological edge while IA64 was still young and unimpressive.   J An honest HP could have simply said that yes, Alpha's last hurrah was veryJ very fast, but produce a graph showing that IA64 was coming up faster than# Alpha and would syurpass it "soon".   K Clearly, HP has taken moves to protect the image of Carly instead of taking L moves to maximise profitys from its existing assets. How much did they spendM to buy Compaq ? They should have made full leverage of those assets that they = got (ex Tandem and Digital assets since Compaq had no assets)    ------------------------------  % Date: Thu, 23 Oct 2003 15:27:35 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>$ Subject: Re: EV79 CANCELED !!!!!!!!!( Message-ID: <3F982B9F.1792625@istop.com>   "Barry Treahy, Jr." wrote:> > Can't or don't want to, due to lack of economic incentive orI > rustication?  With IBM's technical abilities, I seriously doubt it is a  > lack of ability.  J IBM is just the FAB. If IBM can fab EV7z, they could fab EV79. IBM is just* given the specs and it produces the chips.  K It is clear that HP doesn't want to spend the money tyo do a proper shrink, J which would require HP workers to do design work, testing, evaluation etc.  C It seems more likely now that EV7 was designed to be 15% faster and I artificially slowed down, and now HP will just remove the 15% restriction K which won't require much of engineering work at HP to get done since it was 
 already done.   L One thing this may say though is that the market for Alphas has really dried= up and that HP can't justify spending more money on the chip.   K On the other hand, because of HP's bad image, it just looks like HP doesn't N want Alpha to continue to surpass IA64, making the decision to go to IA64 look	 very bad.   K The fact that some customers would think the real reason is to preserve the L image of IA64 should matter a lot to HP because it says a lot about how muchN distrust customers have in HP even if there might be some justified reason for
 the decision.    ------------------------------  + Date: Thu, 23 Oct 2003 21:09:18 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) $ Subject: Re: EV79 CANCELED !!!!!!!!!( Message-ID: <bn9g1u$s07$1@pcls4.std.com>  , "Bill Todd" <billtodd@metrocast.net> writes:    7 >"Barry Treahy, Jr." <Treahy@MMaz.com> wrote in message   >news:3F982773.20401@MMaz.com... >> Dirk Munk wrote:  >>7 >> > Take a deep breath Bill, and 10 tablets of Valium.  >> >H >> > Today we had some HP reps visiting us to teel us about Alpha, Tru64K >> > Linux etc. They told us that about two weeks ago it was decided NOT to  >> > produce the EV79.G >> > The reason they gave us is that "IBM can not produce the chip" !?!   D The supposed reason is that EV79 would have been only a few % fasterF than the EV7z (whatever that is), and is not worth it for such a small
 increment.  M >It's just the "Alpha development was too expensive" and "Alpha couldn't have M >kept ahead of Itanic" and "EV8 was going to take a 1 GHz performance hit due F >to SMT" and "the Alpha *engineers* told us this" crap all over again:  C Ummm, EV8 was dead and buried even before HP came into the picture. E As to performance, haven't the INTC chips passed Alpha a while back?  & ("1 gigahertz? That's so Windows 98!")       -- e -Mike    ------------------------------  % Date: Thu, 23 Oct 2003 16:37:06 -0400 * From: "Bill Todd" <billtodd@metrocast.net>$ Subject: Re: EV79 CANCELED !!!!!!!!!2 Message-ID: <tY2dnb1X-IRwpgWiU-KYuQ@metrocast.net>  6 "Barry Treahy, Jr." <Treahy@MMaz.com> wrote in message news:3F982773.20401@MMaz.com...o > Dirk Munk wrote: >r6 > > Take a deep breath Bill, and 10 tablets of Valium. > > G > > Today we had some HP reps visiting us to teel us about Alpha, Tru64EJ > > Linux etc. They told us that about two weeks ago it was decided NOT to > > produce the EV79.!F > > The reason they gave us is that "IBM can not produce the chip" !?! >C> > Can't or don't want to, due to lack of economic incentive orI > rustication?  With IBM's technical abilities, I seriously doubt it is a  > lack of ability.  J Er, you don't actually believe that *IBM* is the problem, do you?  They'reK actively looking for things to fab at Fishkill, and were all set to do EV79i there.  L It's just the "Alpha development was too expensive" and "Alpha couldn't haveL kept ahead of Itanic" and "EV8 was going to take a 1 GHz performance hit dueE to SMT" and "the Alpha *engineers* told us this" crap all over again:PD surely you don't *trust* anything cHumPaq says?  After all, they hadI *already* gutted the EV79 'plan of record' that they promised solemnly toI< adhere to to string customers along for another year or two.  G cHumPaq lies - deliberately, and right to your face - whenever it suitsp5 them.  Learn to live with it, or find another vendor.c   - bill   ------------------------------  % Date: Fri, 24 Oct 2003 01:00:19 +0200n From: Dirk Munk <munk@home.nl>$ Subject: Re: EV79 CANCELED !!!!!!!!!2 Message-ID: <bn9mks$3qj$1@news1.tilbu1.nb.home.nl>   Michael Moroney wrote:. > "Bill Todd" <billtodd@metrocast.net> writes: >  >  > 8 >>"Barry Treahy, Jr." <Treahy@MMaz.com> wrote in message! >>news:3F982773.20401@MMaz.com...f >> >>>Dirk Munk wrote:  >>>f >>>e6 >>>>Take a deep breath Bill, and 10 tablets of Valium. >>>>G >>>>Today we had some HP reps visiting us to teel us about Alpha, Tru64aJ >>>>Linux etc. They told us that about two weeks ago it was decided NOT to >>>>produce the EV79.rF >>>>The reason they gave us is that "IBM can not produce the chip" !?! >  > F > The supposed reason is that EV79 would have been only a few % fasterH > than the EV7z (whatever that is), and is not worth it for such a small > increment.  P I don't get this. The EV79 was suppose to be a EV7 build with new manufacturing Q technology, meaning a smaller die etc. Normally a smaller die means higher clock S@ speeds and thus more performance. Not so with the EV79? Why not?  N These Alpha engineers must be so stupid and clumsy that you can only use them / for very unimportant projects like the Itanium.>   >  > N >>It's just the "Alpha development was too expensive" and "Alpha couldn't haveN >>kept ahead of Itanic" and "EV8 was going to take a 1 GHz performance hit dueG >>to SMT" and "the Alpha *engineers* told us this" crap all over again:- >  > E > Ummm, EV8 was dead and buried even before HP came into the picture.hG > As to performance, haven't the INTC chips passed Alpha a while back? C( > ("1 gigahertz? That's so Windows 98!") >  >  >    ------------------------------  % Date: Thu, 23 Oct 2003 19:16:01 -0400w) From: "Neil Rieck" <n.rieck@sympatico.ca>.$ Subject: Re: EV79 CANCELED !!!!!!!!!: Message-ID: <SiZlb.18835$XO.1049346@news20.bellglobal.com>  ' This was sent to me in a recent e-mail:f  M ...HP elected to make some changes to the Alpha end game. To reduce costs andmN speed delivery of the microprocessortime to market apparently was becoming anL issueHP decided not to subject EV7 to a drastic overhaul, but to shrink theN incumbent chip, crank the clock to about 1.3GHz, give the CPU a new nameEV7z,L perhapsand deliver it as scheduled next year with a performance improvement of ~15 percent. Well see...  K If this author is correct, it looks like HP will literally "just shrink the3D die" but won't tweak the layout as is required in a true die-shrink.  	 * * * * *   ' This was sent to me in a recent e-mail:f  I HP chose not to publish performance figures on the new 64-way AlphaServersE GS1280, but GS1280 customers have experienced substantial performance G improvements on 16-way and 32-way GS1280s vis-a-vis equivalent Wildfirep systems.  	 * * * * *t  L Now couple the above news items and you begin to see a bigger picture. It isN my belief that the 64-cpu Itanium2 machine is junk when compared to the 64-cpuM Alpha. Allowing EV7 to be developed into EV79 would only hurt future sales ofsI their Itanium2 machines. By shrinking the die without tweaking the layouttJ (EV7z), they will get a modest improvement for the least amount of effort.  M (ps. for anyone who thinks that cancelling EV79 is no big deal, check out thelM following chart http://h18002.www1.hp.com/alphaserver/a-chart.html then slidebH down to the third chart which compares an "DS20E EV67/667" with a "DS20EM EV68/833". The EV68 has a clock running only 24% faster than the EV67 but theo SpecWeb99 test runs 85% better)   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/    ------------------------------  % Date: Thu, 23 Oct 2003 19:38:15 -0400n) From: "Neil Rieck" <n.rieck@sympatico.ca>0$ Subject: Re: EV79 CANCELED !!!!!!!!!9 Message-ID: <GDZlb.7780$7t3.307666@news20.bellglobal.com>i  + "Dirk Munk" <munk@home.nl> wrote in message , news:bn9mks$3qj$1@news1.tilbu1.nb.home.nl... > Michael Moroney wrote:
 ...snip... >5C > I don't get this. The EV79 was suppose to be a EV7 build with newo
 manufacturingtL > technology, meaning a smaller die etc. Normally a smaller die means higher clocksB > speeds and thus more performance. Not so with the EV79? Why not? >sJ > These Alpha engineers must be so stupid and clumsy that you can only use them1 > for very unimportant projects like the Itanium.I >r  H People throw around the term "die shrink" loosely but it really means isJ "shrink the mask" and "tweak the mask" (shorten lines here, lengthen linesN there, widen power lines in places, etc. What HP will want the engineers to doJ to produce "EV7z" is just "shrink the mask" and "increase the clock" untilN something breaks. Then they would probably expand the mask by 10% to give themM some kind of margin of error. This isn't engineering, it's closer to hacking.t2 What an uninteresting way to end the Alpha legacy.  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/    ------------------------------  # Date: Fri, 24 Oct 2003 00:04:04 GMTa& From: Rick Jones <foo@bar.baz.invalid>$ Subject: Re: EV79 CANCELED !!!!!!!!!2 Message-ID: <U%Zlb.7727$em6.3216@news.cpqcorp.net>  ( Neil Rieck <n.rieck@sympatico.ca> wrote:A > (ps. for anyone who thinks that cancelling EV79 is no big deal,c > check out the following chartnD > http://h18002.www1.hp.com/alphaserver/a-chart.html then slide downE > to the third chart which compares an "DS20E EV67/667" with a "DS20E"B > EV68/833". The EV68 has a clock running only 24% faster than the. > EV67 but the SpecWeb99 test runs 85% better)  D If you go to http://www.spec.org/ and pull-up the details of the two@ results, you can see that there was a _lot_ more than just a CPUD change there. Between April 2000 when the first of the two SPECweb99C results was published on the DS20E EV67/667, and December 2001 when.D the second was published on the DS20E EV68/833, the changes include:   *) Zeus 3.3.5 to Zeus 4.0r1  *) CLF logging to Binary format $ *) Tru64 4.0F to  Tru64 V5.1A Spiked *) 2GB of RAM to 4GB of RAM  *) 6 disc mechanisms to 14  E That is _way_ too many changes to allow one to draw conclusions about.$ the importance of processor changes.  
 rick jones -- PB firebug n, the idiot who tosses a lit cigarette out his car windowF these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...9   ------------------------------  % Date: Thu, 23 Oct 2003 20:58:07 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>$ Subject: Re: EV79 CANCELED !!!!!!!!!) Message-ID: <3F987915.6EA19A49@istop.com>    Neil Rieck wrote:.N > issueHP decided not to subject EV7 to a drastic overhaul, but to shrink theP > incumbent chip, crank the clock to about 1.3GHz, give the CPU a new nameEV7z,N > perhapsand deliver it as scheduled next year with a performance improvement > of ~15 percent. Well see..r  J Will the "z" actually shrink to a new process, or will they just crank theI clock up to what EV7 is capable of supporting since it was designed to bea! faster than what it was sold as ?o  O > Alpha. Allowing EV7 to be developed into EV79 would only hurt future sales of  > their Itanium2 machines.    N Alpha only eats into VMS and possibly Linux sales with a few Tru64 sales left.M And Alpha doesn't "steal" any sales for HP because any profits still go to HP1# because Alpha is now an HP product.1  N HP shareholders should have Carly shot for purposefully cannabalising an assetL that would allow HP to remain a winner while the very long bridge to IA64 isH being crossed.  If IA64's performance isn't so stellar, HP would be muchD better off selling a stellar Alpha than to lose sales to IBM or Sun.  E And for HP, it would be politically easy to have permitted the last 23M iteration of Alpha to be at their maximum potential even it it made IA64 look0M pale.  They were, after all, only honouring promises made by Compaq. And theyiL could then turn to Intel and complain about Intel not fulfilling promises ofX an IA64 beingt the world'Ms fastest chip by 1999 or whenever it was originally expected.  7 It isn't HP's job to make Intel or Microsoft look good.:   ------------------------------    Date: 23 Oct 2003 19:48:54 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)s$ Subject: Re: EV79 CANCELED !!!!!!!!!= Message-ID: <cf15391e.0310231848.56b59a1b@posting.google.com>m  X Dirk Munk <munk@home.nl> wrote in message news:<bn95r9$b07$1@news4.tilbu1.nb.home.nl>...O > They told us that about two weeks ago it was decided NOT to produce the EV79.=D > The reason they gave us is that "IBM can not produce the chip" !?!  B HP has acted in good faith on what was laid out in the Roadmaps itD inherited from Compaq.  EV7 chip development was continued, the chipE was completed, and great systems using that chip developed, which are0D available today. The OpenVMS port to Itanium has continued and is onE schedule. Some things the Roadmaps originally excluded have even been=D added to the Roadmaps based on customer requests, like the new DS15.@ Here we see one case where things didn't go as well as expected.F Sometimes things just don't work out as well as you had hoped, and youF must do the best with the hand that is dealt you, and make the best ofE things. In this case, the performance boost in 2004 is not as high as.D anticipated, but increased performance will be available at the same price.  # Here's a Q&A covering the decision:    AlphaServer Roadmap Q&A3  : Q: What progress has HP made to date on the Alpha roadmap?  B A: A great deal of progress has been made to date.  In January, weF introduced the next generation of AlphaServer systems based on the newE EV7 Alpha processor. The new AlphaServer family includes the high-endiD GS1280 enterprise server, the ES80 departmental server, and the ES47A workgroup systems.  HP began shipping in August, on schedule, the A 32-processor HP AlphaServer GS1280.  In October, we will ship theeF latest products in the roadmap: the 64-processor HP AlphaServer GS1280F and the new entry-level system, the AlphaServer DS15, which takes fullC advantage of the powerful 1-gigahertz Alpha processor running Tru64 ? UNIX or OpenVMS.  The next update to the EV7 Alpha processor ise scheduled for mid-2004.|    C Q:  What is the status update to the AlphaServer roadmap in 2004?     A A:  In mid-2004, HP plans to release, as scheduled, a performancedC boost to the EV7 Alpha processor.  We originally planned to deliver-F this performance boost via a new chip, which we have been referring to? as EV79.  As the project progressed, it became clear in workingoD closely with our CPU chip supplier that the EV79 chip would not meet3 our expectations for performance or time to market.h  B However, the manufacturing process maturity for EV7 has progressedD very well, producing good yield and making it possible to produce anB EV7 part (EV7z at 1.33GHz) with significantly improved performanceB over our current EV7.  The EV7z coupled with faster memory upgradeC will allow us to deliver a 14% - 16% performance improvement withinA1 the timeframe that we committed to our customers.   F Therefore, we have made the decision to provide our customers with theC performance improvements that we had committed based on EV7z rather = than EV79.  We believe this will meet our customers' needs by5E delivering the upgrade on time and introducing a performance boost atP$ the same price as EV7-based systems.    4 Q: Who was the scheduled supplier of the EV79 chips?  4 A: The supplier is the same as the current EV7 chip.   	eE Q: When are the enhancements to the Alpha EV7 systems scheduled to bed	 released?   A A: We remain on schedule to meet our 2nd half of 2004 commitment.     @ Q: Will customers be able to add EV7z CPUs to existing Alpha EV7 systems?  ? A: Yes, customers will be able to add EV7z CPUs to existing EV7nC systems.  If the faster EV7z CPUs are in a separate hard partition,kD they will run at the higher clock speed.  If the EV7z CPUs are mixed; with EV7 CPUs in a hard partition, the EV7z processors willvA automatically run at the lower EV7 clock speed in that partition.h   ------------------------------  # Date: Fri, 24 Oct 2003 02:52:57 GMT # From: "John Smith" <a@nonymous.com>e$ Subject: Re: EV79 CANCELED !!!!!!!!!J Message-ID: <du0mb.263344$ko%.215725@news04.bloor.is.net.cable.rogers.com>   Dirk Munk wrote:4 > Take a deep breath Bill, and 10 tablets of Valium. >gE > Today we had some HP reps visiting us to teel us about Alpha, Tru64kE > Linux etc. They told us that about two weeks ago it was decided NOTyC > to produce the EV79. The reason they gave us is that "IBM can nott > produce the chip" !?!m >cG > Most likely the Sahara is covered in 10 feet of snow and ice, so thatdD >   IBM can't dig enough sand to produce the silicon for the wafers.     found at9 http://www.openvms.org/stories.php?story=03/10/23/1052724a  
 Rich Marcellos' Senior Vice President & General Managerr& Business Critical Servers Product Line     15 October 2003e     Dear Valued HP Customer,    I Since January, HP's Business Critical Servers product line has achieved adK number of significant milestones toward our strategy of creating innovativedE products and solutions that provide you with the lowest total cost oftH ownership, with better choice and flexibility, and assured stability andJ security where it matters most in your business. These milestones include:    L . Launching the HP Integrity servers which have moved Itanium-based systemsJ into the mainstream, backed by more than 1000 applications from major ISVs to date;6 . Shipping HP-UX 11i v2 full enterprise-class release;G . Introducing OpenVMS V8.0 Evaluation Release for HP Integrity servers;iC . Previewing TruCluster technology and Advanced File System (AdvFS), capabilities on HP-UX;H . Providing unprecedented customer commitment with the Alpha RetainTrust program;J . Achieving world leading Windows/SQL performance on HP Integrity servers; and,K . With Oracle, setting the transaction processing world record to break the? 800K barrier at 824,164 tpmC    K In keeping with HP's on-going effort to communicate strategy updates to youaK in a timely manner, I want to make you aware of recent updates to the HP-UX  11i v3 and Alpha roadmaps.    I First let me say that we are committed to bringing the leading enterprisecL UNIX capability to market delivered across our PA-RISC and Itanium-based HPF Integrity server platforms. Planned functionality for HP-UX 11i v3 hasE remained consistent since the merger and in fact, the Engineering labnJ demonstrated proof-of-concept for TruCluster technology and AdvFS on HP-UXL in June. In addition, we plan to deliver vPars dynamic partitioning in HP-UXJ 11i v3, thus enhancing our partitioning continuum on HP Integrity servers.I We are delivering breakthrough functionality and continuing to make HP-UXn  11i the leader of the UNIX pack.    L While significant progress has been made to date on this next major release,L we have come to realize that the effort and time required to complete and toL deliver a top quality HP-UX 11i v3 operating system will extend the scheduleI from our original goal of the end of CY2004 to the 2nd half of CY2005. To,A meet this new timeline, we have increased the investment in HP-UXoI solidifying the commitment to the capabilities that will uniquely deliverd( leadership UNIX return on IT investment.    G Additionally, part of the Alpha commitment was to deliver a performance G boost to EV7-based AlphaServer systems in 2004 based on a new chip, the K EV79. As the EV79 process has progressed, working closely with our CPU chip-B supplier, it has become clear that the EV79 chip will not meet ourL expectations for performance or time to market. Given this, we have made theJ decision to provide you with performance improvements based on EV7z ratherF than EV79. We believe this will still meet your needs by introducing aI performance boost of 14-16% at the same price as EV7-based systems and ine the same timeframe.i    K The PA-RISC, OpenVMS, and Tru64 UNIX roadmaps are unaffected and remain on2 track.    H In closing, be assured that we at HP continue to honor our commitment toJ bring you clear roadmap directions and proven technology results that willD help you drive real business results. Please feel free to contact meL directly if you would like to discuss these updates further. I thank you for your continued business.    
 Sincerely,      
 Rich Marcelloe   ==============   ------------------------------  % Date: Fri, 24 Oct 2003 00:29:25 -0400.* From: JF Mezei <jfmezei.spamnot@istop.com>$ Subject: Re: EV79 CANCELED !!!!!!!!!) Message-ID: <3F98AA90.E184BCC8@istop.com>    Keith Parris wrote:eD > HP has acted in good faith on what was laid out in the Roadmaps it > inherited from Compaq.  J You're allowed to believe that. But you have to understand that others are  also allowed to disbelieve this.  / >  EV7 chip development was continued, the chip2G > was completed, and great systems using that chip developed, which are1 > available today.  J Lets not forget the rumours that EV7 was ready well before it was actuallyN released, with much speculation that HP didn't want to release EV7 before IA64L so that IA64 could have its 15 seconds of fame before it was outperformed by Alpha.    J And then, when EV7 was allowed out, its performance was less than had been
 anticipated. a  5 > The OpenVMS port to Itanium has continued and is ond > schedule.g   Very few doubt this. .  A > as EV79.  As the project progressed, it became clear in working F > closely with our CPU chip supplier that the EV79 chip would not meet5 > our expectations for performance or time to market.u  L If their expectations were that IA64 would outperform Alpha, then of course,* the EV79 wouldn't meet their expectations.  D > However, the manufacturing process maturity for EV7 has progressedF > very well, producing good yield and making it possible to produce anD > EV7 part (EV7z at 1.33GHz) with significantly improved performance > over our current EV7.8  M So, what this means is that EV7 won't even need any changes, they'll just use M a faster clock. And it may also mean that EV7 was purposefully given a slowerlN clock, and now, instead of doing EV79, they are just going to remove the speed  restriction they had put on EV7.  K Sorry of I appear sceptical, but it was up to Comapq and HP to work hard tol  regain trust, which they didn't.  H > Therefore, we have made the decision to provide our customers with theE > performance improvements that we had committed based on EV7z ratherS > than EV79.  J Reminds me of stores who raise prices before announcing a sale. HP loweredN performance of EV7 so it can now announce a faster EV7 and make it appear like a true speed improvement.e    J In the end, HP breaks the "roadmap", "commitments" etc. They promised EV79A which was a process shink. And they will not honour that promise.e   ------------------------------  % Date: Fri, 24 Oct 2003 00:09:27 -0400 ( From: David Froble <davef@tsoft-inc.com>$ Subject: Re: EV79 CANCELED !!!!!!!!!, Message-ID: <3F98A5F7.3060301@tsoft-inc.com>   > Michael Moroney wrote:  H >> As to performance, haven't the INTC chips passed Alpha a while back? ) >> ("1 gigahertz? That's so Windows 98!")r  K Do you know of any Intel product running at 1 GHz that will match an Alpha c running at that speed?   Didn't think so.   Clock speed isn't everything.    Dave   -- y4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road- Vanderbilt, PA  15486-   ------------------------------    Date: 23 Oct 2003 22:35:10 -0700. From: mistdragon@zdnetonebox.com (mist dragon)$ Subject: Re: EV79 CANCELED !!!!!!!!!= Message-ID: <7500353b.0310232135.4571b50c@posting.google.com>:  L > Will the "z" actually shrink to a new process, or will they just crank theK > clock up to what EV7 is capable of supporting since it was designed to be5# > faster than what it was sold as ?6  : Or maybe, as in overclocking world, the first problem from@ overclocking is the raise of heat. This could mean only a better$ cooling system, not even die shrink.  D Note what they said: if run on separate hardware, it runs faster, if< on same, as slow as others. Now, this could be either a goodF engineering, or the cause of the above: EV7z with EV7's will run usingD the same power and motherboard layout, supporting same kind of fans.D EV7z running on separate hardware could have different power,fans or thermal elements.n  E It is also common practice that some yelds are better than other - ifiE a cpu cant clock to 2,8Ghz, it could still work as 2,5Ghz and is sold % as such. The same could be with EV7z.n     Mr   ------------------------------  % Date: Thu, 23 Oct 2003 11:27:52 -0700a+ From: "Barry Treahy, Jr." <Treahy@MMaz.com>  Subject: Re: FTP From a Programa' Message-ID: <3F981DA8.3000606@MMaz.com>    Mike Freeman wrote:i   >Greetings.a >aG >I work for the Bonneville Power Administration, a Federal agency which0I >controls the electric power grid in the WEstern part of the U.S.  We use!H >many systems running VAX/VMS and VAX/AXP for various activities in this	 >process.l >aA >Is a package available which will allow a program to perform FTPoI >operations directly (as opposed to calling a FTP client via LIB$SPAWN or 3 >similar)?  We have FORTRAN, C and PASCAL programs.s >  e >a< Yes, but you did not identify which stack you are running...   Barrya   -- o  > Barry Treahy, Jr                       E-mail: Treahy@MMaz.com> Midwest Microwave                          Phone: 480/314-1320> Vice President & CIO                         FAX: 480/661-7028                            ------------------------------  % Date: Thu, 23 Oct 2003 20:28:57 +02001 From: Dirk Munk <munk@home.nl>7 Subject: High-end SUN servers to be produced by Fujitsu 2 Message-ID: <bn96o9$dqp$1@news1.tilbu1.nb.home.nl>  I Today it was announced that Fujitsu is going to produce the High-end SUN aD systems, Sun itself will only produce mid-range and low-end systems.   ------------------------------    Date: 23 Oct 2003 14:52:46 -0600+ From: young_r@encompasserve.org (Rob Young)a; Subject: Re: High-end SUN servers to be produced by Fujitsuh3 Message-ID: <QzVLaDEEacfh@eisner.encompasserve.org>i  S In article <bn96o9$dqp$1@news1.tilbu1.nb.home.nl>, Dirk Munk <munk@home.nl> writes:-K > Today it was announced that Fujitsu is going to produce the High-end SUN  F > systems, Sun itself will only produce mid-range and low-end systems.   Actually, this is the rumor:   http://www.marketwatch.com/news/yhoo/story.asp?source=blq/yhoo&siteid=yhoo&dist=yhoo&guid=%7B89313627%2DE309%2D4859%2DA889%2D6D5CDC39DEE2%7D  N TOKYO (CBS.MW) -- Japanese electronics giant Fujitsu and Sun Microsystems haveH agreed to merge their high-performance server businesses, according to a published report.d  J The Nihon Keizai Shimbun reported Thursday that the firms will standardizeL designs for Unix servers as early as 2004 and production of high-end servers/ would be consolidated at a Fujitsu subsidiary. t  K If they agree to integrate their server operations, the two companies wouldhJ have more than 40 percent of the Unix server market, topping market leader- Hewlett-Packard (HPQ: news, chart, profile). t  M Fujitsu spokesman Scott Ikeda said that while the two companies enjoy a closesK partnership and have had discussions in the past, there have not been fresh $ talks to broaden this relationship.   G "At the present time, however, nothing has been decided with respect tofL expanding the scope of our current relationship with Sun," Fujitsu said in a
 statement.   ---o  D 	"If, "May", "reported".  But perhaps it will come to pass.  Sun has@ 	to do something - can't shoulder the heavy development costs by; 	itself (and keep shareholders happy, etc.)  Seems there isAA 	quite a bit of excitement about the possibility.  Sun's stock isn9 	up 3.5% or 12 cents a share, currently at $3.59 a piece.l   				Rob    ------------------------------  % Date: Thu, 23 Oct 2003 13:01:13 -0700u/ From: Greg Cagle <news@removethisgregcagle.com>a; Subject: Re: High-end SUN servers to be produced by Fujitsua/ Message-ID: <vpgcsbpe0k6sc1@corp.supernews.com>    Rob Young wrote:  F > 	"If, "May", "reported".  But perhaps it will come to pass.  Sun hasB > 	to do something - can't shoulder the heavy development costs by= > 	itself (and keep shareholders happy, etc.)  Seems there isTC > 	quite a bit of excitement about the possibility.  Sun's stock is/; > 	up 3.5% or 12 cents a share, currently at $3.59 a piece.8  E I actually hope this *isn't* true - I have a number of friends at the  Beaverton plant.   -- :
 Greg Cagle gregc at gregcagle dot com   ------------------------------  # Date: Thu, 23 Oct 2003 18:35:59 GMTn& From: Rick Jones <foo@bar.baz.invalid>Y Subject: Re: HP announces new AlphaServer systems and enhancements to Tru64 UNIX and Openi2 Message-ID: <jcVlb.7704$%46.5275@news.cpqcorp.net>  ) Bill Todd <billtodd@metrocast.net> wrote:b5 > "Rick Jones" <foo@bar.baz.invalid> wrote in messageoF >> You left-out that the SPECfp_rate2000 figures for the Superdome you@ >> provided are also from HP compilers, and that to date, the HPE >> compilers for SPECfp have not been as fast as the Intel compilers.o  E > You're of course welcome to characterize any such difference if youi1 > consider it significant (as I did for SPECint).a  C Here are two results for the McKinley rx5670 from www.spec.org, onesC running Linux and using an Intel compiler, the other running HP-UX,a< using HP compilers. Output truncated to fit a normal screen.   rx5670 (1000 MHz, Itanium 2)  / Red Hat Linux Advanced Server 2.1   1431   1431a0 HPUX11i-TCOE B.11.22                1305   1178    A delta of 9.7% for peak.i  - >> Perhaps it was in the past, but not today.+  B > Yes, today (look at the software availability date on the single > exception you list). > ...gB > Note the 'so far' in the sentence in question: it's not December > 2003 yet.h  F It would have been good for you to say what you meant by "today" as it4 could mean published, or it could mean shipping etc.  C >> BTW, the "scaling" on SPECrate from 16 to 32 to 64 processors oniF >> the Superdome is it seems rather good (as it also seems on the 1280C >> if my cursory glance is accurate).  If it has been a month sincehF >> you've looked at http://www.spec.org (infering from your 20% claim)C >> you might not have seen those yet. They were just published thisi	 >> month.p  $ > You are correct:  I spoke loosely.  B At happens to all of us, especially when we are passionate about a topic.  ? > Superdome *itself* indeed scales quite linearly from 16 to 64VD > processors, just as the 1280 does.  Its problem is in scaling fromD > small systems (4 processors or less) up to 16 (or more likely evenA > just 8): the 1280 scales linearly in this region as well, whilePE > scaling linearity really sucks when moving from a 1- to 4-processor 3 > zx1 HP system to a 16-processor Superdome system.a  , So, looking at the SPECint_rate2000 results:  C HP Integrity Server rx5670 (1500 MHz, Itanium 2)   60.0   60.0  4  'B HP Integrity Superdome 16-way (1500 MHz Itanium 2)   229   229  16B HP Integrity Superdome 64-way (1500 MHz Itanium 2)   904   904  64  A It looks like the scaling from 4-CPU zx1 to 16-CPU sx1000 is 3.8. 7 Does that "suck?" I am not sure where to define that.  t  F From four to 64 CPUs with the CEC change the scaling is 15 as compared- to the same-CEC scaling on the 1280 of ~15.6.e  E Now, there is of course SPECfp_rate2000 (My mind reading does tell me F that you would want to include that :).  There we have a problem beingA able to compare - because there are no SPECfp_rate2000 figures onAE www.spec.org for a four-CPU zx1 system using the HP compilers, and welC have no figures for a >= 16-CPU sx1000-based system using the IntelkD compilers. So, that are two variables, compiler and CEC - out of the? big three for SPECcpu of compiler, CEC and processor (I suppose ? libraries would be a fourth of the big three).  However, havingc caveated things that way:   A Intel compiler zx1 rx5670 (1500 MHz, Itanium 2)   66.4   66.4  4 0I HP compiler sx1000 Superdome 16-way (1500 MHz Itanium 2)   236   215  16 !H HP compiler sx1000 Superdome 64-way (1500 MHz Itanium 2)   928   846  64  E Looks like the changing-the-CEC scaling from four to 16 CPUs is 3.55. D Out to 64 CPUs the scaling is still only 13.9. No, that is certainly
 not great.  C > The net result is that while an N-processor 1280 system gives youE7 > very close to N times the SPECint/fp performance of apE > single-processor 1280 system, an N-processor Superdome system givese= > you somewhat less than N times the SPECint performance of aeE > single-processor HP Itanic system and a *lot* less than N times thed< > SPECfp performance of a single-processor HP Itanic system   C I realize that there is not a boatload of low-CPU count sx1000 dataeF from which to work, but it seems that switching the CEC's in one case,C and not in the other isn't completely apropriate.  I'm not going top? say it is _absolutely_ invalid, but it does need to include then caveats.  F And while there is no public 1 CPU Superdome SPECcpu data, the data weE have seen thusfar going from 16 to 32 to 64 CPUs does suggest that an > N CPU Superdome would give N times the SPECcpu of a single CPU
 Superdome.  E > (and is even more pathetic in scaling linearity up from zx1 systems = > in TPC-C as well, though that benchmark was not part of the F > discussion since HP has elected not to release TPC-C results for EV7 > systems).   % But you will bring it up anyway... :)U  D > Hence my somewhat loosely-worded comment about Superdome's ability? > to scale.  While we'd need to see Superdome results down to 4. > processors to be suret   Indeed.s  C > I'm perfectly willing to entertain the idea that Superdome scaless > just fine    Fair enough.  D > but simply sucks across the board in making the performance of the/ > processors in it available for effective use.e  D There I think I will disagree that it "sucks," not being fond of the subjective term.  
 rick jones  E SPECfp, SPECint, SPECcpu are registered trademarks of SPEC, data fromv) www.spec.org as of 10/23/2003 etc etc etc    --  ? Process shall set you free from the need for rational thought. tF these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...v   ------------------------------  % Date: Thu, 23 Oct 2003 16:37:12 -0400t* From: "Bill Todd" <billtodd@metrocast.net>Y Subject: Re: HP announces new AlphaServer systems and enhancements to Tru64 UNIX and Opene2 Message-ID: <pPWdnWTcS7NupgWiU-KYhg@metrocast.net>  3 "Rick Jones" <foo@bar.baz.invalid> wrote in messagec, news:jcVlb.7704$%46.5275@news.cpqcorp.net...+ > Bill Todd <billtodd@metrocast.net> wrote:-7 > > "Rick Jones" <foo@bar.baz.invalid> wrote in messageBH > >> You left-out that the SPECfp_rate2000 figures for the Superdome youB > >> provided are also from HP compilers, and that to date, the HPG > >> compilers for SPECfp have not been as fast as the Intel compilers.o > G > > You're of course welcome to characterize any such difference if youu3 > > consider it significant (as I did for SPECint).o >eE > Here are two results for the McKinley rx5670 from www.spec.org, oneeE > running Linux and using an Intel compiler, the other running HP-UX,e> > using HP compilers. Output truncated to fit a normal screen. >r > rx5670 (1000 MHz, Itanium 2)1 > Red Hat Linux Advanced Server 2.1   1431   1431c1 > HPUX11i-TCOE B.11.22                1305   1178k >  > A delta of 9.7% for peak.u  B Fair enough - and the difference in base is 21%, comparable to theJ difference in SPECint.  Thanks:  while I vaguely remembered that the IntelJ compiler generated higher SPECfp scores, I hadn't remembered the magnitude of the difference.   >n/ > >> Perhaps it was in the past, but not today.d > D > > Yes, today (look at the software availability date on the single > > exception you list). > > ... D > > Note the 'so far' in the sentence in question: it's not December
 > > 2003 yet.h >pH > It would have been good for you to say what you meant by "today" as it6 > could mean published, or it could mean shipping etc.  L While I was aware of the new (not yet released) Intel V8 result when I wroteI the sentence, I didn't feel that it materially affected the observation I0I made, for the reasons noted.  The HP-UX compiler's 20% (or more - IIRC it!F was more like 30% ahead of the Intel compiler back around the McKinleyI launch date, but only about 20% ahead of MS VC back then) lead in SPECint F has been pretty consistent for well over a year now, and, as I said, IK suspect that if Intel has now managed to improve its compiler's performancerI enough to start to catch up then HP likely also has improvements ready toi ship fairly soon.s   ...A  A > > Superdome *itself* indeed scales quite linearly from 16 to 64 F > > processors, just as the 1280 does.  Its problem is in scaling fromF > > small systems (4 processors or less) up to 16 (or more likely evenC > > just 8): the 1280 scales linearly in this region as well, whilewG > > scaling linearity really sucks when moving from a 1- to 4-processor 5 > > zx1 HP system to a 16-processor Superdome system.w > . > So, looking at the SPECint_rate2000 results: >iC > HP Integrity Server rx5670 (1500 MHz, Itanium 2)   60.0   60.0  4oD > HP Integrity Superdome 16-way (1500 MHz Itanium 2)   229   229  16D > HP Integrity Superdome 64-way (1500 MHz Itanium 2)   904   904  64 >pC > It looks like the scaling from 4-CPU zx1 to 16-CPU sx1000 is 3.8.d7 > Does that "suck?" I am not sure where to define that.>  I Actually, to understand how it was defined all you had to do was read the K paragraph which followed the one you quoted above (it's still quoted a ways . down below, if I can remember not to snip it):  G a) it clearly stated that SPECint_rate scores were "somewhat less" thansG linear (your factor of 3.82 above can be contrasted with a 3.96 scaling J factor for EV7 over the same range, but I specifically referred to scalingF up from *single*-processor systems, where the EV7 scaling factor to 16K processors is 15.84 and the Superdome scaling factor is 14.97 - noticeably, = though not dramatically, worse than the comparison you made);k  G b) it then stated that SPECfp_rate scores increased "a *lot* less" thanoJ linearly (again, compared with a zx1 system) when scaling up from a singleJ processor - and indeed while EV7 obtains 15.92x the SPECfp_rate score whenH moving from 1 to 16 processors Superdome's 16-processor (base - since noD special peak testing seems to have been done on the single-processorK configuration) SPECfp_rate score is only 8.78x that of the single-processorHK rx5670 system (and even after you adjust for differences between the HP anduE Intel compilers, by any definition I'm familiar with that scaling cancL reasonably be considered to 'suck'):  the reason your comparison below makesL Superdome's scaling appear more linear when compared with zx1 is because youK compared it with a 4-processor zx1 score, and the zx1 chipset itself scalesrJ rather poorly between 1 and 4 processors - but that was different from the@ single-processor comparison to which you were responding (I hopeL inadvertently, since so far you have seemed happy to discuss issues on their7 merits rather than stoop to that kind of misdirection).n   >mH > From four to 64 CPUs with the CEC change the scaling is 15 as compared/ > to the same-CEC scaling on the 1280 of ~15.6.  >eG > Now, there is of course SPECfp_rate2000 (My mind reading does tell me H > that you would want to include that :).  There we have a problem beingC > able to compare - because there are no SPECfp_rate2000 figures onEG > www.spec.org for a four-CPU zx1 system using the HP compilers, and we%E > have no figures for a >= 16-CPU sx1000-based system using the IntellF > compilers. So, that are two variables, compiler and CEC - out of theA > big three for SPECcpu of compiler, CEC and processor (I suppose,A > libraries would be a fourth of the big three).  However, having. > caveated things that way:L >!B > Intel compiler zx1 rx5670 (1500 MHz, Itanium 2)   66.4   66.4  4J > HP compiler sx1000 Superdome 16-way (1500 MHz Itanium 2)   236   215  16J > HP compiler sx1000 Superdome 64-way (1500 MHz Itanium 2)   928   846  64 >sG > Looks like the changing-the-CEC scaling from four to 16 CPUs is 3.55.hF > Out to 64 CPUs the scaling is still only 13.9. No, that is certainly > not great.  G But a hell of a lot better than the 1-processor-to-16-processor scalinglI ratio of 8.78 (I'm being kind:  if you use the rx2600 score, the ratio isoH only 8.74) that you would have been using had you been responding to theD statement I actually made (ah - now we've gotten to it, just below).   > E > > The net result is that while an N-processor 1280 system gives your9 > > very close to N times the SPECint/fp performance of aoG > > single-processor 1280 system, an N-processor Superdome system givest? > > you somewhat less than N times the SPECint performance of a G > > single-processor HP Itanic system and a *lot* less than N times thet= > > SPECfp performance of a single-processor HP Itanic systemp >lE > I realize that there is not a boatload of low-CPU count sx1000 data H > from which to work, but it seems that switching the CEC's in one case,E > and not in the other isn't completely apropriate.  I'm not going toiA > say it is _absolutely_ invalid, but it does need to include them
 > caveats.  K And I included them quite clearly in the post to which you responded above,  though not in my previous one.   > H > And while there is no public 1 CPU Superdome SPECcpu data, the data weG > have seen thusfar going from 16 to 32 to 64 CPUs does suggest that an @ > N CPU Superdome would give N times the SPECcpu of a single CPU > Superdome. >2G > > (and is even more pathetic in scaling linearity up from zx1 systemsy? > > in TPC-C as well, though that benchmark was not part of the H > > discussion since HP has elected not to release TPC-C results for EV7
 > > systems).p > ' > But you will bring it up anyway... :)   C Well, actually *you* were the one who first mentioned TPC-C in thishD sub-thread, IIRC (look back to your first post).  And it's certainlyJ relevant to the question of Superdome's scaling w.r.t. zx1 systems, thoughG we can't ascertain just how much better EV7 would scale because of HP'ss reluctance to test it publicly.y  K But I did get a bit carried away in suggesting that Superdome "sucks acrosshI the board in making the performance of the processors in it available for K effective use":  while it well and truly sucks in SPECfp_rate and even more L so in TPC-C (and in at least a couple of other benchmarks that I'm not goingL to bother to dig up right now, but where poor old aging Alpha gives it a runH for its money), it doesn't actually suck in SPECint scaling (though it's) still noticably less linear than Marvel).t   - bill   ------------------------------  # Date: Thu, 23 Oct 2003 21:38:23 GMTo& From: Rick Jones <foo@bar.baz.invalid>Y Subject: Re: HP announces new AlphaServer systems and enhancements to Tru64 UNIX and Open 2 Message-ID: <jTXlb.7722$8i6.5146@news.cpqcorp.net>  ) Bill Todd <billtodd@metrocast.net> wrote:tI >> It would have been good for you to say what you meant by "today" as it 7 >> could mean published, or it could mean shipping etc.g  F > While I was aware of the new (not yet released) Intel V8 result whenE > I wrote the sentence, I didn't feel that it materially affected theuF > observation I made, for the reasons noted.  The HP-UX compiler's 20%B > (or more - IIRC it was more like 30% ahead of the Intel compilerF > back around the McKinley launch date, but only about 20% ahead of MS > VC back then)d  8 Which data are you using for that? I cannot find data atC http://www.spec.org/ that holds the system constant and changes thei	 compiler.   E I can find some results where the system and the compiler change suchu as these for 1000 MHz Itanium2:A  A Bull  NovaScale 4040                   719 711 1 Mar-2003 Windowsi? hp server rx2600 (1000 MHz, Itanium 2)  -- 810 1 Jul-2002 HP-UX E SGI Altix 3000 (1000MHz, Itanium 2)    683 683 1 Jun-2003 Linux/Intele  F Where the delta is 13.9% for the Windows compiler and 18.6% for Linux.  F > lead in SPECint has been pretty consistent for well over a year now,D > and, as I said, I suspect that if Intel has now managed to improve@ > its compiler's performance enough to start to catch up then HP9 > likely also has improvements ready to ship fairly soon.2  E I guess how far apart compilers might remain depends on how far alongu> you think the compilers happen to be.  Presumeably, as all theD compilers mature and get more tunes and such, they would "naturally"D tend towards the same perf level.  Of course, by then the benchmarks will probably have changed. :)  D > a) it clearly stated that SPECint_rate scores were "somewhat less"F > than linear (your factor of 3.82 above can be contrasted with a 3.96@ > scaling factor for EV7 over the same range, but I specificallyC > referred to scaling up from *single*-processor systems, where thes@ > EV7 scaling factor to 16 processors is 15.84 and the SuperdomeF > scaling factor is 14.97 - noticeably, though not dramatically, worse  > than the comparison you made);  @ And again, we have no single-CPU Superdome numbers with which toF play... and no numbers from the EV7 where the processor frequency held constant and the CEC changed.'  C > the reason your comparison below makes Superdome's scaling appear F > more linear when compared with zx1 is because you compared it with aA > 4-processor zx1 score, and the zx1 chipset itself scales rathereE > poorly between 1 and 4 processors - but that was different from thecB > single-processor comparison to which you were responding (I hopeE > inadvertently, since so far you have seemed happy to discuss issuesrB > on their merits rather than stoop to that kind of misdirection).  D It was a coin-toss in my head as single and quad CPU stuff was under discussion.v  I > But a hell of a lot better than the 1-processor-to-16-processor scalingnK > ratio of 8.78 (I'm being kind:  if you use the rx2600 score, the ratio is J > only 8.74) that you would have been using had you been responding to theF > statement I actually made (ah - now we've gotten to it, just below).  " Again that coin-toss in my head.    ( >> But you will bring it up anyway... :)  E > Well, actually *you* were the one who first mentioned TPC-C in thiso4 > sub-thread, IIRC (look back to your first post).    B Only in the context of where one might go to find statements as toB availability dates for 32 and 64-way Itanium Superdomes.  I wasn'tD trying to use TPC-C scores to debate the relative merits of systems.  D > And it's certainly relevant to the question of Superdome's scalingD > w.r.t. zx1 systems, though we can't ascertain just how much betterA > EV7 would scale because of HP's reluctance to test it publicly.r  @ Admittedly, EV7 has some things on it that can be considered CECD functions, but still, should you be mixing and matching zx1 CEC with EV7 processors like that?w  
 rick jones --  . a wide gulf separates "what if" from "if only"F these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...l   ------------------------------    Date: 23 Oct 2003 19:17:57 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)f; Subject: Re: HP offers WebLogic on OpenVMS, NonStop serverst= Message-ID: <cf15391e.0310231817.14fafc32@posting.google.com>z  V "Wayne W. Scott" <wscott@nac.net> wrote in message news:<3F96BB77.499A6544@nac.net>...< > something positive to report with OpenVMS in the headline.  B The computer industry press seems to have gotten the message aboutA OpenVMS continuing on with Itanium.  Here's another example, from7 CNet:   ' New HP AlphaServer to be most powerful l# By Stephen Shankland, CNET News.come! Monday, October 20 2003 10:04 AM t@ http://asia.cnet.com/newstech/systems/0,39001153,39155366,00.htm  B Hewlett-Packard plans on Monday to begin selling the last and most@ powerful model in the AlphaServer line, a series of servers thatA stretches back to a very different era in the computing industry.  ...tC One major feature of the AlphaServer line will live on: the OpenVMSnC operating system. That software, born more than 25 years ago as VMSeA (Virtual Memory System), is being moved to the Itanium processor.-   ------------------------------  % Date: Thu, 23 Oct 2003 18:27:20 +0100yO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>1; Subject: Re: OpenVMS I64 ISV application count now over 500:0 Message-ID: <bn931p$lef$1@new-usenet.uk.sun.com>   John Smith wrote:h > Fred Kleinsorge wrote: > 7 >>"Bill Todd" <billtodd@metrocast.net> wrote in messageh. >>news:ididnaDGBNE7owiiU-KYgg@metrocast.net... >>A >>>Of course, exactly how you determined that people of like minddG >>>constitute only 0.3% of c.o.v.'s readership is somewhat questionable # >>>(sort of like a lot of HP's PR).  >>>n >>D >>Frankly, it's because I get a stream of complaints via email aboutD >>you, and a stream of emails agreeing with me.  None of the writersB >>hacve any interest in writing in this forum to be cut up by your
 >>poison pen.  >>D >>In fact, if 3-4 posters would dissapear - 95% of the true negativeD >>spin would be gone... leaving those who - while not always happy - >>want VMS to succeed. >  >  > , > So who is on your 'Hit List', Mr. Soprano? > 5 > Nobody here, aside from Andrew, is negative on VMS.iA > Everyone here, aside from Andrew, wants VMS to thrive and grow.e  ? I have no views either way, OpenVMS's presence in the market isl= currently so tiny that if it were to double it would still be  almost invisible.e  % OpenVMS inspired BS is another thing.h   regardsl Andrew Harrisono   ------------------------------  % Date: Thu, 23 Oct 2003 15:51:04 -0400 ' From: "Main, Kerry" <kerry.main@hp.com>s; Subject: RE: OpenVMS I64 ISV application count now over 500oR Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB17BF09@tayexc19.americas.cpqcorp.net>  7 > > Nobody here, aside from Andrew, is negative on VMS.;C > > Everyone here, aside from Andrew, wants VMS to thrive and grow.e >=20A > I have no views either way, OpenVMS's presence in the market=20oB > is currently so tiny that if it were to double it would still=20 > be almost invisible. >=20' > OpenVMS inspired BS is another thing.l >=20	 > regardst > Andrew Harrison  >=20  	 ROTFL ...h   Andrew, Andrew ...  ? Hey, like anyone, you are certainly free to participate here ini comp.os.vms, but -  A If OpenVMS worries Sun and you so little, if, as recent newsgrouptC posting analysis by a few readers here is correct, why do you spend H approx 80%+ of your online posting time in comp.os.vms and not somewhereD that would be much more to your liking i.e. in Solaris, UNIX or even architecture newsgroups?  > I'll bet you do not see many AIX or OpenVMS posters on SolarisG newsgroups playing moderator to "correct" the Solaris fud and marketing ( that would inevitablely come up there...   Regardsy  
 Kerry Main Senior Consultant1 HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477s Email: kerryDOTmainAThpDOTcomn. (remove the DOT's and AT for email address)=20   ------------------------------    Date: 23 Oct 2003 18:46:29 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)e; Subject: Re: OpenVMS I64 ISV application count now over 500h= Message-ID: <cf15391e.0310231746.13a9c6a5@posting.google.com>h   Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<bn931p$lef$1@new-usenet.uk.sun.com>....% > OpenVMS's presence in the market iso? > currently so tiny that if it were to double it would still bee > almost invisible.b  A A common misconception.  OpenVMS doesn't get as much hype as someo things, that's all.r  @ Take Linux, for example.  HP is proudly Number 1 in Linux marketD share, and earlier this year surpassed US$2 Billion in Linux-relatedD revenues.  In contrast, HP has between $2.5 Billion and $3.0 Billion> in OpenVMS revenues annually, and does so with $500 Million in: profits. (I suspect the Linux profits were a bit slimmer).  F And while we're on the subject of market presence, Sun's sure looks toF be shrinking.  Another very bad week last week for Sun, judging by the headlines at Yahoo Finance:g,  Sun Microsystems Stuck in Downward Spiral + Wed, Oct 15 - 3:45pm ET - Associated Press e2  Bad news flows like red ink at Sun Microsystems , Wed, Oct 15 - 10:12pm ET - Associated Press .  Sun Micro sees Q1 loss soar to $286 million - Thu, Oct 16 - 6:14pm ET - at CBS MarketWatch r,  Sun Microsystems Loss Widens, Sales Slide ! Thu, Oct 16 - 9:21pm ET - Reuters=  Just Avoid Sun -( Fri, Oct 17 - 2:56pm ET - at Motley Fool-  S&P may cut Sun Microsystems 'BBB' ratings @" Fri, Oct 17 - 5:01pm ET - Reuters   A But no need to worry, Andrew.  (At least not this quarter.)  See:r9  Sun Micro CFO: Not Planning Work Force Reductions In 2Qu1 Thu, Oct 16 - 7:00pm ET - Dow Jones Business Newso   ------------------------------  # Date: Fri, 24 Oct 2003 02:47:55 GMT # From: "John Smith" <a@nonymous.com> ; Subject: Re: OpenVMS I64 ISV application count now over 500eJ Message-ID: <vp0mb.263252$ko%.137984@news04.bloor.is.net.cable.rogers.com>   Keith Parris wrote:h# > Andrew Harrison SUNUK Consultancyo: > <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message. > news:<bn931p$lef$1@new-usenet.uk.sun.com>...& >> OpenVMS's presence in the market is@ >> currently so tiny that if it were to double it would still be >> almost invisible. >cC > A common misconception.  OpenVMS doesn't get as much hype as somen > things, that's all.s >dB > Take Linux, for example.  HP is proudly Number 1 in Linux marketF > share, and earlier this year surpassed US$2 Billion in Linux-relatedF > revenues.  In contrast, HP has between $2.5 Billion and $3.0 Billion@ > in OpenVMS revenues annually, and does so with $500 Million in< > profits. (I suspect the Linux profits were a bit slimmer). >t4 > And while we're on the subject of market presence,J don't you think that a little advertsisng and promotion of VMS could boostJ those numbers. I'm pretty sure you could use a raise/bonus, and if the VMSJ division doubled its profit by selling more VMS systems.......think of the possibilities....v   ------------------------------  # Date: Thu, 23 Oct 2003 18:20:11 GMTe, From: "warren sander" <warren.sander@hp.com> Subject: Re: OpenVMS Roadmap2 Message-ID: <vZUlb.7702$D46.7310@news.cpqcorp.net>  I not want to dump on MS but when converting a ppt to html the best size tot$ pick is the 800x600 because it makesL a fixed size. I know the images are small if you are at greater than 800x600( but the other sizes that powerpoint letsH you choose are not much better. I still have office 2000 if office xp or, office 2003 does better let me know and I'll4 upgrade. I still like the office 98 version myself..  G but we also have the PPT, PDF and PS versions available as links in thee footer.   & If there is a better way let me know..   -warrene  2 "DL Phillips" <whohe@whoever.com> wrote in message7 news:af0dc2ea.0310221202.312334d2@posting.google.com...-E > Can anyone actually read the roadmap? Or is there some magic buttonbF > I'm missing that will make this pos readable? Or do I really need toF > download the thing to read it? I have a 17" monitor but I doubt that? > even a 60" would be enough. Or, is the roadmap posted legiblyk > someplace other than:t >s@ > http://h71000.www7.hp.com/openvms/roadmap/openvms_roadmaps.htm > ) > This page is a waste of good electrons.    ------------------------------  % Date: Thu, 23 Oct 2003 14:49:15 -0400y* From: JF Mezei <jfmezei.spamnot@istop.com> Subject: Re: OpenVMS Roadmap) Message-ID: <3F9822A5.893CB8EB@istop.com>r   warren sander wrote:K > not want to dump on MS but when converting a ppt to html the best size to & > pick is the 800x600 because it makes > a fixed size.:    N That particular page isn't a PPT issue. It is an HTML issue. With proper HTML,K the frames would be adjusted proportional to the screen size, and then, one D would use scroll bars to view the 800-600 content inside of a frame.  L The way the page was designed, the unnecessary fluff was in frames that tookM up all of the screen real estate, and the frame where the PPT would have beend displayed was totally occluded.c  N Use percentages to size frames, not fixed point sizes. HTML  must not assume a specific screen size.a  M Buy yourself a mac where you can easily change screen size and you'll see how L your pages behave at different screen sizes. )called "resolution" in windows3 world even though screen resolution never changes).d   ------------------------------   Date: 23 Oct 2003 18:02 CDTo. From: carl@nospam.gerg.tamu.edu (Carl Perkins) Subject: Re: OpenVMS Roadmap4 Message-ID: <23OCT200318025865@nospam.gerg.tamu.edu>  X In article <3F9822A5.893CB8EB@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes... }warren sander wrote:eL }> not want to dump on MS but when converting a ppt to html the best size to' }> pick is the 800x600 because it makesJ }> a fixed size. }  } O }That particular page isn't a PPT issue. It is an HTML issue. With proper HTML,FL }the frames would be adjusted proportional to the screen size, and then, oneE }would use scroll bars to view the 800-600 content inside of a frame.e  K The problem is that it isn't 800x600. It is smaller than that and thereforeo? hard to impossible to make out from the images on the web page.a  M }The way the page was designed, the unnecessary fluff was in frames that tooktN }up all of the screen real estate, and the frame where the PPT would have been  }displayed was totally occluded. } O }Use percentages to size frames, not fixed point sizes. HTML  must not assume ay }specific screen size. } N }Buy yourself a mac where you can easily change screen size and you'll see howM }your pages behave at different screen sizes. )called "resolution" in windows 4 }world even though screen resolution never changes).  C Yes it does. The size of the screen stays the same (thus calling it G "size" is incorrect). The resolution of the image on the screen changes9F When at 800x600 it produces an image that is 800 pixels by 600 pixels.G When at 1280x1024 it produces an image that is 1280 by 1024 pixels. TherH monitor neither grows nor shrinks - it stays the same size (give or takeK some possible small changes to the unused black border on the screen, whichaF you can change via the available controls) therefore the resolution of the displayed image changes. a  9 This is for a CRT, of course. LCD displays are different..   --- Carl   ------------------------------  % Date: Thu, 23 Oct 2003 20:42:59 -0400t* From: JF Mezei <jfmezei.spamnot@istop.com> Subject: Re: OpenVMS Roadmap) Message-ID: <3F987589.E8D8F8A5@istop.com>s   Carl Perkins wrote:/E > Yes it does. The size of the screen stays the same (thus calling itsI > "size" is incorrect). The resolution of the image on the screen changesS    J But the resolution of the screen doesn't change. It is just the video cardM that draws bigger or smaller dots that are spaced closer or farther away. ThetU resolution of the CRT is defined by the number of scan lines, and frequency of scans.n   ------------------------------   Date: 23 Oct 2003 21:19 CDTr. From: carl@nospam.gerg.tamu.edu (Carl Perkins) Subject: Re: OpenVMS Roadmap4 Message-ID: <23OCT200321194813@nospam.gerg.tamu.edu>  . JF Mezei <jfmezei.spamnot@istop.com> writes... }Carl Perkins wrote:F }> Yes it does. The size of the screen stays the same (thus calling itJ }> "size" is incorrect). The resolution of the image on the screen changes } K }But the resolution of the screen doesn't change. It is just the video carddN }that draws bigger or smaller dots that are spaced closer or farther away. TheL }resolution of the CRT is defined by the number of scan lines, and frequency
 }of scans.  G The number of scan lines changes when you change the resolution setting G on a CRT type display - at 800x600 it is drawing 600 scan lines, and atoG 1600x1200 it is drawing 1200 scan lines. They really do change. (Unlikei LCD displays, which don't).t  E The frequency of scans has nothing to do with the spatial resolution,uH which is what the term refers to (the temporal resolution of the displayH as a whole is not called "resolution", it is called "refresh rate" - theF rate at which individual scan lines are drawn is pretty much just fastF enough to allow it to run at the whole screen refresh rate). A displayF at 1024x768 is the same (spatial) resolution if you update it 60 times9 per second as it is if you update it 72 times per second.o   But that is all unimportant.  B The resolution of the output image on the display is the number ofD distinct pixels in a given area (or in a given length if you want toB separate the horizontal and vertical resolutions). The area of theE screen (which is the "given area") stays the same, the number of dots H changes. Clearly that means the resolution changes. You can also measureD who many dots per inch you have at each setting and you'll find thatD you get twice as many dpi in each direction when set to 1600x1200 asI you do when set to 800x600 (if you adjust the monitor so the used portionr# is the same in both cases, anyway).s  I If you print a document at 600 dpi and at 1200 dpi both producing lettersuJ and images that are the same size on the paper, then the 1200 dpi documentK is the same size but higher resolution (even if it was produced by the samefM printer). Ditto for using different resolutions such as 800x600 and 1600x1200tJ on a monitor (for which the unit of measure isn't usually inches, but "oneM full screen" - using inches a monitor's resolution is typically between 90dpicL and 120dpi these days, which isn't nearly as useful in most cases as knowingJ the resolution in terms of the whole display) - just like the paper is theI same size, the monitor is the same size, but they both have twice as manyPI dpi or 4 times as many "dps" ("dots per surface", a term which I just nowi	 made up).a   --- Carl   ------------------------------    Date: 23 Oct 2003 15:13:51 -0600+ From: young_r@encompasserve.org (Rob Young)i5 Subject: Re: OT: Why Scott McNeally is not worried...e3 Message-ID: <wjVCSKiogZ67@eisner.encompasserve.org>v   In article <bn8do1$eca$1@new-usenet.uk.sun.com>, Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes: > Rob Young wrote:Y >> In article <3F958776.90F01FDD@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes:o >>   >>>Rob Young wrote:y >>>cE >>>>        PowerPC systems are woefully under-powered, Power systemsp >>>>        certainly aren't.y >>>0P >>>I repeat: PowerPC systems now come from a Power core, made by IBM, with a few? >>>bells and whistles added for Apple and markleted as PowerPC.  >> f >> e >> a? >> 	No.  With many bells and whistles removed.  Come back after*F >> 	reviewing both architectures.  I don't mean that as a slam.  PowerC >> 	is MCM based, etc.  But don't take just my word for it, compares> >> 	your earlier mentioned SPEC numbers for Power G5 to these: >> s >> 	PowerMAC G5  >> n/ >>    SPECint_base2000                      800s/ >>    SPECfp_base2000                       840s >>   > P >> http://www.specbench.org/cpu2000/results/res2003q3/cpu2000-20030728-02415.asc >> II >>         IBM Corporation IBM eServer pSeries 655 (1700 Mhz, 1 CPU LPAR)i >> p0 >>    SPECint_base2000                      10236 >>    SPECfp_base2000                       1405   (1) >> 9D > Don't you just love it when someone who appears to have absolutelyG > no idea why people design specific processors for different types of fG > systems comes up with a wonderfull apples for oranges comparison likes > this.c >  > Pity its generally Rob.  > B > The G5 has a L2 512K cache the Power4+ 1700 has a 1536K L2 CacheK > and a 128MB L3 cache because 7 of the 8 CPU's in the MCM were turned off t > for SPECint. > D > Now why do you think that the G5 has a much smaller cache than the > P690 ? Answers on a post card, > A > Do you attribute any of the performance differences between the ? > G5 and the Power4+ to the fact that the Power4+ had 258 x the @ > cache of the G5 ? Remember most of SPECint and SPECfp fit into= > 128MB of cache and the same cannot be said of a 512K cache.e >   C 	It's pretty obvious why the numbers are different.  The difference : 	is in dispute, not the how or the why for the difference.   > ? >> 	And throughput numbers (i.e. multiple CPUs) are much higherS< >> 	for Power, PowerPC doesn't scale but wasn't designed to. >>     > @ > Ahh well done G5 was designed for something entirely different= > a low cost desktop/deskside and that means a smaller cache.r  8 	Right.  And in your usual fashion of jumping in halfway9 	through a thread - that has devolved substantially - your: 	always neglect to go back and read context.  Context thatB 	JF sees and has been part of and is addressed in various threads.  & 	The context revolves around P4 versusE 	G5 and has have off-shoots that have dragged in separate directions,n 	including Power.e   > : > Does than mean that PowerPC is out of gas crippled etc ? >   B 	Crippled?  Absolutely.  Compared to P4 (as mentioned earlier on)  	In fact, the quote is this:  c http://groups.google.com/groups?selm=qelcT2prGfQv%40eisner.encompasserve.org&oe=UTF-8&output=gplain   N In article <3F957148.199A7FE3@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes:c > Rob Young wrote:H >>         But Sun isn't going for the desktop.  The PowerPC is woefully0 >>         underpowered compared to latest P4s.  >  > F > Go to http://www.apple.com/g5processor/ and tell me exactyly what is	 "woefullyy' > underpowered" about the PowerPC chip.e >   ; 	Well, if you check out these 490 entries, nary an Apple in  sight:  6 http://www.specbench.org/cpu2000/results/cint2000.html  0 	So the entries found on page 5 are interesting:  k http://a1472.g.akamai.net/7/1472/51/a67986e6dfb80d/www.apple.com/powermac/pdf/PowerMacG5_Perf_WP_072903.pdf   > 	But never officially published, unless of course I overlooked= 	something, I haven't spent all day.  But if you look at pageeD 	5 on that PDF it shows the PowerMAC doing 800 SpecInt.  The current% 	top Dell does 1583 SpecInt2000 base:f  N http://www.specbench.org/cpu2000/results/res2003q4/cpu2000-20030922-02523.html  > 	The numbers Apple used were a joke and a number of guffaws inA 	various groups abounded.  The PowerMAC is woefully underpowered.f   ---2  @ 	But of course, you missed that as you miss many of the threads.B 	Buy or rent a good newsreader - go back and read the threads.  It> 	makes little sense to jump in and debate things that have notC 	only been earlier addressed BUT you BRING UP the same thing and itaB 	looks silly to bring it up again later on when addressed earlier.  # 	Answers on a postcard?  Pleeeze.      				Robr   ------------------------------  % Date: Thu, 23 Oct 2003 18:50:13 -0400S* From: JF Mezei <jfmezei.spamnot@istop.com>5 Subject: Re: OT: Why Scott McNeally is not worried...0) Message-ID: <3F985B24.B51E8B4B@istop.com>    Rob Young wrote:< > > Does than mean that PowerPC is out of gas crippled etc ? > >g > J >         Crippled?  Absolutely.  Compared to P4 (as mentioned earlier on)% >         In fact, the quote is this:   K Take your favourite IA64 and reduce its cache to 512K and use an old MercedeM compiler. You'll find your favourite IA64 performing worse than my all mightyi( microvax II. Crippled would be the word.  M the PowerPC G5 is "crippled" compared to high end version of the P4 chip. ButfK it is a Power chip, 64 bit and all. It is manufactured to specs by IBM, andr^ specs which  don't require the same bells and whistles as IBM does for its servers/mainframes.  H However, the G5 is still a high performance machine for a desktop and isN definitely not "underpowered" compared to its competition. (IBM is making sureL that Apple doesn't really compete against its own servers by differentiating( the Apple version from the IBM version).    H Go back to Digital and imagine a Multia that had a version of Alpha that9 wasn't as performant as the Alpha chips used in Galaxies.P   ------------------------------    Date: 23 Oct 2003 21:16:38 -0600+ From: young_r@encompasserve.org (Rob Young)e5 Subject: Re: OT: Why Scott McNeally is not worried...f3 Message-ID: <Kc6Fg44c0qGe@eisner.encompasserve.org>   V In article <3F985B24.B51E8B4B@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes: > Rob Young wrote:= >> > Does than mean that PowerPC is out of gas crippled etc ?e >> > >> eK >>         Crippled?  Absolutely.  Compared to P4 (as mentioned earlier on) & >>         In fact, the quote is this: > M > Take your favourite IA64 and reduce its cache to 512K and use an old MercedeO > compiler. You'll find your favourite IA64 performing worse than my all mightyo* > microvax II. Crippled would be the word. >   E 	Take any modern CPU and change its design to hinder its performance.s? 	But things don't work that way.  You take existing designs andiH 	create new ones.  You have criteria in mind.  Mostly higher performance@ 	and mostly decreased manufacturing cost.  Ideally both.  So you9 	probably have a point, but it isn't the way things work.r    O > the PowerPC G5 is "crippled" compared to high end version of the P4 chip. But4M > it is a Power chip, 64 bit and all. It is manufactured to specs by IBM, ands` > specs which  don't require the same bells and whistles as IBM does for its servers/mainframes. > J > However, the G5 is still a high performance machine for a desktop and isP > definitely not "underpowered" compared to its competition. (IBM is making sureN > that Apple doesn't really compete against its own servers by differentiating* > the Apple version from the IBM version).  @ 	Sure it is.  It is half the power, how isn't that underpowered?  J > Go back to Digital and imagine a Multia that had a version of Alpha that; > wasn't as performant as the Alpha chips used in Galaxies.t   	Yeah.  Time Machines.   				Rob    ------------------------------  # Date: Thu, 23 Oct 2003 20:48:26 GMT 2 From: "George Pagliarulo" <georgepag@adelphia.net>$ Subject: Re: problem with CXX patch?2 Message-ID: <u8Xlb.7717$lh6.7058@news.cpqcorp.net>  I I took a look at this.  The file got corrupted when it was moved from the F old site to the new ITRC site.  A corrected file will appear tomorrow.  I Since the V7.2-1 was an error in the original docs it propagated through.r' The docs were not reworked, just moved.n   George Pagliaruloo ECO Release Processt OpenVMS Engineeringt Hewlett-Packard Companyd    L "Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>/ wrote in message news:bmserj$8sa$4@online.de... ? > Jul 22 18:12  text/plain       CXXE01056.A-DCX_VAXEXE  4829Kbs >.6 > Seems to uncompress OK then gives (on a 7.2 system): >o8 > %VMSINSTAL-I-RESTORE, Restoring product save set A ...K > %BACKUP-E-VBNMISSING, DSA144:[SYS0.SYSUPD.CXXE01056]DECC$RTLDEF.TLB;1 hasf missin > g blocks 594 through 1317e: > %VMSINSTAL-E-NOSAVESET, Save set  A  cannot be restored. >rG > Can anyone reproduce this?  (The patch is from the ITRC ftp site.  Itf > says >hC >      4.1  Version(s) of OpenVMS to which this kit may be applied:y > " >      OpenVMS VAX V5.5-2 - V7.2-1 >lE > which is a bit strange since there is no 7.2-1 for VAX (as far as Ii > know). >o > Is it not usable on 7.3? >h   ------------------------------  # Date: Fri, 24 Oct 2003 03:36:38 GMT . From: Carl Bennett <carl.bennett3@verizon.net> Subject: Re: Product problem7 Message-ID: <a71mb.16954$Vf7.1741@nwrdny02.gnilink.net>a  G I saw something like this once because VMS$COMMON wasn't set up right, sG in fact, it was missing altogether... I had to do a set file /enter, I g think, to get past that one...  *   what does a show dev /files look like...   carl     Didier Morandi wrote:0 > JF Mezei wrote:d > H >> PCSI really wants to play only on system disks. YOu probably need to 	 >> define = >> some logicals to ensure that it points to the right files.o >>I >> Another thing you may wish to do is SET WATCH FILE/CLASS=ALL and then   >> issueE >> the proper PRODUCT command to see exactly which file/directory it .
 >> looks for.wH >> The one prior to the error message should normally be the one it has  >> problems with.e >  > J > May I recommend $ set watch file/class=(attr,major) which removes noise.C > Also, FYI, a file not found error code is 910 in the XQP display.  > E >> There are logicals one can set to help steer PRODUCT to the right 0 >> files, but I  >> don't have a list handy.  >>H >> The PRODUCT developper's guide could help you better understand what  >> it tries-J >> to do. Last time I downloaded it, it was named OVMS_73_PCSI_GD.pdf. It 	 >> offersnA >> some insights on logcal names and how kits are structured etc.  >> >> Sorry, lost the URL.o >  > 9 > http://h71000.www7.hp.com/doc/72final/5952/5952pro.htmlt >  > D. >    ------------------------------  % Date: Thu, 23 Oct 2003 11:23:23 -0700s3 From: Alan Frisbie <Usenet01REMOVE@Flying-Disk.com>e& Subject: Re: Spam from Hewlett-Packard. Message-ID: <3F981C9B.9030301@Flying-Disk.com>  3 Sadly, this problem has taken a turn for the worse.C  7 Apparently, Mr. Swartwood decided to get revenge on me. : Yesterday afternoon, he called my client, Nelson Nameplate8 Company (where I had been getting the spams), and left a4 voice-mail message for the president of the company.  > He falsely claimed that I had sent bogus and harassing e-mails1 to him.   He did not offer any proof or examples.o  ; I have never sent any e-mail of any kind to him, nor have Is= ever asked anyone to do so.   I think it would be wrong, justi@ as I think it is wrong for him to make such claims to my client.  = I am deeply saddened that a Hewlett-Packard employee would donA such a thing, especially someone in a position of responsibility.a- The company is greatly diminished in my eyes.   ) Alan             Remove "REMOVE" to replyS   ------------------------------  % Date: Thu, 23 Oct 2003 14:36:11 -0400s* From: JF Mezei <jfmezei.spamnot@istop.com>& Subject: Re: Spam from Hewlett-Packard) Message-ID: <3F981F96.B84568F9@istop.com>r   Alan Frisbie wrote:i9 > Apparently, Mr. Swartwood decided to get revenge on me.t< > Yesterday afternoon, he called my client, Nelson Nameplate: > Company (where I had been getting the spams), and left a6 > voice-mail message for the president of the company.    I That is despicable. This would warrant a lawyers letter on behalf of yourIL president to Carly requiring HP to respond in a letter detailing the actionsL CArly will have taken to not only repair this particulat problem, but ensure- that HP will abide by mass mailing etiquette.s   ------------------------------  # Date: Thu, 23 Oct 2003 20:23:31 GMT # From: "John Smith" <a@nonymous.com>s& Subject: Re: Spam from Hewlett-PackardH Message-ID: <7NWlb.26163$h61.15158@news01.bloor.is.net.cable.rogers.com>   Alan Frisbie wrote:r5 > Sadly, this problem has taken a turn for the worse.l >f9 > Apparently, Mr. Swartwood decided to get revenge on me.i< > Yesterday afternoon, he called my client, Nelson Nameplate: > Company (where I had been getting the spams), and left a6 > voice-mail message for the president of the company. >l@ > He falsely claimed that I had sent bogus and harassing e-mails3 > to him.   He did not offer any proof or examples.j >:= > I have never sent any e-mail of any kind to him, nor have Ir? > ever asked anyone to do so.   I think it would be wrong, just.B > as I think it is wrong for him to make such claims to my client. >e? > I am deeply saddened that a Hewlett-Packard employee would domC > such a thing, especially someone in a position of responsibility. / > The company is greatly diminished in my eyes.n    K Retain a lawyer to sue the bastard and HP for defamation of character...suev in both CA and TX.   ------------------------------  # Date: Thu, 23 Oct 2003 21:15:49 GMT # From: "John Smith" <a@nonymous.com> & Subject: Re: Spam from Hewlett-PackardH Message-ID: <9yXlb.26413$h61.16701@news01.bloor.is.net.cable.rogers.com>   Alan Frisbie wrote:i< > Some time ago, someone signed me up for a bunch of mailing@ > lists.   Fortunately, most of them were true confirmed opt-in,9 > so when I didn't reply to the confirmation requests, myH@ > address was dropped from the list.   Not so with HP, so I have% > been getting their spam ever since.0 >z? > To make matters worse it was all in HTML, which is a bit hardI; > to read on a VAX with VMS Mail.   Plus, it was all for PCt< > stuff which I am not about to buy from HP, especially now. >d? > To make it even worse, none of the opt-out mechanisms worked, > > including complaints to abuse@hp.com and abuse@cw.net (their> > upstream).   Ironically, the head of CW's security and abuse? > department is Bill Hancock, an old-time DECUS personality and2 > true spam-hater. >rB > I just got off the phone with two of Hewlett-Packard's "Privacy"A > department managers regarding their spam list.   Finally, I haddB > been able to get an HP employee to forward my complaint to theirE > internal help address, which forwarded it several times, eventuallyc$ > reaching their Privacy Department. > A > They eventually promised to listwash all my domains after firstrE > only agreeing to listwash the specific addresses I first complainedo > about. >rB > However, my big complaint was that they are entirely opt-out and= > have no intention of using confirmed opt-in (they called itrB > "double opt-in", the mark of a true spammer).   They say that no; > large company does, so it would put them at a competitivea > disadvantage., > A > I explained to them how their signup web site was being used asn( > an abuse tool, but they were unswayed. >e? > I also noted that California law requires "ADV:" as the firstp> > four characters of the subject line, but they said that they: > don't have to.   Interesting, since both HP and I are in
 > California.c >,@ > They are both familiar with MAPS, but say they will not followA > MAPS's "Basic Mailing List Management Guidelines for Preventingr, > Abuse", and have no intention of doing so. > B > Perhaps someone with greater persuasive powers than I have could/ > educate them.   The people I talked with are:i >o >    Debbie Thomsont! >    PSG Customer Privacy Managerl >    Houston, TX  CCA4 - 4307  >    phone:  281.514.4276l >    fax:  281.927.4525 # >    email:   debbie.thomson@hp.com  >a > and her boss,b >g >    Dan Swartwood >    HP Privacy Officero >    Houston, TX >    phone:  281.518.9564s >    fax:  281.927.4525n" >    email:   dan.swartwood@hp.com >aA > Dan appears to be a pretty bright guy and knows exactly what he @ > is doing, so this is not casual ignorance.   He says that theyD > opt-out over 50 people a day, so he is not unaware of the problem.? > I hope that someone can convince them to change away from thet > dark side.      ) http://www.theinquirer.net/?article=12296y     US senate passes anti-SPAM billr  = Law could mean billions worth of penalties if people break itv    2 By INQUIRER staff: Thursday 23 October 2003, 10:59  G A BILL WHICH will stop companies bombarding inboxes with their spam was 0 passed in the senate yesterday, 97 votes to nil.   ------------------------------  # Date: Thu, 23 Oct 2003 21:11:49 GMTo# From: "John Smith" <a@nonymous.com>d& Subject: Re: Spam from Hewlett-PackardH Message-ID: <puXlb.26394$h61.13463@news01.bloor.is.net.cable.rogers.com>   John Smith wrote:  > Alan Frisbie wrote:m6 >> Sadly, this problem has taken a turn for the worse. >>: >> Apparently, Mr. Swartwood decided to get revenge on me.= >> Yesterday afternoon, he called my client, Nelson Nameplate-; >> Company (where I had been getting the spams), and left aM7 >> voice-mail message for the president of the company.i >>A >> He falsely claimed that I had sent bogus and harassing e-mails34 >> to him.   He did not offer any proof or examples. >>> >> I have never sent any e-mail of any kind to him, nor have I@ >> ever asked anyone to do so.   I think it would be wrong, justC >> as I think it is wrong for him to make such claims to my client.t >>@ >> I am deeply saddened that a Hewlett-Packard employee would doD >> such a thing, especially someone in a position of responsibility.0 >> The company is greatly diminished in my eyes. >. >t= > Retain a lawyer to sue the bastard and HP for defamation ofk$ > character...sue in both CA and TX.    
 RETRACTIONJ My apologies to Mr. Swartwood. I'm sure he's not a bastard and I mis-spoke in calling him that.  L I'm sure he was only following HP policies in the course of his duties as anL HP employee. What other possible reason or motive could he have to call your client?a   ------------------------------  % Date: Thu, 23 Oct 2003 15:13:23 -0700e3 From: Alan Frisbie <Usenet01REMOVE@Flying-Disk.com>,& Subject: Re: Spam from Hewlett-Packard. Message-ID: <3F985283.5050902@Flying-Disk.com>   Alan Frisbie wrote: 5 > Sadly, this problem has taken a turn for the worse.  > 9 > Apparently, Mr. Swartwood decided to get revenge on me.S< > Yesterday afternoon, he called my client, Nelson Nameplate: > Company (where I had been getting the spams), and left a6 > voice-mail message for the president of the company. > @ > He falsely claimed that I had sent bogus and harassing e-mails3 > to him.   He did not offer any proof or examples.o > = > I have never sent any e-mail of any kind to him, nor have I ? > ever asked anyone to do so.   I think it would be wrong, justfB > as I think it is wrong for him to make such claims to my client.  = I can't believe this guy.   I just got a call from my client.>? He said that Dan Swartwood called him again today, still tryinga; to drag them into this.   Doesn't Hewlett-Packard have somel5 rules for employees about ethical and legal behavior?w  ) Alan             Remove "REMOVE" to reply    ------------------------------  + Date: Thu, 23 Oct 2003 23:27:00 +0000 (UTC) , From: lewis@PROBE.mitre.org (Keith A. Lewis)& Subject: Re: Spam from Hewlett-Packard. Message-ID: <bn9o44$q1r$1@newslocal.mitre.org>   Alan Frisbie <Usenet01REMOVE@Flying-Disk.com> writes in article <3F985283.5050902@Flying-Disk.com> dated Thu, 23 Oct 2003 15:13:23 -0700:-@ >He said that Dan Swartwood called him again today, still trying >to drag them into this.   @  J And you posted here again, still trying to drag comp.os.vms (HP's clients)+ into it.  Maybe he's playing "tit for tat"?@   Suggestions:   / * Spamcop.net maintains a RBL, report it there.   B * Use a filter, either on your mail client or on your SMTP server.  J To try to get back on-topic here, I'll mention that TCPIP services for VMSJ has a somewhat functional IMAP server (not as nice as Multinet's), and you? can use Mozilla for VMS as a client.  Mozilla supports filters.a  0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------  # Date: Fri, 24 Oct 2003 00:45:19 GMTO* From: "Mark Buda" <buda_NO@SPAM.yahoo.com>& Subject: Re: Spam from Hewlett-Packard> Message-ID: <zC_lb.125283$qj6.7792584@news1.news.adelphia.net>  @ "Alan Frisbie" <Usenet01REMOVE@Flying-Disk.com> wrote in message( news:3F985283.5050902@Flying-Disk.com...? > I can't believe this guy.   I just got a call from my client.oA > He said that Dan Swartwood called him again today, still tryingd= > to drag them into this.   Doesn't Hewlett-Packard have somei7 > rules for employees about ethical and legal behavior?e  K I would suggest contacting his boss and letting them know what is going on. I Also point out that you are sharing your experiences with comp.os.vms and=L how poorly treated you have been to date.  If that does not work, move it up to the next in line.  K Sooner or later Mr. Smartwood will find himself in deep water.  His actionseJ go against employee conduct, a course he is required to take and obviously has not taken...  F I would expect that he would call and apologize for his unprofessional' behavior before he gets into trouble....   mark   ------------------------------  # Date: Fri, 24 Oct 2003 02:43:32 GMTd# From: "John Smith" <a@nonymous.com>v& Subject: Re: Spam from Hewlett-PackardJ Message-ID: <ol0mb.263175$ko%.193740@news04.bloor.is.net.cable.rogers.com>   Alan Frisbie wrote:u > Alan Frisbie wrote:a6 >> Sadly, this problem has taken a turn for the worse. >>: >> Apparently, Mr. Swartwood decided to get revenge on me.= >> Yesterday afternoon, he called my client, Nelson Nameplates; >> Company (where I had been getting the spams), and left at7 >> voice-mail message for the president of the company.o >>A >> He falsely claimed that I had sent bogus and harassing e-mails 4 >> to him.   He did not offer any proof or examples. >>> >> I have never sent any e-mail of any kind to him, nor have I@ >> ever asked anyone to do so.   I think it would be wrong, justC >> as I think it is wrong for him to make such claims to my client.  > ? > I can't believe this guy.   I just got a call from my client.mA > He said that Dan Swartwood called him again today, still tryingl= > to drag them into this.   Doesn't Hewlett-Packard have somer7 > rules for employees about ethical and legal behavior?     G Make a scrupulous concurrent log of everything that occured and have ite witnessed. Contact your lawyer.t   ------------------------------    Date: 23 Oct 2003 19:15:00 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)u3 Subject: Sun and the high cost of SPARC developmente= Message-ID: <cf15391e.0310231815.32f51ad5@posting.google.com>s  D "Japanese electronics giant Fujitsu and Sun Microsystems have agreedA to merge their high-performance server businesses, according to a. published report." http://www.marketwatch.com/news/yhoo/story.asp?source=blq/yhoo&siteid=yhoo&dist=yhoo&guid=%7B89313627%2DE309%2D4859%2DA889%2D6D5CDC39DEE2%7D  F "A move by struggling network computer maker Sun Microsystems Inc. andB Japan's Fujitsu Ltd. to merge their high-end server business couldF help Sun cut costs, analysts said on Thursday, even as some questioned! whether that would go far enough.e ...xF For Sun, which has reported a string of losses and falling revenue forD 10 quarters, striking a deal with Fujitsu could help cut expenses as4 it angles to return to profitability, analysts said.  C Toni Sacconaghi, an analyst at Sanford C. Bernstein, estimated in a C note to clients that if Sun and Fujitsu jointly developed the Sparc A processor, that alone could save Sun $200 million, or 4 cents pert share, annually.  D Joint development of Sparc chips and servers could potentially yield, savings of as much as $400 million, he said.  C Sun spends about $400 million on processor research and development ; annually, Sacconaghi estimated, noting that Intel Corp. and A International Business Machines Corp. annually spend far more, $4r% billion and $5 billion, respectively.   B But even with such an arrangement, that might not be enough, other analysts said. ...rF "The long-term viability of the Sun architecture that they use is openF to question and the two companies need to do something about it," HSBC analyst Steve Myers said."  B http://biz.yahoo.com/rc/031023/tech_sunmicrosystems_fujitsu_1.html   ------------------------------  % Date: Thu, 23 Oct 2003 19:35:07 -0700p# From: "Tom Linden" <tom@kednos.com>s7 Subject: RE: Sun and the high cost of SPARC developmenti9 Message-ID: <CIEJLCMNHNNDLLOOGNJIAEBHIFAA.tom@kednos.com>e   >-----Original Message-----e9 >From: Keith Parris [mailto:keithparris_NOSPAM@yahoo.com]e) >Sent: Thursday, October 23, 2003 7:15 PMg >To: Info-VAX@Mvb.Saic.Com4 >Subject: Sun and the high cost of SPARC development >  > E >"Japanese electronics giant Fujitsu and Sun Microsystems have agreednB >to merge their high-performance server businesses, according to a >published report."nD >http://www.marketwatch.com/news/yhoo/story.asp?source=blq/yhoo&siteJ >id=yhoo&dist=yhoo&guid=%7B89313627%2DE309%2D4859%2DA889%2D6D5CDC39DEE2%7D >pG >"A move by struggling network computer maker Sun Microsystems Inc. andaC >Japan's Fujitsu Ltd. to merge their high-end server business could@G >help Sun cut costs, analysts said on Thursday, even as some questionedi" >whether that would go far enough. >...G >For Sun, which has reported a string of losses and falling revenue for E >10 quarters, striking a deal with Fujitsu could help cut expenses asu5 >it angles to return to profitability, analysts said.r >rD >Toni Sacconaghi, an analyst at Sanford C. Bernstein, estimated in aD >note to clients that if Sun and Fujitsu jointly developed the SparcB >processor, that alone could save Sun $200 million, or 4 cents per >share, annually.a >oE >Joint development of Sparc chips and servers could potentially yield - >savings of as much as $400 million, he said.  > D >Sun spends about $400 million on processor research and development< >annually, Sacconaghi estimated, noting that Intel Corp. andB >International Business Machines Corp. annually spend far more, $4& >billion and $5 billion, respectively.  H Sun is obviously aware of those numbers, and it is only a matter of timeL before they abandon Sparc and announce that Sparc is being (has been) portedJ to  _____ .  Even an economic simpleton can see the futility of persistingJ with an architecture that can only fall further behind.  If you add up all thatH was spent developing Alpha and porting SW to it, and had instead applied thatL money to continuing development of the VAX architecture, we might have had aL 3+ GHz VAX today and Digital could have stayed in business.  Sorry, I do notK normally indulge in subjunctive speculations, but some on this newgroup aree toolL fixated on HW, this is about VMS, and that is where the assets reside.  Same is0 true for Sun, Solaris has value, Sparc does not.     > C >But even with such an arrangement, that might not be enough, otherr >analysts said.s >...G >"The long-term viability of the Sun architecture that they use is openiG >to question and the two companies need to do something about it," HSBCe >analyst Steve Myers said."w >eC >http://biz.yahoo.com/rc/031023/tech_sunmicrosystems_fujitsu_1.htmlp >e >---' >Incoming mail is certified Virus Free.T; >Checked by AVG anti-virus system (http://www.grisoft.com).sB >Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003 >y ---a& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).A Version: 6.0.530 / Virus Database: 325 - Release Date: 10/22/2003y   ------------------------------    Date: 23 Oct 2003 17:40:05 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)07 Subject: Re: Translating to I64 (was: We buy Alpha ...) 3 Message-ID: <Qeb3yxiTSjyj@eisner.encompasserve.org>y  q In article <k$Rwh3rT+tUJ@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:ne > In article <P0OjD2zzLCv+@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:o >> eD >> I am "selling" TECO, by posting comments in response to any itemsC >> where TECO might solve the problem.  But I actually avoid trying-C >> to overdo it (regardless of how others might judge my postings).z > D >    Did anyone ever make a commitment to make TECO work on VMS I64?= >    Is that the acid test for translating translated images?t  D I don't believe it is the acid test, since TECO does not access manyD shareable images.   VMS Development has backed away from what shouldE be the acid test, translating Compaq Ada shareable images (a compiler ( they will not be supporting on Itanium).   ------------------------------  # Date: Thu, 23 Oct 2003 21:08:57 GMTn" From:   VAXman-  @SendSpamHere.ORGI Subject: Tru64 unix Layeredproducts won't install on my OpenVMS machines! 0 Message-ID: <00A27D10.CFB2A024@SendSpamHere.ORG>  J I just arrived home from .IE to find a box that looked like it was the VMSK LP SDK kit for Q4.  Wrong I was.  I was shipped a Tru64 unix LP SDK KIT Q4.n  K Who do I contact to correct this?  There's an address on the shipping labeltK for H-P Company, Americas' Software Manufacturing, Avard Street, Nashua, NH - but no telco numbers anywhere on the package.h  J This is *NOT* the first time this has happened and as a cause of it I have% holes in my OpenVMS LP SDK continuum.s   --  L VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)COM            o5   "Well my son, life is like a beanstalk, isn't it?" t   ------------------------------  % Date: Thu, 23 Oct 2003 17:06:44 -0500a( From: Wayne Sewell <wayne@tachysoft.com>M Subject: Re: Tru64 unix Layeredproducts won't install on my OpenVMS machines!c/ Message-ID: <00A27D10.7FE0FB69.3@tachysoft.com>o   >X-Newsgroups: comp.os.vmsJ >Subject: Tru64 unix Layeredproducts won't install on my OpenVMS machines!! >From: VAXman-  @SendSpamHere.ORGe >Organization: TMESIS Software >iK >I just arrived home from .IE to find a box that looked like it was the VMS L >LP SDK kit for Q4.  Wrong I was.  I was shipped a Tru64 unix LP SDK KIT Q4. >eL >Who do I contact to correct this?  There's an address on the shipping labelL >for H-P Company, Americas' Software Manufacturing, Avard Street, Nashua, NH. >but no telco numbers anywhere on the package. >pK >This is *NOT* the first time this has happened and as a cause of it I havez& >holes in my OpenVMS LP SDK continuum. >f  O Crap.  I got one of those too.  It's hard to imagine anything more useless thane+ software that will install only on eunuchs.    WaynelO =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html   oO ===============================================================================dH Randolph Duke (in Trading Places): "Mother always said you were greedy."1    Mortimer Duke: "She meant it as a compliment!"    ------------------------------  # Date: Thu, 23 Oct 2003 23:12:30 GMT)" From:   VAXman-  @SendSpamHere.ORGM Subject: Re: Tru64 unix Layeredproducts won't install on my OpenVMS machines! 0 Message-ID: <00A27D22.12286385@SendSpamHere.ORG>  Z In article <00A27D10.7FE0FB69.3@tachysoft.com>, Wayne Sewell <wayne@tachysoft.com> writes: >>X-Newsgroups: comp.os.vmsaK >>Subject: Tru64 unix Layeredproducts won't install on my OpenVMS machines! " >>From: VAXman-  @SendSpamHere.ORG >>Organization: TMESIS Softwareh >>L >>I just arrived home from .IE to find a box that looked like it was the VMSM >>LP SDK kit for Q4.  Wrong I was.  I was shipped a Tru64 unix LP SDK KIT Q4.  >>M >>Who do I contact to correct this?  There's an address on the shipping labelRM >>for H-P Company, Americas' Software Manufacturing, Avard Street, Nashua, NHe/ >>but no telco numbers anywhere on the package.w >>L >>This is *NOT* the first time this has happened and as a cause of it I have' >>holes in my OpenVMS LP SDK continuum.  >> >rP >Crap.  I got one of those too.  It's hard to imagine anything more useless than, >software that will install only on eunuchs.  J OK... Seems then that it is some hiccup in their system.  As long as I getJ my VMS SDK Q4, I'll be happy.  As for the Tru64 unix SDK CDs, I have a set of new beer coasters.f   -- bL VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)COM            t5   "Well my son, life is like a beanstalk, isn't it?" >   ------------------------------  + Date: Thu, 23 Oct 2003 21:13:05 -0500 (CDT)b From: sms@antinode.orgM Subject: Re: Tru64 unix Layeredproducts won't install on my OpenVMS machines!o) Message-ID: <03102321130512@antinode.org>>  " From:   VAXman-  @SendSpamHere.ORG  4 > [...]  As for the Tru64 unix SDK CDs, I have a set > of new beer coasters.t  B    If the layered product licenses for noncommercial Tru64 were asH liberal as those for hobbyist VMS, _I_ would be _happy_ to take them offE your hands.  Unfortunately, I don't know what good they are without a> more extensive license set.   H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode,orgo    Saint Paul  MN  55105-2547    ------------------------------  # Date: Fri, 24 Oct 2003 02:39:59 GMT # From: "John Smith" <a@nonymous.com>wM Subject: Re: Tru64 unix Layeredproducts won't install on my OpenVMS machines! J Message-ID: <3i0mb.263108$ko%.256001@news04.bloor.is.net.cable.rogers.com>    VAXman- @SendSpamHere.ORG wrote:D > I just arrived home from .IE to find a box that looked like it wasF > the VMS LP SDK kit for Q4.  Wrong I was.  I was shipped a Tru64 unix > LP SDK KIT Q4. > G > Who do I contact to correct this?  There's an address on the shippingi@ > label for H-P Company, Americas' Software Manufacturing, AvardB > Street, Nashua, NH but no telco numbers anywhere on the package.    L Send them to carly(tm) with an explanatory note outlining your problems with HP over this and other issues.   3000 Hanover Streeth Palo Alto, California 94304C   (650) 857-1501   ------------------------------  % Date: Thu, 23 Oct 2003 14:24:18 -0500h1 From: "Grealy, Patrick" <PGrealy@sph.uth.tmc.edu>d- Subject: RE: User permissions vs. volume ACLsAL Message-ID: <EEC575D39D864C4BBAE8CD309982B0F20714EE@sphnt33.sph.uth.tmc.edu>   Hi, I For JF Mezei and anyone else interested, I finally  determined that the = E problem was with protections on file [000000]000000.dir . This file =.H seems to need W:E permission and somehow it had been turned off. - Pat = G.   > -----Original Message-----3 > From: JF Mezei [mailto:jfmezei.spamnot@istop.com] ) > Sent: Tuesday, October 21, 2003 8:04 PM  > To: Info-VAX@Mvb.Saic.Coma/ > Subject: Re: User permissions vs. volume ACLsh >=20 >=20 > "Grealy, Patrick" wrote: > > AXP>direA > > %DIRECT-E-OPENIN, error opening $1$DUA300:[RPB]*.*;* as input C > > -RMS-E-PRV, insufficient privilege or file protection violation@ >=20 >=20B > Do you have security alarms enabled on the operator console ?=20 > The alarmeF > generated by the above would tell you exactly which resource failed. >=20; > make sure that $1$dua300:[000000]rpb.dir is owned by RPB.y >=20? > Also, in the ACL for the device, should the user also have=20  > "CONTROL" access ? >=20   ------------------------------    Date: 23 Oct 2003 11:30:02 -0700 From: jjnojack@yahoo.com (JJ)   Subject: VMS Text Files --> Unix< Message-ID: <8c7decf3.0310231030.d57989d@posting.google.com>   Hi All,a  E I have about 25 gig worth of data that I need to put on a tape from aaA vms system that is readable and useable on an unix system. I have D tried vmstar and it doesn't write to the tape. The version of VMSTARF is 3-4.1. VMSTAR will let me however make a huge tar ball on the disk.C Once I have all the files in a large tarball on the disk, how can I0F transfer it to a dlt device, so that it can be read on an unix system?    Any help is greatly appreciated.   JJ   ------------------------------  % Date: Thu, 23 Oct 2003 21:00:47 +0200s$ From: Michael Unger <unger@decus.de>$ Subject: Re: VMS Text Files --> Unix9 Message-ID: <bn98m6$ucaf1$1@ID-152801.news.uni-berlin.de>m    On 2003-10-23 20:30, "JJ" wrote:  G > I have about 25 gig worth of data that I need to put on a tape from aoC > vms system that is readable and useable on an unix system. I havesF > tried vmstar and it doesn't write to the tape. The version of VMSTARH > is 3-4.1. VMSTAR will let me however make a huge tar ball on the disk.E > Once I have all the files in a large tarball on the disk, how can I.H > transfer it to a dlt device, so that it can be read on an unix system? > " > Any help is greatly appreciated.  C What about BACKUP /INTERCHANGE to write "standard" records to tape?    Michaeli   -- r; Real names enhance the probability of getting real answers. @ Please do *not* send "Security Patch Notifications" or "SecurityA Updates"; this system isn't running a Micro$oft operating system.y= And don't annoy me <mailto:postmaster@[127.0.0.1]> please ;-)o   ------------------------------  % Date: Thu, 23 Oct 2003 14:54:07 -0400t* From: JF Mezei <jfmezei.spamnot@istop.com>$ Subject: Re: VMS Text Files --> Unix) Message-ID: <3F9823C9.4F3191C9@istop.com>s  	 JJ wrote:oG > I have about 25 gig worth of data that I need to put on a tape from aa< > vms system that is readable and useable on an unix system.  H > is 3-4.1. VMSTAR will let me however make a huge tar ball on the disk.    D Have you tried creating an ANSI tape on VMS and reading it on Unix ?  N Also, are your files "vms" text files (variable length records) or "unix" text files (streamlf) ?  N If they are variable length files, you may wish to convert them to streamlf so$ that Unix can process them natively.  M Have yo considered using FTP or kermit to move the data ? that would load theM& files in a text format native to Unix.   ------------------------------  + Date: Thu, 23 Oct 2003 20:02:41 +0000 (UTC)o, From: lewis@PROBE.mitre.org (Keith A. Lewis)$ Subject: Re: VMS Text Files --> Unix. Message-ID: <bn9c51$iiv$1@newslocal.mitre.org>  { JF Mezei <jfmezei.spamnot@istop.com> writes in article <3F9823C9.4F3191C9@istop.com> dated Thu, 23 Oct 2003 14:54:07 -0400:i
 >JJ wrote:H >> I have about 25 gig worth of data that I need to put on a tape from a= >> vms system that is readable and useable on an unix system.t > I >> is 3-4.1. VMSTAR will let me however make a huge tar ball on the disk.  >e >CE >Have you tried creating an ANSI tape on VMS and reading it on Unix ?   + I think what he's asking is how to do that.  And I *think* the answer is:   $ init mka500 xxxl $ mount/for mka500 $ copy tarball.tar mka500: $ dismount mka500e  % (assuming your tape device is mka500)t  7 ..or see the VMSTAR help for a single-command solution.i  O >Also, are your files "vms" text files (variable length records) or "unix" textp >files (streamlf) ?i  J Even my old copy of VMSTAR 1.6 converts "Variable length" to "Stream_LF". K Nothing to worry about there.  I assume version 3-4.1 is as good or better.G  0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------   Date: 23 OCT 2003 19:58:47 GMT+ From: Dave Greenwood <greenwoodde@ornl.gov>p$ Subject: Re: VMS Text Files --> Unix2 Message-ID: <23OCT03.19584792@feda01.fed.ornl.gov>  5 In a previous article, jjnojack@yahoo.com (JJ) wrote: 	 > Hi All,v >  nG > I have about 25 gig worth of data that I need to put on a tape from asC > vms system that is readable and useable on an unix system. I have-F > tried vmstar and it doesn't write to the tape. The version of VMSTARH > is 3-4.1. VMSTAR will let me however make a huge tar ball on the disk.E > Once I have all the files in a large tarball on the disk, how can I H > transfer it to a dlt device, so that it can be read on an unix system? >   " > Any help is greatly appreciated. >    > JJ  E I don't believe I've ever actually tried it, but the help file for my F version of VMSTAR (V3.3-4) gives examples of writing to tape.  So whatD error messages do you get when you try to write to tape with VMSTAR?? And what options did you use?  If you're using unix-style ("-")dC options, I suspect you need to define the logical $TAPE to point to  your tape drive.   Dave --------------9 Dave Greenwood                Email: Greenwoodde@ORNL.GOVyH Oak Ridge National Lab        %STD-W-DISCLAIMER, I only speak for myself   ------------------------------    Date: 23 Oct 2003 15:02:25 -0600 From: briggs@encompasserve.org$ Subject: Re: VMS Text Files --> Unix3 Message-ID: <PUdoyB3TvTp4@eisner.encompasserve.org>o  \ In article <8c7decf3.0310231030.d57989d@posting.google.com>, jjnojack@yahoo.com (JJ) writes:	 > Hi All,i > G > I have about 25 gig worth of data that I need to put on a tape from ahC > vms system that is readable and useable on an unix system. I have F > tried vmstar and it doesn't write to the tape. The version of VMSTARH > is 3-4.1. VMSTAR will let me however make a huge tar ball on the disk.E > Once I have all the files in a large tarball on the disk, how can I9H > transfer it to a dlt device, so that it can be read on an unix system?  @ Your tarball on disk should be a file with fixed length 512 byte! records with no carriage control.e  B I believe a Unix tar tape defaults to a blocking factor of 20 to 1@ with 10240 bytes per block on tape.  So an appropriate technique is:   5 $ MOUNT /FOREIGN tape-drive: /BLOCK=10240 /RECORD=512u! $ CONVERT tarball.tar tape-drive:s  > It's been a long time since I've had to copy data to a foreign= mounted tape. My recollection is that you need to use CONVERTn? when copying data _to_ tape in order to get the records blockedw( appropriately.  $ COPY won't do the job.  > If all else fails, use dd to copy data from tarball on tape to> tarball on Unix disk and blocking factor on tape should become irrelevant.(   	John Briggs   ------------------------------    Date: 23 Oct 2003 16:44:37 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)l2 Subject: Re: We buy Alpha  - URGENT - DS10 systems3 Message-ID: <k$Rwh3rT+tUJ@eisner.encompasserve.org>p  c In article <P0OjD2zzLCv+@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:i > C > I am "selling" TECO, by posting comments in response to any itemscB > where TECO might solve the problem.  But I actually avoid tryingB > to overdo it (regardless of how others might judge my postings).  B    Did anyone ever make a commitment to make TECO work on VMS I64?;    Is that the acid test for translating translated images?F   ------------------------------  # Date: Fri, 24 Oct 2003 00:37:58 GMT95 From: rdeininger@mindspringdot.com (Robert Deininger)a2 Subject: Re: We buy Alpha  - URGENT - DS10 systemsL Message-ID: <rdeininger-2310032048030001@user-uinj4gt.dialup.mindspring.com>  I In article <fua4m2aLKzas@eisner.encompasserve.org>, Kilgallen@SpamCop.neta (Larry Kilgallen) wrote:  < >In article <3F9736F2.64596355@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:o >> Tim Llewellyn wrote:a >>>  >>> Island wrote:  >>> >n >>> > Geez I knowl >>> > J >>> > But I am buying not selling, so hopefully people won't mind too much >>> >j9 >>> > Sorry Everyone - (Slapping himself on the keyboard)  >>> >n >>> > DT >>> N >>> If the systems are to deploy or expand existing VMS solutions then this is  >>> good news for all VMS users. >> aI >> Then again, sometimes the glass *IS* half-empty. I can't help thinking G >> that if a reseller has to go begging on the open market for product,  >> vendor support may be, well,z ><# >Switching to a newer model (DS15).R >SC >And having mis-estimated the relative demand for DS10s vs. DS10Ls.  >l" >That seems normal for any vendor.  I But in the present case, DS10, DS10L, and DS15 are all available new frommI HP.  I expect Island has customers who need systems at lower cost than HP  offers.a   ------------------------------   End of INFO-VAX 2003.589 ************************