1 INFO-VAX	Sat, 15 Dec 2001	Volume 2001 : Issue 695       Contents:8 Re: ALPHA strategy (was: RE: Inquirer: OpenVMS on DS20L)8 Re: ALPHA strategy (was: RE: Inquirer: OpenVMS on DS20L)8 RE: ALPHA strategy (was: RE: Inquirer: OpenVMS on DS20L)# Command-line driven graphs from ECP   Re: Compaq now a takeover target  Re: Compaq now a takeover target  Re: Crash (SYSDUMP.DMP) question  Re: Crash (SYSDUMP.DMP) question" Re: DEC Alpha 255 - 300 Mhz wantedE Re: From within a CGI: sending an https method=post request elsewhere E Re: From within a CGI: sending an https method=post request elsewhere E Re: From within a CGI: sending an https method=post request elsewhere  Re: global foreign command Re: global foreing command Re: Got The Gold?????? Re: Got The Gold?????? RE: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L RE: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L Re: Inquirer: OpenVMS on DS20L# Re: More about Alpha and the merger # Re: More about Alpha and the merger 2 Re: Move to an HP OS, most folks would rather not.2 Re: Move to an HP OS, most folks would rather not.. Re: nova (was: RE: Inquirer: OpenVMS on DS20L) Re: Old VAX Documentation  post etiquetteE Re: Press Release SyntheSys Secure Technologies - JabCast  on OpenVMS % Re: Reloading device drivers on Alpha % Re: Reloading device drivers on Alpha % Re: Reloading device drivers on Alpha % Re: Reloading device drivers on Alpha # Re: remote connection and pathworks P Re: SPAM Reporting - was Re: Chase Visa Card, Verisign Thawte Certificate, Rapid sys$getdvi and socket  Re: sys$getdvi and socket  Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq Re: The demise of compaq0 Re: Unix for HELP ... Examples? ANS: No standard Re: vms 3.x question Re: vms 3.x question Re: vms 3.x question  F ----------------------------------------------------------------------  % Date: Fri, 14 Dec 2001 05:22:13 -0500 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> A Subject: Re: ALPHA strategy (was: RE: Inquirer: OpenVMS on DS20L) 2 Message-ID: <RWuS7.617$BK1.16083@news.cpqcorp.net>  F "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message5 news:01KBVBG11KKO9138XQ@sysdev.deutsche-boerse.com... G > > Well.  I suppose it is because it is the Alpha Server business that  makes  > > the money. > F > I know the comparison is not spot-on, but isn't that like saying "weG > stopped fitting our cars with tyres since engines were making most of I > the profit" or, a bit closer to home, "we stopped fitting our computers > > with hard disks since memory was making most of the profit"?  L I think a better example would be where someone stopped making compact cars,C because SUVs are what people were buying, and where the profit was.   K An NT workstation is a much more cost-effective desktop solution.  It's the 	 *volume*.    > J > As I see it, the move to Itanium will allow the full range, from low-endG > desk-top workstations to high-end high-performance servers.  It seems E > strange to me that this strategy will be possible with Itanium, but F > wasn't possible with ALPHA.  Unless, of course, the hope is that theD > high volume of NON-VMS low-end machines will make it worthwhile to& > support VMS on the low-end machines. >   9 Volume and profit.  We know we need a smallish system for H workstations/development.  The hard part is building one that will stillG make a good profit on a small volume.  When most of the world is buying 0 pentiums for the desktop, with margins so low...  H Let us imagine for a second that Itanium does "succeed" and Intel startsK selling them in the million unit range, which also means that all the other A giblets that go into it are in the millions.  The volume, and the H competition from multiple vendors will result in prices lower than Alpha  could get with its small volume.   ------------------------------  % Date: Sat, 15 Dec 2001 01:21:56 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> A Subject: Re: ALPHA strategy (was: RE: Inquirer: OpenVMS on DS20L) , Message-ID: <3C1AEBFF.FFD40CAE@videotron.ca>   Fred Kleinsorge wrote:M > An NT workstation is a much more cost-effective desktop solution.  It's the  > *volume*.   M 1- from the software point of view, it doesn't really matter.  You could sell I VMS licenses for the same price as NT and come out a winner since that is $ extra revenu with little cost to it.  L 2-from a strategic point of view, if you tell a user to get NT workstations,K guess what OS he will be developping on and for : NOT VMS.  If you make VMS L workstations affordable, then you'll have plenty more VMS software availableK and you can then grow the VMS marketplace instead of restricting it to ever  smaller niches.   N 3- From a hardware point of view, I think that Compaq should have been able toN produce Alpha for the same price and upscale wintel workstations. Only the CPUM need be different with the rest probably common. And Compaq could have offset I the higher costs of the chip and lower volume by making such workstations N available only through internet sales and the workstations built to order. (no, inventory costs, no distribution costs etc).   ------------------------------  % Date: Sat, 15 Dec 2001 01:35:07 -0500 + From: "Main, Kerry" <Kerry.Main@compaq.com> A Subject: RE: ALPHA strategy (was: RE: Inquirer: OpenVMS on DS20L) T Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4010D721C@kaoexc01.americas.cpqcorp.net>   JF,   , re: what type of development workstations ..  E Fwiw, the Government of Canada earlier this year had a large UNIX RFP D (open to public) to replace a large number of Sun servers with a newD middleware platform. The entire RFP was based on the J2EE middlewareA architecture so that it did not matter what platform the code was @ developed on - the deployment platform can be totally different.  > They mandated that NT workstations were to be proposed for theD development environment, but made it very clear (mandatory) that the) deployment platform was going to be UNIX.   G The choice of development platforms in a J2EE environment is based more G on more on cheap $'s AND the SW development tools availability to build D the app's. That is an entirely different decision than what platform< they plan to use to run their important production stuff on.  > You can build J2EE app's on NT and assuming the proper QA/TestH environment is in place, deploy them on UNIX, OpenVMS or yes, even NT if you were so inclined.    Regards,  
 Kerry Main Senior Consultant  Compaq Canada Corp.  Professional Services  Voice: 613-592-4660  Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----4 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca] Sent: December 15, 2001 1:22 AM  To: Info-VAX@Mvb.Saic.Com A Subject: Re: ALPHA strategy (was: RE: Inquirer: OpenVMS on DS20L)      Fred Kleinsorge wrote:C > An NT workstation is a much more cost-effective desktop solution.  It's the > *volume*.   H 1- from the software point of view, it doesn't really matter.  You could sellF VMS licenses for the same price as NT and come out a winner since that is$ extra revenu with little cost to it.  > 2-from a strategic point of view, if you tell a user to get NT
 workstations, G guess what OS he will be developping on and for : NOT VMS.  If you make  VMS B workstations affordable, then you'll have plenty more VMS software	 available F and you can then grow the VMS marketplace instead of restricting it to ever smaller niches.   F 3- From a hardware point of view, I think that Compaq should have been able to F produce Alpha for the same price and upscale wintel workstations. Only the CPU F need be different with the rest probably common. And Compaq could have offset< the higher costs of the chip and lower volume by making such workstationsC available only through internet sales and the workstations built to 
 order. (no, inventory costs, no distribution costs etc).   ------------------------------  # Date: Sat, 15 Dec 2001 04:14:43 GMT $ From: "Ed Wilts" <ewilts@ewilts.org>, Subject: Command-line driven graphs from ECP: Message-ID: <T6AS7.4663$yC.190602@typhoon.mn.mediaone.net>  @ Has anyone written any tools to process the ECP data?  Since theH collector is now free, it would be nice to get some simple graphs out ofI it in batch.  Right now, I have to fire up the X interface and select the E data file and request a graph, at which point I can save the graph as F Postscript.  Alternatively, I can export a raw text file from the dataF and then fire that into Excel, but I'm still looking for a better way.I With PSPA (now gone from our cluster since we've upgraded to 7.3), we had . a nice way to generate weekly summary stats...   Any ideas greatly appreciated.   Thanks,  	.../Ed  --   Ed Wilts, Mounds View, MN, USA mailto:ewilts@ewilts.org   ------------------------------  # Date: Sat, 15 Dec 2001 04:10:08 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>) Subject: Re: Compaq now a takeover target = Message-ID: <A2AS7.12834$Sj1.7514664@typhoon.ne.mediaone.net>   1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message ( news:u19em742ehd1b@corp.supernews.com...K > It is far more likely that Blackmore will take over if a senior executive  is > given the post.  > K > If the merger fails Capellas walk away with a $675 million dollar parting B > gift which will given some time to find the "better answers" and. > "inspiration technology" to "invent" plan B. > J > The most serious wreckage the Capellas will need to most recover from is the L > criminal damage that has been done to Tru64's reputation at least with the" > non-Compaq Unix ISV community... >   I Yup. Merger or no merger, Tru64 as we know it is not long for this world. C Absent the merger, Compaq most likely will OEM HP-UX, equip it with K TruCluster bells and whistles, and end up with a lesser Unix with a greater G apps portfolio. Which might be OK... Sun has succeeded with Solaris not K because of the technical excellence of the product, but because of the apps  portfolio the OS has attracted.    ------------------------------  % Date: Sat, 15 Dec 2001 01:41:20 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> ) Subject: Re: Compaq now a takeover target , Message-ID: <3C1AF08B.91CF4635@videotron.ca>   "Terry C. Shannon" wrote: K > Yup. Merger or no merger, Tru64 as we know it is not long for this world. E > Absent the merger, Compaq most likely will OEM HP-UX, equip it with M > TruCluster bells and whistles, and end up with a lesser Unix with a greater I > apps portfolio. Which might be OK... Sun has succeeded with Solaris not M > because of the technical excellence of the product, but because of the apps ! > portfolio the OS has attracted.   I Do you seriously believe that Compaq could succesfully compete against HP # selling HP's OS on Compaq harware ?   J Sun and IBM will get Compaq's Tru64 business. Compaq will be left with itsM desired focused in wintel with the Tandem and VMS stray product not yet dealt  with.    ------------------------------  # Date: Fri, 14 Dec 2001 19:12:07 GMT 1 From: "Mark D. Jilson" <jilly@clarityconnect.com> ) Subject: Re: Crash (SYSDUMP.DMP) question 2 Message-ID: <3C1A4F19.19DE07AC@clarityconnect.com>  # Well actually it is available!  See U http://www.compaq.com/support/asktima/operating_systems/00968F6D-A41BF020-1C0186.html  (beware of any line wrapping)    and   U http://www.compaq.com/support/asktima/operating_systems/0092F703-DD75C040-1C009F.html  (beware of any line wrapping)   H See http://www.compaq.com/support/ask/index.html , click on AlphaServers and then ask your question.      Lorin Ricker wrote:  >  > Mark D. Jilson wrote: M > > If you have access to DSNLink there are 2 articles to help you with this.  > C > > [OpenVMS] Managing Dumpfiles on VAX & Alpha Systems or Clusters D > > [OpenVMS] How To Check That the Dumpfile Was Mapped at Boot Time > L > No, I don't have access to DSNLink, but these two articles sound just like > what I need.  ;-( + > Any other way I can access them?  Thanks!  >  > -- > Lorin Ricker >   Lorin@LockTrack.com    --  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: Fri, 14 Dec 2001 12:52:32 -0700 * From: "Lorin Ricker" <Lorin@LockTrack.com>) Subject: Re: Crash (SYSDUMP.DMP) question C Message-ID: <_HsS7.106102$lV4.16254027@e420r-atl1.usenetserver.com>     > Well actually it is available!  J Yes, and thanks, Mark!  I'd just forgotten that DNSLink = "Ask Compaq" web pages.K All better now.  The first article suggested to me that a quick way to just  *confirm* whatI I suspected is true about my problem system's dump configuration is to do  this:   3 $ SHOW DEV /FILE /SYSTEM /OUT=foo.lis SYS$SYSDEVICE  $ SEARCH foo.lis sysdump.dmp  F which yields a line which confirms my dumpfile's ultimate destination:  4                 00000000  [SYS0.SYSEXE]SYSDUMP.DMP;1  2 Ta-da.  Thanks again for responding with pointers. -- Lorin Ricker   Lorin@LockTrack.com    ------------------------------  % Date: Fri, 14 Dec 2001 21:08:24 -0500   From: John Santos <JOHN@egh.com>+ Subject: Re: DEC Alpha 255 - 300 Mhz wanted 4 Message-ID: <1011214210333.418A-100000@Ives.egh.com>  & On 14 Dec 2001, Jan Vorbrueggen wrote:  < > John Macallister <J.Macallister1@physics.ox.ac.uk> writes: >  > > Running VMS x.y .  > > Using package P . O > > P (hardware or software) causes VMS system crashes or "hangs". P is a third  > > party product.& > > DEQ claim the problem lies with P. > L > As long as P does not contain non-user-mode code, DEQ has no reason at all# > to put the blame on anybody else.  >  > 	Jan  E Not for crashes.  "Hangs" could be due to mistuning.  Mistuning could > be due to P's supplier not understanding its' own application.  D Also, John mentioned the P only works with old VMS x.y, but not withF x+n.y+n.  If P is user-mode-only, then this should never (well, hardlyB ever) happen.  (Vendor P might not be interested in supporting it,* but that's vendor P's problem, not DEQ's.)   --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Fri, 14 Dec 2001 20:46:37 +0100 , From: Didier Morandi <Didier.Morandi@gmx.ch>N Subject: Re: From within a CGI: sending an https method=post request elsewhere& Message-ID: <3C1A571D.90F36F1F@gmx.ch>  * "j.lance wilkinson, (814) 865-1818" wrote:  I >         I don't see how the server that I run is relevant to the issue. H >         I'm running CSWS, but the problem is how to establish an HTTPSK >         connection *from within the DCL CGI script to ANOTHER web server*  > H >         The server running MY script should be irrelevant.  The serverK >         running the target script on the other machine, the one expecting J >         HTTPS as the protocol to receive the POST method script data, isK >         running on some AIX platform.  WASD isn't relevant there, either.   M Correct me if I'm wrong. Either I did not really understand CGI scipting (but O I'm doing DCL scipring programming for a WASD server since five months...) or I ! did not understand your question.   J A CGI script is executed by the TARGET server, you are the CLIENT. Its theN browser page on your CLIENT machine which triggers the SERVER CGI script. WhenP you do a post, there is no server running on the CLIENT system as far as I know.  P Explain to me how you could have a server executing a script which does HTTPS toZ another server. You are sure that you do not rather want to do task to task communication?   D.   ------------------------------  # Date: Fri, 14 Dec 2001 21:40:38 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")N Subject: Re: From within a CGI: sending an https method=post request elsewhere8 Message-ID: <00A0682D.61107B0F@SSRL04.SLAC.STANFORD.EDU>  U In article <3C1A571D.90F36F1F@gmx.ch>, Didier Morandi <Didier.Morandi@gmx.ch> writes:o+ >"j.lance wilkinson, (814) 865-1818" wrote:L > J >>         I don't see how the server that I run is relevant to the issue.I >>         I'm running CSWS, but the problem is how to establish an HTTPSSL >>         connection *from within the DCL CGI script to ANOTHER web server* >>  I >>         The server running MY script should be irrelevant.  The serversL >>         running the target script on the other machine, the one expectingK >>         HTTPS as the protocol to receive the POST method script data, is:L >>         running on some AIX platform.  WASD isn't relevant there, either. >aN >Correct me if I'm wrong. Either I did not really understand CGI scipting (butP >I'm doing DCL scipring programming for a WASD server since five months...) or I" >did not understand your question. >DK >A CGI script is executed by the TARGET server, you are the CLIENT. Its theuO >browser page on your CLIENT machine which triggers the SERVER CGI script. WhenDQ >you do a post, there is no server running on the CLIENT system as far as I know.t >pQ >Explain to me how you could have a server executing a script which does HTTPS tot[ >another server. You are sure that you do not rather want to do task to task communication?R  + I think you didn't understand the question.u  L Lance might prefer to do task-to-task communication, but the only option theM other server (in another organization, over which he has no control, running eH AIX) offers is an HTTPS connection to a password-change page that runs a script.i  L It's not at all unknown to have scripts that are able to talk to other HTTP I servers, more-or-less pretending to be browsers, and pulling information eH from then.  Arne Vaxjhj (or however that's rendered) has a postaction.c G script that can give the effect of a user having clicked on the submit iG button of a form whose action is POST; there's a flock of tools in Perlx libwww to make this easy.:  L Here's a hacked-up version of one of Lincoln Stein's examples, which fetchesK an NOAA web page with the weather at Palo Alto airport and prints it out onaM the terminal, although you can do othr things with it, like embed the resultszJ in a different web page you're generating as part of a CGI script (a good M example of server->server communications where one server is running a scriptE' that acts as client to another server).n  I -------------------------------------------------------------------------I   # File: get_weatheri   use LWP::Simple;  	 # optionsa $STATE = shift || 'BOS';; $URL = 'http://weather.noaa.gov/weather/current/KPAO.html';l
 $OPTIONS =E 'city=on&area=Local+Forecast&match=Strong+Match&html=text+only+formatt '; $DESTINATION = 'TT:';i   # Fetch the raw text $text=get("$URL?$OPTIONS");    print $text;   # Strip out the HTML tags. $text=~s/<[^>]+>//g;  4 # Parse out the first paragraph containing the daily
 # forecast2 ($tonight) = $text=~/-------\n\n+([\s\S]+?)\n\n/m;4 $tonight=~tr/\n/ /;             # get rid of newline print $tonight;tI -------------------------------------------------------------------------   H So Lance's question is, all this stuff works over http, and you can alsoJ script lynx to do stuff over http.  Do any of these tools work over https, and if so, which ones?   -- Alani    O ===============================================================================i0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056.M  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210aO ===============================================================================o   ------------------------------   Date: 14 Dec 2001 19:50 CSTs' From: carl@gerg.tamu.edu (Carl Perkins) N Subject: Re: From within a CGI: sending an https method=post request elsewhere- Message-ID: <14DEC200119501775@gerg.tamu.edu>l  0 Didier Morandi <Didier.Morandi@gmx.ch> writes...+ }"j.lance wilkinson, (814) 865-1818" wrote:  } J }>         I don't see how the server that I run is relevant to the issue.I }>         I'm running CSWS, but the problem is how to establish an HTTPS L }>         connection *from within the DCL CGI script to ANOTHER web server* }> uI }>         The server running MY script should be irrelevant.  The serverrL }>         running the target script on the other machine, the one expectingK }>         HTTPS as the protocol to receive the POST method script data, istL }>         running on some AIX platform.  WASD isn't relevant there, either. } N }Correct me if I'm wrong. Either I did not really understand CGI scipting (butP }I'm doing DCL scipring programming for a WASD server since five months...) or I" }did not understand your question. } K }A CGI script is executed by the TARGET server, you are the CLIENT. Its theyO }browser page on your CLIENT machine which triggers the SERVER CGI script. WhenfQ }you do a post, there is no server running on the CLIENT system as far as I know.h } Q }Explain to me how you could have a server executing a script which does HTTPS tow[ }another server. You are sure that you do not rather want to do task to task communication?  }  }D.e   It's easy, at least in concept.h  L 1) You want to display some information on a web page served by your system.M 2) Some, or all, of that information has to be retrieved from another system.iJ 3) One (or possibly the only, in some instances like perhaps this one) wayL to get the information is from a web page served from that system via HTTPS.  @ The web page in point 1 is generated by a script on your system.E The web page in point 3 is generated by a script on the other system.   G To do this, you need your script to be able to retrieve data via HTTPS.t  E (This may not be the best method possible, but it is not difficult ineD concept. If the other system is not under your control, you may have to use what you can get.)t  G The version of Lynx that I have (2.7.1) doesn't have support for HTTPS.eH This may not be the newest version (it is from 1997) and a newer versionJ might do so, which would allow it to grab the page and save a copy locally, that you could extract the information from.  E OK, I just checked. The current verion of Lynx has an HTTPS extensione7 available. A comment about it from the Lynx links page:m           [...]cG           The generic Lynx distribution does not contain SSL capabilityT@           due to the US restrictions on the free distribution ofD           cryptographic software. Patches are available for Lynx 2.8G           which will provide for SSL functionality. More information is,G           available from ftp://www.slcc.edu/pub/lynx/release/ssl.html a G           copy of the document is here. ftp://shadow.cabi.net/pub/Linuxs9           also contains a Lynx 2.7 with SSL distribution.6  H           It is also trivial to add SSL capability to Lynx using a httpsH           proxy (defined in lynx.cfg). The proxy code is available from:D           ftp://ftp.replay.com/pub/replay/pub/crypto/SSLapps/SSLlynx           [...]n  K So it is available, potentially, but not included in the main distribution.f   http://lynx.browser.org/   --- Carl   ------------------------------  % Date: Fri, 14 Dec 2001 21:34:29 -0500   From: John Santos <JOHN@egh.com># Subject: Re: global foreign commandw4 Message-ID: <1011214213316.418B-100000@Ives.egh.com>  * On Fri, 14 Dec 2001, Phillip Helbig wrote:  0 > > nitpick   command :== "$full:[spec]file.exe" > K > Nitpick:  one needs EITHER the : OR the ".  Both don't hurt, but are not sG > necessary.  (Leaving out the quotes will automatically uppercase it, oG > which is probably better since otherwise it will get uppercased when m > parsed anyway.)-  @ nitnitpick: I think the dollar sign was missing in the original. That's necessary either way ;-)    -- i John Santose Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Fri, 14 Dec 2001 06:16:00 +0100r2 From: martin@radiogaga.harz.de (Martin Vorlaender)# Subject: Re: global foreing commandi; Message-ID: <3c198b10.524144494f47414741@radiogaga.harz.de>e  / Phillip (nntpmouse@prism.datastacks.com) wrote:-C > I have figured out how to set up foreing commands with the cmd := K > full:[spec]file.exe at the DCL command line, but I have yet to figure out K > how to figure out how to add it globaly for all users. I saw something totG > the effect of using a `CLD' file, but am at a lose on how to do that.i > Help from anyone?t   1. Use :== instead of :=. 2. Add a $ in front of the full:[spec]file.exe2 3. Add that declaration to SYS$MANAGER:SYLOGIN.COM   cu,a   Martin --  G So long, and thanks        | Martin Vorlaender  |  VMS & WNT programmerx4 for all the books...       | work: mv@pdv-systeme.deG In Memoriam Douglas Adams  |   http://www.pdv-systeme.de/users/martinv/t;             1952-2001      | home: martin@radiogaga.harz.dea   ------------------------------   Date: 14 Dec 2001 21:25:36 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)A Subject: Re: Got The Gold??????-* Message-ID: <9vdqog$if$1@info.cs.uofs.edu>  " In article <4992043@MVB.SAIC.COM>,  "Visa Gold" <> writes:mD |> This is an HTML email message.  If you see this, your mail clientH |>                                       does not support HTML messages. |> I  5 Your right, and I'm rather proud of that fact!!   :-)w   bill   -- iJ 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>   a   ------------------------------    Date: 14 Dec 2001 16:44:35 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)c Subject: Re: Got The Gold??????m3 Message-ID: <a6cBcFkE8g3b@eisner.encompasserve.org>   ^ In article <9vdqog$if$1@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:$ > In article <4992043@MVB.SAIC.COM>, >  "Visa Gold" <> writes:lF > |> This is an HTML email message.  If you see this, your mail clientJ > |>                                       does not support HTML messages. > |> s > 7 > Your right, and I'm rather proud of that fact!!   :-)e  C Actually, if you see this, you will recognize this message as spam.a  $ And I'm rather proud of _that_ fact.   ------------------------------    Date: 14 Dec 2001 13:03:16 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) ' Subject: RE: Inquirer: OpenVMS on DS20L13 Message-ID: <jenp6xOxidBP@eisner.encompasserve.org>   _ In article <CIEJLCMNHNNDLLOOGNJIAEOIDLAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes:m  M > So if you are going to continuing producing desktops based on EV68, why notaL > EV7, it is only a chip and the incremental cost to produce a new board for. > it (if it is even required) is small indeed.  K If it provides no advantage over the EV68 in that environment, why bother ?o   ------------------------------  % Date: Fri, 14 Dec 2001 16:26:21 -0500d) From: "Mike Foley" <mikiefoley@yahoo.com>P' Subject: Re: Inquirer: OpenVMS on DS20L / Message-ID: <u1krdl8frs8v59@corp.supernews.com>l  ? "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messagea' news:MsoR7.35513$Yy.383191@rwcrnsc53...-J > Pure conjecture, but I have a vague recollection that the DS20L is based onK > a third-party (Samsung) motherboard, not a CPQ-designed board. This mighto4 > have something to do with the lack of VMS support.  H I believe it's based on the API CS20 design, though it may have recievedG "updating" when it moved to Compaq. If so, it's based on the UP2000 API K motherboard. ie: Tsunami-based. However, it probably has a southbridge that/G VMS knows nothing about and ethernet controllers that VMS knows nothingpI about. The CS20 has/had two built-in ethernet controllers, Intel I think.a  K It doesn't surprise me that the DS20L isn't supported on VMS. You don't see H VMS running on a UP1000 either. Qualifying a platform for VMS isn't likeC releasing a new update to Linux after all. There's a tried and truet
 proceedureK for supporting new hardware. The VMS group has to be in on the design cycleoJ of the system in order to time support for it. The VMS group was NOT in onG the design cycle of API's CS20. It was developed to run Linux and MAYBEoF Tru64 on a good day. After all, Tru64 and VMS are Compaq products, not  sold or supported by API.  L As Fred K. said, if your customers decided they had to have x00's of DS20L'sK running VMS, I'm sure the product managers in ZK would stand up and notice.-     --   mike Former VMS Group system manager1* Former technical marketing engineer at API   ------------------------------  # Date: Fri, 14 Dec 2001 21:35:59 GMTe4 From: "Terry C. Shannon" <terryshannon@mediaone.net>' Subject: Re: Inquirer: OpenVMS on DS20Li= Message-ID: <3huS7.12759$Sj1.7261277@typhoon.ne.mediaone.net>n  . "Tom Linden" <tom@kednos.com> wrote in message3 news:CIEJLCMNHNNDLLOOGNJIAEOIDLAA.tom@kednos.com...s >  >n > > -----Original Message-----> > > From: Fred Kleinsorge [mailto:kleinsorge@star.zko.dec.com], > > Sent: Friday, December 14, 2001 10:20 AM > > To: Info-VAX@Mvb.Saic.Comu+ > > Subject: Re: Inquirer: OpenVMS on DS20Lm > >p > >s# > > Phillip Helbig wrote in message 6 > > <01KBV9MUZL029138XQ@sysdev.deutsche-boerse.com>...H > > >> And guess what.  There were no plans for any new small Alphas you might K > > >> have considered for a desktop or even a desk side.  The smallest EV7rH > > >> platform is a dual processor server.  The EV8 would have had 64kb pagessH > > >> only (translation: ~2GB minimum memory configurations are what weL > > >> envisioned). Do you know what *my* personal WS is today?  A DS20E.  AJ > > >> bit too noisy for anyone that hasn't already lost a fair percentage of > > >> their hearing.c > > >>J > > >> At least Itanium provides the possibility of something smaller, and > > >> cheaper.s > > >sL > > >Presumably, this was the plan before talk of the merger, and before theL > > >death of ALPHA.  What was the reasoning behind it?  I always consideredK > > >it a strength of VMS that it ran on everything from very small to verysL > > >large machines.  For various reasons (purchase price, loudness, runningJ > > >costs), many people don't develop on really big systems.  Also, thereG > > >are some applications which could make use of a fast CPU but whichi don't  > > >need a lot of memory. > > >s > >  > > G > > Well.  I suppose it is because it is the Alpha Server business that- makes-I > > the money.  The Alpha workstation business effectively folded.  AlpharC > > Servers itself is focused on 1) performance, 2) performance, 3) @ > > scaleability, 4) performance, 5) reliability.  Why?  Because > > performance wasn > > Alpha's differentiation. > >:B > > EV7 has no other purpose that to provide high-performance, and > > scale to very K > > large systems.  It is not focused on the uniprocessor market.  You wantoL > > something on the desktop, think EV68, but not EV7 or EV8, or EV9, or any# > > other processor on the roadmap.  >iI > So if you are going to continuing producing desktops based on EV68, whyc not L > EV7, it is only a chip and the incremental cost to produce a new board for > it+ > (if it is even required) is small indeed.t  L Well, the base "building block" for EV7 is a dual-processor board. There mayG have been plans to do a uni, but such plans went away about a year ago.r  I Pete Bannon's EV7 pitch shows such a building block, it's a public-domain J slide that also appears in the Marvel PID that Compaq offers to customers.  I I presume Compaq figures it isn't worth the time or expense to design andGF produce an EV7 uni box. If unis are primarily used for development, an) EV68-based uni probably is the way to go.o  H Meanwhile, Reliable Sources indicate that Compaq is mulling over ways toC deliver affordable VMS development environments in the pre-IPF era.m   ------------------------------  # Date: Fri, 14 Dec 2001 22:24:01 GMT0* From: "Bill Todd" <billtodd@metrocast.net>' Subject: Re: Inquirer: OpenVMS on DS20Lp@ Message-ID: <5_uS7.98027$C8.6858661@bin4.nnrp.aus1.giganews.com>  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message, news:_JqS7.606$BK1.15878@news.cpqcorp.net...   ...,  L > Nobody has presented a credible case for how Hammer gets beyond IA32 mode,( > besides some niche Linux applications.  K I suppose if you apply sufficiently stringent criteria to what you considerWH 'credible' (e.g., ignoring the presence in Windows code of 64-bit HammerF specifics because no Windows using them has yet shipped).  But if yourE criteria are that stringent, you could equally assert that nobody has L presented a credible use for Itanic *anywhere*:  there's always a far better. alternative for anything you might wish to do.   - bill   ------------------------------  # Date: Fri, 14 Dec 2001 22:28:55 GMT * From: "Bill Todd" <billtodd@metrocast.net>' Subject: Re: Inquirer: OpenVMS on DS20LsB Message-ID: <H2vS7.258141$8q.24296054@bin2.nnrp.aus1.giganews.com>  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message, news:ssrS7.614$BK1.16039@news.cpqcorp.net...   ...r  I > EV7 has no other purpose that to provide high-performance, and scale toh veryI > large systems.  It is not focused on the uniprocessor market.  You wantEJ > something on the desktop, think EV68, but not EV7 or EV8, or EV9, or any! > other processor on the roadmap.S >tL > From I think a non-VMS perspective, anything small enough to be on or next2 > to a desktop, is something for a Intel solution. >uE > Do I agree with that?  Not from a VMS, or Tru64 perspective.  WhileeL > certainly big systems is where we make our money, you still need the small. > form factor ones to sell the whole solution. >iL > Itanium has the potential of providing us a lower-cost platform than where > Alpha was heading.  H But not a lower-cost platform than Alpha *already* provided in EV68, andH with only process-shrinks that could have been kept reasonably cost- andJ cost/performance competitive for most of the rest of the decade in low-endK use (hint:  compare chip area and power requirements with *anything* Itanica will ever produce).r   - bill   ------------------------------   Date: 14 Dec 2001 19:16 CSTo' From: carl@gerg.tamu.edu (Carl Perkins)A' Subject: RE: Inquirer: OpenVMS on DS20La- Message-ID: <14DEC200119162130@gerg.tamu.edu>h  1 Kilgallen@SpamCop.net (Larry Kilgallen) writes...e` }In article <CIEJLCMNHNNDLLOOGNJIAEOIDLAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes: } N }> So if you are going to continuing producing desktops based on EV68, why notM }> EV7, it is only a chip and the incremental cost to produce a new board for-/ }> it (if it is even required) is small indeed.s } L }If it provides no advantage over the EV68 in that environment, why bother ?  F It does provide a benefit: the on chip memory controler has phenominalH performance compared to anything in any (current or likely) EV6x system.   --- Carl   ------------------------------  % Date: Sat, 15 Dec 2001 00:46:49 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> ' Subject: Re: Inquirer: OpenVMS on DS20L , Message-ID: <3C1AE3C7.254400D1@videotron.ca>   Fred Kleinsorge wrote:N > And guess what.  There were no plans for any new small Alphas you might haveM > considered for a desktop or even a desk side.  The smallest EV7 platform iso > a dual processor server. e  I But that was a political decision by Compaq. I agree with Alan Grieg that M Windows NT was dropped from Alpha when Compaq decided it wasn't going to push=I Alpha (and hence phase it out).  Following that time, any plans for AlphasM would have been only to extend the revenu stream of installed base with a fewo wins here and there.    J I would also find credible that Compaq decided to keep Alpha alive at thatG time because IA64 wasn't credible yet and waited until it saw IA64 as a= credible platform.  I I would not be surprised to learn that Capellas would have negotiated the H Alpha murder with Andy Grove a long time ago with the deal on hold untilE Windows boots on IA64. 3 days after this happened, Alpha is murdered.5    M My only question is what arguments did Compaq use at the time it decided thatkM Alpha wasn't going to make it and Compaq shouldn't bother with Windows-Alpha.IG Were they so intel-centric that they didn't even take a serious look atlC Alpha's potential for both desktop and mini and mainframe servers ?t   ------------------------------  % Date: Sat, 15 Dec 2001 01:03:15 -0500n- From: JF Mezei <jfmezei.spamnot@videotron.ca> ' Subject: Re: Inquirer: OpenVMS on DS20Lh, Message-ID: <3C1AE7A0.AC1DEEE2@videotron.ca>   Fred Kleinsorge wrote:K > Well.  I suppose it is because it is the Alpha Server business that makesfB > the money.  The Alpha workstation business effectively folded.    L For the same reason that Compaq needs wintel desktops , VMS/Alpha also needsE desktops. By widthdrawing workstation support, you eliminated a largedJ potential for business. By eliminating desktops, you relegated Alpha to an  even lower volume niche product.  I Alpha desktops need not lose money, but they need not be profitable. They K attract the business that will then buy the bigger profitable systems, justnM like folks who are happy with their compaq wintel desktop are likely to orderoJ from Compaq when they need wintel servers. And the lack of workstation mayW cost you sales of larger systems since it makes testing and development more expensive.n  L When Compaq bought Digital, it should have been fully aware that Digital hadE never really tried to seriously push Alpha. It *should* have seen theOL potential of Alpha and given it a fair attempt at allowing it to compete andH marketed Alpha workstations and servers to tell the world that Alpha wasI finally in business.  At that time, Compaq was still seen as a leader anda7 would have been able to make Alpha "industry standard".m    N In hindsight, it seems that Compaq never really wanted Digital and Digital wasN forced onto Compaq. As soon as Pfeiffer was out, Compaq decided that it shouldJ simply write off that waste of money called "Digital". But the distractionM during the Tandem/Digital acquisitions made Compaq lag behind other PC makersHI and it became dependant on those revenus generated by the very stuff theyr didn't want: Digtal.   ------------------------------  % Date: Sat, 15 Dec 2001 01:12:36 -0500e- From: JF Mezei <jfmezei.spamnot@videotron.ca>k' Subject: Re: Inquirer: OpenVMS on DS20LP, Message-ID: <3C1AE9D0.AFA9B7BC@videotron.ca>   Larry Kilgallen wrote:M > If it provides no advantage over the EV68 in that environment, why bother ?c  N Forget for a minute that Alpha is dead. Consider that you want to sell as manyL Alpha workstations and servers as possible. Consider that you want to fosterF the development of applications that make bets use of EV7's features. N Consider that you want to provide kick ass performance on workstations to beatJ the pants off the 8-86 and IA64. Makes very much sense to evolve the whole2 Alpha product line with the most up to date chips.  G Look at the wintel market. They will often upgrade the chip in the same K machine and market it as a faster machine , usually at an even lower price.: (Imac is an example)  L Last I checked, the DS-10 was still at a low clock rate. How come they don'tF simply upgrade the unit with a faster chip and still call it a DS-10 ?  K Of course, with the demise of Alpha, making workstations or even servers is2I moot. They will keep spewing out Alphas as a convenience for customers togI allow then to comtinue to operate until they migrate to another platform.    ------------------------------  % Date: Fri, 14 Dec 2001 23:38:51 +0100c1 From: John McLean <mcleanj@swissonline.delete.ch>O, Subject: Re: More about Alpha and the merger5 Message-ID: <3C1A7F7B.164F84E8@swissonline.delete.ch>p   Duane Sand wrote:  >  ...l > @ > In January 2001, Compaq directors spoke to stock analysts at aC > web-casted annual meeting.  Alan Greig listened and reported hereaB > that he heard a Compaq VP say that the NonStop Himalaya line wasF > going to be ported onto IPF rather than onto Alpha EV7 as previously> > planned.  This was half a year before Compaq management toldB > anyone in the Himalaya division that we should stop the EV7 port@ > and resurrect our pre-Digital-acquisition port onto IPF.  ThisA > announcement proves to me that Capellas and that VP had alreadyr< > definitely decided by Jan 2001 to cancel future Alpha chip9 > developments (at least for EV9 and beyond, if not EV8).f  G Interesting.  IIRC someone mentioned a few weeks back during the livelysG (?) refutation of Compaq's White paper that Compaq started looking into @ in Februrary.  I recall commenting that this was odd because theD Alpha-is-better-than-IPF paper was released at almost the same time.  H Now you're saying it was decided before January, which surely would haveE been enough time to stifle that paper.  If it had been blocked before G release, we would have been none-the-wiser about what it contained.  In.F fact many of the statements to the effect that Compaq can't be seriousH because they've just said Alpha was better would never have been voiced.  1  A > We in the Himalaya division certainly didn't want the delay andc? > costs of starting over, yet again; EV7 and its chip designers.; > and compiler team were far nicer to work with than Intel.r  D But you've just claimed that Compaq had decided to terminate Alpha 6@ months before they redirected your efforts from Alpha to IPF forF Himalaya.  What reason can you suggest as to why they would completely- waste 6 month's effort by you and your team ?|   > A > The HP board of directors have said that they began discussions E > among themselves about possible acquisitions and mergers, including|< > possibly Compaq.  Some reporters and many people here have@ > interpreted that remark to mean that Fiorina and Capellas haveE > been discussing mergers and joint restructurings from that time on.:  D As far as I am aware the HP people have never stated, one way or theF other, who they discussed mergers with before Fiorina talked seriously to Capellas.  @ > Capellas has said no, that's not what happened; he and Fiorina= > first began discussing possible merger after some unrelatedh9 > proposals for licensing HP-UX to Compaq for filling out 6 > Compaq's commercial Unix mid-range offerings on IPF.  E Ahh, No !  According to Fiorina - and I think subsequently Capellas -eD they had met in New York for some IT forum discussions last year andD there was a meeting-of-the-minds (my words, not hers) on a number ofC issues.   I will have to dig up her submission to SEC,but I seem touE recall mention of a series of discussions earlier this year and theserH gradually developed from working together on some projects/issues into a merger.T  G I recall no mention of any licensing of HP-UX to Compaq re Unix on IPF, D but I will search some of the EDGAR submissions over the weekend and0 will report anything that I find on that matter.  > > Those Unix license discussions occurred well after the long-< > running Alpha/IPF contractual negotiations with Intel were > underway.-  H Let's defer that issue for a moment until I can find evidence to supportG your claim.  Let's ask instead about the stage that discussions between E Fiorina and Capellas may have reached by late May or early June.  The<A difficulty is of course that we have no clear picture of when the8B decisions about Alpha was made.  On the other hand, to make such aH decision in Quarter 1 and not announce it - and allow financial benefitsD from Quarter 2 onwards - sounds rather strange.  Surely Compaq wouldG have acted promptly after reaching their decision if it meant they were B going to save about $100 million off the bottom line each quarter.  C As I said about 16 hours ago, the meeting on June 22 between HP and G Compaq had to contain some component of preparation time.  If we assumenE - and yes it is an assumption - that the meeting was arranged in latee? May to allow adequate time to assemble relevant information andaH investigate anything that needed investigation (like estimated dollars),E then putting this with the previous paragraph it becomes increasinglyaF likely that the decision to terminate Alpha came about while preparing for the June 22 meeting.  H To conceptualise it very simply, Compaq - or was it Capellas alone ?  WeG cannot be sure. - decided to explore the possible obstacles to a merger + and to do whatever possible to remove them.6  D Did Compaq (or Capellas) want the merger to go ahead ?  Yes, I think@ they had already decided to make every effort to take this path.  D At the end of March revenue in PCs ("Access") was $350 million lowerG than in Year 2000 and what had been a $15 million profit on expenses ofoH $4689 million had turned into a loss of $82 million on expenses of $4456H million.  In "Enterprise" the drop in revenue was just $45 million (from+ $2953) but income was down by $132 million.u  @ (** Something very strange here.  The above figures use Compaq'sF "restated" figures for each segment when the segments changed in AprilG 2001.  The original 31 Mar 2000 figure for Enterprise revenue was $4726nC million, with income $568 million.  Somehow these morphed into justlB $2953 million revenue and $262 million when they were "restated". F That's a big change !!!  And we have a $150 million shortfall in total  income to contend with as well.)  C At the estimated time of initial contact for the subsequent June 22rB meeting it would have been obvious that Compaq was going to take aF pasting for the second quarter as well as the first.  As things turnedA out, PCs would lose about $240 million for the first half year on F revenue of $8.1 billion and that was down from a $59 million profit onD revenue of $9.6 billion in 2000.  Enterprise would make $106 millionC profit on $5.6 billion revenue, but that was down from $645 millionoG profit on revenue of $6.6 billion.  (I'm using the restated figures fort, 2000 here just to compare apples to apples.)    G Make no mistake, there were some strong financial attractions in Compaqs6 being bought out by, or merging with, another company.  F Perhaps in my earlier I put a little too much emphasis on the personalG gain that senior Compaq people stand to make if the merger goes throughyG (like Capellas getting $14.1 million at some stage).  I object to these D bonuses on principle.  These people are employed to take appropriateG action for the company.  If one of those actions is to oversee a mergerhF ("oversee" because they usually just delegate the work), then I regardD this as something they are paid to do and that bonuses should not be part of it.   C Regardless of all this, it is very evident that there are some veryeH personal motivations for trying to ensure that the merger takes place.  ? To what extent these personal issues have influenced any of theaC applicable people is impossible to judge; I simply remark that theyt exist.     C > The HP BOD remark and Capellas' statements are not contradictory. = > The HP BOD merely said they debated possible merger actionsiB > among themselves, not that they contacted any of those companiesC > and began serious discussions with any of them, including Compaq.a  F True as regards the HP BoD, but we know that Fiorina and Capellas wereG having quiet chats about all kinds of things prior to June 22.  As AlanpD Greig remarked today, we have no idea when the discussions turned toE talk of a merger rather than simply working together in various ways.r  C > This happens all the time; companies routinely consider all sortsu@ > of possible and impossible acquisitions and spin-offs, without6 > any of that going beyond some internal-only debates.  . Of coure they do, and of course they should.    ; > I believe the axe was already falling on Alpha before thedA > merger was contemplated, not vice versa.  Others will doubtlessd > prefer grander conspiracies.  E I don't know.  There are some "independent" reasons why the axe couldoC have fallen on Alpha, but there are also some very powerful reasonsrH related to the merger which could have caused Compaq to quickly grab theF axe and start wielding it.   With some unspecified level of discussionE underway from last year between at least some people in Compaq and at.7 least some peple in HP, it all continues to look fishy.   F I find it difficult to believe the exceedingly good fortune of HP who,C just weeks before serious merger discussions, finds their target isfH suddenly $3 or $4 billion dollars cheaper.  Not only that but the vexingE problem of two versions of unix has also disappeared.  Coincidence ? y I'm not so sure.     John McLeano   ------------------------------  % Date: Sat, 15 Dec 2001 01:28:18 -0500n- From: JF Mezei <jfmezei.spamnot@videotron.ca> , Subject: Re: More about Alpha and the merger, Message-ID: <3C1AED7D.380496A0@videotron.ca>   John McLean wrote:J > Now you're saying it was decided before January, which surely would have) > been enough time to stifle that paper. -  N Consider that often long term strategic decisions are known only to a few very  high exec VPs and president/CEO.  J From Compaq's point of view, they may have decided that Alpha was out backN when Windows was dropped, with various metrics to gauge how quickly they couldL move with that long term project (eg: dependant on Intel finally producing aK working 64 bit chip). Meanwhile, it is business as usual below at the gruntiN level, and since Alpha is still technologically superior to IA64, it is normalF to expect engineers to continue to say that Alpha is superior and will  continue to be superior to IA64.   ------------------------------  # Date: Fri, 14 Dec 2001 22:44:10 GMTt* From: "Bill Todd" <billtodd@metrocast.net>; Subject: Re: Move to an HP OS, most folks would rather not..B Message-ID: <_gvS7.258144$8q.24307327@bin2.nnrp.aus1.giganews.com>  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message, news:_2rS7.608$BK1.15719@news.cpqcorp.net... > ? > JF Mezei wrote in message <3C199651.FF940430@videotron.ca>...  > >Bill Todd wrote:hC > >> 'Facing the proposed merger, 45 percent of the Alpha customersh
 > interviewedeI > >> by Warburg believed it was "less likely" that they would stay with arK > >> combined HP/Compaq company, while 55 percent said their feelings aboutm1 > >> remaining a Compaq customer were "unchanged"  > >iA > >What is important to consider is whether there are significanto differencesg9 > >between the 45% and 55% in terms of customer profiles.S > >S >a >e7 > Yeah, like 45% were Tru64 customers and 55% were VMS.@  1 In that case, you should start worrying about the L unquantified-but-sufficiently-significant-to-mention portion of that 55% whoI had already decided to dump Compaq (you might have missed that in a quickn	 reading).n   - bill   ------------------------------  # Date: Fri, 14 Dec 2001 22:50:20 GMT * From: "Bill Todd" <billtodd@metrocast.net>; Subject: Re: Move to an HP OS, most folks would rather not.eB Message-ID: <MmvS7.240116$uB.25994979@bin3.nnrp.aus1.giganews.com>  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message, news:N%qS7.607$BK1.15808@news.cpqcorp.net... >   > Bill Todd wrote in message ... > >e > >,I > >I'm sure Fred will be delighted that someone has actually gone out and L > >polled Alpha customers to find out how they feel, but, again, the resultsG > >seem less consistent with his optimistic view of the world than witha > >others':w > >l >p > ...  > > < > >Admittedly, the poll here was merger-specific rather thanI > >Alpha-to-Itanic-specific, but it still indicates significant sentimenttF > >toward defection that Fred's radar does not appear to have detected (thoughoI > >one could understand why it might be much more heavily weighted towarde > Tru64 J > >customers).  And without attempting to quantify defection potential theK > >article does mention the discomfort Alpha customers reportedly have witho > >Itanic as a replacement.o > >d >d >tK > On its face, this thing puports to relay the effects on "Alpha" customersuF > and their probability of moving to HP-UX.  This, I would submit, has nothingh > to do with OpenVMS.n  K Ask your speed-reading course for a refund:  the context of this particularoH result was the merger per se, without reference to the specific issue ofK migrating to HP-UX (where IIRC 90% of the respondents said they'd seriouslyd. consider instead migrating to another vendor).  6   You want to be able to eat your cake here by lumping6 > "Alpha" bad news together to make it "VMS" bad news.  H No.  In point of fact, my original assertion was that Alpha sales tankedI after June 25th, and it was you who responded in what you apparently felt J was a rebuttal by stating that you hadn't seen such erosion (presumably inI VMS sales).  I'm simply using this reference to support my own statement,gB though the article also casts some doubt on your more limited one.   - bill   ------------------------------  % Date: Fri, 14 Dec 2001 23:16:53 +0100 9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> 7 Subject: Re: nova (was: RE: Inquirer: OpenVMS on DS20L)o' Message-ID: <3C1A7A55.3932B261@aaa.com>t  E Well, nothing where the star *was*. Was is left of it is a lot of gasn that islH thrown out in space in all directions. When our "sun" reach this status, it@ will end it's "life" by becoming an "nova" and expand to includeD all three nearest satelites (Mercurius, Venus and Earth). Well, that& will more or less be the end of all...  
 Jan-Erik..     Eric Smith wrote:e  . > Jan-Erik Sderholm <noone@dummy.com> writes:; > > The astronomical "nova" is actualy an exploding star at > > > the end of it's (normal) life. Depending on it's size, the> > > nova can end in just nothing or in a white small, very hot	 > > star.a >t! > It can't end in "just nothing".    ------------------------------  % Date: Fri, 14 Dec 2001 22:40:31 -0500d' From: Howard S Shubs <howard@shubs.net>h" Subject: Re: Old VAX Documentation< Message-ID: <howard-D0ED79.22403114122001@enews.newsguy.com>  A In article <5.1.0.14.2.20011214081331.0504ab40@mail.eclipse.net>,n)  Ken Robinson <kenrbnsn@rbnsn.com> wrote:a  O > 1) The 1981 VAX Architecture Handbook (Sub-titled "Architecture for the 80's"a   VERY good book.h --   Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"( Golf vs Bug: VW has been cutting corners   ------------------------------  + Date: Fri, 14 Dec 2001 20:22:03 +0100 (MET) 9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>- Subject: post etiquette ; Message-ID: <01KBVD55QKF29138XQ@sysdev.deutsche-boerse.com>m  B > Again I have problems with the format of one of your posts and I/ > probably won't make a huge effort to read it.g > J > The problem is the line wrapping. (See example below which contains some > of your posting.)  > H > We all do it from time to time but it should be easy to correct before > posting, not after.e > E > What I've started to do lately is to cut-and-paste, then remove theaD > obvious carriage-returns, then resize the width of window that I'mJ > working in to see how the text wraps under the new size and to make sure> > that I have removed all the carriage-returns that I need to.  D There is absolutely no substitute for limiting original lines to 72 I characters (comes second-nature to me as an old Fortran programmer :-)), fF which allows them to be quoted 4 times by the usual 2-character quote I symbol (e.g. "> ").  Important is that the line breaks are REALLY there; nF unfortunately, many editors (emacs comes to mind) display them on the H screen but don't put them into the file which is written.  (To be fair, C VMS MAIL in its /NOEDIT mode, i.e. when the text of the message is rE entered at the prompt, does this as well (though one can put in real  I line breaks by hitting RETURN), but I don't think anyone is posting here 0 using VMS MAIL/NOEDIT.)   I Of course, things should be just printable ASCII, not be in HTML, not be nE encoded etc.  Unfortunately, some software includes things like HTML  B (either formatting the whole message that way or appending a HTML I version of the same text message to the text message) without the sender s
 realising it.t  6 OK, we'll forgive the folks who indent with TABs.  :-)   ------------------------------  % Date: Fri, 14 Dec 2001 20:15:36 +010071 From: John McLean <mcleanj@swissonline.delete.ch>fN Subject: Re: Press Release SyntheSys Secure Technologies - JabCast  on OpenVMS5 Message-ID: <3C1A4FD8.3959A70B@swissonline.delete.ch>t   Hi Sue,t  @ Again I have problems with the format of one of your posts and I- probably won't make a huge effort to read it.t  H The problem is the line wrapping. (See example below which contains some of your posting.)   F We all do it from time to time but it should be easy to correct before posting, not after.W  C What I've started to do lately is to cut-and-paste, then remove theoB obvious carriage-returns, then resize the width of window that I'mH working in to see how the text wraps under the new size and to make sure< that I have removed all the carriage-returns that I need to.     John McLeane  / PS.  This doesn't only apply to Sue either !!!!l       Sue Skonetski wrote: >  > They also have a surveya >  > Suet >  > http://www.prnewswire.comC > J > BOCA RATON, Fla., Dec. 12 /PRNewswire/ -- SyntheSys Secure Technologies,J > Inc. announces the release of the JabCast Secure Realtime Communications > (SRC) I > system on Compaq Computer Corporation's AlphaServer systems running thenK > OpenVMS operating system.  SyntheSys developed the product for JabCast, al > Newh > York-based software company.N >     JabCast SRC is the first technology that allows for realtime interactiveL > text, file, and document exchange in a secure environment via the InternetN > across multiple operating systems including Windows NT, Windows 2000, Linux, > and UNIX. J >     "Many companies and government agencies have been unable to maximize > theirdI > productivity and communications with the use of realtime communicationsp > acrossL > the Internet because of significant security concerns and the inability of   ------------------------------    Date: 14 Dec 2001 13:01:03 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)e. Subject: Re: Reloading device drivers on Alpha3 Message-ID: <vpZPyHXRHPgZ@eisner.encompasserve.org>i  j In article <P5rS7.609$BK1.16022@news.cpqcorp.net>, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:J > Nope.  I agree it's a pain in the ass, and I disagreed with the decisionD > when it was made.  But the only really safe thing to do is reboot.  5 If you want safety, don't work on device drivers :-).t   ------------------------------  % Date: Fri, 14 Dec 2001 14:04:36 -0500n- From: "Peter Weaver" <peter.weaver@stelco.ca> . Subject: Re: Reloading device drivers on Alpha3 Message-ID: <q3sS7.76051$Z2.1097831@nnrp1.uunet.ca>o  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message, news:P5rS7.609$BK1.16022@news.cpqcorp.net...$ > Simon Clubley wrote in message ...F > >I am aware that reloading of device drivers on Alpha as such is notH > >possible, but I am interested in hearing what techniques other driver >...J > Nope.  I agree it's a pain in the ass, and I disagreed with the decisionD > when it was made.  But the only really safe thing to do is reboot. >...  ( Is this a bug that will be fixed in IPF?  K You may not call it a bug, but I always have, it was a major step backwardstJ when upgrades to applications started including reboots. A few years ago IJ was on an airplane sitting next to a PC person who had some VMS experienceH from many years ago. He was complaining that he had to reboot a PC afterG installing IE, and he said that as he was doing it he remembered how heiJ could never remember the VMS boxes going down at all. I really had to biteJ my lip to keep from telling him that things had gotten worst since he last touched VMS.     --J A study has shown that sheep can remember faces for up to 2 years, I guess- that means I'm dumber than the average sheep.n   ------------------------------  % Date: Fri, 14 Dec 2001 05:10:48 -0500n5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>a. Subject: Re: Reloading device drivers on Alpha2 Message-ID: <8MuS7.616$BK1.15996@news.cpqcorp.net>  8 "Peter Weaver" <peter.weaver@stelco.ca> wrote in message- news:q3sS7.76051$Z2.1097831@nnrp1.uunet.ca...bB > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message. > news:P5rS7.609$BK1.16022@news.cpqcorp.net...& > > Simon Clubley wrote in message ...H > > >I am aware that reloading of device drivers on Alpha as such is notJ > > >possible, but I am interested in hearing what techniques other driver > >...L > > Nope.  I agree it's a pain in the ass, and I disagreed with the decisionF > > when it was made.  But the only really safe thing to do is reboot. > >... > * > Is this a bug that will be fixed in IPF? >r  I No.  But perhaps it might as a side effect of hot-plug PCI.  Drivers will4/ need to know how to quiece, and perhaps unload.   C > You may not call it a bug, but I always have, it was a major step 	 backwardslL > when upgrades to applications started including reboots. A few years ago IL > was on an airplane sitting next to a PC person who had some VMS experienceJ > from many years ago. He was complaining that he had to reboot a PC afterI > installing IE, and he said that as he was doing it he remembered how he L > could never remember the VMS boxes going down at all. I really had to biteL > my lip to keep from telling him that things had gotten worst since he last > touched VMS. >n  F It was a decision by those charged with doing the driver structure forG Alpha.  The VAX reload mechanism was always a bit "loose".  That is, itp* kind-of worked, at least for some drivers.   ------------------------------   Date: 14 Dec 2001 19:26 CSTd' From: carl@gerg.tamu.edu (Carl Perkins)l. Subject: Re: Reloading device drivers on Alpha- Message-ID: <14DEC200119260100@gerg.tamu.edu>$  1 "Peter Weaver" <peter.weaver@stelco.ca> writes...iA }"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in messagel- }news:P5rS7.609$BK1.16022@news.cpqcorp.net...u% }> Simon Clubley wrote in message ...rG }> >I am aware that reloading of device drivers on Alpha as such is noteI }> >possible, but I am interested in hearing what techniques other driveri }>...tK }> Nope.  I agree it's a pain in the ass, and I disagreed with the decision E }> when it was made.  But the only really safe thing to do is reboot.e }>...g } ) }Is this a bug that will be fixed in IPF?e } L }You may not call it a bug, but I always have, it was a major step backwardsK }when upgrades to applications started including reboots. A few years ago IsK }was on an airplane sitting next to a PC person who had some VMS experience I }from many years ago. He was complaining that he had to reboot a PC aftereH }installing IE, and he said that as he was doing it he remembered how heK }could never remember the VMS boxes going down at all. I really had to bite K }my lip to keep from telling him that things had gotten worst since he lastp
 }touched VMS.   ; Since when do typical applications include a device driver?   B Sure you have to reboot after modifying your IP stack or whatever,C since that involves device drivers. But you still don't have to form an application.   C I have noticed that some applications' installation instructions dosG tell you to reboot, which is usually both unfortunate and unneccessary. F (As I recall, the last thing I installed which said this was PMDF. YouE don't have to, and I didn't. Really. It worked just fine anyway.) ForhD the most part all the reboot gains you is knowing whether or not you@ got the code to setup/startup anything the new software needs to; setup/startup into the system startup proceedure correctly.i   --- Carl   ------------------------------  % Date: Fri, 14 Dec 2001 23:27:12 -0500 5 From: "Brad McCusker" <brad.mccuskerNOSP@Mcompaq.com>s, Subject: Re: remote connection and pathworks2 Message-ID: <lnAS7.618$BK1.15969@news.cpqcorp.net>  7 "Peter LANGSTOEGER" <eplan@kapsch.net> wrote in messager" news:3c172f5c@news.kapsch.co.at...K > In article <1245D1C0C039D411933708002BB29C644B2D09@DOAISD02003>, "Rowell,A& Bradley" <browell@state.mt.us> writes:K > >Pathworks binds to the first TCP interface that it sees, it can only run  on > >one interface.   K Yes, but, I'll qualify it as "first interface that it sees and recognizes".a
 Those withI the new EIA devices know what I refer to.  (And this blindness to the EIAu# devices is fixed in newer releases)c   >oB > I remember seeing PATHWORKS using all my interfaces and I had to  9 If you did see that, then, I'd say you were seeing a bug.$  C > define logicals to stop PATHWORKS using one particular interface.   = Probably what you were seeing was PATHWORKS binding to the an'J interface that you didn't want it to use.  you had to help it find the one you wanted.0  $ > But then again that was years ago. >.  9 Well, maybe then you are going back before my time... ;^)    > YMMV >gH > PS: I think Brad should jump in and give the ultimative answer. Brad ?  + I think so to.  Anyone seen Brad lately...?r       -- +++++++++++++++++++++++++++++++e$ The opinions expressed herein are my% own and do not represent my employer.   
 Brad McCuskery# OpenVMS Advanced Server Engineering    ------------------------------  # Date: Sat, 15 Dec 2001 04:02:51 GMTk- From: "John E. Malmberg" <wb8tyw@qsl.network>sY Subject: Re: SPAM Reporting - was Re: Chase Visa Card, Verisign Thawte Certificate, Rapidf* Message-ID: <3C1AD153.1000504@qsl.network>   Larry Kilgallen wrote:  m > In article <3C1A05CD.5080706@dskwld.zko.dec.compaq>, John Malmberg <Malmberg@dskwld.zko.dec.compaq> writes:p > H >>Actually not really HTML.  It was plain text, the bad HTML tag at the G >>beginning prevented http://www.spamcop.net from decoding the spam to e >>identify the true senders. >>< > On a mail (not newsgroup) message I received this morning,6 > the SpamCop parse put up a red notice about bad HTML8 > but did parse the message correctly.  I had never seen9 > that red notice before, so perhaps it is a new feature._    I It identified the sending account in this case, but not the spamvertised 5E web sites.  These are the real targets, as it takes a while and some o= cash to get the old DNS entries moved to the new DNS and ISP.e  H It means that it skipped parsing part of the message.  When the SPAMCOP H parser saw the content tag of HTML, it stopped parsing until it found a G <HEAD>.  Since there wasn't one, it skipped looking for urls and email s
 addresses.  G Fixing the header and resubmitting it identified several web sites and 4 e-mail addresses.      -John    wb8tyw@qsl.network Personal Opinion Onlyr   ------------------------------  % Date: Fri, 14 Dec 2001 10:57:25 -0800y$ From: Shane Smith <ssmith@icius.com> Subject: sys$getdvi and socket0 Message-ID: <01C1848E.3A0E9060@sulfer.icius.com>   >Help! o >i7 >I have a socket that I've created using socket(), then 7 >bind() and listen().  After the connect() call returns2= >I create a new socket to accept the connection via accept().c >R; >Now I want to find the VMS device name for this socket.  ID? >thought I could get sys$getdvi but am not successful.  What am  >I doing wrong ? >g >Here's the code snipet:   [snip]  H Binh, I think you'll have to go via decc$get_sdc. I don't have the rightE docs loaded right now, but my code comments on the snippet I have sayaG that'll get you the VMS IO channel number. Remember, socket descriptorsf5 are an artifact of berkley sockets, not VMS devices. i  E When I get out from under my current workload I'll be able to be more  help to you.   Shanel   ------------------------------  % Date: Fri, 14 Dec 2001 22:43:03 -0500i' From: Howard S Shubs <howard@shubs.net>t" Subject: Re: sys$getdvi and socket< Message-ID: <howard-DF7291.22430314122001@enews.newsguy.com>  / In article <u1kid46mvva79e@news.supernews.com>,e'  "John Vottero" <John@mvpsi.com> wrote:   J > It only works because you're lucky.  Item lists must be terminated by anM > item list entry that's all zeros.  You only have a single item in your itemaK > list, you're just lucky that the stuff following that happens to be zero.s > M > Make your item list an array and set all the members of the last element tos > zero.s  I Close.  Only the first longword of the final element needs to be zero to uM terminate an item_list_3.  Or, for that matter, an item_list_2.  Or an array.e --   Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"( Golf vs Bug: VW has been cutting corners   ------------------------------    Date: 14 Dec 2001 13:29:56 -08004 From: gherbert@gw.retro.com (George William Herbert)! Subject: Re: The demise of compaqc' Message-ID: <9vdr0k$qtr$1@gw.retro.com>a  ) Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:hE >>> One day this will happen to something critical, and cause a majortD >>> economic collapse - which, history teaches us, very often causes >>> a major war :-(t >>5 >>What "... something critical" did you have in mind?  >eA >Dunno.  One possibility is air traffic control, which is already-B >having problems.  Let us say that there is a load-related problemB >in the infrastructure (i.e. not the main code) that causes LondonB >to go down.  So it switches to the backup.  Because this is load-> >related and software, it goes down.  So it switches to Paris.3 >The extra load then triggers the same problem ....l >rA >Today, there are manual backups that will get most aircraft down"@ >intact.  In 20 years, there probably won't be.  And all backupsE >are against hardware failure - NOT against a failure of the softwaretA >design.  Now a one-off incident like that (even if 20,000 peoplekB >died) isn't serious.  But what if the programmers couldn't locate
 >the problem?l  B Actually, ATC is moving to a redundant and distributed independent@ model from a single central control model, which should increase? reliability a lot.  The collision avoidance systems on aircraft-@ now are independent; each aircraft has the system, it broadcastsE and receives, so you can avoid collisions even if ATC goes completelym$ away due to catastrophic collapse.    D There have been isolated incidents of regional ATC going out before,@ and the response is usually that everyone stops feeding aircraftB into that zone, and all the aircraft in it watch more closely withA visual and keep a close eye on their collision avoidance systems, F and announce maneuvers and position on the radio as often as practicalD given the aircraft density.  The area clears out, including aircraft6 getting on the ground that need to, reasonably safely.     -george william herbertd gherbert@retro.com   ------------------------------  # Date: Fri, 14 Dec 2001 21:40:12 GMTu  From: jlsue <jlsuexxxz@home.com>! Subject: Re: The demise of compaqo8 Message-ID: <bcsk1u4ndl08802uocfpostojkdk9soucj@4ax.com>  9 On Thu, 13 Dec 2001 10:21:13 +0100, Franz-Josef Fornefeldp <jo.fornefeld@gmx.de> wrote:   >Goran Larsson wrote:  >e0 >> My conclusion was that software should have aF >> software quality that is balanced. Not too bad as your customers goH >> elsewhere. Not too good as your customers don't need your help fixing >> bugs. > B >We had the same experience. Our customers cancelled their service >contracts in the 90's.o >kG >A well configured VMS system runs practically with no attention[1] and E >so does our software[2]. It was more economic to call for service onh >demand. >e: >[1] our record holder is a VAX8250 with ~1500 days uptime. >[2] not bug free of course, but fairly robust  C Unfortunately, due to lack of ongoing maintenance contracts, all of # the local service reps were let go.t   Sorry, please call again.s  1 Not speaking for anyone, certainly not DEC/Compaqt- (get rid of the xxxz in my address to e-mail)r   ------------------------------   Date: 14 Dec 2001 21:40:41 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)! Subject: Re: The demise of compaq 0 Message-ID: <9vdrkp$ku7$1@pegasus.csx.cam.ac.uk>  ' In article <9vdr0k$qtr$1@gw.retro.com>,E5 George William Herbert <gherbert@gw.retro.com> wrote:C* >Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:F >>>> One day this will happen to something critical, and cause a majorE >>>> economic collapse - which, history teaches us, very often causesm >>>> a major war :-( >>>m6 >>>What "... something critical" did you have in mind? >>B >>Dunno.  One possibility is air traffic control, which is alreadyC >>having problems.  Let us say that there is a load-related problem C >>in the infrastructure (i.e. not the main code) that causes LondonsC >>to go down.  So it switches to the backup.  Because this is load-9? >>related and software, it goes down.  So it switches to Paris. 4 >>The extra load then triggers the same problem .... >>B >>Today, there are manual backups that will get most aircraft downA >>intact.  In 20 years, there probably won't be.  And all backupsaF >>are against hardware failure - NOT against a failure of the softwareB >>design.  Now a one-off incident like that (even if 20,000 peopleC >>died) isn't serious.  But what if the programmers couldn't locate  >>the problem? > C >Actually, ATC is moving to a redundant and distributed independentuA >model from a single central control model, which should increase @ >reliability a lot.  The collision avoidance systems on aircraftA >now are independent; each aircraft has the system, it broadcasts F >and receives, so you can avoid collisions even if ATC goes completely% >away due to catastrophic collapse.  l >eE >There have been isolated incidents of regional ATC going out before,cA >and the response is usually that everyone stops feeding aircraftrC >into that zone, and all the aircraft in it watch more closely withlB >visual and keep a close eye on their collision avoidance systems,G >and announce maneuvers and position on the radio as often as practicaliE >given the aircraft density.  The area clears out, including aircraft 7 >getting on the ground that need to, reasonably safely.l  A Oh, yes, I know about that.  But that isn't the failure mode I ampA talking about.  I am talking about the failure mode that a few ofd? us in the HPC area have encountered, and which has occasionallyu been seen in other areas.   A This is when some aspect of the application doesn't scale, and itfC is the load itself that triggers the failure.  If it is inherent in0D the design, then switching to a backup system will not help (if thatC uses similar software), as the extra load on that will then triggers@ the same problem.  This isn't resolved by going to a distributed5 system, though that assuredly changes the properties.   ? Now, many such failures will not be in the province of computereD architecture, but there are some that are.  Ones where (for example)A such excess loading can trigger an undetected overflow, which has ? no immediate effect, but much later causes an incorrect action. A Please don't mention Ariadne, as simply ignoring overflows is NOT: an improvement in general!  ? The circumstance which I am referring to is where such problemseB occur in code that is so poorly understood that nobody can predictB the consequences of (say) recompiling it with all integers doubled@ in size.  Not even after months of study.  And it is appropriate? to lay the blame for THAT sort of mess on computer architecturet' mistakes (usually software, of course).a     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679,   ------------------------------  # Date: Fri, 14 Dec 2001 22:12:01 GMTi+ From: Anne & Lynn Wheeler <lynn@garlic.com>s! Subject: Re: The demise of compaqn) Message-ID: <u3d2dpi60.fsf@earthlink.net>n  6 gherbert@gw.retro.com (George William Herbert) writes: > D > Actually, ATC is moving to a redundant and distributed independentB > model from a single central control model, which should increaseA > reliability a lot.  The collision avoidance systems on aircraftiB > now are independent; each aircraft has the system, it broadcastsG > and receives, so you can avoid collisions even if ATC goes completelya& > away due to catastrophic collapse.    D current system was done back in the '60s by various guys that nearly all are retired.  F one of the "redos" in the late 80s/early 90s ... was focused on havingE (lots of) triple redundant independent hardware (cluster) effectivelyPC checking on each other. a problem that was uncovered was assumption0F that all failure modes are either hardware &/or operating system whichC using redudancy and/or other checking, all failures could be masked.B totally from the application. based on that assumption ... the ATCF application itself didn't have to have failure-mode logic. The problemC was that there were a number of business process or domain-specific F failure modes ... like missing a hand-off from one regional to another< which turned out had to be handled at the application level.   -- oH Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/    ------------------------------  % Date: Fri, 14 Dec 2001 15:56:24 -0800 & From: name99@mac.com (Maynard Handley)! Subject: Re: The demise of compaqt7 Message-ID: <name99-1412011556240001@handma2.apple.com>u  I In article <OpYR7.293546$W8.10030758@bgtnsc04-news.ops.worldnet.att.net>,n( "Hank Oredson" <horedson@att.net> wrote:G > > But I am also warning that the world is heading for a disaster, andtE > > I don't mean the minor glitches that we have seen so far.  We canaG > > only hope that we receive a healthy shock in time to recover.  Yes,iG > > I really am talking about a potential collapse of civilisation, andh9 > > most of the other experts in this area agree with me.n > , > Which disaster? What cause? Which experts? >   I I have a friend who worked at a bank in Manhattan. His description of theeI risk system they used was quite terrifying---various "objects" running on-H different types of CPUs/OSs, written by a variety of different people toE mutual "understanding" rather than a clear spec, lashed together withsG various perl scripts, and with pretty much everyone responsible for therD initial iteration of this now gone. My friend frequently encounteredG situations where the numbers coming out of the model were clearly wrongSF because something unexpected had happened---Japan posted their numbersH before Singapore unlike the usual case, or some server timed out and the= script talking to it didn't have any sensible error handling.e  H Something like this going wrong and not being caught in time has all theG potential of another Barings or LTCM, and coming at at a less favorable G economic time (or if it has an aspect that is politically touchy---eg auG Japanese bank that screws up, and hurts a lot of Americans) there couldt well be long term consequences.    Maynardg   ------------------------------  + Date: Sat, 15 Dec 2001 00:36:01 +0000 (UTC) 0 From: "Rupert Pigott" <Darkb00ng@btinternet.com>! Subject: Re: The demise of compaql/ Message-ID: <9ve5te$2fb$1@helle.btinternet.com>m  1 Maynard Handley <name99@mac.com> wrote in messageo1 news:name99-1412011556240001@handma2.apple.com...k   [SNIP]  F > initial iteration of this now gone. My friend frequently encounteredI > situations where the numbers coming out of the model were clearly wrongvH > because something unexpected had happened---Japan posted their numbersJ > before Singapore unlike the usual case, or some server timed out and the? > script talking to it didn't have any sensible error handling.   D This is what I meant by gangs "niggles" becoming almighty "cockups".  E That rings familiar bells with my friends too. One of them complained B bitterly that the most reliable methods of promotion were golf and procreation. :)    Cheers,o Rupert   ------------------------------  % Date: Fri, 14 Dec 2001 22:39:29 -0700t+ From: "Dennis O'Connor" <dmoc@primenet.com>t! Subject: Re: The demise of compaqt3 Message-ID: <1008394770.988349@nnrp2.phx1.gblx.net>   9 "George William Herbert" <gherbert@gw.retro.com> wrote... + > Nick Maclaren <nmm1@cus.cam.ac.uk> wrote::G > >>> One day this will happen to something critical, and cause a majorp > >>> economic collapse - [...]  > >>7 > >>What "... something critical" did you have in mind?. > >.C > >Dunno.  One possibility is air traffic control, which is already, > >having problems.  [...] >tD > Actually, ATC is moving to a redundant and distributed independentB > model from a single central control model, which should increaseA > reliability a lot.  The collision avoidance systems on aircraftsB > now are independent; each aircraft has the system, it broadcastsG > and receives, so you can avoid collisions even if ATC goes completelys$ > away due to catastrophic collapse. >nF > There have been isolated incidents of regional ATC going out before,B > and the response is usually that everyone stops feeding aircraft > into that zone, [...]   A And here in the US, we spent a few days without _any_ air traffic'> being allowed at all, except for military and law enforcement.? While it was different to look up and see no contrails, somehowy civilization did not collapse.  4 George, any idea how well AWACS/JSTARS would do as a9 temporary replacement for ground-based ATC ?  They seemed C to handle quite a bit of air traffic with them during the Gulf War.+  = You'd think that with his contacts with "experts", Nick wouldt: have been able to come up with a better doomsday scenario.? Or at least one that didn't expose his ignorance quite so much.  --3 Dennis O'Connor                   dmoc@primenet.comn3 We don't become a rabid dog to destroy a rabid dog.    ------------------------------  # Date: Sat, 15 Dec 2001 01:52:46 GMT0- From: "Dave Kneitel" <dkneitel@optonline.net> 9 Subject: Re: Unix for HELP ... Examples? ANS: No standarda9 Message-ID: <O1yS7.6795$bs2.1614422@news02.optonline.net>u  I If you use the Compaq online doc rather then the man pages, you will findn> examples for commands; it is organized similar to the VMS doc.    2 "C.W.Holeman II" <cwhii@mail.com> wrote in message" news:3C17F838.B97D7783@mail.com... > "C.W.Holeman II" wrote:  > >r* > > What is Unix for Examples in VMS HELP?# > > MAN seems to lack this feature.n > D > So, man is the location for examples to be provided. Or did I missD > something? apropos will help direct one to a manual entry but does  > not address the example issue. > > > In general, those who created the man pages do not appear toE > have understood the need for the information. In VMSland there must ? > have been a documentation standard that required the examples ? > section. So, it looks like it is just a lack of documentationw4 > standards that has not been addressed to this day. >s >.< > Also, the use of VMS terminology is the main reason I post' > this kind of question on comp.os.vms.J >  > -- > C.W.Holeman II > cwhii@mail.com > http://also.as/cwhii   ------------------------------  % Date: Fri, 14 Dec 2001 14:48:14 -0700  From: Kevin Handy <kth@srv.net>g Subject: Re: vms 3.x question0' Message-ID: <3C1A739E.920CEBF0@srv.net>l   Robert DiRosario wrote:t > I > No typo in the title, I got the RA81 running on my VAX 4000 and mountedtI > it and it looks like it has VMS 3.x on it!  Looking around on it I findtI > files with names that start with "starlet" and "rsx" and "rms".  (Now IoD > know why the 4000 gave "?" when I tried to get it to boot from the > disk!) > C > When I look around in [SYS0.SYSUPD] the .com files seem to be for C > version 3.x.  How can I tell for sure what version of VMS it has?m  8 Try doing a 'sho sys' and look at the banner at the top.& It should tell you what version it is.  G > It looks like it was on a 750 but it has some files with "730", "750" E > and "780" as part of the file names.  Would one distribution of 3.x  > support all of those systems?- > H > This version of VMS is old enough that I want to make a good backup ofG > it.  I have 7.1 running on the 4000, with a TK70 and a 4mm drive, and-I > lots of disk space.  Other then a few dozen hours on my hobbyist systemmD > it's been 12+ years since I used VMS.  How do I back this disk up, > including any boot files?o >  > Thanks > Robert   ------------------------------  % Date: Fri, 14 Dec 2001 14:56:23 -0700e From: Kevin Handy <kth@srv.net>i Subject: Re: vms 3.x questions' Message-ID: <3C1A7587.22975521@srv.net>   . Oops, I didn't notice you hadn't booted on it.  E What yow might want to try, is look for a file in sys$manager on thatw@ drive (whatever the path was), and see id there is a 'welcome.*'B file there (welcome.txt, welcome.template). It often contains the  version number in it.    Kevin Handy wrote: >  > Robert DiRosario wrote:c > >"K > > No typo in the title, I got the RA81 running on my VAX 4000 and mounted K > > it and it looks like it has VMS 3.x on it!  Looking around on it I findaK > > files with names that start with "starlet" and "rsx" and "rms".  (Now IrF > > know why the 4000 gave "?" when I tried to get it to boot from the
 > > disk!) > > E > > When I look around in [SYS0.SYSUPD] the .com files seem to be forhE > > version 3.x.  How can I tell for sure what version of VMS it has?" > : > Try doing a 'sho sys' and look at the banner at the top.( > It should tell you what version it is. > I > > It looks like it was on a 750 but it has some files with "730", "750"mG > > and "780" as part of the file names.  Would one distribution of 3.x ! > > support all of those systems?k > >BJ > > This version of VMS is old enough that I want to make a good backup ofI > > it.  I have 7.1 running on the 4000, with a TK70 and a 4mm drive, and K > > lots of disk space.  Other then a few dozen hours on my hobbyist systemeF > > it's been 12+ years since I used VMS.  How do I back this disk up, > > including any boot files?f > >s
 > > Thanks
 > > Robert   ------------------------------  % Date: Sat, 15 Dec 2001 01:16:07 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>t Subject: Re: vms 3.x questions, Message-ID: <3C1AEAA3.121F1EC5@videotron.ca>   Kevin Handy wrote:: > Try doing a 'sho sys' and look at the banner at the top.( > It should tell you what version it is.  K Nop. The person bootw off a 7.2 system disk, and mounts an older disk drive L and wants to know what VMS version is installed on that drive. SHOW SYS will3 give you the version of the system you booted from.l   ------------------------------   End of INFO-VAX 2001.695 ************************