1 INFO-VAX	Wed, 04 Jul 2001	Volume 2001 : Issue 367       Contents:1 Re: 3 Reasons why VMS is alive and probably well+ 1 Re: 3 Reasons why VMS is alive and probably well+ 1 Re: 3 Reasons why VMS is alive and probably well+ 5 Alpha/NT conspiracy theorists should love this one... + Re: Apache CGI Problems on VMS with TCPware  ASI PDF Viewer Futures Re: ASI PDF Viewer Futures Re: Changing platforms. C Cluster comms over fc, was Re: Compaq's Alpha design team for sale? G Re: Cluster comms over fc, was Re: Compaq's Alpha design team for sale? G Re: Cluster comms over fc, was Re: Compaq's Alpha design team for sale? G Re: Cluster comms over fc, was Re: Compaq's Alpha design team for sale? & Compaq adopts IA-64 technology in 1998 Re: Compaq switches to IA-64 Re: Compaq switches to IA-646 Re: Compaq to phase out computer lines not using Intel DEC Notes available, someone? ! Empty SCA Storageworks canisters?  Excerpt from internal IBM memo. ) Re: followup to my post from last week...  Re: FUD   Re: Full port of VMS to Itanium.! Re: H-P EOLs PA-RISC Architecture * Re: Hobby LIcense: One USER, or one LOGIN?0 Re: How to (auto-re)submit batch few times a day HP DLT1 drives on Alpha VMS?  Re: HP DLT1 drives on Alpha VMS?" Re: I didn't stick it upside down!" Re: I didn't stick it upside down!" Re: I didn't stick it upside down!" Re: I didn't stick it upside down! Re: IA64 Rocks My World  Re: IA64 Rocks My World  Re: IA64 Rocks My World  Re: KZMSA support on VAX 7710 " Re: LCD Screen on VMS Workstation?E OpenVMS as bootserver for other OS's - was Re: Probably the strangest ( OT: The Great Computer Language Shootout, Re: OT: The Great Computer Language Shootout, Re: OT: The Great Computer Language Shootout$ Probably the strangest request yet!!( Re: Probably the strangest request yet!!> Re: Problems Creating ODBC Connections to RDB databases on vms QBUS SCSI Adapter  Re: Qlogic question  Re: Question to Charlie Matco. Re: Question to Charlie Matco. Re: Question to Charlie Matco. Re: Question to Charlie Matco.B Re: Questions on VAX local (SCSI) shadowed system disk H/W upgrade- Re: Re; One more dreadful thought to consider - Re: Re; One more dreadful thought to consider  Re: RMS file performance Re: Sadness P Sending a double (floating-point) field over tcp from OpenVMS 7.2 to Tru64 4.0 u' Re: Thanks Compaq for the new business!  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: UPS for AlphaServer 2100A  Re: VMS V7.3 SPD Error< Re: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.)7 Wailing and moaning.... (was: Compilers go to Intel...) # Re: What about performance issues?? / Re: Yet Another Reason Why Windoze .ne. OpenVMS / Re: Yet Another Reason Why Windoze .ne. OpenVMS   F ----------------------------------------------------------------------  $ Date: Tue, 3 Jul 2001 15:24:04 -0400' From: "Bill Todd" <billtodd@foo.mv.com> : Subject: Re: 3 Reasons why VMS is alive and probably well+( Message-ID: <9ht5tt$p3v$1@pyrite.mv.net>  3 "Bob Marcan" <bob.marcan@aster.si> wrote in message " news:3B41FE4D.582DF76D@aster.si...< > C'mon, Arne. Did you read about clustering on Tru64 v5.1a?9 > Did you try v5.1? They have lot inherited from the VMS.   2 And are open-sourcing a great deal of it on Linux:  ! http://www.opensource.compaq.com/   E (though I don't know how much of the newer stuff is mixed into that).    - bill   ------------------------------   Date: 3 Jul 2001 15:25:08 CDT = From: wayne@tachysoft.xxx.320117.killspam.015d (Wayne Sewell) : Subject: Re: 3 Reasons why VMS is alive and probably well+. Message-ID: <+x2IDvG+Rgvz@tachxxsoftxxconsult>  Y In article <9hsntt$m8l$1@bob.news.rcn.net>, "John Saunders" <jws@ma.ultranet.com> writes: 9 > "Arne Vajhj" <arne.vajhoej@gtech.com> wrote in message % > news:3B41BB9B.B896E94B@gtech.com...  >> Alphaman wrote:J >> > Don't forget, CSA membership and _site-wide_ SDK is MUCH cheaper than > just% >> > ONE single-user MSDN membership.  >>K >> Now - I have never believed that system/development-tools prices had any , >> significant impact on support from ISV's. > J > That depends on the ISV. For a small ISV, costs of development tools andA > platforms can determine whether they support a platform at all.     K It also determines *how* they support the platform.  For instance, software I partners has always been forced to use its own mechanism for license keys 8 because of the incredible cost of the LMF PAK generator.   --  O =============================================================================== M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxx : 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 =============================================================================== ? Flounder: "I can't believe I threw up in front of Dean Wormer." >    Otter: "Face it, Flounder.  You threw up *on* Dean Wormer."   ------------------------------   Date: 3 Jul 2001 17:53:43 -0500 9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) : Subject: Re: 3 Reasons why VMS is alive and probably well+3 Message-ID: <9RAEVBnZDwOg@eisner.encompasserve.org>   n In article <+x2IDvG+Rgvz@tachxxsoftxxconsult>, wayne@tachysoft.xxx.320117.killspam.015d (Wayne Sewell) writes:[ > In article <9hsntt$m8l$1@bob.news.rcn.net>, "John Saunders" <jws@ma.ultranet.com> writes: : >> "Arne Vajhj" <arne.vajhoej@gtech.com> wrote in message& >> news:3B41BB9B.B896E94B@gtech.com... >>> Alphaman wrote: K >>> > Don't forget, CSA membership and _site-wide_ SDK is MUCH cheaper than  >> just & >>> > ONE single-user MSDN membership. >>> L >>> Now - I have never believed that system/development-tools prices had any- >>> significant impact on support from ISV's.  >>  K >> That depends on the ISV. For a small ISV, costs of development tools and B >> platforms can determine whether they support a platform at all. >  > M > It also determines *how* they support the platform.  For instance, software K > partners has always been forced to use its own mechanism for license keys : > because of the incredible cost of the LMF PAK generator.  F I find it unbelievable that they get a higher price than LJK Software.   ------------------------------  # Date: Wed, 04 Jul 2001 03:54:00 GMT . From: brown_du@eisner.decus.org (Duncan Brown)> Subject: Alpha/NT conspiracy theorists should love this one...1 Message-ID: <3b429137.54642113@news.telocity.com>   A We all figured that MS continued to develop the 64-bit Windows on A Alpha even though that O/S target was officially cancelled.  What A choice did they have?  Wait for working IA-64 chips?!  If you had 5 acted fast, perhaps you could have had working proof:   A http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=1245075127   D (For those not willing to follow the link, or for those reading thisC after the eBay lsiting expires, it is a pair of used RM 4100's with = the description "Currently Loaded with Windows 2000 for Alpha E Computers (Beta Ver.) "  and  "It was formerly owned by Microsoft and  is in perfect working order. ")   D Nobody bit at the $19,999.00 price, so it ended without a bid.  TheyB relisted it with a tiny starting bid and an unknown reserve price:  A http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=1249059441   ? But *this* time it is "Currently Loaded with REDHAT 6.2" and no D mention of MS.  Guess the black helicopters swooped in and made sure$ it no longer contained The Evidence.  E (Oddly enough, the second auction was nearing the end without meeting B the reserve, but then the seller set about cancelling all the bids; with the explanation "Sorry the item is not available" - an @ unnecessary move since it had not met reserve, but who knows...)  ? Duncan, wondering why everyone abruptly cancels their perfectly C working Alpha O/Ses and puts their support behind near vaporware... $ did someone threaten their families?   ------------------------------  % Date: Wed, 04 Jul 2001 04:23:15 +0200 2 From: martin@radiogaga.harz.de (Martin Vorlaender)4 Subject: Re: Apache CGI Problems on VMS with TCPware; Message-ID: <3b427e13.524144494f47414741@radiogaga.harz.de>   ( Tom Rataski (trataski@clwcpc.com) wrote:5 > martin@radiogaga.harz.de (Martin Vorlaender) wrote: + > >Tom Rataski (trataski@clwcpc.com) wrote: D > >> Has anyone successfully gotten Apache CGI to work with TCPware? > > H > >My Perl scripts are doing well with CSWS_PERL. Didn't yet try command+ > >procedures, executable images, and JAVA.  > > G > >I must admit that I don't quite understand what the choice of TCP/IP  > >stack has to do with CGI. > B > For some reason it does seem to make a difference... on two likeH > systems I can get the cgi .coms/.exes to work on one that has  TCPwareD > 5.4-3 installed, but it refuses to work on the system with TCPwareG > 5.3-2. I get server errors and the error_log file states that the com E > or exe terminated with "premature end of script". One other thing -  > perl seems to work just fine.   H I know the "premature end of headers" error (it means that Apache didn'tJ see any valid HTTP headers before the first empty line; normally some kindA of error message). But I've never seen "premature end of script".   I Sorry, no idea what could be going on. But I still doubt it has something H to do with TCPware (except perhaps for different ressource usage). IMHO,9 there must be other differences between the two machines.    cu,    Martin --  F                           | Martin Vorlaender  |  VMS & WNT programmer3  Cetero censeo            | work: mv@pdv-systeme.de F  Redmondem esse delendam. |   http://www.pdv-systeme.de/users/martinv/:                           | home: martin@radiogaga.harz.de   ------------------------------  % Date: Tue, 03 Jul 2001 16:45:19 -0500 / From: Chris Scheers <chris@applied-synergy.com>  Subject: ASI PDF Viewer Futures 2 Message-ID: <3B423CEF.94D842A@applied-synergy.com>  B If you are interested in the ASI PDF Viewer or Ghostscript on VMS,
 please see  <         http://www.applied-synergy.com/pdf/announcement.html  G ----------------------------------------------------------------------- $ Chris Scheers, Applied Synergy, Inc.  C Voice: 817-237-3360            Internet: chris@applied-synergy.com     Fax: 817-237-3074    ------------------------------  % Date: Tue, 03 Jul 2001 23:34:52 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)# Subject: Re: ASI PDF Viewer Futures L Message-ID: <rdeininger-0307012334520001@user-2ive6bt.dialup.mindspring.com>  @ In article <3B423CEF.94D842A@applied-synergy.com>, Chris Scheers" <chris@applied-synergy.com> wrote:  D > If you are interested in the ASI PDF Viewer or Ghostscript on VMS, > please see > > >         http://www.applied-synergy.com/pdf/announcement.html >    Informative but terse.  ' Any projections on the release of V2.0?   H And can you give any details about the lost display engine used in V1.x?   --   Robert Deininger rdeininger@mindspring.com    ------------------------------   Date: 3 Jul 2001 18:19:36 -0700 ( From: kparris@my-deja.com (Keith Parris)  Subject: Re: Changing platforms.= Message-ID: <cb85fed2.0107031719.2b6aa1c6@posting.google.com>   v "Duane Sand" <duane.sand@mindspring.com> wrote in message news:<LBU_6.139045$%i7.93197619@news1.rdc1.sfba.home.com>...K > I don't challenge that VMS makes nice earnings from offering good systems @ > with good software features to a very desirable customer base.G > But somehow the net total of everything associated with Alpha, ie the I > entire division formerly known as Digital, is consistently losing money H > every quarter, and those losses are only barely covered by the profitsK > from the division formerly known as Tandem.  I believe it's been that way I > since before both were acquired, and maybe long before, given Digital's " > long decline before acquisition.  F I think this is a myth.  And it concerns me that it is believed withinA the Tandem division, because that means it is probably widespread  within Compaq.  B Let's examine this assertion in more depth -- that the portions ofF Compaq which were formerly Digital are chronically losing money.  WhatE was left of Digital after the takeover by Compaq?  VMS, Tru64, Alpha, D StorageWorks, and Services (arguably the majority of Services, sinceF Compaq reportedly bought Digital primarily for that capability).  (TheA Networks Division had been sold to Cabletron.  The PC Division of > Digital was immediately axed; even the exemplary HiNote series succumbed swiftly to NIH.)  F We've been told VMS has $4B in revenues per year, with profits of $800D million.  Tru64 can't be doing much worse than VMS, considering thatF we're told more than half of all high-end Alphaservers go out the doorC running Tru64.  Alpha costs $150 million per year, according to the = recent press info (other sources reported here estimated $300 E million); even if take the larger number and we assume that number is B a total loss, it's more than covered by the profits of VMS alone. F StorageWorks is going great gangbusters, with #1 market share in SANs,D so I really doubt they're losing money.  The 2000 Annual Report saysB Services made a profit.  So what portions of Digital are left that could possibly be losing money?   C Tandem's revenues are $1.3 billion per year, and it is profitable.  F But its contribution to Compaq's profits is dwarfed in comparison withC that of VMS, even after subtracting all the Alpha development costs  first.    > The fixation on home-grown cpuB > chips named Alpha seems to be a big part of the expense problem.  F What big expense problem?  The press info said Alpha development costsC $150 million per year.  Big deal!  They could double or even triple B the development expenditures to keep Alpha competitve and still be' profitable based on VMS' profits alone.   E Face it -- VMS, Tru64, StorageWorks, and Tandem have been keeping the D PC Division afloat for years.  If VMS goes down, Tandem could end upD in the dumpster with the rest of Compaq.  And the recent decision to= can Alpha puts VMS and Tru64 revenues at risk, in my opinion.    ------------------------------  # Date: Tue, 03 Jul 2001 17:56:34 GMT $ From: Scott Vieth <svieth@wi.rr.com>L Subject: Cluster comms over fc, was Re: Compaq's Alpha design team for sale?) Message-ID: <3B4207E6.DC443376@wi.rr.com>   U Gimme some more detail on what you mean when you say "all the fibre players agreeing" P on host-to-host communication.  Can't Compaq just write an add-on which lets VMSS systems talk to each other over fibre channel?  We don't need any standards body to Q come out with "this is the offical way for hosts to talk to each other over fibre 	 channel".    Maybe I'm missing something....    -Scott     "Mark D. Jilson" wrote:   G > Well this will be very dependent on all the Fibre players agreeing on E > the way to do host-host communication which they have not shown any I > inclination in doing.  It may happen but it will be some time before it  > does happen. >  > Scott Vieth wrote: > T > > 2) Fibre channel will probably be a cluster interconnect in the future.  I don'tS > > think we're stuck with just ethernet for cluster comms between an OpenVMS Alpha  > > and OpenVMS Intel system.  > >  > > -Scott :^) >  > --H > Jilly   - Working from Home in the Chemung River Valley - Lockwood, NYL >         - jilly@clarityconnect.com                      - Brett Bodine fanL >         - Mark.Jilson@Compaq.com                        - since 1975 or so5 >         - http://www.jilly.baka.com               -    ------------------------------  $ Date: Tue, 3 Jul 2001 15:15:27 -0400' From: "Bill Todd" <billtodd@foo.mv.com> P Subject: Re: Cluster comms over fc, was Re: Compaq's Alpha design team for sale?( Message-ID: <9ht5dj$ors$1@pyrite.mv.net>  1 "Scott Vieth" <svieth@wi.rr.com> wrote in messaged# news:3B4207E6.DC443376@wi.rr.com...oE > Gimme some more detail on what you mean when you say "all the fibreF players agreeing"gI > on host-to-host communication.  Can't Compaq just write an add-on which  lets VMSC > systems talk to each other over fibre channel?  We don't need any  standards body to H > come out with "this is the offical way for hosts to talk to each other
 over fibre > channel".  >h! > Maybe I'm missing something....o  L Perhaps 'target mode'?  My very limited acquaintance with the issue suggestsC that only a couple of FC HBA vendors support initiator-to-initiator J communication in their hardware, and perhaps only one provides the drivers
 to use it.   - bill   >o > -Scott >p >  > "Mark D. Jilson" wrote:  >eI > > Well this will be very dependent on all the Fibre players agreeing onbG > > the way to do host-host communication which they have not shown anytK > > inclination in doing.  It may happen but it will be some time before ite > > does happen. > >i > > Scott Vieth wrote: > >iE > > > 2) Fibre channel will probably be a cluster interconnect in thei future.  I don'tG > > > think we're stuck with just ethernet for cluster comms between an 
 OpenVMS Alphap > > > and OpenVMS Intel system.o > > >o > > > -Scott :^) > >b > > --J > > Jilly   - Working from Home in the Chemung River Valley - Lockwood, NYJ > >         - jilly@clarityconnect.com                      - Brett Bodine fan K > >         - Mark.Jilson@Compaq.com                        - since 1975 ory so7 > >         - http://www.jilly.baka.com               -e >o   ------------------------------  # Date: Tue, 03 Jul 2001 19:27:26 GMT 1 From: "Mark D. Jilson" <jilly@clarityconnect.com> P Subject: Re: Cluster comms over fc, was Re: Compaq's Alpha design team for sale?2 Message-ID: <3B421D8F.2E9F0E8D@clarityconnect.com>   Here's a short summary  D 'So far only 1 vendor even claims to provide some level of hooks for
 host-host G comm. capability, and it isn't  clear that they are really committed tov fix E any problems we might ( will ) find, or what kind of performance we'ds get.  D It's also not yet clear whether they are committed to implement this
 feature inD future  adapter models or to ensure interpretability across multiple adapter < models. (but there are recent indications that they may be.)  E So, would we have an viable VMS FC as a cluster interconnect solutionb if:   E a)It only worked with one specific adapter model that may not get bugS fixes?  H b)Or, each time COMPAQ changed FC adapter vendors you had to add the new adaptertD model to all systems, or replace all the FC old vendor's FC adapters because the D new vendor's adapter used a host-host protocol that was incompatible	 with the e prior vendor's adapters.  ; In spite of the above we haven't given up. We're constantlye re-evaluating then@ possibility whenever we get a 'futures' update from FC vendors.'   Scott Vieth wrote: > W > Gimme some more detail on what you mean when you say "all the fibre players agreeing"mR > on host-to-host communication.  Can't Compaq just write an add-on which lets VMSU > systems talk to each other over fibre channel?  We don't need any standards body to-S > come out with "this is the offical way for hosts to talk to each other over fibre@ > channel".  > ! > Maybe I'm missing something....  >  > -Scott >  > "Mark D. Jilson" wrote:@ > I > > Well this will be very dependent on all the Fibre players agreeing on4G > > the way to do host-host communication which they have not shown anyoK > > inclination in doing.  It may happen but it will be some time before it  > > does happen. > >  > > Scott Vieth wrote: > > V > > > 2) Fibre channel will probably be a cluster interconnect in the future.  I don'tU > > > think we're stuck with just ethernet for cluster comms between an OpenVMS Alpha: > > > and OpenVMS Intel system.. > > >1 > > > -Scott :^) > >  > > --J > > Jilly   - Working from Home in the Chemung River Valley - Lockwood, NYN > >         - jilly@clarityconnect.com                      - Brett Bodine fanN > >         - Mark.Jilson@Compaq.com                        - since 1975 or so7 > >         - http://www.jilly.baka.com               -h   --  D Jilly	- Working from Home in the Chemung River Valley - Lockwood, NY0 	- jilly@clarityconnect.com			- Brett Bodine fan. 	- Mark.Jilson@Compaq.com			- since 1975 or so, 	- http://www.jilly.baka.com               -   ------------------------------   Date: 3 Jul 2001 17:42:37 -0500t9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)tP Subject: Re: Cluster comms over fc, was Re: Compaq's Alpha design team for sale?3 Message-ID: <fxF5a$BjQ8Eo@eisner.encompasserve.org>F  A That doesn't even touch on the issue of no vendor with an adapternB to provide the sort of hardware assist that is in the CI adapters.? The ability to do something in software does not achieve parity= with CI.   Larry Kilgallen=  f In article <3B421D8F.2E9F0E8D@clarityconnect.com>, "Mark D. Jilson" <jilly@clarityconnect.com> writes: > Here's a short summary > F > 'So far only 1 vendor even claims to provide some level of hooks for > host-host I > comm. capability, and it isn't  clear that they are really committed to= > fix G > any problems we might ( will ) find, or what kind of performance we'd  > get. > F > It's also not yet clear whether they are committed to implement this > feature inF > future  adapter models or to ensure interpretability across multiple	 > adapterK> > models. (but there are recent indications that they may be.) > G > So, would we have an viable VMS FC as a cluster interconnect solutionx > if:g > G > a)It only worked with one specific adapter model that may not get bugl > fixes? > J > b)Or, each time COMPAQ changed FC adapter vendors you had to add the new	 > adaptersF > model to all systems, or replace all the FC old vendor's FC adapters
 > because the4F > new vendor's adapter used a host-host protocol that was incompatible > with the d > prior vendor's adapters. > = > In spite of the above we haven't given up. We're constantly  > re-evaluating the B > possibility whenever we get a 'futures' update from FC vendors.' >  > Scott Vieth wrote: >>  X >> Gimme some more detail on what you mean when you say "all the fibre players agreeing"S >> on host-to-host communication.  Can't Compaq just write an add-on which lets VMS*V >> systems talk to each other over fibre channel?  We don't need any standards body toT >> come out with "this is the offical way for hosts to talk to each other over fibre >> channel". >> ." >> Maybe I'm missing something.... >> a	 >> -Scottc >> n >> "Mark D. Jilson" wrote: >> -J >> > Well this will be very dependent on all the Fibre players agreeing onH >> > the way to do host-host communication which they have not shown anyL >> > inclination in doing.  It may happen but it will be some time before it >> > does happen.n >> > >> > Scott Vieth wrote:n >> >W >> > > 2) Fibre channel will probably be a cluster interconnect in the future.  I don'taV >> > > think we're stuck with just ethernet for cluster comms between an OpenVMS Alpha  >> > > and OpenVMS Intel system. >> > > >> > > -Scott :^)V >> > >> > --4K >> > Jilly   - Working from Home in the Chemung River Valley - Lockwood, NYhO >> >         - jilly@clarityconnect.com                      - Brett Bodine fancO >> >         - Mark.Jilson@Compaq.com                        - since 1975 or soa8 >> >         - http://www.jilly.baka.com               - >  > -- rF > Jilly	- Working from Home in the Chemung River Valley - Lockwood, NY2 > 	- jilly@clarityconnect.com			- Brett Bodine fan0 > 	- Mark.Jilson@Compaq.com			- since 1975 or so. > 	- http://www.jilly.baka.com               - -- tN ==============================================================================N Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> ClustersN ==============================================================================   ------------------------------  $ Date: Tue, 3 Jul 2001 21:11:40 -0400) From: "Neil Rieck" <n.rieck@sympatico.ca>i/ Subject: Compaq adopts IA-64 technology in 1998e8 Message-ID: <A0u07.7214$NY.974451@news20.bellglobal.com>  K I recently discovered this February 1998 "EE Times" article titled "DigitaloH Attacks -- And Compaq Adopts -- Intel's Merced" which can be read in its entirety here:6 http://content.techweb.com/wire/story/TWB19980202S0008  J Here is a schizophrenic excerpt (Compaq bought Digital in the same month):J Digital Equipment's Alpha microprocessor division is preparing to come outK with its answer to Intel's Merced at a time when Alpha's fate is clouded inrF the wake of Compaq's announced plan to acquire Digital. The company isE expected to detail significant new Alpha products on Monday, possiblywI including plans to take the processor to speeds of 1 GHz. However, CompaqyB publicly sketched a road map last week that shows no role for RISCJ processors in its future high-end systems. The Houston PC maker separatelyI disclosed it is already working with a new design group at Intel to buildc Merced-based servers.t  ; If that's not an example of DeJa Vu, then it doesn't exist.a  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/o@ http://www3.sympatico.ca/n.rieck/links/compaq_memorial_site.html   ------------------------------  $ Date: Tue, 3 Jul 2001 21:07:28 -0400) From: "Neil Rieck" <n.rieck@sympatico.ca>f% Subject: Re: Compaq switches to IA-64i8 Message-ID: <DYt07.7201$NY.971621@news20.bellglobal.com>  F I recently discovered this found this Feb-1998 article titled "DigitalH Attacks -- And Compaq Adopts -- Intel's Merced" which can be read in its entirety here:6 http://content.techweb.com/wire/story/TWB19980202S0008   Here is an excerpt: J Digital Equipment's Alpha microprocessor division is preparing to come outK with its answer to Intel's Merced at a time when Alpha's fate is clouded inrF the wake of Compaq's announced plan to acquire Digital. The company isE expected to detail significant new Alpha products on Monday, possibly I including plans to take the processor to speeds of 1 GHz. However, Compaq-B publicly sketched a road map last week that shows no role for RISCJ processors in its future high-end systems. The Houston PC maker separatelyI disclosed it is already working with a new design group at Intel to buildV Merced-based servers.   5 If that's not an example of DeJa Vu, then nothing is.m  
 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: Wed, 04 Jul 2001 01:56:00 GMT-4 From: "Terry C. Shannon" <terryshannon@mediaone.net>% Subject: Re: Compaq switches to IA-64n< Message-ID: <QIu07.1441$tH1.1266273@typhoon.ne.mediaone.net>  4 "Neil Rieck" <n.rieck@sympatico.ca> wrote in message2 news:DYt07.7201$NY.971621@news20.bellglobal.com...H > I recently discovered this found this Feb-1998 article titled "DigitalJ > Attacks -- And Compaq Adopts -- Intel's Merced" which can be read in its > entirety here:8 > http://content.techweb.com/wire/story/TWB19980202S0008 >   8 As can the October 11, 1999 Alpha and IA64 Comparison at www.alphapowered.com  I For sure that little journalistic exercise can and will be used against ao revisionist Compaq!i   ------------------------------  $ Date: Tue, 3 Jul 2001 21:01:59 -0400) From: "Neil Rieck" <n.rieck@sympatico.ca> ? Subject: Re: Compaq to phase out computer lines not using Intel88 Message-ID: <uTt07.7174$NY.967565@news20.bellglobal.com>  : "Warren Spencer" <wspencer@nospam.ap.org> wrote in message- news:90CB5605Awspenceraporg@207.126.101.97.... > Terry was right; big news: >k/ > http://biz.yahoo.com/rf/010625/n25216200.htmli >g > ws >a > -- > Warren Spencer  > <<< My opinions are my own >>>G Don't forget the leaked Compaq charts found at the bottom of this page:d' http://www.theinquirer.net/30060101.htms    
 Neil Rieck Kitchener/Waterloo/Cambridge,o Ontario, Canada.! http://www3.sympatico.ca/n.rieck/r@ http://www3.sympatico.ca/n.rieck/links/compaq_memorial_site.html   ------------------------------  , Date: Tue, 03 Jul 2001 20:49:23 +0200 (CEST)- From: Freddy Meerwaldt <frederik@freddym.org> & Subject: DEC Notes available, someone?K Message-ID: <Pine.LNX.4.21.0107032045450.32503-100000@firewall.freddym.org>y  	 Hi there,   / is there someone who has a DEC Notes Kit handy?o2 We have a hobbyist VAX6000 running to promote VMS.F Perhaps you know vax6k.openecs.org from a previous announcement (go to) http://vax6k.openecs.org for more infos).,  C Anyway, we would like to install DEC Notes on it, but I only have a,  slightly outdated version handy.D If someone have the kits available (we have the license, of course), please contact me.8 Perhaps he/she could manage to upload this kit to vax6k.H The "sponsor" of this software will (if he/she wants it) be mentioned inB the software announcement, too, and will receive an account on the machine.   Many thanks in advance and
 Best Regards,h 	Freddy   H PS: Still looking for VAX 6300 / 6400 RAM/CPU Modules. Please contact me" off-list if you have such modules.   -- cN 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 morerI  Solaris, HP/UX, AIX, NetBSD, OpenBSD, IRIX, Tru64, OpenVMS, Ultrix, BeOSd   ------------------------------  % Date: Tue, 03 Jul 2001 21:48:39 -0400o+ From: Tim Shoppa <shoppa@trailing-edge.com>l* Subject: Empty SCA Storageworks canisters?1 Message-ID: <3B423DB6.7DF6BAE7@trailing-edge.com>c  ? I once had a local source for empty (well, filled with dead SCAe9 drives) Storageworks canisters, but that's dried up.  Canu7 anyone recommend dealers who sell such things?  I'm nots< picky about grey vs blue, but it does have to be SCA inside.   Tim.   ------------------------------  % Date: Tue, 03 Jul 2001 15:11:40 -0400n( From: Hamlyn Mootoo <univms@bigfoot.com>( Subject: Excerpt from internal IBM memo.+ Message-ID: <3B4218EC.B646C7E0@bigfoot.com>   6 The following is an excerpt from an internal IBM memo:  G ----------------------------------------------------------------------- 
  Perspective:       Compaq: feeling blue?    B  In an internal memo circulated Monday, Compaq set its sights on a strategy@  that strongly resembles IBM's, moving its focus point away from hardwareF  (stalled sales of PCs and Internet equipment) and emphasizing bundled/  solutions of hardware, software, and services.     G  Michael Capellas, CEO of Compaq, has previously commented that IBM hasy theaF  right strategy, but this time there seem to be some substantive movesE  afoot to refashion Compaq in line with that strategy. Compaq is alsokE  stepping up its business alliances with Microsoft and Intel. Sale of  itseD  DEC-based Alpha chip operation and transfer of related personnel to Intel F  brings an infusion of working capital and a cost savings. A promisingF  non-PC revenue stream has also suddenly appeared in the device arena:H  Compaq's iPAQ handheld computer (based on Microsoft's operating system,C  not Palm's) is about to take the dollar-volume lead in that field,l earningtH  around $200 million in the quarter now closing, which is more than Palm  and Handspring combined.     @  No doubt, Compaq needs to shift its focus, but transforming its businessH  into something that looks more like IBM will be difficult. To shift theH  focus to services, as the Compaq memo proposes, the company must eitherG  recruit a services staff, cross-train surplus personnel from the othertF  areas, or buy its way into the business with acquisitions. But Compaq hascE  already bought a fairly strong services organization (DEC), and mostlG  analysts agree that move did not successfully translate into a viable,uH  non-product-centered services business for Compaq. The company wants toF  grow services from one-fifth of revenue to one-third in the next fourD  years, and wants to create and sell software, but has no history of doingr  either.    G  Meanwhile, Compaq is taking a calculated risk by centering on Itanium,lD  giving up its unique Alpha server technologies to Intel without anyD  obvious compelling benefit in return. It's leaving itself without a realF  differentiator in server architecture, and is betting that the delays thatC  have slowed Itanium's marketplace debut are over. While Compaq nows leanskC  totally on Itanium chips, IBM has both Itanium and our own PowerPCeF  technology. Meanwhile, there's an opportunity for competitors to pick offsB  Compaq customers disgruntled with the suddenly stunted technology roadmapa  for their Alpha servers.r  H ------------------------------------------------------------------------   ------------------------------   Date: 3 Jul 2001 17:09:51 -0500 7 From: hamilton@encompasserve.org (Bradford J. Hamilton)o2 Subject: Re: followup to my post from last week...3 Message-ID: <NbUe73id$pnF@eisner.encompasserve.org>I  X I know - bad form to follow up my own post, but in the interest of *fairness*, here goes  > (my updated comments are interspersed among my original post):m In article <kHAyp1eyQh3i@eisner.encompasserve.org>, hamilton@encompasserve.org (Bradford J. Hamilton) writes:p > Hi Terry,  > L > I understand that the last 36 hours has been very trying for all involved. > Q > I don't think that there is anyone (c.o.v. posters, COMPAQ, even Intel) *wants*@U > to destroy VMS.  I *do* think that a lot of the "negativity" seen in this NG arises@1 > from the *way* in which the news was delivered.  > \ > There were (to my knowledge) *no* efforts by COMPAQ's sales force, marketers, or Engineers] > to "prepare" their customers for this news - probably because it was a surprise to everyoneu > involved.u >r  _ When I returned to work today, I found out that our local sales team had been in touch with ouryX "CIO" and "CTO" on Friday, 22-June, to give them a preview of the Monday announcement.  % I have no idea what the reaction was.     i\ > This surprise has generated a lot of the FUD that you think has been generated by this NG.X > You have seen the word "shock" used here in many postings - human beings tend to reactC > in previously-unknown patterns when a shock is delivered to them.o > Y > Many of us have to answer to our customers and managers who *immediately* had questionsn` > upon hearing the news.  I am on "vacation" this week, but I had to feed some quick information_ > to my colleagues at work who were caught by surprise by this announcement, and who spent mosthU > of their time on the phone to customers and management on Monday morning, trying tos > explain the "unexplainable". >   ` Our customer's questions were few - we have no indication from them that they are "jumping ship"d at this time.  They have requested (and will receive) a detailed presentation from COMPAQ next week,e which will (hopefully) answer any questions they may have.  I don't know if I will be invited; if so, = I will try to report what I hear (unless NDA's are invoked!).s  _ > We had just been given a great presentation on Thursday, showing our customers how they couldaa > use VMS, from Web server front-end, to DB back-end, to tie up a lot of "loose-end" applications [ > on different platforms.  I was *very* pleased after that meeting - I thought that we had @a > finally turned a corner in our multi-year battle to convince our cutomers (and managers) of the@. > worthiness of VMS as an enterprise platform. >  > What do we tell them now???  >   _ I had honestly (based on past experience) expected our customers and management to "jump ship";a\ they have not done so, to my relief.  I can't honestly say what the future holds, but I am aO little more confident in the future of VMS at this company, for the time being.e  ` > I will choose to interpret your one-liner at the bottom of this post as something arising from_ > extreme frustration and exhaustion, but please, don't let it appear as though you feel the NGrc > is somehow responsible for the current situation!  It's alomst as if you think that VMS customers  > are at fault!   c Terry, please don't let the very vocal minority here get you down - it looks as though most of them a have an axe to grind, and few of them are COMPAQ's customers.  Please notice, also, that Andrew'srf FUD has been minimal, and generally ineffective - I wonder if he doth protest too much at the imminent disappearance of Slowlaris?	:-)i  e Dave, you have presented a relatively balanced view of this issue, even though it looks as though you E are *really* affected by it.  Please keep up your viewpoint, as well.t  n Folks, please let's all make an effort to keep the discourse civilized - we can all violently disagree without resorting to namecalling.c   Thanks,s Brad > 	 > Thanks,a > Bradx >>> In article <Pine.SGI.4.21.0106251430450.16346-100000@world.std.com>, Terry C Shannon <shannon@world.std.com> writes: > <snip>P >>> Having a background effort to port VMS to IA-64 to cover all the bases makesQ >>> sense. Stopping development and selling Alpha to Intel doesn't. It sends all yM >>> the wrong signals. Compaq have just created their own FUD which may well  " >>> destroy VMS, TRU64 and Compaq. >> n >> lK >> And this newsgroup is doing its damdest to ensure the destruction of thel >> aforementioned. >> p   ------------------------------  # Date: Tue, 03 Jul 2001 23:44:05 GMTc6 From: "Andy Bustamante" <a_c_bustamante@earthlink.net> Subject: Re: FUDD Message-ID: <9Ns07.1701$xp1.183917@newsread1.prod.itd.earthlink.net>  F I was the Y2K program manager for VMS sites.  We offered customers theK option of shutting down their VMS systems Friday 31-Dec-1999 and restartingkJ the next day, "just in case."   Of the 12 sites that elected to do this, 8H had to be directed to the power/halt buttons on their VMS systems.  ThisF proved to be the only VMS Y2K issue we dealt with.  Can anyone imagineC forgetting where your reset/power buttons are a Windows xyz system?t   --   Andy Bustamantee( remove the ascii-95's to reply by e-mail      < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3B3E0D77.E03ECA98@fsi.net...t > Larry Kilgallen wrote: > >p? > > In article <3B3CF79E.FD041A24@infopuls.com>, Christof Brasss <brass@infopuls.com> writes: > >e= > > > My experience with Slowaris on SPARC isn't quite good -c? > > > especially the NFS and NIS+ related parts are a source of > > > > problems. Some servers with certain functions have to be" > > > rebooted monthly (at least). > >"J > > I know a Solaris-centric shop that wanted to reboot their VMS machines6 > > each month because that is "normal" for computers. >cJ > Recent real-life lesson: it is possible to get so accustomed to machinesC > that *DON'T* need to be rebooted that the procedures to shutdown,-I > startup and/or reboot become lost artifacts due to a number of factors.. >t@ > Unless uptime demands are such that scheduled downtime is near: > impossible, I don't necessarily view this as a negative. >  > -- > David J. Dachterai > dba DJE Systemsf > http://www.djesys.com/ >k< > Unofficial Affordable OpenVMS Home Page and Message Board:! > http://www.djesys.com/vms/soho/t >sH > This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings > is to be expected. > B > Feel free to exercise your rights of free speech and expression. > H > However, attacks against individual posters, or groups of posters, are > strongly discouraged.  >s   ------------------------------   Date: 3 Jul 2001 22:54:16 -0400 5 From: pechter@i4got.pechter.dyndns.org (Bill Pechter)e) Subject: Re: Full port of VMS to Itanium.y3 Message-ID: <9hu0go$akt$1@i4got.pechter.dyndns.org>i  3 In article <3B38006B.7FEA9CBE@toyvax.Tucson.AZ.US>,i3 Vance Haemmerle  <vance@toyvax.Tucson.AZ.US> wrote:= >award!= >= >  Compaq is the next Lucent.= >=  E Hell no.  As an Ex-DECcie and Ex-Lucent Bell Labs geek... (who baileds) both times before the bottom dropped out)=  F Lucent may buy way too many companies and run them into the ground but; they don't unload their intellectual property THAT CHEAPLY.N  ) I'm of two minds on Compaq and the Alpha:C   Here's the options:n  H 1.  Compaq made a brilliant move for VMS -- compatibility with IA64 appsB can be added at little to no cost so they can gain access to apps B written for HPUX, SCO, Linux, IA64 without a major porting effort.E NT for IA64 can be emulated or run on top of Tru64 or VMS without tooWD many problems  and they get access to thousands of OEM packages with? less cost than full application ports.  Office for Win2k/64 rundG unmodified on a VAX--err-Alpha-err whatever box under X11 on both Tru64t and VMS.  ? 2.  Compaq will pay for this idiotic move with their existance.a  9 Guess which one it really will be given Cpq's management.t  - (I'm hoping for #1 but getting ready for #2).n  F Well, hope Charlie Matco can find up what's up with the Compaq brains. If there are any.m   Bill e -- a ---w>   Bill Gates is a Persian cat and a monocle away from being a >   villain in a James Bond movie              -- Dennis Miller 8   bpechter@shell.monmouth.com|pechter@pechter.dyndns.org   ------------------------------   Date: 04 Jul 2001 00:35:37 GMT' From: prosullivan@aol.com (PROSULLIVAN)m* Subject: Re: H-P EOLs PA-RISC Architecture: Message-ID: <20010703203537.13923.00002132@ng-bk1.aol.com>  . >HP have a server SuperDome which is allready . >able to support IA-64 and the IA-64 processor  M hmm. exactly how many superdomes have HP sold with that whizzy PA-RISC 552Mhz6 chip? HP aren't saying.0  J The poor customer who has an N class HP (552Mhz chip) and wants to  expandO beyond 8 cpu's has to go to a superdome, running shock horror, the same PA-RISChE 552Mhz chip. HP banked on Superdome being available with IA64 and are/A desperately trying to squeeze their PA-RISC until IA64 comes out.   B That is one reason why HP server sales have taken a nose-dive. The price/performance ratio dives.  L As a result sales in Tru64 and VMS GS machines has increased, despite all of Compaq's marketing effort.   ------------------------------  $ Date: Tue, 3 Jul 2001 20:26:16 -0500+ From: Phil Mendelsohn <mend0070@tc.umn.edu>13 Subject: Re: Hobby LIcense: One USER, or one LOGIN?lG Message-ID: <Pine.SOL.4.20.0107032024230.9843-100000@garnet.tc.umn.edu>y  % On Mon, 2 Jul 2001, Hans Vlems wrote:i  J > Perfect. A class A license with 0 units will load on any processor model1 > and allow an infinite number of users to logon.e  J Great!  Now all I have to do is persuade those proverbial monkeys to tradeI in their Selectrics for EDT!  Oh, wait, the license will expire before wer get Shakespeare...        ? > Martin Vorlaender <martin@radiogaga.harz.de> wrote in message07 > news:3b3f3f00.524144494f47414741@radiogaga.harz.de...m% > > Hans Vlems (hvlems@iae.nl) wrote:h4 > > > Mark Vance <mvance@iglou.com> wrote in message) > > > news:3B3DF757.FA66C5EE@iglou.com...cK > > > > Does the hobbyist license confine you to ONE USER at a time, or one.& > > > > LOGIN of one user at one time. > > > J > > > Assuming that the hobbyist license uses LMF, it depends on what type > > > of VMS license you have.$ > > > Is it an A, B, C or D license? > >b7 > > The hobbyist VMS license is a class A, 0 units one.r > >1 > > cu,  > >   Martin > > --H > >                         | Martin Vorlaender  |  VMS & WNT programmer5 > >  VMS is today what      | work: mv@pdv-systeme.de-I > >  Microsoft wants        |    http://www.pdv-systeme.de/users/martinv/N< > >  Windows NT 8.0 to be!  | home: martin@radiogaga.harz.de >  >  >    -- e6 "To misattribute a quote is unforgivable." --Anonymous   ------------------------------  % Date: Tue, 03 Jul 2001 21:53:06 +0200m2 From: martin@radiogaga.harz.de (Martin Vorlaender)9 Subject: Re: How to (auto-re)submit batch few times a daym; Message-ID: <3b4222a2.524144494f47414741@radiogaga.harz.de>c  6 Netsurfer (netsurfer@sentosa.singaporemail.com) wrote:B > Is there a simple batch DCL script to automatically resubmit its. > ownself few times a day given a fixed delay?  C Have a look at SCHEDULE.COM (courtesy of Wolfgang J. Moeller) on mynA website at http://www.pdv-systeme.de/users/martinv/schedule.com .t   cu,    Martin -- -G                            | Martin Vorlaender  |  VMS & WNT programmerr4  UNIX is user friendly.    | work: mv@pdv-systeme.deG  It's just selective about |   http://www.pdv-systeme.de/users/martinv/1;  who its friends are.      | home: martin@radiogaga.harz.dee   ------------------------------   Date: 3 Jul 2001 12:13:23 -0700t( From: klane@thriftyfoods.com (Kurt Lane)% Subject: HP DLT1 drives on Alpha VMS?g= Message-ID: <43a0fe51.0107031113.4dc8b103@posting.google.com>w   Hi all,o  D I am in the process of upgrading to an AlphaServer DS10, and hope toE get away from the current DAT DDS (TLZ-09) tape drive technology thatr$ is attached to our current MicroVAX.  B We are not backing up a lot of disk here, and the DAT drive is not8 winning any reliablity awards, so I am considering DLT1.  E The DS10 will be running OpenVMS Version 7.2-1, with a HP DLT1 drive,a0 part number C7483A (40/80 GB), using VMS Backup.  $ Are there any compatibility issues?    Other drives I should consider?e   Thanks,i Kurt   ------------------------------  % Date: Tue, 03 Jul 2001 23:43:12 -0400-2 From: rdeininger@mindspring.com (Robert Deininger)) Subject: Re: HP DLT1 drives on Alpha VMS?=L Message-ID: <rdeininger-0307012343120001@user-2ive6bt.dialup.mindspring.com>  = In article <43a0fe51.0107031113.4dc8b103@posting.google.com>,u) klane@thriftyfoods.com (Kurt Lane) wrote:n  	 > Hi all,u > F > I am in the process of upgrading to an AlphaServer DS10, and hope toG > get away from the current DAT DDS (TLZ-09) tape drive technology that & > is attached to our current MicroVAX.   Wise, and wise again!.  D > We are not backing up a lot of disk here, and the DAT drive is not: > winning any reliablity awards, so I am considering DLT1. > G > The DS10 will be running OpenVMS Version 7.2-1, with a HP DLT1 drive, 2 > part number C7483A (40/80 GB), using VMS Backup.  G We use the plain-vanilla, quantum-firmware DLT drive in 20/40 density. u
 VMS loves it.   & > Are there any compatibility issues?   C You can't know for sure until you try it.  Buy from a vendor who'll.H promise the drive works, and take it back if it doesn't?  If you alreadyA have the drive, hook it to a friend's alpha/VMS system as a test?-  ! > Other drives I should consider?C  J I'm happy with DLTs, and I can't think of another drive type I can say the same about.a   -- e Robert Deininger rdeininger@mindspring.coms   ------------------------------  # Date: Tue, 03 Jul 2001 18:02:27 GMTi$ From: Scott Vieth <svieth@wi.rr.com>+ Subject: Re: I didn't stick it upside down! ) Message-ID: <3B420947.83B3D598@wi.rr.com>v   That's insane!!a  ; How did you get the SBB in there?  Use a big rubber mallet?b  F Somebody must have pulled the front cover off the SBB and re-installed it the wrong way.s  @ I bet this drive is good for a few laughs when the field service' engineer comes out to look at things...t  
 -Scott :^)   zessin@decus.de wrote:  ) > http://www.decus.de/~zessin/pic/sbb.jpgt >a > -- > Uwe Zessin   ------------------------------  % Date: Tue, 03 Jul 2001 15:31:16 -0400 - From: Roberta Sutter <nmassage@ix.netcom.com> + Subject: Re: I didn't stick it upside down!)- Message-ID: <3B421D84.DC630982@ix.netcom.com>t  1 That's obviously the Southern Hemisphere variant.e   zessin@decus.de wrote:  ) > http://www.decus.de/~zessin/pic/sbb.jpg  >  > -- > Uwe Zessin   ------------------------------  $ Date: Tue, 3 Jul 2001 21:28:21 -0400- From: "Scott Smith" <s-gsmith@mindspring.com>t+ Subject: Re: I didn't stick it upside down!o/ Message-ID: <tk4s9nr7s450f4@corp.supernews.com>e  3 Did anyone else notice that the sticker is missing?   H <zessin@decus.de> wrote in message news:009FE727.B07520BA.16@decus.de...) > http://www.decus.de/~zessin/pic/sbb.jpgo >n > -- > Uwe Zessin   ------------------------------  % Date: Tue, 03 Jul 2001 23:12:14 -0400e2 From: rdeininger@mindspring.com (Robert Deininger)+ Subject: Re: I didn't stick it upside down! L Message-ID: <rdeininger-0307012312140001@user-2ive6bt.dialup.mindspring.com>  = In article <tk4s9nr7s450f4@corp.supernews.com>, "Scott Smith"   <s-gsmith@mindspring.com> wrote:  5 > Did anyone else notice that the sticker is missing?i  E Yes, I noticed.  I wonde what's really in that canister.  Perhaps thee1 missing plans for the Death Star, or Alpha EV8...l   -- e Robert Deininger rdeininger@mindspring.comi   ------------------------------  # Date: Tue, 03 Jul 2001 19:14:42 GMTe3 From: "David Schmitt" <dschmitt@la-archdiocese.net>p  Subject: Re: IA64 Rocks My World: Message-ID: <CQo07.3705$3R1.299458@paloalto-snr1.gtei.net>  2 "Gavin Scott" <gavin@allegro.com> wrote in message+ news:RM707.1$va3.962@news.nyc.globix.net...o [grep'd to /dev/null]aD > P.S. We actually have it running at the moment by pointing a largeF > houshold fan at the dead PS fan.  The airflow is enough to drive the; > bad fan (backwards :-) and keep the PS from tripping off.   F Dr. Rube Goldberg taught me a solution to this very problem on anotherJ off-contract, proprietary mound of hardware: drill holes in case and mountK slightly larger muffin fan over dead fan using self-tapping screws. You canmH usually tell if it's a pusher or a puller that you're emulating; it *is*( important to duplicate airflow patterns.  J I use loud 120V jobs; a eerie quiet means it's time to get the screwdriver and the spare out.   ------------------------------  % Date: Tue, 03 Jul 2001 13:52:08 -0700 & From: name99@mac.com (Maynard Handley)  Subject: Re: IA64 Rocks My World> Message-ID: <name99-0307011352080001@il0203a-dhcp93.apple.com>  = In article <un16nynko.fsf@earthlink.net>, Anne & Lynn Wheelerr <lynn@garlic.com> wrote:  * > name99@mac.com (Maynard Handley) writes: > K > > As I recall when RS/6000 first came out, there were three models (maybetJ > > 4). There was a mondo server type machine, a tower type machine, and aK > > desktop type machine of much the same size and shape as a desktop PC of  > > the time. I > > While I was aware that the higher end machines were multiple chips, InL > > thought those low-end desktops were single chip, but heck, I can believe+ > > it if you say they were also multichip.h > >  > > Maynards >  > Announced early 1990 >  > 320 ... desktopu > 520 ... deskside > 330 ... desktopl > 530 ... deskside< > 730 ... "wide" deskside w/vmebus for special graphics card > 930 ... rack mount > * > effectively same chipset and motherboard >  > x20 was clocked at 20Mhz > x30 was clocked at 25Mhz >  > then came x40s, and x50s i > < > x50s were announced Oct. 1990  and had 41.6 Mhz clock rate  2 Aah. 320 and 330 were the guys I was thinking of. D So same chipset after all. I guess for the lower price you got what,)    less RAM, disk, and RAM and disk slotsu    (maybe) slower bus /    fewer PCI or MCA or whatever they were slotsr    (maybe) less L2    lower speed CPU.e   Maynard(   ------------------------------  $ Date: Tue, 3 Jul 2001 23:57:08 +0100/ From: cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley).  Subject: Re: IA64 Rocks My World) Message-ID: <4kith9.n06.ln@teabag.cbhnet>r  A According to Bob Kaplow <kaplow_r@eisner.encompasserve.org.mars>:e# > Remember, AMD already has Palmer.s  G That's a real shame.  I'd have liked to have seen AMD have some sort ofd	 a future.    Chris. -- - -----BEGIN GEEK CODE BLOCK-----t
 Version: 3.12wD GIT/CM d?(pu)@ s:++>:+ a(?) C++(---) UB/L/S++++$ p--- L+++@ E--- W--E N+++(--) o+ w--- !O !M V(+) PS PE Y+ PGP+ t+(--) 5 X-(+) R- tv++ b+++a DI+++ G e+ h- r++ y+++ ------END GEEK CODE BLOCK------e   ------------------------------  % Date: Tue, 03 Jul 2001 21:12:21 +0100 + From: "antonio.carlini" <arcarlini@iee.org>d& Subject: Re: KZMSA support on VAX 7710' Message-ID: <3B422725.6AAC66EC@iee.org>t   "Steeples, Oliver" wrote: M > So it looks like AXP only, not VAX.  My VAX 7700 SOC shows CI based storage N > as the only option with no scsi HSx controllers allowed   As for striping on$ > an HSZ40, yes a license is needed.  + I'm late to the thread - seems to have beeno2 much traffic about something or other lately :-) -5 but the KZMSA XMI-SCSI board has Alpha-only firmware.m, No VAX firmware was ever done (at least none+ I know about) and it's not simply a lack ofy a VAX driver in this case.  . The KFMSA (XMI-DSSI) does come in two variants' (just a firmware change from one to thes' other IIRC) and that card supports bothd( VAX and Alpha (given the right firmware 	 variant).v   Antonior   -- d   ---------------h- Antonio Carlini             arcarlini@iee.org-   ------------------------------  % Date: Tue, 03 Jul 2001 22:48:18 -0600e From: yyyc186@mindspring.com+ Subject: Re: LCD Screen on VMS Workstation? ; Message-ID: <3b42a03b$1$lllp186$mr2ice@nntp.mindspring.com>a  : In <009FE376.389F2825.10@leva.leeds.ac.uk>, on 06/28/2001 <    at 04:16 PM, Ted Allwood <support@leva.leeds.ac.uk> said:  I I have a SyncMaster 570S (Samsung) hooked up to my AlphaPC164.  VMS likes-. it.  Needed the Elsa Gloria video card though.   Roland  D >Is anyone using an LCD flat panel monitor in conjunction with a VMSI >workstation?  I'd appreciate any information on makes/models  of monitorn9 >that are compatible, plus setup hints (nowt in the FAQ).n  I >Specifically, I have an Alpha 255/233 with ZLXP-L1 graphics card running,F >VMS 6.2-1H3 and Open3D 3.6.  A conventional monitor takes up too much	 >space.  e    	 >Regards,n >Ted     -- o; -----------------------------------------------------------  yyyc186@mindspring.com; ----------------------------------------------------------->   ------------------------------   Date: 3 Jul 2001 18:09:04 -0500.3 From: malmberg@encompasserve.org (John E. Malmberg)oN Subject: OpenVMS as bootserver for other OS's - was Re: Probably the strangest3 Message-ID: <87Y$qSx1sk0O@eisner.encompasserve.org>j  ` In article <9ht0c2$2bj6$1@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes: > And, it's even on topic!!!!s >r; > I have a desire to have available, but not full-time, thei@ > following VAX OSes: MicroVMS4.5, OpenVMS-6.2 and Ultrix32-3.0. >y > Now, the question:E >   While I know that I can run Ultrix32 diskless from another UltrixaC > server, is it possible to run all of these OSes diskless with theA0 > server being another VAX running OpenVMS-7.1??  $ > So the question(s) work out to be:L >    Can OpenVMS serve diskless machines running OSes and versions different >    than itself??  6 If OpenVMS can serve the required protocol, then sure.  F >    Is there a way (possibly boot flags) that can select what it will >    boot??a  < It depends on the local console program and the boot server.  F Basically a boot request comes on a specific protocol from an address,F and may pass along a requested boot image and flags.  MOP is basically+ proprietary, and most others will use TFTP.a  9 I do not know of any VAX consoles that will support TFTP.s  L Now the serving host may or may not ignore the information that the diskless" client is sending it for the boot.   It all is negotiable.e  M OpenVMS with a suitable TCPIP stack can be a boot host for MOP, TFTP, and NFS J protocols, and I think that the Alpha's may soon if not already be able to serve LAD and LAST  J With Pathworks or SAMBA, serving SMB over TCP/IP may work.  NETBeui should also work with Pathworks.V  H >    If the second is not possible, would the first be possible if I hadH >    a non-VMS mop server that could serve up different images on demandD >    and is there a VMS kernel that could be served up this way?? (I2 >    already know this can be done with Ultrix32.)  G MOP is only used for a primary boot for OpenVMS, the full boot requirese either LAD or LAVC.l  N I have not tried this, but it should be possible to run LINUX with all of it'sN disks except the boot floppy served from an OpenVMS system running either NFS, or possibly SAMBA / Pathworks.  > With LINUX on ALPHA, no local disks should be required at all.   -John  wb8tyw@qsl.network Personal Opinion Only.   ------------------------------  % Date: Tue, 03 Jul 2001 17:08:38 -0400 + From: John Eisenschmidt <jeisensc@aaas.org> 1 Subject: OT: The Great Computer Language Shootoutn# Message-ID: <sb41fc36.015@aaas.org>   % http://www.bagley.org/~doug/shootout/C  J My learning languages were Pascal and C++, so I'm well represented here. =K Those of you who adore Bliss, Ada, Fortran, PL/1, etc should either email =cF this guy or participate. This is pretty high profile in the CS/IS/IT =7 community - could be a boost to your favorite language.u   ------------------------------   Date: 3 Jul 2001 17:54:17 -0500d9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)t5 Subject: Re: OT: The Great Computer Language ShootoutA3 Message-ID: <rzPZ8zFQ8hEo@eisner.encompasserve.org>M  Q In article <sb41fc36.015@aaas.org>, John Eisenschmidt <jeisensc@aaas.org> writes: ' > http://www.bagley.org/~doug/shootout/e > L > My learning languages were Pascal and C++, so I'm well represented here. =M > Those of you who adore Bliss, Ada, Fortran, PL/1, etc should either email =-H > this guy or participate. This is pretty high profile in the CS/IS/IT =9 > community - could be a boost to your favorite language.e  0 I see no way to "participate" show on the pages.   ------------------------------  % Date: Tue, 03 Jul 2001 23:31:56 -0400T2 From: rdeininger@mindspring.com (Robert Deininger)5 Subject: Re: OT: The Great Computer Language Shootout0L Message-ID: <rdeininger-0307012331560001@user-2ive6bt.dialup.mindspring.com>  3 In article <rzPZ8zFQ8hEo@eisner.encompasserve.org>,s: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:  7 > In article <sb41fc36.015@aaas.org>, John Eisenschmidto <jeisensc@aaas.org> writes:s) > > http://www.bagley.org/~doug/shootout/o > > N > > My learning languages were Pascal and C++, so I'm well represented here. =O > > Those of you who adore Bliss, Ada, Fortran, PL/1, etc should either email =gJ > > this guy or participate. This is pretty high profile in the CS/IS/IT =; > > community - could be a boost to your favorite language.  > 2 > I see no way to "participate" show on the pages.  4 And I can't even get a connection to the web server.  + At least I won't get shot by this web page.a   -- , Robert Deininger rdeininger@mindspring.coms   ------------------------------   Date: 3 Jul 2001 17:45:38 GMTr1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)2- Subject: Probably the strangest request yet!! , Message-ID: <9ht0c2$2bj6$1@info.cs.uofs.edu>   And, it's even on topic!!!!l  9 I have a desire to have available, but not full-time, theo> following VAX OSes: MicroVMS4.5, OpenVMS-6.2 and Ultrix32-3.0.   Now, the question:C   While I know that I can run Ultrix32 diskless from another UltrixeA server, is it possible to run all of these OSes diskless with them. server being another VAX running OpenVMS-7.1??" So the question(s) work out to be:J    Can OpenVMS serve diskless machines running OSes and versions different    than itself??D    Is there a way (possibly boot flags) that can select what it will
    boot?? F    If the second is not possible, would the first be possible if I hadF    a non-VMS mop server that could serve up different images on demandB    and is there a VMS kernel that could be served up this way?? (I0    already know this can be done with Ultrix32.)   -- bJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Tue, 03 Jul 2001 23:26:37 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)1 Subject: Re: Probably the strangest request yet!!yL Message-ID: <rdeininger-0307012326370001@user-2ive6bt.dialup.mindspring.com>  H In article <9ht0c2$2bj6$1@info.cs.uofs.edu>, bill@cs.scranton.edu wrote:   > And, it's even on topic!!!!  > ; > I have a desire to have available, but not full-time, thec@ > following VAX OSes: MicroVMS4.5, OpenVMS-6.2 and Ultrix32-3.0. >  > Now, the question:E >   While I know that I can run Ultrix32 diskless from another UltrixiC > server, is it possible to run all of these OSes diskless with thee0 > server being another VAX running OpenVMS-7.1??  ! I can't comment on ultrix at all.   $ > So the question(s) work out to be:L >    Can OpenVMS serve diskless machines running OSes and versions different >    than itself??  F Yes.  An alpha can MOP boot a VAX, and vice versa.  But AFAIK, this isH only intended to boot satellites into the same cluster.  So all it meansG is that a boot node doesn't have to run the same OS as its satellites. lJ See the VMS clustering manual for an outline of how to do this.  I haven't- done it myself, nor do I know anyone who has..  J You _will_ need a different disk on the boot node for each version of VMS.  F You may run into trouble trying to cluster microVMS 4.5 with VMS 7.1. I (Can you even cluster microVMS 4.5?)  It should not be a problem with VMSg 6.2.  F I don't think this method will work to boot a "satellite" that's not aJ member of the same cluster as its boot node.  SCS (cluster communications)B is intimately involved in disk sharing and a zillion other things.  D Still, strange things are possible with VMS.  I guess you can use anH alphabook as a boot node for a GS320.  I suspect is is possible, becauseI the manual goes to the trouble of saying it's a really bad idea to use ann alphabook as a boot node. ;-)i  F >    Is there a way (possibly boot flags) that can select what it will >    boot??r  D Typical vaxes let you specify the boot device and boot flags.  For aI network boot, the boot server knows which initial system file to server.  J You can tweek the boot server to start whatever VMS you want.  Only one at/ a time per satellite ethernet address, however.o  H >    If the second is not possible, would the first be possible if I hadH >    a non-VMS mop server that could serve up different images on demandD >    and is there a VMS kernel that could be served up this way?? (I2 >    already know this can be done with Ultrix32.)  J I don't think there are loose bits of VMS floating around to do this.  YouD probably need the whole OS, and thus have to follow it's rules.  TheB problem isn't the initial load.  Rather, the hard part is that the? satellite expects to have SCS (cluster-voodoo) available almosthB immediately. Or you can write something that looks like SCS to theF satellite, but doesn't act like part of the cluster on the boot node. D (And SCS isn't completely documented for public consumption, AFAIK.)  E On the other hand, I'm NOT a wizard of clustering, so maybe there's ag; painless way around these problems that I've never learned.-  J I suppose just adding a couple of disks in an external enclosure is out of5 the question?  Just how old _is_ this beasty, anyway?g   -- 3 Robert Deininger rdeininger@mindspring.com!   ------------------------------  # Date: Wed, 04 Jul 2001 04:40:20 GMTe$ From: bigfanboy@yahoo.com (Ben Todd)G Subject: Re: Problems Creating ODBC Connections to RDB databases on vmso5 Message-ID: <Xns90D3F2C2C164Ebigfanboy@151.164.30.58>m  1 Nivlesh Chandra <NChandra001@itc.gov.fj> wrote indF news:084681714A1BD511970B0002A560015F2D742B@exchange01.govnet.gov.fj: L If this is a mission critical situation you could have a look at one of the L adapters that iWay Software offers to get to rdb. You could then get to rdb D from just about front end you wanted, JDBC, ODBC, ActiveX, XML. You / wouldn't be pinned down to a 'WinTel' platform.v    H > I had posted this question sometime earlier but I guess I was not very& > coherent. here is the question again > G > I have rdb databases on VMS Alpha Machines. The version of rdb is DECi, > Rdb V6.1-04 and the version of VMS is V6.0F > Now what I want to do is to connect to the rdb database using a odbcI > connection from a windows machine. Before this used to work but now for@G > some reason it does not. I do not have any manuals to work by and the/G > person that had setup the odbc stuff previously has long gone without-G > leaving any documentation. This is of urgency since I have to get theiH > ODBC connections up as soon as possible. Would really appreciate it ifI > someone could help me figure out what is going on or better still pointnG > me to documentation which I can follow to troubleshoot the problem...i > - > Your urgent help would be most appreciated.o >  > Nivi   ------------------------------  # Date: Wed, 04 Jul 2001 04:30:47 GMTy From: dittman@dittman.net  Subject: QBUS SCSI Adapter> Message-ID: <XZw07.3310$AM.119099@e420r-sjo3.usenetserver.com>  4 Does anyone know of a source for an inexpensive SCSI3 controller for a QBUS MicroVAX system?  I'd like toh3 be able to stick a SCSI disk and tape on the system62 to replace my RQDX3 and TQK50 controllers and RD54 and TK50 drives.   Thanks!G -- S Eric Dittman dittman@dittman.netm   ------------------------------  % Date: Tue, 03 Jul 2001 17:33:26 -0600a From: yyyc186@mindspring.com Subject: Re: Qlogic question; Message-ID: <3b425700$1$lllp186$mr2ice@nntp.mindspring.com>s  G In <rdeininger-0207011230420001@user-2iveajn.dialup.mindspring.com>, ong 07/02/2001  B    at 12:30 PM, rdeininger@mindspring.com (Robert Deininger) said:  F I'm just going to put the 18Gig drive back in it.  A vendor sent me anE update file which needed to be run from the ARC console to update theoH contoller BIOS.  Still no fixy.  I have seen many older SCSI controllersJ on the PC platform die in the same manner.  They call cap out around 20GigK and anything over that in size gets reported as 8Gig to be DOS compatible. -B This is an old SCSI BIOS limitation which I thought was long since9 gone....  I will put the 34Gig in my Netware file server.   G I will have too boot the system later and verify what version of VMS itoG has, but I believe it is the plain 7.1 which shipped as the Hobbiest CDn
 last year.     Roland< >In article <3b3fde9f$1$lllp186$mr2ice@nntp.mindspring.com>, >yyyc186@mindspring.com wrote:   >> All,h >> oL >> I have an Alpha PC164 running VMS and the SRM console.  All was well withJ >> a pair of 18Gig drives in it.  Today I installed an extra 34Gig drive IG >> had laying around.  No biggie...until I checked the drive size afteraJ >> initing.  Shows up as 8Gig.  When running the FWUPDATE program it loadsE >> the driver for Qlisp10x0.  Is this a known "feature" of the QlogiciM >> controller?  I have seen other older SCSI controllers which cap out around 	 >> 20Gig.e  3 >What version of VMS?  Are your patches up to date?.  F >We had trouble with 36 GB drives until we upgraded to VMS 7.1-2 (plus> >patches).  Plain 7.1 doesn't handle newer/bigger drives well.  G >The console might not like the drive.  It might report the wrong size,sF >but still let VMS use the drive.  It might not be able to boot from aI >large drive (though I've never heard of this on an alpha), but the drivel! >might be fine for anything else.g     --  ; -----------------------------------------------------------  yyyc186@mindspring.com; -----------------------------------------------------------s   ------------------------------  # Date: Tue, 03 Jul 2001 17:50:13 GMTJ4 From: "Terry C. Shannon" <terryshannon@mediaone.net>' Subject: Re: Question to Charlie Matco.k; Message-ID: <pBn07.1108$tH1.930721@typhoon.ne.mediaone.net>o  = "andrew harrison" <andrew.nospam@uk.sun.com> wrote in message $ news:3B41EC25.9B3087D7@uk.sun.com... > Bill Todd wrote: > > < > > "Rob Young" <young_r@encompasserve.org> wrote in message1 > > news:apcMbq61Rqob@eisner.encompasserve.org...s > >3 > > .../ > >(: > >   Part of the rationale behind Alpha getting set asideC > > > was a careful study of where IA64 will be in 3-5 years.  TheyaG > > > concluded the performance differential will be marginal.  You can-E > > > call into question that reasoning... but you can bet they spenttE > > > time and money on that and know more about McKinley performance7F > > > than many outsiders do.  Point is, IA64 will be very competitiveE > > > and cheaper than RISCs 2-3 years out.  That is a very bad placee1 > > > to be for non-IA64 platforms 2-3 years out.o > >l > > ...e > >s > > as Intel has beenHB > > > promising us it gets much better and IDF in February shockedG > > > a few people when they found out how fast McKinley will be going.Z > > > Who knows about Madisonl > >m= > > Can this truly be the same Rob Young who has made so manyoD > > admiring-to-the-point-of-adulation statements about future Alpha performanceSK > > (especially in comparison to future IA64 performance) for lo these many I > > years?  Are we witnessing a deathbed conversion (so to speak - I hope  noti > > literally)?r > >- > 0 > Funny isn't it. Rob the most rabid of all anti. > Intel FUDsters with a particular dislike for( > IA-64 has over night become a convert. > 1 > Circumstances make for very strange bed fellowse >n  G Oh, there are folks who will have a tougher time of it than Rob. CompaqcF marketeers, f'rinstance, who must now eat crow and humble pie. HeapingI helpings thereof, served up on placemats bearing the words of wisdom froms4 Compaq's October 11, 1999 Alpha and IA64 comparison.   ;-}t   ------------------------------   Date: 3 Jul 2001 14:17:56 -0500u+ From: young_r@encompasserve.org (Rob Young) ' Subject: Re: Question to Charlie Matco. 3 Message-ID: <GGZURyn$3YAl@eisner.encompasserve.org>r  r In article <pBn07.1108$tH1.930721@typhoon.ne.mediaone.net>, "Terry C. Shannon" <terryshannon@mediaone.net> writes: >    >>1 >> Funny isn't it. Rob the most rabid of all antit/ >> Intel FUDsters with a particular dislike for ) >> IA-64 has over night become a convert.- >>2 >> Circumstances make for very strange bed fellows >> >    Andrew,-  5 	Not so much a convert as attempting to be objective.-@ 	You see in another forum, I made a statement that EV7 should beE 	the high-end box when it ships.  But then that is it.  In 4-5 years,vH 	IA64 should be 80%+ of the 64 bit space all others will be bit players.  B 	Maybe we dig through Deja to see how this pans out in a few years, 	as we have occasionally done to each other.  B 	Again, I'm a big Alpha fan... but Alpha goes away in a few years. 	What to do ... what to do.l   				Robi  I > Oh, there are folks who will have a tougher time of it than Rob. Compaq,H > marketeers, f'rinstance, who must now eat crow and humble pie. HeapingK > helpings thereof, served up on placemats bearing the words of wisdom from 6 > Compaq's October 11, 1999 Alpha and IA64 comparison. >    ------------------------------  $ Date: Tue, 3 Jul 2001 15:52:43 -0400' From: "Bill Todd" <billtodd@foo.mv.com> ' Subject: Re: Question to Charlie Matco.t( Message-ID: <9ht7jf$qhs$1@pyrite.mv.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:GGZURyn$3YAl@eisner.encompasserve.org...oG > In article <pBn07.1108$tH1.930721@typhoon.ne.mediaone.net>, "Terry C. , Shannon" <terryshannon@mediaone.net> writes: > >o >a > >>3 > >> Funny isn't it. Rob the most rabid of all antit1 > >> Intel FUDsters with a particular dislike foro+ > >> IA-64 has over night become a convert.s > >>4 > >> Circumstances make for very strange bed fellows > >> > >  >k	 > Andrew,t > 6 > Not so much a convert as attempting to be objective.A > You see in another forum, I made a statement that EV7 should be F > the high-end box when it ships.  But then that is it.  In 4-5 years,I > IA64 should be 80%+ of the 64 bit space all others will be bit players.e  J Rob, I've never known you to be anything like objective, and you certainlyJ don't seem to be being so now.  Instead, you're continuing to be a boosterG for whatever you see Compaq's VMS direction as being - and it isn't anyhC easier to swallow now than it was when you were proclaiming Alpha'sk inevitable dominance.t  G When confronted with Paul DeMone's (the source you've promoted over theoH years as *the* place to go to assess Alpha-vs.-IA64 issues) opinion that@ Alpha would have retained or increased its performance edge overJ contemporary IA64 implementations for as far into the future as any of theI road maps went, you just say "Yes, Paul's still a really credible source"lJ and proceed blithely to ignore his assessment in favor of Compaq's drivel.J So since nothing has changed (except Compaq's attitude) since your ferventJ support of Alpha's future potential, your own conversion casts, to say the( least, severe doubt on your objectivity.   - bill   ------------------------------  $ Date: Tue, 3 Jul 2001 15:54:04 -0400' From: "Bill Todd" <billtodd@foo.mv.com> ' Subject: Re: Question to Charlie Matco.1( Message-ID: <9ht7m3$qi0$1@pyrite.mv.net>  ? "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messaget5 news:pBn07.1108$tH1.930721@typhoon.ne.mediaone.net...-   ...-  I > Oh, there are folks who will have a tougher time of it than Rob. CompaqrH > marketeers, f'rinstance, who must now eat crow and humble pie. HeapingK > helpings thereof, served up on placemats bearing the words of wisdom fromn6 > Compaq's October 11, 1999 Alpha and IA64 comparison.  G If Alpha and the systems on it had been marketed with anything like theyF competence used in writing that comparison, we wouldn't be having this discussion.y   - bill   ------------------------------  % Date: Tue, 03 Jul 2001 16:00:30 -0500t/ From: Chris Scheers <chris@applied-synergy.com>/K Subject: Re: Questions on VAX local (SCSI) shadowed system disk H/W upgradew3 Message-ID: <3B42326E.B3AD1E4A@applied-synergy.com>-  ! norm.raphael@jamesbury.com wrote:u > E > I am about to upgrade a pair of VAXstation system disk shadow pairs = > so I will have more space before I do the V7.3 s/w upgrade.- > It is currently running V6.2.u > ! > The old ones are RZ26L-EN  1GB.n" > The new ones are RZ28L-EN 2.1GB.  H You don't say what model VAXstation you have, but just to be on the safeG side, the first thing you need to do is to ensure that you don't have as VAXstation 3100.  ? The RZ28 can not be used as a system disk on a VAXstation 3100.g  G -----------------------------------------------------------------------u$ Chris Scheers, Applied Synergy, Inc.  C Voice: 817-237-3360            Internet: chris@applied-synergy.com     Fax: 817-237-3074S   ------------------------------  $ Date: Tue, 3 Jul 2001 13:57:11 -0400- From: "Peter Weaver" <peter.weaver@stelco.ca>a6 Subject: Re: Re; One more dreadful thought to consider4 Message-ID: <8In07.259357$Z2.3069349@nnrp1.uunet.ca>  ? "Terry C. Shannon" <terryshannon@mediaone.net> wrote in message-4 news:gJ1%6.486$9r6.477439@typhoon.ne.mediaone.net... >...G > There is that;-}. But hey, realize that a MiG burns a lot of JP-4, sog LarryuG > needs to charge high prices to as to keep his Russian toy in the air.n >...  L Does Larry still own his MiG? I thought he sold it 2 or 3 years ago. I could( not find it during a quick check throughJ http://162.58.35.241/acdatabase/acftref_inquiry.htm. The only 2 MIG-29's ID see on the FAA site belong to "AIR ASSETS INC 532 MAINE ST QUINCY IL 62301-3932."   ------------------------------  # Date: Tue, 03 Jul 2001 18:19:08 GMTt4 From: "Terry C. Shannon" <terryshannon@mediaone.net>6 Subject: Re: Re; One more dreadful thought to consider; Message-ID: <w0o07.1125$tH1.943255@typhoon.ne.mediaone.net>c  8 "Peter Weaver" <peter.weaver@stelco.ca> wrote in message. news:8In07.259357$Z2.3069349@nnrp1.uunet.ca...A > "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messagea6 > news:gJ1%6.486$9r6.477439@typhoon.ne.mediaone.net... > >...I > > There is that;-}. But hey, realize that a MiG burns a lot of JP-4, so  > Larry I > > needs to charge high prices to as to keep his Russian toy in the air.  > >... > H > Does Larry still own his MiG? I thought he sold it 2 or 3 years ago. I could * > not find it during a quick check throughL > http://162.58.35.241/acdatabase/acftref_inquiry.htm. The only 2 MIG-29's IF > see on the FAA site belong to "AIR ASSETS INC 532 MAINE ST QUINCY IL > 62301-3932." >s  I I dunno if Larry tired of his toy, or if it fact was a '29. Rumour has itrG some guy up in Burlington, VT has a MiG of older vintage, a '23 or '25,. IIRC.t  K At least Larry's got the Gulfstream to tool around in. Much more comfy thanb a MiG, I'll bet!   ------------------------------  # Date: Wed, 04 Jul 2001 05:56:13 GMT  From: Dirk Munk <munk@home.nl>! Subject: Re: RMS file performances' Message-ID: <3B42AFFC.60B7DAB9@home.nl>i   Kenneth wrote:  J > Beside file fragmentation, what statistic should I check to for the poor) > performance of the index type RMS file?l   In general: file design.   some rules:   = Avoid large amounts of duplicate keys, deadly for performancesH If you have random inserts in indexes and / or the record area, use fill( factors. This will avoid buckets splits.I Increase the bucket size. For sequential access this means: double bucketoH size  = double performance. For random access: larger bucket size = lessH index depth = less IO. In my experience larger bucket size has almost no drawback with modern disks.oF Use global buffers. This may load a lot of the indexes in memory, thus avoiding disk access. I Use Convert/Reclaim to cleanup the internal structure of the file withouteK building a new one (you can always start with this to improve performance).'   Regards,   Dirk   ------------------------------  % Date: Tue, 03 Jul 2001 21:08:50 -0500 * From: cjt & trefoil <cheljuba@prodigy.net> Subject: Re: Sadness+ Message-ID: <3B427AB2.737DC3DC@prodigy.net>.   andrew harrison wrote: >  > Christof Brass wrote:s > >  <snip> > >lB > > SUN is already in a process of dropping Slowaris on SPARC. The$ > > IA32 version is almost dead now.  3 If they are, they sure have odd ways of showing it.a     > 5 > Really, you have made this assertion before withouth > backing it up. > 8 > So what makes you think that Sun has any intentions to > drop Solaris ??f > 	 > regardse > Andrew Harrisont > Enterprise IT Architect    ------------------------------   Date: 3 Jul 2001 12:47:43 -0700e& From: dvoigt@talarian.com (Dave Voigt)Y Subject: Sending a double (floating-point) field over tcp from OpenVMS 7.2 to Tru64 4.0 ui= Message-ID: <553fbce0.0107031147.6c1ab079@posting.google.com>s  C I have a customer that is receiving the double on the Tru64 machine E incorrectly. Incorrectly, meaning that one of the bytes is zeroed outtF when it should have a number in it. This missing byte makes the actual5 number being represented slightly off. For example, asE 4.712000000000000e+03 is sent from the VMS program and is received byeC the Tru64 program as 4.608000000000000e+03. The bytes for 4712 lookvE like this: {0 0 0 0 0 104 -78 64} and 4608 look like this: {0 0 0 0 0lF 0 -78 64}. There is number conversion done on the Tru64 side to handleE DecG real-format to IEEE real-format, but I don't believe that that'soF the problem. The reason for this is that this problem doesn't occur atF my companies site but it does at the customer's. The customer is usingF the following compilers: Compaq C++ V6.2-048 for OpenVMS V7.2-1 on VMSE 7.2 and Compaq C++ V6.2-024 for Digital UNIX V4.0F(Rev.1229) on Tru64gF 4.0. My company is using Dec C V6.0-001 on OpenVMS Alpha V7.2-1 on VMSC 7.2 and Compaq C++ V6.2 for Tru64 UNIX on Tru64 5.0. I'm looking tonB find out if there are any known problems related to the compilers,D hardware or anything else that could affect real numbers. Has anyone2 seen strange behavior like this with real numbers?   ------------------------------   Date: 3 Jul 2001 16:05:55 -0700n" From: lyngwyst@aol.com (Jay Braun)0 Subject: Re: Thanks Compaq for the new business!= Message-ID: <4ce97a1a.0107031505.5b14b5a1@posting.google.com>   " Then again, there is always Linux.  = At JPL (Jet Propulsion Laboratory), we just ported a militarynA simulation from VAX/VMS to Intel-based Linux.  It runs fast, it's E stable, and we're not worried about our hardware becoming (remaining)iE obsolete.  You can read more in the July 2001 Linux Journal, page 10.   D This NG has many die-hard OpenVMS users.  OpenVMS is a great OS, andB has deserved your support for these past 20+ years.  But there areC low-risk, practical paths to minimize your risk.  Linux will run onuD anything.  Most OpenVMS applications can be ported to Linux with the@ right approach; there are even companies that sell packages that. emulate OpenVMS features (we did not use any).  B You'll see lots of positive and negative statements about Linux on? comp.os.linux.advocacy.  Most of those threads compare Linux tooF Windows and to proprietary UNIXes.  Like similar arguments on this NG,D they ultimately become religious arguments, and therefore, never getE resolved.  Linux is _not_ "better" than OpenVMS.  It just has more of-C a future.  That's the way history unfolded.  Please be open-minded.i   Jayi   ------------------------------   Date: 3 Jul 2001 15:23:54 -050099 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)o" Subject: Re: The Alpha/IA64 Hybrid3 Message-ID: <xu1946w16jvw@eisner.encompasserve.org>l  q In article <Mrj07.402598$eK2.81551047@news4.rdc1.on.home.com>, "Yousuf Khan" <ykhan@nospam.home.com.spam> writes: : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:alxQ0RAo2HBL@eisner.encompasserve.org...0C >> Failover clustering isn't clustering.  The failover box could go C >> away for a weeks vacation and if nothing happened to the primarysE >> everything would be okay.  If resources are being shared (a better,@ >> definition of clustering), a box going away may not be a good2 >> thing (if you are teetering above a threshold). > 4 > Sun, HP, and Veritas would beg to differ with you.  ; Sun and HP are late to the game and trying to make excuses.l; Even Tru64 (nee Digital Unix (nee DEC OSF1)) claimed it hadl= "clustering" when it really did not.  Tru64 claims to be more ; equal to VMS these days, but I have no personal experience.d  L > There is a form of asymmetric load-balancing going on in a product such asK > Veritas Cluster Server. Basically, you can have upto 32 nodes in a singlerM > cluster, all running different applications, and if one of the nodes fails, N > the application can fail over to another box, which might already be runningK > a different application. There is load balancing in the sense that all of,J > the boxes are busy running a few applications, and when one of the nodesL > goes down the other nodes take over its applications, increasing their own > loads temporarily.  = Another way to configure failover.  Certainly not clustering,u3 no matter what Veritas uses for their product name.o  A >> Prior to failover becoming widely available, we had a customeriB >> that had two RS/6000s.  One primary, and one backup that sat inB >> a closet.  They would periodically run a fire drill by wheeling? >> the box out of the closet and plugging it in to the storage, B >> simulating a failed primary.  That paradigm has advanced to the? >> point whereby you can leave it plugged in and have nice Perlr2 >> scripts to failover your application(s).  Cute. > N > All in all, most clustering software is basically a glorified version of the > old Perl scripts.a  B Now I am sure you have never used or programmed for a VMS cluster.  N ==============================================================================N Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> ClustersN ==============================================================================   ------------------------------  # Date: Tue, 03 Jul 2001 19:38:35 GMTm) From: Bob Willard <bobwbsgs@mediaone.net>l" Subject: Re: The Alpha/IA64 Hybrid, Message-ID: <3B421EED.7B5B08B6@mediaone.net>   Anne & Lynn Wheeler wrote: > B > we had fallover announced and shipping in mid-90 on 6000 and ...  = VMS had fallover running in '77.  Failover took a bit longer.r -- n Cheers, Bob    ------------------------------  # Date: Tue, 03 Jul 2001 21:02:08 GMT + From: Anne & Lynn Wheeler <lynn@garlic.com>s" Subject: Re: The Alpha/IA64 Hybrid) Message-ID: <upubhybeg.fsf@earthlink.net>   + Bob Willard <bobwbsgs@mediaone.net> writes:l   > ? > VMS had fallover running in '77.  Failover took a bit longer.t > -- n
 > Cheers, Bobt  ? yep ... we had worked on loosely-coupled (including fall-over &aD fail-over) starting in '60s continuing thru the '70s. My wife was inF g'burg JES group ... both JES2 and JES3 having cluster/loosely-coupledC support ... and then was con'ed into going to POK to be responsible > for loosely-coupled (aka cluster) architecture (there were two: multi-cpu architectures ... the person responsible for SMP@ architecture and my wife responsible for loosely-coupled/clusterC architecture and originated "peer-coupled shared data" architectureo@ ... that was subsequently basis for ims hot-standby and sysplex.   misc. refs:e4 http://www.garlic.com/~lynn/98.html#30 Drive letters5 http://www.garlic.com/~lynn/98.html#35a Drive letters?7 http://www.garlic.com/~lynn/98.html#37 What is MVS/ESA?IA http://www.garlic.com/~lynn/98.html#40 Comparison Cluster vs SMP? @ http://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390A http://www.garlic.com/~lynn/99.html#77 Are mainframes relevant ?? D http://www.garlic.com/~lynn/99.html#92 MVS vs HASP vs JES (was 2821)q http://www.garlic.com/~lynn/99.html#100 Why won't the AS/400 die? Or, It's 1999 why do I have to learn how to usegL http://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases@ http://www.garlic.com/~lynn/2000.html#13 Computer of the century- http://www.garlic.com/~lynn/2000f.html#30 OT?1- http://www.garlic.com/~lynn/2000f.html#37 OT?r< http://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.= http://www.garlic.com/~lynn/2001c.html#69 Wheeler and Wheeler<D http://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?C http://www.garlic.com/~lynn/2001e.html#2 Block oriented I/O over IPe  ? it took some time to start translating that to Unix platform onk! commodity components in the '80s.o  C you would really be surprised at the people that current run around C esposing various clusters stuff that we had major arguments with inc> the late 80s and early 90s (both from standpoint of concurrent; operation, scale-up, fall-over, continuous operation, etc).i  C as per thread in this ng in april ... we used similar semantics for F HA/CMP DLI as found in VMS (because there was effectively port of someF DBMS from vax cluster to ha/cmp). As per attached ... some of the DBMSD vendors that had vms cluster (failover) implementations ... also hadC their list of "things needing fixing" which we were able to benefith, from in doing the implementation for ha/cmp.   misc. refs:i( http://www.garlic.com/~lynn/2001e.html#2( http://www.garlic.com/~lynn/2001e.html#4   random refs:/ http://www.garlic.com/~lynn/subtopic.html#hacmpb. http://www.garlic.com/~lynn/subtopic.html#hone  % slightly related from RAS standpoint:,. http://www.garlic.com/~lynn/subtopic.html#disk   -- @F Anne & Lynn Wheeler  | lynn@garlic.com - http://www.garlic.com/~lynn/    ------------------------------  % Date: Tue, 03 Jul 2001 16:59:35 -0500n' From: Greg Pfister <pfister@us.ibm.com>a" Subject: Re: The Alpha/IA64 Hybrid* Message-ID: <3B424047.D782DA69@us.ibm.com>   Bill Todd wrote: > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:alxQ0RAo2HBL@eisner.encompasserve.org...tJ > > In article <ZFb07.398996$eK2.81072129@news4.rdc1.on.home.com>, "Yousuf, > Khan" <ykhan@nospam.home.com.spam> writes:E > > > "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messagec: > > > news:_lb07.709$tH1.512983@typhoon.ne.mediaone.net...> > > >> > In which specific categories did Tru64 surpass HP-UX? > > >> > > >> Clustering, for one.i > > >IF > > > Now, there are two separate meanings for clustering. There's theG > > > load-balancing type clustering, where multiple nodes run the samevL > > > applications and share tasks with each other simultaneously to work onL > > > bigger workloads. Then there is the failover type clustering, where itA > > > simply a high-availability option. Which one is cited here?c > > >  > >') > > Failover clustering isn't clustering.e > K > You guys really need to read Greg's book (well, Rob needs to re-read it).tN > Clustering means many different things to many people, and no one group owns > the definition.o  $ True, and thanks for the plug, Bill.  @ More specifically -- even I would be hard-pressed to describe as: "clustering" the kind of thing described in a later threadA branch: roll a machine out of a closet, turn it on, try to get its' working. Lots of luck making that work.x  @ Failover clustering really tries to be a bit better than that --A at least having the "other" machine up and running, with failovero> initiated automatically. *That,* in many (not all) contexts is= decidedly nontrivial, usually takes weeks to set up, requires @ continuous maintenance, and has to be periodically tested if you- want any confidence at all that it will work.r  
 Some reasons:e  > First of all, how do you know the other guy failed? Heartbeat.; Um, did he stop, or is he busy right now? (It's a real-timeo? signal, and few OSs are set up to deal with it right.) Now, aretA you *really* sure he's not accessing those disks any more? If you 3 both start writing them, scrambled data. And so on.w  @ And by the way, are you really sure that application is going to9 run after restart on the other system? Did you faithfullydA replicate all the tuning, option-setting, updating, etc., you didnA on one box to the other? For the app, the middleware, and the OS?-@ Do you even *know* exactly what you did to get it to work on the
 first system?   A You haven't used the other paths to those disks recently. Are youS= sure the cleaning people didn't jostle a connector loose? AndD@ what about the re-cabling everybody did last week, was it a mite0 too tight in some areas? Near those paths? Hmmm?  : And, of course, most people aren't satisfied just to leaveA another system sitting there doing nothing, just in case. There's A always something else running on it. Are the priorities set right.> to keep your customers satisfied? Of course, this isn't "just" failover clustering any more.h  : And yes, I would agree with the statement that there is an? advantage Tru64Cluster may have acquired over many others. TheytA added the single-system image facilities that have a long history-? but eventually landed there. This capability makes it look likec? there's a single copy of the OS, even though there are multiple ? boxes. That helps a lot with some of the problems, particularlyu@ keeping the OS parameters and options and tuning the same on all? the systems. Somewhat helps the same problem for middleware andr> apps, but they need rewriting to really eliminate that part of; the problem. It provides advantages, but in many cases theye@ aren't overwhelming; they could be overshadowed if, for example,@ the customer really wanted some form of fancy cascading failover' that another vendor had and Tru didn't.a  7 Is this enough of a difference to win the usual clusters@ comparison contest? -- meaning: add up incommeasurate qualities,@ see who gets the biggest score -- quite possibly. I think it did in DH Brown's latest compaison.o  ? By the way, Compaq recently took that capability and applied it 9 to Linux, open-sourcing the whole thing. Makes you think.-@ True64Cluster dies with Alpha, right? Just like VMS. Locus lives on, now in open source.a  ? (By the way, to complete the book plug: "In Search of Clusters,e? second edition" published by Prentice Hall. ISBN 0-13-899709-8.t3 Generally avaiable in bookstores. A couple of URLs: E http://www.amazon.com/exec/obidos/ISBN=0138997098/4308-1385679-076577e (Amazon)> http://www.prenhall.com/ptrbooks/ptr_0138997098.html (Prentice Hall))   (Sorry, no third edition yet.)   Greg Pfister   ------------------------------  # Date: Wed, 04 Jul 2001 00:36:27 GMTo0 From: "Yousuf Khan" <ykhan@nospam.home.com.spam>" Subject: Re: The Alpha/IA64 Hybrid> Message-ID: <fyt07.406522$eK2.82328712@news4.rdc1.on.home.com>  F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:xu1946w16jvw@eisner.encompasserve.org...-6 > > Sun, HP, and Veritas would beg to differ with you. > = > Sun and HP are late to the game and trying to make excuses.d  K I'm afraid not, it truly is a form of clustering, whether it fits into your, narrow definition or not.a  ? > Another way to configure failover.  Certainly not clustering,o5 > no matter what Veritas uses for their product name.!  0 Certainly is, your narrow view needs broadening.           Yousuf Khan    ------------------------------   Date: 3 Jul 2001 20:59:12 -0500e9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) " Subject: Re: The Alpha/IA64 Hybrid3 Message-ID: <xCFJA14cPQtJ@eisner.encompasserve.org>   q In article <fyt07.406522$eK2.82328712@news4.rdc1.on.home.com>, "Yousuf Khan" <ykhan@nospam.home.com.spam> writes:aH > "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message/ > news:xu1946w16jvw@eisner.encompasserve.org...c7 >> > Sun, HP, and Veritas would beg to differ with you.c >>> >> Sun and HP are late to the game and trying to make excuses. > M > I'm afraid not, it truly is a form of clustering, whether it fits into yourr > narrow definition or not.r > @ >> Another way to configure failover.  Certainly not clustering,6 >> no matter what Veritas uses for their product name. > 2 > Certainly is, your narrow view needs broadening.  < So far as I know, the term was first used by VMS about 1985,? for what they offered then (not materially different from today-2 with regard to the capabilities under discussion).  4 Was there a prior use of "cluster" in this context ?  < If not, then lesser copycat efforts are not really clusters.9 Greater copycat efforts are, but I have not heard of any, 7 including Tru64.  The net effect includes the operatingp: system and the software that runs on it.  Absent RMS or an9 equivalent, programs have to be specially written to makea  use of the cluster capabilities.  : There is a Sun fellow here in comp.os.vms who insists that; Sun has something equivalent if you just add legacy Oracle.r9 Somehow I doubt that all utilities on Solaris access disk  through legacy Oracle.   ------------------------------  $ Date: Tue, 3 Jul 2001 21:53:46 -0400' From: "Bill Todd" <billtodd@foo.mv.com>a" Subject: Re: The Alpha/IA64 Hybrid( Message-ID: <9htso9$go4$1@pyrite.mv.net>  F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:xCFJA14cPQtJ@eisner.encompasserve.org...    ...      Absent RMS or an; > equivalent, programs have to be specially written to makeh" > use of the cluster capabilities.  F Trouble is, at least some of those other cluster facilities (SUN's and+ Tru64, for two) *do* have file systems thate  C a) allow concurrent access to the same data from multiple nodes and0  E b) include robust access and distributed (byte-range) lock management8L facilities for that data that survive the loss of any node without requiringJ client applications to do anything but wait for storage fail-over and lockG state re-build to occur (though it's reportedly not as fast as in a VMS I environment - something on the order of a minute, unless they've improvedo the speed lately).  L In other words, rather a lot like the distributed facilities RMS provides onK VMS.  Tru64 even supports decent distributed caching as of its new release,uE IIRC (whatever SUN supports in this area would likely be whatever NFSV
 supports).  H I've told comp.os.vms this multiple times over the past year or two, but. your hearing seems to be permanently impaired.   - bill   >u< > There is a Sun fellow here in comp.os.vms who insists that= > Sun has something equivalent if you just add legacy Oracle.a; > Somehow I doubt that all utilities on Solaris access diskr > through legacy Oracle.   ------------------------------  # Date: Wed, 04 Jul 2001 03:04:25 GMTo$ From: Ric Werme <werme@mediaone.net>" Subject: Re: The Alpha/IA64 Hybrid< Message-ID: <ZIv07.1672$tH1.1326049@typhoon.ne.mediaone.net>  - young_r@encompasserve.org (Rob Young) writes:i  r >In article <Mrj07.402598$eK2.81551047@news4.rdc1.on.home.com>, "Yousuf Khan" <ykhan@nospam.home.com.spam> writes:   >> iB >>> Prior to failover becoming widely available, we had a customerC >>> that had two RS/6000s.  One primary, and one backup that sat in2C >>> a closet.  They would periodically run a fire drill by wheelingr@ >>> the box out of the closet and plugging it in to the storage,C >>> simulating a failed primary.  That paradigm has advanced to thes@ >>> point whereby you can leave it plugged in and have nice Perl3 >>> scripts to failover your application(s).  Cute.a >> tO >> All in all, most clustering software is basically a glorified version of theo >> old Perl scripts. >> y  ; >	As the OS/390 and VMS folks shudder at the thought . . . e  H Indeed.  I should give him a peek at the Tru64 source code.  Were single: system image support as simple as a random Perl script....   --@ Ric Werme                            | werme@nospam.mediaone.net; http://people.ne.mediaone.net/werme  |       ^^^^^^^ delete9   ------------------------------  # Date: Wed, 04 Jul 2001 03:38:36 GMT:+ From: Anne & Lynn Wheeler <lynn@garlic.com>6" Subject: Re: The Alpha/IA64 Hybrid) Message-ID: <uy9q5qs7m.fsf@earthlink.net>d  ; Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:t   > > > So far as I know, the term was first used by VMS about 1985,A > for what they offered then (not materially different from todayg4 > with regard to the capabilities under discussion). > 6 > Was there a prior use of "cluster" in this context ? > > > If not, then lesser copycat efforts are not really clusters.; > Greater copycat efforts are, but I have not heard of any,t9 > including Tru64.  The net effect includes the operatingd< > system and the software that runs on it.  Absent RMS or an; > equivalent, programs have to be specially written to makel" > use of the cluster capabilities. > < > There is a Sun fellow here in comp.os.vms who insists that= > Sun has something equivalent if you just add legacy Oracle.o; > Somehow I doubt that all utilities on Solaris access diskd > through legacy Oracle.  @ os/360 from the 60s was designed that way ... so was PARS (whichB morphed into ACP, the airline control program ... which eventuallyB morphed into the current TPF ... transaction processing facility).   random pars referencei& http://www.garlic.com/~lynn/99.html#24  F both os/360 and PARS were operating system for 360 mainframes that hadE concurrent filesystem disks in the 60s. A facility that ran on top ofdE os/360 in the '60s was ASP (which morphed into JES3 in the early 70s) D which also supported multi-system processing. While HASP didn't have@ similar facilities, it was added to it when it morphed into JES2! ... also in the early to mid-70s.    misc. ASP reference at UCLAo( http://www.garlic.com/~lynn/2000.html#77  C Because of the high transaction processing rate for ACP in multipleu@ system complex, the device level reserve/release for updates wasB proving cumbersome and so fine-grain locking was added to the diskE (3830) controller in the early '70s ...  originally for ACP. The 3830n@ controller was upgraded to the 3880 controller in the late '70s.  E For a specific installation, I help put together possibly the largesteD single system image in the world (at the time) in late '77 and earlyC '78 for the hone system ... eight mainframe multiprocessors complex=< all sharing large, football sized disk (DASD) farm. HONE wasF world-wide "field", "sales" and "customer" support. In the early '80s,C the configuration was replicated in Dallas and Boulder, in part for=+ disaster survivability (earthquake in cal.)a  A Dialog (a couple miles away, at the time still owned by lockheed)oF possibly had a larger disk (DASD) farm, but didn't have as many of the! (same kind) mainframe processors.h  B My wife worked in the JES group in the mid-70s and then was con'ed= into going to POK to be responsible for loosely-coupled (i.e.oC non-shared memory, cluster) multiple system architecture. There she-E was responsible for "peer-coupled shared data" architecture which wasn+ the basis for ims hot- standby and sysplex.y  ? in fact, one of the "problems" of the os/360 genre of operatingbC systems has been the careful propensity of commiting every thing to.F disk, just in case another system might need to read it from disk (and= effectively tendency to not trust any caching) from the '60s.s  D the current incarnation on mainframe is "parallel sysplex" (can show iineage back to the mid-60s)  > http://www-1.ibm.com/servers/eserver/zseries/zos/psysplex.html4 http://www.research.ibm.com/journal/sj/362/nick.html     random refs:. http://www.garlic.com/~lynn/subtopic.html#hone/ http://www.garlic.com/~lynn/subtopic.html#hacmpa   -- iH Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/    ------------------------------  # Date: Wed, 04 Jul 2001 03:56:00 GMTo+ From: Anne & Lynn Wheeler <lynn@garlic.com>e" Subject: Re: The Alpha/IA64 Hybrid) Message-ID: <uu20tqreb.fsf@earthlink.net>l  - Anne & Lynn Wheeler <lynn@garlic.com> writes:.  B > os/360 from the 60s was designed that way ... so was PARS (whichD > morphed into ACP, the airline control program ... which eventuallyD > morphed into the current TPF ... transaction processing facility).   some random tpf flufft6 http://content.techweb.com/wire/story/TWB19980404S0001) http://www.blackbeard.com/tpf/tpfhist.html+ http://www.tpfug.org/Background/history.htm    some past threadsv& http://www.garlic.com/~lynn/96.html#29& http://www.garlic.com/~lynn/96.html#31) http://www.garlic.com/~lynn/2000f.html#20/   -- 0H Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/    ------------------------------  # Date: Wed, 04 Jul 2001 04:10:53 GMTi0 From: "Yousuf Khan" <ykhan@nospam.home.com.spam>" Subject: Re: The Alpha/IA64 Hybrid> Message-ID: <hHw07.407093$eK2.82706357@news4.rdc1.on.home.com>  F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:xCFJA14cPQtJ@eisner.encompasserve.org...o< > There is a Sun fellow here in comp.os.vms who insists that= > Sun has something equivalent if you just add legacy Oracle.l; > Somehow I doubt that all utilities on Solaris access diskh > through legacy Oracle.  L Veritas has come out with new versions of its Volume Manager and File SystemL which it calls Sanpoint Foundation Suite HA. These are versions of VM and FSK that allow for simultaneous shared access of storage resources. This is the(8 basic ingredient in building load-balanced applications.   ------------------------------  # Date: Wed, 04 Jul 2001 04:13:16 GMTd0 From: "Yousuf Khan" <ykhan@nospam.home.com.spam>" Subject: Re: The Alpha/IA64 Hybrid> Message-ID: <wJw07.407098$eK2.82710236@news4.rdc1.on.home.com>  1 "Ric Werme" <werme@mediaone.net> wrote in message.6 news:ZIv07.1672$tH1.1326049@typhoon.ne.mediaone.net...J > >> All in all, most clustering software is basically a glorified version of the > >> old Perl scripts. > >> >#< > > As the OS/390 and VMS folks shudder at the thought . . . >.J > Indeed.  I should give him a peek at the Tru64 source code.  Were single< > system image support as simple as a random Perl script....  A Well, it's been augmented with heartbeating facilities, and such.f       Yousuf Khan    ------------------------------  # Date: Wed, 04 Jul 2001 04:15:10 GMT.+ From: Anne & Lynn Wheeler <lynn@garlic.com>y" Subject: Re: The Alpha/IA64 Hybrid) Message-ID: <uofr1qqic.fsf@earthlink.net>s  - Anne & Lynn Wheeler <lynn@garlic.com> writes:0  G > concurrent filesystem disks in the 60s. A facility that ran on top of>G > os/360 in the '60s was ASP (which morphed into JES3 in the early 70s)eF > which also supported multi-system processing. While HASP didn't haveB > similar facilities, it was added to it when it morphed into JES2# > ... also in the early to mid-70s.   D .... note that while there was multi-system disk support in the baseB os/360 system, it took awhile for various things to evovle to take advantage (mid to late '60s)   from:s5 http://www.share.org/Industry_Influence_Successes.pdfr  . MultiSystem Support in OS/360 and Followons   E SHARE members originally developed both local and remote multisystemeF support for OS/360 MFT/MVT using the HASP spooling subsystem. NIH, theB National Institutes of Health, developed MultiAccess Spool, whichF allowed multiple OS/360HASP systems to share workload via shared DASDC and shared spool. TUCC, the Triangle Universities Computing Center,,D developed a Remote HASPtoHASP facility. Eventually both facilitiesF were incorporated by IBM into JES2, becoming JES2 MAS and NJE (Network Job Entry) (see below).    JES2 and JES3   D When MVS was finally available in the mid1970s it had two Job EntryE Subsystems (spooling systems), JES2 and JES3. The system shipped with C JES2 (HASP Version 5) with JES3 coming somewhat later, and JES2 wasiF seen by IBM as being a deadend, with significant enhancements such asF multiple system support and remote support planned only for JES3. Very? heavy user support for JES2 from SHARE ultimately caused IBM totF continue to support and enhance both JES2 and JES3, and both local andC remote multiple system support in JES2 were adopted from originallyI0 developments of SHARE installations (see above).   -- wH Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/    ------------------------------  # Date: Wed, 04 Jul 2001 02:55:27 GMT / From: StevenU@POBoxes.com (Steven P. Underwood)a& Subject: Re: UPS for AlphaServer 2100A2 Message-ID: <3b42842d.229692281@news.telocity.com>  A APC has an auction site that usually has a variety of refurbishedhE USP's that are fine for hobby use.  There is someone on the list hereeB (or used to be) who has written software to control the APC so you< won't need to spend ~$300 to APC for their crippled version.  E I have the APC version at work and it does shutdown the system, but Io7 have no way of knowing anything else about it's status.    Steve E (who has a Smart-UPS 1250 for his home network which he needed to user= at work this weekend to replace a dying unit while we awaitedg	 delivery)u    > On 3 Jul 2001 08:01:27 -0700, jason_odonnell@erinet.com (Jason O'Donnell) wrote:.   >Hello,o >cF >I recently acquired an AlphaServer 2100A RM for home hobbyist use.  I? >have read the input current specifications and it looks like aiG >standard everyday retail UPS will do the trick.  However, it does lookdF >like I need a 1400 rated UPS.  Is that right or can I get away with a! >smaller one?  Money is an issue.i >mF >Also, a rackmounted one would be better.  Can I get a rackmounted oneF >for about the same price as a pedestal model?  It looks like they are >a little more expensive.m >r >JMODp >nD >PS:  I felt like I was kicked in the stomach when Compaq made their >Itanium announcement.   Steven P. Underwood,DNRC Whitinsville,MAm StevenU@POBoxes.comh   ------------------------------  % Date: Tue, 03 Jul 2001 23:37:52 +0100m+ From: "antonio.carlini" <arcarlini@iee.org>l Subject: Re: VMS V7.3 SPD Errorm' Message-ID: <3B424940.88074A57@iee.org>a   "Zane H. Healy" wrote:K > The MicroVAX III is the KA650, and the MS650 is available in 8Mb and 16MbsJ > sizes.  IIRC, you can have 3 RAM boards, which results in 48MB.  This ofJ > course brings up two questions, one am I remembering correctly about theH > three boards, and two was there a 3rd party option that allowed larger	 > boards?p  8 The KA650 (MicroVAX 3500/3600) can handle 4 16MB boards 3 (assuming you are in a suitable enclosure ... i.e.  - enough slots are available). So that's 64MB. p  - Same goes for the KA655 (MicroVAX 3800/3900).o  0 I don't believe that the memory controller could/ cope with >64MB and since it's on the CPU therep3 is no chance (that I know of) for a 3rd party board0 to do anything about this.  + The MicroVAX 3400 (KA640) can handle (IIRC)p- 3 memory boards and has 4MB on the CPU board,  so that's 52MB max.)  + The MicroVAX II (KA630) was limited to 16MB-, total memory (and would disable its on-board' 1MB if necessary). This too was limiteds  by its memory controller design.   Antonios   --     ---------------2- Antonio Carlini             arcarlini@iee.orgl   ------------------------------   Date: 3 Jul 2001 15:26:43 -0500w9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)sE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)n3 Message-ID: <C4VhzF4YoiAA@eisner.encompasserve.org>y  [ In article <3B41BD8D.20A05680@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:a > Larry Kilgallen wrote: >> ih >> In article <DTiotGxQ0bj6-pn2-11PDYk77IZzV@localhost>, djweath@attglobal.net (Dave Weatherall) writes:4 >> > On Mon, 2 Jul 2001 21:07:28, "Terry C. Shannon"' >> > <terryshannon@mediaone.net> wrote:  >> > >> >> 8 >> >> "Alan Greig" <a.greig@virgin.net> wrote in message* >> >> news:3B40BF27.EEA2F08A@virgin.net... >> >> >- >> >> >A >> >> > Dave Weatherall wrote: >> >> >aP >> >> > > However , there is a statement that it will take 18 months for iVMS toP >> >> > > be up-and-running and the whole thing ready for production in 3 years.J >> >> > > Who assessed the timescale, on what is it based? Who's doing theO >> >> > > planning? What were the criteria and, crucially, what are the caveatst >> >> > > and contingiencies?x >> >> F >> >> Verily, Sun loves it! Verily, HP loves it! Verily, IBM loves it! >> >>uO >> >> Yes, keep on keeping on for Compaq's competitors!  Comp.os.vms is doing aaI >> >> Great Job in this regard. Keep up the fantastic work, you losers!!!. >> >J >> > Terry I take your point. If this doesn't work then yes I, and many ofH >> > the others around here,  _will_ be the losers. The degree may vary. >> l >> Not the losers, the cause ! > J > Please elucidate: what can we grunts do to stop our corporate higher-upsH > from making the final, if bone-headed, choice to take this most recent+ > excuse to dump VMS in favor of BillyWare?I  ? Start planning for success rather than trying to generate every ? possible failure scenario for this newsgroup.  While it is trueR> you cannot take your VMS code to an IA64 porting center today,; there is plenty of time to look at those changes made goingo@ from VAX to Alpha and be sure they were really done in a general fashion.   Be supportive for a change.o   ------------------------------  $ Date: Tue, 3 Jul 2001 16:33:44 -0400' From: "Bill Todd" <billtodd@foo.mv.com>aE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)c( Message-ID: <9hta0c$s6c$1@pyrite.mv.net>  F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:C4VhzF4YoiAA@eisner.encompasserve.org...x   ...P   > Be supportive for a change.   B For a change?  Most of the people (those who haven't left already)F expressing concerns here have been more supportive than Compaq had any& reason to hope for - until a week ago.  K It's long past time for *Compaq* to 'be supportive for a change'.  Instead,n it has  H 1)  taken action *guaranteed* to hurt VMS acceptance (does anyone reallyL thing that the prospect of having VMS on IA64 hardware 2 or 3 years from nowF will have anything like enough attraction - for those for whom it's anL attraction at all - to come anywhere near balancing the negative effect that' dropping Alpha is already having?), and   K 2) done *absolutely nothing* to counter-balance this injury to VMS (e.g., aoC major ad campaign that touted VMS's strengths and promised specificuA significant new development - no, *not* the port:  that's at bests' growth-neutral in the current climate).   H Whenever people suggest that Compaq's future plans for VMS differ in anyE material way from its past ones, I say "Show me the money" (i.e., theoJ willingness to *invest* in VMS in ways that *only* have a long-term returnH to prove the long-term nature of the commitment), and that applies today more than ever.t   - bill   ------------------------------  % Date: Tue, 03 Jul 2001 16:14:20 -0500e1 From: "David J. Dachtera" <djesys.nospam@fsi.net>-E Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)m' Message-ID: <3B4235AC.CA956973@fsi.net>A   Larry Kilgallen wrote: > ] > In article <3B41BD8D.20A05680@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:s > > Larry Kilgallen wrote: > >>j > >> In article <DTiotGxQ0bj6-pn2-11PDYk77IZzV@localhost>, djweath@attglobal.net (Dave Weatherall) writes:6 > >> > On Mon, 2 Jul 2001 21:07:28, "Terry C. Shannon") > >> > <terryshannon@mediaone.net> wrote:d > >> > > >> >>s: > >> >> "Alan Greig" <a.greig@virgin.net> wrote in message, > >> >> news:3B40BF27.EEA2F08A@virgin.net...	 > >> >> >i	 > >> >> >   > >> >> > Dave Weatherall wrote:	 > >> >> >.R > >> >> > > However , there is a statement that it will take 18 months for iVMS toR > >> >> > > be up-and-running and the whole thing ready for production in 3 years.L > >> >> > > Who assessed the timescale, on what is it based? Who's doing theQ > >> >> > > planning? What were the criteria and, crucially, what are the caveats. > >> >> > > and contingiencies?h > >> >> H > >> >> Verily, Sun loves it! Verily, HP loves it! Verily, IBM loves it! > >> >>PQ > >> >> Yes, keep on keeping on for Compaq's competitors!  Comp.os.vms is doing anK > >> >> Great Job in this regard. Keep up the fantastic work, you losers!!!- > >> >L > >> > Terry I take your point. If this doesn't work then yes I, and many ofJ > >> > the others around here,  _will_ be the losers. The degree may vary. > >>  > >> Not the losers, the cause ! > >dL > > Please elucidate: what can we grunts do to stop our corporate higher-upsJ > > from making the final, if bone-headed, choice to take this most recent- > > excuse to dump VMS in favor of BillyWare?e > A > Start planning for success rather than trying to generate everye0 > possible failure scenario for this newsgroup.   G Tony Robbins put it this way: "You can look at the weeds in your gardenIF and say, 'There's NO weeds! There's NO weeds! There's NO weeds!'. Hey!F They'll take your garden!" Sort of like ignoring a serial killer - youD can plan for the day he is off the streets; but until then, you must! expect the killings to continue.    C We can be as positive and supportive as any one can be! In the long G term, however, this will have little or no impact on corporate decisionhF making at Compaq or any other company. That's not negative, just plain fact.o   > [snip] > Be supportive for a change.P  H Tony Robbins put it this way: "Don't expect the worst, expect the best -, but have a plan in case the worst shows up!"  H I *AM* *TOTALLY* supportive of ANY and EVERYthing that furthers OpenVMS.G To date, however, I have seen almost nothing since Galaxy and OVMShobbyf5 that even remotely resembles a furthering of OpenVMS.   : So, exactly *WHAT* am I supposed to be supportive *OF*??!!  E Compaq comes out and makes statements which are generally going to beeE (if they haven't already been) interpreted as "Alpha will not advancetF beyond the existing timeline for EV7. After that, it will fall to IA64% (or IPF, whatever ya wanna call it)".g  A Show me *ONE* ivy-league biz prof. that will support investing insE OpenVMS and Alpha given that the current gear has effectively had itse= EOL established and the follow-on is effectively vapor-ware. l   Just one will suffice.  @ At least when Alpha appeared, DEC should show something concreteH replacing the VAX. Show me an OpenVMS-capable IA64 box (running or not)!   Just one will suffice.  < The Chgo. VMS job market died two years ago, and this latestG announcement has effectively welded the lid onto the coffin. My currentsH course will lead me away from VMS unless something comes along very soon (before 31-Aug-2001).a  F I hope your plans include still being in the OpenVMS biz come the dawnE of OpenVMS-IPF (and I don't mean field test, I mean Gamma Test a.k.a.pD General Release), and I hope it will be lucrative for you and othersB like you. The count of OpenVMS systems in the world will likely beE halved by then, if not reduced to a quarter of what it is now. Again, ) not negative - just highly probable, IMO.   F If I can't find another OVMS job before Sept., my VMS career - nay, my" EDP career - is effectively over.   H ...which quite possibly may be the best that could happen for me. Again,/ not negative - just a simple statement of fact.i   --   David J. Dachterai dba DJE Systemsa http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/o  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.t   ------------------------------  % Date: Tue, 03 Jul 2001 16:17:51 -0500.1 From: "David J. Dachtera" <djesys.nospam@fsi.net>cE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)e' Message-ID: <3B42367F.8E2FA2DF@fsi.net>m   Bill Todd wrote: > [snip]   Excellent post, Bill!!  @ (...he said, then quickly ducked, taking cover behind a stack of discarded Alpha 8400's.)   -- 0 David J. Dachtera& dba DJE Systemsn http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/l  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.t   ------------------------------  $ Date: Wed, 4 Jul 2001 09:57:20 +1000- From: "Paul Nankervis" <paulnank@au1.ibm.com>gE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)l/ Message-ID: <9htm5e$921i$1@poknews.pok.ibm.com>m  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9hta0c$s6c$1@pyrite.mv.net... >.J > 1)  taken action *guaranteed* to hurt VMS acceptance (does anyone reallyJ > thing that the prospect of having VMS on IA64 hardware 2 or 3 years from nowaH > will have anything like enough attraction - for those for whom it's anI > attraction at all - to come anywhere near balancing the negative effectr that) > dropping Alpha is already having?), andn >e  I This guarantee is in your mind only!  A number of people I have talked to  actuallyH believe that porting VMS to Itanium is a GOOD thing!  Without it VMS was tiedJ to the Alpha millstone and was eventually doomed to disappear as Alpha wasL rolled by architectures with a much higher revenue base. Unfortunately it is a fact of life that the $ rules.H  K No-one could have predicted this when the Alpha was created. It is a superbfD architecture that should really have gone places. Unfortunately, for whateverH reason, it now has a very small support base and a correspondingly small researchE and design effort. For the first few years of its life it held a hugep competitivedL performance edge, but over the last few years it has been flagging a little. PartC of the problem is that no-one envisiaged that the really crappy x86o architectureI could be made to sing by pouring huge amounts of money into it.  In a fewv years J it is possible that ONLY Intel architectures will survive from the current crop!t  K As to whether the port of VMS is a good thing or not it probably depends on I whether you are an optimist or a pessimist. As I have said I believe thatt	 this portlI is the only possible way that VMS can survive (certainly true now!). To afK pessimist this is just one more sign that the sky is falling. UnfortunatelyM if this G pessimistic view prevails then it becomes a self-fulfilling prophecy. Id *LIKE*L VMS so I feel that I have to take the optimistic approach to least give it aF chance.  With so many negative thoughts in this newgroup it looks likeC comp.os.vms may be the death of VMS - something Compaq has not beennL able to achieve! :-)   I suspect that if everyone were to put as much effortJ into porting applications to VMS instead of complaining about past events,0 then we would have a very different picture now!  G Maybe we should create another newsgroup to discuss Compaq/VMS bashing?e   Paul Nankervis   ------------------------------  $ Date: Tue, 3 Jul 2001 20:21:14 -0400' From: "Bill Todd" <billtodd@foo.mv.com>cE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)H( Message-ID: <9htnav$ao2$1@pyrite.mv.net>  8 "Paul Nankervis" <paulnank@au1.ibm.com> wrote in message) news:9htm5e$921i$1@poknews.pok.ibm.com...i >l4 > "Bill Todd" <billtodd@foo.mv.com> wrote in message$ > news:9hta0c$s6c$1@pyrite.mv.net... > >tL > > 1)  taken action *guaranteed* to hurt VMS acceptance (does anyone reallyL > > thing that the prospect of having VMS on IA64 hardware 2 or 3 years from > nowaJ > > will have anything like enough attraction - for those for whom it's anK > > attraction at all - to come anywhere near balancing the negative effectl > that+ > > dropping Alpha is already having?), ands > >o >g& > This guarantee is in your mind only!  I No, it is already happening:  multiple reports of lost VMS or Alpha salesaI due to the announcement.  How many so far no one knows (not even Compaq), & but the number is non-zero and rising.  K AFAIK, there are *zero* new sales attributable to the announcement.  Do youl know of any?  %   A number of people I have talked toJ
 > actually6 > believe that porting VMS to Itanium is a GOOD thing!  F A lot of people in Germany believed that (I can't say the name, or theL thread will end) was a good thing.  Even helped the economy for a while (war' preparations have a way of doing that).-     Without it VMS was > tied > to the Alpha millstone  L Watch your language, sonny.  Alpha wasn't the millstone, Compaq's managementJ of it was (and still is), and DEC's management before that.  Fix that, and8 you fix a great many problems, not just the present one.   - bill   ------------------------------  # Date: Wed, 04 Jul 2001 02:20:35 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>E Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)r< Message-ID: <T3v07.1456$tH1.1287256@typhoon.ne.mediaone.net>  8 "Paul Nankervis" <paulnank@au1.ibm.com> wrote in message) news:9htm5e$921i$1@poknews.pok.ibm.com...o >w4 > "Bill Todd" <billtodd@foo.mv.com> wrote in message$ > news:9hta0c$s6c$1@pyrite.mv.net... > >uL > > 1)  taken action *guaranteed* to hurt VMS acceptance (does anyone reallyL > > thing that the prospect of having VMS on IA64 hardware 2 or 3 years from > nowbJ > > will have anything like enough attraction - for those for whom it's anK > > attraction at all - to come anywhere near balancing the negative effect  > that+ > > dropping Alpha is already having?), andI > >a > K > This guarantee is in your mind only!  A number of people I have talked tod
 > actually6 > believe that porting VMS to Itanium is a GOOD thing!  , This actually includes some VMS ambassadors.   > Without it VMS was > tiedL > to the Alpha millstone and was eventually doomed to disappear as Alpha wasK > rolled by architectures with a much higher revenue base. Unfortunately itn is > a fact > of life that the $ rules.- >-  K Yep. And if CPQ can pull off the OS port (while retaining its customer baseiD and ISV apps portfolio), I think VMS will be a far stronger product.F Technically the port seems doable. Methinks the customer base and apps3 portfolio remain the gating factors in this scheme.e   ------------------------------   Date: 3 Jul 2001 15:35:08 -0500 9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)e@ Subject: Wailing and moaning.... (was: Compilers go to Intel...)3 Message-ID: <3muriWXVncvJ@eisner.encompasserve.org>o  l In article <1Wi07.34540$P5.9687529@news1.rdc1.tn.home.com>, "Alphaman" <alphaman64@nixspam-home.com> writes:F > Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote in message/ > news:t$OY720dA3f9@eisner.encompasserve.org...oM >> In article <9hlbj6$keb@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edut > (David Mathog) writes:J >> > It would be nice if once Q managements' eyes stop spinning they couldL >> > clarify the repercussions on the hobbyist and education programs of the/ >> > sale of their compiler divisions to Intel.  >>E >> Where does it say that "compiler divisions" will be sold to Intel.aC >> Everything I have read indicates Intel will be getting GEM, with-) >> Compaq still making the VMS compilers.  > E > Yuh, GEM is a jewel.  I can understand how some folks would get the:F > impression that "Alpha technology and engineering" would include GEME > software plus compiler people.  Perhaps this needs to be clarified.n > K > I can see where Intel would need the GEM backend, and the Q (and other OSAK > mfg's) would need specific frontends.  However, the question then becomes H > does Q pay Inhel royalties for the backend?  If so, does that kill anyE > ability to include the compilers in the free kits (hobbyist, etc.)?J  C Doesn't anybody _read_ what has been posted here?  Michael CapellaswE is quoted as saying the transfer to Intel was _non_exclusive_rights_,mB meaning there can be no royalty requirement.  Otherwise they would@ have to make their case with the antitrust folks, something they are strongly inclined to avoid.   G > And those, kiddies, are only questions we can speculate on right now, M > because NOBODY has the answer to things not yet built.  But keep asking the K > hard questions so that the Q can generate the right answers as they build  > the products.r  F Doesn't anybody _read_ what has been posted here ?   A VMS development? manager has been quoted here as saying this will not affect the> hobbyist program.i  0 > Back from a mind-numbing reprieve from c.o.v., > Aaron>  = I would strongly suggest, then, that you _read_ what has beens; posted here in the interim, before writing about it.  It isk< bad enough to have those the doomsayers who say "even though9 Compaq said it, I do not believe it", without having suchr8 strong comments from someone who has not even heard what Compaq said.   ------------------------------  $ Date: Tue, 3 Jul 2001 15:59:03 -0400' From: "Bill Todd" <billtodd@foo.mv.com>V, Subject: Re: What about performance issues??( Message-ID: <9ht7va$qi9$1@pyrite.mv.net>  5 "Keith Parris" <kparris@my-deja.com> wrote in messagei7 news:cb85fed2.0107030817.7abe3d38@posting.google.com...p> > bill@triangle.cs.uofs.edu (Bill Gunshannon) wrote in message' news:<9ha6c2$qeo$4@info.cs.uofs.edu>... C > > It has been said here that VMS performance, particularly I/O is D > > considerably slower than under other OSes.  Is this true, or wasF > > it just the unjustified rantings of people not in a place to know? >WE > Most of these posts seem to involve C programs and comparisons with9G > Unix systems.  I believe they are honest, sincere, and not ranting orr5 > ignorant.  They simply reported what they observed.c >a( > My experience has been very different. > E > I've seen that with VMS you can set up an 18-node cluster of GS-140 F > class systems, and set up a RAID 0+1 array with 56 solid-state disksF > spread across dozens of disk controllers, and get I/O performance soC > good that I had to patch MONITOR CLUSTER so that it could display)G > 5-digit values of I/Os per second so I could observe the actual peaksh > in I/O rates.p > F > And this level of I/O performance was being achieved with the older,D > slower HSJ50 and CI hardware, not the hot new Fibre Channel stuff;F > with no XFC; with plain old RMS indexed files, without using the newC > Fast_IO interface that is significantly streamlined compared withn > $QIO.c  I But, I suspect, by taking advantage of mirrored, stable, controller-level J write-back caching.  Suitable hardware can always make up for a great dealG in the way of software inadequacy - but most of the discussion involvedlL write performance on lesser hardware where enabling write-back caching wouldG potentially compromise integrity.  (Yes, to some extent read-caching ase@ well, and XFS has helped in that area, but it did take a while.)   - bill   >t > Keithe   ------------------------------  % Date: Tue, 03 Jul 2001 15:58:02 -0500-/ From: Chris Scheers <chris@applied-synergy.com>18 Subject: Re: Yet Another Reason Why Windoze .ne. OpenVMS3 Message-ID: <3B4231DA.C24A7150@applied-synergy.com>u   norm lastovica wrote:m >  > Robert Deininger wrote:3 > >nD > > In article <3B40DFE0.C183EC48@iee.org>, arcarlini@iee.org wrote: > >> > > >d3 > > > Now the VAX 8500 *was* deliberately crippled.a6 > > > The original microcode had NOPs to slow it down.6 > > > Very shortly afterwards came the VAX 8530 - same8 > > > machine, but without the NOPs. (Not to be confused2 > > > with the VAX 8350!). It was common knowledge5 > > > outside of DEC exactly what had happened (I was.0 > > > a customer in a little backwater ... if we > > > knew, everyone knew!). > >>Q > > Let me guess.  DEC would gladly sell you an upgrade from 8500 to 8530, right?e > 8 >         as I recall, the 8500->8530 upgrade was "free"6 > in that all the 8500s got the "eco".  rumor was that7 > there were some bugs fixed in the micro code and thatt; > at some point it was found that the NOPs weren't required  > for the timing on the boards.a > --@ > norman lastovica / oracle rdb engineering / usa / 610.696.4685  E IIRC, the 8500 (3 VUPs) had been out a while.  Then the 8530 (4 VUPs)MH was announced.  An "upgrade" from the 8500 to the 8530 was available for about $100K.  G Someone did some comparisons and found that the only difference betweenoD the two machines (other than the medallion) was the firmware floppy.  G The resulting PR backlash resulted in DEC offering the microcode updateb9 to existing 8500 owners, converting all 8500s into 8530s.r  G -----------------------------------------------------------------------u$ Chris Scheers, Applied Synergy, Inc.  C Voice: 817-237-3360            Internet: chris@applied-synergy.com e   Fax: 817-237-3074    ------------------------------   Date: 3 Jul 2001 22:52:43 GMT ' From: robinm@rpi.edu (Michael Robinson)e8 Subject: Re: Yet Another Reason Why Windoze .ne. OpenVMS, Message-ID: <9htibr$mn8$1@newsfeeds.rpi.edu>  0 Chris Scheers (chris@applied-synergy.com) wrote:I : Someone did some comparisons and found that the only difference betweenaF : the two machines (other than the medallion) was the firmware floppy.  D On that note... Does anyone have such a floppy?  I've got an 8530 in need of a backup set.    Michael Robinson robinm (at) rpi (dot) edui RPI Electronics Club Vaxherd   ------------------------------   End of INFO-VAX 2001.367 ************************