1 INFO-VAX	Sun, 23 Feb 2003	Volume 2003 : Issue 106       Contents:P =?iso-8859-1?Q?Re:_Official_OpenVMS_name_for_the_Itanium=AE_releases_and_?=	=?is/ Re: Broadcast is not working if IP is specified ) Re: DECthreads question re PTHREAD_CONFIG ) Re: DECthreads question re PTHREAD_CONFIG  Re: Dumping LAT  Re: Dumping LAT  Re: Dumping LAT  Re: Dumping LAT  Re: Dumping LAT  Re: Dumping LAT  Re: Dumping LAT  Re: Encompass Membership Re: EVA Courses ?  Re: GCC for VMS  RE: GCC for VMS P Re: HSxx shadowing/striping vis a vis hardware RAID - was RE: Volumeset   acrossH Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyH Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyH Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyH Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyH Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyH Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopoly Shutdown and power off?  Re: Shutdown and power off?  Re: Shutdown and power off? P Re: TCPIP, LAN, pseudointerface, SET ROUTE, SET HOST, ISDN, DSL: puzzles galore! Re: The End of OpenVMS Re: The End of OpenVMS Re: The End of OpenVMS Re: The End of OpenVMS Re: The End of OpenVMS Re: The End of OpenVMSF Re: unix, was Re: IBM says AMD dead in 5yrs ... -- MS Monopoly vs. IBM
 URL change$ Re: VMSclusters vs. others' clusters$ RE: VMSclusters vs. others' clusters$ Re: VMSclusters vs. others' clusters  F ----------------------------------------------------------------------  % Date: Sun, 23 Feb 2003 12:14:48 +0100 " From: "Hans Vlems" <hvlems@iae.nl>Y Subject: =?iso-8859-1?Q?Re:_Official_OpenVMS_name_for_the_Itanium=AE_releases_and_?=	=?is 6 Message-ID: <b3aafb$1j9inh$1@ID-143435.news.dfncis.de>  @ "Sue Skonetski" <susan_skonetski@hotmail.com> schreef in bericht7 news:857e9e41.0302211053.4c43b5c8@posting.google.com...  > Dear Newsgroup,  > B > Please keep in mind that this has just come out and may not have > reached all parts of HP yet. > Warm Regards,  > Sue  >  [snip] >  > # > "hp OpenVMS Industry Standard 64"  >  > Informal Name @ > The following is the informal use of the name. We can use thisE > abbreviated name after we formally state the official name and have ' > subsequent references to the product.  >  > "OpenVMS I64"  >  [snip]   Sue,  D the comments on your post just prove that it is impossible to pleaseK everyone everytime, right? After years of neglect by Digital and Compaq, HP K comes up with a name for VMS that has an element of challenge (de l'audace, A toujours de l'audace)  in it and you get responses like this .... K Consider it the result of being ignored for such a long time. Children tend / to behave likewise in similar circumstances :-)    Hans   ------------------------------  % Date: Sun, 23 Feb 2003 12:19:30 +0100 " From: "Hans Vlems" <hvlems@iae.nl>8 Subject: Re: Broadcast is not working if IP is specified6 Message-ID: <b3aao5$1j3poh$1@ID-143435.news.dfncis.de>  1 "Upadhyaya" <ups@hotvoice.com> schreef in bericht ( news:mJe5a.99$eb5.33@news.cpqcorp.net... > Hi,  > J > I have written a sample application which will broadcast some info. If IF > specify INADDR_ANY at the time of binding, broadcast works. But if I specify 8 > the IP address of the machine broadcast will not work.  J The IP address 16.20.212.15 belongs to which machine: the machine on which& this program runs or another computer?   > What is causing the problem?' > Any solution  or workaround for this?   L Difficult to solve, unless you'd care to tell us about the IP address of theG machine you're running this program on, as well as the associated mask.    > 
 > Regards, > Upadhyaya  >  > Sample app > =========  > int  > main( void ) > { C >   /*  char buf[512];    */                  /* server data buffer  > */ > H >     int optval = 1;                     /* SO_REUSEADDR'S option value (on) > */ > > >     int sockfd;                         /* socket descriptor > */ > F >     unsigned int client_addrlen;        /* returned length of client socket > */> >                                         /* address structure > */L >     struct sockaddr_in client_addr;     /* client socket address structure > */L >     struct sockaddr_in serv_addr;       /* server socket address structure > */ > " >   char buf[512] = "hello123456"; >     /*0 >      * init broadcast socket address structure	 >      */  > 5 >     memset( &client_addr, 0, sizeof(client_addr) ); ' >     client_addr.sin_family = AF_INET; 5 >     client_addr.sin_port   = htons( SERV_PORTNUM ); 5 >     client_addr.sin_addr.s_addr = INADDR_BROADCAST;  >  >  >     /*/ >      * init server's socket address structure 	 >      */  > 1 >     memset( &serv_addr, 0, sizeof(serv_addr) ); * >     serv_addr.sin_family      = AF_INET;8 >     serv_addr.sin_port        = htons( SERV_PORTNUM );. >      serv_addr.sin_addr.s_addr = INADDR_ANY;@ > /*   serv_addr.sin_addr.s_addr = inet_addr("16.20.212.15"); */ >  >     /* >      * create a udp socket	 >      */  > : >     if ( (sockfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0 ) >         { . >         perror( "Failed to create socket" ); >         exit( EXIT_FAILURE );  >         }  >  >     /*A >      * bind server's internet address and port number to socket 	 >      */  >  >     if ( setsockopt(sockfd, J >                     SOL_SOCKET, SO_BROADCAST, &optval, sizeof(optval)) < 0 )  >         { 2 >         perror( "Failed to set socket option" ); >         exit( EXIT_FAILURE );  >         }  >  >     if ( bind(sockfd, H >               (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0 ) >         { , >         perror( "Failed to bind socket" ); >         exit( EXIT_FAILURE );  >         }  >  >     /*  >      * Send broadcast datagram	 >      */  >  > / >     printf( "Sending datagram on port: %d\n", ' >             ntohs(serv_addr.sin_port)  >           ); > 2 >         if ( sendto(sockfd, buf, sizeof(buf), 0,J >                 (struct sockaddr *) &client_addr, sizeof(client_addr)) < 0 )  >         { 9 >         perror( "Failed to write datagram to server" );  >         exit( EXIT_FAILURE );  >         }  >  >     /* >      * close udp socket 	 >      */  >  >     if ( close(sockfd) < 0 ) >         { - >         perror( "Failed to close socket" );  >         exit( EXIT_FAILURE );  >         }  >  >     exit( EXIT_SUCCESS );  > }  >  >  >    ------------------------------  % Date: Sun, 23 Feb 2003 06:06:16 +0100 2 From: martin@radiogaga.harz.de (Martin Vorlaender)2 Subject: Re: DECthreads question re PTHREAD_CONFIG; Message-ID: <3e5856c8.524144494f47414741@radiogaga.harz.de>   
 VAXman wrote: F > The pthread.h file contains a comment about defining an "environmentG > variable" called PTHREAD_CONFIG.  According to the comments, defining I > this to "METER=1" should cause DECthreads to record all synchronization  > operations.    > I > When I define it (DEFINE/SYSTEM/EXEC) and run a DECthreads application,  > I get: > 2 >   %PTHREAD_CONFIG keyword "METER=1" is not valid > G > Can this be used and, if so, how?  Where does it record the synchron-  > ization operations?   3 I find it in the "Guide to DECthreads", Appendix D:    <QUOTE> A During initialization of the DECthreads run-time environment, the C PTHREAD_CONFIG environment variable (on DIGITAL UNIX and Windows NT G systems) or logical symbol (on OpenVMS systems), if defined, is used to = set static options for the multithreaded program. You can set D PTHREAD_CONFIG to assist you in debugging a DECthreads application.   D As summarized in Table D-1, PTHREAD_CONFIG takes "major keywords" asB arguments. Use a "minor keyword" to specify a value for each major	 keyword.    / Major keyword   Minor keyword           Meaning   H  dump=          file-path               Path of DECthreads bugcheck file  K  meter=         condition               Meter condition variable operations >                 mutex                   Meter mutex operationsK                 stack                   Record thread greatest stack extent 0                 thread                  (Unused)F                 all                     Meter all available operations3                 none                    No metering   G  width=         bugcheck_output_width   Width of output from DECthreads 7                                         bugcheck output     F When setting PTHREAD_CONFIG, use a semicolon to separate major keyword= expressions and use a comma to separate minor keyword values.  </QUOTE>  E Disclaimer: I've never used it, so I have no idea whether it works...    cu,    Martin --  G So long, and thanks        | Martin Vorlaender  |  VMS & WNT programmer 4 for all the books...       | work: mv@pdv-systeme.deK In Memoriam Douglas Adams  |       http://www.pdv-systeme.de/users/martinv/ ;             1952-2001      | home: martin@radiogaga.harz.de    ------------------------------   Date: 23 Feb 2003 09:52:29 GMT- From: djweath@attglobal.net (Dave Weatherall) 2 Subject: Re: DECthreads question re PTHREAD_CONFIG5 Message-ID: <DTiotGxQ0bj6-pn2-jqWOjMDptPSR@localhost>   C On Sun, 23 Feb 2003 05:06:16 UTC, martin@radiogaga.harz.de (Martin   Vorlaender) wrote:  	 > <QUOTE> C > During initialization of the DECthreads run-time environment, the E > PTHREAD_CONFIG environment variable (on DIGITAL UNIX and Windows NT 
 > systems) or   !  logical symbol ------- OK which?   -  (on OpenVMS systems), if defined, is used to ? > set static options for the multithreaded program. You can set F > PTHREAD_CONFIG to assist you in debugging a DECthreads application.  > F > As summarized in Table D-1, PTHREAD_CONFIG takes "major keywords" asD > arguments. Use a "minor keyword" to specify a value for each major > keyword.   > 1 > Major keyword   Minor keyword           Meaning  > J >  dump=          file-path               Path of DECthreads bugcheck file > M >  meter=         condition               Meter condition variable operations @ >                 mutex                   Meter mutex operationsM >                 stack                   Record thread greatest stack extent 2 >                 thread                  (Unused)H >                 all                     Meter all available operations5 >                 none                    No metering  > I >  width=         bugcheck_output_width   Width of output from DECthreads 9 >                                         bugcheck output  >  > H > When setting PTHREAD_CONFIG, use a semicolon to separate major keyword? > expressions and use a comma to separate minor keyword values. 
 > </QUOTE> > G > Disclaimer: I've never used it, so I have no idea whether it works...    So that's :   - PTHREAD_CONFIG ="meter=mutex,stack;width=132"   	 or maybe    3 DEFINE PTHREAD_CONFIG "meter=mutex,stack;width=132"   @ The doc definitley seems to imply that 'meter=1' is not a valid  option.   ? At home can't check - must get around to setting up a hobbyist  D environment. I tend to favour the logical though. Definite room for ! improvement in the manual though.    --   Cheers - Dave.   ------------------------------  % Date: Sun, 23 Feb 2003 11:42:17 +0100 " From: "Hans Vlems" <hvlems@iae.nl> Subject: Re: Dumping LAT6 Message-ID: <b3a8ij$1jg7f1$1@ID-143435.news.dfncis.de>  0 "John N." <JNixon@cfl.rr.com> schreef in bericht6 news:lbQ5a.19610$Cv4.371124@twister.tampabay.rr.com...H > Our network guys are somewhat Unix and Windows literate, but have (nor want) L > much VMS knowledge.  They want to get rid of  LAT and go to all IP.  TheseK > are the same guys that took our many segmented LAN and "simplified" it by J > conbining everything on one Lan segment, thereby sacrificing redundancy.G > Now, if the one network segment glitches, my sattelite nodes CLUEXIT.  They > have agreed to fix this. > L > But now I have to justify keeping LAT.  Other than saying "better trackingK > of connection sources", or "better support for reverse operation ,such as G > printing", I need some real arguments.  The word "better" is somewhat 
 > subjective.  > J > Actually, I guess I should ask whether you guys think I should keep LAT, orI > am I a dinosaur.  Should we migrate to an all-IP network?  We primarily  use I > LAT for incoming dialup connections.  They make a request for a service  thatK > is offered by several VMS systems.  We also do a fair amount of printing, * > but we also do some IP printing as well. > J > Opinions are invited of course, but directions to appropriate literature may  > give my words more  validity.  > 	 > Thanks.  >  > K LAT is an advertising protocol and for a properly working link all you need K are two working machines: the host that offers a service and the client, as F well as a properly working LAN. This raises a few issues. One, LAT hasK fairly small timers built in and as such is usually the first protocol that L starts complaining. IP and DECnet van handle LAN problems that last a minuteI and still stand a fair chance to continue. LAT links are all dead by that J time. This is either a good thing (LAT signal LAN problems) or a bad thingD (lAT is too sensitive for our LAN), depending on how you look on it.J Two, IP needs a lot more supporting hardware to set up a link: ARP server,I DNS server, IP gateway, DHCP server. Not all of them are required but the H idea is that if you use, say, DNS then you'd better be sure that the DNS server is reachable.G Things that LAT do and IP (AFAIK) does not: service rating and multiple L hosts offering the same (fail over) service. IP does offer something similar6 to the latter but at the expense of confusing routers.I OTOH LAT is dead as a doornail. It is built in VMS as long as it does not G break and as soon as it takes more than the time to recompile for a new G version it may be dropped. Hardware that supports LAT is quite rare, so K eventually you need to move to, errr, an industry standard. Well you've got * one (VMS) why not take the other (IP)  <G>   hans   ------------------------------    Date: 23 Feb 2003 05:22:22 -0800( From: bob@instantwhip.com (Bob Ceculski) Subject: Re: Dumping LAT= Message-ID: <d7791aa1.0302230522.6a6cdaf7@posting.google.com>   g "John N." <JNixon@cfl.rr.com> wrote in message news:<lbQ5a.19610$Cv4.371124@twister.tampabay.rr.com>... N > Our network guys are somewhat Unix and Windows literate, but have (nor want)L > much VMS knowledge.  They want to get rid of  LAT and go to all IP.  TheseK > are the same guys that took our many segmented LAN and "simplified" it by J > conbining everything on one Lan segment, thereby sacrificing redundancy.M > Now, if the one network segment glitches, my sattelite nodes CLUEXIT.  They  > have agreed to fix this. > L > But now I have to justify keeping LAT.  Other than saying "better trackingK > of connection sources", or "better support for reverse operation ,such as G > printing", I need some real arguments.  The word "better" is somewhat 
 > subjective.  > M > Actually, I guess I should ask whether you guys think I should keep LAT, or M > am I a dinosaur.  Should we migrate to an all-IP network?  We primarily use N > LAT for incoming dialup connections.  They make a request for a service thatK > is offered by several VMS systems.  We also do a fair amount of printing, * > but we also do some IP printing as well. > N > Opinions are invited of course, but directions to appropriate literature may > give my words more  validity.  > 	 > Thanks.   @ why not go with decnet over IP and have the best of both worlds?   ------------------------------  % Date: Sun, 23 Feb 2003 06:20:05 -0700 $ From: Lee Y T Mah <lytmah@cha.ab.ca> Subject: Re: Dumping LAT) Message-ID: <3E58CA85.B7736A93@cha.ab.ca>   . I would recommend keeping LAT and also DECnet.= We have multiple VMS systems spread across several sites.  We ? have encountered situations where IP on a remote VMS 7.2 system A seized up.  Obviously, we could not telnet to the remote machine. @ DECnet would not work to it either.  From a dumb VT terminal, we< were able to connect to the system and do a shutdown/reboot.G (If no terminal was available, but you had a terminal server configured D for IP, you could telnet to the terminal server and then connect via? LAT to the misbehaving VMS machine.)  The reboot cleared up the  IP problem. D LAT would also provide an alternate path if somehow you accidentally> shut down IP while performing maintenance on the TCP/IP stack.H LAT will also let you back into a system if for some reason the shutdownB of a remote system aborts after DECnet and IP have been turned offE during the shutdown process.  LAT may let you back into the system to  resume the shutdown.@ From past experience, I can tell you that LAT has been the least0 troublesome of the three for us since VMS 5.5-2.     "John N." wrote:  N > Our network guys are somewhat Unix and Windows literate, but have (nor want)L > much VMS knowledge.  They want to get rid of  LAT and go to all IP.  TheseK > are the same guys that took our many segmented LAN and "simplified" it by J > conbining everything on one Lan segment, thereby sacrificing redundancy.M > Now, if the one network segment glitches, my sattelite nodes CLUEXIT.  They  > have agreed to fix this. > L > But now I have to justify keeping LAT.  Other than saying "better trackingK > of connection sources", or "better support for reverse operation ,such as G > printing", I need some real arguments.  The word "better" is somewhat 
 > subjective.  > M > Actually, I guess I should ask whether you guys think I should keep LAT, or M > am I a dinosaur.  Should we migrate to an all-IP network?  We primarily use N > LAT for incoming dialup connections.  They make a request for a service thatK > is offered by several VMS systems.  We also do a fair amount of printing, * > but we also do some IP printing as well. > N > Opinions are invited of course, but directions to appropriate literature may > give my words more  validity.  > 	 > Thanks.    -- Lee   5 L Y T Mah                    Email:  lytmah@cha.ab.ca  Capital Health Authority Information Systems, RAH CSC Edmonton, Alberta, CANADA    ------------------------------  % Date: Sun, 23 Feb 2003 08:50:43 -0500 2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: Dumping LATL Message-ID: <rdeininger-2302030850430001@user-uinj49v.dialup.mindspring.com>  = In article <d7791aa1.0302230522.6a6cdaf7@posting.google.com>, ) bob@instantwhip.com (Bob Ceculski) wrote:     A >why not go with decnet over IP and have the best of both worlds?   . LAT and DECnet are aimed at different targets.  H LAT is Local.  That's what the L stands for.  It can't operate over longJ distances due to timing restrictions.  But in it's local area, it requiresC minimal configuration and no network infrastructure except the bare F ethernet medium.  When all the new-fangled, configurable, programmableI network equipment goes into a coma, LAT is usually still working.  If you I have redundant hardware, a few extra lines in the startup files will make  sure LAT uses it.   G Classic DECnet requires somewhat more configuration.  Like LAT, it runs H without extra infrastructure, but only within its local area (geographicF AND address space area).  To get the wider reach we normally associateF with DECnet, you need DECnet routers, which can be VMS systems but areH usually external network boxes.    These days, DECnet routing is usuallyD an extra protocol running in the firmware/software of a conventionalF network router.  No matter how you handle routing, it takes some extraI work to configure it.  And routers that speak DECnet are becoming hard to  get and expensive.  J DECnet-over-TCP/IP "solves" the problem of long-distance routing.  All theD routing is done on the encapsulating IP packets.  You have even moreI configuration work to do, since you need full TCP/IP infrastructure, plus J DECnet configuration, plus a bit extra to enable DECnet-over-TCP/IP.  NoneF of this is difficult, and it works.  And least it works as well as theI underlying TCP/IP stuff, which the world seems to think is "good enough".     ; LAT, DECnet, and TCP/IP.  Serious VMS shops need all three.   C TCP/IP: industry-standard, lowest-common-denominator functionality, # interoperates with other platforms.   F DECnet: Easy-of-use and functionality of native, VMS-aware networking.  O LAT: Keeps working when the "industry-standard" infrastructure goes casters-up.    ------------------------------    Date: 23 Feb 2003 07:58:07 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: Dumping LAT3 Message-ID: <OAbmMJVIOlW8@eisner.encompasserve.org>   [ In article <b3a8ij$1jg7f1$1@ID-143435.news.dfncis.de>, "Hans Vlems" <hvlems@iae.nl> writes:   I > version it may be dropped. Hardware that supports LAT is quite rare, so   * There seems to be a steady supply on eBay.   ------------------------------  % Date: Sun, 23 Feb 2003 16:16:22 +0100 6 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> Subject: Re: Dumping LAT) Message-ID: <3E58E5C6.6030100@vajhoej.dk>    Bob Ceculski wrote: B > why not go with decnet over IP and have the best of both worlds?  1 And what does that have to do with the question ?   & I have never heard about LAT over IP !   Arne   ------------------------------  % Date: Sun, 23 Feb 2003 12:07:05 -0600  From: brandon@dalsemi.com  Subject: Re: Dumping LAT1 Message-ID: <03022312070557@dscis6-0.dalsemi.com>    >>> N >>> But now I have to justify keeping LAT.  Other than saying "better trackingM >>> of connection sources", or "better support for reverse operation ,such as I >>> printing", I need some real arguments.  The word "better" is somewhat  >>> subjective.  >>>   L My Network group proclaims LAT as a bad thing.  I guess ignorance is bliss. L They also talked bad about DELNI's and DEMPRE's and such.  10 years ago this3 was great technology - my how times have changed...   L However we made an effort to convert LAT to IP - when possible.  We replacedL VT terminals with Win/clients and used terminal emulation products instead.  This was done over the years.    >>> O >>> Actually, I guess I should ask whether you guys think I should keep LAT, or O >>> am I a dinosaur.  Should we migrate to an all-IP network?  We primarily use P >>> LAT for incoming dialup connections.  They make a request for a service thatM >>> is offered by several VMS systems.  We also do a fair amount of printing, , >>> but we also do some IP printing as well. >>>   N We still do LAT for one or two printers and terminals.  Less than 10 out of anO origional (guess) 200 or 300 terminals and printers.  Converted LAT print to IP  print.  No issues with that.  J I have found that creating TELNET Symbiont printers is eaiser, compare the difference for yourself:  )                                  LAT  /IP ) 1) Configure DECserver Port      YES  YES . 2) Configure LAT Port            YES  NO      * 3) Configure Print Queue         YES  YES ( 4) LAT or IP symbiont limits*     16  NO    N * I am not sure that this has been fixed or is a design issue.  However we hadC to limit 16 print queues to each symbiont.  Anyone comment on this?   N   For IP, I believe the TCPIP$TELNETSYM_STREAMS set to 1 resolves one queue to one symbiont.   + (LAT) Lose a symbiont lose one print queue. + (IP)  Lose a symbiont lose 16 print queues.     P >>> Opinions are invited of course, but directions to appropriate literature may! >>> give my words more  validity.  >>>   N My opinion is to dump LAT where appropriate.  Use this to create oppurtunitiesK to replace old DECservers (200 - 300 series) with newer ones that will both # boot IP and allow telenet sessions.        John Brandon VMS Systems Administrator  Dallas Semiconductor john.brandon@dalsemi.com 972.371.4172 wk  972.371.4003 fx    ------------------------------  % Date: Sun, 23 Feb 2003 11:13:50 +0100 " From: "Hans Vlems" <hvlems@iae.nl>! Subject: Re: Encompass Membership 6 Message-ID: <b3a6t1$1i2akv$1@ID-143435.news.dfncis.de>  > "Robert Lawrence" <robl@no-no-badpuppy.com> schreef in bericht7 news:eebf2e9b.0302222241.5f7078c6@posting.google.com... ? > How long should it take for Encompass to approve an Associate C > Membership?  I applied last week, but I have not heard from them.  > 	 > Thanks. B in my case: application mailed 5 Feb 2003 and confirmed 7 Feb 2003   ------------------------------  % Date: Sun, 23 Feb 2003 09:33:49 +0000  From: Roy Omond <Roy@Omond.net>  Subject: Re: EVA Courses ?( Message-ID: <3E58957D.7CB69EB@Omond.net>   John Travell wrote:   7 > "Craig Cooke" <ccooke@beta.dabs.com> wrote in message 1 > news:gKWPwoc2CHA.2316@juno.intranet.dabs.com...  > > Hi,  > > / > > The company I work for has recently aquired  > >  > > Two HSV110 Controllers0 > > 1 x Compaq SAN works Management Appliance II > >  > > 1 x SAN Switch 2/16-EL > > M > > Is anyone aware of any course being run by any company that would help us  > to; > > configure / commission this EVA equipment effectively ?  > >  > % > What part of the world are you in ? 9 > I know of a company in the UK that may be able to help.    "dabs.com" ... Bolton.  8 Friend of mine went on the course given by (then) Compaq6 in Manchester, so he (Craig) won't have far to travel.  	 Roy Omond  Blue Bubble Ltd.   ------------------------------  % Date: Sun, 23 Feb 2003 01:43:21 -0600 : From: Michael Rice <MichaelARice@knology.n-o--s-p-a-m.net> Subject: Re: GCC for VMS/ Message-ID: <v5gut0lcd15ac6@corp.supernews.com>    Brian Hechinger wrote:2 >>>A copy of the old PROGIS stuff is available at:3 >>>   ftp://ftp.tmk.com/vms-freeware/gcc-for-alpha/  >>H >>The last GCC version for Alpha, 2.8.0 was known to generate bad object >>code. Use caution. >  > M > if you are a Hobbyist user, you can freely use DEC C, which IMHO, kicks the  > snot out of GCC anyway.  ;)  >  > -brian  H The hobbyist licenses also include Ada, BASIC, C++, FORTRAN, and Pascal H - all of which are much better than GCC.  I think a condist is req'd to  get Ada, C++, and FORTRAN.  H However, getting a VMS 7.3-1 distribution seems to be pretty tough - at H least it has been for me - I don't know anyone with VMS, there are none L on eBay, and hp doesn't respond to my e-mails.  Guess I'm just stuck at 7.2.   Michael    ------------------------------  % Date: Sun, 23 Feb 2003 10:35:47 -0800 # From: "Tom Linden" <tom@kednos.com>  Subject: RE: GCC for VMS9 Message-ID: <CIEJLCMNHNNDLLOOGNJICEKLGKAA.tom@kednos.com>    >-----Original Message----- B >From: Michael Rice [mailto:MichaelARice@knology.n-o--s-p-a-m.net]+ >Sent: Saturday, February 22, 2003 11:43 PM  >To: Info-VAX@Mvb.Saic.Com >Subject: Re: GCC for VMS  >  >  >Brian Hechinger wrote: 3 >>>>A copy of the old PROGIS stuff is available at: 4 >>>>   ftp://ftp.tmk.com/vms-freeware/gcc-for-alpha/ >>> I >>>The last GCC version for Alpha, 2.8.0 was known to generate bad object  >>>code. Use caution.  >>   >>  ? >> if you are a Hobbyist user, you can freely use DEC C, which   >IMHO, kicks the >> snot out of GCC anyway.  ;) >>  	 >> -brian  > I >The hobbyist licenses also include Ada, BASIC, C++, FORTRAN, and Pascal  I >- all of which are much better than GCC.  I think a condist is req'd to   >get Ada, C++, and FORTRAN.   D PL/I is also available under the hobbyist licenses and may be freely5 downloaded from www.kednos.com both for VAX and Alpha    > I >However, getting a VMS 7.3-1 distribution seems to be pretty tough - at  I >least it has been for me - I don't know anyone with VMS, there are none  @ >on eBay, and hp doesn't respond to my e-mails.  Guess I'm just  >stuck at 7.2. >  >Michael >  >---' >Incoming mail is certified Virus Free. ; >Checked by AVG anti-virus system (http://www.grisoft.com). A >Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003  >  --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003   ------------------------------  % Date: Sun, 23 Feb 2003 08:59:34 +0100 ) From: Bart Zorn <B.Zorn@xs4all.nospam.nl> Y Subject: Re: HSxx shadowing/striping vis a vis hardware RAID - was RE: Volumeset   across 6 Message-ID: <3e587f66$0$49104$e4fe514c@news.xs4all.nl>   David J. Dachtera wrote: > Ryan Moore wrote:  > L >>There's a bigger disadvantge than this.  All of your disks are in one rack& >>connected to one set of controllers. >  >  > John and Ryan, > E > In my experience, the likelihood of such a failure is low enough to + > justify mitigating the negatives of HBVS.  >  > As I said, YMMV... > I > Also, do not the newer controller support "remote copy" so a mirror set . > can be propagated to second controller pair? >   F Yes, they do. But that remote copy disk cannot be accessed by OpenVMS G concurrently with the master, as can be done with HBVS. I believe that  0 is important when you have a multi site cluster.  	 Bart Zorn    ------------------------------  % Date: Sun, 23 Feb 2003 01:37:33 -0500 : From: Charles Shannon Hendrix <shannon@news.widomaker.com>Q Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopoly 7 Message-ID: <slrnb5gr1d.8oe.shannon@news.widomaker.com>   I In article <b355lb$h2o$1@shell.monmouth.com>, Bill/Carolyn Pechter wrote:   E > At least in Unix when XFree86 on my BSD box blows chunks I can just G > restart it... and the Solaris box is pretty solid since Sun's had 10+ G > years to get the bugs out of their X stuff for the CG6 graphics card.   E I have always marveled that graphics cards are incapable of resetting  themselves to a known state.  C Many X problems are actually situations where the graphics card has I gone nuts.  If the server could simply restart the card to a known state,  it could likely keep going.   E Of course, I also wonder why, after all these years, X cannot restart ) itself without losing client connections.    ------------------------------  % Date: Sun, 23 Feb 2003 01:25:21 -0500 : From: Charles Shannon Hendrix <shannon@news.widomaker.com>Q Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopoly 7 Message-ID: <slrnb5gqah.8oe.shannon@news.widomaker.com>   I In article <b35ool$42d$1@shell.monmouth.com>, Bill/Carolyn Pechter wrote:   B > Event Log seems to me to have it's root in VAX/VMS Error Logging
 > subsystems.    Where they text files?  : I hate how much stuff in Windows is binary.  Really sucks.   ------------------------------  % Date: Sun, 23 Feb 2003 01:40:39 -0500 : From: Charles Shannon Hendrix <shannon@news.widomaker.com>Q Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopoly 7 Message-ID: <slrnb5gr77.8oe.shannon@news.widomaker.com>   C In article <b356qd$38$9@bob.news.rcn.net>, jmfbahciv@aol.com wrote:   C > Yup.  Now notice what Gates funded in Apple, then apply a deja vu A > since he can't seem to stop his business practices.  Since he's @ > moved off to a sideline, it may not happen (but then I've been > accused of being too naive).  & Gates hasn't funded anything at Apple.   What are you talking about?   - All he did is invest, and not even that much.   6 Or, were you talking about the Mac group at Microsoft?   ------------------------------  ! Date: Sun, 23 Feb 03 12:33:25 GMT  From: jmfbahciv@aol.com Q Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopoly , Message-ID: <b3ahj1$r7a$16@bob.news.rcn.net>  / In article <3E57DEE8.CB2FC60C@vl.videotron.ca>, 4    JF Mezei <jfmezei.spamnot@vl.videotron.ca> wrote:  >"Dr. Richard E. Hawkins" wrote:I >> cost of production.  The U.S. price does both; the Canadians and other I >> freeloaders only cover the second (and it makes economic sense for the J >> producer to sell to such thieves when they cover marginal costs, but itF >> really amounts to a subsidy of Canadian buyers by the U.S. buyers). > G >Considering that the major pharmaceutical firsm all have major R&D and E >production facilities in Canada which were heavily subsidized by the < >governments in canada, your accusation is not well founded. > I >Fact is that the pharmaceuticals in the USA are taking advantage of the   USA's D >health care structure, knowing exactly just how much the insurance 	 companies  >are capable of paying.   C Uh...this one won't fly.  Complete drug coverage doesn't exist here @ in the US.  If my folks paid for drug insurance, the cap is $2K;B that happens to be less than the premium.  So they buy their drugs? out-of-pocket.  What's killing them is this idiot limitation by0@ the pharmacies of only dispensing a few weeks' worth of drugs at@ a time.  They can buy three months' worth for the price they pay  for one month plus a little bit.    6 > .. Note that this applies also to the many companiesB >headquartered outside the USA such as Bayer (germany) , Novartis 
 (switzerland)nJ >etc. Isn't Merck the one major remaining pharmaceutical that is based in  thee >USA ?   Abbott Labs.   /BAH  ' Subtract a hundred and four for e-mail.M   ------------------------------  % Date: Sun, 23 Feb 2003 14:36:34 -0000 D From: "Rupert Pigott" <roo@dark-try-removing-this-boong.demon.co.uk>Q Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyo2 Message-ID: <1046010994.926630@saucer.planet.gong>  K <jmfbahciv@aol.com> wrote in message news:b3ahj1$r7a$16@bob.news.rcn.net...l1 > In article <3E57DEE8.CB2FC60C@vl.videotron.ca>,.6 >    JF Mezei <jfmezei.spamnot@vl.videotron.ca> wrote:" > >"Dr. Richard E. Hawkins" wrote:K > >> cost of production.  The U.S. price does both; the Canadians and other K > >> freeloaders only cover the second (and it makes economic sense for theEL > >> producer to sell to such thieves when they cover marginal costs, but itH > >> really amounts to a subsidy of Canadian buyers by the U.S. buyers). > >eI > >Considering that the major pharmaceutical firsm all have major R&D and G > >production facilities in Canada which were heavily subsidized by theM> > >governments in canada, your accusation is not well founded. > > J > >Fact is that the pharmaceuticals in the USA are taking advantage of the > USA's,E > >health care structure, knowing exactly just how much the insurancec > companies- > >are capable of paying.m >oE > Uh...this one won't fly.  Complete drug coverage doesn't exist here-B > in the US.  If my folks paid for drug insurance, the cap is $2K;D > that happens to be less than the premium.  So they buy their drugsA > out-of-pocket.  What's killing them is this idiot limitation by B > the pharmacies of only dispensing a few weeks' worth of drugs atB > a time.  They can buy three months' worth for the price they pay" > for one month plus a little bit.  7 Talking as a son of a pair of general practitioners whos7 gave a toss about their patients... Restrictions on thef4 amount a patient holds at any given time is a *good*: thing. No it's not nanny state either. They can get mugged8 for them, they can have a funny spell & down a couple of( months worth at a time... etc etc etc...  5 Now obviously it depends on the drug and state of the 8 patient (lots of variables there), but as a general rule it is a good thing.a  7 I imagine most families have a Xanax addict these days,i7 even if they don't know it. Having seen first hand whatr7 that shit can do I'm of the opinion that for some drugs 5 it's a very good idea to restrict it to 3 days worth.,7 Xanax isn't the only insidious drug out there by a longi8 chalk either, there are lots of them which people appear8 to take like candy, ignoring the warnings and directions7 safe in the knowledge that they can blame their GPs for  the side-effects..  7 Of course restrictions on what the patient has in theirl6 possession do *not* preclude intelligent vending, such5 as selling them 3 months worth, but only releasing its in n day chunks at a time.   EOR.   Cheers,a Rupert   ------------------------------  % Date: Sun, 23 Feb 2003 17:43:23 +0000i/ From: cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley)oQ Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopoly ) Message-ID: <r71b3b.6q2.ln@teabag.cbhnet>c  J According to Rupert Pigott <roo@dark-try-removing-this-boong.demon.co.uk>:9 > I imagine most families have a Xanax addict these days, 9 > even if they don't know it. Having seen first hand what 9 > that shit can do I'm of the opinion that for some drugs 7 > it's a very good idea to restrict it to 3 days worth. 9 > Xanax isn't the only insidious drug out there by a long/: > chalk either, there are lots of them which people appear: > to take like candy, ignoring the warnings and directions9 > safe in the knowledge that they can blame their GPs for  > the side-effects.   ; IMHO anyone who feels that the withdrawal from the likes ofn< benzos is worse than the condition they're intended to treat: should never have been taking them in the first place.  It6 doesn't help when they go whinging to the likes of the8 professional "ban everything" brigade so that people who= really need those drugs can no longer get them.  I'm inclineda< to think that protecting someone from their own stupidity is= only viable if it doesn't impact on everyone else (the stupid.: person will simply move on to get themselves into problems= with something else in the meantime)  Three days' worth might = sound like a good idea until you think about how that affectsd( people with agoraphobia-induced panic...  ; BTW, since I'm feeling pedantic this afternoon, Xanax isn'ts; normally available for prescription in the UK, although itsr< potentially more nasty-withdrawal-prone cousin lorazepam is.   Chris. --  O "If the world was an orange it would be like much too small, y'know?" Neil, '84 A   Currently playing: Hawkwind - various Bridget Wishart-era stuffxN   http://www.chrishedley.com  My stuff, including genealogy, other things, etc   ------------------------------  % Date: Sun, 23 Feb 2003 13:23:21 +0100(" From: "Hans Vlems" <hvlems@iae.nl>  Subject: Shutdown and power off?6 Message-ID: <b3aefs$1itv2v$1@ID-143435.news.dfncis.de>  H The @SYS$SYSTEM:SHUTDOWN utility in AXP/VMS 7.3 lists, among others, theI power off option. However, when selected the Alpha does not power off but_9 returns to the >>> prompt. Hardware: Digital Server 5305.r+ Is there an SRM attribute that must be set?t   Hans   ------------------------------  % Date: Sun, 23 Feb 2003 08:31:22 -0500 2 From: rdeininger@mindspring.com (Robert Deininger)$ Subject: Re: Shutdown and power off?L Message-ID: <rdeininger-2302030831220001@user-uinj49v.dialup.mindspring.com>  C In article <b3aefs$1itv2v$1@ID-143435.news.dfncis.de>, "Hans Vlems"f <hvlems@iae.nl> wrote:  I >The @SYS$SYSTEM:SHUTDOWN utility in AXP/VMS 7.3 lists, among others, the J >power off option. However, when selected the Alpha does not power off but: >returns to the >>> prompt. Hardware: Digital Server 5305., >Is there an SRM attribute that must be set?  D "Power off" works if the hardware/firmware support it.  I think your system is too old for it.   @ The most recent 2 or 3 generations of alpha systems have a extraH management console processor.  This processor handles the power on/powerF off duties, whether initiated by a button press or by software.  TheseF systems usually have a console callback that lets the OS request power off.  G For example, the ES45 and DS25 have the RMC (Remote Management Console)HJ which controls the power.  Acronyms and functionality will differ somewhat on other platforms.o   ------------------------------  # Date: Sun, 23 Feb 2003 14:56:06 GMTE( From: "Mark E. Levy" <mlevy70@attbi.com>$ Subject: Re: Shutdown and power off?? Message-ID: <ai56a.226899$HN5.944474@rwcrnsc51.ops.asp.att.net>d  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in messagetF news:rdeininger-2302030831220001@user-uinj49v.dialup.mindspring.com...   ...i  F > "Power off" works if the hardware/firmware support it.  I think your > system is too old for it.   L Age alone is not the issue. The "old" 8xxx series VAXen could do this, IIRC.     -- Mark E. Levy" System Management Associates, Inc. Phone: 847-730-3193a Fax:      847-730-3194 Cell:      847-370-3071  Text:     melevy@vtext.com   ------------------------------  % Date: Sun, 23 Feb 2003 12:07:49 +0100u" From: "Hans Vlems" <hvlems@iae.nl>Y Subject: Re: TCPIP, LAN, pseudointerface, SET ROUTE, SET HOST, ISDN, DSL: puzzles galore! 6 Message-ID: <b3aa28$1k3bhc$1@ID-143435.news.dfncis.de>  K The TCPIP stack allows a choice in broadcast masks: all ones or all zeroes.a= The latter is no longer used. You entered an all zeroes mask:e   Interface: WE0?    IP_Addr: 213.252.154.202   NETWRK: 255.255.255.248   BRDCST:s 213.252.154.207     Interface: WEA0?    IP_Addr: 192.168.1.202     NETWRK: 255.255.255.248   BRDCST:  213.252.154.207l  B The WEA0 interface should have BRDCST set to 192.168.1.207, right?   Along the same lines:o   TCPIP> SET NOINTERFACE FFA0r  C TCPIP> SET INTERFACE FFA0 /HOST=KESTREL /NETWORK_MASK=255.255.0.0 - " _TCPIP> /BROADCAST_MASK=128.30.0.0  K In this example the bradcast mask should read 128.30.255.255, shouldn't it?t   Hans   ------------------------------  % Date: Sun, 23 Feb 2003 00:06:10 -0800i% From: Dean Woodward <deanw@rdrop.com>t Subject: Re: The End of OpenVMS ( Message-ID: <3E5880F2.4090800@rdrop.com>   Baby Peanut wrote:y > "Fred Kleinsorge" <kleinsorge@star-dot-zko-dot-dec-dot-com> wrote in message news:<3e54e126$1_2@hpb10302.boi.hp.com>... 
 >>Dear Troll,  > 8 > Troll? Talk about the pot that calls the kettle black.  ) Everyone, please stop feeding the trolls.    ------------------------------  # Date: Sun, 23 Feb 2003 12:05:56 GMTu# From: "John Smith" <a@nonymous.com>  Subject: Re: The End of OpenVMScH Message-ID: <EO26a.50380$UXa.32620@news02.bloor.is.net.cable.rogers.com>  > "Sue Skonetski" <susan_skonetski@hotmail.com> wrote in message7 news:857e9e41.0302222024.35b94106@posting.google.com...O > Greetings,0 > I am on vacation but just could not keep away.  1 You're a true believer, just like the rest of us.(    E > I do not really know the entire process on how names are chosen andmD > just knowing some of the work that went into this name I have come toE > the conclusion that I dont ever want to either.  It is tied up withR so@ > much legal stuff its amazing.  Legal departments in HP and the "other"cF > company are involved and all kinds of research has to be done, and a* > large amount of signatures are required.   Like the old joke goes: 0 What's a 100 lawyers at the bottom of the ocean?
 A good start.      > All the suggestionsoD > mentioned in this note were given by either the Ambassadors or theE > engineers or the customers, but there was always something (usuallyrB > legal).  A decision had to be made.  Everyone will still call it VMS,F > but there needed to be a way to differentiate between the platforms.  
 Official Name = The following is the official name for OpenVMS on the Itanium D platform. This is the full name of the product and to be used in any. title, header, and first mention in body text:  E "hp OpenVMS Industry Standard 64  but around the water cooler in PalojE Alto we call it "VMS - It's cool as an iced latte on a hot day"" (tm)u  B Did the lawyers ever think that the people at industrystandard.netC might sue HP for trademark infringement, or hold you up for ransom?t  E If hP or Hp or HP or hp felt compelled to change the name of OpenVMS,sB the best name for OpenVMS is hp OpenVMS. Period. Full stop. With a silent hp and Open.i        E > Maybe not the folks on this newsgroup but many customers think thatoD > VMS is for VAX, OpenVMS is for Alpha and I assume OpenVMS I64 will beE > thought of as the Intel box.  I am still surprised at the amount of-D > people that think the VMS vs OpenVMS, and I still get requests for- > presentations on VMS to OpenVMS migrations.e  D Just have some pre-printed Post-It notes made up that say '"OpenVMS"B on it. Send pads of these to people who ask for the presentations, with the instructions:    [begin VMS -> OpenVMS migration]B "'Put one of these Post-It notes on each location you see the word 'VMS'."t [end VMS -> OpenVMS migration]     >eB > Advertising - funny I have not seen an HPux advertisment either,A > Everyone I know would love to do a VMS advertisment and we havec gottenC > some excellent suggestions from the newsgroup and enginnering ande oursD > customers.  But if the company does not allow advertising for OS's we@ > can not, we work for HP, and that is their rule.  It is not an option	 > period.e  F Sheesh!! In reality o/s'es are the only differentiator you've got onceA Intel starts cranking out whitebox IA-64 systems or if Mikey Dell > starts to eat your lunch.Time to fire Carly and the BOD if notE advertising HP's own o/s'es is their game plan. All this does is handk> the market to Microsoft [Bill Gates could really use the extraE revenue, don't you think], Sun [Scott McNeally *really needs* anotheryD opening from HP so big he could drive a truck through it], and LinuxC [which gets almost all it's high profile publicity through IBM *TV*t ads].   A If HP won't allow o/s advertising then sell VMS to a company that D will. Better yet, spin VMS off as a separate company. Push stock out? to existing shareholders in a tax-free spinoff and then let VMS . Engineering go wild. Get new marketing people.  C BTW - there has been plenty of HP-UX advertising/marketing over thea( years. Much more than VMS has ever seen.   ------------------------------    Date: 23 Feb 2003 04:44:51 -0800" From: nma124@hotmail.com (steve_H) Subject: Re: The End of OpenVMSn= Message-ID: <8db3d6c8.0302230444.15e8fab7@posting.google.com>g  _ "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message news:<3E56EDEE.8417B05@fsi.net>...n > Phil Jamieson wrote: > > I > > > ...barring any miracles, like a balls-out, throttle to the firewallvK > > > marketing campaign, promises and commitments actually being kept, ...h > > > that sort of thing.n > > ( > > This got some mileage once for us... > > , > > www.softwarepartners.com/VMS_not_toy.pdf > > F > > If only H-P would run something like that in the Wall St. Journal. >  > Amen to that, Bro!      Can I run VMS on my PC ?  (x86).   ------------------------------  % Date: Sat, 22 Feb 2003 21:22:47 -0500a* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: The End of OpenVMSe2 Message-ID: <4Jydnd2hnrHgrcWjXTWcqA@metrocast.net>  5 "Nic Clews" <sendspamhere@127.0.0.1> wrote in messagen# news:3E576FDF.9CB6AF64@127.0.0.1...n > JF Mezei wrote:o   ...   K > > But with VMS moving to an unimpressive chip, its performance will truly- be@ > > lower than everyone else and this may start to matter a lot. >lI > Again, you need to take a closer look at the IPF. Check the pointers onoH > the HP website leading to the Intel areas, and read up what the chip'sE > features are. I can only assume from your statement that you're notsD > familiar with the technical features of the chip. If you are, then@ > justify  "unimpressive". Arguments about speed will not count.  L Since I'm quite familiar with the technical features, history, and projected" future of Itanic, I'll justify it:  H 1.  HP began designing Itanic in late 1988 (i.e., only a couple of yearsL after Alpha design began - and that's if you include the PRISM work as AlphaL design).  To have taken 13 years to create the first (disasterous, from justF about any viewpoint) shippable product, and another year to create theG second (at least usable) one, qualifies as unimpressive in the extreme.w  L 2.  Intel (perhaps including HP) is reported by the NYT to have already sunkI about $5 billion into Itanic.  For that kind of money (by comparison withPJ that expended on its competitors), the results are decidedly unimpressive.  L 3.  Leaving aside the Itanic the First debacle, Itanic2's performance, whileK competitive, is said by those who should know to depend far more heavily on G feedback-optimized compilation than its RISC (or IA32, and soon x86-64)uL competition.  This means that in real-world use, where such optimization mayG not be applied at all, or may be applied initially but not reapplied to-F adjust for each new generation, or even if applied may not achieve theL improvements it gives benchmarks because of the unpredictably varying natureL of user data sets, Itanic2 may be notably less impressive (regardless of theE degree to which you may or may not consider its optimized performance I impressive) in comparison to its less-optimization-sensitive competition.e  F 4.  Itanic2's performance, even if one considers it 'impressive' todayD (though why one would is not clear, since it trails substantially inF SPECint, especially compared with its IA32 brethren, and several other@ benchmarks - HP having been somewhat shy of exposing it to widerK comparisons - and even in the few benchmarks where it leads those leads areuI rather slim), seems destined to fall (i.e., to become unimpressive if youoB don't consider it so already) relative to its competition over theK foreseeable future, because unlike that competition we're going to be stuckhE with the same basic Itanic2 design until at least 2006 (i.e., throughoK Madison, and Madison II, and Montecito, though at least Montecito will moveeL to dual cores).  By contrast, EV7 already has the on-chip memory and MP glueI that Itanic so sorely lacks, POWER (which already include good on-chip MPtL support) is moving next year to SMT, on-chip memory controllers, and on-chipJ offload engines, SPARC (which also already includes on-chip MP support) isJ moving next year to multiple cores (it already has on-chip memory control)E and the year after that to SMT and other core enhancements, Hammer isiL appearing in two months with an EV7-like system architecture (though limitedH to 8-processor systems) and next year is said to be going to dual cores,H faster HT interconnect, and (if not later this year) chipsets capable ofH supporting larger systems, and, of course, Alpha would have leaped aheadH next year with EV8 had it been allowed to.  So the only hope seems to beH whatever the transplanted Alpha team may be brewing up for 2006 or 2007,J which no one is willing to talk about:  sounds like yet another "Just wait. for <the next big thing>!" refrain for Itanic.  H 5.  Three things that *are* impressive about Itanic are its appetite forI power, chip area, and fast cache.  So one can very reasonably assert thatiL its efficiency in these areas is unimpressive compared with its competition.  F 6.  Now, there are some useful (though it's not clear very innovative)K features in Itanic.  However, most of them would be equally applicable to aeD RISC platform, and were they applied there Itanic would be even more unimpressive by comparison.-  K 7.  And then there's Itanic's abysmal performance running IA32 code.  AlphaoG runs it faster under software emulation, and Hammer runs it faster than3 Intel's own IA32 products do.l  C That's just off the top of my head, but it seems an adequate start.g   - bill   ------------------------------    Date: 23 Feb 2003 07:46:28 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: The End of OpenVMSi3 Message-ID: <7ba4kDwsK3mu@eisner.encompasserve.org>s  m In article <b096a4ee.0302222209.5bb5b36@posting.google.com>, spamsink2001@yahoo.com (Alan E. Feldman) writes:sh > bill@cs.uofs.edu (Bill Gunshannon) wrote in message news:<b380fe$1j80pf$1@ID-135708.news.dfncis.de>... > [...]  > G >> Hardly.  Most military procurements are public information availableyF >> through a simple(?) FOI request.  Especially when you consider thatI >> they usually start as a public RFP published in the CBD.  I have never I >> been at a government site, including the pentagon where the brand nameuH >> of the system or the OS was classified information.  If DEC/COMPAQ/HPG >> really cared there is nothing stopping them from publishing numbers,tI >> customer names and types of systems being run on VMS.  They choose not  >> to and rest is history. > E > Maybe they simply don't want to piss off their big customers. Mayben4 > they're just protecting the customers' privacy(s). > A > Maybe they could. But maybe they have other incentives not to.    J Beyond anything classified, there is a tradition at US and allied militaryJ installation of not wanting to be perceived as a "blabbermouth".  A vendorK who assumed the attitude of "blabbermouth" would be informally frowned upono, regardless of lack of classification stamps.  H Correspondingly, a vendor approaching this sort of installation will tryG to "fit in" more than their competition.  In my limited experience, VMSlE sales force personnel to this sort of installation have a much longer I tenure in their assignment than typical tales of woe from this newsgroup.nH The business of understanding "their customer" is taken quite seriously,E and vendor representatives do _not_ want to appear as a blabbermouth.v  G That said, _within_ this customer community there is good communication F between customers, and _they_ know what projects are using what OS (to
 some extent).   C And sometimes there are government contractors who will mention VMS:* in public, such as for the JSTARS program.   ------------------------------  # Date: Sun, 23 Feb 2003 11:36:52 GMTd# From: "John Smith" <a@nonymous.com>l Subject: Re: The End of OpenVMS H Message-ID: <on26a.50300$UXa.17561@news02.bloor.is.net.cable.rogers.com>  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in messageeF news:rdeininger-2202032204000001@user-uinj4sp.dialup.mindspring.com... > In article= <_nN5a.47057$Zr%.41757@news01.bloor.is.net.cable.rogers.com>,a& > "John Smith" <a@nonymous.com> wrote: >o >oE > >I understand the particulars of the situation you find yourself in D > >regarding this specific installation, and you *have* said all you canP= > >. But there are MANY other non-military, non-intelligence,e non-'black'0C > >major users of VMS out there in the world whose stories parallelg the 5 > >one you alluded to that can be reported in detail.  > >  > >HP chooses not to.  >.A > HP can't use success stories from other companies without theirr permission.o       Does HP even ask? [rhetorical]    E Okay, how about 'an unnamed government agency, headquartered at [pick>< location] uses VMS to do [censored] in order to [spy/traffic3 analysis/censored/...etc..] on [censored]...etc....k  D But if VMS had a larger customer base, there'd be a larger potentialD pool of customers who would be willing to share success stories. SunD seems to have no end of customer stories they can trot out on-demand  F "Gee whiz...how do you get a larger OpenVMS customer base?", asked HP.  0 Why through marketing and advertising of course.  C In fact, it would probably be the *newest* customers who would havedE some of the better stories - ie. our Sun or NT environment sucked and>8 the minute we moved to OpenVMS our problems were solved.   ------------------------------  % Date: Sun, 23 Feb 2003 01:35:25 -0500f: From: Charles Shannon Hendrix <shannon@news.widomaker.com>O Subject: Re: unix, was Re: IBM says AMD dead in 5yrs ... -- MS Monopoly vs. IBMt7 Message-ID: <slrnb5gqtd.8oe.shannon@news.widomaker.com>a  9 In article <3e56de5c$1@news.ucsc.edu>, Eugene Miya wrote:i   [snip excellent response] L > You are more than welcome to stay with VMS (or EXEC*1100, or VMS, or ...).- > Just stay out of the way of the rest of us.I; > Remember this is Usenet not vmsnet (nor Bitnet nor Vnet).L  4 I wish more people would realize this kind of thing.  C Honestly, I think we should be amazed at how well UNIX systems have G remained close, despite some very concerted efforts to tear them apart.d   ------------------------------  % Date: Sun, 23 Feb 2003 10:47:07 -0500 0 From: "Island Computers" <dbturner@islandco.com> Subject: URL changeu/ Message-ID: <v5hr1tl86bn971@news.supernews.com>e  ? We have just changed over from www.islandco.com to www.hpaq.net ? Still great prices - a diifferent look and more reliable servert   -- Island Computers US Corporatione 2700 Gregory St. Suite 180 Savannah GA 31404  Toll Free 1-877 636 4332 Tel: USA 912 447 6622i Fax: USA 912 201 0402e http://www.islandco.comw dbturner@islandco.coml   Ask about our DS10L special!4 36 DS10L 600Mhz systems in rack for only $25,000 !!!   ------------------------------  % Date: Sun, 23 Feb 2003 13:18:49 -00007* From: "John Travell" <john@travell.uk.net>- Subject: Re: VMSclusters vs. others' clusters 6 Message-ID: <b3ahns$1k7r2k$1@ID-120847.news.dfncis.de>  5 "David Froble" <davef@tsoft-inc.com> wrote in messagew& news:3E57FC07.6080506@tsoft-inc.com... > Alan E. Feldman wrote: >n > > Hello fellow VMS-ers,2 > >1G > > Occasionally the topic of clusters comes up at work and I'd like to G > > say what makes VMSclusters so much better than others'. I know thatnF > > VMSclusters go back to the 80's and that VMSclusters are the best. > >0F > > But I know very little about what others' clusters really do. I'veH > > heard that Google has a cluster of thousands of Linux boxes. Is that) > > true? How would VMS make that better?C > >@E > > So what are the particular features of VMSclusters that sets them.G > > apart from the rest, esp. Unix and Windows systems? If readers give J > > good answers here I'll be well equipped to tell my coworkers about it. >w >SI > One basic concept of VMS clustering is that the 'logical' filesystem is  the coreA > of the cluster.  You can have 2 or more computers accessing they filesystem, atK > the same time, with the DLM providing lock granularity down to the recordv level.K >   I don't know much about IBM's Sysplex, but I don't know of any other soe called > cluster with this capability.o >.  J Is there any cluster environment other than VMS in which lots (potentiallyH hundreds) of nodes can all have a specific storage device (jbod, raid orH shadow set) directly mounted, rather than have mounting a virtual deviceH served out by the only node able to directly access the device ? Can anyL other cluster have the same file open on multiple nodes with different nodesI concurrently writing different records (e.g. database updates) all on the  same directly mounted disk ?J On VMS this is relatively trivial, I suspect that on most other 'clusters' this is essentially impossible.   K (potentially hundreds) - about ten years ago one of Digital's customers was K running a cluster with about 150 members, even though this is well over thetF number that is 'officially supported', it worked fine. The 'about' wasJ because there were always a of the many VAXstations down for one reason orK another, and it was quite rare for them all to be running at the same time.y   -- John Travell  VMS crashdump expertise for hire john@travell.uk.nete http://www.travell.uk.net/   ------------------------------  % Date: Sun, 23 Feb 2003 08:49:01 -0500 ' From: "Main, Kerry" <Kerry.Main@hp.com>u- Subject: RE: VMSclusters vs. others' clusterseT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF402660DAF@kaoexc01.americas.cpqcorp.net>   Alan,e   Re: cluster background.l  E One quick note to add to the other comments - while OpenVMS certainly-E supports numerous cluster interconnects, recent versions also supportvD load balancing of cluster traffic - something which I do not believeH (can someone confirm?) many other cluster offerings can do i.e. they allH run on one interconnect and will fail-over if there is an issue with the  designated primary interconnect.  F Hence, one can use multiple cheap NIC's as cluster interconnects (loadF balanced across different PCI buses for improved throughput) and if itH were ever needed, simply add a few more (different PCI buses perhaps) asG your cluster grows. With the relatively new SCACP utility, you can also E add weighting factors to each of these cluster interconnects as well.   6 A few additional cluster references for consideration:  : State of clustering white paper from Illuminate (Aug 2002)H <http://www.tru64unix.compaq.com/unix/illuminata_dt_unix_research_note.p df>=20  ; Shared everything vs. shared nothing: (pretty good article)VH <http://archive.infoworld.com/articles/fe/xml/01/12/17/011217feclustertc a.xml>   Parallel Sysplex clustering:H <http://www-1.ibm.com/servers/eserver/zseries/library/techpapers/pdf/gf2
 25015.pdf>  ) Also, a good general book on clusters is:.   "In Search of Clusters"  Greg Pfister 2nd Edition 
 Prentice Hallg ISBN 0-13-899709-8   Regards   
 Kerry Main Senior Consultant( Hewlett-Packard (Canada) Co.! Consulting & Integration Services- Voice: 613-592-46600 Fax   : 613-591-4477 Email: kerryDOTmain@hpDOTcom-     (remove the DOT's and replace with "."'s)Z OpenVMS DCL - the original .COMR    
 Kerry Main Solutions Architecth Hewlett-Packard (Canada) Co.! Consulting & Integration Services$ Voice: 613-592-4660. Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----8 From: Alan E. Feldman [mailto:spamsink2001@yahoo.com]=20 Sent: February 21, 2003 8:29 PMo To: Info-VAX@Mvb.Saic.Coma) Subject: VMSclusters vs. others' clustersi     Hello fellow VMS-ers,o  G Occasionally the topic of clusters comes up at work and I'd like to say,? what makes VMSclusters so much better than others'. I know that B VMSclusters go back to the 80's and that VMSclusters are the best.  H But I know very little about what others' clusters really do. I've heardH that Google has a cluster of thousands of Linux boxes. Is that true? How would VMS make that better?a  G So what are the particular features of VMSclusters that sets them apart B from the rest, esp. Unix and Windows systems? If readers give goodA answers here I'll be well equipped to tell my coworkers about it.y   Thanks.i   Alan E. Feldman.   ------------------------------  % Date: Sun, 23 Feb 2003 08:53:14 -0500 * From: "Bill Todd" <billtodd@metrocast.net>- Subject: Re: VMSclusters vs. others' clusters 2 Message-ID: <n7GdnbnKTLrMT8WjXTWcog@metrocast.net>  5 "John Travell" <john@travell.uk.net> wrote in message 0 news:b3ahns$1k7r2k$1@ID-120847.news.dfncis.de...   ...r  L > Is there any cluster environment other than VMS in which lots (potentiallyJ > hundreds) of nodes can all have a specific storage device (jbod, raid orJ > shadow set) directly mounted, rather than have mounting a virtual deviceJ > served out by the only node able to directly access the device ? Can anyH > other cluster have the same file open on multiple nodes with different nodesrK > concurrently writing different records (e.g. database updates) all on the- > same directly mounted disk ?   Yes - in fact, quite a few.n   Tru64, as of recently.  G A bunch of cluster-style file system products, some of which can run inoJ multiple environments:  SANergy (IBM), Centravision (ADIC), Celerra (EMC),K Unity (Avid), GFS (open-source project), SANpoint (Veritas), and at least ao1 couple more that I can't remember at this moment.n  J Clustered AIX systems (at least I think they now support directly-accessedF devices rather than virtual devices served much like VMS's MSCP-servedJ devices).  Parallel Sysplex (ditto, and while it doesn't support 'hundredsJ of nodes each of the nodes that it does support can be substantial).  Even" Sun's new cluster file system may.  E Some of the above use a central (possibly itself clustered) server toaK distribute and manage metadata, but they all allow concurrent direct accesso/ to user data on the device from multiple nodes.    - bill   ------------------------------   End of INFO-VAX 2003.106 ************************ine, it may not happen (but then I've beensfer completed.1
 <<< CDUP1 >>> 250 Connected to /disk$misc/decus/vmslt97a.c	 <<< PWD ; >>> 257 "/disk$misc/decus/vmslt97a" is current directory.t <<< CWD provost 9 >>> 250 Connected to /disk$misc/decus/vmslt97a/provost.<	 <<< PWD C >>> 257 "/disk$misc/decus/vmslt97a/provost" is current directory.
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,13,109)>
 <<< LIST >>> 150 List started.  >>> 226 Transfer completed. 
 <<< CDUP1 >>> 250 Connected to /disk$misc/decus/vmslt97a. 	 <<< PWD ; >>> 257 "/disk$misc/decus/vmslt97a" is current directory.  <<< CWD pine6 >>> 250 Connected to /disk$misc/decus/vmslt97a/pine.	 <<< PWD @ >>> 257 "/disk$misc/decus/vmslt97a/pine" is current directory.
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,13,110)<
 <<< LIST >>> 150 List started.d >>> 226 Transfer completed.1
 <<< CDUP1 >>> 250 Connected to /disk$misc/decus/vmslt97a.c	 <<< PWD ; >>> 257 "/disk$misc/decus/vmslt97a" is current directory.  <<< CWD perl6 >>> 250 Connected to /disk$misc/decus/vmslt97a/perl.	 <<< PWDW@ >>> 257 "/disk$misc/decus/vmslt97a/perl" is current directory.
 <<< PASVA >>> 227 Entering passive mode; use PORT (198,151,12,104,13,111)<
 <<< LIST >>> 150 List started.d >>> 226 Transfer completed.1
 <<< CDUP1 >>> 250 Connected to /disk$misc/decus/vmslt97a.c	 <<< PWD ; >>> 257 "/disk$misc/decus/vmslt97a" is current directory.c <<< CWD pdp11>7 >>> 250 Connected to /disk$misc/de