1 INFO-VAX	Thu, 01 Jun 2006	Volume 2006 : Issue 303       Contents: Compiling Problem with LibCurl" Re: Compiling Problem with LibCurl" Re: Compiling Problem with LibCurl" Re: Compiling Problem with LibCurl Re: DCL: IF and .AND. logic  Re: DCL: IF and .AND. logic & Re: Error installing VMS732_PCSI-V0300" Re: Fixing a Corrupt PCSI Database" Re: Fixing a Corrupt PCSI Database3 FOR SALE! OpenVMS v7.1 Full Documentation Hard Copy A Re: I knows it's unsupported, but does current VMS run on ZX2000? / Re: Network Card for an AlphaServer 1000 4/233. 2 Re: OT: Sun release 8-socket/16-way SMP X64 server* Sun axes 5000 jobs but gains market share. Re: Unix runs faster, maybe  Re: Unix runs faster, maybe  Re: Unix runs faster, maybe  Re: Unix runs faster, maybe  Re: Unix runs faster, maybe  Re: Unix runs faster, maybe  Re: Unix runs faster, maybe D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)  F ----------------------------------------------------------------------   Date: 1 Jun 2006 03:38:36 -0700 , From: "Francesco Donini" <fdonini@gmail.com>' Subject: Compiling Problem with LibCurl B Message-ID: <1149158316.845953.315850@f6g2000cwb.googlegroups.com>  
 Dear List,G I am a newbie of OpenVMS and im trying to compiling a short c (using of & course libcurl) application under VMS.@ Just to test if i was able to compile the application i tried to compile the simple.c example:    #include <stdio.h> #include <curl/curl.h> int main(void) {  CURL *curl; 
 CURLcode res;    curl =3D curl_easy_init();
 if(curl) {4 curl_easy_setopt(curl, CURLOPT_URL, "curl.haxx.se");  res =3D curl_easy_perform(curl);   /* always cleanup */ curl_easy_cleanup(curl); } 	 return 0;  }    Now i show what i've done:  - - unzipped the lib VMS Alpha 7.15.2 (from url I http://curl.haxx.se/latest.cgi?curl=3Dvms-axp-zip) on my src folder where  there is simple.c 0 - compiled simple.c with the following directive  ' cc curllib.olb_openssl/LIBRARY+simple.c    - then i get this message:  K %CC-F-OPENIN, error opening =C3=A6z=C3=B4=C2=A1=C3=BF=C3=BF=C3=BF=C3=BF=C3=  =A5=C3=B3=C3=BD=C2=BC       G @GEM_DEBUG4+t=C3=A7k0,@=C3=A6z0O0,=C3=8AH7GVERSION=E2=89=A5=C2=B4=C3=BB L =E2=89=A5=C3=A0=C3=A3=C3=B3=E2=89=A5=C3=98!=C3=BB=E2=89=A5 =C3=A6=E2=89=A50=7 =C3=A8=C3=B3=E2=89=A5=C3=98=C3=A4=C3=B3=E2=89=A5VERSION L -LBR-W-TYPMISMCH, =E2=94=8C=E2=90=8B=E2=90=89=E2=8E=BC=E2=96=92=E2=8E=BC=E2=+ =89=A4 =E2=94=9C=E2=89=A4=E2=8E=BB=E2=90=8A H =E2=94=94=E2=90=8B=E2=8E=BD=E2=94=94=E2=96=92=E2=94=9C=E2=90=8C=E2=90=A4  = I looked around in Internet but i don't know how to solve the  compilation problem.F Im thinking that should exist a special directive to compile with .olb! library o special way to do this.  Your help will be appreciated. Thanks in advance.   --=20  Francesco Donini   ------------------------------  * Date: Thu, 1 Jun 2006 11:06:12 +0000 (UTC) From: david20@alpha2.mdx.ac.uk+ Subject: Re: Compiling Problem with LibCurl ) Message-ID: <e5mhn4$3m9$1@news.mdx.ac.uk>   q In article <1149158316.845953.315850@f6g2000cwb.googlegroups.com>, "Francesco Donini" <fdonini@gmail.com> writes:  >Dear List, H >I am a newbie of OpenVMS and im trying to compiling a short c (using of' >course libcurl) application under VMS. A >Just to test if i was able to compile the application i tried to  >compile the simple.c example: >  >#include <stdio.h>  >#include <curl/curl.h>  >int main(void)  >{ >CURL *curl; >CURLcode res; >  >curl =3D curl_easy_init();  >if(curl) { 5 >curl_easy_setopt(curl, CURLOPT_URL, "curl.haxx.se"); ! >res =3D curl_easy_perform(curl);  >  >/* always cleanup */  >curl_easy_cleanup(curl);  >}
 >return 0; >} >  >Now i show what i've done:  > . >- unzipped the lib VMS Alpha 7.15.2 (from urlJ >http://curl.haxx.se/latest.cgi?curl=3Dvms-axp-zip) on my src folder where >there is simple.c1 >- compiled simple.c with the following directive  > ( >cc curllib.olb_openssl/LIBRARY+simple.c >  >- then i get this message:  > L >%CC-F-OPENIN, error opening =C3=A6z=C3=B4=C2=A1=C3=BF=C3=BF=C3=BF=C3=BF=C3= >=A5=C3=B3=C3=BD=C2=BC >  >  > H >@GEM_DEBUG4+t=C3=A7k0,@=C3=A6z0O0,=C3=8AH7GVERSION=E2=89=A5=C2=B4=C3=BBM >=E2=89=A5=C3=A0=C3=A3=C3=B3=E2=89=A5=C3=98!=C3=BB=E2=89=A5 =C3=A6=E2=89=A50= 8 >=C3=A8=C3=B3=E2=89=A5=C3=98=C3=A4=C3=B3=E2=89=A5VERSIONM >-LBR-W-TYPMISMCH, =E2=94=8C=E2=90=8B=E2=90=89=E2=8E=BC=E2=96=92=E2=8E=BC=E2= , >=89=A4 =E2=94=9C=E2=89=A4=E2=8E=BB=E2=90=8AI >=E2=94=94=E2=90=8B=E2=8E=BD=E2=94=94=E2=96=92=E2=94=9C=E2=90=8C=E2=90=A4  > > >I looked around in Internet but i don't know how to solve the >compilation problem. G >Im thinking that should exist a special directive to compile with .olb " >library o special way to do this. >Your help will be appreciated.  >Thanks in advance.  >   O Creating an executable on VMS is a two stage process. Compiling the source into N object files (.obj files) and then linking these files together with libraries to create executables.  E The CC command only does the first step. .olb files are library files G containing object files and hence shouldn't be included on the CC line. E The LINK command is then used to link the object files and libraries.     ) What you probably need is something like     cc simple.c   $ which will produce a simple.obj file   and then  ' link simple+curllib.olb_openssl/LIBRARY     & which should produce a simple.exe file    
 David Webb Security team leader CCSS Middlesex University     >--=20 >Francesco Donini  >    ------------------------------   Date: 1 Jun 2006 05:14:02 -0700 , From: "Francesco Donini" <fdonini@gmail.com>+ Subject: Re: Compiling Problem with LibCurl C Message-ID: <1149164042.421764.177420@i40g2000cwc.googlegroups.com>   $ david20@alpha2.mdx.ac.uk ha scritto:Q > Creating an executable on VMS is a two stage process. Compiling the source into P > object files (.obj files) and then linking these files together with libraries > to create executables. > G > The CC command only does the first step. .olb files are library files I > containing object files and hence shouldn't be included on the CC line. G > The LINK command is then used to link the object files and libraries.  >  > * > What you probably need is something like > 
 > cc simple.c    Yes u are right A I tried before what u are telling me but i get only error message  compiling the source. ? The compiler can't resolve the include files and all the others . function because doesn't know where find them.@ So i don't how i can produce the .obj file if the compiler don't compile.   > & > which will produce a simple.obj file > 
 > and then > ) > link simple+curllib.olb_openssl/LIBRARY  >  > ( > which should produce a simple.exe file >  >  > David Webb > Security team leader > CCSS > Middlesex University >  >  > >--=20 > >Francesco Donini  > >    ------------------------------  * Date: Thu, 1 Jun 2006 13:12:02 +0000 (UTC) From: david20@alpha2.mdx.ac.uk+ Subject: Re: Compiling Problem with LibCurl ) Message-ID: <e5mp32$63s$1@news.mdx.ac.uk>   r In article <1149164042.421764.177420@i40g2000cwc.googlegroups.com>, "Francesco Donini" <fdonini@gmail.com> writes:% >david20@alpha2.mdx.ac.uk ha scritto: R >> Creating an executable on VMS is a two stage process. Compiling the source intoQ >> object files (.obj files) and then linking these files together with libraries  >> to create executables.  >>H >> The CC command only does the first step. .olb files are library filesJ >> containing object files and hence shouldn't be included on the CC line.H >> The LINK command is then used to link the object files and libraries. >> >>+ >> What you probably need is something like  >> >> cc simple.c >  >Yes u are rightB >I tried before what u are telling me but i get only error message >compiling the source.@ >The compiler can't resolve the include files and all the others/ >function because doesn't know where find them. A >So i don't how i can produce the .obj file if the compiler don't 	 >compile.  > 6 I'd guess that the problem is finding the curl.h file    #include <curl/curl.h>    K One solution would be to to define a logical curl pointing at the directory    eg  % If the curl.h file was in a directory    user1:[david.curl]   then   define curl user1:[david.curl]   then   cc simple.c     F Another solution would be to use the /include qualifier on the cc line   eg  ' cc/include=user1:[david.curl]  simple.c       
 David Webb Security team leader CCSS Middlesex University     >>' >> which will produce a simple.obj file  >> >> and then  >>* >> link simple+curllib.olb_openssl/LIBRARY >> >>) >> which should produce a simple.exe file  >> >>
 >> David Webb  >> Security team leader  >> CCSS  >> Middlesex University  >>   >>  	 >> >--=20  >> >Francesco Donini >> > >    ------------------------------  % Date: Thu, 01 Jun 2006 11:43:13 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> $ Subject: Re: DCL: IF and .AND. logic; Message-ID: <7c021$447eb6b2$50db5015$10251@news.hispeed.ch>    Dave Froble wrote: > Doug Phillips wrote: >  >> Dave Froble wrote:  >> >>> Michael Unger wrote: >>> / >>>> On 2006-05-30 18:47, "Hoff Hoffman" wrote:  >>>> >>>>> [...]  >>>>> H >>>>>    Run-time computed goto operations -- one of the reasons why it  >>>>> would J >>>>> be comparatively "fun" to write a compiler for DCL -- are available: >>>>>   >>>>>    $ GOTO LABEL_'severity' >>>>H >>>> I don't like "GOTO" at all -- it is much simpler to "go back" using> >>>> "GOSUB" and "RETURN" or "CALL" and "EXIT" (or even "EXIT  >>>> <status-value>".  >>>> >>>>> [...]  >>>> >>>> Michael >>>>L >>> And next we'll have someone wanting to get rid of the BRANCH instruction >>> in assembler.  >>>  >>E >> Uh Oh. I smell another religious war, and here I was just about to  >> GOSUB lunch ;-) >> > / >  From which I assume you plan to RETURN.  :-)    LOL   
 $ gosub lunch 4 $ if $status .eq. too_much_spaghetti then goto sleep   > G > The point is, any instruction can be misused.  Don't blame GOTO when  I > some idiot uses it to write practically unreadable code.  If there was  0 > no GOTO, he'd find some other way to screw up. > G > I knew a guy that was so intent on writing 'structured' code that he  0 > used GOSUB to GOTO the exit part of a program. >   A I've seen that, but also instances where such coding has lead to  H recursive calls causing the program to blow up (not necessarily in DCL).  G In DCL, I personally prefer CALL to GOSUB, as you have to declare your   subroutine formally with   $label: SUBROUTINE   ...    $ENDSUBROUTINE  @ Compare the results of HELP CALL EXAMPLE and HELP GOSUB EXAMPLE.  G > And anybody that has written any assembler code understands that the  A > various forms of BRANCH is how it's all done regardless of HLL   > implementations. >    True.    ------------------------------  % Date: Thu, 01 Jun 2006 17:46:37 +0200 3 From: Michael Unger <spam.to.unger@spamgourmet.com> $ Subject: Re: DCL: IF and .AND. logic, Message-ID: <4e8gjuF1dbpvoU1@individual.net>  ( On 2006-06-01 11:43, "Paul Sture" wrote:   > [...]  > I > In DCL, I personally prefer CALL to GOSUB, as you have to declare your  +                        ^^^^^^^^^^^^^^^^^^^^  > subroutine formally with >  > $label: SUBROUTINE >  > .... >  > $ENDSUBROUTINE > B > Compare the results of HELP CALL EXAMPLE and HELP GOSUB EXAMPLE. >  > [...]   E In addition to the formal declaration needed for a subroutine ("EXIT" F being an implicite "ENDSUBROUTINE") you get a new procedure level when@ it gets executed -- making it easier to manage the "locality" ofC symbols. (If you have more of them than just a few hundreds ... ;-)    Michael    --  ; Real names enhance the probability of getting real answers. 5 My e-mail account at DECUS Munich is no longer valid.    ------------------------------  % Date: Wed, 31 May 2006 16:53:37 +0200 3 From: "Gorazd Kikelj" <gorazd.kikelj@nospam.hp.com> / Subject: Re: Error installing VMS732_PCSI-V0300 , Message-ID: <447dadf1$1@usenet01.boi.hp.com>  / "Bobby" <colemanr7@yahoo.com> wrote in message  = news:1149082460.915184.322630@h76g2000cwa.googlegroups.com... H >>    Does this box have its DCLTABLES.EXE in SYS$SPECIFIC:[SYSLIB]?  OrG >> are there any PCSI*.EXE images in SYS$SPECIFIC:[SYSEXE] or [SYSLIB]?  > B > Before PCSI-V0300:  There were three version of DCLTABLES.EXE in= > SYS$SPECIFIC:[SYSLIB] and there were no PCSI*.EXE images in 1 > SYS$SPECIFIC:[SYSEXE] or SYS$SPECIFIC:[SYSLIB].  >   L Check DCLTABLES in SYS$COMMON:[SYSLIB]. This file should be updated by pcsi." If you have it there, test it with  * $SET COMM/TAB=SYS$COMMON:[SYSLIB]DCLTABLES  A If then PRODUCT command work ok, remove spurius DCLTABLES.EXE in   SYS$SPECIFIC area. They shoul not be there.  
 Best, Gorazd     ------------------------------  # Date: Thu, 01 Jun 2006 13:51:08 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>+ Subject: Re: Fixing a Corrupt PCSI Database 1 Message-ID: <ghCfg.1351$Ge5.714@news.cpqcorp.net>    Dave Froble wrote: > JF Mezei wrote:  >> Charlie Hammond wrote: C >>> How/why is this easier than just repeating the PRODUCT INSTALL   >>> operation? ... " > Gotta agree with JF on this one.  G    So folks here are seriously proposing manually moving files around?  0 (Shudder.)  That's why installation tools exist.  F    Please use the PRODUCT REGISTER commands to recreate the database, @ that's the safest way.  PRODUCT *REGISTER*, not PRODUCT INSTALL.  E    Barring a transactional file system and/or barring occurrences of  I perfect code, these sorts of problems can unfortunately arise -- keeping  B current on ECOs, such as those for PCSI, can help reduce exposure.   ------------------------------  # Date: Thu, 01 Jun 2006 14:03:31 GMT 3 From: hammond@not@peek.ssr.hp.com (Charlie Hammond) + Subject: Re: Fixing a Corrupt PCSI Database 2 Message-ID: <TsCfg.1352$Ce5.1350@news.cpqcorp.net>  ` In article <ghCfg.1351$Ge5.714@news.cpqcorp.net>, Hoff Hoffman <hoff-remove-this@hp.com> writes: >Dave Froble wrote:  >> JF Mezei wrote: >>> Charlie Hammond wrote:D >>>> How/why is this easier than just repeating the PRODUCT INSTALL  >>>> operation?  >... ..  H >   So folks here are seriously proposing manually moving files around? 1 >(Shudder.)  That's why installation tools exist.  > G >   Please use the PRODUCT REGISTER commands to recreate the database,  A >that's the safest way.  PRODUCT *REGISTER*, not PRODUCT INSTALL.                      1 Hoff is right here (among other places <grin>...)   A *IF* you need to move files -- PRODUCT INSTALL is much safer than @ roll-your-own copying -- and will be much more likely to get the PRODUCT DATABASE fixed.   A *IF* your products are working and only the PRODUCT DATABASE is a A problem, then PRODUCT REGISTER is the way to go.  Either with the 6 original kit (preferred, if kit available) or by using$ SYS$UPDATE:PCSI$REGISTER_PRODUCT.COM   --  J       Charlie Hammond -- Hewlett-Packard Company -- Ft Lauderdale  FL  USAF           (hammond@not@peek.ssr.hp.com -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------   Date: 1 Jun 2006 09:45:20 -0700  From: alexcn@writeme.com< Subject: FOR SALE! OpenVMS v7.1 Full Documentation Hard CopyC Message-ID: <1149180320.906829.219420@y43g2000cwc.googlegroups.com>   @ New item #9735255143 - OpenVMS v7.1 Full Documentation Hard Copy  ? http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&item=9735255143    ------------------------------  % Date: Wed, 31 May 2006 16:22:28 -0400 * From: "FredK" <fred.nospam@nospam.dec.com>J Subject: Re: I knows it's unsupported, but does current VMS run on ZX2000?* Message-ID: <447dfb06@usenet01.boi.hp.com>  : "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message& news:447DF472.CC62BD96@teksavvy.com... > Hoff Hoffman wrote: I > >    As for unsupported HP Itanium-based systems, the zx2000 and zx6000 J > > workstations and the older McKinley-class Integrity systems within theH > > supported Integrity lines should -- SHOULD -- boot Hobbyist OpenVMS. > F > VMS today still runs on the all mighty microvax II even though thereJ > have been a number of new generation VAXes since that time. I guess thatE > once the support files were added for the MVII, they didn't need to  > change over the years. > J > Will the same be said about IA64, or will the evolution of the compilersJ > that are more closely tied to the chip mean that at one point, a versionH > of VMS compiled to support a new generation of those IA64 things would5 > no longer run properly on a McKinley class system ?   J Never say never.  There are Alpha systems that will not "easily" boot V8.3 or even E V7.3 - because they no longer have the resources - for example memory 	 capacity.   ' But there are no plans to break things.   J But let's say compiler breakthroughs increase performance by 2 or 3x - but would K cause the zx2000 to not work - I think you can guess what the outcome would  be... & since it was never a supported system.   ------------------------------   Date: 1 Jun 2006 03:31:34 -0700  From: etmsreec@yahoo.co.uk8 Subject: Re: Network Card for an AlphaServer 1000 4/233.C Message-ID: <1149157894.647975.219720@h76g2000cwa.googlegroups.com>   D The DE500 and DE450 will work and are commonly available on Ebay for peanuts.  A If you want to buy from a dealer, Abacus Computing in Reading are " always my best bet.  0118 940 3111   Steve    Chris wrote:N > DE500 would be the preferable card, but any old DE450 will work just fine as5 > well (and are probably being given away these days)  >  > 9 > "Robert Tillyard" <rob@vetsystems.com> wrote in message 0 > news:e5l5rf$flq$1$8302bc10@news.demon.co.uk...E > > I have an AlphaServer 1000 4/233 that I bought from someone who'd  > > installed Linux on it. > > H > > I've put OpenVMS 7.3-1 on it but it says it doesn't have an ethernetH > > card, the previous owner said he swapped it for one that Linux would > > recognise. > > K > > What card do I need to buy (I'm in the UK if that makes a difference to  > > suppliers) for VMS to use? > > / > > The case says 4/233 but the LCD says 4/266.  > >  > > Thanks, regards, Rob.    ------------------------------   Date: 1 Jun 2006 02:58:37 -0700 - From: "Andrew" <andrew_harrison@symantec.com> ; Subject: Re: OT: Sun release 8-socket/16-way SMP X64 server C Message-ID: <1149155917.036232.314530@i39g2000cwa.googlegroups.com>    Tom LINDEN wrote: K > On Wed, 31 May 2006 09:06:07 -0700, Andrew <andrew_harrison@symantec.com>  > wrote: >  > >  > > Alan Greig wrote:  > >> Tom LINDEN wrote: > >> > >> > > >> >* > >> > Looks like a good system to run VMS > >>L > >> And probably has about the performance of the fastest 32-way Alpha. How4 > >> much does one of these set you back these days? > >> --  > >> Alan Greig  > > I > > $1,939,268.00 (32 CPU 32GB, 2 x Internal disks)  Can't seem to get it G > > configured with 16 GB but halving the memory would save you $56,000 3 > > slightly more than the list price of the x4600.  > > H > > The Opteron is roughly 2x the performance of the EV7 1300 on Int and > > 1.3-1.5x faster on FP. > >  > > Regards  > > Andrew Harrison  > >  > I > $2 Million , are you serious?  It only has two PCI slots:-)  If you put % > in two FC HBA's no more space left.    How about the 4 USB ports ? :-)    Regards  Andrew Harrison    ------------------------------   Date: 1 Jun 2006 07:00:24 -0700 - From: "Andrew" <andrew_harrison@symantec.com> 3 Subject: Sun axes 5000 jobs but gains market share. B Message-ID: <1149170424.328102.77740@c74g2000cwc.googlegroups.com>  D In his first major organisational announcement since taking over theF reins from Scott McNealy Jonathan Schwartz has announced that Sun willC be making 5000 redundancies worldwide in an attempt to cut costs by D $480-$590 million dollars per annum. Most of these redundancies will happen in the next 6 months.  B News from Sun is not entirely grim however. Q1 server numbers fromG Gartner show that Sun revenue rose 8%, HP was flat, IBM despite posting B an 19% rise in shipments saw revenue decline by 4%. Sun posted the( scond largest shipment increase of 8.1%.  G Sun also regained the top spot in the high end server market with a 32% ( share, HP and IBM both have a 30% share.   Regards  Andrew Harrison    ------------------------------  * Date: Thu, 1 Jun 2006 10:23:14 +0000 (UTC) From: david20@alpha2.mdx.ac.uk$ Subject: Re: Unix runs faster, maybe) Message-ID: <e5mf6i$2ud$1@news.mdx.ac.uk>   r In article <n--dncxoJ9118ePZnZ2dnUVZ_sCdnZ2d@metrocastcablevision.com>, Bill Todd <billtodd@metrocast.net> writes: >Dave Froble wrote:  >  >....  >  > H >By contrast, Unix has thrived throughout, achieved royalty of its own, G >spawned vigorous offspring to carry on the line, and seems far better  I >positioned to confront its own upstart (Windows) than VMS was back then  J >(in part because Unix runs on the same hardware that Windows does - plus  >more).  >   H Wrong upstart. The upstart UNIX has to confront is Linux not Windows and! sorry Unix isn't well positioned.     F >VMS had its chance and blew it (or at least in part had it blown for E >it).  Absent some massively credible effort by its owner to turn it  I >around, no one who isn't already committed to VMS will give it a second  H >thought, because it's at best stagnant and quite likely headed for the I >ultimate code freeze sooner rather than later (and the people who might  E >otherwise be most interested in it are interested in the long term).  > I >Attempting to compare VMS and Unix on technical grounds entirely misses  F >the point.  Unix is clearly *adequate* for most needs, regardless of J >whether VMS might be better.  And Unix is credible as a platform for the E >future, whereas VMS simply isn't (due to decades of neglect with no  5 >indication whatsoever of any change in that status).  >   O Linux is adequate for most needs and is credible as a platform for the future.  H Traditional commercial Unix systems look like they are going to be very  badly squeezed.         
 David Webb Security team leader CCSS Middlesex University     >- bill    ------------------------------   Date: 1 Jun 2006 07:28:38 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) $ Subject: Re: Unix runs faster, maybe3 Message-ID: <sSW8hYYXIgAG@eisner.encompasserve.org>   J In article <e5mf6i$2ud$1@news.mdx.ac.uk>, david20@alpha2.mdx.ac.uk writes: > Q > Linux is adequate for most needs and is credible as a platform for the future.  J > Traditional commercial Unix systems look like they are going to be very  > badly squeezed.   C    Linux, UNIX, and Windows are all "good enough" for at least some 	    needs.   C    Linux is starting to address, or be used to address, needs never '    really addressed by UNIX or Windows.   H    It looks like IBM plans to take on Windows with a Linux based office '    product.  I wish them great success.   ?    I think IBM realizes that the business is software; computer D    manufacturing has been moving out of the profit margins since the    middle 80's.   G    Don't take on Intel, AMD, or Dell, partner with them.  Don't partner *    with Microsoft, compete with Microsoft.   ------------------------------   Date: 1 Jun 2006 07:18:25 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) $ Subject: Re: Unix runs faster, maybe3 Message-ID: <KN+4BPdKkHr$@eisner.encompasserve.org>   r In article <n--dncxoJ9118ePZnZ2dnUVZ_sCdnZ2d@metrocastcablevision.com>, Bill Todd <billtodd@metrocast.net> writes: > E > By contrast, the existing VMS customer base (which clearly already  F > includes all VMS enthusiasts, at least those committed to using the E > product) is minute (and shrinking - in no small part because VMS's  C > future is insufficiently assured to justify embracing a hardware  B > platform that they don't find very attractive in its own right).  E    Minute?  Well, small may be a better word.  Shrinking?  Nope, it's B    stable.  Some are leaving, some are entering, most are staying.  G    The great dropoff in the VMS market share was a long time ago.  If I E    have to choose between replacinga old VAX/VMS based solution with  D    either a new VMS/Itanium solution or a UNIX based solution, I'll 8    choose that Itanium because UNIX can't meet my needs.  F    And I'll keep watching UNIX, Linux, ..., to see if any of them ever?    catch up.  For many of my need Linux has turned in the right B    direction, even though Linus used to claim he didn't believe in    addressing those needs.   ------------------------------   Date: 1 Jun 2006 14:05:56 GMT 1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) $ Subject: Re: Unix runs faster, maybe, Message-ID: <4e8ai4F1ahl9iU1@individual.net>  / In article <7_udnfXVDL5nyOPZ4p2dnA@libcom.com>, * 	Dave Froble <davef@tsoft-inc.com> writes: > Bill Gunshannon wrote:< >> In article <vrmdnezKCIpPVuDZnZ2dnUVZ_vqdnZ2d@libcom.com>,- >> 	Dave Froble <davef@tsoft-inc.com> writes: K >>> I get real tired of reading about how Unix is thriving and VMS is not.   >>  N >> I get tired of reading about rising taxes, rising interest rates and rising1 >> crime rates.  Doesn't make them any less true.  >>  J >>> It's always stated in a manner that suggests that it's the OS that is  >>> causing this effect. >>  ? >> Maybe it is, but not the way you seem to be interpreting it.  >>  F >>> Can anyone possibly conceive the notion that VMS runs on only one K >>> currently produced CPU and on systems (not the most desired) from only  O >>> one vendor?  Do you think this might have something to do with the numbers?  >>  M >> And why is that?  Could it be that its last few owners have not thought it L >> stood a chance competing with the alternatives and chose to milk the cashM >> cow to death rather than trying to fatten it up enough for it to carry its  >> own weight? >  > Hmmm...........  > J > I don't want to put words in your mouth, so let me ask very explicitly, @ > are you accusing palmer and curly of being astute businessmen?  ' I would never accuse them of that.  :-)    > D > If they made such good decisions, where are their companies today?  L I didn't say the decision was good, as a matter of fact, I think it was bad.5 Bad for Digital/Compaq/HP.  And bad for the industry.    > J > Perhaps if DEC and Compaq were 1/10 as good as you seem to declare them & > to be, they'd still be around today.  D No, they would have needed management that was 10 times as good, not
 1/10 as good.    > C >>> Add to this Palmer driving away hugh numbers of ISVs using VMS.  >>   >> Why is that?  See above.  >>  4 >>> Add to this the lack of any promotion of the OS. >>> % >>> Add killing Alpha, and more .....  >>  K >> I won't keep repeating the above, but surely the people who did all this K >> had to have a reason, even if no one on the outside saw it the same way.  > K > The people who didn't make good decisions have caused the destruction of   > their companies. > H > The most probatable reason is that they were afraid to compete in the  > market.     E This is the crux of the matter.  And it still exists today.  They are C so inept as to be blind to the value of what they have.  They don't B think they can compete and that becomes a self-fulfilling concept.  H >          They looked at Microsoft and Intel and just stood quaking in D > their booties and didn't do a damn thing.  They just waited to be % > gobbled up.  They were incompetent!   F Not just MS/Intel. Pretty much everybody.  They could have eaten IBM'sE shorts during their IBM time.  But, even after a decade of decay, IBM 9 came back.  And VMS stood on the sidelines doing nothing.    > M >>> Now, once again, tell me just how much of the OS selection is determined   >>> by the OS capabilities.  >>  I >> As late as the early Alpha days, there is little if any doubt that VMS J >> was superior in capabilities.  But times have changed.  the competitionL >> turned commercial in a big way and moved forward to a greater extent thanI >> VMS did.  With the possible exception of clustering most modern Unixes K >> can do everything that VMS can do.  Not necessarily in the same way, but ' >> to the satisfaction of the industry.  >>  . >>> I'll suggest that if all else were equal,  >>  . >> In the real world, all else is never equal. >>  L >>>                                           VMS would be chosen over Unix 5 >>> more often than not.  As an example, in the 80s,   >>  ) >> There we go, living int he past again.  > H > Not living in the past, just citing an example.  Do you know anywhere I > else to get examples of history?  Please tell me how to get an example  H > of what the stock prices will be tomorrow.  You'll never hear from me  > about VMS again. > " >> Back int he 80's VMS was prettyJ >> much superior to all the available Unixes.  But this isn't the 80's and >> Unix didn't stand still.  > H > And neither has VMS.  I won't claim that it has moved as fast as some K > others, but I will say that it's possible that some of the advances made  + > by others was because VMS showed the way.   I Well, with the possible exception of clustering technology, I can't think H of anything that VMS has been working on that anyone has tried to match.I Probably the best example (as much as many here hate it) is GUI's.  While H everyone else is working hard to perfect GUI's because that's what theirF user base wants, where is VMS?  An ancient version of Motif.  Only oneH small example, but it shows a mindset.  Sad as it may sound, it is slickJ fluff that sells systems much more than hidden features (like security andH reliability).  Modern man is very jaded and has a really short attentionI span.  Show him slick 3D graphics with animation and he will remember it. G Tell him how great your OS is compared to the alternatives and he won't E remember what you said by the time he get's to the front door of your F building.  Why do you think "death by Powerpoint" is so popular rather than lengthy Whitepapers?    > I >>>                                                  when a rather large  K >>> percentage of computers in use (before PCs) were VAXs, what percentage  * >>> ran VMS, and what percentage ran Unix? >>  L >> It would be interesting to see real (from a source that could be trusted)K >> numbers.  I know from personal experience backin the 80's I saw more VAX N >> running VMS than Unix.  But then I saw more systems of other architectures . >> than VAX and the majority of them ran Unix. > G > Because VMS only ran on VAX.  Sort of the whole point of my original   > post, don't ya think?   I Um...  For the most part, so did Unix in the early days. (Well, there was G the PDP-11, but it was never powerful enough to compete with the VAX or H anything else that came along later to run Unix.)  Berkeley concentratedH on VAX as did AT&T (at least until they tried and totally screwed up the	 WE32000!) H But, some people looked at Unix and said, "The whole world isn't a VAX."F and decided to push it in other directions.  Too bad the management at Digital didn't see that.   > J >>> If you want to talk about reasons there is more use of Unix than VMS, C >>> I've given you a list, and none of them are about capabilities.  >>  G >> Yes, but I still hold that the background reason for many of the bad G >> decisions above were that people in a position to make the decisions H >> could not see VMS competing.  In any event, it changes nothing.  UnixG >> is still growing and VMS is shrinking.  Professionals trying to push H >> VMS by souting off obviously wrong information about Unix don't help,J >> they just loose even more credibility with the managers they are tryingF >> to convince and relegate VMS even further to the realm of "legacy". >>  E >> Even after my little poll which showed a number of people here who C >> actually think VMS is the better OS, most of them still laugh at E >> the idea of actually using it.  Why do you think that is?  I know, B >> I'm the one they think is a dinosaur, with all my toys straight >> out of the Jurasic Era. > @ > Yeah, the car is great.  But use it?  No way!  Horses forever!  K If Henry Ford had developed and marketed the automobile the way the various G owners of VMS have handled their life's blood, we would still be riding  horses.    > F > Ok, lets try once more.  You work at a University, you do under the 0 > concept of a hypothetical question, don't you? > F > If VMS ran on only itanic, and Unix also ran only on itanic, do you F > truly feel that Unix would enjoy such greater numbers of users?  No C > bullshitting around, just answer the question as it's posed.  No  B > bullshit about the real world as a way of avoiding the question.  F Insufficent data, but I'll answer it two ways to allow for the missing pieces.   D If you mean as VMS and Unix exist today, Unix would win, hands-down.G Why?  Because it has the best features that the users can actually see.  And fluff sells.  G If you mean going back to the 80's and starting again but limiting Unix E to running on only the same hardware as VMS, I think VMS could be the E hands-down winner.  Note, I said could, because it would still depend B on its management.  If Unix took the marketing tack that Linux hasG today and VMS used the same strategy it has demonstrated, it eould have G failed just as surely.  Like I said, it's all about fluff.  Clustering, A security and reliability are nice, but the majority of users (and F managers) never see it.  You can't put a picture of security in a fullA page ad in a magazine, you can put a slick GUI there.  And that's 
 marketing.  G Heck, I'll go you one better.  I don't think VMS's days are necessarily F over even now.  Just like IBM came back I think VMS could do the same.G With a serious development effort to make it match what Linux/Unix have D to offer (that includes support for the dominant architecture of theG day although making it even more portable would be better) and a really G serious marketing effort to match the Linux hype, I think it could grow J quite a bit.  Would it ever beat out Windows or Linux/Unix?  I don't know.I But it could be a viable contender in the marketplace.  It could probably D challenge what is left of IBM's mainframe market and that would be a! decent piece of change in itself.   @ The bad news, I don't see it happening. But we can always dream.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 1 Jun 2006 14:10:30 GMT ( From: bill@cs.uofs.edu (Bill Gunshannon)$ Subject: Re: Unix runs faster, maybe, Message-ID: <4e8aqmF1ahl9iU2@individual.net>  3 In article <sSW8hYYXIgAG@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > I >    Don't take on Intel, AMD, or Dell, partner with them.  Don't partner , >    with Microsoft, compete with Microsoft.  G The best advice you could possibly offer.  Too bad no one is listening.     bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 1 Jun 2006 14:16:49 GMT ( From: bill@cs.uofs.edu (Bill Gunshannon)$ Subject: Re: Unix runs faster, maybe, Message-ID: <4e8b6hF1ahl9iU3@individual.net>  3 In article <KN+4BPdKkHr$@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:t > In article <n--dncxoJ9118ePZnZ2dnUVZ_sCdnZ2d@metrocastcablevision.com>, Bill Todd <billtodd@metrocast.net> writes: >>  F >> By contrast, the existing VMS customer base (which clearly already G >> includes all VMS enthusiasts, at least those committed to using the  F >> product) is minute (and shrinking - in no small part because VMS's D >> future is insufficiently assured to justify embracing a hardware C >> platform that they don't find very attractive in its own right).  > G >    Minute?  Well, small may be a better word.  Shrinking?  Nope, it's D >    stable.  Some are leaving, some are entering, most are staying.  D I guess that depends on how deep you look.  I have found many of theD supposed VMS strongholds to have been looted and left with the doors= hanging off their hinges. (And, I have looked recently, too!)    > I >    The great dropoff in the VMS market share was a long time ago.  If I G >    have to choose between replacinga old VAX/VMS based solution with  F >    either a new VMS/Itanium solution or a UNIX based solution, I'll : >    choose that Itanium because UNIX can't meet my needs. > H >    And I'll keep watching UNIX, Linux, ..., to see if any of them everA >    catch up.  For many of my need Linux has turned in the right D >    direction, even though Linus used to claim he didn't believe in >    addressing those needs.  4 Boy would I like to see a list of those needs!!  :-)   bill      --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 1 Jun 2006 09:59:11 -0700  From: bob@instantwhip.com $ Subject: Re: Unix runs faster, maybeC Message-ID: <1149181151.387300.299510@g10g2000cwb.googlegroups.com>    Bill Gunshannon wrote: > 6 > Boy would I like to see a list of those needs!!  :-)  : how about security for one ... no viruses ... no hacks ...' that should be your number one need ...    ------------------------------   Date: 1 Jun 2006 07:29:22 +0100 2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) ? Message-ID: <DTiotGxQ0bj6-pn2-eKEWpyzPt3Ht@dave2_os2.home.ours>   E On Wed, 31 May 2006 12:31:18 UTC, bill@cs.uofs.edu (Bill Gunshannon)   wrote:  A > In article <DTiotGxQ0bj6-pn2-xmo0OPFdlJg6@dave2_os2.home.ours>, 7 > 	"Dave Weatherall" <djw-nothere@nospam.nohow> writes: I > > On Wed, 31 May 2006 01:49:20 UTC, bill@cs.uofs.edu (Bill Gunshannon)  
 > > wrote: > >  > >> >  < > >> > This makes writing robust applications easier on VMS.  G > >> If the application requires robustness, then it isn't TCPIP's job, F > >> it's the applications.  TCPIP provides all the tools needed to doF > >> that.  You can always write your application using UDP and do allG > >> of the session management in your application, making it as robust  > >> as you want.   G > > Agreed Bill but JF's point is that VMS, in general, and DecNet, in  J > > particular, make it less work for the developer and I believe that to  > > be the case.  D > Even if it was true, which I don't agree with (I still think it isF > more a matter of which one the programmer knows better) it is likelyE > due more to differences in the total model of the protocol than any I > inherent superiority.  We have undergrads who write servers and clients E > for TCPIP, usually in less than 24 hours from the assignement being A > given out and that is with students coming into the course with E > absolutely no experience with networking at all.  Of course, I have F > no doubt that they could do the same thing with DECNET, but it shows5 > that TCPIP is not particularly hard to program for.    > > E > > I have two versions of a server app. One uses DecNet,  the other  
 > > TCPIP. > H > And at the time you wrote them, which one were you more familiar with?5 > Or did you have no experience with either protocol?   F If you'd read the post through before diving in you'd know the answer  !    H > > The DecNet one is more robust partly because of the programming but H > > mainly because it 'just works' and tells me when and why it doesn't. > J > You keep bringing up this robustness thing.   Be nice to see it defined.M > Why?  Because I think it consists mostly of concepts that were specifically G > left out of TCP because they didn't belong at that level.  Robustness E > belongs at the application level.  And IP allows for that.  TCP has B > robustness too, but probably not the way you are thinking of it.E > Query:  What happens to a DECNET connection if the path between two G > nodes goes away?  I assume it dies and reports back to both ends that  > there is no longer a path.  E Correct - and I can report that to the user using standard VMS error   reporting services (PUTMSG).  ) >  I assume that is what you are calling  G > "robustness".  TCPIP on the other hand is robust in quite a different J > way.  If the path between two nodes goes away the connection is designedI > not to break.  One reason for this is to allow for finding an alternate F > path if it exists.  Another is that the path may come back.  Now, ifE > the connection is time critical, it becomes the applications job to I > know that a path between the nodes no longer exists and to deal with it 2 > at the application layer.  Not TCPIP's job, man.  E Fine - it's the applications job. It is relatively time-critical.The  > difference appears to me appears to be the comparative effort ) involved. DecNet appears to involve less.   F > Like most of the stuff that people argue here, it is not a matter ofI > superiority/inferiority, just a matter of different design philosophies I > because the designers had different ideas of functionality in mind when  > they designed the protocol.   F Agreed but then don't have a go at JF when he tries to explain one of < the differences or reasons for _his_, and coincidentally my 
 _preference_.   H > > I accept that the error handling in the TCPIP one is less effective  > C > I don't know what you mean by error handling, but I think you are D > lumping a bunch of application layer stuff into the network layer.D > How much the network layer handles depends on wether you are using? > TCP or UDP and what parameters are are set (like Keep_Alive).   A Again you've lost the context - I was talking about the app! But  B actually when I think about there was one issue in that area that F caused us trouble. If the server connection died we had to restart theF app completely before we could establish a link from a client. We had F to use a specific socket option ISTR. In similar circumstances DecNet D just sorted itself out. and we could reconnect (after I handled the F 'gone-away message' to release the servers for re-use at my code level :-)   K > >                                                                    but  H > > that's because it requires a lot more work to be done and the bloke 0 > > who implemented it didn't understand it all.  H > I thnk he understood it perfectly well.  He just decided not to do theF > application layers work in the network layer.  :-)  Just because youG > don't agree with the way he did it doesn't mean he didn't understand.   F He had done some TCP/IP work before and his experience was that it wasF less 'reliable' or to quote 'weniger zuverlaessig', so packed in a lotC of extra overhead that my DecNet stuff doesn't need. IIRC he'd not  F been responsible for the communication layer and had had trouble with D packets arriving out of order. I didn't criticise him then, when he : worked for me, and I'm not doing so now. We discussed the F implementation and I deferred to _his_ experience. Please don't assume# to know what's going on in my head!   F > > I didn't fully understand the DecNet one when I wrote it but it's I > > still more robust.  Thanks in both cases to the code in xxx$EXAMPLES.  > G > Like I said, there are different ways to be robust.  Doing one layers I > job in another layer does not particularly mean the protocol is robust.   D Where did I say anything about theDecNet protocol being more robust  than TCP/IP?  	 I said ->   H > > The DecNet one is more robust partly because of the programming but H > > mainly because it 'just works' and tells me when and why it doesn't.  C Where the 'one' is the server, i.e. my code is more robust. I said  D it's more robust because doing the error handling on DecNet is less C work and thus _easier_ to do _well_ than it seems to be on TCP/IP.  C That is what JF was saying, its what Dave F, Bob K and many others   have been saying.   F I don't want a religious or flame war on this or any other subject. I F just want to make it plain where I believe VMS has its strengths. I'm F not criticising Unix in Linux or any other form. I've never programmedA much on the platform so am not qualified to have an in depth go,  D although there are things which bug me straight away after years of  RSX, VMS and even Dos/Windows.   --   Cheers - Dave W.   ------------------------------  % Date: Thu, 01 Jun 2006 09:29:41 +0200 + From: Karsten Nyblad <nospam@nospam.nospam> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) = Message-ID: <447e9731$0$60780$157c6196@dreader1.cybercity.dk>    Bob Koehler wrote:m > In article <447db5dd$0$67257$157c6196@dreader2.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes:  > I >>No, but I wonder if you do.  You keep using examples from years ago to  C >>put down current days *NIX.  Why should anybody take advise from  J >>somebody doing that?  Do you really think you do VMS any good that way?  >  > H >    Years ago?  Are you sure nobody is programming in Fortran or Pascal >    today?  > J >    I don't buy the C, or C++, or Java, is The Silver Bullet hype.  I buyI >    the right tool for the job.  Some things are easier to do in PL/I.   # >    Some things are easier in Ada.  > F >    Some are easier pushing buttons.  Some buttons are easier to push >    than others.  > E I was not referring to Fortran or Pascal.  What we are discussing is  I whether any of us two are trying to start a VMS vs. *NIX fight.  Both of  I us have participated in a number of debates on c.o.v on the capabilities  G of VMS and *NIX.  I feel that in these debates you are describing *NIX  G as it was in the last millennium, e.g., in this debate you are putting  B down *NIX because of the way wildcard specifications of files are I handled in *NIX.  As I have pointed out, the limitations in the *NIX way  F of doing things do not cause serious problems to *NIX users on modern I *NIX, and you fail to mention that the VMS way of doing things also have  G its shortcomings.   Using outdated arguments does not help VMS because  F such arguments can be dismissed as coming from a person that does not E have up to date knowledge.  Further, putting down *NIX with outdated  F information tend to start long debates, at least if you do it here in G c.o.v.  I have a hunch that you actually have up to date knowledge, so  ' why not use knowledge to fight for VMS?    ------------------------------   Date: 1 Jun 2006 03:02:04 -0700 - From: "Andrew" <andrew_harrison@symantec.com> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) C Message-ID: <1149156124.253643.114070@u72g2000cwu.googlegroups.com>    Mark Berryman wrote: > norm.raphael@metso.com wrote:  > > N > > "Richard B. Gilbert" <rgilbert88@comcast.net> wrote on 05/25/2006 10:39:32 > > AM:  > >  > >  > >>Bill Gunshannon wrote: > >>1 > >>>In article <e54907$ljp$1@reader1.panix.com>, 8 > >>>   John F <john@pleaseSeeSigForAddress.com> writes: > >>>  > >>> ; > >>>>OP seems, in reply to your query, rather annoyed that > > >>>>nobody's willing to take on his brilliant idea for free. > > 
 > > [snip] > > 5 > >>Unix runs faster than VMS on comparable hardware.  > >  > > 3 > > I just cannot let that statement go unremarked. E > > Unix may run faster, but without the reliability, so "comparable" F > > is as always dependent on the business problem needing a solution. > > One man's meat.... > O > I have done a number of head to head performance comparisons of Unix vs. VMS, Q > usually on the same hardware.  Unix never won.  This would have been in the VAX L > days and a few years into the Alpha days.  I have not had reason do to anyO > recently.  However, neither have I seen anything to indicate that the results  > would now be different.   B Depends which UNIX you are refering to. True64 hasn't changed muchG recently, on the other hand other UNIX OS's have gone through so fairly G significant changes which have a major impact on performance. Of course E most of the other UNIX OS's don't run on Alpha making a like for like  comparison impossible.   Regards  Andrew Harrison  >  > Mark Berryman    ------------------------------   Date: 1 Jun 2006 03:15:59 -0700 - From: "Andrew" <andrew_harrison@symantec.com> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) B Message-ID: <1149156958.973745.212840@f6g2000cwb.googlegroups.com>   Bob Koehler wrote:P > "Richard B. Gilbert" <rgilbert88@comcast.net> wrote on 05/25/2006 10:39:32 AM: > 5 > > Unix runs faster than VMS on comparable hardware.  > I >    Intentionally misleading FUD.  A subtract instruciotn, for instance, ; >    depends only on the hardware and not at all on the OS.  > K >    What you get with VMS is the option to determine whether you want more H >    reliable I/O or faster I/O since you control the buffering.  If youJ >    don't tell VMS otherwise, it will do realiable I/O.  You get what you
 >    need. > J >    With UNIX you get no choice other than to buy a megabucks DBMS if you >    need reliable I/O.   D Marvelous you accuse Richard of intentionally misleading FUD, make aD number of statements about UNIX I/O that are incorrect ever heard ofD fsync and then top it all off with your DBMS point which is the bestA example of intentional missleading FUD I have seen in a couple of  years.  G Way to go Bob. First statement arguable, second plain wrong, third pure  FUD.   Regards  Andrew Harrison    ------------------------------   Date: 1 Jun 2006 07:10:55 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) 3 Message-ID: <E8zica1NjZ8+@eisner.encompasserve.org>   O In article <op.tafpdsy0lvpiaf@hyrrokkin>, "Tom LINDEN" <tom@kednos.com> writes:  > & > Alright, I give, the sheep would be?       Using a product from Redmond.   ------------------------------   Date: 1 Jun 2006 07:22:37 -0500 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) 3 Message-ID: <zEBg0EGL1K4J@eisner.encompasserve.org>   k In article <447e9731$0$60780$157c6196@dreader1.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes:   A > I have a hunch that you actually have up to date knowledge, so  ) > why not use knowledge to fight for VMS?   C    Way back in the start of this thread I did use that knowledge to E    defend against the UNIX is faster FUD.  All of my comments on both 6    VMS and UNIX since then have been based on reality.  B    I know UNIX.  I know it deeply, I've studied its internals, itsI    history, its strenghts, and its faults.  I know VMS even deeper.  I'm  +    glad I don't know Windows that deeply.         And I don't tolerate hype.    ------------------------------   Date: 1 Jun 2006 06:21:27 -0700 - From: "Andrew" <andrew_harrison@symantec.com> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) B Message-ID: <1149168087.164798.45590@j55g2000cwa.googlegroups.com>   Bob Koehler wrote:m > In article <447e9731$0$60780$157c6196@dreader1.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes:  > B > > I have a hunch that you actually have up to date knowledge, so+ > > why not use knowledge to fight for VMS?  > E >    Way back in the start of this thread I did use that knowledge to G >    defend against the UNIX is faster FUD.  All of my comments on both 8 >    VMS and UNIX since then have been based on reality. > D >    I know UNIX.  I know it deeply, I've studied its internals, itsJ >    history, its strenghts, and its faults.  I know VMS even deeper.  I'm+ >    glad I don't know Windows that deeply.  >  >    And I don't tolerate hype.   E No you have me truely baffled. You know "UNIX" you know its internals E etc etc but you have made some statements about how UNIX does I/O and B how much control you have over it which are quite simply wrong for$ almost all current flavours of UNIX.  F In the past you have made similar incorrect claims about UNIX securityB requirments for root users etc which were also highly questionable( given that they were untrue for Solaris.  F Can you give me some idea of which version of UNIX you are refering to0 when you talk about deep and meaningfull study ?   Regards  Andrew Harrison    ------------------------------   End of INFO-VAX 2006.303 ************************