1 INFO-VAX	Fri, 12 Jul 2002	Volume 2002 : Issue 380       Contents: !MalRe: OpenVMS Ambassadors  Re: !MalRe: OpenVMS Ambassadors - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) # RE: 2002 Worldwide HP OpenVMS Study # Re: 2002 Worldwide HP OpenVMS Study # Re: 2002 Worldwide HP OpenVMS Study # Re: 2002 Worldwide HP OpenVMS Study : Re: Alpha 255 UCX 4.2 slowness - A woeful tale. Any ideas?: Re: Alpha 255 UCX 4.2 slowness - A woeful tale. Any ideas?: Re: Alpha 255 UCX 4.2 slowness - A woeful tale. Any ideas?% Re: Alpha Shadowing Phase II question % Re: Alpha Shadowing Phase II question  Andrew the hypocrite! ' Re: C and X11 programming, finding info ' Re: C and X11 programming, finding info ' Re: C and X11 programming, finding info ' Re: C and X11 programming, finding info  CMS - Command Procedure to logoff inactive users... 1 Re: Command Procedure to logoff inactive users... 1 Re: Command Procedure to logoff inactive users...  Re: Convert conundrum. Help?1 Re: DECdoc -> PDF (Was: Looking for your opinion) 1 Re: DECdoc -> PDF (Was: Looking for your opinion) 1 Re: DECdoc -> PDF (Was: Looking for your opinion) 1 Re: DECdoc -> PDF (Was: Looking for your opinion)  Depressing world of mergers   DLT Tape BarCode label generator Re: Doing the Math on Alpha  Re: Doing the Math on Alpha  Re: Doing the Math on Alpha  Re: Doing the Math on Alpha  Re: Doing the Math on Alpha  Re: Doing the Math on Alpha  Re: DS10 shutting down Re: DS10 shutting down Re: DS10 shutting down DVD drives on OpenVMS  Re: DVD drives on OpenVMS  Re: F$getsyi hidden Feature ?  Re: FTP Hang Question  Re: FTP Hang Question  GUI builder for VMS/Motif & Re: List the processes using a mailbox& Re: List the processes using a mailbox& Re: List the processes using a mailbox& Re: List the processes using a mailbox, RE: Looking for terminal session sharing pgm, Re: Looking for terminal session sharing pgm, Re: Looking for terminal session sharing pgm Re: Looking for your opinion Re: Looking for your opinion Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... RE: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh...+ Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: Only 20% drop in VMS systems (was: wow) . Re: OpenSSL and certificates concept questions. Re: OpenSSL and certificates concept questions Re: OpenVMS Ambassadors  Re: OpenVMS Ambassadors  Re: OpenVMS Ambassadors  Re: OpenVMS Ambassadors  Re: OpenVMS Ambassadors  RE: OpenVMS Ambassadors  Re: OpenVMS Ambassadors  Re: OpenVMS Ambassadors  Re: OpenVMS Ambassadors  Re: OpenVMS Ambassadors  Re: OpenVMS Ambassadors  Re: OpenVMS Ambassadors  Re: OpenVMS Ambassadors  Re: OpenVMS Ambassadors  Re: OpenVMS Ambassadors  Re: OpenVMS Polls are back!  Re: OpenVMS Polls are back!  Re: OpenVMS Polls are back!  Re: PURGE   version set to ;1 1 Re: Quality control problems in VMS Engineering ? 1 Re: Quality control problems in VMS Engineering ?  Re: Quick Poll - two sessions  Re: RECALL suggestion  Re: Used Alpha's and Vax's Re: Used Alpha's and Vax's Re: VAX Scan on OpenVMS Alpha  RE: VAX Scan on OpenVMS Alpha B Re: VMS vs. MVS (was: Re: McKinley tops SpecFP AND SpecInt charts)/ Re: What does UCX 6.2 SMTP intermittently fail?  Worldcom soap opera   F ----------------------------------------------------------------------  # Date: Thu, 11 Jul 2002 23:08:59 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com> $ Subject: !MalRe: OpenVMS Ambassadors. Message-ID: <feoX8.154289$Uu2.34623@sccrnsc03>  . "John Smith" <a@nonymous.com> wrote in messageB news:GDlX8.12854$WJf1.9814@news01.bloor.is.net.cable.rogers.com... > > > "Terry C. Shannon" <terryshannon@attbi.com> wrote in message* > news:MSkX8.152678$Uu2.34534@sccrnsc03... > > H > > Relax, Sue... the whining, whinging, and griping and moaning clearly come > > from people who  > > 0 > > A) Are not key customers or key influencers, > >  > > and  > > L > > B) take a self-defeatist delight in showcasing their complete ignorance. > > % > > Par for the course in this venue.  >  >  > Terry, > C > If you or HP don't take the attitude that EVERY customer is a key 	 customer, - > then you both deserve to go down the tubes.   J That is your opinion, whoever the hell you are. Incidentally, I place veryE little credence in people who post anonymously. If you don't have the I fortitude to admit who you are, I consider your comments to be completely  without merit.  I Now. If you think you have the power to flush me down the tubes, I hereby  dare you to GO FOR IT!   Make my day, whoever you are   ------------------------------  # Date: Fri, 12 Jul 2002 04:16:31 GMT # From: "John Smith" <a@nonymous.com> ( Subject: Re: !MalRe: OpenVMS AmbassadorsE Message-ID: <zKsX8.1146$7vA.995@news01.bloor.is.net.cable.rogers.com>   < "Terry C. Shannon" <terryshannon@attbi.com> wrote in message( news:feoX8.154289$Uu2.34623@sccrnsc03... >  >> ....go down the tubes.   1 > That is your opinion, whoever the hell you are.   I No Terry, that's an observation of what the market does to companies that I don't take their customers seriously. You've seen it and written about it 
 often enough.   F In this case 'the market' is both customers and Wall Street. CustomersJ because when they walk revenues and profits drop. Wall Street because whenI revenues and profits are down, and defection rates go up and PC's haven't L turned around, then the cash cushion starts to run low and the credit ratingL suffers. Which means when they have to go to the bond market to borrow moneyE the rate they have to pay goes up significantly too, and impact later L earnings. That only makes sense in a real growth industry where revenues areK increasing by leaps and bounds. Their recent bond offerings last month were K rated "A3" by Moody's Investors Services, "A-" by Standard & Poor's and "A" K by Fitch Ratings, ***in each case with a negative outlook***. That's single H A for god's sake. Some investment managers won't buy BBB-rated bonds anyJ more, and HP is one step from that. Yes, companies are tending to buy moreG and more gear, but the unit cost keeps coming down, so revenues tend to 8 stagnate relative to where they may otherwise have been.  H With the capital markets spooked the way they are, many corporations areG going to continue to defer IT capital expenditures as long as possible, I because many of them would rather raise the money first before they spend H it, and that just isn't happening to the extent that would significantlyL help HP at this time. HP has two dead processor families (PA and Alpha) theyF are trying to flog at the same time as a new processor on the block isI introduced to not as rabid a reception as they'd have liked, one dead OS, L and another that is not marketed, and all the while the PC market hangs like* an over-ripe albatross around their necks.  F VMS was about 1/4 of the all-in revenue stream for Compaq and they didI nothing to effectively market it; with HP it's less than 10%. It's all to D easy for a big corporation to 'forget' about something that 'small',L especially when it has a small mindshare even within the corporation itself,J never mind the potential customer base. Perhaps some of the complaining inK c.o.v. reaches the ears of those that hold the controls and that would be a I good thing, because in the absence of those complaints it would seem that $ complacency is the order of the day.      @ > Incidentally, I place very  little credence in people who post" anonymously. If you don't have theK > fortitude to admit who you are, I consider your comments to be completely  > without merit.  E The truth, or reasonable approximation thereof, is where you find it, F irrespective of who writes it. Whether it is me, or you, a Nobel PrizeJ winning economist, Bob Celuski (just kidding), or somebody else who writes it matters not.     K > Now. If you think you have the power to flush me down the tubes, I hereby  > dare you to GO FOR IT!  H If you carefully re-read what I wrote, I never suggested that I would orK could do that. I am sorry I worded things that way with respect to you, but  I do mean it relative to HP.   ------------------------------   Date: 11 Jul 2002 18:03:05 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)0 Message-ID: <agkh8p$fra$1@pegasus.csx.cam.ac.uk>  a In article <1026405894.951169@nnrp2.phx1.gblx.net>, "Dennis O'Connor" <dmoc@primenet.com> writes: 1 |> "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote ... F |> > If I were designing a clean CISC ISA, it would be very like RISC,F |> > but with some of the heretical features added consistently.  SuchF |> > as, say, variable length instructions where a few bits in a fixedE |> > location in the first byte determined the instruction format and . |> > number and format of operands, PRECISELY. |>  D |> This kind of context-sensitive instruction decode is a major painF |> in the ass if you want to build a superscalar pipeline, and I doubtB |> the slightly decreased instruction fetch bandwidth and slightly? |> lower demands on i-cache capacity can justify it in a modern 9 |> system, except maybe for really low-end embedded stuff 1 |> where smaller binaries can bring cost savings.   ? Or where you separate the instruction decode and execute steps, : as in the Pentium 4.  Given that design, its extra cost is negligible.   A But I think that you missed my point about saying that the format ; should be a small number of bits in a fixed location, which > specify the format precisely.  Given those constraints, it may? be a pain, but is not likely to be a major pain.  Without those + constraints, it could well be a major pain.      Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679    ------------------------------  % Date: Thu, 11 Jul 2002 14:42:08 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...), Message-ID: <3D2DD173.F7F130E5@videotron.ca>   Nick Maclaren wrote:C > If I were designing a clean CISC ISA, it would be very like RISC, C > but with some of the heretical features added consistently.  Such C > as, say, variable length instructions where a few bits in a fixed B > location in the first byte determined the instruction format and+ > number and format of operands, PRECISELY.   M But doesn't variable length instructions add considerably to the headaches of = pipelines , pre-fetching and also branch prediction etc etc ?   L I remember the days of looking at COBOL memory dumps from ibm mainframes andH decoding the instructions. You really needed to know assembler and stillJ needed THE card (with all the instructions , their opcode and arguments asI well as instruction length) to go through it and find out what was really 	 going on.     M But the 360/370/390 architecture is MUCH MUCH simpler than the VAX one and in K many aspects, could have been considered a RISC because its adressing modes ! were more restrained than on VAX.    ------------------------------   Date: 11 Jul 2002 18:43:38 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)0 Message-ID: <agkjkq$hhl$1@pegasus.csx.cam.ac.uk>  , In article <3D2DD173.F7F130E5@videotron.ca>,/ JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:  >Nick Maclaren wrote: D >> If I were designing a clean CISC ISA, it would be very like RISC,D >> but with some of the heretical features added consistently.  SuchD >> as, say, variable length instructions where a few bits in a fixedC >> location in the first byte determined the instruction format and , >> number and format of operands, PRECISELY. > N >But doesn't variable length instructions add considerably to the headaches of> >pipelines , pre-fetching and also branch prediction etc etc ?  F See my reply to Dennis O'Connor.  Subject to the constraints I mentionA above, it does complicate such things, but not considerably.  But F please don't think that I regard the above as necessarily a good idea;A it is an example of something that is definitely CISC and yet can  still be done cleanly.  E As an example of a really UNCLEAN equivalent, consider a format where ? there are 256 opcodes, with a variety of numbers and formats of B operands, and where an operand's length was similarly derived fromC some of the bits in the operand itself.  Or, even more revoltingly, A where the format of an operand could be changed by the value in a 	 register!   B Some of the nastier restrictions in the nastier RISC architectures run that pretty close.  M >I remember the days of looking at COBOL memory dumps from ibm mainframes and I >decoding the instructions. You really needed to know assembler and still K >needed THE card (with all the instructions , their opcode and arguments as J >well as instruction length) to go through it and find out what was really
 >going on.  A It depends on how well you knew the instruction set - those of us 6 who did a fair amount of that didn't need the card :-)  B More seriously, needing a reference card is one thing, but needing@ to refer to a full manual is another.  And I have had to on some? RISC architectures, because there were so many complications in C the specification that I couldn't remember exactly what was allowed  and what the effect was.  N >But the 360/370/390 architecture is MUCH MUCH simpler than the VAX one and inL >many aspects, could have been considered a RISC because its adressing modes" >were more restrained than on VAX.  B Precisely.  Why do you think that I called its basic design clean?     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679    ------------------------------  % Date: Thu, 11 Jul 2002 16:00:55 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...), Message-ID: <3D2DE3E5.7B55A4AF@videotron.ca>   Jan-Erik Sderholm wrote: J > I checked some ASM genereted from the COBOL compiler on a IBM mainframe,H > and e.g. e COBOL "MOVE ONE-STRING-VARIABLE TO ANOTHER-STRING-VARIABLE"  N Yep, Cobol mapped very well to assembler for most operations, but when you gotG a dump, you still had to locate the instruction and there were no clear L "boundaries" due to variable instruction lengths, so you really had to count5 the bytes to arrive at the opcode of the instruction.   I I have been on VMS for about 15 years now, and I still know IBM assembler M better than VAX. partly because I never really had to know VAX assembler, but C also because IBM assembler was much simpler in its instruction set.   M A few years ago, I amazed one mainframe guy because overlooking his shoulder, G I found the bug in the assembler code he was trying to debug and he had N absolutely no idea I knew anything but VMS. And that was years and years after% I had last played with IBM assembler.   L Personally, I think that learninbg IBM assembler was perhaps one of the mostL key  IT courses I ever took (along with computer architecture when you learn8 how and/or gates are put together to add, subtract etc).  N Anyone who doesn't know any assembler probably lacks a lot of understanding of how computer works.e   ------------------------------  % Date: Thu, 11 Jul 2002 15:53:56 -0400C From: William_Bochnik@acml.com6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)> Message-ID: <OF31B0B8E9.126DEC68-ON85256BF3.006D2F58@acml.com>  = Hear hear - I'm tired of those MS techweenies who can't thinkI? past the mouse - learn hardware and assembler first.  It's goodl6 for an understanding of what's going on, as well as an understanding of bad practices.         H                                                                        =,                                          =20H                       JF Mezei                                         =,                                          =20H                       <jfmezei.spamnot@vi                To:  Info-VAX@=, Mvb.Saic.Com@SMTP@SCB                    =20H                       deotron.ca>                        cc:           =,                                          =20H                                                   Subject: Re: "Clean" =, CISC (was Re: McKinley Cometh...)        =20H                       07/11/2002 04:00 PM                              =,                                          =20H                       Please respond to                                =,                                          =20H                       JF Mezei                                         =,                                          =20H                       <jfmezei.spamnot@vi                              =,                                          =20H                       deotron.ca>                                      =,                                          =20H                                                                        =,                                          =20H                                                                        =,                                          =20       Jan-Erik S=F6derholm wrote:e? > I checked some ASM genereted from the COBOL compiler on a IBMn
 mainframe,/ > and e.g. e COBOL "MOVE ONE-STRING-VARIABLE TOs ANOTHER-STRING-VARIABLE"  A Yep, Cobol mapped very well to assembler for most operations, butr when you gotA a dump, you still had to locate the instruction and there were no  cleare? "boundaries" due to variable instruction lengths, so you reallya had to count5 the bytes to arrive at the opcode of the instruction.s  ? I have been on VMS for about 15 years now, and I still know IBMk	 assemblerm> better than VAX. partly because I never really had to know VAX assembler, but> also because IBM assembler was much simpler in its instruction set.  ? A few years ago, I amazed one mainframe guy because overlookingm
 his shoulder,i@ I found the bug in the assembler code he was trying to debug and he had> absolutely no idea I knew anything but VMS. And that was years and years after.% I had last played with IBM assembler.y  @ Personally, I think that learninbg IBM assembler was perhaps one of the mostc= key  IT courses I ever took (along with computer architecturea when you learn8 how and/or gates are put together to add, subtract etc).  = Anyone who doesn't know any assembler probably lacks a lot oft understanding of how computer works.e              H The information contained in this transmission may contain privileged a=8 nd confidential information and is intended only for theH use of the person(s) named above.  If you are not the intended recipien=: t, or an employee or agent responsible for delivering thisH message to the intended recipient, any review, dissemination, distribut=4 ion or duplication of this communication is strictlyH prohibited.  If you are not the intended recipient, please contact the =9 sender immediately by reply e-mail and destroy all copiest of the original message.   =    ------------------------------  % Date: Thu, 11 Jul 2002 22:01:36 +0200o9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>x6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)' Message-ID: <3D2DE420.BD0A0E0E@aaa.com>e   Amen to that !  7 I got a large deal of my professional base from playinge: around with a home built microprocessor card (called SC/MP6 and used in a build-it-yourself project in the magasin? "Elector" during the late 70's.) Made it all, including etchingT: and drilling the PCB's. No ROM, 256 *bytes* mem, two 8-bit> DIP switches for "programming". I had it playing the wellknown! intro to "Smoke on the water" :-)m   Well well, that was times...  	 Jan-Erik.4   JF Mezei wrote:t >  > P > Anyone who doesn't know any assembler probably lacks a lot of understanding of > how computer works..   ------------------------------  % Date: Thu, 11 Jul 2002 13:07:32 -0700i+ From: "Dennis O'Connor" <dmoc@primenet.com> 6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)3 Message-ID: <1026417901.734555@nnrp2.phx1.gblx.net>i  , "Jan-Erik Sderholm" <aaa@aaa.com> wrote ...9 > RISC vs. CICS is not only about addressing modes, not ?   1 Way-back-when, "RISC-v-CISC" were more indicativea/ of radically different ISA design philosophies:u  @ CISC: "Closing the semantic gap" between ISA and program intent,B      which lead to tagged architectures like the i432, and the VAX@     "evaluate polynomial" instruction, and the "5th generation";      a CS grad-student attitude   3 RISC: performance of compiled code is what matters,o5      and if feature drops the clock speed enough thatI:      overall performance drops, or if a compiler can't use9      that feature, it probably doesn't belong in the ISA; "     a more commercial-EE attitude.  8 A lot of the early RISC work seemed inspired by the VAX:4 people noticed that sequences of simple instructions6 out-performed the equivalent complex instructions, and@ started to question why the hell the complex ones were in there.  3 These days, all competent commercial architects useo6 the RISC philosophy, even when working on "CISC" ISAs,3 because end-users care about price/performance, nota all that theoretical CS stuff. --7 Dennis O'Connor                       dmoc@primenet.com 4 "We don't become a rabid dog to destroy a rabid dog"   ------------------------------  % Date: Thu, 11 Jul 2002 21:38:47 +0200l9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>f6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)' Message-ID: <3D2DDEC7.E94DA825@aaa.com>t  C Isn't the "R" i RISC "Reduced" and the first "C" in CICS "Complex".   H I checked some ASM genereted from the COBOL compiler on a IBM mainframe,F and e.g. e COBOL "MOVE ONE-STRING-VARIABLE TO ANOTHER-STRING-VARIABLE"E was more or less compiled inte one *single* ASM instuction, somethingbC like "MOVC ..." I think. That's "complex" to me. I'll bet that mostcD RISC processors would take more then one ASM instruction to do that.  7 RISC vs. CICS is not only about addressing modes, not ?   B Well, that was the times when a programmer could look at some code< and say "well, that'll take 54 machine cycles", or whatever.A Today, with the "Visual [your_favourite_language]" type of tools,e' (most) programmers don't have a clue...e   Jan-Erik Sderholm.e   JF Mezei wrote:t > O > But the 360/370/390 architecture is MUCH MUCH simpler than the VAX one and inrM > many aspects, could have been considered a RISC because its adressing modese# > were more restrained than on VAX.p   ------------------------------  % Date: Thu, 11 Jul 2002 21:57:06 +0100t, From: Peter Boyle <pboyle@holyrood.ed.ac.uk>6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)H Message-ID: <Pine.GSO.4.33.0207112134100.10471-100000@holyrood.ed.ac.uk>  0 On Thu, 11 Jul 2002, Jan-Erik S=F6derholm wrote:  J > I checked some ASM genereted from the COBOL compiler on a IBM mainframe,H > and e.g. e COBOL "MOVE ONE-STRING-VARIABLE TO ANOTHER-STRING-VARIABLE"G > was more or less compiled inte one *single* ASM instuction, somethingeE > like "MOVC ..." I think. That's "complex" to me. I'll bet that mostiF > RISC processors would take more then one ASM instruction to do that.    Well, how about two for PowerPC.    =09lswi  R10,R1,nbi =09stswi R10,R1,nb  D Loads/stores a string of length nb (up to 32) bytes, across multipleC registers (up to 8) starting at R10 in this case, and pads the lasta register filled with zeros.o@ Other versions of the instructions exist where the byte count is
 programmable.e  D > Well, that was the times when a programmer could look at some code> > and say "well, that'll take 54 machine cycles", or whatever.C > Today, with the "Visual [your_favourite_language]" type of tools, ) > (most) programmers don't have a clue...y  F It is very hard with todays memory systems to take plain asm that doesC anything non-trivial and predict how long it will take, let alone ay compiled language.   Petern   > Jan-Erik S=F6derholm.n >o > JF Mezei wrote:  > > L > > But the 360/370/390 architecture is MUCH MUCH simpler than the VAX one = and inL > > many aspects, could have been considered a RISC because its adressing m= odes% > > were more restrained than on VAX.  >o  & Peter Boyle=09pboyle@physics.gla.ac.uk   ------------------------------  % Date: Thu, 11 Jul 2002 17:43:49 -0400k- From: JF Mezei <jfmezei.spamnot@videotron.ca>s6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...), Message-ID: <3D2DFBFC.E9E6927B@videotron.ca>   Peter Boyle wrote:" > Well, how about two for PowerPC. >  >         lswi  R10,R1,nba >         stswi R10,R1,nbr  G And where does R1 get loaded in there ? So you'd need 3 instructions...R  J MVC in IBM assembler has the ability to address memory directly because itM uses, for both source and destination, a base register and displacement (basecN register is usually set when the routine starts and memory references are madeB relative to that register (usually 15), but can be something else.  \ MVC essentially takes 5 arguments: length, base-1, displacement-1, base-2 and displacement-2  H each base-displacement combo could be coded as a variable name which theH assembler would convert to a base register and displacement combination.  D The length is limited to 4 bits though, but later version of the 360J architecture had a Move-long which was able to move large/vasts amounts of memory in a single instruction.s  M P.S. Binders tend to stick together after years of being stacked against eachh	 other :-)u   ------------------------------  # Date: Thu, 11 Jul 2002 21:31:00 GMTo* From: "Bill Todd" <billtodd@metrocast.net>6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)A Message-ID: <oOmX8.34917$iB1.1935625@bin4.nnrp.aus1.giganews.com>o  6 "Dennis O'Connor" <dmoc@primenet.com> wrote in message- news:1026417901.734555@nnrp2.phx1.gblx.net...n. > "Jan-Erik Sderholm" <aaa@aaa.com> wrote ...; > > RISC vs. CICS is not only about addressing modes, not ?4 >23 > Way-back-when, "RISC-v-CISC" were more indicative-1 > of radically different ISA design philosophies:0 > B > CISC: "Closing the semantic gap" between ISA and program intent,D >      which lead to tagged architectures like the i432, and the VAXB >     "evaluate polynomial" instruction, and the "5th generation";! >      a CS grad-student attitudeC  3 Well, there was a bit more than philosopy involved.s  F Way-back-when, code size mattered - in many environments a *lot*.  AndC way-back-when, compilers often weren't nearly as smart/efficient in I translating source intent to underlying machine operations as they becamei later.   >n5 > RISC: performance of compiled code is what matters,i7 >      and if feature drops the clock speed enough that < >      overall performance drops, or if a compiler can't use; >      that feature, it probably doesn't belong in the ISA;d$ >     a more commercial-EE attitude. >c: > A lot of the early RISC work seemed inspired by the VAX:6 > people noticed that sequences of simple instructions8 > out-performed the equivalent complex instructions, andB > started to question why the hell the complex ones were in there.  L Questioning why a *lot* of the complex instructions were there was eminentlyK reasonable (especially after code size became less of an issue and compiler2I practices evolved).  But it's still not clear to me that something like alL memory-to-memory move (or fill, or even scan) operation is best performed byI a sequence of RISC instructions - unless it really would be impossible tozF add such facilities compatibly to (but possibly largely separate from,K though some kind of address-range checks might need to interact), e.g., thehJ pipeline of an otherwise RISC architecture.  For that matter, that kind ofF operation does not differ all that much from the kind of parallelism aG processor shares with its system's DMA engines, and could operate under G similar ground rules (not necessarily software-transparent, which couldyJ eliminate the aforementioned interaction issues as well as clearly freeingG up the pipeline to do other work in parallel - assuming the bulk-memoryII operation didn't consume all available processor/memory bandwidth:  if it K did, then the feature would have zero advantage over the instruction loop).i   >e5 > These days, all competent commercial architects use 8 > the RISC philosophy, even when working on "CISC" ISAs,5 > because end-users care about price/performance, not   > all that theoretical CS stuff.  I Price/performance is exactly what I was discussing above:  I appreciate aeJ lot of what the CS community has to offer, but I'm definitely an engineer.K As usual, philosophies may be useful as guides but the devil winds up beingrJ in the details that the philosophies may just skate over (because they mayE not quite fit with the large, but average, picture that generated the C philosophy in the first place).  Of course, when deviating from theyI philosophy it's also vital to keep both eyes on any future development incK the same philosophical direction that your deviation might tend to precluderI (and/or that might make your deviation unnecessary after all):  one wouldy: hope that the philosophy did have a good underlying basis.   - bill   ------------------------------  # Date: Thu, 11 Jul 2002 22:03:36 GMTi* From: "Bill Todd" <billtodd@metrocast.net>6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)A Message-ID: <YgnX8.46704$Bt1.2507874@bin5.nnrp.aus1.giganews.com>f  3 "Jan-Erik Sderholm" <aaa@aaa.com> wrote in messagee! news:3D2DDEC7.E94DA825@aaa.com...t   ...0  D > Well, that was the times when a programmer could look at some code> > and say "well, that'll take 54 machine cycles", or whatever.C > Today, with the "Visual [your_favourite_language]" type of tools,u) > (most) programmers don't have a clue...?  H It's not just HLL (or 'higher') facilities that contribute to this.  TheH last real assembly-level code-optimization I did was on early Alphas andF 80486s:  the latter were straight-forward, but the former were alreadyI getting a bit complex (largely in rearranging instructions such that theyFJ paired up or loaded ahead for efficient execution, though it was wonderfulJ for the first time to have enough registers to do exactly what I wanted to$ in a moderately complex inner loop).  E While I won't suggest that comparable progammer-level optimization isBL *impossible* on today's variants of both architectures (due to how much moreI hardware-level rearrangement of the code stream takes place), things havetH gotten to the point where I *really* hope that a compiler, given a cleanL source implementation, will do something close to the right thing, or at theL very least that the hardware will if given what would be a near-optimal codeI sequence on an in-order, single-issue implementation of the architecture.    - bill   ------------------------------   Date: 11 Jul 2002 22:14:44 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)0 Message-ID: <agl00k$q2b$1@pegasus.csx.cam.ac.uk>  A In article <oOmX8.34917$iB1.1935625@bin4.nnrp.aus1.giganews.com>,e) Bill Todd <billtodd@metrocast.net> wrote:y7 >"Dennis O'Connor" <dmoc@primenet.com> wrote in messages. >news:1026417901.734555@nnrp2.phx1.gblx.net... >>4 >> Way-back-when, "RISC-v-CISC" were more indicative2 >> of radically different ISA design philosophies: >>C >> CISC: "Closing the semantic gap" between ISA and program intent,kE >>      which lead to tagged architectures like the i432, and the VAXrC >>     "evaluate polynomial" instruction, and the "5th generation";1" >>      a CS grad-student attitude >c4 >Well, there was a bit more than philosopy involved. >hG >Way-back-when, code size mattered - in many environments a *lot*.  AndeD >way-back-when, compilers often weren't nearly as smart/efficient inJ >translating source intent to underlying machine operations as they became >later.t  @ Interestingly enough, some research has shown that this is stillC at least partially true.  If you interpret byte code using a really @ tight loop, you can often get impressively close to the speed of> compiled code.  This is merely a CISC instruction set executed in microcode, but in software!  = My belief is that, if you did it PROPERLY, you could probably @ get a moderate improvement in performance over most (if not all)1 existing architectures.  This is the approach of:   >     The 'ISA' is designed for a combination of code generation@ from important HLLs and clean conversion into the hardware code.A It is probable that a template-based macro facility would pay, by 0 allowing a HLL to customise the ISA for its use.  C     The hardware code is designed for efficient hardware execution, C sufficient flexibility to support the ISA and little else.  I.e. it 1 would be an extreme, but very clean, RISC system.   ?     The conversion is done when loading the pipeline and/or the A first-level instruction cache, much as in the Pentium 4, but witha/ an absolute prohibition on self-modifying code.   6 >> RISC: performance of compiled code is what matters,8 >>      and if feature drops the clock speed enough that= >>      overall performance drops, or if a compiler can't use < >>      that feature, it probably doesn't belong in the ISA;% >>     a more commercial-EE attitude.  >>; >> A lot of the early RISC work seemed inspired by the VAX:=7 >> people noticed that sequences of simple instructions-9 >> out-performed the equivalent complex instructions, andoC >> started to question why the hell the complex ones were in there.O >SM >Questioning why a *lot* of the complex instructions were there was eminentlyaL >reasonable (especially after code size became less of an issue and compilerJ >practices evolved).  But it's still not clear to me that something like aM >memory-to-memory move (or fill, or even scan) operation is best performed byoJ >a sequence of RISC instructions - unless it really would be impossible toG >add such facilities compatibly to (but possibly largely separate from,eL >though some kind of address-range checks might need to interact), e.g., theK >pipeline of an otherwise RISC architecture.  For that matter, that kind ofeG >operation does not differ all that much from the kind of parallelism a H >processor shares with its system's DMA engines, and could operate underH >similar ground rules (not necessarily software-transparent, which couldK >eliminate the aforementioned interaction issues as well as clearly freeing H >up the pipeline to do other work in parallel - assuming the bulk-memoryJ >operation didn't consume all available processor/memory bandwidth:  if itL >did, then the feature would have zero advantage over the instruction loop).  B Yes.  Very much so.  The previous incarnation of RISC (in the late= 1960s) noted that compilers typically used only 10-30% of the A instruction set, and favoured optimising an ISA for the compiler.dB The later incarnation (i.e. the current one) got half of the pointC (simplicity) but missed the point about providing an ISA that couldi be optimised into.  A And your point about the memory operations being similar to thoset? needed for communication is one that is sadly missed by most ofe the current HPC people :-(  6 >> These days, all competent commercial architects use9 >> the RISC philosophy, even when working on "CISC" ISAs,a6 >> because end-users care about price/performance, not! >> all that theoretical CS stuff.c >xJ >Price/performance is exactly what I was discussing above:  I appreciate aK >lot of what the CS community has to offer, but I'm definitely an engineer.o  ? Well, I have favoured the RISC approach for 30+ years, but I amd@ a purist.  But I am seriously amused at the idea of CISC being aA CS viewpoint and RISC the engineer's - the reality of the currentn' incarnation was PRECISELY the opposite!b  C Those of us who remember 1980 will remember the computer scientiststA declaiming the RISC slogan and the computer companies saying that B it will never take off :-)  That is, after all, why Intel designed= the 8086 architecture and Motorola the 68000 - and most othern vendors did the same.r     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 3346795   ------------------------------  % Date: Thu, 11 Jul 2002 15:15:58 -0700 + From: "Dennis O'Connor" <dmoc@primenet.com>d6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)2 Message-ID: <1026425608.16602@nnrp1.phx1.gblx.net>  . "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote ...1 > JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:  > >Nick Maclaren wrote:3F > >> If I were designing a clean CISC ISA, it would be very like RISC,F > >> but with some of the heretical features added consistently.  SuchF > >> as, say, variable length instructions where a few bits in a fixedE > >> location in the first byte determined the instruction format and . > >> number and format of operands, PRECISELY. > >IP > >But doesn't variable length instructions add considerably to the headaches of@ > >pipelines , pre-fetching and also branch prediction etc etc ? >o" > See my reply to Dennis O'Connor.  $ There is no such reply on my server.  5 Also, as this thread has no relevance to comp.os.vms,  I've removed it from follow-upsc --7 Dennis O'Connor                       dmoc@primenet.com"4 "We don't become a rabid dog to destroy a rabid dog"   ------------------------------  % Date: Fri, 12 Jul 2002 00:23:42 +0100 , From: Peter Boyle <pboyle@holyrood.ed.ac.uk>6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)H Message-ID: <Pine.GSO.4.33.0207120011260.10471-100000@holyrood.ed.ac.uk>  $ On Thu, 11 Jul 2002, JF Mezei wrote:   > Peter Boyle wrote:$ > > Well, how about two for PowerPC. > >  > >         lswi  R10,R1,nb  > >         stswi R10,R1,nbe >aI > And where does R1 get loaded in there ? So you'd need 3 instructions...h   Lets pretend I saidB   move32bytes:         lswi  R5,R3,nb         stswi R5,R4,nb 	blr  F This is complete function that copies nb (compile time constant) bytesC from pointer argument 1 to pointer argument 2. No loading in, sincee, arguments are passed in registers R3, R4,...  2 i.e. These three instructions encode the whole of:  # move32bytes(char * src, char *dest)  {   for ( i = 0; i< 32; i ++ ) {     dest[i] = src[i];  } }m  B Since I switched the registers touched to R5...R12 it stays withinI the caller save regs, and there's is _no_ entry exit/code bar the branch.p@ The trailing branch is presumably not performed by MVC either ;)  E The lswx and stswx add a variable displacement to the base registers,hG but the count is then stored in xer, and therefore adds one instruction = load up xer, with the gain of making this a runtime variable.X   Peter-  L > MVC in IBM assembler has the ability to address memory directly because itO > uses, for both source and destination, a base register and displacement (baseoP > register is usually set when the routine starts and memory references are madeD > relative to that register (usually 15), but can be something else. >A^ > MVC essentially takes 5 arguments: length, base-1, displacement-1, base-2 and displacement-2 >BJ > each base-displacement combo could be coded as a variable name which theJ > assembler would convert to a base register and displacement combination. >.F > The length is limited to 4 bits though, but later version of the 360L > architecture had a Move-long which was able to move large/vasts amounts of! > memory in a single instruction.r >aO > P.S. Binders tend to stick together after years of being stacked against eachi > other :-)t >    ------------------------------  % Date: Thu, 11 Jul 2002 19:58:31 -0400h- From: JF Mezei <jfmezei.spamnot@videotron.ca>r6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...), Message-ID: <3D2E1B85.CFE62BE7@videotron.ca>    One issue about the MVC vs RISC.  J In cobol and other languages, MVC uis extremely useful because you know in) advance how many bytes need to be copied..  L But in Unix/C, a routine such as strcpy must really look at individual bytesL to determine where the copy is to stop, so a single assembler instruction toN move large amounts of data doesn't map terribly well to C in this case and you= need a loop with a test for 0 in there and move byte by byte.e   ------------------------------  % Date: Fri, 12 Jul 2002 01:07:25 +0100a, From: Peter Boyle <pboyle@holyrood.ed.ac.uk>6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)H Message-ID: <Pine.GSO.4.33.0207120104250.10471-100000@holyrood.ed.ac.uk>  $ On Thu, 11 Jul 2002, JF Mezei wrote:  " > One issue about the MVC vs RISC. >"L > In cobol and other languages, MVC uis extremely useful because you know in+ > advance how many bytes need to be copied.w >oN > But in Unix/C, a routine such as strcpy must really look at individual bytesN > to determine where the copy is to stop, so a single assembler instruction toP > move large amounts of data doesn't map terribly well to C in this case and you? > need a loop with a test for 0 in there and move byte by byte.e   Absolutely, ;)  ) C null terminated strings are responsiblen1 for a great many optimisation and security evils.)   Peter    ------------------------------    Date: 11 Jul 2002 18:19:26 -07004 From: gherbert@gw.retro.com (George William Herbert)6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)' Message-ID: <aglaqu$59t$1@gw.retro.com>b  . Peter Boyle  <pboyle@holyrood.ed.ac.uk> wrote:O >> But in Unix/C, a routine such as strcpy must really look at individual bytesdO >> to determine where the copy is to stop, so a single assembler instruction tosM >> move large amounts of data doesn't map terribly well to C in this case andaD >> you need a loop with a test for 0 in there and move byte by byte. >1 >Absolutely, ;)0 >M* >C null terminated strings are responsible2 >for a great many optimisation and security evils.  9 While true, note that this is a standard library problem,i# not an underlying language problem.o  9 One could trivially write up a library full of equivalent25 functions using an alternative string handling system>; (say, a struct with string_len and string_ptr) which didn'td# have to deal with null terminators.C     -george william herbert- gherbert@retro.com   ------------------------------  + Date: Thu, 11 Jul 2002 19:53:08 +0000 (UTC)IA From: "Rupert Pigott" <dark.try-eating-this.b00ng@btinternet.com>i6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)1 Message-ID: <agknn3$2g0$1@knossos.btinternet.com>r  5 "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in messageh* news:agkjkq$hhl$1@pegasus.csx.cam.ac.uk.... > In article <3D2DD173.F7F130E5@videotron.ca>,1 > JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:s > >Nick Maclaren wrote:lF > >> If I were designing a clean CISC ISA, it would be very like RISC,F > >> but with some of the heretical features added consistently.  SuchF > >> as, say, variable length instructions where a few bits in a fixedE > >> location in the first byte determined the instruction format andb. > >> number and format of operands, PRECISELY. > >cC > >But doesn't variable length instructions add considerably to theb headaches of@ > >pipelines , pre-fetching and also branch prediction etc etc ? > H > See my reply to Dennis O'Connor.  Subject to the constraints I mentionC > above, it does complicate such things, but not considerably.  ButcH > please don't think that I regard the above as necessarily a good idea;C > it is an example of something that is definitely CISC and yet can  > still be done cleanly.  C The cleanest implementation I've seen of that kind of thing was thecA transputer's pfix/opr instruction sequences. Despite that elegant B solution I still hate the idea having tasted the joys of debugging% fixed-length instruction binaries. :)e   Cheers,u Rupert   ------------------------------  + Date: Thu, 11 Jul 2002 21:59:37 +0000 (UTC)oA From: "Rupert Pigott" <dark.try-eating-this.b00ng@btinternet.com>o6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)/ Message-ID: <agkv48$qv4$1@paris.btinternet.com>g  6 "Dennis O'Connor" <dmoc@primenet.com> wrote in message- news:1026417901.734555@nnrp2.phx1.gblx.net... . > "Jan-Erik Sderholm" <aaa@aaa.com> wrote ...; > > RISC vs. CICS is not only about addressing modes, not ?i >a3 > Way-back-when, "RISC-v-CISC" were more indicativec1 > of radically different ISA design philosophies:f > B > CISC: "Closing the semantic gap" between ISA and program intent,D >      which lead to tagged architectures like the i432, and the VAXB >     "evaluate polynomial" instruction, and the "5th generation";! >      a CS grad-student attitudeo >n5 > RISC: performance of compiled code is what matters,f7 >      and if feature drops the clock speed enough thati< >      overall performance drops, or if a compiler can't use; >      that feature, it probably doesn't belong in the ISA; $ >     a more commercial-EE attitude.  
 Nice summary.a  : > A lot of the early RISC work seemed inspired by the VAX:6 > people noticed that sequences of simple instructions8 > out-performed the equivalent complex instructions, andB > started to question why the hell the complex ones were in there. > 5 > These days, all competent commercial architects usec8 > the RISC philosophy, even when working on "CISC" ISAs,5 > because end-users care about price/performance, not   > all that theoretical CS stuff.  9 When I read through the various histories it seems that a-5 lot of those complex ISAs were developed because theyM9 believed that they could do the job faster in hardware...:7 Maybe they were wrong, but I can't remember any of themY* saying that they did for the fun of it. :)   20/20 is a handy thing. :)   Cheers,. Rupert   ------------------------------  % Date: Thu, 11 Jul 2002 14:25:29 -0500w/ From: "Stuart, Ed" <Ed.Stuart@austinenergy.com> , Subject: RE: 2002 Worldwide HP OpenVMS StudyT Message-ID: <92EFB80E551BD511B39500D0B7B0CDCC0642C634@ohms.electric.ci.austin.tx.us>  < Just cause it fits here... we all remember "New Coke" right?   EdE **Please apply a generous amount of all the usual disclaimers here.**e     > -----Original Message-----* > From: John Smith [mailto:a@nonymous.com]' > Sent: Thursday, July 11, 2002 3:40 AMe > To: Info-VAX@Mvb.Saic.Comp. > Subject: Re: 2002 Worldwide HP OpenVMS Study >  >  > > > "Terry C. Shannon" <terryshannon@attbi.com> wrote in message* > news:ag6X8.145261$Uu2.33296@sccrnsc03... > >t@ > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message% > > news:3D2CEE88.C8C142AA@fsi.net...m > > > "Terry C. Shannon" wrote:i > > > >i6 > > > > "John Smith" <a@nonymous.com> wrote in message > > > > C > news:u_1X8.12195$wLk.7632@news01.bloor.is.net.cable.rogers.com...)	 > > > > >vA > > > > > "Kenneth Farmer" <kfarmer@openvms.org> wrote in messagen@ > > > > > news:p2_W8.4431$Sb3.137375@twister.southeast.rr.com...; > > > > > > A Rich Marcello email sent to selected OpenVMS v > customers anouncing- > > theo > > > > > "2002nE > > > > > > Worldwide HP OpenVMS Study" and asking for participation.  > > > > > >-E > > > > > > http://www.openvms.org/stories.php?story=02/07/10/1060371m > > > > > >M	 > > > > >uE > > > > > Does this study mean that if enough customers don't plan to0 > transition > > toG > > > > > Itanic, and will be moving to IBM or Sun instead, that they'do
 > consider > > > > > reviving Alpha?>	 > > > > >"; > > > > That's a question only HPQ is properly equipped to : > answer, but I'd say. > > the.D > > > > odds are slim to none that the post-EV7 Alpha effort will be > > reinitializedn* > > > > 13 months after it was terminated. > > >h@ > > > In driver's ed. many years ago, they emphasized safety in 
 > the name ofc= > > > "defensive driving" and stated it this way: you may be m > right, but don't > > > DEAD right!o > > >>? > > > Not sure why that comes to mind just now, but let's face   > it: there are al> > > > lot of folks who are dead, out of business or whatever,  > but at least= > > > they didn't have admit a mistake and back-pdeal to get i > back on track -i? > > > they gave up and died, went bankrupt, folded the company   > or whatever,0 > > > all the time knowing they were 100% right. > > >i > >t8 > > Yep. But here's a question: having cast all the EV8  > developers into theoF > > not-so-tender embrace of L'Intella, and having lost over a year of> > > development, is there any way in which HPQ could re-start  > the effort now?l >  > < > Haven't you ever heard of the marketing phrases, "Back by  > popular demand",@ > or "Held over", or the classic "The customer is always right"? >  >    ------------------------------  # Date: Fri, 12 Jul 2002 01:32:23 GMTi* From: "Bill Todd" <billtodd@metrocast.net>, Subject: Re: 2002 Worldwide HP OpenVMS StudyA Message-ID: <HkqX8.45130$iX5.2121060@bin3.nnrp.aus1.giganews.com>u  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in messageoE news:rdeininger-1107020811450001@1cust206.tnt1.nashua.nh.da.uu.net... 7 > In article <3D2CEEA0.539CF480@videotron.ca>, JF Mezeiv' > <jfmezei.spamnot@videotron.ca> wrote:r >n > >Robert Deininger wrote:= > >> If Compaq couldn't afford to continue Alpha development,h  J It's seldom wise to start a chain of logic with an assumption as blatantly false as the one above.p    what makes youa) > >> think HP could afford to restart it?o  K But raising the issue of the likely significantly larger *restart* costs is  legitimate.   %   Have microprocessor designers takeniJ > >> a pay cut?  Is IBM charging less to fab chips?  What's the new factor thatI > >> radically changes the economics of Alpha development and production?p  H Unfortunately, you then return to your flawed base assumption.  RestrictK yourself to trying to quantify restart cost/effectiveness and you might getQ
 somewhere.   > >oG > >Since Compaq did not release audited and honest numbers to show thatp	 Alpha waseL > >really losing money, it is wrong to blindly believe the Compaq propaganda that2 > >claims they could not afford to continue Alpha. >mK > Then I guess it is also wrong to blindly assume the numbers tossed around @ > here for Alpha development and production costs are realistic.  K Incorrect.  The reason that Compaq would need to release audited numbers to J show that Alpha was losing money is because the numbers reported here wereG not grabbed out of thin air but taken from explicitly-referenced Compaqo sources.  I So the situation for the past year has been that Compaq has asserted thateJ Alpha was unprofitable but provided no evidence whatsoever to support thatK assertion or even begin to refute the fairly clear evidence to the contraryeH presented here based on analysis of quantitative information that Compaq itself provided.     If an I > alpha CPU cost several times as much as the guesses seen here, it would/K > certainly change the flavor of many of the "economic" arguments that havee > been swirling.  J And if the Moon had been made out of green cheese the foot-pads on the LEM0 would have had to have been considerably larger.  J Once again, what's been seen here are not guesses but conclusions based onI Compaq's own statements, and no quantitative evidence to the contrary hasm ever been presented.  L In an interview with Rich Marcello the day of the Alphacide the annual AlphaK development cost was quoted as $150 million.  A day later IIRC Mike WinklernL reported the cost at $300 million:  leaving aside the issue of just why MikeK (with no Alpha responsibilities whatsoever) would have been in closer touchnK with reality in this area than Rich would, it's also entirely possible thataL Mike's number erroneously (or calculatedly) included annual costs associatedJ with Alpha *server* development that were not directly associated with theL EV8 effort and hence would not be saved by eliminating EV8 development.  ForC example, EV8 leveraged the EV7 server environment, hence additional E development required to integrate EV8 into the existing - and alreadys; paid-for - EV7 server architecture would have been minimal.   A In other words, while it's certainly fair to include Alpha serverr@ architecture development costs in overall assessments of Alpha'sI profitability, in the particular case of deciding whether to continue EV8eH development those costs were pretty irrelevant, because they already hadE been committed (and even to some degree spent) for EV7.  Perhaps new,iJ expensive server architecture development would have been required for EV9D (or perhaps not:  the Marvel server promises to be a fairly wondrousC beastie, comments from the former EV8 team about its unusually high B bandwidth capacity suggest that it was designed with an eye towardD supporting EV9 as well, and it's far from clear that movement in theL direction of 'blade servers' would have been necessary or even desirable forF Alpha) - but if so *that* would seem to have been the logical point toK consider deep-sixing Alpha (especially given how far EV8 development itselfi? had progressed and how unproven its delegated replacement was).i  B Terry, who has always claimed the inside track on DECpaq activity,J consistently reported the Alpha system run rate at about 100K systems; hisK post today waffles that number to "below 100K systems per year in Y2K", buteG he neither quantified just how much 'below' that might have been nor at G exactly what point in Y2K that rate was observed:  Tru64 reported a 30% I annualized growth rate in that year and VMS a modest one (and Alpha LinuxoI was also healthy IIRC), so the total run could easily have been over 100KlJ systems even if earlier in the year the rate had been under 100K.  He alsoK (still today) reports the average CPU count per system as about 5, yielding-H approximately 500,000 CPUs per year over which to spread the development cost.d  E Even if one includes the cost of server development and uses the fullgJ Winkler number of $300 million, that's only a $600 development-cost burdenK per server-installed CPU.  If Marcello's number more closely represents thewH actual chip-development cost, it falls to $300 per CPU:  if Alpha serverI development had been wound down (as presumably it will anyway now) ratheruJ than EV8 development, this is the number that would have applied - plus it= would have left open considerably more room for reversing thec> server-development decision should that have proven desirable.  L Terry today referred to 'updated internal figures' that 'put the cost closerG to $800 per CPU' but, as is usually the case with Compaq spin, fails to2J provide one whit of evidence to back this up (and refute the other numbersJ Compaq itself made public):  that's why people start throwing around terms7 like 'audited' when demanding proof of Compaq's claims.    - bill   ------------------------------  # Date: Fri, 12 Jul 2002 02:45:51 GMTy1 From: "David J. Dachtera" <djesys.nospam@fsi.net> , Subject: Re: 2002 Worldwide HP OpenVMS Study' Message-ID: <3D2E472A.DA106AD9@fsi.net>e   "Terry C. Shannon" wrote:u > > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message# > news:3D2CEE88.C8C142AA@fsi.net...i > > "Terry C. Shannon" wrote:e > > >t4 > > > "John Smith" <a@nonymous.com> wrote in messageG > > > news:u_1X8.12195$wLk.7632@news01.bloor.is.net.cable.rogers.com...s > > > > ? > > > > "Kenneth Farmer" <kfarmer@openvms.org> wrote in message1> > > > > news:p2_W8.4431$Sb3.137375@twister.southeast.rr.com...L > > > > > A Rich Marcello email sent to selected OpenVMS customers anouncing > thei
 > > > > "2002oC > > > > > Worldwide HP OpenVMS Study" and asking for participation.r	 > > > > > C > > > > > http://www.openvms.org/stories.php?story=02/07/10/1060371o	 > > > > >u > > > >aN > > > > Does this study mean that if enough customers don't plan to transition > toN > > > > Itanic, and will be moving to IBM or Sun instead, that they'd consider > > > > reviving Alpha?  > > > >sL > > > That's a question only HPQ is properly equipped to answer, but I'd say > the,B > > > odds are slim to none that the post-EV7 Alpha effort will be > reinitialized:( > > > 13 months after it was terminated. > > I > > In driver's ed. many years ago, they emphasized safety in the name ofRK > > "defensive driving" and stated it this way: you may be right, but don'to > > DEAD right!  > >bL > > Not sure why that comes to mind just now, but let's face it: there are aH > > lot of folks who are dead, out of business or whatever, but at leastJ > > they didn't have admit a mistake and back-pdeal to get back on track -I > > they gave up and died, went bankrupt, folded the company or whatever,a. > > all the time knowing they were 100% right. > >- > I > Yep. But here's a question: having cast all the EV8 developers into thedD > not-so-tender embrace of L'Intella, and having lost over a year ofK > development, is there any way in which HPQ could re-start the effort now?T  0 Rather depends how stupidly they went about it.   G If they did the "burn the bridges thing" and didn't leave the path backsC open, then they'll have to do more learning-from-experience than iswH absolutely necessary, not mention eating a lot more crow than necessary.  G If they were smart and left the path back open, if somewhat obstructed, D then it's likely nothing a little good old fashioned hard work can'tH cure (what a concept!), not to mention a modicum of humility. (S**T, DJ!G What the F**K planet do *YOU* live on???!!! - Figured I'd say it beforep someone else did.)   -- o David J. Dachterau dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/o   ------------------------------  % Date: Thu, 11 Jul 2002 23:16:46 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>b, Subject: Re: 2002 Worldwide HP OpenVMS Study, Message-ID: <3D2E4A1B.2018E8BB@videotron.ca>   re: restarting EV8 project.a  L At this point in time,  wouldn't it be simpler/more efficient and cheaper toH simply keep the EV7 team and tell then to continue the work begun by theN dearly departed EV8 team ? (perhaps hire a few more newbie engineers but youd'& still have the core EV7 folks, right ?   ------------------------------  % Date: Thu, 11 Jul 2002 16:03:45 -0500cC From: "Craig A. Berry" <craig.berry@nospam.SignalTreeSolutions.com>lC Subject: Re: Alpha 255 UCX 4.2 slowness - A woeful tale. Any ideas?tH Message-ID: <craig.berry-FD68BA.16034511072002@news.directvinternet.com>  = In article <c5d3d5e1.0207110342.268e321e@posting.google.com>,w/  bobmarlow@postmaster.co.uk (Bob Marlow) wrote:C    5 > Network tested and is definitely 100Bt all through.-  H Even the built-in ethernet?  I think that's unusual for an Alphastation C 255 but could be wrong.  This will tell you the line speed you are j actually getting:S  , $ mcr lancp show device ewb0/characteristics   or substitute ewa0.e   > A very popular suggestion:-m >  > $ UCXu" > UCX>SET PROTOCOL TCP/NODELAY_ACK > D > But didn't help. The above reverts to default on restarts/reboots, > how can I get it to stay?n   Try   0 $ ucx set configuration protocol tcp/nodelay_ack  7 if you want it to persist after restarting the service.S  = > HP have done their best, I think. Yes, it is 'old' softwarelA > and we should upgrade blah-blah, but then thats money. If we'ret> > spending, I can get a Linux box that will do all we want for? > less than 1k. Having been a Vax fan and user since 1981, I'mL8 > reluctant to go that way, but that may be the reality.  F Obviously telling your sales rep you want to see upgrade licenses for G half the cost of a new linux box may not do you any good.  But then it cG might.  Note you can get a PWS500au from www.islandco.com for 1400 USD bG including VMS license, so upgrading systems might not necessarily mean a leaving VMS.   ------------------------------  # Date: Thu, 11 Jul 2002 22:42:57 GMT 4 From: "Andy Bustamante" <a_c_bustamante@bigfoot.com>C Subject: Re: Alpha 255 UCX 4.2 slowness - A woeful tale. Any ideas?iA Message-ID: <RRnX8.6616$Kx3.916@newsread1.prod.itd.earthlink.net>l  @ I don't know if this applies to 6.21h3, but in in later version:  ' Check network send and recieve buffers.   
 $ Anal/sys SDA> sho lan/csmacd/full  ; About 5 screens into the display you'll see something like: $ Current rcv buffers              288$ Rqst MAX rcv buffers             512$ Rqst MIN rcv buffers             256$ Curr MAX rcv buffers             512$ Curr MIN rcv buffers             256  : LANCP allows you to up buffers (SET and DEFINE as in NCP).    C You may also want to check for pool expansion, $ show mem/pool/fulls   --   Andy Bustamanteg( remove the ascii-95's to reply by e-mail      : "Bob Marlow" <bobmarlow@postmaster.co.uk> wrote in message7 news:c5d3d5e1.0207110342.268e321e@posting.google.com...b > Alphastation 2554 > Console Firmware level V6.4-1  17.01.1997 14:27:04 > 320M memory. > 2 x 2G internal disks.
 > CD, floppy.n > Built-in network card, ewa-0.n( > Added DE500 Fast Ethernet card, ewb-0./ > VMS 6.2 - 1H3, y2k applied. Also ALPLAN05-062t= > Pathworks 5.0 - 620F, y2k and w2k patch applied. Also patchi* > to get UCX to work following ECO5 patch. > UCX V4.2 - ECO Level 5.t > 5 > Network tested and is definitely 100Bt all through.  >o5 > Using Decnet, can get a 50M file to/from in 15-20s. 9 > Could do with this being faster, but having looked intoe; > data transfer in VMS itself (i.e. at $ prompt), this timee= > is probably best we'll get. (The disks we're using are slowoB > under VMS - I've looked at other Vaxes/Alphas, and its the same,I > they don't perform anything like they should. But thats another story.)r >g; > Problem is transferring data by UCX, i.e. TCP/IP, whetherm5 > by LM (Pathworks), or ftp. Times for ftp upload arer6 > typically 90s for 50M. By LM, same, and can go up to
 > 8 minutes!!x >A8 > Actually, transfer by nft (which is Decnet), is taking9 > 90s to upload a file, very similar to ftp. I have nevert< > known this before: nft was always a good fast standby when5 > Pathworks goes slow (often made worse by Windows) - 1 > here its actually slower! perhaps thats a clue?h >1+ > These times seem to then degrade in time."> > We need TCP/IP because more PCs are coming in with XP, which' > can't use Decnet properly, if at all.1 >9@ > Any ideas? I have tried almost everything in the last 2 weeks,D > and am now thinking of using old Unix box as main server, just use> > the alpha so non-unix people can see files in a vax-friendly > way (via nfs mounts).- > > > Samba also seemed to be slow, and now after various patches,? > doesn't work at all. I know there is a CMU TCP/IP, but I have:: > to have a LM (Lan Manager - mapped drives) element to it% > for PC applications. (Samba is V2).n >s >e+ > Summary of what's been tried and failed:-  >t0 > Both switch and >>>  (Firmware) set to FastFD.+ > Trying auto and HD had no effect, and nowf3 > Decnet is giving speed we want anyway, so I don'ti/ > think that's the problem, but for the record,m> > the switch is a 3com SuperStack II 3300. The port being used" > for the alpha shows zero errors. > ; > Tried different PCs and some Unix boxes. ftp time poor onn? > all of them. For some PCs, discovered the card setting should.B > be set to 100Bt Full Duplex, or it might not do that. But still,  > the problem is with the alpha. >  > $ analyse/system > SDA> sho lan/fullS >u" > nothing wrong there, apparently. > @ > In sho lan output, EWA device name appears as 'Tulip', but its< > really a DE500. Does that matter? Again , Decnet works ok,& > but UCX doesn't, so would think not. >l< > (VMS swaps EWA/EWB round from what you see at firmware >>>= > prompt, so in VMS, EWA is the new DE500 Fast network card).  >i$ > Added patch to VMS. No difference. >a > A very popular suggestion:-e >p > $ UCX " > UCX>SET PROTOCOL TCP/NODELAY_ACK > D > But didn't help. The above reverts to default on restarts/reboots,= > how can I get it to stay? Not that it really mattered here.h > 6 > (show protocol tcp /params showed this was not set). >i/ > Times only slightly better (DM3 AND Xerox) :-  >t > DM3\ftp: 55s/21s > XeroxD\ftp:50s/24s >n( > Did UCX$SHUTDOWN and then UCX$STARTUP,  > also set PWRKS to TCP/IP only. >  > Times no better. > # > Set switch to HD, FC off on both.a > No change, so put back.  >t > Added SCSI terminator. > 
 > In VMS:- >e* > $ set rms /network=127 /system  (was 8). >k > = > HP have done their best, I think. Yes, it is 'old' softwareeA > and we should upgrade blah-blah, but then thats money. If we're0> > spending, I can get a Linux box that will do all we want for? > less than 1k. Having been a Vax fan and user since 1981, I'mc8 > reluctant to go that way, but that may be the reality. >n   ------------------------------    Date: 11 Jul 2002 16:57:45 -0700( From: bob@instantwhip.com (Bob Ceculski)C Subject: Re: Alpha 255 UCX 4.2 slowness - A woeful tale. Any ideas?t= Message-ID: <d7791aa1.0207111557.28720a36@posting.google.com>-  r bobmarlow@postmaster.co.uk (Bob Marlow) wrote in message news:<c5d3d5e1.0207110342.268e321e@posting.google.com>... > Alphastation 2554 > Console Firmware level V6.4-1  17.01.1997 14:27:04 > 320M memory. > 2 x 2G internal disks.
 > CD, floppy.g > Built-in network card, ewa-0.g( > Added DE500 Fast Ethernet card, ewb-0./ > VMS 6.2 - 1H3, y2k applied. Also ALPLAN05-062D= > Pathworks 5.0 - 620F, y2k and w2k patch applied. Also patchd* > to get UCX to work following ECO5 patch. > UCX V4.2 - ECO Level 5.d > 5 > Network tested and is definitely 100Bt all through.i >  > + > Summary of what's been tried and failed:-a > 0 > Both switch and >>>  (Firmware) set to FastFD.+ > Trying auto and HD had no effect, and now 3 > Decnet is giving speed we want anyway, so I don'tg/ > think that's the problem, but for the record,c> > the switch is a 3com SuperStack II 3300. The port being used" > for the alpha shows zero errors. >   G sounds like a NIC problem ... to run fastfd, you have to use a DE500-BAcB and make some adjustments to the switch, like no spanning tree ...D I don't even know if your version of vms/ucx supports a DE500-BA ...@ I would run at the twisted-pair or fast level on the console ...F there are known problems running earlier de500's (AA/XA) with switchesH at fastfd ... I have run 7.1 on alphastation 200/250/500 with DE500-BA'sG and bay networks switches fastfd with no problems ... definitely do noti- use autoconfigure as this causes problems ...o   ------------------------------  % Date: Thu, 11 Jul 2002 23:41:05 +0100i) From: Witchy <news@sruasonidyranib.co.uk>u. Subject: Re: Alpha Shadowing Phase II question8 Message-ID: <652siugknd6j7un274cs3vig3sctefrulj@4ax.com>  @ On 11 Jul 02 01:06:07 +0200, p_sture@elias.decus.ch (Paul Sture) wrote:  e >In article <m0cpiuojtmejp56mvr7o51qci09m0mef4g@4ax.com>, Witchy <news@sruasonidyranib.co.uk> writes: ; >> On 9 Jul 02 13:15:32 PST, mckinneyj@cpva.saic.com wrote:h >> s/ >>>In article <3D2B4283.265BC8A1@videotron.ca>,e3 >>> JF Mezei <jfmezei.spamnot@videotron.ca> writes:l   <snip>   Hi Paul,  B I've been away from this ng for a couple of years owing to my lastE company moving away from the platform; it's great to be back here and D see some names I recognise from back then, and even the VMS forum on
 Compuserve :)   * >Good tip - that destroys the SCB as well. > L >OTOH, if you are running V7.3, have a  HELP INIT/SHADOW says the following: >e >INITIALIZEs >e
 >  /SHADOW > D >        /SHADOW=(device_name_1, device_name_2, device_name_3) label >n   <snip>  A >     Additional information can be found in Volume Shadowing for  >     OpenVMS.  F I must be slipping; I've been all over the Shadowing docs and I didn'tE see that. Surely though a full copy must be performed anyway? Setting$A up the volume headers is one thing but the data's still got to bep> copied over......then again it's late and I'm probably missing
 something....i   cheers   ------------------------------  % Date: Thu, 11 Jul 2002 19:54:36 -0400u- From: JF Mezei <jfmezei.spamnot@videotron.ca>o. Subject: Re: Alpha Shadowing Phase II question, Message-ID: <3D2E1A9A.B2215733@videotron.ca>  
 Witchy wrote:n
 > >INITIALIZEe > >a > >  /SHADOW > >tF > >        /SHADOW=(device_name_1, device_name_2, device_name_3) label  @ > see that. Surely though a full copy must be performed anyway?   I *speculation* Perhaps what this does is simply setup the few prerequisiteoL files in [000000] on all 3 drives at the same time, and with the rest markedM "unused" it doesn't bother copying the "random" data on the unused portion ofc the drive ?d  J This way, when you copy data to the new "empty" shadowset, perhaps it onlyL needs to write the new data to all drives without having to first compare to see if it needs to be written ?   $ This is just speculation on my part.   ------------------------------    Date: 11 Jul 2002 17:03:06 -0700( From: bob@instantwhip.com (Bob Ceculski) Subject: Andrew the hypocrite!= Message-ID: <d7791aa1.0207111603.2b70fdc5@posting.google.com>s   > > H > > FWIW, Solaris is more or less "UN*X vanilla" here: at, atq, crontab,5 > > etc., but no batch queues as VMS folks know them.e > >  >  > D > But there is a wealth of 3rd party batch queue products, Control-M
 > etc etc. > 	 > Regardss > Andrew Harrisonp  ; from one of your prior posts Andrew about VMS IP stacks ...e  C Nice try but not the point. Who gives a rats arse if Multinet isn'tsD vunerable. Now days no customer expects to have to buy an additionalA layered 3rd party product to get IP support in an OS and very fewdC customers would be impressed with the idea that you need to do this * because the vendors own product is broken.   Regardsh   Andrew Harrisonx  * now I can slightly modify this to read ...  D Nice try but not the point. Who gives a rats arse if you can buy 3rdH party batch queues. Now days no customer expects to have to buy an add'lC layered 3rd party product to get batch queues in an OS and very fewhC customers would be impressed with the idea that you need to do thisg* because the vendors own product is broken.   chew on your own words matey!y   ------------------------------  % Date: Thu, 11 Jul 2002 20:15:37 +0200e2 From: martin@radiogaga.harz.de (Martin Vorlaender)0 Subject: Re: C and X11 programming, finding info; Message-ID: <3d2dcb49.524144494f47414741@radiogaga.harz.de>s  3 Martin Vorlaender (martin@radiogaga.harz.de) wrote:o0 > JF Mezei (jfmezei.spamnot@videotron.ca) wrote:3 > > (same with FONT/DIR which doesn't exist on VAX)i >iM > Same here. There is a FONTCOMPILER command, however. But no /DIR qualifier.e  H Also on Alpha V7.2-1. But there's SYS$SYSTEM:DECW$MKFONTDIR.EXE (also on	 VAX 6.2):v   $ mkfontdir := $decw$mkfontdir, $ mkfontdir sys$common:[sysfont.decw.common] 44 fonts loadedt@ Creating sys$common:[sysfont.decw.common]DECW$FONT_DIRECTORY.DAT $    cu,    Martin -- oH    Emacs would be a great   | Martin Vorlaender  |  VMS & WNT programmer5    operating system,        | work: mv@pdv-systeme.deaL    if only it came with     |       http://www.pdv-systeme.de/users/martinv/<    a decent editor...       | home: martin@radiogaga.harz.de   ------------------------------  % Date: Thu, 11 Jul 2002 14:51:01 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>d0 Subject: Re: C and X11 programming, finding info, Message-ID: <3D2DD387.88ADD037@videotron.ca>   Martin Vorlaender wrote:" > $ sho logical /table=* decw$font@ >    "DECW$FONT" = "DECW$SYSCOMMON:[SYSFONT.DECW.USER_CURSOR32]" >  (DECW$SERVER0_TABLE)m  K OK, I have it too, but without the TABLE=* the logical is not visible. Thisb" means that "dir DECW$FONTS" fails.   ------------------------------  % Date: Thu, 11 Jul 2002 15:10:57 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>a0 Subject: Re: C and X11 programming, finding info* Message-ID: <3D2DD832.31A5FE@videotron.ca>   Martin Vorlaender wrote:. > $ mkfontdir sys$common:[sysfont.decw.common]  L Thanks. I had seen that utility, but didn't know what incantation would make) it work (eg: which directory to specify).    ------------------------------  % Date: Fri, 12 Jul 2002 04:27:34 +0200 2 From: martin@radiogaga.harz.de (Martin Vorlaender)0 Subject: Re: C and X11 programming, finding info; Message-ID: <3d2e3e96.524144494f47414741@radiogaga.harz.de>r  . JF Mezei (jfmezei.spamnot@videotron.ca) wrote: > Martin Vorlaender wrote:0 > > $ mkfontdir sys$common:[sysfont.decw.common] > I > Thanks. I had seen that utility, but didn't know what incantation woulds0 > make it work (eg: which directory to specify).  E I must admit that I looked into a Linux system for that (after making B sure there was no VERB for it). And afterwards I applied the usual4 amount of mental translation for *ix X11 manuals ;-)   <QUOTE>oA MKFONTDIR(1)                                         MKFONTDIR(1)t   NAMEA        mkfontdir,  fonts.dir,  fonts.scale,  fonts.alias,  encod-,@        ings.dir - create an index of X font files in a directory   SYNOPSISA        mkfontdir [-x suffix] [-r] [-p prefix] [-e encoding-direc-c1        tory-name] ...  [--] [directory-name ... ]e   DESCRIPTIONIA        For  each  directory  argument, mkfontdir reads all of the A        font files in the directory searching for properties namedhA        "FONT", or (failing that) the name of the file stripped ofeA        its suffix.  These are converted to lower case and used asoA        font names, and, along with the name of the font file, areoA        written out to the file "fonts.dir" in the directory.  TheaA        X  server  and  font  server  use "fonts.dir" to find font 
        files.a  A        The kinds of font files read by mkfontdir depend  on  con-oA        figuration  parameters,  but typically include PCF (suffixtA        ".pcf"), SNF (suffix ".snf") and BDF (suffix ".bdf").   IfdA        a  font  exists  in multiple formats, mkfontdir will firsty,        choose PCF, then SNF and finally BDF.  A        The first line of fonts.dir gives the number of  fonts  in-A        the  file.  The remaining lines list the fonts themselves,eA        one per line, in two fields.  First is  the  name  of  theu?        font file, followed by a space and the name of the font.g   SCALABLE FONTS        [...]   FONT NAME ALIASES A        The  file "fonts.alias", which can be put in any directoryaA        of the font-path, is used to map  new  names  to  existing A        fonts,  and  should  be edited by hand.  The format is twoaA        white-space  separated  columns,  the   first   containing A        aliases  and  the  second  containing  font-name patterns.iA        Lines  beginning  with  "!"  are  comment  lines  and  areX        ignored.   A        If  neither  the  alias  nor  the value specifies the size0A        fields of the font name, this is a scalable alias.  A fonteA        name of any size that matches this alias will be mapped to)<        the same size of the font that the alias resolves to.  A        When a font alias is  used,  the  name  it  references  isAA        searched  for  in  the normal manner, looking through eachsA        font directory in turn.  This means that the aliases  needcA        not mention fonts in the same directory as the alias file.o  A        To embed white space in either name, simply enclose it  innA        double-quote  marks;  to  embed double-quote marks (or anya6        other character), precede them with back-slash:  @        "magic-alias with spaces"     "\"font name\" with quotes"%        regular-alias            fixedr  A        If the string "FILE_NAMES_ALIASES" stands alone on a line,lA        each  file-name  in the directory (stripped of its suffix)i.        will be used as an alias for that font.   ENCODING FILESA        The option -e can be used  to  specify  a  directory  withu        encoding  files. [...]b   OPTIONSl+        The following options are supported:c;        [...I don't think any of those are supported on VMS.n:            And no, "-r" wouldn't mean "recursive" here...]   FILESi        [...]   SEE ALSO(        X(7), Xserver(1), xfs(1), xset(1)  A X Version 11               Release 6.5               MKFONTDIR(1)- </QUOTE>   cu,e   Martin -- 0B                         | Martin Vorlaender | VMS & WNT programmer1  OpenVMS: Where do you  | work: mv@pdv-systeme.defD  want to BE today?      |   http://www.pdv-systeme.de/users/martinv/8                         | home: martin@radiogaga.harz.de   ------------------------------    Date: 11 Jul 2002 15:11:31 -0700- From: zroundtree@oasys.com (Zoltan Roundtree)b Subject: CMS= Message-ID: <bf1b7500.0207111411.55bc0d68@posting.google.com>r  > I am attempting to create a menu (via DCL) that would allow an= operator to execute CMS commands (ie. replace/variant, fetch,5= reserv/merg, etc...). My main concern is how to implement the @ reserve/merge command. Does anyone have any suggestions on how I should6 begin? Or, is there a skeleton command file available?   ------------------------------    Date: 11 Jul 2002 14:21:48 -0700- From: contracer11@uol.com.br (Shiva MahaDeva) 6 Subject: Command Procedure to logoff inactive users...= Message-ID: <ddf392ea.0207111321.45d8392b@posting.google.com>9  F Is there any way to make a Command Procedure to logoff inactive users?   ------------------------------  % Date: Thu, 11 Jul 2002 17:47:59 -0400M- From: JF Mezei <jfmezei.spamnot@videotron.ca> : Subject: Re: Command Procedure to logoff inactive users..., Message-ID: <3D2DFCF6.90D43C38@videotron.ca>   Shiva MahaDeva wrote:t > H > Is there any way to make a Command Procedure to logoff inactive users?  H There would be, but it wouldn't be pretty. You need to keep an artray ofL CPU/IO numbers for each process and compare it to see it it has moved in the last XX minutes.  G There are some idle process killers available either commercially, or IeN believe on the freeware CD. They are more powerful than what you could do in aJ command procedure and will "spare" certain processes that are judged OK to live without activity.   ------------------------------  % Date: Thu, 11 Jul 2002 23:50:07 +0200a9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>!: Subject: Re: Command Procedure to logoff inactive users...' Message-ID: <3D2DFD8F.946B3A23@aaa.com>r  % Possible, but download WATCHER from :r  ) http://www.process.com/openvms/index.html < http://vms.process.com/scripts/fileserv/fileserv.com?WATCHER   instead.  > It's a impressing tool to "just" logoff interactive processes. Have used it for years...C   Jan-Erik Sderholm.    Shiva MahaDeva wrote:h > H > Is there any way to make a Command Procedure to logoff inactive users?   ------------------------------  % Date: Thu, 11 Jul 2002 08:56:28 -0400  From: norm.raphael@metso.com% Subject: Re: Convert conundrum. Help?f? Message-ID: <OFFF5B7795.2C3E4BB8-ON85256BF3.0045EB61@metso.com>o  4 Thanks.  The explanation below makes complete sense:> Sort Warns that it encountered a Fatal in a system service andG handled it, so Convert is Successful, if not in the most efficient way.a            9 Alan Greig <a.greig@virgin.net> on 07/11/2002 05:48:30 AMe  1 Please respond to Alan Greig <a.greig@virgin.net>s   To:    Info-VAX@Mvb.Saic.Com cc:e( Subject:    Re: Convert conundrum. Help?    , On Wed, 10 Jul 2002 18:46:53 -0400, JF Mezei% <jfmezei.spamnot@videotron.ca> wrote:i   >norm.raphael@metso.com wrote:I >> 1)  I always puzzle over a "-W-" error generated by a "-F-" error in aC
 >> subsystem. J >> If LIB is fatal, how can SORT be only a warning (something died, but if youg >> leave; >> the area quickly enough, maybe you won't be dead, too?))t >, >How about " >sG >Hi ! My name is SORT, I tried to get more memory to make the sort morehD >efficient, but I couldn't, so I reverted to another, less efficient method,a >which requires less memory" >5 >oro >tE >Hi ! My name is CONVERT, my friend SORT told me a few times that LIB  couldn'tK >give him more memory, so I decided to give up on SORT and proceed with the J >CONVERT as if it were a /NOSORT. The output file may be "correct", but it mayeF >not be the most efficient since records may have been inserted out of order. >D >Y. >(The above two message are mere speculation).  , Certainly for answer 1 it is not speculation   Search Result 1t1 From: hein@eps.zko.dec.c*m (hein@eps.zko.dec.c*m)p0 Subject: RE: Insufficient virtual memory on SORT Newsgroups: comp.os.vmsN5 View: Complete Thread (11 articles) | Original Format2 Date: 2000/03/24    
 In articleF <F02D5A46B8AED311BE4F0090279FA2401E82F5@ppnt41.physics.ox.ac.uk>, John7 Macallister <J.Macallister1@physics.ox.ac.uk> writes...s( >>%SORT-W-SYSERROR, system service error/ >>-LIB-F-INSVIRMEM, insufficient virtual memoryyJ >The second line indicates that the problem was fatal and so the operation >hasn't completed.  F Noop. The second line indicates the underlying error sort captured and handled.B The file will be useable, but obviously you'd want to work towards	 resolvinga that underlying problem.D Some of the quotas do not match with the actual available resources.         -- Alan   ------------------------------    Date: 11 Jul 2002 12:55:38 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)s: Subject: Re: DECdoc -> PDF (Was: Looking for your opinion)3 Message-ID: <qhRkzra195ui@eisner.encompasserve.org>@  c In article <3D2DA9D8.A10716FA@aaa.com>, Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> writes:.G > You can use either Adobe Acrobat Destiller on a PC, or (as I'm doing)4: > set up Ghostscript on the VMS box to run the conversion.  < You can also use the Adobe Acrobat Distiller on a Macintosh, which is what I do :-)  A > I run with one command (COM file) directly from the SDML source B > to a PDF document placed on a directory served by SAMBA to my PC# > where I (proof-)read to PDF file.  >  > Jan-Erik Sderholm.e >  > Larry Kilgallen wrote:K >> Postscript to PDF is easiest -- you do it already for VMS Documentation,>K >> don't you ?  (I have not seen a version of DEC Document that outputs PDF 0 >> directly, and yet it shows up on the CDROMs.)   ------------------------------  % Date: Thu, 11 Jul 2002 14:32:04 -0400S- From: JF Mezei <jfmezei.spamnot@videotron.ca>h: Subject: Re: DECdoc -> PDF (Was: Looking for your opinion), Message-ID: <3D2DCF17.C94A76F4@videotron.ca>   Jan-Erik Sderholm wrote:oG > You can use either Adobe Acrobat Destiller on a PC, or (as I'm doing) : > set up Ghostscript on the VMS box to run the conversion.A > I run with one command (COM file) directly from the SDML sourcerB > to a PDF document placed on a directory served by SAMBA to my PC# > where I (proof-)read to PDF file.t  G Does Document generate the postscript commands that permit Distiller toe" generate PDFs with bookmarks etc ?  M PDF can be just as powerful as Bookreader when the source postscript contains2H the right commands inside (which are defined to be "null" when sent to a/ postscript printer, but executed by distiller).6  L But if Document doesn't generate the stuff for bookmarks and links, then theE PDF output is very weak in terms of usability compared to bookreader.v   ------------------------------  # Date: Thu, 11 Jul 2002 19:49:34 GMT * From: Paul Anderson <paul.anderson@hp.com>: Subject: Re: DECdoc -> PDF (Was: Looking for your opinion)5 Message-ID: <110720021543191202%paul.anderson@hp.com>a  5 In article <3D2DCF17.C94A76F4@videotron.ca>, JF Mezeih% <jfmezei.spamnot@videotron.ca> wrote:   F > Does Document generate the postscript commands that permit Distiller' > to generate PDFs with bookmarks etc ?t  E Unfortunately, no.  As you pointed out, this limits the usefulness ofy3 PDFs generated from DECdocument-created PostScript.3  C In article <qhRkzra195ui@eisner.encompasserve.org>, Larry Kilgallen  <Kilgallen@SpamCop.net> wrote:  > > You can also use the Adobe Acrobat Distiller on a Macintosh, > which is what I do :-)  ; Here, too.  All DCPS PDF documentation is created on a Mac.    Paul   -- g  Paul Anderson   OpenVMS Engineering    Hewlett-Packard Companye   ------------------------------  % Date: Thu, 11 Jul 2002 21:44:10 +0200d9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>e: Subject: Re: DECdoc -> PDF (Was: Looking for your opinion)' Message-ID: <3D2DE00A.CBB068F6@aaa.com>-  ; I woudn't think so, since there is no "support" for (later)M5 generation of PDF files. But, since DECdoc is heavilya: configurable, maybe it's possible to add them, don't know.  	 Jan-Erik.>   JF Mezei wrote: I > Does Document generate the postscript commands that permit Distiller to,$ > generate PDFs with bookmarks etc ?   ------------------------------  % Date: Thu, 11 Jul 2002 19:01:46 -0400u- From: JF Mezei <jfmezei.spamnot@videotron.ca>t$ Subject: Depressing world of mergers, Message-ID: <3D2E0E3C.AD9A89D5@videotron.ca>   ok, this is somewhat OT...  = http://biz.yahoo.com/rc/020711/financial_mergers_humor_1.html   / Depressing world of M&A has become a real laugh  By Jeffrey Goldfarb,  M NEW YORK, July 11 (Reuters) - The state of corporate mergers and acquisitionss is so bad it's a joke. e  M Although the hard times that have befallen Wall Street are no laughing matter-L to the thousands of investment bankers without jobs or clients, punsters andG humorists have offered up an array of wacky deals to lighten the mood. 1  L  The famed Sunday New York Times Magazine crossword puzzle recently wonderedI what 16-letter product DaimlerChrysler AG's   Chrysler arm and Krazy GluefC would make if they joined forces.  "Convertible bonds" apparently. b  K  And the result of a union between mattress giant Serta with luxury luggage & maker Louis Vuitton ?  Sleeping bags.   I  And photocopy machine manufacturer Canon and instrument seller WurlitzerfI together would make "reproductive organs,"  according to 50-across in the   puzzle entitled "Merger Mania."   !  But the fun doesn't stop there. r  N  Counterculture magazine Mother Jones printed a series of colorful cartoons byF David Fullarton in its May/June issue that suggested Pfizer Inc.   andL McDonald's Corp.  merge and serve up a "happy meal" of McProzac burgers, andM that Microsoft Corp. and Gap Inc.  team up to "produce a line of T-shirts andr9 jeans that are incompatible with other clothing brands."    N Elizabeth Gorski, who constructed the merger crossword for the Times, said theE idea stemmed from a "government takeovers" puzzle she sold to anothereM newspaper. In that one, a Department of Defense usurpation of Rogaine yielded  "hairy arms."   N "I think as we're all suffering and seeing our portfolios shrink, you might asL well make fun of it," Gorski said. "I think puzzles have always poked fun atN various area of society, and business is always a good place because it has so much pun potential." o  K Old e-mail witticisms of unknown origin have begun to resurface, with punnyiH suggestions that 3M Co.   and Goodyear Tire & Rubber Co.  merge and callM themselves "mmmGood"; Netscape and Yahoo! Inc.  unite as "Net-'n'-Yahoo"; and I package specialists FedEx Corp.   and United Parcel Service Inc.  join asy	 "FedUp." c  K Mimi Sheraton, in a column in the New York Times, while mocking the strangeRM fusion trends in food, suggested two weeks ago that Prada and Ronzoni combinerC to make all-black pasta in fashionable shapes like navels and abs.    H Sheraton also comically opined that bankrupt energy trader Enron Corp.  I re-emerge in the world of frozen meals, where it could sell "gourmet diethJ foods with labels that under-report calories and overestimate nutrients."    NO M&A? TRY MOWING THE LAWN   M While many lament that humorists have more deals on their minds than bankers,-< some in the business have found plenty of reasons to smile.   J "It's not such a bad thing to see your wife and kids on the weekend and toL have that annoying list of things that never get done actually get shorter,"M said George Sard, whose public relations firm Citigate Sard Verbinnen advisesN' companies on mergers and acquisitions. -  M Plus, dealmakers have had some fun of their own, proving they have a sense ofe( humor to go with their business smarts.   M Merger mavens were giddy over last year's peanut butter-and-jelly sandwich --eJ when Procter & Gamble's   Jif merged with J.M. Smucker Co.   that garneredF "Deal of the Year" award from market research firm Thomson Financial.   N So could it be that merger strategists see real possibilities in the seemingly comedic suggestions? 0  I "That would not only surprise me," said Will Shortz, the Times' crossword1E editor, "but it would scare me if bankers got ideas from the puzzle."d   ------------------------------  % Date: Thu, 11 Jul 2002 20:59:30 +0200n From: "Zile" <zile@vip.hr>) Subject: DLT Tape BarCode label generator * Message-ID: <agkk45$farb$1@as201.hinet.hr>   It generates labels for:3 - Breece Hill Tape Library (5 chars + checksum) and. - Compaq Tape Library (6 chars)t  # Download:  http://www.cursor-ri.com    CURSOR Ltd.s Fax: +385-51- 623-115f" Support e-mail: info@cursor-ri.com   ------------------------------  % Date: Thu, 11 Jul 2002 14:41:57 -0400 - From: Jonathan Boswell <jsb@ost.cdrh.fda.gov>1$ Subject: Re: Doing the Math on Alpha0 Message-ID: <3D2DD175.C73758A4@ost.cdrh.fda.gov>   "Terry C. Shannon" wrote:X > About all we can gooL > on are the confirmations from multiple internal CPQ sources that the AlphaL > system run rate was below 100K systems per year in Y2K. And that "5" was aJ > reasonable average per-system CPU count. And that the annual cost of the: > care and feeding of the Alpha effort exceeded $250M USD.  N OK, if we divide $250M by 500K we get $500/Alpha cpu.  What am I missing here?   ------------------------------  # Date: Thu, 11 Jul 2002 19:30:34 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>w$ Subject: Re: Doing the Math on Alpha. Message-ID: <u1lX8.484846$cQ3.41339@sccrnsc01>  : "Jonathan Boswell" <jsb@ost.cdrh.fda.gov> wrote in message* news:3D2DD175.C73758A4@ost.cdrh.fda.gov... > "Terry C. Shannon" wrote:f > > About all we can gouH > > on are the confirmations from multiple internal CPQ sources that the AlphafL > > system run rate was below 100K systems per year in Y2K. And that "5" was aiL > > reasonable average per-system CPU count. And that the annual cost of the< > > care and feeding of the Alpha effort exceeded $250M USD. >eJ > OK, if we divide $250M by 500K we get $500/Alpha cpu.  What am I missing here?F  K Not much... other than updated internal figures put the cost closer to $800e per CPU.  K That is, of course, if you take data points gathered from CPQ execs anotheroD sources at face value. Some of our resident experts claim that AlphaL remained intensely profitable and that it was killed by a Conspiracy Theory.I However, none of the Conspiracy Theorists can back up their rantings. But A hey, when have they let the facts get in the way of a good story?i   ------------------------------  % Date: Thu, 11 Jul 2002 16:51:28 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>I$ Subject: Re: Doing the Math on Alpha, Message-ID: <3D2DEFBA.74DCF7B7@videotron.ca>   "Terry C. Shannon" wrote:iM > Not much... other than updated internal figures put the cost closer to $800)
 > per CPU.  A Isn't that still significantly cheaper than the cost of IA64 ????o   ------------------------------    Date: 11 Jul 2002 14:14:40 -0700( From: bob@instantwhip.com (Bob Ceculski)$ Subject: Re: Doing the Math on Alpha= Message-ID: <d7791aa1.0207111314.25b2b15f@posting.google.com>i  e "Terry C. Shannon" <terryshannon@attbi.com> wrote in message news:<%pfX8.24155$Jp.52164@rwcrnsc53>... A > "Robert Deininger" <rdeininger@mindspring.com> wrote in message G > news:rdeininger-1107020811450001@1cust206.tnt1.nashua.nh.da.uu.net...a9 > > In article <3D2CEEA0.539CF480@videotron.ca>, JF Mezei ) > > <jfmezei.spamnot@videotron.ca> wrote:  > >h > > >Robert Deininger wrote:N > > >> If Compaq couldn't afford to continue Alpha development, what makes youJ > > >> think HP could afford to restart it?  Have microprocessor designers >  takenL > > >> a pay cut?  Is IBM charging less to fab chips?  What's the new factor >  that.K > > >> radically changes the economics of Alpha development and production?d > > >iI > > >Since Compaq did not release audited and honest numbers to show thata >  Alpha wasN > > >really losing money, it is wrong to blindly believe the Compaq propaganda >  that 4 > > >claims they could not afford to continue Alpha. > >DM > > Then I guess it is also wrong to blindly assume the numbers tossed aroundaI > > here for Alpha development and production costs are realistic.  If aneK > > alpha CPU cost several times as much as the guesses seen here, it would M > > certainly change the flavor of many of the "economic" arguments that have- > > been swirling. > " > Re: "Audited and Honest Numbers" > M > For whose sake? Is there any evidence of widespread demand for such numbersbM > outside of c.o.v? Are large customers demanding this information? I've seenoG > no evidence of this, have you? Did Ford Motor Company release auditedhM > numbers to show how much it lost on the Edsel? Did Mazda release numbers tog4 > prove that its Wankel-Inside RX-7 was a money pit? > K > Only HPQ knows the numbers for sure. IMHO it would be a complete waste of-N > shareholder dollars to produce audited numbers to show that Alpha was losingM > money (if in fact it was, which is far from certain). The undertaking mightsL > also expose information that HPQ would rather not "share," e.g. run rates,M > transfer costs, etc. This information would only benefit HPQ's competitors.-L > It probably would not stop the whining and whinging in this forum, though,< > as it appears downright impossible to satisfy some people. > L > What seems to be evident is that Alpha sales were not growing. We all know  A well, that is to be expected when you stop marketing VMS, you letf? development lag, you tell everyone to go to NT, then drop Alphau) support for NT ... not rocket science ...f   ------------------------------  # Date: Fri, 12 Jul 2002 02:29:52 GMTu* From: "Bill Todd" <billtodd@metrocast.net>$ Subject: Re: Doing the Math on AlphaA Message-ID: <zarX8.50379$Bt1.2788420@bin5.nnrp.aus1.giganews.com>u  < "Terry C. Shannon" <terryshannon@attbi.com> wrote in message( news:u1lX8.484846$cQ3.41339@sccrnsc01...   ...   / > Some of our resident experts claim that Alpha  > remained intensely profitabler  F And have backed these claims fairly solidly with Compaq's own figures.  0 > and that it was killed by a Conspiracy Theory.  , I lean toward an Incompetence Theory myself.  G > However, none of the Conspiracy Theorists can back up their rantings.p  L Ah, but evidence of incompetence (and accompanying incompetent mendacity) isH far easier to come by:  so many visible and demonstrable gaffes and lies have occurred.   - bill   ------------------------------  # Date: Fri, 12 Jul 2002 02:25:48 GMTu* From: "Bill Todd" <billtodd@metrocast.net>$ Subject: Re: Doing the Math on AlphaA Message-ID: <M6rX8.151887$vq.7868696@bin6.nnrp.aus1.giganews.com>C  < "Terry C. Shannon" <terryshannon@attbi.com> wrote in message& news:%pfX8.24155$Jp.52164@rwcrnsc53... >eA > "Robert Deininger" <rdeininger@mindspring.com> wrote in messagerG > news:rdeininger-1107020811450001@1cust206.tnt1.nashua.nh.da.uu.net... 9 > > In article <3D2CEEA0.539CF480@videotron.ca>, JF Mezei<) > > <jfmezei.spamnot@videotron.ca> wrote:A   ...l  I > > >Since Compaq did not release audited and honest numbers to show thatC > Alpha wasjC > > >really losing money, it is wrong to blindly believe the Compaq3
 propaganda > that4 > > >claims they could not afford to continue Alpha.   ...o   >t" > Re: "Audited and Honest Numbers" > E > For whose sake? Is there any evidence of widespread demand for sucht numbersaC > outside of c.o.v? Are large customers demanding this information?t  L Did anyone claim there was?  AFAICT, this discussion, and the context of theJ comment, is going on right here, nowhere else, and you're simply trying to drag a red herring across it.r   ...   8 > This information would only benefit HPQ's competitors.  K Guess Compaq shouldn't have put themselves in a situation where the absencem: of the information is of some embarrassment to them, then.  L > It probably would not stop the whining and whinging in this forum, though,< > as it appears downright impossible to satisfy some people.  G Why do you say that?  What even modest steps has Compaq made to satisfy I *any* of the reservations people here have expressed?  Given the level oftH appreciation accorded to even *token* gestures of interest in VMS by itsG owner, I suspect that *any significant* expression of commitment by its F owner to VMS or even to simply honest discussion would be greeted with rousing cheers.    >aL > What seems to be evident is that Alpha sales were not growing. We all knowJ > why. Digital, and then Compaq, engaged in NonStop Marketing Malfeasance. TheyJ > annual cost of maintaining the Alpha effort can, to a certain extent, beI > sanity checked by perusing CPQ's financials and aggregating data points'K > obtained from public domain sources and elsewhere (headcount in practicestK > including microprocessor development, compilers, systems engineering, etckJ > groups; industry estimates on competitive processor development efforts,@ > fabrication costs, etc). The annual Alpha run rate can also be
 approximated.-J > Divide the cost of the Alpha effort by the CPU run rate and you've got a# > rough idea of the per-CPU burden.o  F Exactly.  Which is why the $800/CPU annual development-cost burden youK report as being thrown around internally is patently absurd.  BTW, I forgotoA to include in the post I just completed the projected developmentrL expenditures for *all* in-process products acquired with DEC reported in theK 1999 and 2000 Compaq Annual Reports:  it ran about $500 million annually iniG total, and one of them elsewhere contained the information that storage(L development was the largest single contributor, so even if you consider chipK development and server development to be two separate entries (each smalleraK than storage, and with no other significant contributions from other areas)i? you can't exceed about $300 million annually for both combined.   $  (The icing on the cake would be theK > per-CPU cost of fabbing in the Samsung and IBM foundries, but neither IBM-? > Semiconductor nor Samsung seem willing to "share" this data.)0 > B > Mix in ancillary data, such as the lateness of EV6 and Wildfire.  E That's really not relevant to the balance of annual development costsdI against annual run rates:  it can have indirect influences on the latter,tJ but since EV6 is history (and the numbers we're working with all post-dateD its release) and Wildfire was a server group, not a processor group,@ screw-up it's not clear either shed a great deal of light on the
 conversation.o    Don'tE > forget to toss in projections of competitive processor performance,r > especially POWER and IA64.  K Indeed.  And the projections for Itanic last year, when the decisions underBG discussion were made public, were abysmal.  Intel was claiming McKinley K would achieve 1.5x - 1.7x the performance of Merced, which *at best* put ittH at about 650 SPECint2K.  Anticipated clock rates had fallen from whisper6 numbers of 1.4 - 1.5 GHz, through 1.2 GHz, to 1.0 GHz.  *  All of a sudden the long-term Alpha value, > proposition becomes somewhat questionable,  H Bullshit.  Stringing together a series of mendacious insinuations which,L when combined, paint a 'questionable' picture is not an argument:  it's pure propaganda.d  !  especially for a firm that's not7L > flush with money. Had CPQ had big bags of money with which they could haveI > mounted a crash program to aggressively market Alpha and to pay ISVs too portE > and maintain their apps on Alpha platforms, perhaps things would bet > different.  J Again, bullshit.  Given how tenacious Alpha was at hanging onto its marketI *despite* the abject neglect of its owner, any even modest expenditure oflI effort would have been greeted with an upsurge of sales, generating money I for further efforts.  The *only* thing keeping Alpha from a rising marketaK acceptance (and the feedback effect this has on increasing ISV support) wasr
 its owner.  >  Perhaps the cumulative impact of a decade of ineptitude could8 > have been mitigated, but at what cost and to what end?  L The cost?  Zero:  it would have been offset and then some by simply avoidingL the adverse sales impact of announcing the demise of the platform.  The end?* Profitability.  Any other silly questions?     The fact of the.K > matter is that CPQ did not have the aforementioned gunnysacks full of the, > coin of the realm.  I All the more reason to start taking the very modest steps that would haveaL caused it to acquire some - the steps that, had they been taken 3 years ago,, would have caused it already to *have* some.  8  Furthermore, "shoulda, coulda, woulda" speculation does7 > nada to change the decisions the firm made last year.0  J As long as the same incompetents are in charge, their incompetence remains	 an issue.1   - bill   ------------------------------  % Date: Thu, 11 Jul 2002 14:22:28 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>e Subject: Re: DS10 shutting downe, Message-ID: <3D2DCCD8.45A56EA6@videotron.ca>   Kevin Handy wrote:5 > Would a memory problem cause the power to turn off?t  N Did you ever say anything to make Hoff or Fred mad at you ? Perhaps they wouldC have added some interesting logic in VMS to purposefully cause thisoN undocumented problem to happen specifically and only to you and give you a big headache.... :-) :-) :-)  J I think Bill Todd should be careful whenever he logs into a VMS system, heL might get electrocuted by VMS :-) ( would it be a LIB$ELECTROCUTE_USER, or a SYS$ELECTROCUTE_USER ? )   ------------------------------    Date: 11 Jul 2002 15:26:49 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)t Subject: Re: DS10 shutting downd- Message-ID: <0HYtq7yLyF3j@malvm7.mala.bc.ca.>c  , In article <3D2DCCD8.45A56EA6@videotron.ca>,2    JF Mezei <jfmezei.spamnot@videotron.ca> writes:  L > I think Bill Todd should be careful whenever he logs into a VMS system, heN > might get electrocuted by VMS :-) ( would it be a LIB$ELECTROCUTE_USER, or a > SYS$ELECTROCUTE_USER ? )  ?    I believe it's actually CIA$TERMINATE_WITH_EXTREME_PREJ  :-)a   ------------------------------   Date: 11 Jul 2002 23:25 CDTi' From: carl@gerg.tamu.edu (Carl Perkins)z Subject: Re: DS10 shutting down - Message-ID: <11JUL200223255925@gerg.tamu.edu>s  N }> Kevin Handy <kth@srv.net> wrote in message news:<3D2C557B.10904@srv.net>...B }>>I have a customer with an Alpha DS10 that keeps powering itself> }>>down (at least once a day).  Nothing on the screen (DS10 is4 }>>powered down). I know that if a fan stops, it can7 }>>do this, but the fans on this box all seem to be OK.i }>>r@ }>>Is there anything besides fans that can cause one of these to@ }>>power itself off, and is there any place I can look that will? }>>tell me why it has done this, like a show command at the >>> 
 }>>prompt? }>>r> }>>System seems to be clean (no dust bunnies inside the case),8 }>>it's not in a very hot room, it's plugged into a UPS,7 }>>UPS seems to be Ok, Windows PC's at the site are noto }>>crashing.  C Have you made certain that someone isn't pressing the halt or power G button? That gives you instant system death. They are both convenientlyn* located on the front of the box on a DS10.  E "User stupidity" is not unheard of. Neither is "deliberate sabotage".pE For that matter, neither is "the cleaning person unplugged it to plugo in the vacuum cleaner".c  G You might check to see if the last timestamps recorded before each bootoE indicate hatls at about the same time of the day, and check to see ifl$ it happens on weekends and holidays.   --- Carl   ------------------------------  # Date: Fri, 12 Jul 2002 02:44:00 GMTi/ From: "Richard L. Dyson" <rick-dyson@uiowa.edu>f Subject: DVD drives on OpenVMS( Message-ID: <3D2E4278.4020006@uiowa.edu>  J I've been trying to locate some details on using "PC" style (but SCSI) DVDH drives on Alphas running OpenVMS.  I have found a few references to someF DVD-R and DVD-RAM drivers, but I am just looking for a reader.  If theL DVD drive is a SCSI-2 or UltraSCSI drive compatible with the SCSI controllerG in my AlphaServers, will VMS recognize it and allow me to read from it?t< Would it be dependent on the OS version?  Would I need v7.3?  G Has anyone else hung DVD drives on any Alphas and if so, what models of - drive, Alpha and SCSI controller did you use?a  B This would be a good FAQ entry, if there is a good answer to it!!!  I Note, I know there have been some discussions of this in the newsgroup intH the past, but both archives mentioned in the current FAQ (apparently) noP longer exist. (Google has dropped the archive and crvax.sri.com did not answer.)   Regards, Rick -- pJ Richard L. Dyson                                      rick-dyson@uiowa.eduK   _   _  _____                      http://www-pi.physics.uiowa.edu/~dyson/ J | | | ||_   _|  Senior Systems Analyst   --   INFORMM-Cerner Systems Group< | | | |  | |    The University of Iowa Hospitals and ClinicsJ | \_/ | _| |_   Information Systems Dept. BT1000 GH   Office: 319/384-7016K   \___/ |_____|  Iowa City, IA 52242-1052                 FAX: 319/384-7020gE                  (Consulting to the Physics and Astronomy Department)    ------------------------------    Date: 11 Jul 2002 22:03:07 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)t" Subject: Re: DVD drives on OpenVMS3 Message-ID: <SQO21irav1Zo@eisner.encompasserve.org>   Z In article <3D2E4278.4020006@uiowa.edu>, "Richard L. Dyson" <rick-dyson@uiowa.edu> writes:L > I've been trying to locate some details on using "PC" style (but SCSI) DVDJ > drives on Alphas running OpenVMS.  I have found a few references to someH > DVD-R and DVD-RAM drivers, but I am just looking for a reader.  If theN > DVD drive is a SCSI-2 or UltraSCSI drive compatible with the SCSI controllerI > in my AlphaServers, will VMS recognize it and allow me to read from it?t> > Would it be dependent on the OS version?  Would I need v7.3?  H Read the recent thread on DVDwrite(r) software, which touches on reading as well.  K > Note, I know there have been some discussions of this in the newsgroup inKJ > the past, but both archives mentioned in the current FAQ (apparently) noR > longer exist. (Google has dropped the archive and crvax.sri.com did not answer.)  (http://groups.google.com/groups?as_q=%22dvdwrite(r)%22&num=10&as_scoring=r&hl=en&ie=ISO-8859-1&btnG=Google+Search&as_epq=&as_oq=&as_eq=&as_ugroup=comp.os.vms&as_usubject=&as_uauthors=&as_umsgid=&lr=&as_drrb=q&as_qdr=&as_mind=12&as_minm=5&as_miny=1981&as_maxd=11&as_maxm=7&as_maxy=2002&safe=images   ------------------------------  % Date: Fri, 12 Jul 2002 07:55:45 +0100p, From: "Rainer Giese" <waste.not@welcome.net>& Subject: Re: F$getsyi hidden Feature ?5 Message-ID: <aglr11$n2lv0$1@ID-138444.news.dfncis.de>e  > "Kor Rinkens" <Kor.Rinkens@vodafone.nl> schrieb im Newsbeitrag7 news:fae8becc.0207110214.3b21f1a4@posting.google.com...1E > pagedyn = f$getsyi("pagedyn")   ! give the initial pagedyn in bytes:F > npagedyn = f$getsyo("npagedyn") ! give the initial npagedyn in bytesC > npagevir = f$getsyi("npagevir") ! give the max virtual pagecnt ina6 > parameter is not documented in the vms help f$getsyi  8 It is documented : you can specify any SYSGEN-Parameter.   > f$getsyi("free_npagedyn")- > f$getsyi("cur_pagedyn")   H Don't exist, or better: I never found it. I do similar in a procedure byE checking the output of SHOW MEMORY, and I distinguish the calculationo, between the versions by F$GETSYI("VERSION").   -- Regards, Rainer Giese   ------------------------------  % Date: Thu, 11 Jul 2002 18:12:12 -0400m0 From: "Alan Boyles" <alan.boyles@mindspring.com> Subject: Re: FTP Hang Question/ Message-ID: <uis09qhplb1sfa@corp.supernews.com>0   Scott,  L I've had similar problems in the past and it turned out to be a problem withJ the process quota's in the the FTP account in UAF.  There should be an FTP) log file that gives you an error message.H   Alan1 "Scott Brooks" <sbrooks@psu.edu> wrote in messages( news:sd2d86bd.015@PSUGATE.hmc.psu.edu...	 > Hi All,o >bI > In VMS have a COM program running from a batch queue that FTPs to an NToH > Server running IIS.  Every once in a while the FTP service stops beingJ > available in the middle of the FTP process and the COM program just sitsJ > at the FTP step.  In the batch queue it says it is running, but it neverE > ends until manual intervention is taken. Does anyone know how I canhJ > prevent this from happening?  (Like trap the error and stop the process, > etc.)r >p	 > Thanks,e >a > Scottt >    ------------------------------  # Date: Thu, 11 Jul 2002 22:58:54 GMT  From: lbohan@dbc..spamless..com  Subject: Re: FTP Hang Question8 Message-ID: <2q2siuscc78ncla59k6vho3uivc1aqpon0@4ax.com>  D On Thu, 11 Jul 2002 13:22:51 -0400, "Scott Brooks" <sbrooks@psu.edu> wrote:  H >In VMS have a COM program running from a batch queue that FTPs to an NTG >Server running IIS.  Every once in a while the FTP service stops beingfI >available in the middle of the FTP process and the COM program just sits I >at the FTP step.  In the batch queue it says it is running, but it neveriD >ends until manual intervention is taken. Does anyone know how I canI >prevent this from happening?  (Like trap the error and stop the process,o >etc.)  - I do something like following on copies that  , should be quick, but may potentially hang.   (ie BillyBox on the other end)  ' basically spawing off a subprocess thatt& will do a forcex on its parent process after some time interval.  t  ( this assumes the copy is "well-behaved'  and will respond to a $forcex. w  9 $ spawn/nowait/nologic/nosym/nonotif/outp=nl:/input=nl: -o    @copy_forcex.com & $ copy/log  file.ext  node::dir:*.*;0  $ sts = $STATUSh $ If .not. sts r $ ThenE $!    raise a stink,  Could test for  %x2178  forced exit of image ..i $ endifo0 $ spid = f$trnlnm( "COPY_FORCEX_PID","LNM$JOB" ) $ If( spid .nes. "" )  $ Then $   stop/id='spid'  $   deassign/job copy_forcex_pid $ Endif-  ! where copy_forcex.com looks like:5    $!'f$verify(0)                   $pid = f$getjpi("","PID"):% $define/log/job COPY_FORCEX_PID 'pid'z	 $set noonB& $wait 0 00:05:00.00  !  5 min timeout " $mpid = f$getjpi("","MASTER_PID" )( $img  = f$getjpi(mpid, "IMAGNAME" )     7 $tst1 = (f$locate("COPY",img)    .nes. f$length( img ))i $if( tst1 )c $thena1 $       mcr t_exe:kill /forcex /noconf /id='mpid'a $endif $stop/id=0 s   ------------------------------   Date: 11 Jul 2002 17:51:39 GMT! From: Mark Hatch <mhatch@ics.com>n" Subject: GUI builder for VMS/Motif' Message-ID: <3D2DC5A8.E62F9288@ics.com>h   Hi,   F If you're interested in one, you might check out BX PRO at www.ics.com   Mark   ------------------------------  % Date: Thu, 11 Jul 2002 20:32:29 +0200o2 From: martin@radiogaga.harz.de (Martin Vorlaender)/ Subject: Re: List the processes using a mailbox ; Message-ID: <3d2dcf3d.524144494f47414741@radiogaga.harz.de>.  2 Michael Austin (maustin@firstdbasource.com) wrote: > Soterro wrote:? > > How do I find out which process is using a certain mailbox?rH > > I mean, the other way around from the process id is straightforward,H > > but when I look at the mailbox device it just says how many links it" > > has, not WHO else is using it.I > > Is there a way of doing that other than checking one by one the wholei > > process list?e > < > What commands are you currently using?  - examples please. >C0 > $ write sys$output f$getdvi("mba63:","OWNUIC") >hC > $ pipe show dev mb/full | sear sys$pipe device,"owner process id"d  F Errr... exactly how does that give all the processes that have a share in the "Reference count"?.  D The MBOX tool (available from http://www.process.com/openvms/) showsB the creator and all processes that have queued Read or Write ASTs.   cu,o   Martin -- uD                        |  Martin Vorlaender  |  VMS & WNT programmer1   OpenVMS: When you    |  work: mv@pdv-systeme.demE   KNOW where you want  |     http://www.pdv-systeme.de/users/martinv/ 8   to go today.         |  home: martin@radiogaga.harz.de   ------------------------------    Date: 11 Jul 2002 13:58:30 -0700& From: chessmaster1010@hotmail.com (JG)/ Subject: Re: List the processes using a mailboxs= Message-ID: <dd3f0cb7.0207111258.6cf0f970@posting.google.com>g  k Michael Austin <maustin@firstdbasource.com> wrote in message news:<3D2D9AE1.1601FE0D@firstdbasource.com>...u > Soterro wrote: > > 
 > > Hello, > > ? > > How do I find out which process is using a certain mailbox?eG > > ...when I look at the mailbox device it just says how many links itt$ > > has, not WHO else is using it...  < > What commands are you currently using?  - examples please. > 0 > $ write sys$output f$getdvi("mba63:","OWNUIC") > C > $ pipe show dev mb/full | sear sys$pipe device,"owner process id"i  C The owner UIC has nothing to do with who is currently accessing theh device.,  A The owner process id is more on track, but note the "else" in theiB original question.  This only shows who the first accessor is.  IfA fact, due to a VMS design flaw, the owner pid field of a sharablebC device may be a process that is no longer accessing it.  (Process AeF assigns a channel so it's PID is placed in the owner field.  Process BD then accesses the same device and the reference count is incrementedE but B's PID is not stored anywhere.  A then deacesses the device, butn? as long as the reference count remains >0 A's PID will still bey displayed by SHOW DEV/FULL.)  : The only way I know of determining this from VMS is to use> ANALYZE/SYSTEM.  SET OUTPUT to a log file and then issue "SHOWD PROCESS/CHANNEL ALL".  If the command completes without an error you1 can search the output for the device in question.e   ------------------------------  % Date: Thu, 11 Jul 2002 17:46:02 -0400C- From: JF Mezei <jfmezei.spamnot@videotron.ca>e/ Subject: Re: List the processes using a mailboxo+ Message-ID: <3D2DFC81.5B59930@videotron.ca>i  K This is one area where DECNET has a distinct advantage over mailboxes sincee you can:  K MC NCP SHOW KNOWN LINKS and you will see which process is connected to yourcD server process right away. (and the server process gets some form of= indentification of whom is connecting to it through the NCB.)y   ------------------------------    Date: 11 Jul 2002 14:44:49 -0700) From: jbrankin@ntlworld.com (Jim Brankin)u/ Subject: Re: List the processes using a mailboxs= Message-ID: <863f19d6.0207111344.4169db45@posting.google.com>y  3 I don't think so. I usually do something like this t  # SDA> set out sys$login:channels.tmpf SDA> sho proc all /channel SDA> set out sys$output   7 and then edit the channels.tmp file and search for the   mailbox name.    - Jim       f soterro@yahoo.com (Soterro) wrote in message news:<d5440555.0207110301.58dde354@posting.google.com>... > Hello, > > > How do I find out which process is using a certain mailbox? F > I mean, the other way around from the process id is straightforward,F > but when I look at the mailbox device it just says how many links it  > has, not WHO else is using it.G > Is there a way of doing that other than checking one by one the wholel > process list?  > 	 > Thanks,. > Sorin    ------------------------------  % Date: Thu, 11 Jul 2002 14:00:03 -0400 * From: WILLIAM WEBB <WWEBB1@email.usps.gov>5 Subject: RE: Looking for terminal session sharing pgm - Message-ID: <0033000072116663000002L032*@MHS>l  ? =0AI recommend CONTRL, from RAXCO which is now part of a bundlen called RAXCOSupport.  8 Go to www.raxco.com and you can get free eval downloads.  ; RAXCO's been around the VMS world for a while and the stuffa# in this bundle is pretty darn good.o   WWWebb   -----Original Message-----/ From: Info-VAX-Request@Mvb.Saic.Com at INTERNETe% Sent: Thursday, July 11, 2002 1:41 PMtB To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET1 Subject: Looking for terminal session sharing pgm     H Looking for terminal session sharing software to be used in 'help desk'=  D setting.  I had one at one time but am unable to find it in FreewareH listing (mostly because I've forgotten what it was called, getting' old=  ! ya know).  Any ideas appreciated.*   Thanks,i
 Ransom Fitch=    ------------------------------    Date: 11 Jul 2002 17:00:33 -0700( From: bob@instantwhip.com (Bob Ceculski)5 Subject: Re: Looking for terminal session sharing pgmu= Message-ID: <d7791aa1.0207111600.4db1317d@posting.google.com>   c "Ransom Fitch" <rlfitch@peakpeak.com> wrote in message news:<000d01c22901$f6c7f1c0$0a00a8c0@w2k>...oI > Looking for terminal session sharing software to be used in 'help desk'eF > setting.  I had one at one time but am unable to find it in FreewareI > listing (mostly because I've forgotten what it was called, getting' old # > ya know).  Any ideas appreciated.e > 	 > Thanks,  > Ransom Fitch  ; not only Raxco, but Network Dynamics has "Peek and Spy" ...e   ------------------------------    Date: 11 Jul 2002 18:03:20 -07004 From: bbaxter@denvernewspaperagency.com (Bob Baxter)5 Subject: Re: Looking for terminal session sharing pgm = Message-ID: <477fb6c5.0207111703.1303af7b@posting.google.com>t  c "Ransom Fitch" <rlfitch@peakpeak.com> wrote in message news:<000d01c22901$f6c7f1c0$0a00a8c0@w2k>... I > Looking for terminal session sharing software to be used in 'help desk'hF > setting.  I had one at one time but am unable to find it in FreewareI > listing (mostly because I've forgotten what it was called, getting' old # > ya know).  Any ideas appreciated.d > 	 > Thanks,e > Ransom Fitch  + Look at: http://www.networkingdynamics.com/u  D I do not have personal experience with them or their products, but IB have talked with them.  Seems like an exact match for what you are looking for.   Boba   ------------------------------  # Date: Thu, 11 Jul 2002 18:02:42 GMTM( From: Don Sykes <annonymous@pacbell.net>% Subject: Re: Looking for your opinion-+ Message-ID: <3D2DC891.84632986@pacbell.net>0   "Terry C. Shannon" wrote:m > 0 > "John Smith" <a@nonymous.com> wrote in messageC > news:9H4X8.7333$6DW1.4971@news01.bloor.is.net.cable.rogers.com...  > >t@ > > "Terry C. Shannon" <terryshannon@attbi.com> wrote in message > K > > > Good thing to do if you can figure out how. Those unfamiliar with VMSs	 > > might K > > > not be able to slog through all the technobabble. If you don't know aT	 > > printaL > > > symbiont from a QIO, detailed delvings into such arcane subjects might/ > > > render the publication a bit off-putting.- > > A > > Maybe the first issue should be only a glossary in that case.s > >u > M > Well, back when I wrote for Digital Review, we divided stuff into technical>C > articles (in-depth product reviews, articles surveying a specificnK > technology, eg databases, I/O controllers, OS features, whatever; and the>A > like) and feature articles which were a bit more palatable to aw2 > less-technical audience. The mix seemed to work.  L Agree. I always found the Digital Review informative. A mix of articles willL keep a wider audience interested. Even tech folks aren't *all* interested in  in-depth analysis of everything. -- l   Have VMS. Will Travel. Wire Paladin (@alphase.com)>
 San Francisco    ------------------------------  # Date: Thu, 11 Jul 2002 22:25:30 GMTiL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")% Subject: Re: Looking for your opiniona8 Message-ID: <00A10C77.A77F9951@SSRL04.SLAC.STANFORD.EDU>  V In article <3D2DC891.84632986@pacbell.net>, Don Sykes <annonymous@pacbell.net> writes: >"Terry C. Shannon" wrote: >>  1 >> "John Smith" <a@nonymous.com> wrote in messagefD >> news:9H4X8.7333$6DW1.4971@news01.bloor.is.net.cable.rogers.com... >> >A >> > "Terry C. Shannon" <terryshannon@attbi.com> wrote in messagei >> hL >> > > Good thing to do if you can figure out how. Those unfamiliar with VMS
 >> > mightL >> > > not be able to slog through all the technobabble. If you don't know a
 >> > printM >> > > symbiont from a QIO, detailed delvings into such arcane subjects mightr0 >> > > render the publication a bit off-putting. >> >B >> > Maybe the first issue should be only a glossary in that case. >> > >> rN >> Well, back when I wrote for Digital Review, we divided stuff into technicalD >> articles (in-depth product reviews, articles surveying a specificL >> technology, eg databases, I/O controllers, OS features, whatever; and theB >> like) and feature articles which were a bit more palatable to a3 >> less-technical audience. The mix seemed to work.d >oM >Agree. I always found the Digital Review informative. A mix of articles willoM >keep a wider audience interested. Even tech folks aren't *all* interested ina! >in-depth analysis of everything.   K The same mix used to be used in Unix/World, back when I wrote for it in thenN 1980s.  There  were detailed hardware reviews and techie-only columns, but theM feature articles were aimed at the reasonably intelligent but not necessarilylN knowledgeable.  (This had two advantages: the not-that-technical manager couldL find something intelligible and possibly helpful to read in every issue, andN since the subjects of the feature articles varied considerably each month, andK hardly anybody is a guru in everything, the techies could learn a bit about M topics outside their areas of expertise.  The manager could feel a little bitnO of techie macho even though he couldn't read shell scripts, just because he wasi; reading something in a magazine that printed shell scripts.   D Unix Review always got more respect because it was more unilaterallyN tech-oriented, but had a less broad readership.  What finally killed UnixWorldC (after an abortive name change to, uh, "Open Systems") was industrysO consolidation.  You don't see Altos, Pyramid, Sequent, or Data General buying au% whole lot of ads anywhere these days.o   -- Alan>      >--  >e >Have VMS. Will Travel.m >Wire Paladin (@alphase.com) >San Francisco  O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056SM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210dO ===============================================================================d   ------------------------------  % Date: Thu, 11 Jul 2002 16:23:22 +0200l3 From: Terje Mathisen <terje.mathisen@hda.hydro.com>  Subject: Re: McKinley Cometh...h- Message-ID: <3D2D94DA.70822A07@hda.hydro.com>e   Ken Green wrote:M > > If MS is going to let PCs get into video editting in a major way, they'renK > > going to need GBs of memory for the editors and thus more than 32 bits.o > D > Currently video editing uses less RAM than still picture editting.H > The quantities of data involved with video are just so big that tryingG > to do it in RAM is impractical. For DV 2GB is 9mins of video. So it's=I > all done from disk. Besides theres no real benift in having many frames B > in memory at one time. For stills though 100MBs are nothing, and? > you often want several stages of manipulation in RAM at once,e- > otherwise the undo button takes to long :-)d  
 Very true:  D Last year I thought that getting 512 MB of RAM on my laptop would be? plenty, but after I started to use PanoTools to generate maskednH multi-layer Photoshop images for big panoramas, I realized that "it just
 ain't so".  2 2 GB seems reasonable for my next desktop machine.   Terjei --    - <Terje.Mathisen@hda.hydro.com>@ "almost all programming can be viewed as an exercise in caching"   ------------------------------  % Date: Thu, 11 Jul 2002 17:28:57 +0200 3 From: Terje Mathisen <terje.mathisen@hda.hydro.com>r Subject: Re: McKinley Cometh...o- Message-ID: <3D2DA439.ECF7B8F7@hda.hydro.com>c   JF Mezei wrote:h > W > Merced was terribly slow, but it was more or less a beta version of the architecture.- > N > Can one consider McKinley to be "production" quality and judge IA64 based on > McKinley ? > M > If McKinley is now production quality, isn't it fair to state that from now O > on, IA64 would progress are roughly the same rate as competing chips ? If so, O > its relative position in the pack wouldn't change much over time. It may lead = > for a few months, and then be overtaken by another etc etc.k  D Except if it turns out that it is relatively harder to implement newA ideas in one architecture relative to another, it will still fallaF behind. It is not certain, but at least possible that IA64 might be in such a situation.i  P > What I don't quite understand is that EPIC should simplify a chip design sinceN > it offloads lots of the logic to the compilers, right ? If that is the case,O > is it fair to state that an EPIC's chip improvements will come mostly throughv: > clock increases with far less done through chip design ?  D I wouldn't really say that it offloads a lot of logic, instead it isE extremely dependent upon good compilers, much more so than any of thec current OOO cpus.u   > P > For instance, with a philosophy of having much of the performance logic in theG > chip, the Alpha engineers were ahle to add fancy stuff such as branchrN > prediction and pre-fetching/compilation of both instruction streams after anP > IF statement. So these improvements were added to the clock increases to yield > an even more performing chip.c > P > But just how much fancy stuff can be added to IA64 before it is no longer EPICK > ? And when IA64 is imporved to the point that it is a RISC chip, won't itnP > require that compilers that had been built to do the work that IA64 doesn't doM > be modified to become more conventional compilers that allow the chip to do ( > much of the performance enhancements ?  B There are some obvious venues for IA64 improvement, primarily moreF execution units which would make it much more feasible to do agressive& predicate conversion of IF/ELSE blocks  : Next they can improve some important integer opcodes, like multiplication and shifts.  A Using a set of virtual predicates to do eager/greedy execution of @ multiple execution paths would seem to require very little extra hardware resources.8  H They can of course also retrofit a dataflow (OOO) engine, but this would be a _huge_ step. :-).   Terje  -- h  - <Terje.Mathisen@hda.hydro.com>@ "almost all programming can be viewed as an exercise in caching"   ------------------------------  % Date: Thu, 11 Jul 2002 19:42:56 +0100n& From: Ken Green <Ken.Green@kgcc.co.uk> Subject: Re: McKinley Cometh...i* Message-ID: <3D2DD1B0.E9A48EA5@kgcc.co.uk>   Alex Colvin wrote:  N > >>         Exactly.  You can cook a benchmark to make an UltraSparc III lookB > >>         fast too, i.e. art.  Hats off to their compiler team. >aQ > >But definitelt hats off to the compiler guys. Since the benchmark result still:H > >stands I assume none of the competitor have shown the optomisation toN > >be art specific. Also no one else seems to have managed to pull of the same
 > >trick yet.t >e= > any information or unsupported rumors on what the trick is?- >-  > They managed to invert a nested pair of loops that no one else: has, I believe. The art benchmark forces memory access the< wrong way round, so that it trashes the cache and TLB, Sun's? compiler guys have found a way of putting it into the order them< CPU finds easy, this is usually easy for a programmer to do,; but hard for a compiler to tell whether the change is safe.u  8 If you you knew that already and wanted to know how they9 pulled the trick off, then I'm sorry I haven't a clue (R)   ; I'm sure sooner or later other compiler writers will manageh< the trick and everyone elses SPECfp figures will take a leap+ skyward. Until then Sun wins at that trick.n   >  > -- >         mac the naf   Cheers   Kent   ------------------------------   Date: 11 Jul 2002 18:26:21 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)  Subject: Re: McKinley Cometh...t, Message-ID: <agkikd$1b8k$1@info.cs.uofs.edu>  & In article <Gz3EFD.H3n@world.std.com>,*  alexc@world.std.com (Alex Colvin) writes:D |> >Akk, you don't need a 64 bit processor to support more than 4 GBF |> >of memory, trust me on this one or alternatively look at a sequent
 |> >brochure.: |>  @ |> sure, you can go with TINY/COMPACT/MEDIUM/HUGE memory models. |> but it's no way to live.s |> i/ |> aren't "near" and "far" still reserved in C?o  + near and far have never been reserved in C.    bill   -- 2J 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: Thu, 11 Jul 2002 21:30:07 +0200l& From: Michael Joosten <joost@c-lab.de> Subject: Re: McKinley Cometh...e$ Message-ID: <3D2DDCBF.6F59@c-lab.de>   Nick Maclaren wrote: >    > J > The claim that I made was that the Spec figures (and, most particularly,E > the SpecInt) figures were heavily affected by both the compiler and"E > chipset.  HP have said so in public, for heaven's sake!  And, since F > the compiler that produces the high SpecInt figures is not availableF > under Linux, it is NOT reasonable to claim that the figure indicates! > the performance of IA-64 Linux.t >   G Not sure in how far the situation got better in the mean time, but some E time ago (early 2001, I think) there was an article in a German LinuxiD mag (Linux Magazin? I can't recall...) where an Itanium 1 server was6 compared with an Athlon 1.4 (or 1.6 ? ) GHz PC crate.   F Besides the usual SPEC and whatever benchmarks, they tried to also runA integer and server specific applications, in this case some MySQLeA benches. Using both gcc and the enhanced gcc from HP (?), ecc, inOG particular the MySQL results where plain depressing. In fact, the blamee? was put on the lack of optimization for character/byte-oriented H operations (lots of copy operations in DBs) in gcc. Most ironically, ecc? performed even worse, and both were easily beaten by the Athlon-A reference. Of course, the FP intensive benchmarks were all won byM Itanium.  C Might be interesting to see a similar test performed again in a fewl2 months with Itanium II and a current P4 or Athlon.H Even more interesting would be comparision with a more 'professional' DBG like DB2 or Oracle, because pairing an expensive Itanium box with MySQLi# is quite likely a waste of money...r     -- .* Michael Joosten, SBS C-LAB, joost@c-lab.de* Fuerstenallee 11, 33094 Paderborn, Germany, Phone: +49 5251 606127, Fax: +49 5251 6060658 C-LAB is a cooperation of University Paderborn & SIEMENS   ------------------------------  % Date: Thu, 11 Jul 2002 15:51:20 -0400o* From: WILLIAM WEBB <WWEBB1@email.usps.gov> Subject: RE: McKinley Cometh... - Message-ID: <0033000072134538000002L082*@MHS>   * =0AUsing "Near" and "Far" as memory models. suggest that somebody had "Green Eggs and Ham". read to them too often when they were a child.   WWWebb   -----Original Message-----/ From: Info-VAX-Request@Mvb.Saic.Com at INTERNETw% Sent: Thursday, July 11, 2002 3:42 PM.B To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET Subject: RE: McKinley Cometh...n    & In article <Gz3EFD.H3n@world.std.com>,*  alexc@world.std.com (Alex Colvin) writes:D |> >Akk, you don't need a 64 bit processor to support more than 4 GBF |> >of memory, trust me on this one or alternatively look at a sequent
 |> >brochure.  |>@ |> sure, you can go with TINY/COMPACT/MEDIUM/HUGE memory models. |> but it's no way to live.2 |>/ |> aren't "near" and "far" still reserved in C?p  + near and far have never been reserved in C.o   bill   --H Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wol= ves D bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |? Scranton, Pennsylvania   |         #include <std.disclaimer.h>=h   ------------------------------  % Date: Thu, 11 Jul 2002 16:49:04 -0400O- From: JF Mezei <jfmezei.spamnot@videotron.ca>b Subject: Re: McKinley Cometh...r, Message-ID: <3D2DEF2A.77468C7C@videotron.ca>   re: benchmarks  , http://www.apple.com/xserve/performance.html  L has some "refreshing" benchmarks because they compare real applications, not some SPEC benchmarks.h  K This is not only CPU, but also NETWORK as well as file server stuff. To me,aM these tests are far more meaningful than those SPECmarks  because they really 5 compare total systems for various types of workloads.F   ------------------------------  # Date: Thu, 11 Jul 2002 20:43:14 GMT7* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: McKinley Cometh...aA Message-ID: <C5mX8.88963$Im2.3993776@bin2.nnrp.aus1.giganews.com>o  4 "Alex Colvin" <alexc@world.std.com> wrote in message  news:Gz3EFD.H3n@world.std.com...C > >Akk, you don't need a 64 bit processor to support more than 4 GBiE > >of memory, trust me on this one or alternatively look at a sequentm > >brochure. >o? > sure, you can go with TINY/COMPACT/MEDIUM/HUGE memory models.a > but it's no way to live.  L Nor is there any need to live that way (nor am I even sure that the hardwareK *allows* you to live that way:  while segmentation can IIRC be used, it may-A still limit your segments to a single 32-bit-wide address space).v  L If you want to make use of > 4 GB of memory by multiple applications, but noL single application needs access to more than 2 GB (or 3 GB if it's using theF 3GB app/1GB system Windows server setup; don't know how flexibly LinuxI splits up the address space), then it all just works transparently to therG applications.  Whether Windows supports over-sized system cache in suchaF cases I don't know, but there's certainly no reason why it couldn't if> someone made the effort (though if other system hardware isn'tI 36-bit-physical-address-aware the system would need to copy data into andi> out of such 'high memory' when, e.g., moving it from/to disk).  L Or if one or more individual applications want access to more than 2 or 3 GBC of physical memory for data storage (since having more than 2 GB of E executing code is, I would hope, a rare occurrence), they can use the>J Windows or Linux address windowing extensions to map (not copy) the largerK memory as required into virtual address ranges within their normal 2 GB - 3 B GB address space.  While the overhead of this mapping might becomeI noticeable for, say, random access within very large arrays, using it forrK something like an expanded database cache (where once you get a page you donL at least some actual work with it before needing another) makes the overheadF negligible, and the managing of such a cache adds very little relative6 complexity to that of managing a cache in flat memory.   - bill   ------------------------------  % Date: Thu, 11 Jul 2002 16:54:50 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>l Subject: Re: McKinley Cometh...e, Message-ID: <3D2DF084.2C507AA8@videotron.ca>   WILLIAM WEBB wrote:r > ) > Using "Near" and "Far" as memory modelso0 > suggest that somebody had "Green Eggs and Ham"0 > read to them too often when they were a child.  L Weren't those references in dos to subroutine calls while the 8086 was stillI limited to 16 bit adressing and was using segment registers ? As I recallaM (fuzzy memory), near calls branched to a subroutine in the same "vicinity" astH current program pointer while "far" calls would branch using the segment< register as well as displacement or something to that order.  ? I do not think it was "C" per say, just microsoft "extensions".    ------------------------------  % Date: Thu, 11 Jul 2002 23:31:24 +0100j& From: Ken Green <Ken.Green@kgcc.co.uk> Subject: Re: McKinley Cometh....) Message-ID: <3D2E073C.14C8855@kgcc.co.uk>8   Michael Joosten wrote:   > Nick Maclaren wrote: > >w >e > >"L > > The claim that I made was that the Spec figures (and, most particularly,G > > the SpecInt) figures were heavily affected by both the compiler and.G > > chipset.  HP have said so in public, for heaven's sake!  And, sinceiH > > the compiler that produces the high SpecInt figures is not availableH > > under Linux, it is NOT reasonable to claim that the figure indicates# > > the performance of IA-64 Linux.t > >> >sI > Not sure in how far the situation got better in the mean time, but some>G > time ago (early 2001, I think) there was an article in a German LinuxiF > mag (Linux Magazin? I can't recall...) where an Itanium 1 server was7 > compared with an Athlon 1.4 (or 1.6 ? ) GHz PC crate.c >cH > Besides the usual SPEC and whatever benchmarks, they tried to also runC > integer and server specific applications, in this case some MySQLaC > benches. Using both gcc and the enhanced gcc from HP (?), ecc, in I > particular the MySQL results where plain depressing. In fact, the blamelA > was put on the lack of optimization for character/byte-oriented J > operations (lots of copy operations in DBs) in gcc. Most ironically, eccA > performed even worse, and both were easily beaten by the AthlonsC > reference. Of course, the FP intensive benchmarks were all won byr
 > Itanium. >wE > Might be interesting to see a similar test performed again in a fewe4 > months with Itanium II and a current P4 or Athlon.J > Even more interesting would be comparision with a more 'professional' DBI > like DB2 or Oracle, because pairing an expensive Itanium box with MySQL,% > is quite likely a waste of money...  >i > --, > Michael Joosten, SBS C-LAB, joost@c-lab.de, > Fuerstenallee 11, 33094 Paderborn, Germany. > Phone: +49 5251 606127, Fax: +49 5251 606065: > C-LAB is a cooperation of University Paderborn & SIEMENS  < There are TPC-C figures for the I2 boxes on the TPC website.8 the 4way rx5670 score 78K and the 2way rx2600 score 40K,  < A 2way ProLaint ML530G2T 2P using 2.4GHz P4 Xeons scores 34KF In a quick look, I could see any 4way P4 scores, but the 4way I2 beats
 the 8way P3s.i   Cheers   Kena   ------------------------------  + Date: Thu, 11 Jul 2002 23:40:43 +0000 (UTC).2 From: Anil T Maliyekke <amaliy1@icarus.cc.uic.edu> Subject: Re: McKinley Cometh...a+ Message-ID: <agl51r$rgs$1@newsx.cc.uic.edu>   4 In comp.arch Ken Green <Ken.Green@kgcc.co.uk> wrote:  D > I believe theres quite a difference between the Power4 SPEC scoresA > when they're configured with 64MB of L3 cache instead of 128MB..   POWER4 SPEC @ system     GHz  ratio  L3 cache  int peak  ratio  fp peak  ratio? 1-way p690 1.3  1.3    128MB     839       1.31   1266     1.41S5 1-way p630 1.0         64MB      637              896=  B There is really no differance for 64MB vs 128MB of external cache.A The additional performance boost for the SPECfp200  could be fromj- the cache or the additional memory bandwidth.j     Anil   ------------------------------  + Date: Thu, 11 Jul 2002 21:55:28 +0000 (UTC)rA From: "Rupert Pigott" <dark.try-eating-this.b00ng@btinternet.com>j Subject: Re: McKinley Cometh...e/ Message-ID: <agkusf$qhs$1@paris.btinternet.com>n  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3D2DEF2A.77468C7C@videotron.ca... > re: benchmarks >h. > http://www.apple.com/xserve/performance.html >AJ > has some "refreshing" benchmarks because they compare real applications, note > some SPEC benchmarks.f  D However I don't really get much of a picture of what's going on fromC their "BLAST" benchmark which appears to compare two different code B bases. Note the codebase they used for the non-Apple platforms wasB optimised for searches on word length "11", and if you look at theC graph you will note that the benchmark supports that. Meanwhile theaF Apple version seems to scale pretty linearly with word length. ClearlyB these codebases are very different. SPEC at least tries to compare@ apples with apples (haha). Something that also stands out like a= sore thumb in these results is that Apple compared DDR G4s vs  SDRAM P4s... HMMMMMMMMMMMMMMMM.   A Again the Xinet benchmark seems to run into a wall, but this timea@ it's the Apple stuff which hits the wall, and bizarrely the Dell@ box seems to trail off slightly... RIPs are quite complex pieces> of software which also stress the I/O subsystem (in particular> file write performance). If you don't have enough RAM they can> kick the shit out of your VM too. I also note that the link to? the benchmark details is convieniently broken. On inspection oftB the xinet site itself I note that the configuration info available for the systems is inadequate.  A As for Webench, fuck knows, but SPEC have web benchmarks too, youl? should go look at them. Maybe Apple didn't like the scores theycA got with SPEC's web benchmark suite and so decided to find a moree favourable one. :)  A The Bonnie benchmark was conducted in a dubious manner too. Again @ we have inadequate configuration information available so we are@ unable to tell if they pulled a fast one. Linux supports lots of; filesystems out of the box, plus you have the sync or async ? mounting options. I don't think they adequately explained theirt? choice of filesize either, 2Gb looks like one of those "special  numbers" to me.i  I > This is not only CPU, but also NETWORK as well as file server stuff. Toa me,lH > these tests are far more meaningful than those SPECmarks  because they really7 > compare total systems for various types of workloads.e  < It's also complete shite because they don't compare the sameC codebases and they don't provide the source so you can verify this.bB If that wasn't bad enough they don't give you enough configuration@ info either. Sorry, but I'll take SPEC's benchmarks over Apple'sF any day of the week. What's more SPEC do more than CPU/Memory/Compiler benchmarks too. :)   Cheers,f Rupert   ------------------------------  % Date: Fri, 12 Jul 2002 00:35:41 -0400o- From: JF Mezei <jfmezei.spamnot@videotron.ca>  Subject: Re: McKinley Cometh...e, Message-ID: <3D2E5C95.64BCE402@videotron.ca>   Rupert Pigott wrote:. > http://www.apple.com/xserve/performance.html> > It's also complete shite because they don't compare the sameE > codebases and they don't provide the source so you can verify this.   K That is a fair criticism. But doesn't the apple comparison represent a more K "real world" approach. You take the application available on platform 1 and N compare it with whatever application is available on platform 2 to do the same work ?  K What I find significant is that Apple is starting to push its Unix servers.d   ------------------------------  % Date: Thu, 11 Jul 2002 14:29:08 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>j4 Subject: Re: McKinley tops SpecFP AND SpecInt charts, Message-ID: <3D2DCE67.8F7C07B2@videotron.ca>   John Smith wrote:-K > Short of standing up in a VERY public way to dispell *any* doubt, HP willeL > continue to be severely questioned on its commitment to VMS. Certainly theF > act of NOT actively advertising, selling, and marketing VMS to *new*) > accounts speaks volumes in that regard.p  H Yes, getting up and admitting past mistakes and saying that things wouldK change that that HP would NOT continue "Compaq's plan of record" but ratherkK institute a new plan for VMS that include growth and the ability to competem3 freely would achieve the desired result very fast. s  J Considering that the Compaq folks who had instuituted the "plan of record"N have been hired in high level positions at HP (Winkler, capellas etc), I doubt HP would take such an action.e  H So perhaps their intentions is to very slowly change the course and veryL slowly, without making any noticeable suddent changes, turn the tide around.L This will take longer and be less convincing, so HP will have to continue toG hear "digital is killing VMS" complaints for a while longer before some , credibility in HP's actions begins to build.   In o   ------------------------------  # Date: Thu, 11 Jul 2002 20:23:13 GMT # From: "John Smith" <a@nonymous.com>i4 Subject: Re: McKinley tops SpecFP AND SpecInt chartsF Message-ID: <ROlX8.2654$pxc.2382@news01.bloor.is.net.cable.rogers.com>  < "Terry C. Shannon" <terryshannon@attbi.com> wrote in message& news:wciX8.25103$Jp.52303@rwcrnsc53... >J0 > "John Smith" <a@nonymous.com> wrote in messageA > news:aqhX8.1880$pxc.738@news01.bloor.is.net.cable.rogers.com...D > >k6 > > "Alan Greig" <a.greig@virgin.net> wrote in message6 > > news:g3hqius5rrb345dtj4upodm7n4km221ss9@4ax.com...2 > > > On Wed, 10 Jul 2002 15:50:19 -0400, JF Mezei+ > > > <jfmezei.spamnot@videotron.ca> wrote:  > > >  > > > >tJ > > > >But HP must understand that VMS customers have been lied to so many > timesP > > thatF > > > >it takes time to rebuild trust and during that time, it is HP's > > responsabilityK > > > >to be patient before customers come to believe this is a sincere and2 > > permanent improvement. > > >cK > > > From a meeting I've had I'm sure they understand it. After all HP hashL > > > been attempting to pick up business for HP-UX from VMS sites for many,J > > > many years. Part of their sales pitch was roughly along the lines ofK > > > "VMS is/was great but Digital/Compaq neglected it and you can't trustoI > > > them." Now these same guys own VMS. What do they say/do now? It's ac% > > > hard question and they know it.  > >  > >lH > > Short of standing up in a VERY public way to dispell *any* doubt, HP willJ > > continue to be severely questioned on its commitment to VMS. Certainly theaH > > act of NOT actively advertising, selling, and marketing VMS to *new*+ > > accounts speaks volumes in that regard.e > >n > D > Yep, it would be nice for Ms. Fiorina to come out with a statementJ > reflecting the sentiments you have articulated. Dunno how much push-back$ > you'll get on the "new customers." >oG > It might be worth writing a "Dear Carly" letter, which can be done byxD > visiting http://www.hp.com/hpinfo/execteam/email/fiorina/index.htm > H > I would take a positive, not negative approach... thank HPQ for making stepseK > in the right direction, and respectfully suggesting additional steps thatnK > might benefit the cause. A few hundred letters of this ilk might get some(H > attention... far more attention that commentary in c.o.v. is likely to4 > elicit. My opinion only, and well worth the price. >r  K I agree that big ships are slow to turn. But the decision to turn the wheeliL comes before the ship actually begins the turn. The captain thinks about it,K make a public announcement on the bridge (and maybe to the passengers too),uK gives the order to the helmsman (marketing) and then we begin to slowly seeo a course correction.  B In this case these is nothing wrong with Carly announcing a courseD correction in advance of the order to turn. In fact it would be mostJ refreshing to hear her voice on this matter. And after that, I'm sure thatL most of, if not all, us here would be prepared to give HP some latitude. ButA we wouldn't be averse to keeping a critical eye on things either.A  ! And thank you for the link above.r   ------------------------------  # Date: Fri, 12 Jul 2002 02:50:00 GMT2* From: "Bill Todd" <billtodd@metrocast.net>4 Subject: Re: McKinley tops SpecFP AND SpecInt chartsA Message-ID: <strX8.152427$vq.7886909@bin6.nnrp.aus1.giganews.com>   @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message, news:B7gX8.19$FX6.362593@news.cpqcorp.net...7 > "Bill Todd" <billtodd@metrocast.net> wrote in messageV= > news:8H2X8.70743$Im2.3051998@bin2.nnrp.aus1.giganews.com...2J > > We have different viewpoints, and are both angry (though for differentH > > reasons).  The other difference between us is that I substantiate my > views,B > > but you just disparage them while refusing to present anything substantiveeJ > > in the way of rebuttal.  In other words, while you probably have areas inI > > which you're technically competent, in these particular waters you'veOF > > presented nothing to suggest any competence whatsoever (rather the > > opposite). > >" >i" > You don't substantiate anything.  D Fred, Fred, Fred:  have you completely descended to the Big Lie as aE rebuttal mechanism?  You may not consider the substantiations I offereJ *solid* ones (in which case the thing to do is address them specifically),K but if you claim they don't *exist* then you simply haven't been paying any- attention at all.-  )   You build a house of cards on scraps ofOG > little understood information and pontificate as the grand poo-bah ofo > knowledge.  ! Well, in the land of the blind...c  K I glean what I can, and make what sense of it I can.  In many cases it doeseH make sense, in others things are more tenuous.  And that's exactly how I
 present them.s  H Once again, if you have specific problems with any particular cards, youL should present them rather than just claim they're irrelevant - because most@ of them come directly, and with attribution, from your employer.  @   Your predictions and views display a very specific agenda, andF > no, it has nothing to do with the success of VMS, or IA64.  Sure, my agenda8 > is the opposite - I want VMS and IA64 to both succeed. >eH > My "anger" if there is any, is the potential that your tenuous-at-best) > analysis are taken seriously by people.   K I suspect that it's more because they *are* taken seriously by people.  ButhK instead of presenting a counter-argument that might also be taken seriously D (even by me, if you've really got new light to shed), you just spew.   - bill   ------------------------------    Date: 11 Jul 2002 14:11:13 -0700( From: bob@instantwhip.com (Bob Ceculski)4 Subject: Re: Only 20% drop in VMS systems (was: wow)< Message-ID: <d7791aa1.0207111311.3cb0281@posting.google.com>   Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com> wrote in message news:<agjsf1$8m1$1@new-usenet.uk.sun.com>...iH > > FWIW, Solaris is more or less "UN*X vanilla" here: at, atq, crontab,5 > > etc., but no batch queues as VMS folks know them.r > >  >  > D > But there is a wealth of 3rd party batch queue products, Control-M
 > etc etc. > 	 > Regards' > Andrew Harrison   ; from one of your prior posts Andrew about VMS IP stacks ...   C Nice try but not the point. Who gives a rats arse if Multinet isn'thD vunerable. Now days no customer expects to have to buy an additionalA layered 3rd party product to get IP support in an OS and very fewlC customers would be impressed with the idea that you need to do thisf* because the vendors own product is broken.   Regardst   Andrew Harrisond  * now I can slightly modify this to read ...  D Nice try but not the point. Who gives a rats arse if you can buy 3rdH party batch queues. Now days no customer expects to have to buy an add'lC layered 3rd party product to get batch queues in an OS and very feweC customers would be impressed with the idea that you need to do thisi* because the vendors own product is broken.   chew on your own words matey!a   ------------------------------  # Date: Thu, 11 Jul 2002 20:11:48 GMTe+ From: "Rick Barry" <barry@star.zko.dec.com>o7 Subject: Re: OpenSSL and certificates concept questionsh2 Message-ID: <8ElX8.44$QZ6.437366@news.cpqcorp.net>  4 >"Rich Jordan" <jordan@ccs4vms.com> wrote in message8 >news:cc5619f2.0207101500.14cde0fe@posting.google.com...G >> I'll intrude here with this because we are working on a VMS project.vF >> First off, if anyone has recommended reading thats good on coveringI >> concepts for using certificates in the context of secure http and SSL,hI >> I'd love to know.  I'm going to have the O'Reilly book on SSL shortly,s? > but whatever else would be useful.  The project is the securesI >> 'http/https' client server item I asked about in a previous thread (tol= >> make sure the needed infrastructure was available on VMS).   < The openssl-users@openssl.org mailing might be of help. I'veB attached a recent entry that might be usefull. The C code examplesC may be your best bet. Documentation on using SSL is still maturing.-  * Don't forget to check out www.openssl.org.  
 Rick Barry) Compaq Secure Web Server Development Teamo OpenVMS Systems Software Group Hewlett Packard Company0
 Nashua, NHC -------------------------------------------------------------------w   There are 2 books in the marketd  * 1. network Security with openssl (oreilly) which is just out in the marketw  > 2. SSL and TLS Designing and Building Secure Systems : by Eric Rescorla  B Plus you can find some examples on how to set up ssl communication  if you download a latest version of openssl library0 I think they are in the apps directory and named# client.c , server.c and inetdserv.cc   check out this link also:   0 http://www.pdos.lcs.mit.edu/asrg/2000-11-13.html  " Examples in the Eric book are here% http://www.rtfm.com/openssl-examples/    [...]aF ______________________________________________________________________F OpenSSL Project                                 http://www.openssl.orgF User Support Mailing List                    openssl-users@openssl.orgF Automated List Manager                           majordomo@openssl.org   ------------------------------  % Date: Thu, 11 Jul 2002 23:37:59 -0500t( From: Rich Jordan <duodec@speakeasy.net>7 Subject: Re: OpenSSL and certificates concept questionsm, Message-ID: <3D2E5D27.1020106@speakeasy.net>   Rick Barry wrote:e5 >>"Rich Jordan" <jordan@ccs4vms.com> wrote in messagee9 >>news:cc5619f2.0207101500.14cde0fe@posting.google.com...  >> >>>The project is the secureI >>>'http/https' client server item I asked about in a previous thread (to = >>>make sure the needed infrastructure was available on VMS).n >> > > > The openssl-users@openssl.org mailing might be of help. I'veD > attached a recent entry that might be usefull. The C code examplesE > may be your best bet. Documentation on using SSL is still maturing.  > , > Don't forget to check out www.openssl.org. > .......... > Rick Barry+ > Compaq Secure Web Server Development Team:  > OpenVMS Systems Software Group > Hewlett Packard Companyi > Nashua, NH   Rick,oI       thanks _very_ much.  We're going in cold on this one; never worked .I with 'secure' protocols and had no relevant documentation or experience, nG and its been hard to finagle google into providing the needed results, sF though I've found a lot of esoterica about certificates, explicit vs. @ implicit tags, various malfeasances on the part of every CA and $ certificate generating program, etc.  I       I got my copy of the O'Reilly OpenSSL book today, and I'm starting gH to go through it.  Looks like I finally get to reinstall C on the Alpha K (our shop is dedicated to BASIC, sigh).  The pointers will be very helpful.e   Rich Jordan    ------------------------------    Date: 11 Jul 2002 13:00:44 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)i  Subject: Re: OpenVMS Ambassadors3 Message-ID: <RkjYc8U1ll67@eisner.encompasserve.org>   ` In article <5niX8.29$l_6.460904@news.cpqcorp.net>, "Mike Kier" <michael.kier@compaq.com> writes:  N > We meet twice a year in Nashua.  We are at about capacity for what the local > hotel facility can provide.   F Boston is building a new Convention Center, which should hold 5000 :-)   ------------------------------  % Date: Thu, 11 Jul 2002 14:19:38 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>   Subject: Re: OpenVMS Ambassadors, Message-ID: <3D2DCC2E.1FC7F4D2@videotron.ca>   "Terry C. Shannon" wrote:mM > Hint: acknowledging that HPQ is taking initial steps in the right directioneN > would not hurt. If HPQ realizes that the positive messages are resonating we+ > might see more of the same in the future.   G Or they may simply say " wow, that is all that is needed, no need to doyN anything above and beyond a token press release per new VMS version". You must= not give them the impression that they have achieved success.t  1 > Negative reinforcement will not help the cause.o  N But "we need more before we are convinced" is not bnegative re-enforcement. HPM must be aware that VMS folks have learned to be cynical because of the number  of times we have been screwed.   ------------------------------  % Date: Thu, 11 Jul 2002 14:37:46 -0400l- From: JF Mezei <jfmezei.spamnot@videotron.ca>d  Subject: Re: OpenVMS Ambassadors, Message-ID: <3D2DD06C.BBE7E90D@videotron.ca>   Sue Skonetski wrote:J > Folks as well as you know me, do you think that I would not make it veryM > clear to everyone from Michael on down the value of the Ambassadors??  ComeoJ > on, many have tried, many of failed to shut me up about the Ambassadors.  I But if the title of Ambassador is not known in the payroll/HR systems for'L those employees who are ambassadors, then with the volumes of layoffs, it isN much more likely that a "mere" employee may be flagged as redundant and by theF time you find out, it is too late. That is why I asked whether the VMSJ ambassadors were known to the payroll/human resources people and thus they= would be far less likely to flag such employees as redundant.t   ------------------------------  % Date: Thu, 11 Jul 2002 14:46:56 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>e  Subject: Re: OpenVMS Ambassadors, Message-ID: <3D2DD292.583FEAC8@videotron.ca>   Mike Kier wrote:N > The folks that are Ambassadors are in the program because they are competentK > and effective.  This tends to make them less likely to be targeted in thei > first place.  F In the case I know about, during one of the first rounds of layoffs atK Digital, it was the VMS guru who was a partner who was first told to leave.UK And while he may have had "I am better than you" attitude (he was quite the M guru), he was still THE person you wanted to service your site when you had a I VMS problem. The Montreal office threw out its most valuable VMS resourceeC first, and he was thrown out exactly because he was the VMS expert.u  J Remember that this is the same office that talked about VMS in the past inM sensences such as "Tru64 now has all the clustering that many of you HAD whenp
 you RAN VMS."f   ------------------------------  # Date: Thu, 11 Jul 2002 19:07:52 GMTt+ From: "Mike Kier" <michael.kier@compaq.com>-  Subject: Re: OpenVMS Ambassadors2 Message-ID: <cIkX8.41$vX6.352325@news.cpqcorp.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3D2DD292.583FEAC8@videotron.ca... > Mike Kier wrote:F > > The folks that are Ambassadors are in the program because they are	 competenteI > > and effective.  This tends to make them less likely to be targeted in  theu > > first place. > H > In the case I know about, during one of the first rounds of layoffs atF > Digital, it was the VMS guru who was a partner who was first told to leave.I > And while he may have had "I am better than you" attitude (he was quite  the I > guru), he was still THE person you wanted to service your site when youx had asK > VMS problem. The Montreal office threw out its most valuable VMS resourceeE > first, and he was thrown out exactly because he was the VMS expert.  >sL > Remember that this is the same office that talked about VMS in the past inJ > sensences such as "Tru64 now has all the clustering that many of you HAD when > you RAN VMS."o  E Yep, like I said, we're not immune.  Sometimes field management has a K differing perspective on their business priorities than does the VMS group.oJ Still, the track record is pretty good... I know of one Ambassador who nowH works directly for the VMS group due to such a difference in perception.I And I remember another case where a delegation of Ambassadors visited Ken I Olsen's office, who left a business meeting to receive the delegation, todH reverse (successfully) a layoff decision for an Ambassador that occurred7 while the said Ambassador was in Nashua at the meeting.o  H I would expect for the Sales/Sales Support folks that safety, as always,J will depend primarily on their sales performance - that's what we pay themL to do.  Similarly, for those of us in Consulting, bringing in revenue is theL safest place to be when the Sword of Damocles is hovering.  I'm fortunate inI that I've been slinging Fortran on VMS at a single customer site for over K six years and have been nearly continuously billable for well over the past-@ decade.  I'm always on the lookout for the next project, though.  L VMS Ambassador is a role that we play and an organization we work within andL build from our own talents and personalities.  That's pretty key, too - to aL large extent, the Ambassadors determine how the program is run (Sue just hasJ more votes than the rest of us)... it changes over time as the environmentL and the people in the program change.   Its sort of like being a member of aJ small professional society.  Its not a job title nor a recognized positionH within an HR organization or payroll system.  It is highly valued by theD OpenVMS group however, and was identified as one of the adopt-and-goL functions by the HP-Compaq merger team (i.e., no changes needed; approved toD continue according to prior plans) and recommended as an example and@ template for other HP organizations to form Ambassador programs.   --	 Mike Kiert$ HP Consulting & Integration Services Cincinnati, OH, USA. michael.kier@hp.coma   ------------------------------  % Date: Thu, 11 Jul 2002 15:06:31 -0400n' From: "Main, Kerry" <Kerry.Main@hp.com>   Subject: RE: OpenVMS AmbassadorsT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF402660829@kaoexc01.americas.cpqcorp.net>   JF -  G >>> In the case I know about, during one of the first rounds of layoffss at Digital,<<<  7 No one is saying mistakes were not made in the past.=20   H In fact, if the individual you are thinking about initials are PBL, then% I could not agree with you more !!=20t  G I knew him quite well as he also worked in Ottawa. He was definitely in  the role of VMS "guru" ..t   Regardsi  
 Kerry Main Senior Consultant  Hewlett-Packard Canada! Consulting & Integration Services, Voice: 613-592-4660  Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----7 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]=20  Sent: July 11, 2002 2:47 PMg To: Info-VAX@Mvb.Saic.Com   Subject: Re: OpenVMS Ambassadors     Mike Kier wrote:G > The folks that are Ambassadors are in the program because they are=20pH > competent and effective.  This tends to make them less likely to be=20 > targeted in the first place.  F In the case I know about, during one of the first rounds of layoffs atD Digital, it was the VMS guru who was a partner who was first told toH leave. And while he may have had "I am better than you" attitude (he wasH quite the guru), he was still THE person you wanted to service your siteB when you had a VMS problem. The Montreal office threw out its mostE valuable VMS resource first, and he was thrown out exactly because heo was the VMS expert.b  G Remember that this is the same office that talked about VMS in the past G in sensences such as "Tru64 now has all the clustering that many of youi HAD when you RAN VMS."   ------------------------------  # Date: Thu, 11 Jul 2002 19:19:08 GMTc1 From: "Terry C. Shannon" <terryshannon@attbi.com>   Subject: Re: OpenVMS Ambassadors. Message-ID: <MSkX8.152678$Uu2.34534@sccrnsc03>  @ "Sue Skonetski" <susan.skonetski@hp.nospam.com> wrote in message$ news:agk9tu$d3h$1@web1.cup.hp.com...K > Actually,  the Ambassadors have their own internal web site available fora# > anyone in the company to look at.r > G > Ambassadors programs are an hp supported program.  I say this becauseN theren- > is more than one Ambassadors program in hp.b >.J > Folks as well as you know me, do you think that I would not make it veryG > clear to everyone from Michael on down the value of the Ambassadors??o ComeJ > on, many have tried, many of failed to shut me up about the Ambassadors. >nF > And finally we have double digit percentage of new customers a year.G > Corporate policy does not allow me to be any more specific that this.  >i  I Relax, Sue... the whining, whinging, and griping and moaning clearly comeu from people whon  , A) Are not key customers or key influencers,   andt  H B) take a self-defeatist delight in showcasing their complete ignorance.  ! Par for the course in this venue.y   ------------------------------  % Date: Thu, 11 Jul 2002 15:44:53 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>a  Subject: Re: OpenVMS Ambassadors, Message-ID: <3D2DE023.17A2CC35@videotron.ca>   "Main, Kerry" wrote:J > In fact, if the individual you are thinking about initials are PBL, then$ > I could not agree with you more !! > I > I knew him quite well as he also worked in Ottawa. He was definitely in  > the role of VMS "guru" ..t  M His name has escaped me for the past few weeks. I have a picture of his face,tL his style of voice, but not his name !  When he was fired, he and some otherH ex-DECies formed a company that was the opposite of Digital (think of anM ______ watch) but that didn't seem to go very well and he was hired by one ofh3 the few remaining large VMS shops in montreal area.y   ------------------------------  % Date: Thu, 11 Jul 2002 15:53:09 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>e  Subject: Re: OpenVMS Ambassadors, Message-ID: <3D2DE212.742E33BA@videotron.ca>   "Terry C. Shannon" wrote:dK > Relax, Sue... the whining, whinging, and griping and moaning clearly comes > from people who   H Has there been whining, whinging , griping and moaning on the subject of/ Ambassadors ? I think folks only had QUESTIONS.l   ------------------------------    Date: 11 Jul 2002 16:21:37 -0400& From: fdc@columbia.edu (Frank da Cruz)  Subject: Re: OpenVMS Ambassadors1 Message-ID: <agkpch$4pu$1@watsol.cc.columbia.edu>a  K In article <3D2D9889.E2E9932D@vcu.edu>, Jim Agnew  <jpagnew@vcu.edu> wrote:oF : i'm glad someone did something for him...  he sounded like a regular : guy... : G The old school...  When CEOs cared about such things as their customersOK and employees and the long-term viability of their company.  Legacy notions2F now discredited and deprecated in the modern fast-paced marketplace inI which nobody matters but the stockholders.  Hmmm, wait, they don't matters	 either....   ------------------------------  # Date: Thu, 11 Jul 2002 20:11:18 GMT # From: "John Smith" <a@nonymous.com>e  Subject: Re: OpenVMS AmbassadorsH Message-ID: <GDlX8.12854$WJf1.9814@news01.bloor.is.net.cable.rogers.com>  < "Terry C. Shannon" <terryshannon@attbi.com> wrote in message( news:MSkX8.152678$Uu2.34534@sccrnsc03... > K > Relax, Sue... the whining, whinging, and griping and moaning clearly come  > from people who  >c. > A) Are not key customers or key influencers, >e > anda > J > B) take a self-defeatist delight in showcasing their complete ignorance. >w# > Par for the course in this venue.f     Terry,  K If you or HP don't take the attitude that EVERY customer is a key customer,lI then you both deserve to go down the tubes. Every customer has an opinionaI and is entitled to hold and share that opinion with whomever they please.sJ Every customer IS an influencer - if not for many systems within their ownB corporation or institution, then perhaps on the golf course with aK friend/acquaintance who has the authority to purchase 30 GS320 systems or 5oL DS10's or Storageworks products. If I don't treat my customers opinions with? respect or courtesy then I, too, deserve to go out of business.u  B Just because someone who is not from a very large customer makes aE suggestion or complains does not mean that it is ok to relegate theircL legitimate grievance to the trash heap by calling them whiners and ignorant.I it is exactly this sort of perception by DEC/Digital, Compaq, and perhaps K now HP, that has in part brought OpenVMS and Alpha to where they are today,n3 which is not where most of us would like to see it.   L Coming from a military background, you might understand the following - JustG because the majority of German and Japanese generals thought it was therC right thing to do to attack Poland in 1939 and Pearl Harbor in 1941rK respectively, doesn't mean it was the right decision. Similar arguments canhC be made about involvement in Vietnam too. Were *all* the people whoaL counseled against the foregoing whiners, complainers, and defeatists too andK needed to be silenced, temporarily or permanently? Similarly, the gaggle of E 'yes-men' surrounding Palmer, Capellas, and perhaps Carly too, do theaG fortunes of VMS no favors. Think back to your childhood where you first ? learned the lesson of the story of "The Emperor's New Clothes".-  J I am merely pointing out that debate allows the facts and viewpoints to beJ aired and considered. Dissent, and the right to express that are hallmarksE of a free society. You are free to express your opinion, as am I. OurpH observations may not always be correct, nor appreciated, but we have the right to make them.   J You may be making your observations from a position of 'inside' knowledge,J having much better and closer contacts to the levers of power than most ofK us have. We've all heard the words coming from Digital and Compaq, which insH effect say 'trust us', only to find whatever trust we have placed in theJ words to be mistaken. But to the great huddled masses of VMS customers whoK are not 'key customers or influencers' (and just how many of them are thereoE in fact?), all we can do is judge HP by its actions that are publiclyoL visible at a point-in-time, and keep in mind whatever they have done to thatJ point. We have been taught the hard lesson of naively placing our trust inI mere words. So far, IMHO, what we have seen from HP is not sufficient foreL the mistrust to dissipate. Perhaps in the fullness of time it will, but that0 is in the hands of HP and their actions, not us.  F I have much respect for you and your efforts and observations over theJ years. To see a comment such as the one you have written above saddens me.   John   ------------------------------  % Date: Thu, 11 Jul 2002 16:28:44 -0400n1 From: Michael Austin <maustin@firstdbasource.com>   Subject: Re: OpenVMS Ambassadors2 Message-ID: <3D2DEA7C.6DA85BA3@firstdbasource.com>   Jim Agnew wrote: > F > i'm glad someone did something for him...  he sounded like a regular > guy... >  > jimS >   F The stories that could be told on this subject are far too numerous toF count.  One of the most kind, unassuming and humble man you would everD want to meet. My encounter was in Dallas in '85-86 timeframe.  ThereA were several of the field engineers in the service center when hehE visited every office in the building.  We talked for 15-20 minutes on D what the MVII was "supposed" to look like -- (lighter, more portable with handles.)   Really neat person.f -- y Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163 7 Sr. Consultant            http://www.firstdbasource.comCE                           http://www.firstdbasource.com/donation.htmli/ 704-947-1089 (Office)     704-236-4377 (Mobile)-   ------------------------------    Date: 11 Jul 2002 15:40:51 -0600+ From: young_r@encompasserve.org (Rob Young)R  Subject: Re: OpenVMS Ambassadors3 Message-ID: <LOiEpuQF5axw@eisner.encompasserve.org>c  Z In article <agkpch$4pu$1@watsol.cc.columbia.edu>, fdc@columbia.edu (Frank da Cruz) writes:M > In article <3D2D9889.E2E9932D@vcu.edu>, Jim Agnew  <jpagnew@vcu.edu> wrote: H > : i'm glad someone did something for him...  he sounded like a regular
 > : guy... > : I > The old school...  When CEOs cared about such things as their customers9M > and employees and the long-term viability of their company.  Legacy notionsSH > now discredited and deprecated in the modern fast-paced marketplace inK > which nobody matters but the stockholders.  Hmmm, wait, they don't matter  > either...o    B 	Right.  And for a very long time the Japanese had cradle to grave@ 	employment but then economies caught up to them and guess what? 	They have layoffs too.h  > 	No longer like the brand of shirt you are wearing or a better: 	quality and cheaper shirt is more appealing?  Guess what?
 	Competition.m  C 	Stockholders?  The idea is they drive everything, which ties-in inwE 	the above two paragraphs.  Return on investment.  And oh by the way,iD 	fake profits are no longer acceptable.  Senate votes 96-0 to punishC 	CEOs (see today's Wall Street Journal).  Stock market swindles in cG 	1920s?  SEC was/is the outgrowth.  Sometimes it takes something broken4 	in order to fix it.   				Rob.   ------------------------------  # Date: Thu, 11 Jul 2002 23:43:04 GMT21 From: LESLIE@JRLVAX.HOUSTON.RR.COM (Jerry Leslie):  Subject: Re: OpenVMS Ambassadors; Message-ID: <cKoX8.75186$eF5.2420342@twister.austin.rr.com>n  ' Frank da Cruz (fdc@columbia.edu) wrote:aM : In article <3D2D9889.E2E9932D@vcu.edu>, Jim Agnew  <jpagnew@vcu.edu> wrote: H : : i'm glad someone did something for him...  he sounded like a regular
 : : guy... : : I : The old school...  When CEOs cared about such things as their customerssM : and employees and the long-term viability of their company.  Legacy notionseH : now discredited and deprecated in the modern fast-paced marketplace inK : which nobody matters but the stockholders.  Hmmm, wait, they don't mattero : either...s :i  " There are 1 or 2 such CEOs left...  L    http://sitesearch.washingtonpost.com/wp-dyn/articles/A3963-2001Dec19.html7    A CEO Who Lives by What's Right (washingtonpost.com):      By Mary McGrory(    Thursday, December 20, 2001; Page A03  G   "In this anxious hour of pink-slip dread, it is restoring to think ofg@    Aaron Feuerstein, a Massachusetts manufacturer who prizes his/    employees and risks profits on their behalf.s  A    The CEO of Malden Mills, located in Lawrence, the 23rd poorestoF    community in the country, stepped clear of the greedy stereotype ofI    his kind in 1995 when, just before Christmas, his factory burned down.dD    Rather than taking the insurance money and retiring or moving theI    plant to some Third World country, he promptly announced that he wouldiG    rebuild. He gave bonuses to the help and paid them while they waitedu    for the factory reopening.e  D    Last Monday, this paragon of corporate virtue held a rally at theA    plant he inherited from his father. The idea was to kick off ayG    campaign for Malden Mills's special product, Polartec, a light, warmhC    fabric that is keeping U.S. Marines cozy in the grinding cold ofcG    Afghanistan. Sen. John Kerry hailed Malden Mills as a mill with soulnC    and a mill with heart. Rep. Marty Meehan, the local congressman,nH    saluted Feuerstein for sticking it out with his workers, and sticking    it out in Lawrence.  D    Feuerstein has not had all the good fortune he may deserve. SalesD    dipped, and he recently filed for bankruptcy under Chapter 11 andF    negotiated a $25 million bank loan. Feuerstein would have liked theI    money without the chapter -- "I hate to put any stain on our beautifulsF    name" -- but he told cheering workers that together they would win.  E    Columnist Mark Shields was the first to make the striking contrastnG    between Feuerstein and today's most celebrated bankruptcy case, thatfG    of Enron, the monstrous Texas energy outfit. Most of its 21,000 lostnD    jobs. For 11,000, it was a lump of coal, the loss of life savingsG    invested in Enron stock. Enron employees were urged to buy the stockhG    with their retirement funds, their 401(k)s. When Enron started goingAI    south in October, however, the employees were forbidden to sell. Enron A    CEO Kenneth Lay and his fellow executives were exempt from thes5    lockdown and sold, often at tremendous profits..."d  2 --Jerry Leslie   (my opinions are strictly my own)9   Note: leslie@jrlvax.houston.rr.com is invalid for emailn   ------------------------------  # Date: Fri, 12 Jul 2002 02:55:55 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>i  Subject: Re: OpenVMS Ambassadors' Message-ID: <3D2E4985.FD8E273E@fsi.net>a   Sue Skonetski wrote: > [snip]F > And finally we have double digit percentage of new customers a year.G > Corporate policy does not allow me to be any more specific that this.n  B When Corporate learns to get out of its own way, you'll be able toA boldly say EXACTLY what those percentages are, and do it proudly!p   You deserve it!   G What kind of moron doesn't understand the importantance of blowing youroF own corporate horn??!! ...especially now when corporate f**kups are atA an all-time record high and still rising with no end in sight??!!m  F Haven't they ever heard of "stockholders"??!! Y'know, those people who? invest in the company and expect a return on their investment?    A What happens when a company announces increased sales of its mosta> lucrative product? (Hint: the stock price does *NOT* go down!)  = I gotta shutup now - my blood pressure is up to 160 over 125.r   -- s David J. Dachteran dba DJE Systemsh http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t   ------------------------------   Date: 12 Jul 2002 01:53:36 GMT2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>$ Subject: Re: OpenVMS Polls are back!+ Message-ID: <aglcr00a1d@enews2.newsguy.com>m  @ In comp.sys.dec David J. Dachtera <djesys.nospam@fsi.net> wrote:? > o Should HP (or OpenVMS's current owner) revive OpenVMS-IA32?o  L Would you mind explaining *WHY* this makes any sort of sense from a businessG standpoint?  I for one would much rather see development money spent on A porting to iA64 and on improving OpenVMS than on porting to iA32.0  C Now what I'd really like to see is an affordable iA64-based OpenVMSb< Workstation!  Something along the lines of the Sunblade-100.   		Zane   ------------------------------  # Date: Fri, 12 Jul 2002 03:15:04 GMTe1 From: "David J. Dachtera" <djesys.nospam@fsi.net> $ Subject: Re: OpenVMS Polls are back!' Message-ID: <3D2E4E03.1E7088CF@fsi.net>i   "Zane H. Healy" wrote: > B > In comp.sys.dec David J. Dachtera <djesys.nospam@fsi.net> wrote:A > > o Should HP (or OpenVMS's current owner) revive OpenVMS-IA32?i > N > Would you mind explaining *WHY* this makes any sort of sense from a business
 > standpoint?a  3 Bloody hell! I *KNEW* that was gonna come up AGAIN!6  F I won't pursue this as a thread, but I will ask the questions one more time:-  C 1. How many IA32 servers are currently in service world-wide today?1  ( 2. How many of them are running OpenVMS?  F Are there any other questions? (Don't bother replying, because I won'tG pursue it. Experience has shown that I'm the only person in the world - C or at least in these ng's - who understands this in any appreciablei7 depth, and I will not attempt to explain it yet again.)e   --   David J. Dachterao dba DJE Systemsi http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t   ------------------------------    Date: 11 Jul 2002 23:08:42 -06009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow)l$ Subject: Re: OpenVMS Polls are back!3 Message-ID: <++3LMg6xSs89@eisner.encompasserve.org>o  [ In article <3D2E4E03.1E7088CF@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:e > "Zane H. Healy" wrote: >> nC >> In comp.sys.dec David J. Dachtera <djesys.nospam@fsi.net> wrote:AB >> > o Should HP (or OpenVMS's current owner) revive OpenVMS-IA32? >> uO >> Would you mind explaining *WHY* this makes any sort of sense from a business: >> standpoint? > 5 > Bloody hell! I *KNEW* that was gonna come up AGAIN!  > H > I won't pursue this as a thread, but I will ask the questions one more > time:1 > E > 1. How many IA32 servers are currently in service world-wide today?t > * > 2. How many of them are running OpenVMS?  C 3. What percentage of IA64 systems will be shipping unencumbered bytH Microsoft license management hardware by the time VMS is ready to run on that platform?  K         This is a country which stands tallest in troubled times, a country K         that clings to fundamental principles, cherishes its constitutionalrI         heritage, and rejects simple solutions that compromise the values H         that lie at the roots of our democratic system. -- Supreme Court(         Justice Thurgood Marshall, 1972   1 	26-October, 2001: A day that will live in infamyg4 	Support Freedom: http://www.indefenseoffreedom.org/   ------------------------------    Date: 11 Jul 2002 16:35:13 -0700& From: chessmaster1010@hotmail.com (JG)& Subject: Re: PURGE   version set to ;1< Message-ID: <dd3f0cb7.0207111535.f7ec5f5@posting.google.com>  a JOUKJ <joukj@hrem.stm.tudelft.nl> wrote in message news:<3D2BD516.9020500@hrem.stm.tudelft.nl>...: > 5 > Try this (replace the *.* by the wild card you use)r > 
 > $ PURGE *.*r > $ RENAME *.* ;1c  A I'd recommend keeping a minimum of two versions of the files. For  example:   $ PURGE *.* /KEEP=2! $ RENAME *.*;-0 ;1 $ RENAME *.*; ;l  > The advantage of this is that the version limit of the file isE maintained. If you PURGE to one version and then RENAME the file getsu/ reset to the directory's default version limit.   F A file's version limit is a unique attribute because it applies to allC versions of a file name in a given directory.  The version limit isdD maintained as long as one version of the file name exists.  But whenF the only version of a file is RENAMEd RMS removes the entire directoryF entry and re-enters it, even though in this case RMS could just update the version number in place.  D Hoff, if you are reading this, IMHO this is an RMS bug.  Can you ask> the RMS guys to fix this?  TIA. (no online support tool here).  B Using a command procedure to change just the version number of allF versions of a file (such as Jim's RENUMBER.COM) is safe, but it can beA slow if there are big gaps in the list of version numbers - which-A could happen if the RENUMBER command procedure is interrupted ande later restarted.  A If the purpose of all this is to create an automatic procedure tocE prevent the version number of automatically created files from rising<E to the ;32767 limit (at my site we have some batch job log files thathF are created every minute so this happens weekly) then all of the aboveC techniques suffer from a race condition - a new version of the filet@ created while the renaming is in progress may get a high version number.c  E The technique of RENAMEing all versions of a file to a temporary fileeD name and then RENAMEing them back will also reset the version limit,F although in this case it is a feature, not a bug.  But the big problemD here is the race condition - if a new version is created during thisE process it won't be the top version when the second RENAME completes.T   ------------------------------  % Date: Thu, 11 Jul 2002 09:41:54 -04007 From: norm.raphael@metso.com: Subject: Re: Quality control problems in VMS Engineering ?? Message-ID: <OFEAF8F11D.4016E6C9-ON85256BF3.004B212D@metso.com>e  H As an aside, why is it not suggested/recommended that those who have/had installed this6 ECO back it out if the cure is worse than the disease?        J clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) on 07/11/2002 09:29:29 AMr  E Please respond to clubley@remove_me.eisner.decus.org-Earth.UFP (Simonn        Clubley)t   To:    Info-VAX@Mvb.Saic.Com cc:t9 Subject:    Quality control problems in VMS Engineering ?     K I am concerned that a VMS patch was released which appears to have not beensI tested properly. Unlike the XFC issues, this is a case of a basic commandrE just not working at all. This time, it was a PPPD patch, with no data'7 integrity issues. Next time, it might be a RMS patch...h  5 I would like to politely ask the following questions:e  < Are you having quality control problems in VMS Engineering ?  6 How did this _ever_ get past your testing procedures ?  G What is VMS Engineering doing about making sure that this kind of thingn doesn't happen again ?   Announcement below:y   |DE |  TITLE: OpenVMS VMS721_PPPD-V0200 PPPDriver ALPHA 7.2-1 ECO Summarya |A" |  New Kit Date:       04-JUN-2002" |  Modification Date:  09-JUL-20026 |  Modification Type:  Kit placed on engineering hold. |t |  OpenVMS Remedial Kit  |  Hold Notification |i |o |  Date: 09-JUL-2002 |e1 |  Kit Name: DEC-AXPVMS-VMS721_PPPD-V0200--4.PCSIc |  Release Date: 04-JUN-2002 |  |1 |  PROBLEM STATEMENT:s | J |  After the VMS721_PPPD-V0200 kit is installed, the disconnect command inG |  the PPD utility no longer works.  Users are then left with no way too& |  force a line to disconnect cleanly. |s |o |  PROBLEM SYMPTOM:l |eH |  The PPPD = DISCONNECT TTA0 command fails to disconnect and returns an |  error like this:s |n  |  SYSTEM> PPPD DISCONNECT TTA0:8 |  %PPPD-E-PPPCONNECTERR, error connecting to PPP device0 |  %SYSTEM-W-NOSUCHDEV, no such device available? |  %PPPD-F-ABORT, fatal error encountered; operation terminatede |l |  |  WORKAROUND: |o |  None. |i |  |  ALTERNATIVE KIT:n |aE |  There is no alternative kit to install.  Engineering is evaluatingfF |  this issue.  Depending on results of that evaluation, this kit willG |  be removed from hold or a new kit issued to replace the problem kit.  | H |  *********************************************************************   Simon.   --; Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP.+ Microsoft: The Lada of the computing world.l   ------------------------------  # Date: Thu, 11 Jul 2002 19:39:53 GMTt1 From: Forrest Kenney <Forrest.Kenney@hp.com.doom>o: Subject: Re: Quality control problems in VMS Engineering ?+ Message-ID: <3D2DDCF1.62E18A10@hp.com.doom>   N     The suggestion to suggests backing  it out was being conservative.  It was made before weN understood exactly what the new bug was.  Even now knowing what the bug is and
 with a fixO in the works I don't think that is a bad way to go.  If the site has one of the  bugs the patch kitB fixed they need to decide if keeping it is better for their needs.  M     There was a slight mistake in what Sue had.  The patch kit fixed a couplen of problems themN one  that cause the problem was for system with more than 10 terminal ports on the sameM controller that could be using PPP.  The code would match TTA1 against TTA11.-   Forrest  OpenVMS development0   ------------------------------  % Date: Thu, 11 Jul 2002 20:45:30 -0400jK From: "Encompass - HP Enterprise Technology Symposium" <KilleenJ@toast.net>o& Subject: Re: Quick Poll - two sessions/ Message-ID: <uis9m0rchvv2fe@corp.supernews.com>a  L We made the decision today to definitely go with #3.  It is unlikely we willI do #2. There will be something on CDSA - clearly any session on CDSA willh need: to be better explained.  David Cathey will be giving #3...   --   Jeff Killeen   All Info: http://www.Killeen.ccn  ? ---------------------------------------------------------------   K "Encompass - HP Enterprise Technology Symposium" <KilleenJ@toast.net> wrotek4 in message news:uio9gsogenp0ac@corp.supernews.com...J > 1) If you had to choose between session #1 or session #2 which would youI > pick and why? (Please assume that session #3 is being offered no matter  > what ) >t6 > 2) Would you attend any of these 3 sessions and why? > - > Thanks in advance (no HP replies please)...n >m >  > Session #1 >iJ > Developing Secure Applications on OpenVMS Using the Common Data Security > Architecture (CDSA)0 >rH > This session provides details on the Common Data Security ArchitectureD > (CDSA) including installing, configuring and administering CDSA on OpenVMS.J > Since CDSA is just being introduced on OpenVMS, this session provides anJ > overview of CDSA and it's components, how they fit together and how CDSA isF > related to SSL. Just having CDSA doesn't help much if you don't haveI > applications using it, so we discuss how to build a CDSA application onh
 > OpenVMS. >  > Session#2e >n8 > OpenSSL for OpenVMS: Application Development and ToolsL > This technical session explains the components and tools available as partD > of the OpenSSL port to OpenVMS. The session covers the various SSL	 protocolsiJ > available and their use in application development that utilize OpenSSL.A > Topics covered include an SSL application example, performance,a certificatesF > and other issues associated with developing along with deploying SSL > applications.y >d > Session#3t > > > This session covers using OpenSSL to secure and encrypt data communicationsK > over the Internet or other open network. This is an introductory session,nJ > but will cover creating and generating Digital Certificates, getting andK > building the OpenSSL libraries from source code (under Unix and OpenVMS),kK > basic programming using the OpenSSL libraries in C, and a working exampletJ > that is portable between Unix and OpenVMS.Experience with either Unix orH > OpenVMS, and familiarity with the C programming language is suggested. Those(H > without programming experience may also benefit from the discussion of2 > applications which can or should use encryption. >f > -- >i > Jeff Killeen >n! > All Info: http://www.Killeen.cc> >iA > ---------------------------------------------------------------i >f >h   ------------------------------  # Date: Fri, 12 Jul 2002 02:37:54 GMTW1 From: "David J. Dachtera" <djesys.nospam@fsi.net>s Subject: Re: RECALL suggestion' Message-ID: <3D2E454D.6D9D97CF@fsi.net>o   JF Mezei wrote:e >  > "David J. Dachtera" wrote:J > > O.k. I gotta look dumb here - can someone tell me what is the value ofJ > > this stack? I've seen multiple people express that interest. Why wouldG > > you need to track where you've been? If you don't know where you're-9 > > going, what's the point of trying to navigate at all?t > J > suppose you are doing much of your work in one directory. You then spawnG > another process so you can rummage through system directories to find P > something. You find it, log off to return to your original directory, but now,Q > you've forgotten in exactly which directory that file you had found really was.,  @ Reflection. SmartTerm, KEA, DECterm, etc.: scroll back and look.  N > OR: you don't spawn and go rummage and once you've found your file, you need' > to return to your original directory.h  H Don't remember where you were? ...and my wife thinks *MY* memory is bad!  N > However, the solution in 7.3 which allows RECALL/ALL string would be perfect > since you could do:  > L > RECALL/ALL CD  and that would list all your prevous CD commands, which youE > could also include in a default recall buffer loaded at login time.e  B Well, here's a slightly difference twist if you're willing to codeE something up in your favorite language: develop a "simple" CD commandnH program that does the appropriate calls to change directory and redefineA SYS$DISK (equiv. to DCL SET DEFAULT), but keeps a history in, forrC example, SYS$LOGIN:CD_HISTORY.DAT (perhaps seek a logical name likegE CD_HISTORY, and use that filespec. as the default if no translation).u  D Then, CD/RECALL could be implemented to display the history, perhapsG using CD/HIST/NUM=x to display the x most recent paths from the historye* file, just like another poster's DCL proc.  H Dunno. Personally, I don't recall not being to remember where I was, but? then I don't have a habit of using SET DEFAULT to examine othere@ directories, rather I state the complete path spec. of the otherC directory for SEARCH, DIRECTORY or whatever and make liberal use ofc) command line editing via the cursor keys.o  A To find things, I use a DEFALL.COM procedure to DEFINE a /PROCESSbC logical name, ALL_DISKS which is a search list including all of thevE RVN-1s MOUNTed to the system. Then, to find something specific, I usewH DIR ALL_DISKS:[000000...]filespec, or use that path spec. with SEARCH orH whatever (usually SEARCH with /NOWARN and /WIN=0, then cut-and-paste the% path and/or file spec.(s) as needed).v   YMMV, of course.   --   David J. Dachtera  dba DJE Systemsu http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/r   ------------------------------  % Date: Thu, 11 Jul 2002 13:52:24 -07001& From: Tom Crabtree <tccrab@sunset.net># Subject: Re: Used Alpha's and Vax's * Message-ID: <3D2DF008.56A5868F@sunset.net>   Jim:  E Call David Turner at Island Computer Company, http://www.islandco.come   You can't go wrong.e   TomC   Jim Rizzolo wrote:  B > I am trying to locate used OpenVMS systems (Alpha and VAX). DoesC > anyone know of any websites where I can find sellers?  Thank you.l   ------------------------------  # Date: Thu, 11 Jul 2002 22:56:10 GMT 4 From: "Andy Bustamante" <a_c_bustamante@bigfoot.com># Subject: Re: Used Alpha's and Vax'suB Message-ID: <e2oX8.6644$Kx3.3580@newsread1.prod.itd.earthlink.net>  : Sunny San Diego CA.  The two 3100's are 3100-80 & 3100-20.   --   Andy Bustamanteh( remove the ascii-95's to reply by e-mail      ? "Robert Deininger" <rdeininger@mindspring.com> wrote in messageiD news:rdeininger-1007022229390001@1cust58.tnt3.nashua.nh.da.uu.net...H > In article <I23X8.12668$A43.1311999@newsread2.prod.itd.earthlink.net>,7 > "Andy Bustamante" <a_c_bustamante@bigfoot.com> wrote:  >rH > >We will have several VAX 3100's available in the next few months, and have a7 > >VAX 7000-730 (3 CPU) we're retiring.  Any interrest?. >/ > Located where? >-   ------------------------------    Date: 11 Jul 2002 12:54:38 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen):& Subject: Re: VAX Scan on OpenVMS Alpha3 Message-ID: <3lSE1pDkj29Y@eisner.encompasserve.org>   L > AlphaScan can use the Language Sensitive Editor (LSE) and with Source CodeC > Analyzer (SCA) for further aid in software development. AlphaScan M > implementation is based on the lexical and semantic modules of the VAX Scan M > compiler, which generate an intermediate representation of the SCAN modulesSK > in ANSI C code. Therefore AlphaScan requires an installed DEC C compiler.eG > AlphaScan modules can be linked with modules written in other OpenVMSlN > languages to produce an executable image that can be executed by the OpenVMS > RUN command.  E Based on that, it seems to me one does not get the debugging featureslF available for VAX SCAN.  I have found those debugging features crucial; to developing moderately sized (12,000 line) Scan programs.p   ------------------------------  % Date: Thu, 11 Jul 2002 11:09:32 -0700n# From: "Tom Linden" <tom@kednos.com>a& Subject: RE: VAX Scan on OpenVMS Alpha9 Message-ID: <CIEJLCMNHNNDLLOOGNJIIEHPFFAA.tom@kednos.com>h  A I looked into this some months ago when the subject first came upIC and concluded at that time, that it was a C language interpreter ofaB the VCG n-tuples and Symbol Table.  So you will still need to keepH your VAX around and use the interpreter/translator for Alpha production.   >-----Original Message-----E5 >From: Larry Kilgallen [mailto:Kilgallen@SpamCop.net]l' >Sent: Thursday, July 11, 2002 11:55 AMe >To: Info-VAX@Mvb.Saic.Com' >Subject: Re: VAX Scan on OpenVMS Alphap >n > A >> AlphaScan can use the Language Sensitive Editor (LSE) and withw >Source CodeD >> Analyzer (SCA) for further aid in software development. AlphaScanA >> implementation is based on the lexical and semantic modules of0
 >the VAX ScanmA >> compiler, which generate an intermediate representation of the:
 >SCAN modulesaL >> in ANSI C code. Therefore AlphaScan requires an installed DEC C compiler.H >> AlphaScan modules can be linked with modules written in other OpenVMSC >> languages to produce an executable image that can be executed bya >the OpenVMS >> RUN command.w >eF >Based on that, it seems to me one does not get the debugging featuresG >available for VAX SCAN.  I have found those debugging features crucialm< >to developing moderately sized (12,000 line) Scan programs. >s >---' >Incoming mail is certified Virus Free.i; >Checked by AVG anti-virus system (http://www.grisoft.com).1A >Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002e >d --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002   ------------------------------  # Date: Thu, 11 Jul 2002 17:39:41 GMTh# From: "John Smith" <a@nonymous.com> K Subject: Re: VMS vs. MVS (was: Re: McKinley tops SpecFP AND SpecInt charts)tH Message-ID: <xpjX8.10549$WJf1.5077@news01.bloor.is.net.cable.rogers.com>  D "Bradford J. Hamilton" <sy18889@rabmbit.famrp.cosm> wrote in message news:yqdhg20lWFRu@rabbit...c
 > Hi John, >hL > Do you have access to Google?  If so, the following c.o.v. post shows that atH > least *one* employee of HP has an idea of how to contrast VMS vs. MVS:      Thank you for pointing that out.  L No offense to you or to Keith, but if HP is not going to market VMS to *new*G customers, then having only one employee who know this well is probablyhK enough. If that statement makes anyone at HP wince, it's probably not a badn thing to have said.s   ------------------------------  # Date: Thu, 11 Jul 2002 18:22:02 GMTA( From: Don Sykes <annonymous@pacbell.net>8 Subject: Re: What does UCX 6.2 SMTP intermittently fail?+ Message-ID: <3D2DCD19.B2C3D84D@pacbell.net>*   Lawrence Bleau wrote:f > O > Hi, I'm helping a colleague.  He has a VAXstation 4000-90 running OpenVMS VAXoN > 6.2.  I just installed UCX 4.2 and put on the latest, greatest patch - ECO 55 > (yes, I rebooted).  Here's the UCX SHO VERS output:u > @ >   Digital TCP/IP Services for OpenVMS VAX Version V4.2 - ECO 50 >   on a VAXstation 4000-90 running OpenVMS V6.2 > O > I configured it okay, and we can ftp and telnet both ways, as well as receiveeN > email.  Sending email is problematic, though.  When sent to one of the otherQ > systems I administer, it works, but when sent to another one, it fails.  Here'sI0 > the contents of the file UCX$SMTP_LOGFILE.LOG: > F > %%%%%%%%%%%%                   10-JUL-2002 15:49:23.80  %%%%%%%%%%%% > P > %UCX-I-SMTP_LOGSUC, Using log file SYS$SPECIFIC:[UCX_SMTP]UCX$SMTP_LOGFILE.LOG > F > %%%%%%%%%%%%                   10-JUL-2002 15:49:24.33  %%%%%%%%%%%% > F > %UCX-I-SMTP_SYMBRUN, Symbiont is running the queue UCX$SMTP_SURYA_01J > smtp_sender_close sclose R0 status = -1, errno = 65535, vaxc$errno = 316J > smtp_sender_close sclose R0 status = -1, errno = 65535, vaxc$errno = 316J > smtp_sender_close sclose R0 status = -1, errno = 65535, vaxc$errno = 316J > smtp_sender_close sclose R0 status = -1, errno = 65535, vaxc$errno = 316 > N > Outgoing email failed 4 times, so I'm assumming that is the reason for the 4= > error messages.  If 316 is a VMS status code, then it meansi > ' > %SYSTEM-F-IVCHAN, invalid I/O channell > Q > Any idea what is happenning and how to go about debugging this?  And why shouldeQ > it work to one system (sampex.umd.edu) but not another (umtof.umd.edu), both ofbO > which are on the same Ethernet cable with the sending system (surya.umd.edu)?   J I'm sure other's know more, but I'd check the SMTP characteristics on both carefully, via 	UCX> show config SMTP 	UCX> show serv SMTP/full7K If that doesn't reveal problematic differences, I'd check the UCX install &E6 release notes for suggested system parameter settings.     -- D   Have VMS. Will Travel. Wire Paladin (@alphase.com)c
 San Franciscoh   ------------------------------  % Date: Fri, 12 Jul 2002 00:39:13 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>d Subject: Worldcom soap opera, Message-ID: <3D2E5D69.819F82EE@videotron.ca>  P Not on topic, but interesting reading nevertheless, considering currrent events:  < Friends-turned-foes complicate Buffett's foray into telecom=   Kevin Maney USA TODAY     J The telecommunications industry truly ought to be made into a soap opera. F Maybe we could call it General Telecom. No? How about As the WorldCom  Turns?   The Young and the Bankrupt?     J Monday, super investor Warren Buffett jolted the nearly prostrate telecom = industry by leading an investment of $500 million in Level 3 gH Communications. Telecom companies now are so reviled, and Buffett is so H worshiped, the investment is like the prom queen deciding to dance with > the greasy kid who broke both legs of the star quarterback by I accidentally running him over in the school parking lot before the first 7 game.-  J Beyond the surface, the potential intrigue could get fascinating. This is H where the soap opera aspects come in. Buffett's investment could set in G motion a complex web of relationships and -- if you play it all out in  J just the right way -- put Bill Gates  in charge of every fiber-optic line  in the USA.R    H This stuff is layered on top of Monday's congressional hearings, during I which new WorldCom management threw tomatoes at old WorldCom management, iE which liked Level 3's founder and CEO, James Crowe, about as much as n homeowners like termites.s     Let's start with Buffett.   G Buffett has known Crowe for a long time. They have mutual ties through  I Walter Scott, CEO of construction giant Peter Kiewit Sons'. Scott is the NH founding investor in Level 3. Scott and Buffett are Omaha billionaires, H which is a small club, and longtime friends. Buffett's offices are on a F floor of Kiewit's Omaha headquarters. When Level 3 started, it leased  space there, too.     F A few months ago, Crowe says, the three well-acquainted men -- Crowe, F Scott and Buffett -- met to talk about opportunities in telecom. They D figured there must be opportunities now that things are so bad that 7 entire telecom companies will probably be sold on eBay.*    H ''We asked Mr. Buffett if he'd be interested in investing in Level 3,'' J Crowe says. Buffett said yes, and pulled in two partners. But why now? Do F Buffett and Crowe think telecom has bottomed out? ''All of us need to J make statements about the future with great humility,'' Crowe says. ''But H signs say it's not going to get much better soon, but it's not going to  get any worse.''    B What will Crowe do with the $500 million? He's NOT looking to buy G fiber-optic networks on the cheap. Crowe's priority is to buy customer dJ bases, which means buying companies or pieces of companies that serve end I users. Level 3 would then move that traffic on its long-haul fiber-optic gG network to make use of Level 3's excess capacity. Crowe didn't say so, SF but if WorldCom spirals into insolvency, pieces of WorldCom might fit ' perfectly into Crowe's shopping basket.a    0 This is where the tangled relationships come in.    G In 1989, Scott funded Crowe's first company, MFS Communications, which MJ provided telephone connections to businesses. In 1995, Buffett, Scott and H some friends were on a retreat in Ireland. They invited Gates, who told I the others about the Internet. Once back in Omaha, Scott told Crowe that sC MFS needed to own the more modern networks that carry the Internet.i    A MFS decided to buy Internet carrier UUNet, run by John Sidgmore. iD Microsoft owned 14.7% of UUNet. Gates told Crowe he'd sell if Crowe J promised to keep Sidgmore. Crowe agreed. The deal was done. Sidgmore owed  Gates a favor.  F Only months later, WorldCom, led by Bernie Ebbers, bought MFS for $14 2 billion, making Crowe, Scott and Sidgmore wealthy.  J Three weeks after the deal closed, Crowe, not wanting to work for Ebbers, D abruptly quit WorldCom and went back to Omaha. Sidgmore stayed, and C Sidgmore and WorldCom's recently fired CFO, Scott Sullivan, became   Ebbers' deputy dealmakers.    I Crowe joined the board of a new fiber-based carrier, Joe Nacchio's Qwest dG Communications. Not long after, Crowe decided the Internet was still a SH huge opportunity. He quit Qwest's board, got $3 billion in funding from B Scott's Kiewit, and started Level 3, a Qwest competitor. Nacchio, & understandably, was teed off at Crowe.    J To start Level 3, Crowe recruited 18 of his top former MFS executives out / of WorldCom. Ebbers got teed off at Crowe, too.i   With me so far?o    G A couple of years ago, Sidgmore cut a deal for WorldCom to buy Nextel,  A but Ebbers nixed the deal an hour before it was to close. Gates' lH Microsoft owned about 5% of Nextel. Sidgmore was mad at Ebbers and quit B his day-to-day job at WorldCom. Gates was probably mad at Ebbers,  too.  I Then last month, Sullivan admitted to improperly accounting for WorldCom lE expenses. Sidgmore took charge of WorldCom, fired Sullivan, and took vF shots at Ebbers for messing up WorldCom, though Sidgmore told me he'd  still call Ebbers ''a friend.''i    @ Qwest is crashing, too, and Nacchio was punted from his CEO job.    G So Crowe has $500 million from investors led by Buffett, who is one of  0 Gates' closest friends. Now for the speculation:    G Depending on how things go for WorldCom, perhaps Sidgmore, as a return tH favor to Gates and a snub of Ebbers, would sell part or all of WorldCom E to Ebbers' enemy Crowe, who runs the company backed by Gates' friend   Buffett.    J With that, Crowe and Sidgmore would both kick Ebbers in the heinie. Then, D with the added cash flow from WorldCom customers, Crowe could buy a : distressed Qwest, thereby shooting a raspberry at Nacchio.      J The combined LevelWorldQwest could drive AT&T into insolvency, then Crowe H could buy that company, too. The Omaha boys -- Crowe, Scott and Buffett > -- would own a near-monopoly in U.S. long-haul fiber networks.      J Gates could approach Buffett to buy it all. Gates would own the Internet. > Gates could unilaterally rename the telecom soap opera All My  Fibers.-    
 Checkmate.   ------------------------------   End of INFO-VAX 2002.380 ************************