1 INFO-VAX	Fri, 28 Apr 2006	Volume 2006 : Issue 234       Contents:8 Re: DCL versus Unix CLIs, was: Re: File output like Unix8 Re: DCL versus Unix CLIs, was: Re: File output like Unix8 Re: DCL versus Unix CLIs, was: Re: File output like Unix Re: decimal point in OpenVMS Re: decimal point in OpenVMS Re: decimal point in OpenVMS Re: decnet vs decnet over IP% Re: Exclude a disk from MSCP serving? % Re: Exclude a disk from MSCP serving? E Re: Heads UP BRUDEN Announces the OpenVMS Bootcamp Uptime Scholarship E Re: Heads UP BRUDEN Announces the OpenVMS Bootcamp Uptime Scholarship E Re: Heads UP BRUDEN Announces the OpenVMS Bootcamp Uptime Scholarship  OT: FAA goes Linux) OT: Intels quickens cadence for new 8086s - Re: OT: Intels quickens cadence for new 8086s  Re: OT: Sparc not dead yet RE: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet RE: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet# REI and stacked PSL with TP/T bits.   Semi-OT: Changes coming at Intel$ Re: Semi-OT: Changes coming at Intel$ Re: Semi-OT: Changes coming at Intel Re: Virtual I/O Cache  Re: Virtual I/O Cache  Re: Virtual I/O Cache   F ----------------------------------------------------------------------  % Date: Thu, 27 Apr 2006 16:55:33 -0400 ' From: Dave Froble <davef@tsoft-inc.com> A Subject: Re: DCL versus Unix CLIs, was: Re: File output like Unix / Message-ID: <8smdnd5WQ-WVsszZRVn-pA@libcom.com>    Simon Clubley wrote:  L > I guess I was just been too subtle. I wasn't referring to invisible files,N > but DCL's default processing. If you omit a filename from a target filespec,6 > then the filename is taken from the source filespec. > L > So unless it has changed in recent versions, the following is what happens- > when you try to rename simon.test to .test:  >  > $ create simon.test      >  Exit  > $ rename/log simon.test .test K > %RENAME-I-RENAMED, {deleted}SIMON.TEST;1 renamed to {deleted}SIMON.TEST;1  > , > You have to use tricks to rename the file.  E What you say is true.  Statistics are also true, but can easily lie,  ! based upon how they're presented.   E So you present this as something not easily done in DCL.  I'll agree  I with you, but I could get there if I needed to.  What I'll state though,  G is that the default DCL behavior is exactly what I'd expect, and want,  	 it to do.   E I have no use for filespecs without the filename part.  The converse  E would be more acceptable, though I prefer both.  I wouldn't want the   Unix behavior.  D Now tell me all the common things you do with filespecs without the  filename part?  H Taking a behavior that by default works in a manner most useful to most B users, then stating that it's deficient because the default isn't I something that in most cases is harmful, isn't a good argument, at least   with me.  H So in Unix, if I don't specify the filename part of the filespec, and I D have multiple files with the same extension, then I can easily lose F files.  I'm assuming that the renamed file, or the one currently with E that name, will end up deleted since Unix doesn't have versions.  At  : best the operation would fail.  What's so good about that?   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Thu, 27 Apr 2006 20:22:57 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>A Subject: Re: DCL versus Unix CLIs, was: Re: File output like Unix 6 Message-ID: <44516E71.DE3430C9@NeOaSrPtAhMlNiOnWk.net>   Simon Clubley wrote: > l > In article <1146094463.265362.201570@i40g2000cwc.googlegroups.com>, "AEF" <spamsink2001@yahoo.com> writes: > >  > > Simon Clubley wrote: > >>, > >> Two examples of more powerful commands:J > >>      grep (the Unix version of search) can do full regular expression > >>      pattern matching.  > > C > > Can it do something like $ SEARCH FILE.TYP WORD1,WORD2,... with E > > /MATCH=(one of OR, NOR, AND, NAND, ...) Maybe it can ... I'm just ( > > asking but I think the answer is no. > >  > L > Yes, that is a nice feature of search. You can achieve most (maybe all) ofJ > that with grep by feeding the output of one grep into another. (grep hasJ > the ability to output just a list of filenames that did, or didn't match > a search string,  1 Take a look at "SEARCH filespec/WINDOW=0 string".   > > and the /match=or ability is built in as part of the regular > expression functionality). >  > >>O > >> Things that I dislike about DCL (these relate to 7.3-1 and prior versions, 0 > >> I haven't upgraded to a later version yet): > >>= > >>      You can't edit commands across linewrap boundaries. 5 > >>      Has this been fixed in later VMS versions ?  > > . > > Isn't this more about the terminal driver? > >  > K > Probably, but it's unbelievable that DCL _still_ cannot do this. Even the $ > Windows command shell can do this.   It's beyond DCL's control.  H Remember: in VMSland, wheels are not commonly re-invented, except by theA under-informed. So, input routines will tend to employ the common D services available rather than try to support special features on an individual basis.    > > F > > Here's one for you: Ever try writing a SET DEFAULT program in Unix > > shell script?  > >  > L > Interestingly, I don't use SET DEFAULT/cd utilities on either VMS or Unix.  F I have one in DCL that I use to allow for both VMS and UN*X/DOS syntax> so some of my vendors can feel a little more at home (very fewF VMS-competent people around these day, y'know ;-) and so I can do "SET DEF [-]" as simply "CD ..".   K > When working in multiple directories, I tend on both VMS and Unix to have K > multiple DCL/bash windows open, with the current directory in each window  > set to a different directory.  > K > Also, it's a lot easier to change directories when you can just press Tab  > to complete a directory name.   F I've never seen a use for that which couldn't be better served another way.   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------  # Date: Fri, 28 Apr 2006 02:29:35 GMT 9 From: Bob Harris <nospam.News.Bob@remove.Smith-Harris.us> A Subject: Re: DCL versus Unix CLIs, was: Re: File output like Unix D Message-ID: <nospam.News.Bob-2D59F0.22293527042006@news.verizon.net>  / In article <8smdnd5WQ-WVsszZRVn-pA@libcom.com>, )  Dave Froble <davef@tsoft-inc.com> wrote:    > Simon Clubley wrote: > N > > I guess I was just been too subtle. I wasn't referring to invisible files,P > > but DCL's default processing. If you omit a filename from a target filespec,8 > > then the filename is taken from the source filespec. > > N > > So unless it has changed in recent versions, the following is what happens/ > > when you try to rename simon.test to .test:  > >  > > $ create simon.test     
 > >  Exit ! > > $ rename/log simon.test .test M > > %RENAME-I-RENAMED, {deleted}SIMON.TEST;1 renamed to {deleted}SIMON.TEST;1  > > . > > You have to use tricks to rename the file. > G > What you say is true.  Statistics are also true, but can easily lie,  # > based upon how they're presented.  > G > So you present this as something not easily done in DCL.  I'll agree  K > with you, but I could get there if I needed to.  What I'll state though,  I > is that the default DCL behavior is exactly what I'd expect, and want,   > it to do.  > G > I have no use for filespecs without the filename part.  The converse  G > would be more acceptable, though I prefer both.  I wouldn't want the   > Unix behavior. > F > Now tell me all the common things you do with filespecs without the  > filename part? > J > Taking a behavior that by default works in a manner most useful to most D > users, then stating that it's deficient because the default isn't K > something that in most cases is harmful, isn't a good argument, at least  
 > with me. > J > So in Unix, if I don't specify the filename part of the filespec, and I F > have multiple files with the same extension, then I can easily lose H > files.  I'm assuming that the renamed file, or the one currently with G > that name, will end up deleted since Unix doesn't have versions.  At  < > best the operation would fail.  What's so good about that?  : Firstly, on *NIX it is _NOT_ ".extension".  It is ".name".  C Technically the characters following a name are only considered an  A extension if some application decides it wants to treat it as an  < extension (the C compiler for example).  But if the program A processing the file doesn't care, then *NIX doesn't care.  Never   did.  B The earliest convention for .named files was for personalization, > preferences, config type files.  The LOGIN.COM equivalent for B example would be .profile for the bourne shell (.login and .cshrc > for the C-Shell; and a bunch of different names for different > shells).  Other applications and utilities may also allow for B customizations such as your editor might have a .exrc, or .emacs, B or .vimrc file.  The debuger might have a .gdbinit file.  A spell 9 checking utility might keep your personal word list in a   .ispell_english file.   ? Another use for .named files is as temporary files, such as an  B editor intermediate work file, often useful for recovering from a A crash, and useful as a flag in case 2 users (or you from another  & window) attempt to edit the same file.  @ The directory listing utility (ls) maintained the convention of C not displaying any file name that started with a period, unless -a  C was included.  And shell wildcard expansion ignore files beginning  @ with a period unless you explicitly specify a leading period in  the wildcard expression.  > This has the effect of hiding .named files, unless explicitly 
 asked for.  @ Now there are other utilities that do not exclude .named files, 2 such as backup utilities, the find command, etc...  C It is in the configuration file arena that most *NIX users working  > on OpenVMS find the need/desire to have .named files, as they ? often times find favorite commands and utilities from the *NIX  ? world which have been ported to OpenVMS and these commands and  ' utilities look for .named config files.   .                                     Bob Harris;                                     And I'm not a trolling! >                                     12 Years OpenVMS includingC                                     PATHWORKS for OpenVMS developer ;                                     14 years *NIX including <                                     Tru64 UNIX developer and>                                     the first version of those>                                     radar weather maps you see:                                     on the Weather Channel@                                     And my favorite color is ...B                                     oops! too much information :-)   ------------------------------    Date: 27 Apr 2006 11:23:44 -0700( From: "pbritto" <britto.paulo@gmail.com>% Subject: Re: decimal point in OpenVMS C Message-ID: <1146162224.837869.295210@y43g2000cwc.googlegroups.com>   B We work with a supervisory system called VXL, it's a client-serverG system, a server communicates with a equipament which retrieves process A values from the industrial plant. The servers values are depicted D properly but some clients values are like they were divided by 10. IF know this problem is far beyond the scope of group, but since you saidA my suspicions are not right because this is likely not an OpenVMS 5 problem profile I will try to dig out somewhere else.   F  If a brain storm pops up with something from you, please let me know.   Thanks ,   Paulo    ------------------------------  % Date: Thu, 27 Apr 2006 13:19:44 -0700 # From: "Tom Linden" <tom@kednos.com> % Subject: Re: decimal point in OpenVMS ) Message-ID: <op.s8on26vjzgicya@hyrrokkin>   K On Thu, 27 Apr 2006 11:23:44 -0700, pbritto <britto.paulo@gmail.com> wrote:   D > We work with a supervisory system called VXL, it's a client-serverI > system, a server communicates with a equipament which retrieves process C > values from the industrial plant. The servers values are depicted F > properly but some clients values are like they were divided by 10. IH > know this problem is far beyond the scope of group, but since you saidC > my suspicions are not right because this is likely not an OpenVMS 7 > problem profile I will try to dig out somewhere else.  > H >  If a brain storm pops up with something from you, please let me know. > 
 > Thanks , >  > Paulo  > J Are these integers, floating point, scaled fixed decimal?  If you expect   helpJ you need to state your problem with more precsison.  What is the client,   how does it retrieve the values?    ------------------------------  % Date: Thu, 27 Apr 2006 17:07:33 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> % Subject: Re: decimal point in OpenVMS , Message-ID: <44513289.E2CE8BAF@teksavvy.com>   pbritto wrote:E > So I am suspicious that a problem that is occouring is a problem of E > decimal points. Like Regional Settings in Windows, how can I change C > between commas and point to indicates decimal part of a number in 
 > OpenVMS?  A I am not sure that Motif has support for this. And if it did, few M applications would actually make use of this setting and just assume decimal.    ------------------------------  # Date: Thu, 27 Apr 2006 22:24:48 GMT A From: "Colin Butcher" <colin_DOT.butcher_AT@xdelta_DOT.co_DOT.uk> % Subject: Re: decnet vs decnet over IP = Message-ID: <Qwb4g.60655$wl.10460@text.news.blueyonder.co.uk>   J In my opinion DECnet does a better job in the LAN, especially Phase V whenJ you have multiple physically separate LAN paths and you get load balancingE and automatic path failover for the price of an end system (end node) E licence. If the 'corpirate network policy' is to have IP only routing L between LANs or VLANs then DECnet over IP will let you use end to end DECnetJ APIs. Downside of DECnet over IP is that you're entirely reliant on the IPF infrastructure for routing, path availability, latency, bandwidth etc.I Upside is that it does work and you can continue to use end to end DECnet K (including proxy accounts) without needing to change very much. Proxies and . name resolution tend to cause most of the fun.  6 You might find this useful for some of the background:8 http://h71000.www7.hp.com/openvms/journal/v5/decnet.pdf.   --     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: Thu, 27 Apr 2006 20:57:25 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply). Subject: Re: Exclude a disk from MSCP serving?$ Message-ID: <e2rb7l$cch$1@online.de>  H In article <000301c66922$9551d310$994614ac@domina.fom>, "Rudolf Wingert" <win@fom.fgan.de> writes:    > Hello, >  > Robert Deininger wrotes: >  > >>> J > The satellite will need a local DOSD (Dump Off System Disk), at least inG > the first implementation.  And most folks will want a local page/swap G > disk.  Here "local" means not MSCP-served.  SAN-based disks are fine.  > <<<  > H > In case of this I have the question, is it possible to exclude disk(s)J > from MSCP serving? AFAIK you can only enable/disable MSCP for all disks!  E I think "not MSCP-served" here means that the node in question has a  G direct connection to the disk, not that it is not MSCP-served to other   nodes.   ------------------------------  + Date: Fri, 28 Apr 2006 02:32:20 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) . Subject: Re: Exclude a disk from MSCP serving?( Message-ID: <e2rurk$5kv$1@pcls4.std.com>  H In article <000301c66922$9551d310$994614ac@domina.fom>, "Rudolf Wingert" ><win@fom.fgan.de> writes:    H > In case of this I have the question, is it possible to exclude disk(s)J > from MSCP serving? AFAIK you can only enable/disable MSCP for all disks!  G There is no way to "un serve" an already served disk.  The way to never D serve a drive is to set MSCP_SERVE_ALL to 0 and have a com file do a> $ SET DEVICE/SERVED command for each drive you do want served.   ------------------------------  % Date: Thu, 27 Apr 2006 16:59:01 -0400 ' From: Dave Froble <davef@tsoft-inc.com> N Subject: Re: Heads UP BRUDEN Announces the OpenVMS Bootcamp Uptime Scholarship/ Message-ID: <8smdndlWQ-VKsszZRVn-pA@libcom.com>    norm.raphael@metso.com wrote:  > ; > VAXman-@SendSpamHere.ORG wrote on 04/27/2006 06:06:35 AM:  > F >> In article <1146086661.057256.157610@t31g2000cwb.googlegroups.com>,. >> "Sue" <susan_skonetski@hotmail.com> writes: >>> J >>> In speaking with Bruce via email today he has had over 70 people apply, >>> for this scholarship which is wonderful. >>> K >>> In case you are wondering last year at this time (4 weeks away from the ? >>> boot camp) we were 50% full we are currently over 85% full. I >> Wow... lots of geezers!  This is one instance where age discrimination  >> is a good thing... I think. > 1 > Just how true is the legend of the VMS geezers? E > We should have a barchart posted by age/number of geezers after the  > deadline.  >  >> -- 3 >> VAXman- A Bored Certified VMS Kernel Mode Hacker  > VAXman(at)TMESIS(dot)COM7 >>   "Well my son, life is like a beanstalk, isn't it?"  >   H First define 'geezers'.  When I'm 110, then maybe you can call me such.    Maybe.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Thu, 27 Apr 2006 17:00:52 -0400 ' From: Dave Froble <davef@tsoft-inc.com> N Subject: Re: Heads UP BRUDEN Announces the OpenVMS Bootcamp Uptime Scholarship/ Message-ID: <8smdndhWQ-XYrczZRVn-pA@libcom.com>    Bill Gunshannon wrote:S > In article <OF8A343049.4427005D-ON8525715D.0047CAF0-8525715D.0047FA09@metso.com>, ! > 	norm.raphael@metso.com writes:  >>< >> VAXman-@SendSpamHere.ORG wrote on 04/27/2006 06:06:35 AM: >>G >>> In article <1146086661.057256.157610@t31g2000cwb.googlegroups.com>, / >>> "Sue" <susan_skonetski@hotmail.com> writes:  >>>>K >>>> In speaking with Bruce via email today he has had over 70 people apply - >>>> for this scholarship which is wonderful.  >>>>L >>>> In case you are wondering last year at this time (4 weeks away from the@ >>>> boot camp) we were 50% full we are currently over 85% full.J >>> Wow... lots of geezers!  This is one instance where age discrimination >>> is a good thing... I think. 2 >> Just how true is the legend of the VMS geezers?F >> We should have a barchart posted by age/number of geezers after the >> deadline. > I > I would be interested in knowing who wins and what their birthdate was. F > Of course, I will be pretty dis-appointed if I then see I would have" > won as I would have loved to go. >  > bill >   E Forget it.  I'll be 60 in July, and I know I wouldn't even be in the   running.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Thu, 27 Apr 2006 17:41:10 -0400  From: norm.raphael@metso.comN Subject: Re: Heads UP BRUDEN Announces the OpenVMS Bootcamp Uptime ScholarshipQ Message-ID: <OFA0230DD6.A3B4CEE7-ON8525715D.007690A2-8525715D.0077201E@metso.com>   B Dave Froble <davef@tsoft-inc.com> wrote on 04/27/2006 04:59:01 PM:   > norm.raphael@metso.com wrote:  > > = > > VAXman-@SendSpamHere.ORG wrote on 04/27/2006 06:06:35 AM:  > > H > >> In article <1146086661.057256.157610@t31g2000cwb.googlegroups.com>,0 > >> "Sue" <susan_skonetski@hotmail.com> writes: > >>> F > >>> In speaking with Bruce via email today he has had over 70 people apply . > >>> for this scholarship which is wonderful. > >>> I > >>> In case you are wondering last year at this time (4 weeks away from  the A > >>> boot camp) we were 50% full we are currently over 85% full. K > >> Wow... lots of geezers!  This is one instance where age discrimination   > >> is a good thing... I think. > > 3 > > Just how true is the legend of the VMS geezers? G > > We should have a barchart posted by age/number of geezers after the 
 > > deadline. 
 > > <snip> > I > First define 'geezers'.  When I'm 110, then maybe you can call me such. 
 >   Maybe. >   H Well, Jeez, Dave, it's a term of affection, don't-ya-know.  Like calling a 300-pound guy "Tiny."  ;)  and alsoB Dave Froble <davef@tsoft-inc.com> wrote on 04/27/2006 05:00:52 PM:   > <snip> > F > Forget it.  I'll be 60 in July, and I know I wouldn't even be in the
 > running.  E Well, you're younger than I am, but I'll not call you "Sonny."  ;) ;)   C Maybe the really old VMS geezers are too infirm to make the journey D or are already registered, having made there fortunes when DEC stock% was up around $190US/share.  ;) ;) ;)      > --6 > David Froble                       Tel: 724-529-0450@ > Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com > DFE Ultralights, Inc.  > 170 Grimplin Road  > Vanderbilt, PA  15486    ------------------------------  % Date: Fri, 28 Apr 2006 00:06:54 -0400 . From: JF Mezei <jfmezei.spamnot@vaxination.ca> Subject: OT: FAA goes Linux - Message-ID: <445194B4.9A476298@vaxination.ca>   Q > http://www.redhat.com/rhel/informationcenter/successstories/government/faa.html   B I think this is worthy of mention because it truly pits Linux as aJ serious competitor to VMS for truly serious mission critical applications.  H Basically, FAA is replacing older systems with a 1000 Linux workstationsF and very large farm of servers at great cost savings compared to other offerings.     ##? In fact, by choosing industry standard hardware and open source  software, the cost of 8 replacing each computer dropped from $25,000 to $3,000.   H Cost savings were significant, but not at the sacrifice of reliability.  ##  H This is a big win for Linux/RedHat as they will be able to point to suchB a high profile application as proof that Linux can run some really serious stuff.   ------------------------------  % Date: Thu, 27 Apr 2006 20:45:43 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: OT: Intels quickens cadence for new 8086s, Message-ID: <4451659E.2B5471AD@teksavvy.com>  X > http://news.com.com/Intel+steps+up+chip+cadence/2100-1006_3-6065925.html?tag=nefd.lede  < Interesting article about Intel now expecting to produce new> microacrhitectures for the 8086 every 2 years in order to stay1 competitive. The last big change was 5 years ago.   H Its attempt for dual core Xeon was dismal failure, producing 165watts ofA heat while the equivalent Opteron produced only 95 watts of heat.   H With the upcoming cores this year, Intel expects to be back in the game.F It also admitted that in order to get to the 2 year release frequency,* it has multiple teams working in parralel.  G The mention of bad financials at Intel has been made very frequently in C the press, with lots of pressure to focus on profitable lines. This A articles makes no mention on increased cadence for IA64 releases.   A So, if the 8086's release frequency is increased, and IA64 delays : continue, it won't be long before IA64 becomes irrelevant.   ------------------------------  % Date: Thu, 27 Apr 2006 20:35:41 -0600 " From: GreyCloud <mist@cumulus.com>6 Subject: Re: OT: Intels quickens cadence for new 8086s0 Message-ID: <PpCdnUZ3Zf3i4szZ4p2dnA@bresnan.com>   JF Mezei wrote:   X >>http://news.com.com/Intel+steps+up+chip+cadence/2100-1006_3-6065925.html?tag=nefd.lede >  > > > Interesting article about Intel now expecting to produce new@ > microacrhitectures for the 8086 every 2 years in order to stay3 > competitive. The last big change was 5 years ago.  > J > Its attempt for dual core Xeon was dismal failure, producing 165watts ofC > heat while the equivalent Opteron produced only 95 watts of heat.  >   H I took one back that had a dual core.  The heat sink was made of copper  and big as a brick.   J > With the upcoming cores this year, Intel expects to be back in the game.H > It also admitted that in order to get to the 2 year release frequency,, > it has multiple teams working in parralel. > I > The mention of bad financials at Intel has been made very frequently in E > the press, with lots of pressure to focus on profitable lines. This C > articles makes no mention on increased cadence for IA64 releases.  > C > So, if the 8086's release frequency is increased, and IA64 delays < > continue, it won't be long before IA64 becomes irrelevant.     --   Where are we going?   And why am I in this handbasket?   ------------------------------  % Date: Thu, 27 Apr 2006 13:15:58 -0700 # From: "Tom Linden" <tom@kednos.com> # Subject: Re: OT: Sparc not dead yet ) Message-ID: <op.s8onwwr2zgicya@hyrrokkin>   K On Thu, 27 Apr 2006 09:11:45 -0700, Doug Phillips <dphill46@netscape.net>    wrote:  F > AMD is helping push the x86 evolution forward. That's what I've saidF > over and over again in this thread. Some here seem to want to ignore1 > that and apparently others don't understand it.    I think Intel is listening  % Intel CEO plans to 'overhaul' company    	  Mark LaPedus	 	  EE Times (04/27/2006 12:24 PM EDT) 	    	 I SAN JOSE, Calif. — Hit hard by the PC slowdown and stiff competition,   J Intel Corp. on Thursday (April 27) said that it plans to restructure the   company.  E Paul Otellini, chief executive of Intel (Santa Clara, Calif.), told   K analysts he plans an overhaul that will impact "every part" of the company.   K “In terms of non-performing businesses, anything with a bracket will be   F looked at,” he said, referring to the company’s loss-ridden units.  I Intel's core processor business is making money, but its NOR flash unit   L could be in big trouble. For several quarters, Intel has been losing money  D in its NOR flash unit. In Q1, the company lost $108 million in the  1 segment; it is investing more in the NAND sector.   K Intel is making a “detailed review” of its business units, added Andy   F Bryant, executive vice president and chief financial officer for the  $ company, during the conference call.  L “We will still invest in technology,” Bryant said. “We will make the   company more efficient.”  L The company provided no details of the restructuring plans, but it expects  # swift actions by the third quarter.   J The move follows ongoing problems at the microprocessor giant. Recently,  G for example, Intel posted first-quarter net income of $1.3 billion on   F revenue of $8.9 billion, down significantly on both a sequential and  E year-to-year basis, with the troubled semiconductor supplier citing   5 slumping PC sales and inventory woes as the culprits.   L One of the problems is in the server space, where Intel is losing share to  B Advanced Micro Devices Inc. (AMD). In the conference call, Intel  + reiterated its roadmap in the server space.   L And this week, it moved to boost desktop sales and improve client security  L and management, announcing a plan called vPro. Upgrading desktop platforms  E involves promoting dual-core microprocessor architectures on client   E platforms and offering a dedicated coprocessing chip set with a new   ? generation of Active Management Technology and hardware-based    virtualization.   Q “I think we’ll get the share back,” said Anand Chandrasekher, senior vice   K president and general manager of the sales and marketing group for Intel,    during the call.  L Still to be seen, however, is if Intel can regain momentum in the consumer  H space. Intel will shortly ship its next-generation, micro-architecture   chip products.  N Built around a 65-nm process technology, Intel’s new products based on the  K Core microarchitecture is expected to show up in the third quarter in the   G Woodcrest platform for servers, Conroe for desktop PCs, and Merom for   2 mobile PCs, according to the company’s road map.  H Another problem for Intel is NOR flash, where Intel is losing a ton of  L money. Intel appears to be putting more resources on NAND. The company has  C a joint NAND venture with Micron Technology Inc., dubbed IM Flash    Technologies LLC.    ------------------------------  % Date: Thu, 27 Apr 2006 16:46:35 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> # Subject: RE: OT: Sparc not dead yet T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401301864@tayexc19.americas.cpqcorp.net>   > -----Original Message-----7 > From: Doug Phillips [mailto:dphill46@netscape.net]=20  > Sent: April 27, 2006 11:41 AM  > To: Info-VAX@Mvb.Saic.Com % > Subject: Re: OT: Sparc not dead yet  >=20 > Main, Kerry wrote: > > > From: Doug Phillips [  > >    [snip..]   > > >  > > ? > > That assumes you are aware of all the known issues. What=20  > happens when7 > > new failures and holes keep coming out every month?  > > = > > For companies that literally have hundreds and in some=20  > cases, thousandsH > > of X86 servers, how do you keep them all in sync and up to date when> > > there are so many new issues being discovered every month? > > > > > Keep in mind that IT shops worth their salt will ensure=20 > that the patches? > > for their main applications (especiually those with Cust=20  > data) are fully ( > > tested before releasing the patches. > >  >=20 >=20C > So, you're saying that any system can *not* be made secure or not 	 > secure.  >=20  G No - just that some platforms have a track record of security holes and H as part of the platform TCO, Cust's need to start looking at how much itB costs to QA/Test their apps every month before they roll out these patches.    	 [snip...]    >=20H > Why does anything have to come after x86? It's an instruction set. AreH > there missing instructions that the world can't live without? Too manyA > instructions to fit on a fast chip? Some unforeseen radical new D > technology that can't be handled by specialized chips? What is theE > technical problem with the x86 instruction set that needs fixing or  > can't be fixed?  >=20  F Reminds me of story in the UK around 1900 whereby there was a movementD or at least a proposal to close the patent department of the govt as? "everything that can be invented has already been invented ..."    :-)   	 [snip...]    >=20G > WordPerfect vs. Word isn't really a good analogy here, but it kind of F > supports what I've been saying: "Follow the Money". Or as a buddy of- > mine puts it: "Money talks and sh*t walks."  >=20  E Point is that a defacto standard grew "old" and was replaced by a new  technology.=20    I expect this trend to continue.  G Perhaps Google or some other player will emerge as the next IT leader??    Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Thu, 27 Apr 2006 17:15:57 -0400 ' From: Dave Froble <davef@tsoft-inc.com> # Subject: Re: OT: Sparc not dead yet 9 Message-ID: <TIydnboW56hNrszZnZ2dnUVZ_vudnZ2d@libcom.com>    Doug Phillips wrote: > Dave Froble wrote: >> Doug Phillips wrote:  >>> Main, Kerry wrote: >>> 	 > [snips] E >>> This is all true, Kerry. But how much money can x86's competition I >>> afford to keep spending to stay ahead? The money being spent on x86's K >>> evolution is huge. Sun is bleeding to death today and SPARC engineering H >>> is a big bleeder. At some point, unless Sun is handed a miracle, theJ >>> SPARC division will probably be sold. Whatever is on the SPARC drawingF >>> board now might or might not ever get to the market. Chips fartherG >>> along in the process probably will, and a return from that "shorter K >>> term" market would be a reason Samsung or whoever might want to buy it. C >>> Anyone willing to do a little homework should come to a similar  >>> conclusion. I >> The problem I see with such reasoning is that it's looking only at one J >> moment in time.  Yes, right now the AMD Opteron is doing well.  Do keepI >> in mind that it's been called by some "little EV7".  But whoever is on H >> top today has no guarantee of staying there.  Need I mention DEC, and >> even Intel? >> > @ > Hmm. I seem to be one of the few people here talking about theD > *future*, so if you mean one moment of time = the future, then ok.  G No, what I'm saying is that x86 is dominant today, but possibly not in   the future.   H >>> The Reliability-Availability-Security bar ("goal") is and always hasK >>> been at 100%. Scalability has a few different meanings depending on the J >>> problem. As you say, IT users (customers) must continually re-evaluateC >>> their IT service delivery. Likewise, IT solution providers must ? >>> continually re-evaluate how to best spend their R&D dollar. J >> Do you really want a world where everyone but one vendor just gives up?I >>   If you believe that you cannot win, and never start a race, then the ; >> opponent wins by default.  Not everybody is a 'quitter'.  >> > H > What quitter? To keep pouring money into a dry well is stubborn beyondG > stupid if there's a clean cool spring running out on the back 40.. (I D > hope that isn't too obscure, but just in case it is, think of "CPU& > instruction sets" instead of water).  I You're assuming I guess that IBM with Power, Sun and Fujitso with Sparc,  D and anyone else not using x86 is a dry well?  If so, then we have a  basic difference of opinion.  M >>>> For many of the these Customers, I would suggest that QA/testing monthly H >>>> security patches (Linux/Windows) with their primary applications isL >>>> rapidly going to become unacceptable. And as we have seen by all of theK >>>> issues in the last few weeks, if Cust's do not test these applications M >>>> with these monthly security patches then they are open to all the issues L >>>> that hit the headlines. In a global market, a companies credibility canJ >>>> take a serious node dive if this happens to them or worse, their CustF >>>> data gets exposed because of one of these monthly security flaws. >>>> >>> H >>> This is all true, today. But, *any* system can be made secure or not >>> secure. E >> Well some have had lots of time, and aren't a bit closer, possibly  >> further away. >> > I > Which ones do you think are less-secure now than in a previous release? / > I see new releases having tightened security.   G Windows and it's included products.  Microsoft seems pretty good about  F replacing a problem with another problem.  They've done it, more than . once.  I'm not interested in citing specifics.  L >>>>> VMS is unusual because its owners keep trying to reinvent the "wheel",K >>>>> then they drop their wheel when they see the "old" wheels rolling on, J >>>>> so they start over and try to invent a different wheel again. In the/ >>>>> meantime, the big wheels keep on rolling.  >>>>>  >>>>> * >>>> Can you expand on what you mean here? >>>>J >>>> Perhaps I missed an extract from an earlier thread, but this does not  >>>> make much sense on its own. >>>> >>> @ >>> Substitute "CPU" for "wheel". Neither Alpha nor Itanium wereC >>> "revolutionary" technologies, they were attempts to advance and C >>> redirect evolution. A true technology "revolution" will quickly G >>> obsolete current technology. Money spent on Alpha and Itanium might % >>> have been better spent elsewhere.   >> Who should work on evolution? >> > C > What? I'm not sure I follow. Intel and AMD (and many others*) are I > "evolving" the chips for x86, and most of the software world is pushing H > them for more. That's pretty much the thrust of what I've been talking
 > about here.   - Power and Sparc seems to have a part in this.   H > (*others: all of the advancements in materials, design, production and9 > all of computer science helps "evolve" chip technology)  > I >> I think Alpha was a decent solution to the problems it was intended to H >> address, and it did the job well.  The only reason Alpha is not aliveI >> today is because Compaq did not want to be in the CPU business, and if F >> they owned the Pentium, they'd still have killed it.  Alpha is deadL >> because the people in charge didn't understand the business they were in. >>E >>> DEC ignored Win-tel until it was too late. Too often history does  >>> repeat itself. >> That I'll agree with. >>6 >> What I won't agree with is the 'quitter' mentality. >> > I > What quitter mentality? Take a hammer and start hitting yourself in the H > head. See how long it takes before you think that maybe that was a bad1 > idea. If you keep on hitting yourself, well,...   ) The quitter mentality of Compaq, for one.   H >> Where would AMD be today if they just figured Intel would control theJ >> CPU world and it was no use competing?  They could have concentrated onK >> something else.  Lots of money in electronics.  But no, they believed in H >> what they were doing, and they upset the hugh unbeatable Intel.  JustE >> read that AMD has a twenty something precent share in last quarter 1 >> server shipments, up from 16 % or thereabouts.  >> >  > F > AMD is helping push the x86 evolution forward. That's what I've saidF > over and over again in this thread. Some here seem to want to ignore1 > that and apparently others don't understand it.   H So, if a CPU mfg is making x86 compatable chips, that's Ok, they're not H bearing their head against the Intel rock,  but to mfg anything else is  not OK?    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------    Date: 27 Apr 2006 14:27:58 -0700- From: "Doug Phillips" <dphill46@netscape.net> # Subject: Re: OT: Sparc not dead yet C Message-ID: <1146173278.864101.211450@i40g2000cwc.googlegroups.com>    Main, Kerry wrote: > > From: Doug Phillips  > > > Main, Kerry wrote: > > > > From: Doug Phillips [  > > >  > 
 > [snip..] >  > > > >  > > > > > > > That assumes you are aware of all the known issues. What > > happens when9 > > > new failures and holes keep coming out every month?  > > > < > > > For companies that literally have hundreds and in some > > cases, thousandsJ > > > of X86 servers, how do you keep them all in sync and up to date when@ > > > there are so many new issues being discovered every month? > > > = > > > Keep in mind that IT shops worth their salt will ensure  > > that the patches> > > > for their main applications (especiually those with Cust > > data) are fully * > > > tested before releasing the patches. > > >  > >  > > E > > So, you're saying that any system can *not* be made secure or not  > > secure.  > >  > I > No - just that some platforms have a track record of security holes and J > as part of the platform TCO, Cust's need to start looking at how much itD > costs to QA/Test their apps every month before they roll out these
 > patches. >   G Okay, look at the track record. Really look. Are those "some platforms" B getting more secure or less secure with each release? Do you thinkB they'll get more secure or less secure with each new release? More& capable or less capable. Jeez. (sorry)   >  > [snip...]  >  > > J > > Why does anything have to come after x86? It's an instruction set. AreJ > > there missing instructions that the world can't live without? Too manyC > > instructions to fit on a fast chip? Some unforeseen radical new F > > technology that can't be handled by specialized chips? What is theG > > technical problem with the x86 instruction set that needs fixing or  > > can't be fixed?  > >  > H > Reminds me of story in the UK around 1900 whereby there was a movementF > or at least a proposal to close the patent department of the govt asA > "everything that can be invented has already been invented ..."  >  > :-)  >   F That remark reminds me more of the person who can't see the forest for all of the trees.    > [snip...]  >  > > I > > WordPerfect vs. Word isn't really a good analogy here, but it kind of H > > supports what I've been saying: "Follow the Money". Or as a buddy of/ > > mine puts it: "Money talks and sh*t walks."  > >  > G > Point is that a defacto standard grew "old" and was replaced by a new 
 > technology.  > " > I expect this trend to continue. >   D Hmm. Word has been WordPerfect compatible since it came out (ok, theD first ones required a "converter" download). And, WordPerfect becameE Word compatible as soon as it was apparent that M$ was Borging the WP C business. That's why I said it wasn't a good analogy to the non-x86 ) compatibles trying to supplant the x86's.   I > Perhaps Google or some other player will emerge as the next IT leader??  >   D It's likely that on-line (on demand?) services will grow, although IE doubt that all of the players in the big-league will jump on-board as D users --- like banks and hospitals and governments and F500's. I see? some of them becoming providers, like large hospitals and banks > providing services to smaller ones --- oh wait, that's already
 happening!  C *Maybe* Google will be a leader there (they want to be), but if so, D they're running x86 servers. So, Google is another x86 evolutionary.   ------------------------------    Date: 27 Apr 2006 15:16:54 -0700- From: "Doug Phillips" <dphill46@netscape.net> # Subject: Re: OT: Sparc not dead yet C Message-ID: <1146176214.146087.162960@i39g2000cwa.googlegroups.com>    Dave Froble wrote: > Doug Phillips wrote: > > Dave Froble wrote: > >> Doug Phillips wrote:  > >>> Main, Kerry wrote:    C Okay, this thread is getting ridiculously long and it's not solving 0 anything other than a few people's need to vent.  C Dave, Kerry, I guess we disagree and maybe one of us will live long  enough to see who was right.  / I'll do this one last time just 'cause I wanta.    > >>>  > > [snips] G > >>> This is all true, Kerry. But how much money can x86's competition K > >>> afford to keep spending to stay ahead? The money being spent on x86's M > >>> evolution is huge. Sun is bleeding to death today and SPARC engineering J > >>> is a big bleeder. At some point, unless Sun is handed a miracle, theL > >>> SPARC division will probably be sold. Whatever is on the SPARC drawingH > >>> board now might or might not ever get to the market. Chips fartherI > >>> along in the process probably will, and a return from that "shorter M > >>> term" market would be a reason Samsung or whoever might want to buy it. E > >>> Anyone willing to do a little homework should come to a similar  > >>> conclusion. K > >> The problem I see with such reasoning is that it's looking only at one L > >> moment in time.  Yes, right now the AMD Opteron is doing well.  Do keepK > >> in mind that it's been called by some "little EV7".  But whoever is on J > >> top today has no guarantee of staying there.  Need I mention DEC, and > >> even Intel? > >> > > B > > Hmm. I seem to be one of the few people here talking about theF > > *future*, so if you mean one moment of time = the future, then ok. > H > No, what I'm saying is that x86 is dominant today, but possibly not in
 > the future.  >   G There is nothing that says the x86 instruction set can't continue on as E long as computers need instruction sets. Whatever the next "computing F revolution" is, I don't know. Maybe someone's drawing it up right now.  J > >>> The Reliability-Availability-Security bar ("goal") is and always hasM > >>> been at 100%. Scalability has a few different meanings depending on the L > >>> problem. As you say, IT users (customers) must continually re-evaluateE > >>> their IT service delivery. Likewise, IT solution providers must A > >>> continually re-evaluate how to best spend their R&D dollar. L > >> Do you really want a world where everyone but one vendor just gives up?K > >>   If you believe that you cannot win, and never start a race, then the = > >> opponent wins by default.  Not everybody is a 'quitter'.  > >> > > J > > What quitter? To keep pouring money into a dry well is stubborn beyondI > > stupid if there's a clean cool spring running out on the back 40.. (I F > > hope that isn't too obscure, but just in case it is, think of "CPU( > > instruction sets" instead of water). > J > You're assuming I guess that IBM with Power, Sun and Fujitso with Sparc,E > and anyone else not using x86 is a dry well?  If so, then we have a  > basic difference of opinion. >   F I am not assuming anything. I'm looking at the flow and power of moneyF and the trends in the technology and I'm drawing conclusions from what I see.  O > >>>> For many of the these Customers, I would suggest that QA/testing monthly J > >>>> security patches (Linux/Windows) with their primary applications isN > >>>> rapidly going to become unacceptable. And as we have seen by all of theM > >>>> issues in the last few weeks, if Cust's do not test these applications O > >>>> with these monthly security patches then they are open to all the issues N > >>>> that hit the headlines. In a global market, a companies credibility canL > >>>> take a serious node dive if this happens to them or worse, their CustH > >>>> data gets exposed because of one of these monthly security flaws. > >>>> > >>> J > >>> This is all true, today. But, *any* system can be made secure or not
 > >>> secure. G > >> Well some have had lots of time, and aren't a bit closer, possibly  > >> further away. > >> > > K > > Which ones do you think are less-secure now than in a previous release? 1 > > I see new releases having tightened security.  > H > Windows and it's included products.  Microsoft seems pretty good aboutG > replacing a problem with another problem.  They've done it, more than 0 > once.  I'm not interested in citing specifics. >   F If you're saying that the latest Windows 2003 server isn't better than> Win2000 and Win2000 wasn't better than WinNT then I guess only! specifics would prove your point.   E Even the best engineers in the world overlook something occassionally ( --- BTW: Hoff's latest blog is right-on.  N > >>>>> VMS is unusual because its owners keep trying to reinvent the "wheel",M > >>>>> then they drop their wheel when they see the "old" wheels rolling on, L > >>>>> so they start over and try to invent a different wheel again. In the1 > >>>>> meantime, the big wheels keep on rolling.  > >>>>>  > >>>>> , > >>>> Can you expand on what you mean here? > >>>>L > >>>> Perhaps I missed an extract from an earlier thread, but this does not" > >>>> make much sense on its own. > >>>> > >>> B > >>> Substitute "CPU" for "wheel". Neither Alpha nor Itanium wereE > >>> "revolutionary" technologies, they were attempts to advance and E > >>> redirect evolution. A true technology "revolution" will quickly I > >>> obsolete current technology. Money spent on Alpha and Itanium might ' > >>> have been better spent elsewhere. " > >> Who should work on evolution? > >> > > E > > What? I'm not sure I follow. Intel and AMD (and many others*) are K > > "evolving" the chips for x86, and most of the software world is pushing J > > them for more. That's pretty much the thrust of what I've been talking > > about here.  > / > Power and Sparc seems to have a part in this.  >   E I don't see how. If the money used to invent and implement completely F new instruction sets had been used simply to advance chip performance,. then yes --- but it wasn't. Is the x86-ABI theG best-one-that-could-ever-be? No, of course not. And, Betamax was better  than VHS, so what.    J > > (*others: all of the advancements in materials, design, production and; > > all of computer science helps "evolve" chip technology)  > > K > >> I think Alpha was a decent solution to the problems it was intended to J > >> address, and it did the job well.  The only reason Alpha is not aliveK > >> today is because Compaq did not want to be in the CPU business, and if H > >> they owned the Pentium, they'd still have killed it.  Alpha is deadN > >> because the people in charge didn't understand the business they were in. > >>G > >>> DEC ignored Win-tel until it was too late. Too often history does  > >>> repeat itself. > >> That I'll agree with. > >>8 > >> What I won't agree with is the 'quitter' mentality. > >> > > K > > What quitter mentality? Take a hammer and start hitting yourself in the J > > head. See how long it takes before you think that maybe that was a bad3 > > idea. If you keep on hitting yourself, well,...  > + > The quitter mentality of Compaq, for one.  >   A Well, that's been talked to death. But, do you think maybe Compaq F actually saw the future a little clearer than some and knew that thereC was no way they could keep pumping their own money into a chip that G would likely be overtaken unless they put so much money into it that it E would hurt them? I think they went about things all wrong, but that's  been talked to death, too.  J > >> Where would AMD be today if they just figured Intel would control theL > >> CPU world and it was no use competing?  They could have concentrated onM > >> something else.  Lots of money in electronics.  But no, they believed in J > >> what they were doing, and they upset the hugh unbeatable Intel.  JustG > >> read that AMD has a twenty something precent share in last quarter 3 > >> server shipments, up from 16 % or thereabouts.  > >> > >  > > H > > AMD is helping push the x86 evolution forward. That's what I've saidH > > over and over again in this thread. Some here seem to want to ignore3 > > that and apparently others don't understand it.  > I > So, if a CPU mfg is making x86 compatable chips, that's Ok, they're not I > bearing their head against the Intel rock,  but to mfg anything else is 	 > not OK?  >   E Well, how is going against the x86 working out so far? Hey, maybe I'm D wrong, but seems like the people who make the products that the mostE people can use and that the most people are writting applications for E will have the most success. Now, if someone finds a better way to run E that software, they'll have a winner. Asking the world to redo all of E their software, or keep different incompatible versions going, hasn't   proven to be a long-term winner.   ------------------------------  % Date: Thu, 27 Apr 2006 18:30:02 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> # Subject: RE: OT: Sparc not dead yet T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B8684013018BE@tayexc19.americas.cpqcorp.net>   > -----Original Message-----7 > From: Doug Phillips [mailto:dphill46@netscape.net]=20  > Sent: April 27, 2006 5:28 PM > To: Info-VAX@Mvb.Saic.Com % > Subject: Re: OT: Sparc not dead yet  >=20  	 [snip...]      > > > G > > > So, you're saying that any system can *not* be made secure or not 
 > > > secure.  > > >  > > ; > > No - just that some platforms have a track record of=20  > security holes and@ > > as part of the platform TCO, Cust's need to start looking=20 > at how much itF > > costs to QA/Test their apps every month before they roll out these > > patches. > >  >=20A > Okay, look at the track record. Really look. Are those "some=20  > platforms"D > getting more secure or less secure with each release? Do you thinkD > they'll get more secure or less secure with each new release? More( > capable or less capable. Jeez. (sorry) >=20  E Well, if that was the case, why is that Windows and Linux continue to * have numerous monthly security patches?=20  F [Please do not state "because they are more popular" as I will scream]  H Red Hat release approx 280 *security* patches last year (not bug fixes),F and they averaged about 10-20 per month. This is on their web site at:@ https://www.redhat.com/archives/enterprise-watch-list/ (click on "threads" for each month) H https://www.redhat.com/archives/enterprise-watch-list/2006-March/thread.) html (19 sec security patches last month)   D So you tell me - does this look like platforms that are getting more secure with each release?=20  G Look at the previous months for Red Hat security patches and see if you % still think it is getting any better.  =20  > > 
 > > [snip...]  > >  > > > : > > > Why does anything have to come after x86? It's an=20 > instruction set. Are= > > > there missing instructions that the world can't live=20  > without? Too many E > > > instructions to fit on a fast chip? Some unforeseen radical new H > > > technology that can't be handled by specialized chips? What is theB > > > technical problem with the x86 instruction set that needs=20 > fixing or  > > > can't be fixed?  > > >  > > B > > Reminds me of story in the UK around 1900 whereby there was=20 > a movementH > > or at least a proposal to close the patent department of the govt asC > > "everything that can be invented has already been invented ..."  > >  > > :-)  > >  >=20H > That remark reminds me more of the person who can't see the forest for > all of the trees.  >=20  F Or perhaps a view from someone who knows that if you spend all of yourH time in the hen house, it is hard to imagine there are any other animals that matter on the farm.   :-)     	 [snip...]   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------    Date: 27 Apr 2006 16:04:30 -0700 From: bob@instantwhip.com # Subject: Re: OT: Sparc not dead yet C Message-ID: <1146179070.475994.304780@i40g2000cwc.googlegroups.com>    "The AMD64 chip C acts more like an Alpha than an 80286. So what. That's evolution. "   . sounds more like patent infringement to me ...   ------------------------------  % Date: Thu, 27 Apr 2006 19:49:33 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> # Subject: Re: OT: Sparc not dead yet , Message-ID: <44515877.5D15A94F@teksavvy.com>   Dave Froble wrote:H > No, what I'm saying is that x86 is dominant today, but possibly not in
 > the future.   ) Yeah, heard that type of argument before.   H PSION, the once leader in PDAs decided that PDAs woudln't have a future,F so it pulled out of the PDA market instead of keeping its place in theH market and bringing ahead its smart phone prototype years ahead of Nokia et all.     G PSION said that it was pointless to sell serial cables between its PDAs E and GSM handsets, because it said that in the future, it would all be C done with the yet to be defined Bluetooth. So at the time we needed F serial cables, we didn't have them. By the time Bluetooth came around," PSION was no longer in the market.  G RIGHT NOW, THE industry standard commodity architecture is the 8086. If A you are going to wait for the 8086 to fade so you can adopt a new G architecture, then you'll apply the same logic when something new comes H along, saying it will eventually be replaced so it is pointless to adopt2 it. So you'll never have anything that is popular.  E RIGHT NOW is when you make sales. and RIGHT NOW you want to be on the B most popular architecture RIGHT NOW.  IA64 is isn't popular. It is' either late to the game or fading away.   H SPARC is riding on its momentum.  But VMS is not riding on any momentum.D If it wants to ride, it needs to latch on to a popular platform. And right now, that is the 8086.   ------------------------------  % Date: Thu, 27 Apr 2006 22:05:33 -0400 2 From: "Timothy Stark" <fsword7_nospam@comcast.net>, Subject: REI and stacked PSL with TP/T bits.0 Message-ID: <QomdncZsV4315czZRVn-og@comcast.com>   Hello folks,  C Does anyone know about how it works with both TP/T-bits during REI   execution?  For example,           PUSHL #10 (T bit set)          PUSHL foo          REI  foo:  inst1 
         inst2 	         : 	         :    and   *         PUSHL #40000010 (TP and T bit set)         PUSHL foo          REI  foo:  inst1 
         inst2 	         : 	         :   I What happens after REI was executed?   Will trace fault occurs before or  " after first instruction execution?   Thanks!  Tim    ------------------------------  % Date: Thu, 27 Apr 2006 20:31:51 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>) Subject: Semi-OT: Changes coming at Intel 6 Message-ID: <44517087.E2510D53@NeOaSrPtAhMlNiOnWk.net>  = At the risk of sounding like others who post such things, ...   I http://www.infoworld.com/article/06/04/27/77838_HNintelrestructure_1.html    Sorry if that wraps.  H In a nutshell, Intel's looking at $9 billion in profits this year versusF $12 billion last year. A major re-org is expected, including "a 90-day= structural reorganization of 'nonperforming business units.'"   9 I'm sure that would not include I64, but it is troubling.    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------  % Date: Thu, 27 Apr 2006 20:34:02 -0600 " From: GreyCloud <mist@cumulus.com>- Subject: Re: Semi-OT: Changes coming at Intel 0 Message-ID: <PpCdnUd3Zf2B4szZ4p2dnA@bresnan.com>   David J. Dachtera wrote:? > At the risk of sounding like others who post such things, ...  > K > http://www.infoworld.com/article/06/04/27/77838_HNintelrestructure_1.html  >  > Sorry if that wraps. > J > In a nutshell, Intel's looking at $9 billion in profits this year versusH > $12 billion last year. A major re-org is expected, including "a 90-day? > structural reorganization of 'nonperforming business units.'"  > ; > I'm sure that would not include I64, but it is troubling.  >   U http://news.com.com/2100-1014_3-6065708.html?part=macworld-cnet&tag=6065708&subj=news   B update "CEO Paul Otellini said Thursday that Intel will undergo a  complete restructuring.   I "We are taking a tight look at spending and structure," Otellini said at  C the chipmaker's shareholder meeting. "We are going to restructure,  H resize and repurpose Intel to adjust to the business realities of today  and tomorrow."   --   Where are we going?   And why am I in this handbasket?   ------------------------------  % Date: Fri, 28 Apr 2006 00:17:18 -0400 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>- Subject: Re: Semi-OT: Changes coming at Intel - Message-ID: <44519723.EA0C84A9@vaxination.ca>    GreyCloud wrote:J > "We are taking a tight look at spending and structure," Otellini said atD > the chipmaker's shareholder meeting. "We are going to restructure,I > resize and repurpose Intel to adjust to the business realities of today  > and tomorrow."    A Yep. But at this point in time, all we can expect is for Intel to G quietly shift more resources from IA64 to the 8086. And that means that B odds of more delays in IA64 increase, and each iteration will have fewwer new features.    B Remember that Digital had very credible charts showing Alpha wouldF always outpace that IA64 thing and they had very credible arguments onE why IA64 was fataly flawed. A day later, those were forgotten and new , charts published stating the exact opposite.  G What this means is that iA64 charts/promises are not credible and could * change any day they decide to change them.  F I am hoping on that June 25 2007, Intel and HP will publish new chartsG showing that the 8086 will outpace that IA64 thing and that HP would be : focusing on the 8086 industry standard commodity platform.    E In february 2004, Intel and HP started to leak information leading to F speculation that IA64 would be replaced by 8087 by 2007. I think it is still on track for this.   ------------------------------  # Date: Thu, 27 Apr 2006 23:46:54 GMT # From: Beach Runner <bob@nospam.com>  Subject: Re: Virtual I/O Cache8 Message-ID: <OJc4g.3365$9o4.603@tornado.tampabay.rr.com>   Dan Foster wrote:  > C > There was at least one nasty XFC bug in 7.2-1 or thereabouts that H > required a key XFC patch to be applied. Workaround was to disable XFC,J > so that might have been the reason why it was set to VCC_FLAGS=1 on your	 > system. J As far as I know, XFC was introduced in 7.3, but immediately had problems. >  > -Dan   ------------------------------  # Date: Thu, 27 Apr 2006 23:44:32 GMT # From: Beach Runner <bob@nospam.com>  Subject: Re: Virtual I/O Cache9 Message-ID: <AHc4g.3347$9o4.2546@tornado.tampabay.rr.com>   # dave.baxter@bannerhealth.com wrote:   F >       We are trying to trouble should a problem on a GS1280, running( > OVMS7.3-2 and TCPIP services 5.4 ECO5.F >      While checking memory on one node it was noted that Virtual I/OA > Cache "Free" was = 0.    It was also discovered that the system E > parameter VCC_FLAGS is set to "1", which is the VAX default, rather ) > than to "2" which is the alpha default.  > = > Q1.    Is Virtual I/O Cache, Free = 0, a potential issue??? = > Q2.    Is having VCC_FLAGS set to 1 on an Alpha system OK?? B > Q2b.        would I be better off with it set to 2, what are the > respective benefits.?? >  > Thanks >  > Dave >  It's normal to reach 0.   G XFC is generally much more effective at caching I/Os, and will cache a  E broader range of them. Certainly, the efforts at HP are going to XFC.   ( Set VCC_flag = 2 and you're ready to go.  4 Make sure you stay current with the latest XFC ecos.  & Your mileage probably won't vary here.   ------------------------------  % Date: Thu, 27 Apr 2006 20:30:17 -0500 % From: Dan Foster <usenet@evilphb.org>  Subject: Re: Virtual I/O Cache5 Message-ID: <slrne52s19.rm2.usenet@zappy.catbert.org>   ] In article <OJc4g.3365$9o4.603@tornado.tampabay.rr.com>, Beach Runner <bob@nospam.com> wrote:  >  > Dan Foster wrote:  >>  D >> There was at least one nasty XFC bug in 7.2-1 or thereabouts thatI >> required a key XFC patch to be applied. Workaround was to disable XFC, K >> so that might have been the reason why it was set to VCC_FLAGS=1 on your 
 >> system.  L > As far as I know, XFC was introduced in 7.3, but immediately had problems.  D Ahh, yes, you're right. I'd been running 7.3 for so long that hadn't remembered it wasn't in 7.2.  H 7.3-1 was the one in dire need of that key ECO; 7.3-2 had it integrated.   -Dan   ------------------------------   End of INFO-VAX 2006.234 ************************                                                                                                                                                                                                                                r&ٹ {su&
\ErBDg_ΛI<.8>X:C{8dw>q|&	
Q5iĮuJRQy|ȵUߏV> 6:Dk~=3KX0U|p0&U6`V=ylkea̪n	7VWٞv*usQ=7y?ٰ@ά}Z
c|Ŷ͌lo()ϯUߗ(A.Nycڡ5ڤS<6jY72$y]|GzVyᝓ29}L.\ގ7xU"B:Ѡt7ei/%8~%K7,z=KR	HU`}\A~s}tj ذ[<*|n5kќU'uYw4>g;,ￖ{.5%l/Rـ}3oXƓ
dtS`[%7\o\vu hTAuņM߹V
N27=MH:8oV_r\;=fr:L?;?}.;1_`a}Ζ׃W&;6.HnqY:fvqn*Ƹ2FqtVꋲyy'gl>9H	WȬ_L&c.Ya-؝uCnhlZ7KAI}]a=H^5L~Qotz(qy!vk@!gDYb3WR/So~'xn[~ҥߡGգ^~_QgV~AzYi@~؝?hhG65s
,ǔ.Tc'wgK60K+q(
ݦF.+Se_f9oվORC|~ʤ7Dqp0W\օ/G9;E& w;<ZG7nYvTߗ4;5UMgmnozgߪGT-R]]su#|B޽YmzĮo.0VW.VqdPl40c	i~kF8^&C?:cdh3](-u
u꒮p,t @4Ҥ6pfvHUvi~(_ãέ^9_,8ωDlH<xi
U>L̜ilZ^}/8hPmU?S[Ճ˺'EnJ5a\O2mklߓ9:j&zޣzf]7/ꗭ9 '6)Pz%mGg9l/H㠵LS9.9Cot"{ifo>.`AҜ>{	j$0,9]}D*UcO@w]Ԣ"zR1fA؛mLWyJU!MEx9BD}WيO3fl:E3j@mb~Unտ[uL=VO9R_iW=t]=%ugן0e1']E+Dڣs_x<⾦#/|4e6C]f-Yc+We	|Qz/೘Wr6JYL[
De\{^vN̼	LymgvyycrB`˿pW| b
CcbVΉ\MG
,y&XF{Wښu>
O]רJc,Sr?{L}]̢o^dkXt*"&F|qX|lr