1 INFO-VAX	Mon, 09 Jul 2001	Volume 2001 : Issue 378       Contents:1 Alpha fiasco looses $30M deal to IBM in Singapore 5 Re: Alpha fiasco looses $30M deal to IBM in Singapore 5 Re: Alpha fiasco looses $30M deal to IBM in Singapore 5 RE: Alpha fiasco looses $30M deal to IBM in Singapore * Re: Capellas admits move anti-competitive?* Re: Capellas admits move anti-competitive?* Re: Capellas admits move anti-competitive?G Re: Cluster comms over fc, was Re: Compaq's Alpha design team for sale? D Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window?D RE: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window?B Re: Computer Rooms and big UPSes: I need some electrical advice...B Re: Computer Rooms and big UPSes: I need some electrical advice...B Re: Computer Rooms and big UPSes: I need some electrical advice.... Re: CSWS/Apache userdir and SSI config problem! Re: DEC Notes available, someone? ! Re: DEC Notes available, someone?  Re: DECWORLD 2001 Byte article Re: DECWORLD 2001 Byte article% Driver SQL server database connectoin  Re: DSL for OpenVMS ) emulation of VMS privilege levels on IA64 - Re: emulation of VMS privilege levels on IA64  Re: Experience with EMC storage 1 Re: exploitable buffer overflows in VMS possible? 1 Re: exploitable buffer overflows in VMS possible? 1 Re: exploitable buffer overflows in VMS possible? 1 Re: exploitable buffer overflows in VMS possible? 1 Re: exploitable buffer overflows in VMS possible? 1 Re: exploitable buffer overflows in VMS possible? 1 Re: exploitable buffer overflows in VMS possible?  Re: ftp script Re: FUD  Re: FUD  Re: FUD  Re: FUD   Re: Full port of VMS to Itanium. RE: IA64 Rocks My World  Re: IA64 Rocks My World  Re: IA64 Rocks My World % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance  Re: Network Printers$ new products from Twobyfour Software Re: Nodenames in cluster Re: ods5 and decc$from_vms OpenVMS and IP Storage- Re: Porting VMS (was Itanium, non-issue, ...) - Re: Porting VMS (was Itanium, non-issue, ...) & Problem with TCPIP 5.1 on VAX/OVMS 7.3
 Re: Rdb troll 
 Re: Rdb troll 1 Re: Some thoughts on the recent turn of events... 1 Re: Some thoughts on the recent turn of events...  Re: The Alpha/IA64 Hybrid . Re: the tcp node name versus the vms node name. Re: the tcp node name versus the vms node name8 VBN 397: Invalid bucket address sample in bucket header.' Re: VMS 7.3/Alpha boot bugcheck problem ' RE: VMS 7.3/Alpha boot bugcheck problem ; Re: Wailing and moaning.... (was: Compilers go to Intel...) F Re: Wailing and moaning.... (was: Some thoughts on the recent turn...)F Re: Wailing and moaning.... (was: Some thoughts on the recent turn...)F Re: Wailing and moaning.... (was: Some thoughts on the recent turn...)F Re: Wailing and moaning.... (was: Some thoughts on the recent turn...)F Re: Wailing and moaning.... (was: Some thoughts on the recent turn...)# Re: What about performance issues?? # Re: What about performance issues?? # RE: What about performance issues?? $ Re: Write record to accounting file?) Re: Writing to OPA0: from a device driver ) Re: Writing to OPA0: from a device driver   F ----------------------------------------------------------------------  $ Date: Mon, 9 Jul 2001 06:55:58 -0400) From: "Neil Rieck" <n.rieck@sympatico.ca> : Subject: Alpha fiasco looses $30M deal to IBM in Singapore: Message-ID: <I0g27.5585$gb6.1031322@news20.bellglobal.com>  H Compaq looses $30M deal to IBM (in Singapore) because of Alpha's demise?  ' http://www.theinquirer.net/09070107.htm   H If this fact is true and more deals fall through, then Capellas could goC down in flames at the next shareholder's meeting (but with a golden K parachute the size of the Alpha Microprocessor Division's annual budget). I G still don't understand why Compaq didn't decide to support/develop both J Alpha and IA-64 (eg. HP: PA-RISC and IA-xx, IBM: PowerPC and IA-xx, etc.).  I Mikey: It's not too late to change your mind about killing Alpha! You can F save face by saying that this is the recommendation of the newly hired marketing consultants.    
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/ @ http://www3.sympatico.ca/n.rieck/links/compaq_memorial_site.html   ------------------------------  # Date: Mon, 09 Jul 2001 12:14:42 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) > Subject: Re: Alpha fiasco looses $30M deal to IBM in Singapore0 Message-ID: <009FEBD7.AB5FDC88@SendSpamHere.ORG>  f In article <I0g27.5585$gb6.1031322@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:I >Compaq looses $30M deal to IBM (in Singapore) because of Alpha's demise?  > ( >http://www.theinquirer.net/09070107.htm > I >If this fact is true and more deals fall through, then Capellas could go D >down in flames at the next shareholder's meeting (but with a goldenL >parachute the size of the Alpha Microprocessor Division's annual budget). IH >still don't understand why Compaq didn't decide to support/develop bothK >Alpha and IA-64 (eg. HP: PA-RISC and IA-xx, IBM: PowerPC and IA-xx, etc.).   J I am aware of one company that has also said "enough!"  They're working to= get off of VMS ASAP now that this debacle is front page news.   I Obviously Compaq can't see the forest through the trees.  The money is in J the software not the hardware.  However, killing off the Alpha places the J longevity of its former supported software in peril in the eyes of a great6 many of its customers.  We all see it, why can't they?    J >Mikey: It's not too late to change your mind about killing Alpha! You canG >save face by saying that this is the recommendation of the newly hired  >marketing consultants.   I Don't count on it.  The influx of cash will appease the shareholders over I the short term.  In the long term, however, I see many brokerage accounts 5 swelling from the commissions on Compaq share sales.     --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              J   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes    ------------------------------   Date: 9 Jul 2001 08:46:52 -0500 9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) > Subject: Re: Alpha fiasco looses $30M deal to IBM in Singapore3 Message-ID: <AEsVzGcA8pIY@eisner.encompasserve.org>   f In article <I0g27.5585$gb6.1031322@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:J > Compaq looses $30M deal to IBM (in Singapore) because of Alpha's demise? > ) > http://www.theinquirer.net/09070107.htm  > J > If this fact is true and more deals fall through, then Capellas could goE > down in flames at the next shareholder's meeting (but with a golden M > parachute the size of the Alpha Microprocessor Division's annual budget). I I > still don't understand why Compaq didn't decide to support/develop both L > Alpha and IA-64 (eg. HP: PA-RISC and IA-xx, IBM: PowerPC and IA-xx, etc.).  . Perhaps Intel required it as part of the deal.   ------------------------------  % Date: Mon, 09 Jul 2001 12:29:55 -0400 + From: "Main, Kerry" <Kerry.Main@compaq.com> > Subject: RE: Alpha fiasco looses $30M deal to IBM in SingaporeR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4AD7EDF@kaoexc01.americas.cpqcorp.net>   Neil,   H >>> I still don't understand why Compaq didn't decide to support/developH both Alpha and IA-64 (eg. HP: PA-RISC and IA-xx, IBM: PowerPC and IA-xx,	 etc.).<<<   J To clarify - while they had to release a few additional speed bumps on theC PA line,  HP has announced their future platform for HPUX is IA64.    D Also, IBM has announced their future AIX5L (former Monterey program) platform is IA64 or Power4.   H Both of which, while some emulation/translation capabilities will likelyL exist, will require application porting / recompile for important 64bit apps	 as well.    
 Reference:H http://www.hp.com/products1/itanium/vision/roi/parisc_roadmap_print.htmlH http://www-1.ibm.com/servers/aix/overview/industry.html (IA64 and Power)& http://www-1.ibm.com/servers/monterey/       Regards,  
 Kerry Main Senior Consultant  Compaq Canada Inc. Professional Services  Voice: 613-592-4660  Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----. From: Neil Rieck [mailto:n.rieck@sympatico.ca] Sent: July 9, 2001 6:56 AM To: Info-VAX@Mvb.Saic.Com : Subject: Alpha fiasco looses $30M deal to IBM in Singapore    H Compaq looses $30M deal to IBM (in Singapore) because of Alpha's demise?  ' http://www.theinquirer.net/09070107.htm   H If this fact is true and more deals fall through, then Capellas could goC down in flames at the next shareholder's meeting (but with a golden K parachute the size of the Alpha Microprocessor Division's annual budget). I G still don't understand why Compaq didn't decide to support/develop both J Alpha and IA-64 (eg. HP: PA-RISC and IA-xx, IBM: PowerPC and IA-xx, etc.).  I Mikey: It's not too late to change your mind about killing Alpha! You can F save face by saying that this is the recommendation of the newly hired marketing consultants.    
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/ @ http://www3.sympatico.ca/n.rieck/links/compaq_memorial_site.html   ------------------------------   Date: 9 Jul 2001 05:54:11 -0500 9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) 3 Subject: Re: Capellas admits move anti-competitive? 3 Message-ID: <wPwfLk3Or7rk@eisner.encompasserve.org>   s In article <ada27.8466$Pf6.3253689@typhoon.ne.mediaone.net>, "Terry C. Shannon" <terryshannon@mediaone.net> writes:   M > Microsoft's influence at Compaq is fading. Oracle is ascendent. Recall that N > Microsoft never got access to the VMS goodies it wanted (cluster file systemA > for NT, etc) yet Oracle got the TruCluster IP for Oracle9i RAC.   G What happened to the snapdisk-related file system that was built in the G UK for VMS ?  It was supposedly transferred on a non-exclusive basis to H Oracle, along with the VMS employees who had worked on it.  The VMS folkF in New Hampshire, USA found it inadequate for their cluster needs, butB I thought conventional wisdom was that Microsoft was not so fussy.   ------------------------------  # Date: Mon, 09 Jul 2001 11:00:52 GMT ? From: Jim.Johnson@software-exploration.nospam.com (Jim Johnson) 3 Subject: Re: Capellas admits move anti-competitive? 0 Message-ID: <3b498e62.10382839@news.demon.co.uk>  F It was transferred to Microsoft on a non-exclusive basis.  A number ofD the engineers associated with it were picked up later when the groupB was shut down.  I hadn't heard of any deal with Oracle for it, but- then there's little reason why I should have.   F I don't know what Microsoft has done with it, but Compaq does offer it* as one of their storage software products.   Jim.  F On 9 Jul 2001 05:54:11 -0500, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:   t >In article <ada27.8466$Pf6.3253689@typhoon.ne.mediaone.net>, "Terry C. Shannon" <terryshannon@mediaone.net> writes: > N >> Microsoft's influence at Compaq is fading. Oracle is ascendent. Recall thatO >> Microsoft never got access to the VMS goodies it wanted (cluster file system B >> for NT, etc) yet Oracle got the TruCluster IP for Oracle9i RAC. > H >What happened to the snapdisk-related file system that was built in theH >UK for VMS ?  It was supposedly transferred on a non-exclusive basis toI >Oracle, along with the VMS employees who had worked on it.  The VMS folk G >in New Hampshire, USA found it inadequate for their cluster needs, but C >I thought conventional wisdom was that Microsoft was not so fussy.    Jim Johnson  Software Exploration, Ltd.) (remove '.nospam' from the reply address)    ------------------------------  $ Date: Mon, 9 Jul 2001 07:20:14 -0400) From: "Neil Rieck" <n.rieck@sympatico.ca> 3 Subject: Re: Capellas admits move anti-competitive? : Message-ID: <rng27.5843$gb6.1040256@news20.bellglobal.com>  L I can't remember who sent me this "department of justice" link, but it wouldJ seem that the Compaq-Intel deal might be anti-competitive and subject to a DOJ investigation.  1 http://www.usdoj.gov/atr/public/testimony/hhi.htm   G Even if Intel doesn't take any Alpha related hardware (masks etc.) from J Compaq, just agreeing to kill Alpha for money might change the marketplace' significantly to trigger HHI (see link)     
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/    ------------------------------   Date: 9 Jul 2001 03:51:31 -0700 ( From: kparris@my-deja.com (Keith Parris)P Subject: Re: Cluster comms over fc, was Re: Compaq's Alpha design team for sale?= Message-ID: <cb85fed2.0107090251.513cfa4b@posting.google.com>   U Scott Vieth <svieth@wi.rr.com> wrote in message news:<3B4207E6.DC443376@wi.rr.com>... W > Gimme some more detail on what you mean when you say "all the fibre players agreeing" R > on host-to-host communication.  Can't Compaq just write an add-on which lets VMS0 > systems talk to each other over fibre channel?  D From what I recall from discussions about this with VMS Engineering:B The initial KGPSA FC adapter is made by Emulex, and supported someD sort of basic host-to-host communications (perhaps SCSI Target Mode,E perhaps support for protocols other than SCSI-3, like IP-over-FC), so D hope for SCS over FC was high.  Later models from Emulex did not, soC at that time VMS Engineering didn't want to spend the effort to get C something working that later FC adapters from their vendor wouldn't / support.  At that point, hope was at a low ebb.   F In a more-recent development, another FC adapter vendor has reportedlyC announced a FC adapter that supports VIA.  The VI Architecture (see B http://viarch.org) looks like it can support the types of reliableD cluster communications capabilities we have come to know and love inA SCS.  Although VIA has been implemented on a variety of hardware, A including common LANs, with a mix of software and hardware in the @ implementation, VIA can also be implemented entirely in hardware (ServerNet II is one example).  ; There would be significant development work required in VMS D Engineering to map SCS onto VIA, and then qualification work, so SCSD over FC can't be available any time soon.  Interestingly, InfinibandC (see http://www.infinibandta.org) also supports VIA, so SCS-via-VIA D might lay the groundwork for VMS Cluster support on Infiniband later on.    Keith    ------------------------------  % Date: Mon, 09 Jul 2001 13:29:15 -0400 , From: Steve Lionel <Steve.Lionel@compaq.com>M Subject: Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window? 8 Message-ID: <7gpjktso8o011lokpmmujh65g4821ibd0k@4ax.com>  A On 30 Jun 2001 20:08:06 GMT, mathog@seqaxp.bio.caltech.edu (David  Mathog) wrote:  G >It would be nice if once Q managements' eyes stop spinning they could  H >clarify the repercussions on the hobbyist and education programs of theH >sale of their compiler divisions to Intel.  Products have at times beenJ >pulled from the CSLG following such sales, and if the CSLG is a bad deal H >now, it's going to be completely unworkable if the compilers go away.  D >Ditto for the hobbyist and (still unusable, but who cares anymore?)? >educational license program.  Ditto for Linux/Alpha compilers.   D As it has been explained to me - note that this is NOT in any way anB official statement - all existing Compaq compilers for OpenVMS andF Tru64 will continue to be Compaq products, thus the transition of someF compiler groups to Intel (Fortran is the first) will have no effect onB programs such as CSLG.  Intel will provide development and supportE resources, but these compilers will still be sold as Compaq products.   F When there are IA64 compilers for OpenVMS and Tru64, these too will be> Compaq products, so Compaq gets to decide how to license them.  E The only current Compaq compiler which will actually change to becomeeF an Intel-branded product is Visual Fortran for Windows, but that won't happen for at least a year.i  E After Fortran, the specifics as to which "compiler" groups (includingdB GEM, math library and some others) transition to Intel and when isD currently unknown.  Fortran will make the move in mid-August (last I heard.)p    - Steve Lionel (mailto:Steve.Lionel@compaq.com)' Fortran Engineeringo* High-Performance Technical Computing Group& Compaq Computer Corporation, Nashua NH  6 Compaq Fortran web site: http://www.compaq.com/fortran   ------------------------------  % Date: Mon, 09 Jul 2001 10:46:45 -0700 ! From: Tom Linden <tom@kednos.com> M Subject: RE: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window?l9 Message-ID: <CIEJLCMNHNNDLLOOGNJIEEBDCPAA.tom@kednos.com>p  J Is Compaq actually transferring title or simply licensing the compilers to Intel?I When you say that the compilers will continue to be Compaq products, does 
 that implyJ that compaq will continue with engineering support, or will that be turned over to Intel?F Has the list yet been identified, as to what is going where?  GEM, SDL various front-endsJ where are they.  Based on the press releases, which identify an agreement, Somebody must know.fG I would be truly amazed if the agreement said "to be defined at a latero< date", Intel doesn't do business that way.  Why the mystery?   > -----Original Message-----5 > From: Steve Lionel [mailto:Steve.Lionel@compaq.com] & > Sent: Monday, July 09, 2001 10:29 AM > To: Info-VAX@Mvb.Saic.Com G > Subject: Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out thec	 > window?  >e >AC > On 30 Jun 2001 20:08:06 GMT, mathog@seqaxp.bio.caltech.edu (Davidv > Mathog) wrote: >iH > >It would be nice if once Q managements' eyes stop spinning they couldJ > >clarify the repercussions on the hobbyist and education programs of theJ > >sale of their compiler divisions to Intel.  Products have at times beenK > >pulled from the CSLG following such sales, and if the CSLG is a bad deal H > >now, it's going to be completely unworkable if the compilers go away.F > >Ditto for the hobbyist and (still unusable, but who cares anymore?)A > >educational license program.  Ditto for Linux/Alpha compilers.  > F > As it has been explained to me - note that this is NOT in any way anD > official statement - all existing Compaq compilers for OpenVMS andH > Tru64 will continue to be Compaq products, thus the transition of someH > compiler groups to Intel (Fortran is the first) will have no effect onD > programs such as CSLG.  Intel will provide development and supportG > resources, but these compilers will still be sold as Compaq products.e > H > When there are IA64 compilers for OpenVMS and Tru64, these too will be@ > Compaq products, so Compaq gets to decide how to license them. > G > The only current Compaq compiler which will actually change to become H > an Intel-branded product is Visual Fortran for Windows, but that won't > happen for at least a year.  >eG > After Fortran, the specifics as to which "compiler" groups (includingtD > GEM, math library and some others) transition to Intel and when isF > currently unknown.  Fortran will make the move in mid-August (last I	 > heard.)o >p >o/ > Steve Lionel (mailto:Steve.Lionel@compaq.com)e > Fortran Engineeringt, > High-Performance Technical Computing Group( > Compaq Computer Corporation, Nashua NH > 8 > Compaq Fortran web site: http://www.compaq.com/fortran >-   ------------------------------  % Date: Mon, 09 Jul 2001 05:28:32 -0400N- From: Jack Patteeuw <jjpatteeuw@peoplepc.com>pK Subject: Re: Computer Rooms and big UPSes: I need some electrical advice...0, Message-ID: <3B497940.861A4FB4@peoplepc.com>  O Terry actually gave a GREAT explanation so I'm only going to highlight a couplerP of his points (and interestingly enough you have a lot of the same equipment we  have).  H First your 75kVA is probably 25kVA per leg.  See if your front panel canL show you current per leg.  If each leg is 120 Volts, then in theory you have* 25000/120 = 208 Amps capacity on each leg.  L You should try to keep the power on each leg "balanced".  Having one leg on F that SW800 drawing twice as much as the other isn't "optimal" but the / numbers are so low, it probably doesn't matter.n  J When adding "phase to phase" equipment (like you ESA1200) the third phase M will obviously wind up with less load.  If possible, put some other equipmenty on that leg.  O The number you have decided not to exceed, per leg, is 80% * 208A = 166A.  Have-N your electrician put his "amp clamp" on the lines going directly into the UPS.< Remember what Terry said.  Those devices are only +/- 10-20%    
 Jack Patteeuw$   ------------------------------  % Date: Mon, 09 Jul 2001 10:49:04 +0100R  From: steven.reece@quintiles.comK Subject: Re: Computer Rooms and big UPSes: I need some electrical advice...CH Message-ID: <OF89F0C82F.451A5E03-ON80256A84.003588B3@qedi.quintiles.com>  D I don't doubt Terry (since he's put more detail in his answer than IG could).  However, the reason that I was told transformers and UPSes andtJ such like are rated in VA rather than Watts is because they transfer powerI rather than consuming it.  Ok, there are some losses in a transformer but A the majority of the input power comes out of the output legs too.(I Electricity distribution would look mighty different if transformers were H not as efficient as they are, plus you want your UPS to supply your kit,1 not to add another 100% to your electricity bill!  Steve.   Terry Kennedy answered : >>>hG > 6) What is the difference between "watts" and "VA"?  Why aren't UPSese > rated in watts?A  H   Glib answer: because then most UPS' would look as wimpy as they really are.  I   Seriously, VA is a simple formula - Volts * Amps. You get a nice numberyJ which is easy to derive and mostly useless for sizing purposes. VA = WattsE applies only for things like pure resistive loads (light bulbs, spacerE heaters, and so forth). Since we're talking AC power which has a sineeK waveform, power supplies can do whatever they want to use it. Early switch- F mode power supplies drew power only during some parts of the waveform. <<<.   ------------------------------  % Date: Mon, 09 Jul 2001 11:17:45 -0400T- From: "Richard D. Piccard" <piccard@ohio.edu> K Subject: Re: Computer Rooms and big UPSes: I need some electrical advice... ( Message-ID: <3B49CB13.980DCDE3@ohio.edu>   Scott Vieth wrote:   > [snip]   >-G > 6) What is the difference between "watts" and "VA"?  Why aren't UPSeso > rated in watts?l  D Watt is a unit of power; Amp is a unit of current; Volt is a unit of potential difference.8  B At each instant, the power is the product of current and potentialE difference, each as a signed quantity.  Positive power represents theoG transfer of energy in one direction (conventionally generator to load), H negative power represents the transfer of energy in the other direction.K With AC, both potential difference and current are likely to be sinusoidal,eE positive half the time and negative half the time; if the current andhE potential difference are both negative or both positive, the power iseH transferred in one direction, if one is positive and the other negative,0 the power is transferred in the other direction.  C         ***the current and potential need not be in phase with each- other***  I so the net transfer of energy, averaged over any extended period of time,KI will be at most equal to the product of current and potential difference,nH each measured separately, and that occurs only if the two are exactly inD phase.  For loads that involve rotating machinery, significant phase/ differences are likely, especially at start-up.a  +                                         RDPP   --B ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  % Date: Mon, 09 Jul 2001 10:10:18 -0400x) From: Rick Barry <barry@star.zko.dec.com>o7 Subject: Re: CSWS/Apache userdir and SSI config problem 0 Message-ID: <3B49BB4A.CDFF070A@star.zko.dec.com>  * Alan Winston - SSRL Admin Cmptg Mgr wrote:   > <snip>K > I'm trying to make everything that works under OSU in another node in the/J > cluster work under Apache/CSWS, before exploring additional capabilities/ > of Apache.  This is mostly going pretty well.  >-H > Server-side Includes (SSI) work on Apache when they come from the main1 > directory tree, whether named .shtml or .htmlx.  >yP > Userdirs work on Apache; ~username gets you to the [.WWW] subdirectory of thatP > user's sys$login.  ([.WWW] to match OSU's userdirs; it's not the default.  The/ > disk is ODS-5, if that makes any difference.)0 >0I > .shtml or .htmlx files that are in userdirs don't work, or at least the K > processing doesn't work.  (The files are served as html, but the SSI tags L > aren't filled in.  These are things like "echo var=LAST_MODIFIED", nothingH > that requires running a separate program.)  Copy the same files to the- > main directory tree, and SSI works on them.B >PM > I see that I must specify that includes are allowed for that directory, andk > I think I'm doing that.e >c# > Here's an excerpt from httpd.confd >o > #tK > # UserDir: The name of the directory which is appended onto a user's homem- > # directory if a ~user request is received.c > #n
 > UserDir www/ > #. > <Directory www>k- >     AllowOverride FileInfo AuthConfig Limit-D >     Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec' >     <Limit GET POST OPTIONS PROPFIND>n >         Order allow,deny >         Allow from all >     </Limit>D >     <Limit PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK> >         Order deny,allow >         Deny from all  >     </Limit> > </Directory> > L > (This is a straight copy of the example in the httpd.conf file.  I've alsoF > tried this with Includes instead of IncludesNoExec and various otherM > combinations.  The files are served but the SSIs aren't processed.) Nothing 3 > interesting shows up in access_log. or error_log.  > <snip>  P In your "UserDir" directive,  "www"  is appended to the user's default directoryS path. For example, if user JOE's default directory is /DEV1/JOE, the full directoryHR path is /DEV1/JOE/WWW. Your "Directory" directive should specify /DEV1/JOE/WWW (orS some regular expression that matches the set of user directories you want to enablea server-side includes).   --
 Rick Barry  3 Compaq Secure Web Server (CSWS) - Development Groupn Compaq Computer Corporationi
 Nashua, NH   ------------------------------  % Date: Mon, 09 Jul 2001 13:32:56 -0400t, From: Steve Lionel <Steve.Lionel@compaq.com>* Subject: Re: DEC Notes available, someone?8 Message-ID: <clqjkt8s277evnjgidaeal429mmv8glsts@4ax.com>  ; On Tue, 03 Jul 2001 20:49:23 +0200 (CEST), Freddy Meerwaldte <frederik@freddym.org> wrote:a  D >Anyway, we would like to install DEC Notes on it, but I only have a! >slightly outdated version handy.t  A The last DEC Notes kit is 2.5A from 1993.  Is that what you have?n    - Steve Lionel (mailto:Steve.Lionel@compaq.com)I Fortran Engineering$* High-Performance Technical Computing Group& Compaq Computer Corporation, Nashua NH  6 Compaq Fortran web site: http://www.compaq.com/fortran   ------------------------------  , Date: Mon, 09 Jul 2001 18:49:09 +0200 (CEST)- From: Freddy Meerwaldt <frederik@freddym.org>e* Subject: Re: DEC Notes available, someone?J Message-ID: <Pine.LNX.4.21.0107091848070.8093-100000@firewall.freddym.org>  	 Hi Steve,   F > >Anyway, we would like to install DEC Notes on it, but I only have a# > >slightly outdated version handy.  > C > The last DEC Notes kit is 2.5A from 1993.  Is that what you have?d   Yupp!rD A real pity that DEC stopped developing DEC Notes - it's a very nice product.    Thanks, I'll install this one...
 Best Regards,i 	Freddy    --  N Geek Code 3.1: GCS s+: a--- C+++ UBOU+++ P-- E--- W++ N w--- V++ PGP- t? 5? tv  J ==========================================================================D  Frederik Meerwaldt  ICQ: 83045387  Homepage: http://www.freddym.orgC  Bavaria/Germany              OpenVMS and Unix Howtos and much moreeI  Solaris, HP/UX, AIX, NetBSD, OpenBSD, IRIX, Tru64, OpenVMS, Ultrix, BeOSl   ------------------------------  % Date: Mon, 09 Jul 2001 10:14:59 -0700p From: aek@spies.com (Al Kossow)m' Subject: Re: DECWORLD 2001 Byte articlee; Message-ID: <aek-0907011014590001@il0502a-dhcp38.apple.com>a  C In article <uiu5ktg8e6r5a0e1hvotsj71tbmeg4lqjm@4ax.com>, Alan Greign <a.greig@virgin.net> wrote:   . > DEC no longer exists, Byte no longer exists? > F > But you can still read the Byte review of DECworld 2001 by Lou Greer   today..    > atA > http://www.byte.com/documents/s=716/byt20010622s0005/greer.html) >   * Will this article exist 25 years from now? Will the URL work next year?  > I can still read a paper copy of an article in Byte from 1976.  H http://abcnews.go.com/sections/scitech/DailyNews/preservation010708.html   food for thought.m   ------------------------------  + Date: Mon, 09 Jul 2001 10:47:01 -0700 (PDT)   From: l_ricker@lto.locktrack.com' Subject: Re: DECWORLD 2001 Byte article . Message-ID: <01070910470171@lto.locktrack.com>  + >Will this article exist 25 years from now?n >Will the URL work next year?n  ? >I can still read a paper copy of an article in Byte from 1976.o  I >http://abcnews.go.com/sections/scitech/DailyNews/preservation010708.htmlh   >food for thought.  A `Scientific American' covered this same topic of data/informations? preservation in an excellent article in, I think, an issue fromgB the early 1990's... I'd post a reference if I could only find that> issue in my banker's boxes containing all my back issues!  ;-)  8 On the other hand, maybe I can find it on the 'net?  ;-?   regards,
   -- Lorin   ------------------------------  % Date: Mon, 09 Jul 2001 14:45:02 +0200V$ From: Richard Meijn <rameijn@wxs.nl>. Subject: Driver SQL server database connectoin& Message-ID: <3B49A74E.CFEDC5FD@wxs.nl>  D Is there a driver or a software package availeble to make a databaseE connection from a VAX/VMS system to a MS-SQL database on a NT system.w  D If there is where can I find it or what is the best solution for it.   Regards,   Richard=A0 Meijn   ------------------------------  % Date: Mon, 09 Jul 2001 12:27:38 -0400i- From: Michael Austin <miaustin@bellsouth.net>e Subject: Re: DSL for OpenVMS- Message-ID: <3B49DB7A.B8F72F23@bellsouth.net>r  H Depending on your provider, you DSL may or may not provide you with whatB you  want.  My provider (bellsouth.net) does not provide static IPH addressing for their home DSL customers making it somewhat useless.  TheG cable provider had static IP but would shut your service off if you hadaF any type of server running.   I use the Linksys BEFRS41 router/hub and$ they provided the "Speed Touch Home"F ethernet-modem from Alcatel.  The router/hub does have port-forwarding% capability, if I can get a static IP.g  E home network consist of 2 Alpha 2100's and 4 PC's of various flavors.h   Michael Austin DBA Consultant   Jason O'Donnell wrote:  D > Does anybody have OpenVMS drivers for any DSL PCI card?  I want to* > access the internet from my OpenVMS box. >L > JMOD   ------------------------------  % Date: Mon, 09 Jul 2001 07:44:09 -0700l, From: Duane Sand <Duane.Sand@mindspring.com>2 Subject: emulation of VMS privilege levels on IA64A Message-ID: <001d01c10885$9cf72640$787ba8c0@stcla1.sfba.home.com>p  ' > On Mon, 9 Jul 2001, Duane Sand wrote:t > [...]t > >+"Bob Koehler" replied:I > >+> Not quite.  While many processors support the 4 modes VMS requires,r UNIX= > >+> requires only 2, and some processors still have only 2.  > >+@ > >+IA-64 supports 4 levels; hopefully they will fit VMS's needs > >+well enough. >.$ Gotfryd Smolik, VMS lists then asked5 >  Can you point a place with description like this ?l9 >  Have one time look for Merced archit. DOCs, have found 4 > most of user mode description - but not the answer > about modes and paging.o   See sections 3.1 and 4.1.1.6 ofeB    http://developer.intel.com/design/ia-64/downloads/24531802s.pdf   ------------------------------  # Date: Mon, 09 Jul 2001 16:14:12 GMTa= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)o6 Subject: Re: emulation of VMS privilege levels on IA640 Message-ID: <009FEBF9.20E91A94@SendSpamHere.ORG>  p In article <001d01c10885$9cf72640$787ba8c0@stcla1.sfba.home.com>, Duane Sand <Duane.Sand@mindspring.com> writes: >'( >> On Mon, 9 Jul 2001, Duane Sand wrote: >> [...] >> >+"Bob Koehler" replied:eJ >> >+> Not quite.  While many processors support the 4 modes VMS requires, >UNIX > >> >+> requires only 2, and some processors still have only 2. >> >+0A >> >+IA-64 supports 4 levels; hopefully they will fit VMS's needso >> >+well enough.S >>% >Gotfryd Smolik, VMS lists then asked 6 >>  Can you point a place with description like this ?: >>  Have one time look for Merced archit. DOCs, have found5 >> most of user mode description - but not the answerc >> about modes and paging. >d  >See sections 3.1 and 4.1.1.6 ofC >   http://developer.intel.com/design/ia-64/downloads/24531802s.pdfn >? >a  D From a cursory look at Table 4.3 "Page Access Rights", it looks likeD VMS will be a bit starved for subsystem page protections as we know 	 them now.    --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMd            aJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbesm   ------------------------------  # Date: Mon, 09 Jul 2001 13:00:04 GMT $ From: Scott Vieth <svieth@wi.rr.com>( Subject: Re: Experience with EMC storage) Message-ID: <3B49AB6D.3E37127E@wi.rr.com>,  8 Hmmmmm....very interesting.  Thanks for enlightening me.  
 -Scott :^)   Rob Young wrote:  O > > The mirrored-cache only comes into play when you enable write-back caching.iI > > You can run controller-based mirrors without having writeback cachingt > > enabled. > >a >iF >         Think so?  Try this as an experiment.  Tell your HSJ/HSZ/HSGG >         that it is using battery backup (not UPS) and then unplug thepC >         battery such that it is showing a failed battery when youoG >         run FMU.... now try creating a mirrorset.  Can't do it?  Why?cP >         Because unbeknowst to the enduser, Raid1 on HSJ/HSZ/HSG uses writebackI >         cache even when set to writethrough, or so I have been told and J >         yes I did have opporunity to perform the above experiment and noN >         you can't create a controller based mirrorset with failed batteries. >s% >                                 Robp   ------------------------------  # Date: Mon, 09 Jul 2001 14:33:03 GMTCF From: lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman): Subject: Re: exploitable buffer overflows in VMS possible?2 Message-ID: <zgj27.444$rc5.26665@news.cpqcorp.net>  < I would be a bit surprised if you could exploit this type of; a hole on VMS, particularly on Alpha.  Programs are dividedn< into code and data segments, and you can't execute something: in a data segment.  This is moderatly enforced on the VAX,9 though it is possible to write to the code segment at runs; time and execute the code (I wrote some diagnostic programsu< some years ago which did this).  However, it's very strongly: enforced on the Alpha.  The buffers themselves which would: have to overflow are in a segment of memory which is going: to be marked to allow writes, but is also going to have to9 be marked as 'no execute'.  Code is in segments which are = going to be marked execute and no write.  So even if a bufferu< was at the end of it's segment (or PSECT) and a code segment< came right after it in memory, the memory protection schemes> in VMS would probably stop you from being able to write to the; code segment, and I think they would probably stop you fromr; telling the program to execute a segment of memory that hade> been previously marked as data because it's going to be marked as no execute.  9 I'm not saying it's impossible, but it is going to take at= lot more effort than any of the buffer overflow exploits I'veo" seen reported for other platforms.  < It would be a lot easier on a VAX if the program was written= with improperly marked PSECTS that mixed code and data in thel? same memory segment.  Fortunately, I don't think there are manye of those around anymore.   -- h(  B. Z. Lederman   Personal Opinions Only  8  Posting to a News group does NOT give anyone permission8  to send me advertising by E-mail or put me on a mailing  list of any kind.  5  Please remove the "DISABLE-JUNK-EMAIL" if you have ae5  legitimate reason to E-mail a response to this post.d   ------------------------------  # Date: Mon, 09 Jul 2001 15:05:57 GMT- From: danco@pebble.org ()o: Subject: Re: exploitable buffer overflows in VMS possible?- Message-ID: <slrn9kji2l.j75.danco@pebble.org>:  2 On Mon, 09 Jul 2001 14:33:03 GMT, Bart Z. Lederman6 <lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com> wrote:  = >It would be a lot easier on a VAX if the program was writtenh> >with improperly marked PSECTS that mixed code and data in the@ >same memory segment.  Fortunately, I don't think there are many >of those around anymore.a  > However, psects in which code and data are intentionally mixed) are usually read only.  No problem there.e   -Dan   ------------------------------  # Date: Mon, 09 Jul 2001 15:41:24 GMTe= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)u: Subject: Re: exploitable buffer overflows in VMS possible?0 Message-ID: <009FEBF4.8B7BD0EC@SendSpamHere.ORG>  { In article <zgj27.444$rc5.26665@news.cpqcorp.net>, lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman) writes:e= >I would be a bit surprised if you could exploit this type ofr< >a hole on VMS, particularly on Alpha.  Programs are divided= >into code and data segments, and you can't execute somethingf; >in a data segment.  This is moderatly enforced on the VAX,p: >though it is possible to write to the code segment at run< >time and execute the code (I wrote some diagnostic programs= >some years ago which did this).  However, it's very stronglyt; >enforced on the Alpha.  The buffers themselves which wouldf; >have to overflow are in a segment of memory which is goinge; >to be marked to allow writes, but is also going to have to": >be marked as 'no execute'.  Code is in segments which are> >going to be marked execute and no write.  So even if a buffer= >was at the end of it's segment (or PSECT) and a code segmentW= >came right after it in memory, the memory protection schemese? >in VMS would probably stop you from being able to write to theo< >code segment, and I think they would probably stop you from< >telling the program to execute a segment of memory that had? >been previously marked as data because it's going to be marked  >as no execute.  >r: >I'm not saying it's impossible, but it is going to take a> >lot more effort than any of the buffer overflow exploits I've# >seen reported for other platforms.r >e= >It would be a lot easier on a VAX if the program was writteni> >with improperly marked PSECTS that mixed code and data in the@ >same memory segment.  Fortunately, I don't think there are many >of those around anymore.o     File TEST.MAR is:o  	 	.EXTRN	X, 	.PSECT	CODE,NOWRT,EXE,5 	.ENTRY	GO,0
 	MOVL	X,R0	 	JSB	(R0)* 	RET	 	.END	GO	p     File DATA.MAR is:   	 	$PDSCDEFc   	.PSECT	$LINKAGE,NOWRT,NOEXE,5 X::	.ADDRESS	X_PDSC 
 	.ALIGN  QUADe  . X_PDSC:	.LONG	<PDSC$K_KIND_NULL@PDSC$V_KIND>!-$ 		<PDSC$M_NATIVE!PDSC$M_NO_JACKET>,0 	.ADDRESS	X_C,0u  " ;                         vvvvv--- 	.PSECT	$DATA,WRT,NOEXE,5h* X_C:	.LONG	^x47E03400	; BIS     R31, 1, R0 	.LONG	^x6BFA8001	; RET     R26e 	.ENDi 	y   Compile, link and run.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM=            =J   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbesv   ------------------------------   Date: 9 Jul 2001 16:23:58 GMTr1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon),: Subject: Re: exploitable buffer overflows in VMS possible?, Message-ID: <9iclqu$13a9$1@info.cs.uofs.edu>  ) In article <3B45C33C.2727C9CE@gtech.com>,4@  Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> writes: |> |>  & |> There are a few good things on VMS:D |>   * the VMS core are not using C/C++ zero-terminated strings, butG |>     uses descriptors => that makes the VMS core much less vulnerables- |>     than its Unix and Windows counterpartsd  D C & C++ are not the only languages subject to data overruns writting into other data areas.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   x   ------------------------------   Date: 9 Jul 2001 12:54:46 -0500g9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)t: Subject: Re: exploitable buffer overflows in VMS possible?3 Message-ID: <hJmIkrqsI+pw@eisner.encompasserve.org>a  ` In article <9iclqu$13a9$1@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:+ > In article <3B45C33C.2727C9CE@gtech.com>,oB >  Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> writes: > |> > |>  ( > |> There are a few good things on VMS:F > |>   * the VMS core are not using C/C++ zero-terminated strings, butI > |>     uses descriptors => that makes the VMS core much less vulnerablec/ > |>     than its Unix and Windows counterpartsi > F > C & C++ are not the only languages subject to data overruns writting > into other data areas.  E Both C and Bliss support sloppy programming in this regard with their @ pointer arithmetic, making it easy to run off the end of arrays.  F C promotes sloppy programming in this regard with it's null-terminated strings.   ------------------------------   Date: 9 Jul 2001 17:13:44 GMT 1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)t: Subject: Re: exploitable buffer overflows in VMS possible?, Message-ID: <9icoo8$14l1$1@info.cs.uofs.edu>  3 In article <hJmIkrqsI+pw@eisner.encompasserve.org>, <  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes: |> ,I |> C promotes sloppy programming in this regard with it's null-terminated  |> strings.f  @ We've been through this before, but Macro-11 had null terminated> strings (.ASCIZ) and very likely predated the common use of C.   bill   -- eJ 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: Mon, 09 Jul 2001 17:47:15 GMTiF From: lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman): Subject: Re: exploitable buffer overflows in VMS possible?2 Message-ID: <D6m27.450$rc5.28335@news.cpqcorp.net>  o In article <hJmIkrqsI+pw@eisner.encompasserve.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:u >tF >Both C and Bliss support sloppy programming in this regard with theirA >pointer arithmetic, making it easy to run off the end of arrays.I >oG >C promotes sloppy programming in this regard with it's null-terminatedm	 >strings.r  @ Even so, the default action of the compilers is to separate code2 and data, and protect the various memory segments.  7 In order for someone to exploit this hole, at least twot things have to happen.  8 First, there has to be a program which people can access7 from the 'outside' in some way: this would usually meanr; a web browser, web server, or some similar network program.o  < Second: the person who wrote that program would have to take; relatively extraordinary steps to bypass the memory segmentw; scheme, at least on Alpha.  As I mentioned before, it's notp; too difficult to bypass the protection on a VAX, especiallys< using Macro code: but on the Alpha it's relatively difficult: to actually bypass the protection, and it's even more of a: chore if you are using Bliss or C or FORTRAN or any of the: other compilers, since they will already do the separation9 of segments.  As I said before, it may not be impossible, 8 but it won't happen by accident.  The person writing the> program will probably have to do strange things at the linking8 stage as well as writing code specifically to bypass the( operating system's protection of memory.  < Then, even if the programmer does do all of this, the person9 on the 'outside' has to know exactly what and where it ist to exploit it.  7 Of course, this doesn't rule out consperacy between twor5 people working to subvert a systems, one 'inside' andg8 one 'outside'.  However, I think that if somebody wanted9 to plant a 'back door' into a system so that someone fromw8 the outside could sneak in, there must be easier ways to/ do it than to try to exploit a buffer overflow.   : I also think the original question was oriented twords the7 question of people exploiting weaknesses in programs or/4 operating systems, as has happened recently on other5 platforms.  I think the way that OpenVMS is designed, 6 especially on the Alpha, makes it rather unlikely that6 such an exploitable weakness will appear accidentally.   --  (  B. Z. Lederman   Personal Opinions Only  8  Posting to a News group does NOT give anyone permission8  to send me advertising by E-mail or put me on a mailing  list of any kind.  5  Please remove the "DISABLE-JUNK-EMAIL" if you have ac5  legitimate reason to E-mail a response to this post.h   ------------------------------  # Date: Mon, 09 Jul 2001 12:36:56 GMT . From: "Alphaman" <alphaman64@nixspam-home.com> Subject: Re: ftp scriptl; Message-ID: <Izh27.22239$B5.4697623@news1.rdc1.tn.home.com>s  4 Tim Downs <tim.downs@thedacare.org> wrote in message5 news:3b45db9c$0$94306$39cecf19@news2.twtelecom.net...nB > The line in the script was: $ ftp ndsftp /user='pcuser' 'netdir' >aD > netdir="put ''ftpname' file://''fsvr'/home/home/''pcusr'/''ftpname >># > ftpname= name of file user wanted , > fsvr= novell file server user was going to > pcusr=novell login id.  # You can do either of the following:   ' $ Pipe write sys$output "put ''ftpname'm1 file://''fsvr'/home/home/''pcusr'/''ftpname'" | -i5   ftp ndsftp /username='pcusr' /password='pcpassword'i   or  % $ Copy /ftp 'ftpname' ndsftp"''pcusr'-> ''pcpassword'"::"file://''fsvr'/home/home/''pcusr'/''ftpname'"  L The advantage of the second method is that a meaningful $Status is returned,- reflecting the success of the copy operation.    Aaron  --> Aaron Sakovich  http://members.home.net/sakovich/alphaman.html> Make April 15 just another day:        http://www.fairtax.org/ "F u cn rd ds, U mst uz UNIX.u1  If you can read this, you could handle OpenVMS."v   ------------------------------  % Date: Mon, 09 Jul 2001 18:21:09 +0200 ) From: Christof Brass <brass@infopuls.com>  Subject: Re: FUD, Message-ID: <3B49D9F5.119B35AD@infopuls.com>   Jordan Henderson wrote:tJ > For no more additional R&D, DEC could have given away Alpha motherboards1 > based on the current or last generation Alphas.f > E > Let's say they put $500 extra value into every single CPU commoditytG > motherboard that they could make (these numbers are admittedly rough,oM > maybe DEC couldn't really build these Motherboards for $500, which would be-J > shocking, but even so, you'd _think_ that they could get _something_ forM > them to make up the difference)  Let's take the $4 Billion in cash that DECsH > had on hand when CPQ picked them up.  DEC could have, starting in 1996I > when Alpha/NT first became available, until 2000 put 2 million of these+F > motherboards on the market each year (refreshing the technology eachE > year based on the last generation or perhaps the current generation E > with 1/2 the cache or something - a Celeron/Duron little brother to  > the current Alpha offering).  @ Without a lot of 3rd party SW the Micro$hit stuff alone wouldn't? have made it. Moreover NT on Alpha doesn't make sense (at least > didn't make sense in the beginning) because of the performance? drop due to 32 and 16 Bit addressing. WNT on Alpha at that timeh= was a no brainer. Forget it. Putting money in that hole would # have made the situation even worse.a  D > What's this you say?  Alpha/NT was doomed because Microsoft didn'tC > really support their apps there?  OK, take $1 Billion in cash outeH > of the above plan and pay MS to keep Office and other tools up-to-dateF > on Alpha/NT.  That would mean only 1.5 million motherboards/year, orD > one less year to the plan or some combination.  Seems like a fully@ > apple-to-apples Alpha/NT competitor to Intel/NT would generateB > enough interest to help defray _some_ of your costs, so it couldD > be the $1 Billion (or whatever it takes) to pay off MS for support> > of your architecture might have no effect on the total plan. > E > If they didn't cripple the motherboards/chips so that they couldn'taC > also run Tru64 and OpenVMS, these would have represented a lot ofoD > license revenue and seeded small developers with a lot of hardwareC > to develop the next big killer app.  Think about it, you would benB > able to buy VMS hardware at true commodity prices based on these > motherboards.. > A > Now, a naive analysis would say that some shops might try to goiA > commodity and this would eat into your big iron sales.  I thinko= > this is not much of a concern as serious shops wouldn't putt? > critical functions on commodity hardware, and most of the VMS E > base are serious shops with critical functions these days.  But, ifrF > this really bothers you, just require these new class of machines toC > have new (not transferred) VMS licenses.  Admittedly, these would:G > be the low end license, but it would still represent a big offsetting B > jump in license sales to help make up for any damage to your big
 > iron sales.r  : VMS shops don't buy and use WNT for their mission critical? tasks. These people wouldn't have bought the WNT on Alpha idea.e  C > Eventually, you would expect some increase in big iron sales fromtE > shops that had started with commodity systems and need to grow out.  > F > You would have definitely made the PC market a lot more interesting.F > If Alpha sales hurt AMD more than Intel, well then, a DEC/AMD merger5 > might have been an even better competitor to Intel.   . Do you remember who is member of board at AMD?  C > That would have been an aggressive plan to grow the Alpha market.oA > Instead, Palmer seemed to think that they needed to hoard theireC > money to make DEC a more attractive takeover candidate.  Even hadnE > the plan I outlined above been a dismal failure, I would think thataK > an aggressive technology company would have represented a better takeover A > candidate than a stagnant company with no market direction that ' > also happened to have a pile of cash.a > F > Sigh... Haven't Mathog and Dachtera been saying this here for years?M > I guess we should have been supporting their efforts more enthusiastically.cL > I dunno, I guess I just never thought that Alpha would be suddenly gone...I > I'm not sure what we could have realistically done, though.  DEC seemedaI > to not be listening and Compaq may have already been too late (althoughe5 > Alpha Proliants seemed to me to be a good idea...).i > 	 > >- bills > >t > >u > >i >  > -Jordan HendersonI > jordan@greenapple.como   ------------------------------  % Date: Mon, 09 Jul 2001 18:27:04 +0200c) From: Christof Brass <brass@infopuls.com>i Subject: Re: FUD, Message-ID: <3B49DB58.B63A052C@infopuls.com>   Christopher Smith wrote: >  > > -----Original Message-----+ > > From: Andrew Harrison SUNUK Consultancye > : > > The fact that the bean counters ensured that it didn't> > > make sense is probably what is really annoying most people > > on this group. > L > If I were most people in this group I'd take this as a compliment.  Yes, IK > think we can safely say that most of our participants are less than happyo& > with bean counters most of the time. > 
 > Regards, >  > Chriso > # > Christopher Smith, Perl Developera > Amdocs - Champaign, IL >  > /usr/bin/perl -e 'A > print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");o > 'f   :-)n   ------------------------------  # Date: Mon, 09 Jul 2001 16:59:55 GMTo. From: "mulp" <michaelpettengill@earthlink.net> Subject: Re: FUDD Message-ID: <fql27.1454$767.167154@newsread2.prod.itd.earthlink.net>  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9i8org$r7t$1@pyrite.mv.net... >-> > "Jordan Henderson" <jordan@lisa.gemair.com> wrote in message& > news:9i8kao$hdu$1@lisa.gemair.com...> >  it would have cost only as much as is necessary to keep theK > > Hudson plant at 100% utilization rather than the pitiful 30% (or worse)g > they? > > maintained for years (that and a pittance in developing and-
 manufacturinga ...oG > That's where I think you're really dreaming.  Windows won the desktopp battleD > a decade or more ago, Intel won the hardware battle for Windows at	 somewhere:J > around the same time (or you could say it won it yet a decade earlier by  I Just as the PC was disruptive, and the PC was disruptive, the pocket/palmhD devices is disruptive and just as DEC had figured out how to use itsJ experience with highly integrated chip/process design, Palmer sold off theK fab and strongarm to Intel.  Intel has been keeping HLO busy and in fact isaG expanding it significantly and its not doing it to produce ia32 or ia64n chips.  I Still, it would probably have made more sense to sell it to IBM and entert0 into a real partnership with IBM in the process.   ------------------------------  # Date: Mon, 09 Jul 2001 17:14:56 GMTD. From: "mulp" <michaelpettengill@earthlink.net> Subject: Re: FUDD Message-ID: <kEl27.1475$HV1.153718@newsread1.prod.itd.earthlink.net>  < "Jordan Henderson" <jordan@lisa.gemair.com> wrote in message$ news:9i8kao$hdu$1@lisa.gemair.com...@ > A lot of people assume that IA-32 will be the low end offering; > for the foreseeable future, and that IA-64 will be only aa@ > server architecture.  I think this is extremely short sighted.< > While you can perform various tricks to extend the address9 > space of 32 bit processors beyond 32 bits, they are all C > unsatisfactory for a number of reasons.  Once _some_ applicationsAD > start requiring additional address space beyond 32 bits, and thereA > are widely available 64 bit processors available, the switch tob: > 64 bit architectures will be rapid, even on the desktop.  G You don't consider PowerPC and SPARC to be widely available?  They have J certainly been around for quite some years in volumes significantly largerK than Alpha.  DEC focused on finding the applications that could use 64 bits 1 and operated on just the premise that you assert.   2 What you are failing to state is the prerequisite:F     64 bit processors must have no cost penalty over 32 bit processors  L Sun forced a rapid switch to SPARC by stopping production of 68K systems and- you couldn't run Solaris on just any 68K box.t  H DEC forced a rapid switch to Alpha by stopping development of VAX chips,J making Alpha systems cheaper, stopping production of MIPS boxes, making as: much software available on both VAX and Alpha as possible.  J Apple forced a migration to PowerPC by stopping production of 68K systems, etc.  J For SPARC, Power, and Alpha, some applications require 64 bits, but that'sI not the reason for the rapid adoption of those platforms.  The reason for0K adopting them is cost - the cost to stay with the old platform is too high,EI but still there are lots of VAX systems out there, and probably even more$	 68K Macs.@  ) COST is what killed off the old platform.C) COST is what killed off the old platform. ) COST is what killed off the old platform.,  E Intel is killing P3 to force a migration to P4; users/system builders D haven't switched rapidly to P4 because it is more significantly moreI expensive than P3 from a cost/performance standpoint.  Intel had forecast=H that P4 volume would be an order of magnitude higher, but there were too& many obstacles to building P4 systems.  H Now if Intel can kill off IA32 and force a migration, then everything isK cool, but the only way that Intel can do that is by buying AMD, and that isn! unlikely to happen any time soon.e  G The reason that Witek, et al, did StrongARM is that they struggled with H doing a low end Alpha for embedded purposes and concluded that it wasn'tL feasible to do a low power chip.  Assumptions within the architecture createI an environment where high power, and with high power, high cost, is builtbC in.  ARM had a different foundation which allowed applying the sameeJ technologies for performance as used by Alpha while retaining the low costJ and power.  Note that the same is true for SPARC, PowerPC, 486+, and MIPS.  K I believe that IA64 has builtin a number of penalties which will make a lowhC cost chip impractical.  In other words, a $200 chip will have lowerfG performance than a $80 Duron when you put it in a system, and the Duron J system cost will be $500 cheaper.  This penalty is greater than it was for Alpha 5 years ago.  K There are three factors that will govern adoption of the successor of IA32::                COSTv                COSTl                COSTk   ------------------------------  % Date: Mon, 09 Jul 2001 14:54:12 -0000s- From: wspencer@ap.nospam.org (Warren Spencer)o) Subject: Re: Full port of VMS to Itanium.@/ Message-ID: <tkjhck715qlo91@news.supernews.com>a  F ah13473_nospam@remove_this.sun.com (Andrew Harrison SUNUK Consultancy)2 wrote in <3B44F1F3.8DF22FDC@remove_this.sun.com>:  >  >Quite >a> >Well I won't, but the sales people who work for Sun will and = >who can refute the facts that they will be able to roll out s >to support their "FUD". > < >I have always had a problem with the term "FUD". In my view> >FUD is not based on hard fact, people who post on this group @ >have in the past been quick to complain that posts which they  : >find disagreable are FUD despite the fact that the posts $ >are undeniably based on hard fact.  >m< >Fact, the WildFire systems and Alpha boxes currently being = >sold by Compaq now have a built in obselescence date, which u. >is no longer determined by the Aplha roadmap.  J It seems reasonable that Alphas are "more obsolete" than they were before J the announcement.  But if you're going to label this as "fact", could you < explain precisely what you mean by "built in obselescence" ?   >m6 >Fact, IA-64/Tru64/OpenVMS will require new OS's/apps.  E I don't understand this one either.  How will porting OpenVMS to IPF  J require a new OS to be created?  Isn't this a porting job?  Same question 	 for apps?n   >o9 >Fact this will cost customers money. (Unless Compaq pay)s  I Do you have some additional details on the financial arrangement between rI Intel and Compaq?  If this is "fact", would you be able to share some of l your source material?-  4 >Fact there is a risk associated with the migration # >(Unless Compaq Garantee the risk).D  L In precise terms, the risk remains, regardless of guarantors.  The question J seems to be how much burden will the customer bear.  That, I expect, will  be a hot topic for some time..  4 >Now people may see these points as being FUD, sadly >they arn't. >r >Regards >Andrew Harrison >Enterprise IT Architect   -- h   Warren Spencer Senior Software Engineer The Associated Press  L ** My employer does not necessarily agree with my statements - neither do I  **   ------------------------------  % Date: Mon, 09 Jul 2001 12:03:00 -0400s+ From: "Main, Kerry" <Kerry.Main@compaq.com>h  Subject: RE: IA64 Rocks My WorldR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF48DBF4F@kaoexc01.americas.cpqcorp.net>  H >>> Valid perhaps, but should a benchmark run on a partitioned system be compared0 directly to one on a non-partitioned system? >>>   Why not?  L A customer buys a single server and wants to know that he can get an overall1 level of performance and availability out of it. t  K Does the Cust business group that approved that purchase care about how thepH techies configure it to get that level of performance and availability ?   :-)    Regards,  
 Kerry Main Senior Consultanto Compaq Canada Inc. Professional Servicesv Voice: 613-592-4660f Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----1 From: cjt & trefoil [mailto:cheljuba@prodigy.net]  Sent: July 6, 2001 7:06 PM To: Info-VAX@Mvb.Saic.Com   Subject: Re: IA64 Rocks My World     "Main, Kerry" wrote: >  > Greg,r > I > re: OPS in a box .. I think Andrew is trying to state somehow that a HWsL > partitioned system using separate OS's within the same system (and OPS) is! > somehow not a valid benchmark. n <snip>  D Valid perhaps, but should a benchmark run on a partitioned system be compared, directly to one on a non-partitioned system?   ------------------------------  # Date: Mon, 09 Jul 2001 16:59:15 GMTe. From: "mulp" <michaelpettengill@earthlink.net>  Subject: Re: IA64 Rocks My WorldD Message-ID: <Dpl27.1448$767.167154@newsread2.prod.itd.earthlink.net>  9 "Peter Boyle" <pboyle@holyrood.ed.ac.uk> wrote in messageoB news:Pine.SOL.4.33.0107082105220.23518-100000@holyrood.ed.ac.uk... >e! > On Sat, 7 Jul 2001, mulp wrote:o >  > >t9 > > "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message . > > news:9i6etb$a5h$1@pegasus.csx.cam.ac.uk...E > > > An indication of that is the vast majority of the supercomputer C > > > contracts that Compaq got were based on ES40/ES45 and even DSl3 > > > boards, usually with a Quadrics interconnect.i > >y > > That isn't true. >m& > Garbage, Nick is completely correct.4 > Look up, e.g. the SC series on the compaq website. >-J I didn't say that the CURRENT delivery plans were for wildfire, or EV7 forD that matter.  But the initial bids were won before the ES45 existed.  I The amount of traffic between nodes for some of the applications is huge.sI Wildfire can outperform quadrics between qbbs by a large enough factor to H offset the reduced bandwidth due to memory latency.  The problem is thatK wildfire's I/O isn't good enough to meet the bisection bandwidth - wildfiresK only support 33MHz PCI while ES45 supports multiple 66MHz PCIs and quadrics' can consume a 66MHz PCI bus.  F Wildfire needed PCI-X today - the investment for this was all Compaq'sJ responsibility and Compaq didn't make the investment.  But this is the wayL that Compaq operates: define a technology standard and require it, but don'tK do anything that requires investing in making it work or taking the risk ofo failing.   ------------------------------  % Date: Mon, 09 Jul 2001 12:33:23 -0500'* From: cjt & trefoil <cheljuba@prodigy.net>  Subject: Re: IA64 Rocks My World+ Message-ID: <3B49EAE3.2FF16224@prodigy.net>   N Because you can "scale out" AFTER you "scale up" but it doesn't work the otherN direction.  Taking a maximally scaled up system and replicating it will yield M yet higher performance, but once you've exhausted your ability to scale out avE system built of pieces that won't scale up any farther, you're spent.0   "Main, Kerry" wrote: > J > >>> Valid perhaps, but should a benchmark run on a partitioned system be
 > compared2 > directly to one on a non-partitioned system? >>> > 
 > Why not? > N > A customer buys a single server and wants to know that he can get an overall2 > level of performance and availability out of it. > M > Does the Cust business group that approved that purchase care about how theiJ > techies configure it to get that level of performance and availability ? >  > :-)u > 
 > Regards, >  > Kerry Main > Senior Consultanty > Compaq Canada Inc. > Professional Servicesh > Voice: 613-592-4660k > Fax  :  819-772-7036 > Email: Kerry.Main@Compaq.com >  > -----Original Message-----3 > From: cjt & trefoil [mailto:cheljuba@prodigy.net]l > Sent: July 6, 2001 7:06 PM > To: Info-VAX@Mvb.Saic.Com " > Subject: Re: IA64 Rocks My World >  > "Main, Kerry" wrote: > > 	 > > Greg,n > >oK > > re: OPS in a box .. I think Andrew is trying to state somehow that a HWeN > > partitioned system using separate OS's within the same system (and OPS) is" > > somehow not a valid benchmark. > <snip> > F > Valid perhaps, but should a benchmark run on a partitioned system be
 > compared. > directly to one on a non-partitioned system?   ------------------------------   Date: 9 Jul 2001 02:30:41 -0400 / From: jordan@lisa.gemair.com (Jordan Henderson)l. Subject: Re: IA64 volume and low-end dominance* Message-ID: <9ibj2h$9nt$1@lisa.gemair.com>  O In article <9iaevf$39o$1@pyrite.mv.net>, Bill Todd <billtodd@foo.mv.com> wrote: D >Multiple people have offered as IA64's manifest destiny a near-termK >replacement of IA32 in the low-end (desktop) arena, and used the resultingdM >volume to suggest that IA64 will have unbeatable cost advantages everywhere.yI >Leaving aside the fact that the cost of the processor(s) is only a smallhL >portion of total system costs (especially outside the low end), Iet's first3 >investigate the desktop migration question itself.  >yH >It's worth remembering that very few current desktop applications wouldL >benefit *at all* from a 64-bit address space.  Of the remainder, most wouldI >perform better if they handled their data explicitly (from disk, or fromeH >Xeon-style extended physical memory) rather than just letting it sprawlH >across a larger address space paged sub-optimally by the OS (e.g., gameH >developers are typically willing to expend such effort for the improved >performance). >hM >And of the even smaller application residue after those are removed, as longoJ >as IA32 systems constitute even a large, let alone a dominant, portion ofI >the market, developers will when at all feasible tend to create a single L >version that will run both there and (perhaps emulated) on IA64.  Even whenC >a machine is dedicated to running a single application, until someeM >significant percentage of low-end machines have more than 2 GB of *physical*dF >memory (or more than 4 GB in cases where the OS doesn't take half theH >virtual address space for its own use, or more than 64 GB if Xeon-styleC >address extensions are used), it will be a very rare desktop-styleeB >application indeed that will see significant advantages in 64-bitA >addressing:  things like high-end servers and CAD are the likelyh( >beneficiaries (just as they are today). >dM >Contrast the above situation with the move from IA16 to IA32.  That move wasnJ >hardware-technology-driven, not demand-driven:  for many years there wereK >virtually *no* 32-bit desktop applications, despite that fact that typicalmK >16-bit applications had been standing on their heads for years to make useaJ >of the megabytes of available physical memory (exactly the reverse of theJ >situation today).  Users bought 32-bit hardware mostly because it offeredJ >better performance (at little or no additional cost) running their 16-bit >OSs and 16-bit applications.h >oM >By abandoning hardware upward-compatibility in IA64, Intel has significantlynM >altered the circumstances from that earlier migration:  IA32 seems likely tohI >enjoy absolute performance advantages running 32-bit applications for atrF >least a while, and cost/performance advantages for even longer.  As aM >result, the desktop (and even low-end server) IA32 market should continue toyM >be far larger than the 64-bit market, and developers will continue to createeM >new applications for the IA32 architecture until it *really* starts to crampeM >their style (hence the probability that an IA64-only 'killer app' will light  >a migration fire is reduced). >IL >In sum, while I can imagine that Intel would *like* IA64 to replace IA32 inK >the mass market ASAP, if only to shut out AMD and simplify its own product:I >lines, it's hard to imagine that the market will let them.  Am I missing  >something critical here?a >e  C Here are some things that I think will drive IA64 onto the desktop:a  < 	- Intel's desire.  Intel will expend considerable marketing< 	  resources to convince IT decision makers that IA64 is the< 	  future, and seeing as you need a whole new set of apps to: 	  take advantage of it, you'd better get on board sooner 9 	  rather than later and this will include the desktop.  o  ; 	- Intel's engineering allocation.  Intel will work hard toh; 	  narrow the performance differences between IA64  running ( 	  IA32 apps and IA32 running IA32 apps.  8 	  Note that AMD has almost no penetration in Enterprise7 	  systems today, and even with wild growth from AMD in : 	  this area, we can still expect to see Intel calling the: 	  shots here.  As Enterprise desktops go IA64, so will go 	  many others.t  5 	  Ultimately, AMD will also develop their own 64 bitt8 	  architecture that will perhaps be somewhat compatible8 	  with IA64 (or not), but the real race between AMD and4 	  Intel will move to whose 64 bit architecture best 	  supports IA32.u  ? 	- ISVs.  The really big ISVs (the Microsofts, Oracles and CAs)n; 	  will have to expend considerable resources to field bothn< 	  IA32 and IA64 versions of their products.  Seeing as they; 	  will ultimately have to have offerings in both spaces, I @ 	  see a divergence of product lines, 'Enterprise' versions that@ 	  are IA64 and 'SOHO' versions that are IA32 only.  IT decision@ 	  makers will have to make a choice here, and that includes the< 	  choice for all the desktops that support their Enterprise	 	  wares.e  @ 	  What really drove the move from IA16 to IA32 was not customer< 	  demand for faster systems, but rather customer demand forA 	  the new system software (Windows386, OS/2, Unix) that requiredL= 	  IA32.  This is what will drive the move from IA32 to IA64.d  = 	  Add to this the fact that the big ISVs would really ratherb; 	  you buy the high-end products (and newer!) products, andr> 	  you should see attractive initial pricing for the new IA64  	  versions.  ? 	- Memory technology.  After a few years with only modest gainslD 	  in price/performance for RAM (partly due to the market recovering> 	  from a fire in Taiwanese plant a few years ago), we are now* 	  seeing rapid improvements in this area.  A 	  Middle tier desktops 2 years ago came with 64MB, today that's l= 	  256MB.  If this trend accelerates we can expect to see 4GBtC 	  desktops commonly in only a few years.  Address extension beyondmB 	  processor word size are unsatisfactory for general application E 	  development for a number of reasons.  More memory is almost always @ 	  better.  Expect to see high end and then all serious desktopsB 	  requiring standard addressing beyond what 32 bits allows within@ 	  4 years.  Once high end desktops require this, entire product9 	  lines will follow so as to allow upward compatibility.    >- bill  >  >' >o   -Jordan HendersonA jordan@greenapple.coml   ------------------------------  $ Date: Sun, 8 Jul 2001 23:51:54 -0700+ From: "Dennis O'Connor" <dmoc@primenet.com> . Subject: Re: IA64 volume and low-end dominance- Message-ID: <9ibkbh$9m5$2@nnrp1.phx.gblx.net>e  + "Bill Todd" <billtodd@foo.mv.com> wrote ...eI > It's worth remembering that very few current desktop applications wouldc/ > benefit *at all* from a 64-bit address space.t   <amused sarcasm>6 And we'll never need more than 640K of memory, either. </amused sarcasm>c --3 Dennis O'Connor                   dmoc@primenet.com . Vanity Web Page http://www.primenet.com/~dmoc/   ------------------------------  % Date: Mon, 09 Jul 2001 05:06:57 -0400 - From: Jack Patteeuw <jjpatteeuw@peoplepc.com>t. Subject: Re: IA64 volume and low-end dominance, Message-ID: <3B497431.DAF93DDA@peoplepc.com>   Bill Todd wrote: .i .  . N > By abandoning hardware upward-compatibility in IA64, Intel has significantlyN > altered the circumstances from that earlier migration:  IA32 seems likely toJ > enjoy absolute performance advantages running 32-bit applications for atA > least a while, and cost/performance advantages for even longer.    As also noted by AMD !!t   .  .O .iM > In sum, while I can imagine that Intel would *like* IA64 to replace IA32 innL > the mass market ASAP, if only to shut out AMD and simplify its own productJ > lines, it's hard to imagine that the market will let them.  Am I missing > something critical here?  
 I concur !  M One of Alpha/OSF1 least desirable feature was that it only had a 64 bit mode.g* No sloppy K&R code could easily be ported.  K Interesting reverse note:  those who did port their old K&R code to ANSI C  J using the GEM compiler as their reference found that back porting to other% 32 bit architectures was mush easier.     
 Jack Patteeuwh   ------------------------------  * Date: Mon, 9 Jul 2001 09:22:46 +0000 (UTC)/ From: Sander Vesik <sander@haldjas.folklore.ee>s. Subject: Re: IA64 volume and low-end dominance2 Message-ID: <994670570.116569@haldjas.folklore.ee>  8 In comp.arch Rob Barris <rbarris@quicksilver.com> wrote:  I >    I have read remarks that indicate that Itanium's performance on x86 l/ > code is uninspired.  But what about McKinley?h  . >    Will McKinley pull off the combination of  . >    a) running x86 software at useful speeds,  H No. I can't even recall any claims this is something McKinley will do...  I >    b) fitting into the power, audible, and thermal limits of a desktop,y  . I though some of the HP boxes were 'desktop'?   . >    c) costing less than $4000 per processor?  F The cost of the processor is AFAIK basicly arbitrary except that IntelD and it's shareholders would like nice margins, I assume. Looking at E rumour numbers posted at theregister, it will be Pentium vs. Xeon allu' over again for different cache sizes....  3 >    At present Itanium seems to miss on all three?    > Roba   --   	SanderD   FLW: "I can banish that demon"   ------------------------------  $ Date: Mon, 9 Jul 2001 06:10:48 -0400' From: "Bill Todd" <billtodd@foo.mv.com>t. Subject: Re: IA64 volume and low-end dominance( Message-ID: <9ibvnr$gtg$1@pyrite.mv.net>  6 "Dennis O'Connor" <dmoc@primenet.com> wrote in message' news:9ibkbh$9m5$2@nnrp1.phx.gblx.net...  >h- > "Bill Todd" <billtodd@foo.mv.com> wrote ...nK > > It's worth remembering that very few current desktop applications wouldv1 > > benefit *at all* from a 64-bit address space.c >h > <amused sarcasm>8 > And we'll never need more than 640K of memory, either. > </amused sarcasm>t  G To address your comment specifically, when the IBM PC was designed as a K 16-bit machine, DEC's top-end 16-bit minicomputers had supported up to 4 MBmH of physical memory for close to a decade (I assume other vendors' did asK well), so the utility of memory well beyond 640 KB was not exactly a secreteH (which is not to say that this initial limitation did not make sense forI economic reasons at the PC's introduction, simply that anyone who felt itpL would be adequate for the long term was not well-acquainted with the rest of the industry at that time).d  K So (as I said in my original post) the 16-to-32-bit transition was at least G in large part driven by the awkwardness of developing applications (and H operating systems) on an architecture that supported and made use of farL more physical memory than the virtual address space of its word length couldI address without remapping.  And even so, after the 386 appeared in (IIRC)eD 1986, it took 4 or 5 years before Microsoft came out with an OS thatJ supported 32-bit applications in any reasonable manner (Win 3.1, I think -F and that was still a 16-bit OS) and more time after that before 32-bitH applications became at all common (in fact, I'm not sure they could have3 been considered very common before Win95 appeared).n  F Contrast that time, a time when widening the word size had significantJ benefits for the systems and applications that already existed (and yet itJ *still* took half a decade for them even to begin to take advantage of it)J with today, when virtually all desktop applications run fat and happy in aF 32-bit address space and nothing but high-end servers and workstationsL (certainly not desktop units) sports anywhere nearly as much physical memory1 as an application can map directly using 32 bits.d  G So while your comment does have some amusement value, I fail to see anyo actual pertinence.   - bill   > --5 > Dennis O'Connor                   dmoc@primenet.comC0 > Vanity Web Page http://www.primenet.com/~dmoc/ >b >    ------------------------------  $ Date: Mon, 9 Jul 2001 06:58:50 -0700+ From: "Dennis O'Connor" <dmoc@primenet.com>e. Subject: Re: IA64 volume and low-end dominance- Message-ID: <9icdc1$hp0$1@nnrp2.phx.gblx.net>-  + "Bill Todd" <billtodd@foo.mv.com> wrote ...-1 > "Dennis O'Connor" <dmoc@primenet.com> wrote ...: > >u/ > > "Bill Todd" <billtodd@foo.mv.com> wrote ... M > > > It's worth remembering that very few current desktop applications wouldt3 > > > benefit *at all* from a 64-bit address space.n > >i > > <amused sarcasm>: > > And we'll never need more than 640K of memory, either. > > </amused sarcasm>d  = [... relatively irrelevant historical commentary omitted ...]h  I > So while your comment does have some amusement value, I fail to see anyy > actual pertinence.  9 If I note that PC133 SDRAM can be had for $80/GB, mention,8 Moore's "Law", and note that HDD are orders of magnitude> slower than memory _now_ and not catching up, does that help ? --3 Dennis O'Connor                   dmoc@primenet.com . Vanity Web Page http://www.primenet.com/~dmoc/   ------------------------------  % Date: Sun, 08 Jul 2001 16:25:10 -0600u+ From: Ben Franchuk <bfranchuk@jetnet.ab.ca> . Subject: Re: IA64 volume and low-end dominance, Message-ID: <3B48DDC6.E2ACA703@jetnet.ab.ca>   Dennis O'Connor wrote: > <amused sarcasm>8 > And we'll never need more than 640K of memory, either. > </amused sarcasm>o( I thought that was Mr Gates famous line.B Strange how bad memory sizing works on the intel chips.(No commentJ on how bad code bloat is on risc machines). Addressing of 128 kb of memoryI was the address space best used by the intel cpu's.( Yes all the chips ).yE You would have bloat with the 8086 chips with the segments, and sincesH the 386 still used the same instruction set,what you lost with segment &G 16 bit math you more than made up with the instruction pre-byte opcodesbH and the fact that memory offsets are only byte,and full words. I suspectF in 90% of the programs static data could be accessed by 16 bit offsets  if you sorted varibles by size.  (bytes)r (short)s (words)M (arrays and records) Ben. l   -- 6> "We do not inherit our time on this planet from our parents...!  We borrow it from our children."t< "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics.   ------------------------------   Date: 9 Jul 2001 14:57:31 GMTa From: Dan.Pop@cern.ch (Dan Pop)a. Subject: Re: IA64 volume and low-end dominance* Message-ID: <9icgor$12e$1@sunnews.cern.ch>  S In <3B497431.DAF93DDA@peoplepc.com> Jack Patteeuw <jjpatteeuw@peoplepc.com> writes:   N >One of Alpha/OSF1 least desirable feature was that it only had a 64 bit mode.+ >No sloppy K&R code could easily be ported.e  J This is not true.  The Alpha/OSF1 C compiler and the linker could generateG executable code that lived in a 32-bit address space.  This feature wasr8 explicitly intended for easy porting sloppy 32-bit code.   Dan  -- Dan Popo CERN, IT Division  Email: Dan.Pop@cern.ch '? Mail:  CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerlands   ------------------------------  # Date: Mon, 09 Jul 2001 16:59:35 GMTt. From: "mulp" <michaelpettengill@earthlink.net>. Subject: Re: IA64 volume and low-end dominanceD Message-ID: <Xpl27.1451$767.167154@newsread2.prod.itd.earthlink.net>  7 "Rob Barris" <rbarris@quicksilver.com> wrote in messagep6 news:rbarris-EC8A58.17551408072001@news.newsguy.com...6 > In article <9iaevf$39o$1@pyrite.mv.net>, "Bill Todd" > <billtodd@foo.mv.com> wrote:. >    Will McKinley pull off the combination of > . >    a) running x86 software at useful speeds,I >    b) fitting into the power, audible, and thermal limits of a desktop,m. >    c) costing less than $4000 per processor? >r3 >    At present Itanium seems to miss on all three?   2 Let's put it in terms of what it needs to deliver:8   a) running x86 code at speeds equal to an 800mhz duron$   b) with a power budget of 15 watts   c) costing less than $80   ------------------------------  # Date: Mon, 09 Jul 2001 16:59:42 GMTs. From: "mulp" <michaelpettengill@earthlink.net>. Subject: Re: IA64 volume and low-end dominanceD Message-ID: <2ql27.1452$767.167154@newsread2.prod.itd.earthlink.net>  < "Jordan Henderson" <jordan@lisa.gemair.com> wrote in message$ news:9ibj2h$9nt$1@lisa.gemair.com...9 >   Note that AMD has almost no penetration in EnterpriseH8 >   systems today, and even with wild growth from AMD in; >   this area, we can still expect to see Intel calling thei; >   shots here.  As Enterprise desktops go IA64, so will goo >   many others.  G AMD's access to the "enterprise" is as much to do with the "no one getsAK fired for buying IBM" syndrome (which did become false about 10 years ago).t  J As the economy is slowing down and "enterprises" are looking for places toE cut, the idea of buying $500 desktops using $75 duron's at 800 mhz is K looking very attractive to a lot of companies.  On the other hand, they areeL also looking at the 233-300mhz systems already on hand and are deeming those sufficient as well,   L One of the biggest limitations for AMD is the limited number of AMD chips inG Compaq's commercial line and Dell's continuing to use only Intel chips.fH Since Compaq has merged the commercial and consumer divisions, its quiteJ likely that Compaq will incorporate Duron chips into the low end, low footD print, bounded corporate desktops to cut costs and power.  This willH eventually increase AMDs presence unless Intel pushes their margins even lower.   ------------------------------  # Date: Mon, 09 Jul 2001 16:59:48 GMTa. From: "mulp" <michaelpettengill@earthlink.net>. Subject: Re: IA64 volume and low-end dominanceD Message-ID: <8ql27.1453$767.167154@newsread2.prod.itd.earthlink.net>  < "Jordan Henderson" <jordan@lisa.gemair.com> wrote in message$ news:9ibj2h$9nt$1@lisa.gemair.com...A >   What really drove the move from IA16 to IA32 was not customerh= >   demand for faster systems, but rather customer demand fornB >   the new system software (Windows386, OS/2, Unix) that required> >   IA32.  This is what will drive the move from IA32 to IA64.  F No, that isn't true.  386 systems shipped for a long time before Win95L shipped.  Win3.1 included multiple memory managers to support at least threeK different methods of mapping more than 16 bit addressing could support; thevL one that most systems used was based on 386 memory management, but that just made the systems cheaper.v  J The big thing with 386 is the data path width which was 32 bits as opposedC to 16 bits.  That made the 386 substantially faster even when doingg everything in 16 bit mode.  I I don't expect to see any demand for new software.  In fact, I'm going tosK avoid XP if possible because I expect that I will run into problems keepingoI the system running because I change the configuration significantly on my K PC.  I don't want to end up in the situation where I'm calling Microsoft inmE three years every few months to get my PC working again after anothers configuration change.a  K Businesses are probably going to find that they can get by without going to-G win/office 2k and will likely standardize on what they have today.  The H current economy has caused a lot of companies to delay upgrades and they1 will probably find that they can delay for years.h  I I have friends who are dealing with the aftermath of the dotbomb and theyoJ are telling stories of server farms of a 100 wintel systems that are beingI replaced by a pair of Sun or linux systems - it turns out that the wintelnH systems were single function systems without storage scalability runningJ mostly idle.  The costs per month are dropping from $100K per month to $5KK for these server farms.  The guys cleaning up this mess are not going to belI spending a lot of money on expensive new systems when they still have old  stuff to dispose of.   ------------------------------  % Date: Mon, 09 Jul 2001 16:56:24 +0100o  From: steven.reece@quintiles.com Subject: Re: Network Printers H Message-ID: <OF5E792002.962EF44D-ON80256A84.005660DF@qedi.quintiles.com>   David,E Different people have had success with many, many different printers.lE There are a number of methods one can use to connect them up as well.l  K Many of the bigger HP LaserJet series printers and Colour Laserjet printerseJ will print successfully using the UCX$TELNETSYM or TCPIP$TELNETSYM printerF symbionts which are supplied with the Compaq TCP/IP stack for OpenVMS.I They typically use port 9100 on the JetDirect card.  Such a configurationlD is described in the VMS FAQ, available on the Compaq OpenVMS websiteH (www.openvms.digital.com), under the heading "MGMT6 - How do I connect a PostScript printer via TCP/IP?"e  H Using DCPS v2.0 you are able to print to non-Compaq branded printers andH use the translation facitilites within DCPS without the need to have theK DCPS-PLUS and DCPS-OPEN licenses.  (This may be co-dependant upon using VMSn v7.3).  I XCD used to manufacture a network card for HP printers which replaced theiJ JetDirect card and enabled the printer to use LAT as well as TCP/IP.  I am8 not sure whether these cards are still available or not.  I One option may be to talk to a local reseller and get a printer on a sale3F or return basis - if it works then you'll pay for it and if not you'llG return it to them.  Failing that, see if any colleagues, associates etci have printers that you can try.d   Steve.   David Lee asked :  >>>oH Sorry to post this silly questions, but I am kind of new to this job andK confusing about the type of printer I should buy and of course I don't want K to buy the wrong one.  I have a couple Alpha workstations that connected tocH an ES-40 Server, running OpenVMS 7.2, my system also support both Decnet and  TCP/IP.  I want E to hook up a network printer so that they all can share.  I have been  looking at theI web, particulartly HP and Lexmark network printers.  None of the printers/> mentioned in their advertisement supporting OpenVMS platforms. My questions are,sK are there any printers out there that support this OpenVMS platform?  Or doe( I have to purchase printers from Compaq?
 Thank you. <<<o   ------------------------------  $ Date: Mon, 9 Jul 2001 09:51:16 -04002 From: "Sue Skonetski" <susan.skonetski@compaq.com>- Subject: new products from Twobyfour Softwaree2 Message-ID: <6Fi27.442$rc5.26346@news.cpqcorp.net>  7 Just received this and thought you might be interested.    suet    $                   Twobyfour Software+                   Releases New Products fors                    the VMS Market  -                   Thu Jul 5 04:30:51 2001 GMT   D                   STOCKHOLM, Sweden--(BUSINESS WIRE)--July 5, 2001--H                   Twobyfour Software, a leading developer of Application
 ManagementD                   software for business critical applications, today announced that two newA                   products for the VMS market have been released.                       --@3                      Twobyfour VMS Surveillance kitc                    --wL                      Twobyfour RTR Probe (Reliable Transaction Router Probe)    0                   Twobyfour VMS Surveillance Kit  G                   The VMS Surveillance kit is the first EMS (Enterprisea Management System)J                   independent product that enables surveillance on the VMS platform. This is-I                   performed with a minimum of CPU usage and can easily bem integrated withjK                   EMS consoles from PATROL/BMC, Tivoli/IBM, OpenView/HP ands                   Unicenter/CA.pJ                   The VMS Surveillance kit enables real time monitoring of operating systemI                   with the ability to generate alarms to an EMS frameworkr when configureds)                   thresholds are reached.vG                   Minimum and maximum thresholds can be configured withf Warning, ErrorL                   and Fatal levels, where all, none or several levels can be defined. DifferentJ                   alarm levels can be set for different times. All monitor values can be saved inL                   the process log file for easy extraction and analysis at a later stage.  I                   Twobyfour RTR Probe (Reliable Transaction Router Probe)e  L                   Reliable Transaction Router (RTR), developed by Compaq, is
 the provenH                   solution for software fault tolerance with transaction integrity at every level inpK                   your distributed network worldwide, including access overs
 the Internet.rH                   The Twobyfour RTR Probe is the first product available that probes the+K                   operational status of the RTR layered software. The Probe6 measures vitalJ                   RTR information and verifies that it is operational. The purpose of the RTRJ                   Probe is to supervise the operation of the RTR software. The RTR probe is2                   installed as a separate product.  -                   About Twobyfour Software ABo  E                   Twobyfour Software develops and markets applicationa management softwarelA                   that increases reliability in business criticalt" applications. Twobyfour Software'sJ                   products are represented by selected partners and in its own offices in SanD                   Francisco, London, Paris, Amsterdam and Stockholm. Twobyfour SoftwareK                   supplies products to some of the world's leading telecom,u banking and financetL                   companies. Twobyfour Software currently employs 50 people, the majority of J                   whom are engaged in program development. The company has an estimatedL                   turnover of 100 million SEK for 2001. For more information please visitF                   www.twobyfour.com Press releases and high-resolution
 images can ben9                   downloaded from www.twobyfour.com/press'  A                   This information was brought to you by Waymaker. http://www.waymaker.netBA                   The following files are available for download:i  C http://www.bit.se/bitonline/2001/07/05/20010705BIT00240/bit0001.docl  C http://www.bit.se/bitonline/2001/07/05/20010705BIT00240/bit0002.pdfe    F                   Copyright  2001 Business Wire. All rights reserved.   ------------------------------   Date: 9 Jul 2001 09:51:49 -0700b( From: kparris@my-deja.com (Keith Parris)! Subject: Re: Nodenames in clusterp= Message-ID: <cb85fed2.0107090851.3506ce3f@posting.google.com>i  P "Ingemar Olson " <> wrote in message news:<01K5J92BKZTG90NMI5@dairyworld.com>...G > The other thing I need to be able to find out is whether the node is   > actually up and runnings  A F$GETSYI("CLUSTER_MEMBER","XYZ") will be .TRUE. if node XYZN:: is " presently a member of the cluster.  K > Does the f$csid only return info for nodes that are "up", or will it alsolC > include (eg) nodes that it knows have been up but now may not be?n  E F$CSID only returns info for nodes which are currently up and runningo@ in the cluster.  A node which has been in the cluster but is not@ presently will not show up in the list.  (VMS does keep track ofF former members in its data structures, which you can see when you lookB at SHOW CLUSTER/CONTINUOUS, but F$CSID doesn't return these former nodes.)p  I > If it's the latter, which argument to f$getsyi will let me distinguish h1 > between the functional vs non-functional nodes?b   CLUSTER_MEMBER.c  E Note that just because a node is a member of the cluster doesn't meanc@ it is able to accept user logins (it may still be in the startupC process, or may be in the process of shutting down).  But this willt! probably cover most of your need.rC ------------------------------------------------------------------- C Keith Parris | parris at encompasserve dot org | VMS consulting on:pC Clusters, Disaster Tolerance, Internals, Perfornamce, Storage & I/Og   ------------------------------  $ Date: Mon, 9 Jul 2001 13:15:38 -04005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>c# Subject: Re: ods5 and decc$from_vmsd2 Message-ID: <qFl27.448$rc5.27979@news.cpqcorp.net>  I You need a new CRTL which doesn't come with the compiler, but which shipsnH with VMS.  A whole slew of "fixes" for ODS-5 filenames and behavior haveG been made for the COE effort.  Dunno when they will hit the street in a9 mainline release.-  H File a bug report if you can.  Otherwise send me a mail message and I'll forward it to the CRTL guy.g    @ David Mathog wrote in message <3B462F6B.2C2471B1@caltech.edu>...B >A while back I posted a little program "VMS_TO_UNIX.C" which will >convert filenames from & >VMS format to Unix format, like this: >s >$ v2u [.users...]*.*  >/usrdisk/users/auser/ >/usrdisk/users/buser/ >etc.e > D >Anyway, I just discovered that it does not work correctly with ODS5 >because it dies when it$ >hits a name like:  cab63596^..fcgi; >s >The problem comes at line:l >r+ >   (void) decc$from_vms(argv[1], emit, 1);  > I >where the emit routine is never even called with the "bad" string.  This  >is Compaq C V6.2-007 on >VMS/Alpha 7.2-1 >M	 >Regards,  > 
 >David Mathog, >mathog@caltech.eduj >    ------------------------------  % Date: Mon, 09 Jul 2001 13:59:35 -0300 ) From: fabio_compaq@ep-bc.petrobras.com.br  Subject: OpenVMS and IP Storage L Message-ID: <OF753DF5E1.66E92298-ON03256A84.005D4263@ep-bc.petrobras.com.br>  ; Any idea if OpenVMS will support IP Storage in the future ?h2 If there is the possibility  of clustering etc ???   Regardse   FC   ------------------------------  , Date: Mon, 09 Jul 2001 14:16:43 +0200 (CEST): From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl>6 Subject: Re: Porting VMS (was Itanium, non-issue, ...)J Message-ID: <Pine.LNX.4.21.0107091414330.22883-100000@irys.stanpol.com.pl>  % On Mon, 9 Jul 2001, Duane Sand wrote:o [...]m >+"Bob Koehler" replied:L >+> Not quite.  While many processors support the 4 modes VMS requires, UNIX; >+> requires only 2, and some processors still have only 2.h >+> >+IA-64 supports 4 levels; hopefully they will fit VMS's needs >+well enough.  3  Can you point a place with description like this ?e7  Have one time look for Merced archit. DOCs, have foundo2 most of user mode description - but not the answer about modes and paging.     Regards - Gotfryd   -- bE =====================================================================sF $ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") - 		THEN EXCUSE/OBJECT=MEe. $!                        GS@stanpol.zabrze.plE =====================================================================m   ------------------------------   Date: 9 Jul 2001 10:45:44 -0500 - From: koehler@encompasserve.org (Bob Koehler):6 Subject: Re: Porting VMS (was Itanium, non-issue, ...)3 Message-ID: <lfHE0kmIwnyq@eisner.encompasserve.org>e   In article <Pine.LNX.4.21.0107091414330.22883-100000@irys.stanpol.com.pl>, "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl> writes:d > 5 >  Can you point a place with description like this ? 9 >  Have one time look for Merced archit. DOCs, have founde4 > most of user mode description - but not the answer > about modes and paging.  >   B Intel's web site has this documentation.  I found it easy to find.  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporation-= NASA GSFC Flight Software       | Federal Sector, Civil Group"E                                 | please remove ".aspm" when replyingd   ------------------------------  , Date: Mon, 09 Jul 2001 16:17:55 +0200 (CEST)- From: Freddy Meerwaldt <frederik@freddym.org>i/ Subject: Problem with TCPIP 5.1 on VAX/OVMS 7.3wJ Message-ID: <Pine.LNX.4.21.0107091559210.7472-100000@firewall.freddym.org>   Hi!d  G I have got some problems with TCPIP 5.1 on a OpenVMS/VAX 7.3 VAXstation  3100.uH I keep wondering what this problem means, as I have set up other 2 VAXes; with minor differences, which are running without problems.t Here's the problem:o  . If I start tcpip after configuring it it says:   $ @sys$startup:tcpip$startup  ? %TCPIP-I-INFO, TCP/IP Services startup beginning at  9-JUL-2001q 16:52:58.02m. %TCPIP-I-NORMAL, timezone information verified= %RUN-S-PROC_ID, identification of created process is 20C0011B 1 %TCPIP-E-STARTFAIL, failed to start TCP/IP Kernel<> -TCPIP-E-INETACPERR, INETACP process error (status = 0000011C)! $ msgstat = f$message(%x0000011C)7 $ sho sym msgstatw?   MSGSTAT = "%SYSTEM-F-INSFWSL, insufficient working set limit". $   F I've already tried to increase PQL_DWSDEFAULT to 512, but that doesn't help. A The only differences between this Station and the other Stations:e   VMS Installation:oB 	- I installed the SYSHLP Database onto dka400 (and set the syshlp logical)   TCPIP Installation:e" 	- Other IP and Domain (of course)A 	- DNS is _not_ pingable (I'm setting up this machine for school)i7 	- Only the Telnet Server and some clients are enabled.c   Other Stuff:@ 	- This Machine is running DECnet/OSI (it doesn't help if I stop
 /net decnet.)l   Many thanks in advance
 Best Regards,y 	Freddyd   --  N Geek Code 3.1: GCS s+: a--- C+++ UBOU+++ P-- E--- W++ N w--- V++ PGP- t? 5? tv  J ==========================================================================D  Frederik Meerwaldt  ICQ: 83045387  Homepage: http://www.freddym.orgC  Bavaria/Germany              OpenVMS and Unix Howtos and much moreqI  Solaris, HP/UX, AIX, NetBSD, OpenBSD, IRIX, Tru64, OpenVMS, Ultrix, BeOSo   ------------------------------   Date: 9 Jul 2001 05:49:22 -0500e9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)d Subject: Re: Rdb troll3 Message-ID: <EahJ64AUXHqg@eisner.encompasserve.org>i  Z In article <3b492690$1$lllp186$mr2ice@nntp.mindspring.com>, yyyc186@mindspring.com writes:  K > What we all need is to dump every Oracle product on every platform in our<J > shops.  Oracle has been cosistently de-improving RDB until they now haveC > it just about down to the level of Oracle...a database that fails., > miserably in every aspect of business use.  C It does not fail in "profitability to the vendor", a characteristicr$ Oracle may value higher than you do.   ------------------------------   Date: 9 Jul 2001 09:26:10 -0700r( From: kparris@my-deja.com (Keith Parris) Subject: Re: Rdb troll= Message-ID: <cb85fed2.0107090826.54e0eeee@posting.google.com>m  _ yyyc186@mindspring.com wrote in message news:<3b492690$1$lllp186$mr2ice@nntp.mindspring.com>... B > Oracle has been cosistently de-improving RDB until they now have. > it just about down to the level of Oracle...  > When I looked into relational databases on VMS recently, I was< pleasantly surprised by the number and depth of features andA performance enhancements that have been added to Rdb since it was2 purchased by Oracle.  B When Oracle bought Rdb, many honestly believed they did so just to> kill it, but in fact it has thrived and grown since.  The onlyB complaints I hear are about price, but when you think about it, ifE Digital had raised the price instead of selling it off because it wasuE unprofitable, Oracle might never have gotten their hands on it in theo first place.   ------------------------------  % Date: Sun, 08 Jul 2001 10:58:51 -0700 ' From: David Mathog <mathog@caltech.edu>o: Subject: Re: Some thoughts on the recent turn of events...+ Message-ID: <3B489F5B.147083A2@caltech.edu>/   Bill Todd wrote:  B > "Ken Fairfield" <kenneth.h.fairfield@intel.com> wrote in message9 > news:3147e88a.0107061126.36adc736@posting.google.com...p >a  & > Yet more proof that Compaq is run by > chimpanzees?  O Hey, let's be fair here!   Chimps are adept at pounding prey and opponents intofJ submission with a big stick.  Field researchers have never reported that QP management possesses this skill.  And as far as I'm aware no chimp has ever beenP observed to give his big stick to an opponent. Q management  much more resemblesP the small monkeys that have to run for their lives through the treetops when the chimps go hunting.   > > L > >         I know, we're all upset that Compaq has been following Digital'sL > >     lead down the "road to hell" with  Alpha and VMS.  No marketing.  NoL > >     valuing  of  its crown jewels.  Not listening to its most loyal  andL > >     technical customers.  Not supporting  those  customers,  like  DavidL > >     Mathog, who were essentially begging to continue running VMS but gotL > >     NO  support  in  that  effort  from  Compaq  (his bitterness is wellK > >     earned!).  The fact that things didn't  _have_ to turn out this wayp3 > See?  You even knew a lot of the answer yourself.T  O I suppose I'm duty bound to report that my VMS system is in it's last couple of  days.oP The users have all been transferred to a Solaris system and I'm just keeping the  O VMS machine up for a little while longer in case I missed something.  The userseJ can't even log onto it anymore and  "seqAXP" is now an alias for a Solaris machine.. (The hardware will live again as a Linux box.)   Regards,   David Mathog mathog@caltech.edu   (I need a new signature file.)   ------------------------------  % Date: Mon, 09 Jul 2001 10:56:29 +0200m& From: Bob Marcan <bob.marcan@aster.si>: Subject: Re: Some thoughts on the recent turn of events...( Message-ID: <3B4971BD.9AB78723@aster.si>   Robert Deininger wrote:A > 9 > In article <3B474299.AFCFEDB2@ui.urban.org>, Jim Beckeri > <jbecker@ui.urban.org> wrote:n > H > > Not exactly a reply to Ken's message -- I'm just swiping his subject > > line...o > >hI > > Our organization was, before the recent turn of events, just about toeD > > buy another Alpha running OpenVMS. We're not a big shop, so thisJ > > wasn't a trivial decision. We like VMS and we like the Alpha, but whenA > > a vendor announces plans to discontinue one platform and portrF > > "everything" to another platform to be made by some other company,C > > it's just good business sense for us to re-assess our decision., >  > <snip> > H > You raised many good points.  Some of them are directly under compaq'sL > control.  I suggest you put the questions for Compaq in a nice letter, andE > send it to Rich Marcello.  Make it plain that your next alphaserverrB > purchase is ON HOLD until you see concrete movement in the right
 > directions.e > J > Keep in mind that it is less than 2 weeks since the public announcement.5 > You shouldn't expect concrete timetables yet, IMHO.    Wrong, wrong, wrong!> The timetables should be available alongside the announcement.   - Bobs   > J > Similar letters should go to the vendors of your important applications.K > They may need even more time, since they have to read Compaq's tea leavest$ > before they worry about their own. >  > -- > Robert Deininger > rdeininger@mindspring.com    -- e@  Bob Marcan                           mailto:bob.marcan@aster.si?  Aster                                tel:    +386 (1) 5894-329C?  Nade Ovcakove 1                      fax:    +386 (1) 5894-201 @  1000 Ljubljana, Slovenia                    http://www.aster.si   ------------------------------  % Date: Mon, 09 Jul 2001 16:41:05 +0200o& From: Michael Joosten <joost@c-lab.de>" Subject: Re: The Alpha/IA64 Hybrid$ Message-ID: <3B49C281.33FA@c-lab.de>   Dennis Ritchie wrote:y > $ > Michael Joosten wrote [of libdbm]: >  ...J > > Compared with C-ISAM they are very poor. C-ISAM has about 20 functionsL > > in its API, locking, erasing of records, multi-part keys, even secondary' > > index files for a single ISAM file.  > >rL > > So, one could think of libdbm as a 'poor university's implementation' of > > ISAM...  > - > libdbm is certainly no substitute for ISAM.e > 1 > > > are they typically part of the C run-time ?  > >r   > E > For the record, libdbm is a Ken-Thompsonism, was in Seventh EditioniI > and 32V, and picked up by Berkeley from there.  It doesn't seem to havev@ > been adopted for the early System V releases, but it reappearsC > in System Vr4 in a place suggesting that it repatriated from UCB.r >   F Pheww. At least not completely wrong... My ignorance (of youth) of theE pre-SVR ages shows. Should have said 'seems to be a BSDism'. So, it'sEH just another case of funny ways of inheritance in the UNIX family, isn't it?      -- e* 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: 8 Jul 2001 22:38:05 CDTn= From: wayne@tachysoft.xxx.320117.killspam.015d (Wayne Sewell)n7 Subject: Re: the tcp node name versus the vms node name . Message-ID: <Nk72$lggaI3c@tachxxsoftxxconsult>  r In article <Pine.LNX.4.33.0107081212070.19811-100000@vger.vgersoft.com>, Steve Thompson <smt@twcny.rr.com> writes:$ > On 8 Jul 2001, Wayne Sewell wrote: > w >> In article <Pine.LNX.4.33.0107071648010.32720-100000@ibmbox.vgersoft.com>, Steve Thompson <smt@twcny.rr.com> writes:T* >> > On 7 Jul 2001, Larry Kilgallen wrote: >> >t >> >> In article <jDtSEaHye7t6@tachxxsoftxxconsult>, wayne@tachysoft.xxx.320117.killspam.015d (Wayne Sewell) writes: >> >>uT >> >> > Since all of the vms stacks will automatically append the domain name to dns, >> >> > lookups as needed, I'm assuming that >> >> >w+ >> >> > 	$ this_node = f$getsyi("NODENAME")b >> >> > 	$ nslookup 'this_node't >> >> >tT >> >> > will always work, assuming the correct domain name (the one matching the dns4 >> >> > entries) has been configured into the stack. >> >> D >> >> It should be possible to run an IP node without any DNS entry. >> >@ >> > And then you have systems with multiple network interfaces. >>F >> What's that got to do with it?  We're talking about name to addressR >> translation.  The multiple addresses aren't necessarily reflected in the dns orR >> host table entry for that node.  If you do a gethostbyname, you assume that youR >> get back an ip address that will work.  What we're talking about the differenceL >> between gethostbyname(<node.domain.name>) and just gethostbyname(<node>). >> >> Wayne > L > I have seen examples of systems with two interfaces where the SCSNODE was,K > say, NODE, and the two IP addresses (assuming no aliases) were in the DNSiI > as "NODE-interface", there being no entry for just plain "NODE". No, it ! > wasn't something that I set up.   M I see.  Well, that basically answers my question.  I can't depend on rational4N behavior and will have to provide an alternate mechanism for tcp/ip.  I should have known.      --  O ===============================================================================-M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxh: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-) O ===============================================================================t? Flounder: "I can't believe I threw up in front of Dean Wormer." >    Otter: "Face it, Flounder.  You threw up *on* Dean Wormer."   ------------------------------  # Date: Mon, 09 Jul 2001 17:41:18 GMTn. From: "mulp" <michaelpettengill@earthlink.net>7 Subject: Re: the tcp node name versus the vms node name D Message-ID: <21m27.1540$767.175472@newsread2.prod.itd.earthlink.net>  J "Wayne Sewell" <wayne@tachysoft.xxx.320117.killspam.015d> wrote in message( news:Nk72$lggaI3c@tachxxsoftxxconsult...J > In article <Pine.LNX.4.33.0107081212070.19811-100000@vger.vgersoft.com>,) Steve Thompson <smt@twcny.rr.com> writes:L& > > On 8 Jul 2001, Wayne Sewell wrote: > >> In article E <Pine.LNX.4.33.0107071648010.32720-100000@ibmbox.vgersoft.com>, Stevee# Thompson <smt@twcny.rr.com> writes:n, > >> > On 7 Jul 2001, Larry Kilgallen wrote:6 > >> >> In article <jDtSEaHye7t6@tachxxsoftxxconsult>,? wayne@tachysoft.xxx.320117.killspam.015d (Wayne Sewell) writes:i, > >> >> > $ this_node = f$getsyi("NODENAME")  > >> >> > $ nslookup 'this_node'I > > I have seen examples of systems with two interfaces where the SCSNODE- was,I > > say, NODE, and the two IP addresses (assuming no aliases) were in thed DNSgK > > as "NODE-interface", there being no entry for just plain "NODE". No, it # > > wasn't something that I set up.- >-F > I see.  Well, that basically answers my question.  I can't depend on rationalI > behavior and will have to provide an alternate mechanism for tcp/ip.  Il should
 > have known.p  J There is a function for finding out all the IP addresses, interfaces, etc.K for a node.  The code for it is relatively straight forward.  UnfortunatelyoI I'm drawing a blank on it and I don't have access to the notes file whichi has the information in it.  : This is a call which is the unix equivalent to $getsyi....  J Direct the question to Myth in the ..ucx conference: How do I find all the( hostnames and address aliases on a node?   ------------------------------  $ Date: Mon, 9 Jul 2001 11:06:08 -0400- From: "Peter Weaver" <peter.weaver@stelco.ca>iA Subject: VBN 397: Invalid bucket address sample in bucket header.s4 Message-ID: <BLj27.261118$Z2.3120513@nnrp1.uunet.ca>  B We had a hard disk fail last week and recovered our latest backup.I Unfortunately we had one file that had been updated since the last backup J and the user asked if we could grab it off of the failed drive. Since thenH we have had an invalid bucket in the file. The programmers have tried toJ recover the data, but are now asking me if I can help. Can anyone give any6 thoughts on what we can do to recover this? (VAX V7.1)   $ANA/RMS PETER.BAD .m .a ._ Key Segments: 1o Key Size: 10 Minimum Record Size: 10t3 Index Fill Quantity: 4096, Data Fill Quantity: 40960 Segment Positions: 0 Segment Sizes: 10a Data Type: stringp Name: "" First Data Bucket VBN: 10t< *** VBN 397: Invalid bucket address sample in bucket header.= *** VBN 397: Invalid first free byte offset in bucket header.16 *** VBN 397: Next-bucket pointer out of range of file.5 Unrecoverable error encountered in structure of file.      -- Peter WeaverJ Using a WIN NT/WIN 2000 box to manage your VMS systems is like towing your6 mechanic in a 5th wheel motor home behind your Porche.   ------------------------------   Date: 9 Jul 2001 06:51:30 -0700   From: alanb@cloud9.net (Alan B.)0 Subject: Re: VMS 7.3/Alpha boot bugcheck problem< Message-ID: <88599d89.0107090551.ea36abd@posting.google.com>   "Koska, John C. (LNG-MBC)" <John.C.Koska@lexisnexis.com> wrote in message news:<3D35AD137AAAD411A6BA0008C7B1B12D01602167@MBCALBEXC03.BENDER.COM>...o > > -----Original Message-----4 > > From: alanb@cloud9.net [mailto:alanb@cloud9.net]* > > Sent: Wednesday, June 27, 2001 8:37 AM > > To: Info-VAX@Mvb.Saic.Com=4 > > Subject: Re: VMS 7.3/Alpha boot bugcheck problem > > 
 > > <SNIP> > > H > > CPQ informs me that if system_check is not 0, 7.3 may bugcheck...per > > VMS engineering. > >  > > Alan > F > Thanks for that tidbit.  I just checked what system_check was on my > > 2100A.  It is at 0, so I believe the problem lies elsewhere. > L > A this point, it does not appear to be allocation class, system_check, or I > a fragemented system disk. (I did a backup/image and restore via tape, 1L > and still have bugcheck when system disk is enabled for volume shadowing.) > H > My thought is that there is some interaction between the Mylex DAC960 0 > controller and volume shadowing a system disk. > I > I have sent a full system dumpfile to Compaq, so hopefully they will be 5 > able to ascertain in some time what the problem is.i >  > :) jck > John Koska > Matthew Bender & Co., Inc. -$ >   A Member of the LexisNexis Group > 1275 Broadway- > Albany, NY  12204  > USA  > 518-487-3255 > John.C.Koska@lexisnexis.com  > , > "I post personal opinion only, and all the, > disclaimers one could imagine apply.  That* > includes, I speak for myself only and my, > views in no way represent my employer(s)."    D Try setting niscs_load_pea0 to 0. That corrected the bug check on myB system. I continued with the upgrade, it invoked autogen as usual,F then I set the parameter back to 1 for LAN clustering. The system then booted OK with no crash.   ------------------------------  % Date: Mon, 09 Jul 2001 10:46:43 -0400p> From: "Koska, John C. (LNG-MBC)" <John.C.Koska@lexisnexis.com>0 Subject: RE: VMS 7.3/Alpha boot bugcheck problemM Message-ID: <3D35AD137AAAD411A6BA0008C7B1B12D016021A0@MBCALBEXC03.BENDER.COM>t   > -----Original Message-----2 > From: alanb@cloud9.net [mailto:alanb@cloud9.net]% > Sent: Monday, July 09, 2001 9:52 AMn > To: Info-VAX@Mvb.Saic.ComS2 > Subject: Re: VMS 7.3/Alpha boot bugcheck problem > ; > "Koska, John C. (LNG-MBC)" <John.C.Koska@lexisnexis.com> E > wrote in message p@ > news:<3D35AD137AAAD411A6BA0008C7B1B12D01602167@MBCALBEXC03.BEN
 > DER.COM>...s  > > > -----Original Message-----6 > > > From: alanb@cloud9.net [mailto:alanb@cloud9.net], > > > Sent: Wednesday, June 27, 2001 8:37 AM > > > To: Info-VAX@Mvb.Saic.Comd6 > > > Subject: Re: VMS 7.3/Alpha boot bugcheck problem > > >  > > > <SNIP> > > > < > > > CPQ informs me that if system_check is not 0, 7.3 may  > bugcheck...per > > > VMS engineering. > > > 
 > > > Alan > > H > > Thanks for that tidbit.  I just checked what system_check was on my @ > > 2100A.  It is at 0, so I believe the problem lies elsewhere. > > = > > A this point, it does not appear to be allocation class,   > system_check, or y9 > > a fragemented system disk. (I did a backup/image and C > restore via tape, < > > and still have bugcheck when system disk is enabled for  > volume shadowing.) > > = > > My thought is that there is some interaction between the Q > Mylex DAC960 a2 > > controller and volume shadowing a system disk. > > ? > > I have sent a full system dumpfile to Compaq, so hopefully B > they will be7 > > able to ascertain in some time what the problem is.- > > 
 > > :) jck > > John Koska  > > Matthew Bender & Co., Inc. -& > >   A Member of the LexisNexis Group > > 1275 Broadwayl > > Albany, NY  12204X > > USAr > > 518-487-3255 > > John.C.Koska@lexisnexis.com1 > > . > > "I post personal opinion only, and all the. > > disclaimers one could imagine apply.  That, > > includes, I speak for myself only and my. > > views in no way represent my employer(s)." >  > F > Try setting niscs_load_pea0 to 0. That corrected the bug check on myD > system. I continued with the upgrade, it invoked autogen as usual,H > then I set the parameter back to 1 for LAN clustering. The system then > booted OK with no crash. >   G For me, setting NISCS_LOAD_PEA0 to 0 allows my2100A that has all ready iJ been upgraded to OpenVMS 7.3 to use volume shadowing with the system disk.E If NISCS_LOAD_PEA0 is set to 1, then the OpenVMS 7.3 system bugcheckseG with PROCGONE on the LANCP process when trying to volume shadowing the r system disk.  H Thanks for the suggestion.  Your case and mine are very similar, but not quite the same..   :) jck
 John Koska Matthew Bender & Co., Inc. -"   A Member of the LexisNexis Group
 1275 Broadwayr Albany, NY  12204r USAd 518-487-3255 John.C.Koska@lexisnexis.comd  * "I post personal opinion only, and all the* disclaimers one could imagine apply.  That( includes, I speak for myself only and my* views in no way represent my employer(s)."   ------------------------------  % Date: Mon, 09 Jul 2001 13:35:46 -0400i, From: Steve Lionel <Steve.Lionel@compaq.com>D Subject: Re: Wailing and moaning.... (was: Compilers go to Intel...)8 Message-ID: <voqjktcmm6e7p1aaifdjl3le2crqgbgn65@4ax.com>  5 On Fri, 06 Jul 2001 10:26:09 GMT, "Nikita V. Belenki"  <public@kits.net> wrote:  L >So Intel *will* have the right to collect royalties for hobbyist use of itsE >compilers on VMS. I doubt that Intel will pursue this right, though.F  ? No - as I understand it, VMS compiler products will be owned by3F Compaq, not Intel.  Compaq alone gets to decide how they are licensed.    - Steve Lionel (mailto:Steve.Lionel@compaq.com)t Fortran Engineeringi* High-Performance Technical Computing Group& Compaq Computer Corporation, Nashua NH  6 Compaq Fortran web site: http://www.compaq.com/fortran   ------------------------------   Date: 9 Jul 2001 06:01:14 -0500b9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)mO Subject: Re: Wailing and moaning.... (was: Some thoughts on the recent turn...)e3 Message-ID: <bV4jlg$eNGl5@eisner.encompasserve.org>   Q In article <3B4971BD.9AB78723@aster.si>, Bob Marcan <bob.marcan@aster.si> writes:d > Robert Deininger wrote:   K >> Keep in mind that it is less than 2 weeks since the public announcement. 6 >> You shouldn't expect concrete timetables yet, IMHO. >  > Wrong, wrong, wrong!@ > The timetables should be available alongside the announcement.  B Even with the small number of Compaq employees who knew about thisD in advance, there were already leaks.  Meaningful timetables are not@ possible without involving more people. Do you really think Mark> Gorham, Rich Marcello or Michael Capellas knows the differenceA between Alpha and IA64 page table mechanisms and how long it wills; take to port the section of VMS code that deals with them ?n  A If there had been more people involve, there would have been more A leaks over a longer period of time, and this newsgroup would havee" had even more wailing and moaning.   ------------------------------  $ Date: Mon, 9 Jul 2001 07:03:34 -0400) From: "Neil Rieck" <n.rieck@sympatico.ca> O Subject: Re: Wailing and moaning.... (was: Some thoughts on the recent turn...) : Message-ID: <P7g27.5667$gb6.1033729@news20.bellglobal.com>  F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:bV4jlg$eNGl5@eisner.encompasserve.org...i [snip] > Do you really think Mark@ > Gorham, Rich Marcello or Michael Capellas knows the differenceC > between Alpha and IA64 page table mechanisms and how long it willi= > take to port the section of VMS code that deals with them ?  [snip]  H Nope. I suspect that execs at GM have more technical understanding aboutJ their own products than these guys have about any computer products. (Hey,K both architectures have registers and use electricity; what's the problem?)u  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/    ------------------------------   Date: 9 Jul 2001 08:45:13 -0500 9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)mO Subject: Re: Wailing and moaning.... (was: Some thoughts on the recent turn...)p3 Message-ID: <FYCORJ7T+9$$@eisner.encompasserve.org>   f In article <P7g27.5667$gb6.1033729@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes: > H > "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message/ > news:bV4jlg$eNGl5@eisner.encompasserve.org...n > [snip] >> Do you really think MarkwA >> Gorham, Rich Marcello or Michael Capellas knows the differenceuD >> between Alpha and IA64 page table mechanisms and how long it will> >> take to port the section of VMS code that deals with them ? > [snip] > J > Nope. I suspect that execs at GM have more technical understanding aboutF > their own products than these guys have about any computer products.  / Automobiles are simpler than operating systems..# That is why they are more reliable.    ------------------------------   Date: 9 Jul 2001 10:47:59 -0500 - From: koehler@encompasserve.org (Bob Koehler)oO Subject: Re: Wailing and moaning.... (was: Some thoughts on the recent turn...) 3 Message-ID: <YjOIhTHXgRke@eisner.encompasserve.org>   o In article <FYCORJ7T+9$$@eisner.encompasserve.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:e > 1 > Automobiles are simpler than operating systems..% > That is why they are more reliable.e  3 I've never seen an automobile run 18 years nonstop.   F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporationb= NASA GSFC Flight Software       | Federal Sector, Civil Group E                                 | please remove ".aspm" when replyingp   ------------------------------   Date: 9 Jul 2001 11:13:16 -0500m9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)aO Subject: Re: Wailing and moaning.... (was: Some thoughts on the recent turn...)r3 Message-ID: <1n1lldVjbd1+@eisner.encompasserve.org>S  c In article <YjOIhTHXgRke@eisner.encompasserve.org>, koehler@encompasserve.org (Bob Koehler) writes:oq > In article <FYCORJ7T+9$$@eisner.encompasserve.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:a >> r2 >> Automobiles are simpler than operating systems.& >> That is why they are more reliable. > 5 > I've never seen an automobile run 18 years nonstop.b  A Try averaging across _all_ the computers in use today and all theaB automobiles in use today.  I believe Microsoft has a larger market share than Yugo.   ------------------------------   Date: 9 Jul 2001 01:52:19 -0700a( From: kparris@my-deja.com (Keith Parris), Subject: Re: What about performance issues??= Message-ID: <cb85fed2.0107090052.2fcf4676@posting.google.com>X  W "Bill Todd" <billtodd@foo.mv.com> wrote in message news:<9i2k58$544$1@pyrite.mv.net>...e7 > "Keith Parris" <kparris@my-deja.com> wrote in messagel9 > news:cb85fed2.0107050734.4eca2e2c@posting.google.com....G > > HSJ50s don't have mirrored cache.  We covered for that by shadowingr- > > across different pairs of controllers ...S > M > That's certainly reasonable, given *independent and reliable* power to eachl
 > controller.>  @ These were at datacenters 130 miles apart, each with generators.  B > Main-memory file-level cache (as Unix uses), however, might wellJ > make a noticeable difference (you could tell by setting up RMS to do the< > caching and comparing uncached SSD performance with that).  C Oh, we had RMS global buffers set up -- the I/O rates I was quoting E were the physical I/Os to the disks; we had 90+% hit rates in the RMSa? global buffer cache at the same time, so the I/O rate up at thesD application level was much higher.  I/O response times (according toA DECps) averaged 0.3 to 0.5 milliseconds, even with I/Os averagingm roughly 6 KB in size.t  @ > > If VMS I/O was really slow and inefficient, we wouldn't haveA > > been able to drive the SSDs to the level of I/O rates we saw.n > L > The whole discussion has been comparative, not absolute.  You can't make aN > statement that's relevant to it without running comparative tests on VMS andL > Unix and including configuration data with the results so that the reasons > can be analyzed.  F It'd be a bit tricky today to set up a long-distance disaster-tolerant$ cluster on Unix to compare with. :-)  D I was addressing the sweeping "VMS I/O is slow" generalizations, andF not criticizing any specific benchmark comparisons with Unix.  I thinkE VMS needs work in the area of I/O, too, but hate to see anyone misled : into thinking it is impossible to achieve fast I/O on VMS.  F I think the most crucial area of I/O scalability and performance todayF in VMS is the area of spinlock contention / CPU 0 saturation / high MP Synch time.wF A higher-performance (yet low-overhead) replacement for CI hardware is* also a big need for high-end VMS clusters.  B Over the last 2-4 years, it appears we were having more difficulty> with locking being a bottleneck than the actual I/O operationsF themselves.  Elinor Woods has done some excellent work lately (7.2-1H1D and later) in RMS in reducing lock rates required for RMS files with5 global buffers, and reducing lock contention as well.u   Keith:   ------------------------------  $ Date: Mon, 9 Jul 2001 06:24:33 -0400' From: "Bill Todd" <billtodd@foo.mv.com> , Subject: Re: What about performance issues??( Message-ID: <9ic0hj$h5o$1@pyrite.mv.net>  5 "Keith Parris" <kparris@my-deja.com> wrote in message37 news:cb85fed2.0107090052.2fcf4676@posting.google.com...h   ...<  F > I was addressing the sweeping "VMS I/O is slow" generalizations, andH > not criticizing any specific benchmark comparisons with Unix.  I thinkG > VMS needs work in the area of I/O, too, but hate to see anyone misledr< > into thinking it is impossible to achieve fast I/O on VMS.  G I have tried to be very careful to qualify every statement I've made assL criticizing VMS's *default* file-access performance (including RMS effects),I and to note at least reasonably frequently that if you're willing to makeNH the effort *most* deficiencies can be avoided (though I suspect that theI path-length through RMS is a non-negligible burden in cases where no diskpI access is involved).  David, while he's sometimes less careful to qualifyeA every statement, has I think also complained mostly about defaultl> performance (and the degree of effort required to improve it).   >iH > I think the most crucial area of I/O scalability and performance todayH > in VMS is the area of spinlock contention / CPU 0 saturation / high MP
 > Synch time.oH > A higher-performance (yet low-overhead) replacement for CI hardware is, > also a big need for high-end VMS clusters.  C As one who has been emphasizing the importance of the high end here C recently, I won't disagree.  But most of the discussion about VMS'slH comparatively poor I/O performance had nothing to do with very-high-loadC situations of the kinds you mention above but with caching behavior<F applicable right down to the desktop level.  And the just-released andC still-planned XFC enhancements are far more important to that area.t   - bill   ------------------------------  % Date: Mon, 09 Jul 2001 08:36:57 -0400t+ From: "Main, Kerry" <Kerry.Main@compaq.com>c, Subject: RE: What about performance issues??R Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4AD7EDE@kaoexc01.americas.cpqcorp.net>  J As Keith Mentioned, there are a considerable number of enhancements in VMS- V7.3 that relate to performance enhancements.o  5 Here is pointer to a summary of the SMP enhancements:PL http://www.openvms.compaq.com:8000/73final/6620/6620pro_003.html#penguin_inf on  E The new features guide for VMS V7.3 (which has a description of other & performance features) can be found at:E http://www.openvms.compaq.com:8000/73final/6620/6620pro_contents.htmls   Regards,    
 Kerry Main Senior Consultantd Compaq Canada Inc. Professional Services  Voice: 613-592-4660k Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----6 From: kparris@my-deja.com [mailto:kparris@my-deja.com] Sent: July 9, 2001 4:52 AM To: Info-VAX@Mvb.Saic.Comc, Subject: Re: What about performance issues??    2 "Bill Todd" <billtodd@foo.mv.com> wrote in message$ news:<9i2k58$544$1@pyrite.mv.net>...7 > "Keith Parris" <kparris@my-deja.com> wrote in messagel9 > news:cb85fed2.0107050734.4eca2e2c@posting.google.com....G > > HSJ50s don't have mirrored cache.  We covered for that by shadowing - > > across different pairs of controllers ...1 > H > That's certainly reasonable, given *independent and reliable* power to each
 > controller.l  @ These were at datacenters 130 miles apart, each with generators.  B > Main-memory file-level cache (as Unix uses), however, might wellJ > make a noticeable difference (you could tell by setting up RMS to do the< > caching and comparing uncached SSD performance with that).  C Oh, we had RMS global buffers set up -- the I/O rates I was quotinghE were the physical I/Os to the disks; we had 90+% hit rates in the RMSe? global buffer cache at the same time, so the I/O rate up at thelD application level was much higher.  I/O response times (according toA DECps) averaged 0.3 to 0.5 milliseconds, even with I/Os averaging  roughly 6 KB in size.u  @ > > If VMS I/O was really slow and inefficient, we wouldn't haveA > > been able to drive the SSDs to the level of I/O rates we saw.m > L > The whole discussion has been comparative, not absolute.  You can't make aJ > statement that's relevant to it without running comparative tests on VMS andnL > Unix and including configuration data with the results so that the reasons > can be analyzed.  F It'd be a bit tricky today to set up a long-distance disaster-tolerant$ cluster on Unix to compare with. :-)  D I was addressing the sweeping "VMS I/O is slow" generalizations, andF not criticizing any specific benchmark comparisons with Unix.  I thinkE VMS needs work in the area of I/O, too, but hate to see anyone misledk: into thinking it is impossible to achieve fast I/O on VMS.  F I think the most crucial area of I/O scalability and performance todayF in VMS is the area of spinlock contention / CPU 0 saturation / high MP Synch time.,F A higher-performance (yet low-overhead) replacement for CI hardware is* also a big need for high-end VMS clusters.  B Over the last 2-4 years, it appears we were having more difficulty> with locking being a bottleneck than the actual I/O operationsF themselves.  Elinor Woods has done some excellent work lately (7.2-1H1D and later) in RMS in reducing lock rates required for RMS files with5 global buffers, and reducing lock contention as well.n   KeithM   ------------------------------   Date: 9 Jul 2001 00:46:50 -0700D( From: kparris@my-deja.com (Keith Parris)- Subject: Re: Write record to accounting file?a= Message-ID: <cb85fed2.0107082346.64966eb2@posting.google.com>d  w Kuff@Tessco.Com (Hal Kuff) wrote in message news:<8466AD1DE9452F59.AB22DD2F757A06C0.5C525EB7E8134524@lp.airnews.net>...oM > I'm looking for some sample code (VMS-BASIC) would be nice to send a recordsJ > to the accounting file... looks like $SNDJBC, but don't seem to see what! > item list needs to be built....f  ; You're on the right track.  Use $SNDJBCW with function code A SJC$_WRITE_ACCOUNTING to write an accounting record.  In the item F list, use the SJC$_ACCOUNTING_MESSAGE item code and supply a buffer ofE 1-255 characters containing your message, which will be placed in thed$ accounting file as a "user message".  C IIRC, there was originally a $SNDACC system service, but that's now + obselete and superceded by $SNDJBC support.t   Keithb   ------------------------------  # Date: Mon, 09 Jul 2001 12:11:04 GMTtB From: Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP>2 Subject: Re: Writing to OPA0: from a device driver7 Message-ID: <sbh27.12408$Kf3.128236@www.newsranger.com>   , On Fri, 06 Jul 2001 21:31:39 GMT, in article: <3b462d1a.6344122@news.process.com>, Hunter Goatley wrote: >lK >The main reason Ed & I wrote our series for DSJ was to provide information1I >that isn't readily documented or easily found.  Unfortunately, a planned H >book never materialized, thanks to some bad promises we'd received from< >Digital Press, and so the articles are no longer available. >tJ >Technically, they're owned by Cardinal Business Media, but they no longerI >exist, and my last efforts to track down somebody who could authorize merH >to post them on a web site failed.  If there's interest, I may just putF >them up until someone from CBM asks me to take them down, which would >probably never happen.a >   G I would be interested in seeing these articles, provided you won't have_$ problems from making them available.   Simon.   -- e; Simon Clubley, simon_clubley@remove_me.excite.com-Earth.UFPaK Worrying idea #101: What if Microsoft goes into the Ada compiler business ?a   ------------------------------  $ Date: Mon, 9 Jul 2001 12:32:43 -04005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>p2 Subject: Re: Writing to OPA0: from a device driver2 Message-ID: <e1l27.446$rc5.27342@news.cpqcorp.net>  L Use the broadcast call if you are at a low enough IPL.  Reserve the high-IPLL CON$ stuff for truly CRITICAL system messages, or debugging.  ALSO note that8 you should be on the PRIMARY CPU to make the CON$ calls.        H Hunter Goatley wrote in message <3b4473ce.176341756@news.process.com>...F >On 5 Jul 2001 09:21:52 -0500, koehler@encompasserve.org (Bob Koehler) wrote: >iE >>In article <s4I07.7053$Kf3.69664@www.newsranger.com>, Simon Clubley 6 <simon_clubley@remove_me.excite.com-Earth.UFP> writes: >>>vI >>> What are the various methods used by VMS device drivers to write (for. example,K >>> debugging text) to the system console and which method do people preferm ?e >>H >>Generally they don't.  It's somewhat difficult in any device driver to: >>write to any device other than the one being controlled. >>B >>I've got device drivers that use the OPCOM mailbox, they haven'tI >>successfully sent out a message in years.  I haven't bothered debugging:: >>this because the messages they did send out are useless. >>F >If you want a real way to write to the actual console and not just to OPCOM,H >there are (I think still undocumented) routines that will do just that.J >They can be called from device IPL and they write directly to the console >device. >cH >I wrote about this in the January 1995 issue of DIGITAL SYSTEMS JOURNALF >as part of my series (co-authored with Ed Heinrich) on writing kernelG >mode code.  In the assumption that others might find it useful, here'sm6 >the section of the article discussing these routines. >aL >(I also have some MACRO macros that make using these routines even simpler;I >if you'd like to see those, drop me a line and I'll e-mail them to you.)y >aL >=========================================================================== ====% >1.4  Writing Messages to the Console  >MB >Invoking XDELTA while debugging systems code works very well, butF >there are cases when it is not practical to use XDELTA. One such caseF >is a device driver that interacts with an external peripheral device.F >If the device driver starts some operation on the peripheral and thenE >invokes XDELTA, the system will stop, but the peripheral may not. By-F >the time the system is allowed to continue, the peripheral may or mayC >not still be in the desired state, which can skew testing with the(E >peripheral. In cases like this, messages to the system error log may.E >be useful, but they cannot be examined in "real-time"; the error loge= >buffers must be flushed to disk before they can be examined.m >sC >A time-honored method of debugging is the writing of informationaleG >messages to a video or hardcopy terminal. Such messages could indicategG >which subroutine is executing or the status of certain operations. ForMF >example, it is not uncommon when writing applications code to write a >routine like the following: >i >--------------------d >     .  >     .s >  int do_the_work (int x) >  {  int i; >h' >     printf("Inside do_the_work()\n");c >     for (i = 0; i < x; i++)  >        printf("%d\n", i);l >C( >     printf("Leaving do_the_work()\n"); >p >     return 1;  >  } >--------------------- >-@ >When the program calling this routine is run, the informational= >messages "Inside do_the_work()"  and "Leaving do_the_work()"gA >will be written to the current output device. This can speed theRB >debugging process---if the second message is never printed, there> >must be a problem inside the loop that keeps it from exiting. >iG >Obviously, any method that uses RMS to do the output is of limited-usen@ >in privileged code, since a kernel-mode routine cannot call theF >executive-mode RMS services. $QIO system service calls would work forE >process-context code that is not executing at elevated IPL. But whataC >about real systems code, that may not have any process context andhG >executes at elevated IPL? These code threads can write output directlyvB >to the system console using some little-known executive routines. >u  >1.4.1  The Console I/O Routines > G >OpenVMS module [SYS]CONSOLIO.LIS contains I/O routines for the consolemG >terminal.  On a VAX, the routines all expect the address of a terminal7? >device's CSR (Control Status Register) to be passed in generalcC >register R11. If R11 has the value 0, the system console device is.A >used by calling CPU-specific routines named beginning with CON$.t >eF >Under OpenVMS AXP, the CSR address is ignored by the EXE$ console I/OD >routines. The system console device is used for all I/O operations.C >Also, the OpenVMS AXP source module [OPDRIVER] contains the sourcer. >code for OPDRIVER, the console device driver. >-= >The characters are written and read from the physical device-C >registers, bypassing the normal device drivers for the device. TheAF >console I/O routines should be called from device IPL or higher, withG >any spinlock held. This makes them ideal for use in device drivers and-E >other elevated-IPL code. The routines will work for non-elevated IPLeF >as long as the system console is not being used for other purposes at >that time.a >SA >Table 1-2 describes the EXE$ routines for writing to the consolenF >terminal. However, before the routines can be called, interrupts mustE >be disabled on the console and then re-enabled. This is accomplishedY? >by calling two CON$ routines: CON$SAVE_CTY to save the currentnC >settings, and CON$RESTORE_CTY to restore the saved settings. Thesea? >routines are defined in OPDRIVER (found in [SYSLOA] in the VAX D >listings and [OPDRIVER] in the AXP listings). CON$SAVE_ CTY returnsE >the current console state in R0 and R1; CON$RESTORE_ CTY expects theu) >console state to be passed in R0 and R1.  >kC >Table_1-2:__EXE$_Console_I/O_Routines_____________________________  >1C >Routine_______________Description_________________________________R >WG >EXE$OUTBYTE           Convert and output hex byte (value passed in R1)@K >EXE$OUTHEX            Convert and output hex longword (value passed in R1)w- >EXE$OUTBLANK          Output blank characterr@ >EXE$OUTCHAR           Output character (character passed in R0)< >EXE$OUTCRLF           Output carriage return/line feed pairC >EXE$OUTCSTRING        Output counted string (address passed in R1)e= >EXE$OUTZSTRING        Output zero terminated string (address,C >______________________passed_in_R1)_______________________________h > F >Example 1-5 shows a VAX MACRO-32 module that defines two subroutines,G >PUT_CONSOLE_ASCIC and PUT_CONSOLE_HEX. These routines save the currentaA >console state, perform the specified output with some additionalnF >linefeeds and carriage returns, then restore the saved console state.A >The following fragment shows how these routines would be called:i >  >--------------------a3 >  MSG:    .ASCIC  /This is a test console message/t >          . >          .< >          MOVAQ   MSG,R0     ; Get address of ASCIC messageD >          JSB     PUT_CONSOLE_ASCIC       ; Write it to the console >          . >          .A >          MOVL    #^XDEAD00ED,R0          ; Move the value to R0eD >          JSB     PUT_CONSOLE_HEX         ; Write it to the console >          . >          . >--------------------o >r& >Example 1-5:  PUT_CONSOLE SubroutinesF >_____________________________________________________________________ >a8 >        .TITLE  PUT_CONSOLE - Write messages to console >        .IDENT  /01-000/a >;+a >;  >;  File:        PUT_CONSOLE.MAR >; >;  Author:      Hunter Goatleyo >;" >;  Date:        November 10, 1992 >; >;  Description: >;C >;       The module contains two routines for performing device I/OnF >;       to the system console: PUT_CONSOLE_ASCIC and PUT_CONSOLE_HEX. >; >;  Modified by: >;B >;       01-000          Hunter Goatley          10-NOV-1992 13:09 >;  Genesis. >; >;-  >        .DSABL  GLOBALe >f< >        .EXTRN  CON$RESTORE_CTY    ;* Restore console state9 >        .EXTRN  CON$SAVE_CTY       ;* Save console statee8 >        .EXTRN  EXE$OUTCHAR        ;* Print a character5 >        .EXTRN  EXE$OUTCRLF        ;* Print <CR><LF>t9 >        .EXTRN  EXE$OUTCSTRING     ;* Print ASCIC stringm8 >        .EXTRN  EXE$OUTHEX         ;* Dump a HEX string >a >;+  >;H >;  PUT_CONSOLE_ASCIC    Expects ASCIC address in R0, preserves all regs >; >;-  >PUT_CONSOLE_ASCIC::A >        PUSHR   #^M<R0,R1,R2,R3,R4,R11>         ; Save registersuF >        CLRL    R11                             ; Show I/O to consoleI >        PUSHL   R0                              ; Save address of string.E >        JSB     G^CON$SAVE_CTY                  ; Save console statec@ >        MOVQ    R0,                             ; Save the dataD >        MOVL    #10,                            ; Move a <LF> to R0@ >        JSB     G^EXE$OUTCHAR                   ; Send the <LF>L >        POPL    R1                              ; Restore address of string? >        JSB     G^EXE$OUTCSTRING                ; Write it outaD >        MOVL    #13,                            ; Move a <CR> to R0@ >        JSB     G^EXE$OUTCHAR                   ; Send the <CR>H >        MOVQ    R3,                             ; Restore console state dataH >        JSB     G^CON$RESTORE_CTY               ; Restore console stateA >        POPR    #^M<R0,R1,R2,R3,R4,R11>         ; Save registersvC >        RSB                                     ; Return to callerg >;+l >;L >;  PUT_CONSOLE_HEX      Expects hex value address in R0, preserves all regs >; >;-r >PUT_CONSOLE_HEX::A >        PUSHR   #^M<R0,R1,R2,R3,R4,R11>         ; Save registerseF >        CLRL    R11                             ; Show I/O to consoleI >        PUSHL   R0                              ; Save address of stringVE >        JSB     G^CON$SAVE_CTY                  ; Save console statey@ >        MOVQ    R0,R3                           ; Save the dataI >        JSB     G^EXE$OUTCRLF                   ; Follow with a <CR><LF>wD >        MOVL    #10,R0                          ; Move a <LF> to R0@ >        JSB     G^EXE$OUTCHAR                   ; Send the <LF>D >        POPL    R1                              ; Restore hex value? >        JSB     G^EXE$OUTHEX                    ; Write it outoD >        MOVL    #13,R0                          ; Move a <CR> to R0@ >        JSB     G^EXE$OUTCHAR                   ; Send the <CR>H >        MOVQ    R3,R0                           ; Restore console state dataH >        JSB     G^CON$RESTORE_CTY               ; Restore console stateA >        POPR    #^M<R0,R1,R2,R3,R4,R11>         ; Save registersFC >        RSB                                     ; Return to callerd >h
 >     .END >dF >_____________________________________________________________________ >c( >1.4.2  Using the $SNDOPR System Service >hA >Non-privileged code can send messages to the operator console by2D >calling the $SNDOPR system service to queue a message to OPCOM, theF >operations communication manager. Messages received by OPCOM are sentB >to appropriate operator terminals, including the console, and areC >recorded in the system operator log (OPERATOR.LOG in SYS$MANAGER).nD >Unfortunately, $SNDOPR cannot be called from kernel mode because itF >initially executes in executive mode. $SNDOPR uses the executive modeE >stack for temporary storage space for the message text, then changes1C >mode to kernel to actually write the message to the OPCOM mailbox,a+ >whose address is stored in SYS$AR_ OPRMBX.v >mG >The system routine EXE$SNDOPR actually writes the message to the OPCOM"G >mailbox by calling the system routine EXE$SNDMSG. This routine ensures2A >that the memory holding the message text is faulted in and callsWF >EXE$WRTMAILBOX to write the message to the OPCOM mailbox. In order toG >ensure that all the necessary pages have been faulted into memory, thebA >address of the message text is rounded down to the previous page D >boundary. If the message is small and near the top of the executiveD >stack, this can cause an overrun into the kernel stack, which worksE >because the routine is executing in kernel mode. If the message wereh@ >allowed to reside on the kernel stack, the rounding down of theD >address could result in the access of the page preceding the kernelD >stack, which is not a valid page. The system would then generate an >access violation exception. >lC >Still, $SNDOPR can be useful in non-privileged portions of systemsoG >code as a means of notifying the system manager of a particular event.gE >Even at the driver-level, if a code thread needs to produce an alarmeA >associated with a particular process, it may be able to queue an @ >executive-mode AST to that process (to be discussed in a futureD >article); the executive-mode AST could then call the $SNDOPR system	 >service. J >========================================================================= >e >Hunters >------e: >Hunter Goatley, Process Software, http://www.process.com/: >goathunter@goatley.com     http://www.goatley.com/hunter/   ------------------------------   End of INFO-VAX 2001.378 ************************