1 INFO-VAX	Tue, 13 Sep 2005	Volume 2005 : Issue 511       Contents:9 ANNOUNCEMENT: Major HP Announcement - OK for external use = Re: ANNOUNCEMENT: Major HP Announcement - OK for external use = Re: ANNOUNCEMENT: Major HP Announcement - OK for external use = Re: ANNOUNCEMENT: Major HP Announcement - OK for external use = Re: ANNOUNCEMENT: Major HP Announcement - OK for external use = Re: ANNOUNCEMENT: Major HP Announcement - OK for external use  Re: DECnet proxy problem Re: DECnet proxy problem Re: DECnet proxy problem) DECwrite style sheets for documentation ?  Disaster recovery: DNS servers  Re: EFI/console general question  Re: EFI/console general question  Re: EFI/console general question  Re: EFI/console general question  ES40 network connection problems9 Re: Former Intel chief architect (P4) shoots from the hip % Hobbyist : VAX/DEC Document License ?  Re: HP Forum location  Re: HP Forum location * Re: HP to dump itanium - bring back alpha? Re: Itanium Solutions Alliance Re: Itanium Solutions Alliance- Re: OpenVMS  FTP server with these features ? - Re: OpenVMS  FTP server with these features ? - Re: OpenVMS  FTP server with these features ? - Re: OpenVMS  FTP server with these features ? , Re: OpenVMS FTP server with these features ?, Re: OpenVMS FTP server with these features ?% Re: OT: Sun's quarterly announcements % Re: OT: Sun's quarterly announcements % Re: OT: Sun's quarterly announcements % Re: OT: Sun's quarterly announcements % Re: OT: Sun's quarterly announcements % Re: OT: Sun's quarterly announcements % Re: OT: Sun's quarterly announcements % Re: OT: Sun's quarterly announcements % Re: OT: Sun's quarterly announcements % Re: OT: Sun's quarterly announcements % Re: OT: Sun's quarterly announcements % Re: OT: Sun's quarterly announcements % Re: OT: Sun's quarterly announcements % Re: OT: Sun's quarterly announcements   Re: Personal Thoughts on Sept 11) Re: Postings  (was Re: HP Forum location) ) Re: Postings  (was Re: HP Forum location) ) Re: Postings  (was Re: HP Forum location) ! Re: Sun's quarterly announcements ! Re: Sun's quarterly announcements ! Re: Sun's quarterly announcements   F ----------------------------------------------------------------------    Date: 12 Sep 2005 11:41:41 -0700! From: susan_skonetski@hotmail.com B Subject: ANNOUNCEMENT: Major HP Announcement - OK for external useC Message-ID: <1126550501.804667.299100@g14g2000cwa.googlegroups.com>    Dear Folks,   A Please note that HP is pleased to announce OpenVMS V8.2-1. Due to C customer demand, we accelerated the availability of support for our A mid-range and high end HP Integrity servers by almost a year.  In C addition to the entry-class HP Integrity rx1620, rx2620, and rx4640 G Servers, OpenVMS version 8.2-1 for HP Integrity servers adds OpenVMS to G the cell-based Integrity servers to include the HP Integrity Superdome, D rx8620, and rx7620 Servers.  With today's announcement, OpenVMS with< enhanced virtualization capabilities also now supports mixedB architecture clusters of up to as many as 96 nodes on HP IntegrityD servers, AlphaServer systems, or both.  This allows for enhanced TCOA and greater investment protection by capitalizing on the multi-OS $ capabilities of HP Integrity servers  E Please visit the following web site for the complete announcement for B everything announced today.  This is much more than 8.2-1 and well worth reading.  : http://www.hp.com/hpinfo/newsroom/press/2005/050912xa.html  
 Warm Regards,  Sue    ------------------------------  % Date: Mon, 12 Sep 2005 20:28:44 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> F Subject: Re: ANNOUNCEMENT: Major HP Announcement - OK for external use, Message-ID: <43261D3B.1540D44D@teksavvy.com>  " susan_skonetski@hotmail.com wrote:C > Please note that HP is pleased to announce OpenVMS V8.2-1. Due to E > customer demand, we accelerated the availability of support for our @ > mid-range and high end HP Integrity servers by almost a year.       G Sue, wasn't the release of 8.2-1 planned for sept 2005 all along ? I am 2 puzzled by the "one year ahead of schedule" issue.    D Note that even if 8.2-1 is being released on-time, it is an industry7 gold medal since usually, products rarely ship on time.    ------------------------------  % Date: Mon, 12 Sep 2005 20:47:57 -0400 ' From: Dave Froble <davef@tsoft-inc.com> F Subject: Re: ANNOUNCEMENT: Major HP Announcement - OK for external use0 Message-ID: <11ic8544kbig62a@corp.supernews.com>   JF Mezei wrote: $ > susan_skonetski@hotmail.com wrote: > C >>Please note that HP is pleased to announce OpenVMS V8.2-1. Due to E >>customer demand, we accelerated the availability of support for our @ >>mid-range and high end HP Integrity servers by almost a year.  >  >  >  > I > Sue, wasn't the release of 8.2-1 planned for sept 2005 all along ? I am 4 > puzzled by the "one year ahead of schedule" issue.  G Duh!  What part of "we accelerated the availability of support for our  F mid-range and high end HP Integrity servers by almost a year"?  8.2-1 F may be on time, but unless I misread the roadmaps, the high end stuff ! wasn't to be supported this soon.   C Duh!  Watch me be wrong on this one because I'm too lazy to go and   re-read the roadmaps.  :-)   --  4 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: Tue, 13 Sep 2005 02:39:15 GMT 1 From: Keith Parris <keithparris_NOSPAM@yahoo.com> F Subject: Re: ANNOUNCEMENT: Major HP Announcement - OK for external use3 Message-ID: <nZqVe.12491$Zc3.8896@news.cpqcorp.net>    Dave Froble wrote:I > Duh!  What part of "we accelerated the availability of support for our  H > mid-range and high end HP Integrity servers by almost a year"?  8.2-1 H > may be on time, but unless I misread the roadmaps, the high end stuff # > wasn't to be supported this soon.   I Dave is correct. As a result of customer feedback, the 8.2-1 release was  D conceived, developed, and now shipped. Previous plans were to first * support the larger systems in version 8.3.   ------------------------------  % Date: Tue, 13 Sep 2005 00:01:26 -0400 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>F Subject: Re: ANNOUNCEMENT: Major HP Announcement - OK for external use- Message-ID: <43264F06.1173B61A@vaxination.ca>    Keith Parris wrote: J > Dave is correct. As a result of customer feedback, the 8.2-1 release wasE > conceived, developed, and now shipped. Previous plans were to first , > support the larger systems in version 8.3.    A Ok, I must have completely dreamed up roadmap plans to have 8.2-1 H released in fall on 2005 on IA64 only to support the larger systems thatH 8.2 didn't support and bring missing features to IA64 (such as clustring
 of 96 nodes).    ------------------------------  % Date: Tue, 13 Sep 2005 01:20:44 -0400 ' From: Ken Robinson <kenrbnsn@gmail.com> F Subject: Re: ANNOUNCEMENT: Major HP Announcement - OK for external use6 Message-ID: <7dd80f60509122220636cfa3b@mail.gmail.com>  ; On 9/13/05, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:  > Keith Parris wrote: L > > Dave is correct. As a result of customer feedback, the 8.2-1 release wa= s G > > conceived, developed, and now shipped. Previous plans were to first . > > support the larger systems in version 8.3. >=20 >=20C > Ok, I must have completely dreamed up roadmap plans to have 8.2-1 J > released in fall on 2005 on IA64 only to support the larger systems thatJ > 8.2 didn't support and bring missing features to IA64 (such as clustring > of 96 nodes).  =20 A That was the roadmap that was put out after the announcement that D 8.2-1 was going to made. Before that the roadmaps indicated that the, big machines wouldn't be supported until 8.3   Ken Robinson   ------------------------------  % Date: Mon, 12 Sep 2005 14:35:06 -0400 ' From: Dave Froble <davef@tsoft-inc.com> ! Subject: Re: DECnet proxy problem 0 Message-ID: <11ibi9th8531a54@corp.supernews.com>   pierre.bru@gmail.com wrote:  > hello, > E > it's been awhile that I have a strange problem with DECnet proxies:  >  > $ dir 0::  > 
 >   works but  >  > $ dir TLSAXJ::8 > %DIRECT-E-OPENIN, error opening TLSAXJ::*.*;* as input1 > -RMS-E-FND, ACP file or directory lookup failed > > -SYSTEM-F-INVLOGIN, login information invalid at remote node  # You're looking for a proxy problem.   I I forget the default directory used if non is supplied, but I think it's  E the SYS$LOGIN on the local system.  Does that directory exist on the  I remote system?  The second line in the above messages seems pretty clear  C that it cannot find a directory.  The third line seems to indicate  I either a proxy issue, or the Username doesn't exist on the remote system.   I A good way to segragate problems is to first do the operation specifying  E the username and password in the node specification.  If this works,  ! then move on to looking at proxy.    --  4 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: 12 Sep 2005 14:00:09 -0700 From: pierre.bru@gmail.com! Subject: Re: DECnet proxy problem C Message-ID: <1126558809.811044.213900@f14g2000cwb.googlegroups.com>   F oh yes, I forgot to tell on *important* thing: node TLSAXJ is the nodeG I am connected on. so "$ dir tlsaxj::" and "$ dir 0::" shoud be exactly  the same thing...   D I tried "$ set h tlsaxj" and "$ telnet tlsaxj" to check both IP host9 name and DECnet host name and they both work as expected.    Pierre.    ------------------------------  # Date: Tue, 13 Sep 2005 02:29:31 GMT A From: "Colin Butcher" <colin_DOT.butcher_AT@xdelta_DOT.co_DOT.uk> ! Subject: Re: DECnet proxy problem > Message-ID: <fQqVe.107721$G8.48917@text.news.blueyonder.co.uk>  A In which case have you tried UAF ADD/PROXY 0::USER USER/DEFAULT ?   A What is the entry in the proxy database for your node & username?    --     Hope this helps, Colin. ) colin DOT butcher AT xdelta DOT co DOT uk E It's not mine, but I like this definition: Legacy = stuff that works.    ------------------------------  % Date: Mon, 12 Sep 2005 14:35:19 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: DECwrite style sheets for documentation ?, Message-ID: <4325CA61.FD115AE1@teksavvy.com>  > Does anyone have some DECwrite style sheets that can mimic theA style/output of VAXdocument  for documentation ? (with perhaps an F example document to show what styles o apply to what and how to create table of contents etc etc).    ------------------------------  % Date: Tue, 13 Sep 2005 01:44:32 -0400 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>' Subject: Disaster recovery: DNS servers , Message-ID: <43266728.C3228339@teksavvy.com>  D FYI, shortlty after Katrina, the www.neworleans.com web site was notE only down, but its name could not be resolved as both the dns servers  were also offline.  F So when planning your disaster recovery, if you are using external DNSG services, you need to ensure that the DNS servers complement each other H instead of being right next to each other. If they go down, so does your
 net presence.    ------------------------------  % Date: Mon, 12 Sep 2005 14:22:43 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ) Subject: Re: EFI/console general question , Message-ID: <4325C771.CC41D374@teksavvy.com>   FredK wrote:J > Microsoft is one of the main proponents of EFI along with Intel.  But toN > break the BIOS barrier takes a lot of coordination and convincing.  RememberJ > that there is a small industry in BIOS, and a lot of historical baggage.  G Is the reason Windows isn't supporting EFI with Longhorn more political  than technical ?  , Could Windows be packaged to support both ?   E BIOS loads a boot block from a fixed disk location, is that correct ?   G EFI loads a boot-loader from a disk partition. So Windows could provide H a boot loader that then loads an alternate Windows boot block, one whichF cooperates with EFI software during very early phases of boot. Is this theoretically possible ?   ------------------------------  % Date: Mon, 12 Sep 2005 12:13:44 -0700 # From: "Tom Linden" <tom@kednos.com> ) Subject: Re: EFI/console general question ( Message-ID: <opswz7o6cgzgicya@hyrrokkin>  . On Mon, 12 Sep 2005 14:22:43 -0400, JF Mezei  % <jfmezei.spamnot@teksavvy.com> wrote:    > FredK wrote:K >> Microsoft is one of the main proponents of EFI along with Intel.  But to H >> break the BIOS barrier takes a lot of coordination and convincing.    >> Remember K >> that there is a small industry in BIOS, and a lot of historical baggage.  > I > Is the reason Windows isn't supporting EFI with Longhorn more political  > than technical ? > - > Could Windows be packaged to support both ?  > G > BIOS loads a boot block from a fixed disk location, is that correct ?  > I > EFI loads a boot-loader from a disk partition. So Windows could provide J > a boot loader that then loads an alternate Windows boot block, one whichH > cooperates with EFI software during very early phases of boot. Is this > theoretically possible ?  G This sounds like the way Linux was loaded on ARC only Alphas usinf milo H on the FAT partition and then linload from a Unix style partition, IIRC.   ------------------------------  # Date: Mon, 12 Sep 2005 22:41:46 GMT * From: "FredK" <fred.nospam@nospam.dec.com>) Subject: Re: EFI/console general question 4 Message-ID: <KunVe.12479$jb3.11698@news.cpqcorp.net>  : "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message& news:4325C771.CC41D374@teksavvy.com... > FredK wrote:L > > Microsoft is one of the main proponents of EFI along with Intel.  But toF > > break the BIOS barrier takes a lot of coordination and convincing. RememberL > > that there is a small industry in BIOS, and a lot of historical baggage. > I > Is the reason Windows isn't supporting EFI with Longhorn more political  > than technical ? >   F I have no insight into MS.  If I were to guess, I would say that it is because H there is a complicated dance that needs to take place.  The BIOS is usedJ for far more than just booting - and I think the goal is to be BIOS-free - there G is a new driver model (graphics drivers in particular) that is aimed at  eliminating Int10 for example.  - > Could Windows be packaged to support both ?  >   	 Probably.   G > BIOS loads a boot block from a fixed disk location, is that correct ?  >    Block 0.  The MBR.  I > EFI loads a boot-loader from a disk partition. So Windows could provide J > a boot loader that then loads an alternate Windows boot block, one whichH > cooperates with EFI software during very early phases of boot. Is this > theoretically possible ?  J The design of the GUID Partition Table based disk is that block 0 contains
 a legacy MBR.    ------------------------------  % Date: Mon, 12 Sep 2005 18:02:14 -0400 2 From: "Paul A. Jacobi" <Paul.Jacobi@nospam.hp.com>) Subject: Re: EFI/console general question * Message-ID: <4325fb91@usenet01.boi.hp.com>  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  & news:4325C771.CC41D374@teksavvy.com...I > Is the reason Windows isn't supporting EFI with Longhorn more political  > than technical ?  M For Windows to support the EFI console, it needs to supply an EFI OS loader,  4 analogous to VMS_LOADER for VMS and ELILO for Linux.     Paul A. Jacobi OpenVMS System Group
 Nashua, NH   ------------------------------    Date: 12 Sep 2005 18:10:08 -04007 From: "Gareth V. Williams" <graff@cfa0.cfa.harvard.edu> ) Subject: ES40 network connection problems . Message-ID: <4325fcc0@cfanews.cfa.harvard.edu>  B We have an ES40 on which we've just installed V8.2 and a number ofD patches.  We are having a number of network connection problems thatA we've never seen before and which don't appear to be described in @ the HP TCPIP/IP Services for OpenVMS: Tuning and TroubleshootingA manual or to have been discused on comp.os.vms before (at least I ? couldn't find any keywords that would allow DejaNews to display  such messages).   E The machine has joined our cluster and is serving up its disks to the F other cluster members, but we can't SSH/TELNET/FTP/PING to or from the@ new machine and name resolution is broken.  The configuration of@ the BIND resolver looks correct, comparing it to the settings onG other machines.  Yet we can set host (using DECNET-over-IP) to and from B the machine using node names or IP addresses (I presume that it is7 DECNET that is supplying the nodename->IP conversions).    What is odd are the following:   $ tcpip show arp6 Cnt  Flags    Timer Host                     Phys Addr/   1: US         134 131.142.xx.xx            #0   8 (Bits of the new machine's IP address have been munged.)C Other machines in the cluster show MAC addresses under Phys Addr.   ! What is the significance of "#0"?    Also:    $ tcpip netstat -iN Name  Mtu   Network     Address               Ipkts Ierrs    Opkts Oerrs  CollN LO0   4096  <Link>      Link#1                    0     0        0     0     0N LO0   4096  loop        LOCALHOST                 0     0        0     0     0N TN0*  1280  <Link>      Link#2                    0     0        0     0     0N TN1*  1280  <Link>      Link#3                    0     0        0     0     0N WE1   1500  <Link>      08:00:2b:xx:xx:xx         0     0       63     0     0N WE1   1500  loop        memele                    0     0       63     0     0  G but it takes more than a minute for it to display the information (the  : last three hex bytes of the MAC address have been munged).  F Are these symptomatic of a misconfiguration of TCPIP (extensive checksE with the configuration of other cluster members shows no difference), > a problem with the interface card (unlikely, otherwise "Why is? DECNET-over-IP working?") or a misconfiguration of the network? D Our Computation Facility is adamant that the new machine is properly registered on the network.  H As we've never seen anything like this before, any pointers from someone who has would be appreciated.       Gareth Williams   --  H ------------------------------------------------------------------------H Gareth V. Williams, MS 18, 60 Garden Street, Cambridge, MA 02138, U.S.A.+ Associate Director, IAU Minor Planet Center H gwilliams@cfa.harvard.edu        http://cfa-www.harvard.edu/iau/mpc.html7 OpenVMS & RISC OS: refined choices in operating systems    ------------------------------  % Date: Mon, 12 Sep 2005 14:16:54 -0400 ' From: Dave Froble <davef@tsoft-inc.com> B Subject: Re: Former Intel chief architect (P4) shoots from the hip0 Message-ID: <11ibh7mjc4f4896@corp.supernews.com>   Keith Parris wrote:  > Neil Rieck wrote:  > 9 >> Former Intel chief architect (P4) shoots from the hip:  >  > D > This is old news, in fact from way back in February 2004, and was & > already discussed here at the time: H > http://groups.google.com/group/comp.os.vms/msg/fa5c5d665ad8bf47?hl=en&  % And still interesting and meaningful.    --  4 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: Tue, 13 Sep 2005 00:53:29 -0400 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>. Subject: Hobbyist : VAX/DEC Document License ?- Message-ID: <43265B35.7E392763@vaxination.ca>   G Just realised that the big list of licences that come with the hobbyist 2 emails does not include VAX Document/DEC Document.  H I realise that at one time, Palmer had given the product away to anotherC company, but hasn't it returned to the owner of VMS when that other F company abandonned the product ? What is the status of DEC Document in terms of who owns it ?  E Perhaps Sue could look into the possibility of including DEC Document # licence in the hobbyist programme ?    ------------------------------  % Date: Mon, 12 Sep 2005 14:17:47 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>  Subject: Re: HP Forum location, Message-ID: <4325C649.936A9EDD@teksavvy.com>   FredK wrote:B > Come on Larry - spend a few extra days - it's a tax writeoff ;-) > D > All computers and no play makes it attractive to hold a convention > in Saskatoon in February ;-)    B It is easier to justify such a trip to your management since it isH clearly a "necessary evil" business where the employee will learn and be$ more productive for the corporation.  G Having an event next to Disneyworld makes it look more like a perk than  a training conference.  A On the other side of the coin, having it next to Disneyworld will G motivate the employee to work harder to find justification to go there.    ------------------------------  % Date: Mon, 12 Sep 2005 12:50:16 -0700 # From: "Tom Linden" <tom@kednos.com>  Subject: Re: HP Forum location( Message-ID: <opswz9d2k4zgicya@hyrrokkin>  K On Mon, 12 Sep 2005 13:34:13 GMT, FredK <fred.nospam@nospam.dec.com> wrote:    > < > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message/ > news:hlPJ4ZgwMzbH@eisner.encompasserve.org...  >  >>F >> I don't know how to tell you this, Fred, but other sources indicate4 >> there will be computer discussions down there :-) > B > Come on Larry - spend a few extra days - it's a tax writeoff ;-) > D > All computers and no play makes it attractive to hold a convention > in Saskatoon in February ;-) > E Fred, maybe next year could lobby for having at Pinehurst or Pebble    Beach:-)   ------------------------------  # Date: Tue, 13 Sep 2005 02:27:27 GMT 1 From: Keith Parris <keithparris_NOSPAM@yahoo.com> 3 Subject: Re: HP to dump itanium - bring back alpha? 3 Message-ID: <jOqVe.12490$bi3.6264@news.cpqcorp.net>    bob@instantwhip.com wrote:+ > http://www.theinquirer.net/?article=25573   A Illuminata has written a "perspective" paper about this Inquirer  5 article: http://www.illuminata.com/perspectives/?p=76    ------------------------------  # Date: Tue, 13 Sep 2005 02:22:24 GMT 1 From: Keith Parris <keithparris_NOSPAM@yahoo.com> ' Subject: Re: Itanium Solutions Alliance 3 Message-ID: <AJqVe.12489$bi3.3077@news.cpqcorp.net>    JF Mezei wrote: g > http://news.com.com/Itanium+allies+to+pool+development+efforts/2100-1006_3-5844877.html?tag=nefd.lede  ... G > HP--the server maker that has pushed the chip most aggressively--sold E > $108 million in Itanium-based Unix servers in the second quarter of D > 2005, compared with $1.1 billion in the PA-RISC-based Unix servers= > they're intended to replace, according to Gartner figures.    F The Garter figures were wrong, and have been corrected. HP's response:  B "The CNET article describes the formation of an Itanium Solutions F Alliance, another good proof-point on the industry standard nature of G Itanium. The CNET article had some incorrect Gartner market share data   which have been corrected.K WW vendor revenue for Q205 (all operating systems) (Source: Gartner QSTAT): 6 HP Itanium based - US$411M, growing 64% year-over-year! HP PA-RISC based systems- US$778M   HP Alpha based systems - US$175M3 HP Itanium revenue vs. HP PA-RISC - 53% and growing E HP Itanium revenue vs. HP Alpha - more than 2 times the size of HPs   Alpha revenue"   ------------------------------  % Date: Mon, 12 Sep 2005 23:06:52 -0400 ( From: Bill Todd <billtodd@metrocast.net>' Subject: Re: Itanium Solutions Alliance = Message-ID: <OPidnekc-IHG37veRVn-jg@metrocastcablevision.com>    Keith Parris wrote:    ...   M > WW vendor revenue for Q205 (all operating systems) (Source: Gartner QSTAT): 8 > HP Itanium based - US$411M, growing 64% year-over-year# > HP PA-RISC based systems- US$778M " > HP Alpha based systems - US$175M5 > HP Itanium revenue vs. HP PA-RISC - 53% and growing G > HP Itanium revenue vs. HP Alpha - more than 2 times the size of HPs   > Alpha revenue"  J Interesting numbers, especially when compared with those from 5 years ago:  G Tru64 system revenue was about $3 billion annually, and IIRC was about  F 1/3 of what HP-UX generated (the Big 3 Unixes had close to 90% of the I large Unix server market back then split fairly evenly among them, while  H Tru64 had around 10% but was gaining ground fast, with an annual growth F rate of 30% shortly prior to the Alphacide).  But today HP-UX appears E only to be generating PA-RISC sales about equivalent to what Tru64's  C were back then (plus whatever percentage of Itanic sales are HP-UX  D systems, but that still won't raise the number to even half of what ( HP-UX reportedly used to be generating).  F Tru64 and VMS combined generated about $7 billion in annual revenue - F and while some significant portion of that was VAX-related back then, H had Alpha remained viable one could reasonably expect that it would all C be Alpha revenue today.  In reality, however, today's Alpha system  B revenue appears to be about 1/10th of that number (which not only D highlights just how disastrous Curly's voyage on the Itanic was but G underlines the fact that conversion of the remaining Alpha users isn't  A going to amount to enough to keep the ship afloat in the future).   D So the fact that Itanic is currently generating more than twice the E *current* Alpha system revenue is considerably less notable than the  F fact that it's generating less than 1/4th as much revenue as VMS plus H Tru64 were generating prior to the Alphacide - despite the fact that HP I is selling 4 OSs on the platform (HP-UX, Windows, Linux, and VMS) rather   than just two.  F Now, Gartner's numbers may not include service revenue, in which case G the situation isn't *quite* as bad as described above.  But it doesn't  F change enough to make a substantive difference:  Itanic's vaunted 64% F annual growth rate reflects not wide industry acceptance (just take a I look at sales numbers from the other vendors trying to sell the platform  B if you doubt this) but in large part often-reluctant migration by E existing HP-UX customers (plus a few Tru64 and MPE refugees, and now  6 some from VMS) who feel they have little other choice.  E There's a very simple way to evaluate Itanic's real-world acceptance  H level:  chart HP's overall sales growth in the proprietary systems that D run on it - i.e., offset Itanic's growth figures by the PA-RISC and @ Alpha losses and you'll see whether it's a help or a hindrance. D Whatever number you come up with, you can be damn sure that if it's @ positive at all it will be an order of magnitude lower than 64%.   - bill   ------------------------------    Date: 12 Sep 2005 13:42:53 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 6 Subject: Re: OpenVMS  FTP server with these features ?3 Message-ID: <SBUyCc3sVMlN@eisner.encompasserve.org>   T In article <h5dltJVbeY+S@eisner.encompasserve.org>, briggs@encompasserve.org writes:   D > For restart markers generated on the sending system, a hex dump ofC > an RFA should do.  For restart markers generated on the receiving / > system, the RFA plus a byte offset should do.   G    That limits the REST command to VMS-VMS transfers.  FTP is a generic F    protocol, the UNIX system on the other end hasn't the foggiest what
    an RFA is.    ------------------------------  # Date: Mon, 12 Sep 2005 19:14:41 GMT ( From: Alan Greig <greigaln@netscape.net>6 Subject: Re: OpenVMS  FTP server with these features ?= Message-ID: <BskVe.54425$2n6.44216@fe3.news.blueyonder.co.uk>    Bob Koehler wrote:  V > In article <h5dltJVbeY+S@eisner.encompasserve.org>, briggs@encompasserve.org writes: >    > D >>For restart markers generated on the sending system, a hex dump ofC >>an RFA should do.  For restart markers generated on the receiving / >>system, the RFA plus a byte offset should do.  >  > I >    That limits the REST command to VMS-VMS transfers.  FTP is a generic H >    protocol, the UNIX system on the other end hasn't the foggiest what >    an RFA is.   I But the Unix system doesn't have the foggiest idea about VMS file layout  G in any case. That doesn't mean that the bytes aren't in the same place  D in the raw transfer so I can't see why restart can't be implemented 2 whether or nor the client understands VMS formats.     --  
 Alan Greig   ------------------------------    Date: 12 Sep 2005 14:52:01 -0500 From: briggs@encompasserve.org6 Subject: Re: OpenVMS  FTP server with these features ?3 Message-ID: <oQ0OInx8BSKJ@eisner.encompasserve.org>   q In article <SBUyCc3sVMlN@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: V > In article <h5dltJVbeY+S@eisner.encompasserve.org>, briggs@encompasserve.org writes: >   E >> For restart markers generated on the sending system, a hex dump of D >> an RFA should do.  For restart markers generated on the receiving0 >> system, the RFA plus a byte offset should do. > I >    That limits the REST command to VMS-VMS transfers.  FTP is a generic H >    protocol, the UNIX system on the other end hasn't the foggiest what >    an RFA is.   E Read what I wrote the next time.  Or read RFC 959.  You have no clue.   C The VMS-generated restart marker is used on the VMS side.  The Unix , system never needs to position to a VMS RFA.  $ Let me take it from the top, slowly.  = Let's try the easy example.  There's a VMS FTP server.  We're D on a Unix FTP client.  And we're downloading a file.  The VMS system% is the sender and we're the receiver.   
 OK so far?  A The VMS system sends a bunch of data in FTP block mode.  And then C it sends a restart marker.  The restart marker is an RFA encoded as H a hex string.  It is embedded into the data stream but is not treated as@ part of the file data.  This can be done because we're doing the transfer in block mode.   E The FTP client sees the restart marker and remembers both that marker > and the local file position to which it corresponds.  Maybe itD does this internally.  Maybe it reports both to the user.  Whatever.2 This part is out of the scope of the FTP protocol.   The transfer blows up.  B Either automatically or at the command of the user the client thenB reconnects to the VMS machine.  It transmits the restart code thatB it retrieved from the restart marker.  It positions the local fileA to the corresponding remembered position.  It then sends the RETR I command to tell the VMS server to pick the transfer up where it left off.   A The VMS system gets the REST command including the hex-coded RFA. = It gets the RETR command that identifies the associated file. + It picks up the transfer where it left off.   B Note well.  The client never needed to know that the restart value> was an RFA.  The VMS side both generated and used a VMS formatA restart value.  The client stored and used it as an opaque string  value.   You still with me?  > There are three other cases to cover.  VMS receiver as server,- VMS sender as client, VMS receiver as client.   = Some of the details will vary in those cases.  But the bottom < line is the same.  An RFA-format restart code generated on a? VMS system ends up being used on a VMS system.  It is presented 0 on the non-VMS system as an opaque string value.   	John Briggs   ------------------------------  % Date: Mon, 12 Sep 2005 19:54:30 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>6 Subject: Re: OpenVMS  FTP server with these features ?+ Message-ID: <43262345.BECD97CB@comcast.net>    briggs@encompasserve.org wrote:  > s > In article <SBUyCc3sVMlN@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: X > > In article <h5dltJVbeY+S@eisner.encompasserve.org>, briggs@encompasserve.org writes: > > G > >> For restart markers generated on the sending system, a hex dump of F > >> an RFA should do.  For restart markers generated on the receiving2 > >> system, the RFA plus a byte offset should do. > > K > >    That limits the REST command to VMS-VMS transfers.  FTP is a generic J > >    protocol, the UNIX system on the other end hasn't the foggiest what > >    an RFA is.  > G > Read what I wrote the next time.  Or read RFC 959.  You have no clue.  > E > The VMS-generated restart marker is used on the VMS side.  The Unix . > system never needs to position to a VMS RFA. > & > Let me take it from the top, slowly. > ? > Let's try the easy example.  There's a VMS FTP server.  We're F > on a Unix FTP client.  And we're downloading a file.  The VMS system' > is the sender and we're the receiver.  >  > OK so far? > C > The VMS system sends a bunch of data in FTP block mode.  And then E > it sends a restart marker.  The restart marker is an RFA encoded as J > a hex string.  It is embedded into the data stream but is not treated asB > part of the file data.  This can be done because we're doing the > transfer in block mode.  > G > The FTP client sees the restart marker and remembers both that marker @ > and the local file position to which it corresponds.  Maybe itF > does this internally.  Maybe it reports both to the user.  Whatever.4 > This part is out of the scope of the FTP protocol. >  > The transfer blows up. > D > Either automatically or at the command of the user the client thenD > reconnects to the VMS machine.  It transmits the restart code thatD > it retrieved from the restart marker.  It positions the local fileC > to the corresponding remembered position.  It then sends the RETR K > command to tell the VMS server to pick the transfer up where it left off.  > C > The VMS system gets the REST command including the hex-coded RFA. ? > It gets the RETR command that identifies the associated file. - > It picks up the transfer where it left off.  > D > Note well.  The client never needed to know that the restart value@ > was an RFA.  The VMS side both generated and used a VMS formatC > restart value.  The client stored and used it as an opaque string  > value. >  > You still with me? > @ > There are three other cases to cover.  VMS receiver as server,/ > VMS sender as client, VMS receiver as client.  > ? > Some of the details will vary in those cases.  But the bottom > > line is the same.  An RFA-format restart code generated on aA > VMS system ends up being used on a VMS system.  It is presented 2 > on the non-VMS system as an opaque string value.  G ...and how many current FTP, HTTP, etc. clients would be compliant with  that scheme?   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/    Coming soon:& Unofficial OpenVMS Marketing Home Page   ------------------------------  % Date: Mon, 12 Sep 2005 19:47:28 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>5 Subject: Re: OpenVMS FTP server with these features ? * Message-ID: <432621A0.1F9ED07@comcast.net>   pierre.bru@gmail.com wrote:  > 2 > > I cross-posted this to the Multinet newsgroup. > # > where can I read this newsgroup ?   C Same place you read this one. Just change the group name (on Google G groups, you may need to click a link to see the full header information 4 for a post so you can see the other newsgroup name).  S > > I wonder if PSC could be pursuaded to add REST support for binary files only...  >  > why binary files only ?   - See http://www.djesys.com/vms/mentor/rms.html    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/    Coming soon:& Unofficial OpenVMS Marketing Home Page   ------------------------------  % Date: Mon, 12 Sep 2005 20:16:59 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>5 Subject: Re: OpenVMS FTP server with these features ? + Message-ID: <4326288A.42D68717@comcast.net>    Hunter Goatley wrote:  > 4 > > > I cross-posted this to the Multinet newsgroup. > % > > where can I read this newsgroup ?  > < > vmsnet.networks.tcp-ip.multinet, which is gatewayed to the > Info-MultiNet mailing list.  > U > > > I wonder if PSC could be pursuaded to add REST support for binary files only...  >  > > why binary files only ?  > E > The REST command works by restarting a download at a specified byte D > offset.  The way VMS stores files makes it it difficult to restart@ > such a transfer at a random number of bytes.  This is true forC > fixed-length, 512-byte binary records, but even more so for ASCII H > files, which don't have a direct byte-to-byte correlation for the fileE > on the remote end and the file on the VMS side.  That would make it ? > more difficult to implement correctly, though not impossible.  > C > I haven't had time to look into the actual mechanics of making it 3 > work, though I agree that it would be very handy.   B Assuming a "typical" "Fixed-512" file where the first free byte is" before the end of the EOF block...  B Without knowing the actual "mechanics" behind the REGET FTP clientE command, seems to me there's some conversation unseen by the end user E where the client tells the server how much of the file it has and the E server figures out much to resend. If the client says, "I have 203456 E bytes" and the server knows that the file is 2048 blocks with the FFB B set at 247, it should be able to figure out that it needs to startE reading at block 397, byte offset 193 and transmit from there thru to  block 2048, byte offset 246.   ...shouldn't it?   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/    Coming soon:& Unofficial OpenVMS Marketing Home Page   ------------------------------  % Date: Mon, 12 Sep 2005 14:08:28 -0400 ( From: Bill Todd <billtodd@metrocast.net>. Subject: Re: OT: Sun's quarterly announcements= Message-ID: <G6idnXIvGrCAWbjeRVn-tA@metrocastcablevision.com>    Alan Greig wrote:  > J > Just watched the live webcast of Sun's Q3 seminar. It's Opteron all the " > way as far as Sun are concerned.  E A bit surprising if there was no mention of Niagara, since IIRC it's  I supposed to ship before the end of this year at at least 1 GHz, 8 cores,  F and 4 threads per core (i.e., most likely with significantly superior E aggregate throughput to *any* other single-socket platform currently  9 available, POWER5 possibly but not necessarily excepted).   D And so far I haven't heard whether the Becky Opteron boxes exceed 4 E sockets - and Sun certainly has customers whose interests far exceed  - what 8 Opteron cores (or even 16) can handle.   H For that matter, I'm still very curious about their new ZFS file system G (which AFAIK hasn't yet shipped or been described in real detail yet).  B It sounds as if it may incorporate rather significant advances in G performance and integrity (some that I've been developing myself at my  I normal glacial pace, which is one reason for my interest), but it's hard  ! to tell without more information.   I But perhaps they just confined themselves to products shipping today, in  I which case Opteron is certainly the newest significant news to shout out.    > J > One interesting point for debate: Sun described HP-UX during the Q&A as G > "effectively end-of-lifed" due entirely to the Itanium situation. As  G > that becomes clearer to customers (they say) Sun hopes to grab HP-UX  @ > customers who will prefer Solaris to Windows or Linux from HP.  I Well, they would say that, wouldn't they?  Sun does have an increasingly  G persuasive tale to tell, but it remains to be proven whether customers  G will actually adopt it as aggressively as Sun would like them to.  And  F while HP is certainly the archetype of the boy who cried wolf far too F often, as Itanic wallows forward it remains possible (though far from G certain) that it will gain sufficient traction not to sink beneath the   waves.     But ifF > you want Windows they've also announced Tier 1 Windows support from D > today - which means Sun will support Windows directly rather than F > through a third party. If you really want Linux they had Red Hat on  > stage as well!  C They certainly seem to be addressing x86 across the board far more  E seriously than ever before, and that can't be bad (for them, and for  ) competitiveness throughout the industry).    - bill   ------------------------------  % Date: Mon, 12 Sep 2005 14:29:47 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> . Subject: Re: OT: Sun's quarterly announcements, Message-ID: <4325C916.7A549982@teksavvy.com>   Alan Greig wrote: G > VMS was not mentioned unsurprisingly but presumably they will use the J > same "end-of-lifed" argument. HP sales (especially HP-UX) really need to5 > work out how to counter this. No, I don't know how.     F I think that HP announcing continued sales of PaRisc and Alpha systemsC (as well as MIPS for Tandem) until 2007 would be a great way out of C this. Customers would not be forced to jump into a platform with an E image of having no future, and HP wouldn't have to admit that IA64 is / dead before it had originally planned to do so.   C If HP continues to force customers to IA64, competitors will have a B field day spreadibg lots of credible FUD about that IA64 thing and stealing customers.   R Hurd must be reminded that his duty is to HP shareholders, not Intel shareholders.   ------------------------------  # Date: Mon, 12 Sep 2005 18:58:11 GMT 1 From: Keith Parris <keithparris_NOSPAM@yahoo.com> . Subject: Re: OT: Sun's quarterly announcements3 Message-ID: <7dkVe.12443$O13.1638@news.cpqcorp.net>    Alan Greig wrote: ( > Sun described HP-UX during the Q&A as G > "effectively end-of-lifed" due entirely to the Itanium situation. As  G > that becomes clearer to customers (they say) Sun hopes to grab HP-UX  @ > customers who will prefer Solaris to Windows or Linux from HP.  B HP-UX is in an architecture transition. This is no different than I Solaris moving to Opteron. The destination CPU in both cases is provided  H by a company other than the OS vendor, and is only manufactured by that D one vendor. And AMD is a lot smaller as a sole-source provider than  Intel, which entails more risk.   B And I can't imagine folks moving from HP-UX to Solaris, given the H desperate straits Sun appears to be in these days. It seems to me to be J a little late in Sun's company life cycle to be jumping on board just now.  	 > But if  F > you want Windows they've also announced Tier 1 Windows support from D > today - which means Sun will support Windows directly rather than  > through a third party.  H After years of strong words against Windows from Sun, it must really be H galling to long-time Sun customers to see Sun get so desperate as to be D accepting transfusions of cash from Microsoft and promoting Windows.  = > If you really want Linux they had Red Hat on stage as well!   G Based on the Sun customers I've dealt with, Sun is really hurting from  @ Linux. For one site's web servers, Linux on Intel had twice the I performance at one-tenth the cost of Solaris on Sun, so out went the Sun   web servers.   ------------------------------  % Date: Mon, 12 Sep 2005 14:37:14 -0400 ' From: Dave Froble <davef@tsoft-inc.com> . Subject: Re: OT: Sun's quarterly announcements0 Message-ID: <11ibidrl681svc4@corp.supernews.com>   Alan Greig wrote:  > J > Just watched the live webcast of Sun's Q3 seminar. It's Opteron all the " > way as far as Sun are concerned. > J > One interesting point for debate: Sun described HP-UX during the Q&A as G > "effectively end-of-lifed" due entirely to the Itanium situation. As  G > that becomes clearer to customers (they say) Sun hopes to grab HP-UX  H > customers who will prefer Solaris to Windows or Linux from HP. But if F > you want Windows they've also announced Tier 1 Windows support from D > today - which means Sun will support Windows directly rather than F > through a third party. If you really want Linux they had Red Hat on  > stage as well! > H > VMS was not mentioned unsurprisingly but presumably they will use the K > same "end-of-lifed" argument. HP sales (especially HP-UX) really need to  5 > work out how to counter this. No, I don't know how.   D If you'll remember, Andrew (was he downsized?) claimed that VMS was 9 insignificant and therefore not mentioned as competition.    --  4 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: Mon, 12 Sep 2005 14:37:37 -0400 ( From: Bill Todd <billtodd@metrocast.net>. Subject: Re: OT: Sun's quarterly announcementsR Message-ID: <wNmdnZ2dnZ0qkxmqnZ2dnWpXuN6dnZ2dRVn-052dnZ0@metrocastcablevision.com>   Keith Parris wrote:  > Alan Greig wrote:  > H >> Sun described HP-UX during the Q&A as "effectively end-of-lifed" due A >> entirely to the Itanium situation. As that becomes clearer to  J >> customers (they say) Sun hopes to grab HP-UX customers who will prefer ' >> Solaris to Windows or Linux from HP.  >  > D > HP-UX is in an architecture transition. This is no different than  > Solaris moving to Opteron.  C That, of course, is rubbish.  Because while Solaris is *embracing*  G Opteron, it is not *abandoning* its previous platform as HP-UX is, but  F instead is forging ahead with its SPARC64 partnership with Fujitsu (a B SPARC product that some people here seem to need to be constantly H reminded out-performs Itanic, both per-core and even more so in maximum G system throughput, on several major commercial benchmarks) and its own  ) imminent Niagara and later Rock products.    - bill   ------------------------------  # Date: Mon, 12 Sep 2005 18:53:32 GMT ( From: Alan Greig <greigaln@netscape.net>. Subject: Re: OT: Sun's quarterly announcements; Message-ID: <M8kVe.1674$Kk3.1440@fe1.news.blueyonder.co.uk>    Bill Todd wrote:    G > A bit surprising if there was no mention of Niagara, since IIRC it's    I In today's talk there was no mention of future Sparc products that I can  D recall but I think that the point of today was to talk specifically D about Opteron products. When asked in the Q&A if Sun weren't eating E their own lunch there was some bizarre response about toothpaste and   supermarket shelf-space.  K > supposed to ship before the end of this year at at least 1 GHz, 8 cores,  H > and 4 threads per core (i.e., most likely with significantly superior G > aggregate throughput to *any* other single-socket platform currently  ; > available, POWER5 possibly but not necessarily excepted).  > F > And so far I haven't heard whether the Becky Opteron boxes exceed 4 G > sockets - and Sun certainly has customers whose interests far exceed  / > what 8 Opteron cores (or even 16) can handle.   H All they have actually launched today were the entry models up to 4-way I SMP (2 * 2 core)in a 1U rack format with 16-way promised as coming soon.  I Lots of slides comparing price, performance, heat with Dell, HP, and IBM  H with Dell singled out for special ridicule. Details at www.sun.com now. G I have to admit these things are tiny and look "cool" :-) The cheapest  I single processor server (Sun Fire X2100) starts at an attention grabbing  I $745 but this increases by $500 if you actually want a disk with it. The  F cheapest 4-way server (2* model 275 Opteron dual-core) is $7,395 with ! 4GB RAM, 2*10000 RPM 73Gig disks.    > K > But perhaps they just confined themselves to products shipping today, in  K > which case Opteron is certainly the newest significant news to shout out.    That was pretty much the case.   > G >> you want Windows they've also announced Tier 1 Windows support from  E >> today - which means Sun will support Windows directly rather than  G >> through a third party. If you really want Linux they had Red Hat on   >> stage as well!  >  > E > They certainly seem to be addressing x86 across the board far more  G > seriously than ever before, and that can't be bad (for them, and for  + > competitiveness throughout the industry).  >  > - bill   --  
 Alan Greig   ------------------------------  % Date: Mon, 12 Sep 2005 14:57:38 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> . Subject: Re: OT: Sun's quarterly announcements, Message-ID: <4325CF9B.9B6F33C4@teksavvy.com>   Bill Todd wrote:D > That, of course, is rubbish.  Because while Solaris is *embracing*D > Opteron, it is not *abandoning* its previous platform as HP-UX is,  F While it is true that SPARC still has some development ahead, the sameE reasons that will force HP to dump IA64 and go 8086 will also compell  Sun to do the same.   G The difference is that Sun doesn't try to hide this and has the correct F menatlity of continuing its "legacy" SPARC until the 8086 is ready forG prime time in enterprise large computers. And when it happens, Sun will H already be ready since it will have had Solaris on 8086 running for many many years.   H HP is busy killing its legacy platforms (PaRisc and Alpha) to help boostC IA64 sales and refuses to admit the inevitable that the 8086 is the G future platform and that IA64 is a dud. Unless HP basements are full of G people doing covert ports of HP-UX, VMS and NSK to the 8086, HP will be ? quite late in the game by the time it admits this,  whereas its E competitors will have their OS running on a stable long term platform  for quite some time.   ------------------------------  % Date: Mon, 12 Sep 2005 12:22:21 -0700 # From: "Tom Linden" <tom@kednos.com> . Subject: Re: OT: Sun's quarterly announcements( Message-ID: <opswz73jmfzgicya@hyrrokkin>  H On Mon, 12 Sep 2005 14:08:28 -0400, Bill Todd <billtodd@metrocast.net>   wrote:  @ >  Well, they would say that, wouldn't they?  Sun does have an  E > increasingly persuasive tale to tell, but it remains to be proven   I > whether customers will actually adopt it as aggressively as Sun would   I > like them to.  And while HP is certainly the archetype of the boy who   K > cried wolf far too often, as Itanic wallows forward it remains possible   J > (though far from certain) that it will gain sufficient traction not to   > sink beneath the waves.  > K While this may be true, it is ironic that one of the orginal arguements was I to share technology with a high volume product, but that was also true of  the Alpha/NT concept.    ------------------------------  % Date: Mon, 12 Sep 2005 16:18:12 -0400 ' From: Dave Froble <davef@tsoft-inc.com> . Subject: Re: OT: Sun's quarterly announcements0 Message-ID: <11ibob6g1590f2e@corp.supernews.com>   Staying off topic:   Alan Greig wrote:   J > All they have actually launched today were the entry models up to 4-way K > SMP (2 * 2 core)in a 1U rack format with 16-way promised as coming soon.    G I'm not familiar with any windows product except single socket, single   core.  So the question.   C Will windows take advantage of (use) the multiple cores on a chip?  F Talking about running in 32 bit mode.  Specifically, will/can windows F use all the cores in a system with one or more sockets, using Opteron  multi-core chips?    --  4 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: Mon, 12 Sep 2005 21:31:44 GMT ( From: Alan Greig <greigaln@netscape.net>. Subject: Re: OT: Sun's quarterly announcements< Message-ID: <4tmVe.24088$k22.9489@fe2.news.blueyonder.co.uk>   Dave Froble wrote:   > E > Will windows take advantage of (use) the multiple cores on a chip?  H > Talking about running in 32 bit mode.  Specifically, will/can windows H > use all the cores in a system with one or more sockets, using Opteron  > multi-core chips?   E Windows XP Professional will enable and use up to 2-way SMP. Windows  B Server 2003 will go all the way up to 64-way SMP with "Datacenter I Edition". "Standard Edition" supports up to 4 way and "Enterprise" up to  8 8-way.  SMP is supported in both 32 bit and 64 bit mode.  F So the answer is yes. But Windows gets more expensive on these boxes. C Oracle (for example) running on these SMP Windows boxes can create  F multiple threads to make use of the processors just like it can under F Unix/VMS. People often use these boxes as "terminal servers" in which I Windows becomes a big multi-user system with only the desktops displayed  = locally on often low-end PCs (or even via X-windows to a VMS  E workstation!). Yes, you really can log hundreds of desktops into the   bigger systems.   D Windows is pretty much binary compatible across the current product I range so all these variants are more to do with marketing than technical   issues.  --  
 Alan Greig   ------------------------------  # Date: Mon, 12 Sep 2005 22:23:36 GMT ( From: Alan Greig <greigaln@netscape.net>. Subject: Re: OT: Sun's quarterly announcements: Message-ID: <IdnVe.1748$Kk3.303@fe1.news.blueyonder.co.uk>   > G > Windows XP Professional will enable and use up to 2-way SMP. Windows  D > Server 2003 will go all the way up to 64-way SMP with "Datacenter K > Edition". "Standard Edition" supports up to 4 way and "Enterprise" up to  : > 8-way.  SMP is supported in both 32 bit and 64 bit mode.  H Btw, yes a dual-core Opteron (or Intel chip for that matter) is seen by G Windows/Solaris/Linux as a 2-way SMP system (and so on up) as I forgot   to make that clear.    --  
 Alan Greig   ------------------------------  # Date: Mon, 12 Sep 2005 23:20:07 GMT ( From: Alan Greig <greigaln@netscape.net>. Subject: Re: OT: Sun's quarterly announcements= Message-ID: <H2oVe.54493$2n6.26239@fe3.news.blueyonder.co.uk>    Tom Linden wrote:   M > While this may be true, it is ironic that one of the orginal arguements was K > to share technology with a high volume product, but that was also true of  > the Alpha/NT concept.   G Talking of Alpha, Sun had Dirk Meyer on stage who's bio at AMD reminds  I us that: "Meyer came to AMD from Digital Equipment Corporation, where he  G worked for nearly a decade and was co-architect of the Alpha 21064 and   21264 microprocessors.  J Meyer’s microprocessor industry experience includes tenures at not only H AMD and Digital but also Intel Corporation. Over the years, he has been G involved in the design of x86, Alpha™, VAX, and embedded processors."    Oh for the days of DEC.  --  
 Alan Greig   ------------------------------  % Date: Tue, 13 Sep 2005 01:00:42 -0400 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>. Subject: Re: OT: Sun's quarterly announcements- Message-ID: <43265CE6.104F0A28@vaxination.ca>   ( Just read an article about this on CNET.  B What struck me isn't the old news that Sun is releasing 8086 based9 servers. What struck me is that they are called "Galaxy".   A My guess is that HP won't even notice Sun's infringement on a VMS  related trademark.    E This would be a perfect opportunity for HP to make noise in the media D about protecting a VMS (now HP) trademark and using this to tell theH world that HP own VMS and is fighting to get VMS to grow. Forcing Sun toH rename a server line because of VMS would be a great step forward for HP< to show its remaining VMS customers that HP cares about VMS.  G Then again, with only 175 million in sales and still dwindling, perhaps ( VMS truly isn't important to HP anymore.   ------------------------------  # Date: Tue, 13 Sep 2005 05:05:35 GMT   From: CJT <abujlehc@prodigy.net>. Subject: Re: OT: Sun's quarterly announcements* Message-ID: <43265E20.7070402@prodigy.net>   JF Mezei wrote:   * > Just read an article about this on CNET. > D > What struck me isn't the old news that Sun is releasing 8086 based; > servers. What struck me is that they are called "Galaxy".  > C > My guess is that HP won't even notice Sun's infringement on a VMS  > related trademark. >  > G > This would be a perfect opportunity for HP to make noise in the media F > about protecting a VMS (now HP) trademark and using this to tell theJ > world that HP own VMS and is fighting to get VMS to grow. Forcing Sun toJ > rename a server line because of VMS would be a great step forward for HP> > to show its remaining VMS customers that HP cares about VMS. > I > Then again, with only 175 million in sales and still dwindling, perhaps * > VMS truly isn't important to HP anymore.  G Is there any likelihood of confusion?  Isn't it clear they're different ) when one is hardware and one is software?    --  D The e-mail address in our reply-to line is reversed in an attempt toC minimize spam.  Our true address is of the form che...@prodigy.net.    ------------------------------  % Date: Mon, 12 Sep 2005 20:02:08 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>) Subject: Re: Personal Thoughts on Sept 11 + Message-ID: <43262510.282E4301@comcast.net>    bob@instantwhip.com wrote: > + > personal thoughts - God will take care of G > the situation ... all the killers are in hell right now right burning 4 > their buns off and crying for a drink of water ...  B You've never known the excruciating agony of true burns, have you?  G If we ever meet in person, ask me how I got the scars on the under-side  of my right arm.  - Thirst was the furthest thought from my mind.   H > professional thoughts ... have businesses really learned anything fromB > this and got on vms, or have they failed to grasp the concept of > disaster tolerance?   B I doubt their minds can grasp anything other than a computer mouse' and/or a beer any more their hands can.    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/    Coming soon:& Unofficial OpenVMS Marketing Home Page   ------------------------------  % Date: Mon, 12 Sep 2005 15:08:04 -0400 * From: "Dennis Couch" <dencouch@us.ibm.com>2 Subject: Re: Postings  (was Re: HP Forum location)) Message-ID: <4325d011_2@news3.prserv.net>   L Just out of curiousity: my ISP is Verizon as well, but I really haven't doneJ anything with their news server from home other than set up the connectionA and make sure it works.  What, in your opinion, is wrong with it?   5 "Bill Gunshannon" <bill@cs.uofs.edu> wrote in message % news:3oitfiF5tustU1@individual.net... 0 In article <00A499D1.64CB5FBA.13@tachysoft.com>,  $ Here's a plug for news.individual.de  J I've been using them since before it went commercial and been very pleasedI and the charge they instituted when it went commercial isn't really worth K considering.  Really good SPAM filtering, great feeds and fast propogation.   J My ISP is Verizon.  I looked at their news server once and it made me even% more pleased with news.individual.de.    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |> Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------   Date: 13 Sep 2005 00:19:34 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)2 Subject: Re: Postings  (was Re: HP Forum location)+ Message-ID: <3omk8mF6mgdhU1@individual.net>   ) In article <4325d011_2@news3.prserv.net>, - 	"Dennis Couch" <dencouch@us.ibm.com> writes: N > Just out of curiousity: my ISP is Verizon as well, but I really haven't doneL > anything with their news server from home other than set up the connectionC > and make sure it works.  What, in your opinion, is wrong with it?   A Probably the most noticable thing was enough SPAM to make the few $ groups I read pretty  much unusable.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  # Date: Tue, 13 Sep 2005 00:56:23 GMT   From: John Santos <john@egh.com>2 Subject: Re: Postings  (was Re: HP Forum location)+ Message-ID: <XspVe.10261$vQ3.4382@trnddc08>    Bill Gunshannon wrote:+ > In article <4325d011_2@news3.prserv.net>, / > 	"Dennis Couch" <dencouch@us.ibm.com> writes:  > N >>Just out of curiousity: my ISP is Verizon as well, but I really haven't doneL >>anything with their news server from home other than set up the connectionC >>and make sure it works.  What, in your opinion, is wrong with it?  >  > C > Probably the most noticable thing was enough SPAM to make the few & > groups I read pretty  much unusable. >  > bill >   F I am reading comp.os.vms on Verizon right now, and don't see any spam.  < Maybe a handful/week on all the newsgroups I read regularly.  C Are you talking about the horrible DIVX storm on the VMSNET groups?  That has been over for *years*.   B If you have Verizon, I would use it rather than pay for some other< news service, unless there was some very specific issue they wouldn't or couldn't deal with.   A Retention is pretty good, about a month for most text groups I've @ seen, and performance seems reasonable on 1.5MB DSL, usually, at+ least for text.  Don't know about binaries.   B They're not perfect, there do seem to be sporadic hiccups, or theyB go out to lunch for an hour or two once or twice a month, but I've? seen *MUCH* worse.  Also, once in a while they seem to renumber C everything (or maybe the article numbering gets out of sync between B their servers), which is a real pain.  But most of the time I find them better than adequate.   --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Mon, 12 Sep 2005 18:34:16 GMT * From: "FredK" <fred.nospam@nospam.dec.com>* Subject: Re: Sun's quarterly announcements4 Message-ID: <ISjVe.12440$AZ2.10216@news.cpqcorp.net>  5 "Alan Greig" <greigaln@netscape.net> wrote in message 5 news:kWhVe.23802$k22.699@fe2.news.blueyonder.co.uk...  > I > Just watched the live webcast of Sun's Q3 seminar. It's Opteron all the " > way as far as Sun are concerned. > I > One interesting point for debate: Sun described HP-UX during the Q&A as F > "effectively end-of-lifed" due entirely to the Itanium situation. AsF > that becomes clearer to customers (they say) Sun hopes to grab HP-UX@ > customers who will prefer Solaris to Windows or Linux from HP.   What do you expect them to say?   =     "Gee.  We continue to lose money and see revenue declines @     since the 2000 dot-bomb.  Our bread & butter chip, the SPARC<     continues to underperform while being underpriced by ourD     rivals.  Solaris continues to go the way of the Dodo bird as ourC     customers bail out to Linux.  We are so deperate, we have ended >     our long running MS bashing, and have jumped on Opteron asE     a desperate last chance at something to differentiate ourselves."   E Frankly, the bigger customers I talk to are not looking at Sun - it's < bake offs between IBM and HP.  Of course, IBM can't run VMS.   ------------------------------  # Date: Mon, 12 Sep 2005 18:27:35 GMT ( From: Alan Greig <greigaln@netscape.net>* Subject: Re: Sun's quarterly announcements= Message-ID: <rMjVe.54413$2n6.26881@fe3.news.blueyonder.co.uk>    FredK wrote:   >  > ! > What do you expect them to say?  > ? >     "Gee.  We continue to lose money and see revenue declines B >     since the 2000 dot-bomb.  Our bread & butter chip, the SPARC> >     continues to underperform while being underpriced by ourF >     rivals.  Solaris continues to go the way of the Dodo bird as ourE >     customers bail out to Linux.  We are so deperate, we have ended @ >     our long running MS bashing, and have jumped on Opteron asG >     a desperate last chance at something to differentiate ourselves."   H The market seems to like today's announcements. Sun up 5% on the day so  far, HP unchanged.   --  
 Alan Greig   ------------------------------  % Date: Mon, 12 Sep 2005 14:33:14 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> * Subject: Re: Sun's quarterly announcements, Message-ID: <4325C9E5.9A0F664D@teksavvy.com>   FredK wrote:? >     "Gee.  We continue to lose money and see revenue declines B >     since the 2000 dot-bomb.  Our bread & butter chip, the SPARC> >     continues to underperform while being underpriced by ourF >     rivals.  Solaris continues to go the way of the Dodo bird as ourE >     customers bail out to Linux.  We are so deperate, we have ended @ >     our long running MS bashing, and have jumped on Opteron asG >     a desperate last chance at something to differentiate ourselves."       ) The Sun situation can also be spun into :   H "We are adapting to changing marketplace to respond to our ever changingG customer needs. HP on the other hand refuses to admit reality and keeps E on insisting its IA64 thing will eventually be industry standard when C all the signs, even from HP and Intel are that the 8086 will remain  industry standard."    ------------------------------   End of INFO-VAX 2005.511 ************************