1 INFO-VAX	Wed, 31 May 2006	Volume 2006 : Issue 301       Contents: Re: 2 Nameservers on 1 node  Call for Freeware: 15-Jun-2006$ Re: Compaq board member sent to jail$ Re: Compaq board member sent to jail Re: DCL: IF   and .AND.  logic Re: DCL: IF and .AND. logic & Re: Error installing VMS732_PCSI-V0300& Re: Error installing VMS732_PCSI-V0300& Re: Error installing VMS732_PCSI-V0300& Re: Error installing VMS732_PCSI-V0300" Re: Fixing a Corrupt PCSI DatabaseA Re: I knows it's unsupported, but does current VMS run on ZX2000? A Re: I knows it's unsupported, but does current VMS run on ZX2000?  Re: MIME bug: escaped filenames . OT: Sun release 8-socket/16-way SMP X64 server2 Re: OT: Sun release 8-socket/16-way SMP X64 server2 Re: OT: Sun release 8-socket/16-way SMP X64 server2 Re: OT: Sun release 8-socket/16-way SMP X64 server2 Re: OT: Sun release 8-socket/16-way SMP X64 server2 Re: OT: Sun release 8-socket/16-way SMP X64 server. Re: So how representative is this experience ?0 Re: speeding up LAVC with switch instead of hub?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)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)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)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: 28 May 2006 21:03:50 -02006 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)$ Subject: Re: 2 Nameservers on 1 node, Message-ID: <447a1036$1@news.langstoeger.at>  y In article <nXkeg.7559$GM.6394@tornado.rdc-kc.rr.com>, "Schroeder, AJ" <aaron.schroeder-no-spam@tmscomputers.com> writes: J >BIND9 implemented a feature called "views" which basically allows you to J >have two separate versions of a zone running on the same machine. I have N >done this successfully on several BIND9 implementations and setting it up is  >a snap!  > So, now we are on the right track. "View" was _the_ keyword...  M >Here is a tutorial on how to set it up (it is written for *nix, but you can   >fill in the blanks):  > H >http://www.oreillynet.com/pub/a/oreilly/networking/news/views_0501.html   Thanks for the link.   >Hope that helps,   ; Indeed. But now I've to downgrade to TCPIP to get BIND9 ;-)    --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  # Date: Wed, 31 May 2006 13:06:46 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>' Subject: Call for Freeware: 15-Jun-2006 1 Message-ID: <Gxgfg.1282$9o4.228@news.cpqcorp.net>   E    The deadline for submissions to the OpenVMS Freeware V8 distro is  E approaching -- if you have or if you know of new or changed software  @ packages for OpenVMS, please submit the package, or a pointer...  8    Details and the submission web form are available at:  +    <http://www.hp.com/go/openvms/freeware/>   H    All Freeware submissions (whether via email or via the web site) are  acknowledged via email.   
    Thank you!    ------------------------------  % Date: Wed, 31 May 2006 05:45:27 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> - Subject: Re: Compaq board member sent to jail 9 Message-ID: <MAdfg.2239$EF1.157131@news20.bellglobal.com>   = "Paul Sture" <paul.sture.nospam@hispeed.ch> wrote in message  5 news:26929$447cf1cb$50db5015$32684@news.hispeed.ch...  > etmsreec@yahoo.co.uk wrote: G >> So, if I weren't a god-fearing christian, one could suggest tht he's / >> both a crook (allegedly) and a bible basher.  >> >  > Or just a plain hypocrite?  J Many of these people auto-magically find religion at the time of the bust.  H Police: Mr. Ken Lay, I'm placing you under arrest and charging you with  corporate fraud.   Ken Lay: Jeeeeesus!   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/    ------------------------------    Date: 31 May 2006 08:40:16 -0700- From: "Doug Phillips" <dphill46@netscape.net> - Subject: Re: Compaq board member sent to jail B Message-ID: <1149090016.399825.89780@h76g2000cwa.googlegroups.com>   Paul Sture wrote:  > Neil Rieck wrote:  > > K > > This article on the personalities of corporate execs was an eye-opener.  > > [ > > http://ctv2.theglobeandmail.com/servlet/story/RTGAM.20060527.wxcover27/BNPrint/Business  > >  >  > Interesting article thanks.  > 1 > How about this snippet from the New York Times?  > = > http://www.nytimes.com/2006/05/25/business/25cnd-enron.html  > P > Mr. Lay later said, "I firmly believe I'm innocent of the charges against me."  G Now, Mr. Lay, close your eyes and click your heels together three times  while repeating that...   C > In televised remarks, he said, "We believe that God in fact is in H > control and indeed he does work all things for good for those who love > the Lord."  G Well, He let your ass get busted, Mr. Lay, so there might be some truth G there. But before we go judging God's good will, let's see how long you ; stay in prison and how well the people you screwed recover.    ------------------------------  % Date: Wed, 31 May 2006 12:40:29 -0400 ' From: Dave Froble <davef@tsoft-inc.com> ' Subject: Re: DCL: IF   and .AND.  logic / Message-ID: <fe-dnc4jcP2GW-DZRVn-ig@libcom.com>    Michael Unger wrote:, > On 2006-05-30 18:47, "Hoff Hoffman" wrote: >  >> [...] >>K >>    Run-time computed goto operations -- one of the reasons why it would  G >> be comparatively "fun" to write a compiler for DCL -- are available:  >> >>    $ GOTO LABEL_'severity'  > E > I don't like "GOTO" at all -- it is much simpler to "go back" using K > "GOSUB" and "RETURN" or "CALL" and "EXIT" (or even "EXIT <status-value>".  >  >> [...] > 	 > Michael  >   I And next we'll have someone wanting to get rid of the BRANCH instruction  
 in assembler.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------    Date: 31 May 2006 09:56:43 -0700- From: "Doug Phillips" <dphill46@netscape.net> $ Subject: Re: DCL: IF and .AND. logicC Message-ID: <1149094603.513790.134550@i39g2000cwa.googlegroups.com>    Dave Froble wrote: > Michael Unger wrote:. > > On 2006-05-30 18:47, "Hoff Hoffman" wrote: > > 
 > >> [...] > >>L > >>    Run-time computed goto operations -- one of the reasons why it wouldI > >> be comparatively "fun" to write a compiler for DCL -- are available:  > >> > >>    $ GOTO LABEL_'severity'  > > G > > I don't like "GOTO" at all -- it is much simpler to "go back" using M > > "GOSUB" and "RETURN" or "CALL" and "EXIT" (or even "EXIT <status-value>".  > > 
 > >> [...] > >  > > Michael  > >  > J > And next we'll have someone wanting to get rid of the BRANCH instruction > in assembler.  >   B Uh Oh. I smell another religious war, and here I was just about to GOSUB lunch ;-)    ------------------------------    Date: 31 May 2006 06:34:20 -0700# From: "Bobby" <colemanr7@yahoo.com> / Subject: Re: Error installing VMS732_PCSI-V0300 C Message-ID: <1149082460.915184.322630@h76g2000cwa.googlegroups.com>   G >    Does this box have its DCLTABLES.EXE in SYS$SPECIFIC:[SYSLIB]?  Or F > are there any PCSI*.EXE images in SYS$SPECIFIC:[SYSEXE] or [SYSLIB]?  @ Before PCSI-V0300:  There were three version of DCLTABLES.EXE in; SYS$SPECIFIC:[SYSLIB] and there were no PCSI*.EXE images in / SYS$SPECIFIC:[SYSEXE] or SYS$SPECIFIC:[SYSLIB].   @ After PCSI-V0300:  Same number of DCLTABLES.EXE (i.e., 3) and no- PCSI*.exe files in the specified directories.   0 > (Is the skew creeping in from another source?)C There have been no other recent changes to the system so I wouldn't F imagine that it is.  Three repeated installs of the update resulted inC the same error.  Restoring to just before the update returns "prod"  commands to normal.    Thank you for your help. Bobby    ------------------------------  % Date: Wed, 31 May 2006 10:56:00 -0400  From: norm.raphael@metso.com/ Subject: Re: Error installing VMS732_PCSI-V0300 Q Message-ID: <OFDB3D1580.7E61F19C-ON8525717F.0051B69E-8525717F.0052008E@metso.com>   > "Bobby" <colemanr7@yahoo.com> wrote on 05/31/2006 09:34:20 AM:  I > >    Does this box have its DCLTABLES.EXE in SYS$SPECIFIC:[SYSLIB]?  Or H > > 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]   C AHA!  IIRC all versions of DCLTABLES.EXE s/b in SYS$COMMON:[SYSLIB] ! for any ECO to install correctly.   E Is there any reason not to purge, then rename the file remaining into 9 the common directory?  I'd bet the update work fine then.     ' > and there were no PCSI*.EXE images in 1 > SYS$SPECIFIC:[SYSEXE] or SYS$SPECIFIC:[SYSLIB].  > B > After PCSI-V0300:  Same number of DCLTABLES.EXE (i.e., 3) and no/ > PCSI*.exe files in the specified directories.  > 2 > > (Is the skew creeping in from another source?)E > There have been no other recent changes to the system so I wouldn't H > imagine that it is.  Three repeated installs of the update resulted inE > the same error.  Restoring to just before the update returns "prod"  > commands to normal.  >  > Thank you for your help. > Bobby  >    ------------------------------  # Date: Wed, 31 May 2006 14:56:59 GMT 3 From: hammond@not@peek.ssr.hp.com (Charlie Hammond) / Subject: Re: Error installing VMS732_PCSI-V0300 2 Message-ID: <%8ifg.1290$xV3.1113@news.cpqcorp.net>  i In article <1149082460.915184.322630@h76g2000cwa.googlegroups.com>, "Bobby" <colemanr7@yahoo.com> writes: 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]?  > A >Before PCSI-V0300:  There were three version of DCLTABLES.EXE in < >SYS$SPECIFIC:[SYSLIB] and there were no PCSI*.EXE images in0 >SYS$SPECIFIC:[SYSEXE] or SYS$SPECIFIC:[SYSLIB]. > A >After PCSI-V0300:  Same number of DCLTABLES.EXE (i.e., 3) and no . >PCSI*.exe files in the specified directories.  2 DCLTABLES belongs in SYS$COMMON, not SYS$SPECIFIC.> You should find one in SYS$COMMON -- which is the one the the > PRODUCT INSTALL updates.  However, when you boot, OpenVMS will. use the out-of-date DCLTABLES in SYS$SPECIFIC.   --  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: Wed, 31 May 2006 16:15:07 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>/ Subject: Re: Error installing VMS732_PCSI-V0300 1 Message-ID: <fijfg.1294$2L4.383@news.cpqcorp.net>    Bobby wrote: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].  > B > After PCSI-V0300:  Same number of DCLTABLES.EXE (i.e., 3) and no1 > PCSI*.exe files in the specified directories...   C    That's likely the source of your skew -- DCLTABLES is typically  D expected to be in the common root, and that's where most tools load 8 their command verbs.  (If somebody issues a SET COMMAND B mumble.CLD/TABLES=SYS$SHARE:DCLTABLES/OUTPUT=SYS$SHARE:DCLTABLES, G unfortunately, the DCLTABLES image ends up in an undesirable location.  H Arguably, SET COMMAND could be re-worked to allow better defaulting, or D to issue a diagnostic.  But that's fodder for another discussion...)  F    The VERB tool (on the Freeware) can help you spot what's different D between the two current DCLTABLES images, or you can get rid of the G SYS$SPECIFIC version and re-install when you bump into missing command  F verbs.  If you use the VERB tool, you can extract everything and then G DIFFERENCES the contents of the command tables.  That'll tell you what  E you need to un-skew to synchronize your DCLTABLES and get rid of the   local versions, obviously.  ;    As an immediate test of this, you can issue the command:   8      SET COMMAND/TABLES=SYS$COMMON:[SYSLIB]DCLTABLES.EXE  /    and try the (failing) PRODUCT command again.    ------------------------------  # Date: Wed, 31 May 2006 13:32:10 GMT 3 From: hammond@not@peek.ssr.hp.com (Charlie Hammond) + Subject: Re: Fixing a Corrupt PCSI Database 1 Message-ID: <uVgfg.1283$LE4.260@news.cpqcorp.net>   &  <jfmezei.spamnot@teksavvy.com> wrote:    M > ... I would fetch the product's original .PCSI file , extract all the files ? >from it in a temporary directory and find the product specific 5 > .pcsi<mumble>  and put them where they belong.  ...   I How/why is this easier than just repeating the PRODUCT INSTALL operation?    --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: Wed, 31 May 2006 13:25:14 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) J Subject: Re: I knows it's unsupported, but does current VMS run on ZX2000?[ Message-ID: <rdeininger-3105060925160001@dialup-4.233.149.246.dial1.manchester1.level3.net>   D In article <447A153C.C8F14DBF@spam.comcast.net>, "David J. Dachtera"# <djesys.no@spam.comcast.net> wrote:   ! >Peter 'EPLAN' LANGSTOEGER wrote:  >>  9 >> In article <00A56009.2D78315A@SSRL.SLAC.STANFORD.EDU>, F winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) writes: N >> >(a) whether VMS 8.2 has any checks in it to prevent it booting on a ZX2000 >>  > >> Don't know, but I doubt. I think, I read here that it runs.G >> But, since you already have the systems, why not trying yourself and = >> telling us? AFAIK, only problem is the graphics adapter...  > C >You'll likely experience the Multia phenomenon of the CPU services F >module for that model being not found, probably at some future point.  + Except VMS doesn't use such modules on I64.    ------------------------------  # Date: Wed, 31 May 2006 13:59:11 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>J Subject: Re: I knows it's unsupported, but does current VMS run on ZX2000?2 Message-ID: <Pihfg.1285$SF4.1062@news.cpqcorp.net>   Robert Deininger wrote: F > In article <447A153C.C8F14DBF@spam.comcast.net>, "David J. Dachtera"% > <djesys.no@spam.comcast.net> wrote:  > # >> Peter 'EPLAN' LANGSTOEGER wrote: : >>> In article <00A56009.2D78315A@SSRL.SLAC.STANFORD.EDU>,H > winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing)	 > writes: O >>>> (a) whether VMS 8.2 has any checks in it to prevent it booting on a ZX2000 ? >>> Don't know, but I doubt. I think, I read here that it runs. H >>> But, since you already have the systems, why not trying yourself and> >>> telling us? AFAIK, only problem is the graphics adapter...E >> You'll likely experience the Multia phenomenon of the CPU services H >> module for that model being not found, probably at some future point. > - > Except VMS doesn't use such modules on I64.   I    I believe we were quite clear on the status of the Multia, and on the  4 version dependence of the images that were released.  F    As for unsupported HP Itanium-based systems, the zx2000 and zx6000 G workstations and the older McKinley-class Integrity systems within the  E supported Integrity lines should -- SHOULD -- boot Hobbyist OpenVMS.  D No special kits are required, though no system testing has been nor G likely will be performed -- you might or might not hit a problem.  You  G will need a PCI Radeon graphics controller or the management processor  H Radeon, if you want to use the DECwindows X Windows server with the box.   ------------------------------  # Date: Wed, 31 May 2006 14:41:57 GMT , From: "Paul Mosteika" <paul.mosteika@hp.com>( Subject: Re: MIME bug: escaped filenames1 Message-ID: <VWhfg.1289$BI4.670@news.cpqcorp.net>    Hiello,   F As I said, MIME decodes the file upon OPEN, creating a temporary file.  K I fixed the temporary file cleanup issue back in V1.4 and another in V1.5.  L Do you have the MAIL directory set to the following or is that your default  for SYS$LOGIN :        ALP$DKA0:[SMS.MIME]   B Try setting the mail directory and see if that resolves the issue.  I It appears there is another defect in the cleanup of the temporary files.     0                                             Paul    8 "Steven M. Schweda" <sms@antinode.org> wrote in message , news:06051621103005_2020743C@antinode.org.... > From: "Paul Mosteika" <paul.mosteika@hp.com> > 9 >> > It's the MIME$2020743C_IBMHD.JPG;1 which bothers me.  >>L >> The temporary file from the OPEN/decode should have been cleaned up. It's? >> created as you may want to READ the file but not EXTRACT it.  > 1 >   Of course, I always said EXTRACT, never READ.  > 3 >> I'll check which version that this was fixed in.  > ? >   Potentially helpful, if I can ever get the replacement kit.  > B >> Proper formal release of a kit is required for support, versionG >> identification and tracking. That formal kit can still be requested. H >> Although I'll have to research an alternate method for general public
 >> access. > I >   I appreciate the extra overhead, but as a non-cash-paying hobbyist, I G > assume that I can't make formal support requests.  From time to time, J > someone surprises me with the odd compiler kit or FTP server replacementJ > executable image, or some such, but it's always a surprise.  (A pleasantF > one, though.)  Considering the amount of griping here about the MIMEE > utility, I'd've figured that when improvements were made, the fresh A > stuff would make it into a patch kit (its own, or an UPDATE, or 4 > something), and that it'd get some publicity, too. > % >> Thanks for reporting this problem.  >  >   Always glad to complain. > J > ------------------------------------------------------------------------ > 4 >   Steven M. Schweda               sms@antinode-org5 >   382 South Warwick Street        (+1) 651-699-9818  >   Saint Paul  MN  55105-2547     ------------------------------  # Date: Wed, 31 May 2006 10:39:55 GMT ( From: Alan Greig <greigaln@netscape.net>7 Subject: OT: Sun release 8-socket/16-way SMP X64 server > Message-ID: <%nefg.238648$tc.172837@fe2.news.blueyonder.co.uk>   Moving on up...   9 http://www.theregister.co.uk/2006/05/31/sun_x4600_ubunti/ / http://www.qassociates.co.uk/academic/84a.htm#2    Sun Fire X4600 x64 server: A67-QGZ8-4S-032CB1  2      * 8xAMD Opteron Model 885 dual-core processor      * 16x2GB DDR1-400 memory       * 2x73GB SAS drive       * DVD-ROM      * 4xPSU, Service Processor )      * 4x10/100/1000 BaseT Ethernet ports       * 4xUSB 2.0 ports9      * 2xPCI-X slots, 6x PCI-E slots (4x8-lane, 2x4-lane)       * no power cord"      * order Geo-specific x-option
      * RoHS-5       * Standard Configuration   # Academic Price: 	43,400  ($80,000)     I Although 8-socket boards have been around for a while, Sun are the first   tier one vendor to ship. --  
 Alan Greig   ------------------------------  % Date: Wed, 31 May 2006 06:28:03 -0700 # From: "Tom LINDEN" <tom@kednos.com> ; Subject: Re: OT: Sun release 8-socket/16-way SMP X64 server ) Message-ID: <op.tae3o10blvpiaf@hyrrokkin>   H On Wed, 31 May 2006 03:39:55 -0700, Alan Greig <greigaln@netscape.net>   wrote:   > Moving on up...  > ; > http://www.theregister.co.uk/2006/05/31/sun_x4600_ubunti/ 1 > http://www.qassociates.co.uk/academic/84a.htm#2  >  > Sun Fire X4600 x64 server: > A67-QGZ8-4S-032CB1 > 4 >      * 8xAMD Opteron Model 885 dual-core processor >      * 16x2GB DDR1-400 memory  >      * 2x73GB SAS drive  >      * DVD-ROM! >      * 4xPSU, Service Processor + >      * 4x10/100/1000 BaseT Ethernet ports  >      * 4xUSB 2.0 ports; >      * 2xPCI-X slots, 6x PCI-E slots (4x8-lane, 2x4-lane)  >      * no power cord$ >      * order Geo-specific x-option >      * RoHS-5  >      * Standard Configuration  > % > Academic Price: 	43,400  ($80,000)  >  > L > Although 8-socket boards have been around for a while, Sun are the first   > tier one vendor to ship.  # Looks like a good system to run VMS    ------------------------------    Date: 31 May 2006 06:42:31 -0700 From: bob@instantwhip.com ; Subject: Re: OT: Sun release 8-socket/16-way SMP X64 server C Message-ID: <1149082951.050102.129610@g10g2000cwb.googlegroups.com>   B and if sun had the brains to buy vms when Palmer was having a fire? sale, they could have done just that and ruled the OS world ...   F Now they have resorted to giving away everything for free just to make5 a few dollars off hardware ... brilliant strategy ...    ------------------------------  # Date: Wed, 31 May 2006 15:25:20 GMT ( From: Alan Greig <greigaln@netscape.net>; Subject: Re: OT: Sun release 8-socket/16-way SMP X64 server = Message-ID: <Azifg.249854$xt.41491@fe3.news.blueyonder.co.uk>    Tom LINDEN wrote:    >  > % > Looks like a good system to run VMS   H And probably has about the performance of the fastest 32-way Alpha. How / much does one of these set you back these days?  --  
 Alan Greig   ------------------------------    Date: 31 May 2006 09:06:07 -0700- From: "Andrew" <andrew_harrison@symantec.com> ; Subject: Re: OT: Sun release 8-socket/16-way SMP X64 server C Message-ID: <1149091567.254760.205880@y43g2000cwc.googlegroups.com>    Alan Greig wrote:  > Tom LINDEN wrote:  >  > >  > > ' > > Looks like a good system to run VMS  > I > And probably has about the performance of the fastest 32-way Alpha. How 1 > much does one of these set you back these days?  > -- > Alan Greig  E $1,939,268.00 (32 CPU 32GB, 2 x Internal disks)  Can't seem to get it C configured with 16 GB but halving the memory would save you $56,000 / slightly more than the list price of the x4600.   D The Opteron is roughly 2x the performance of the EV7 1300 on Int and 1.3-1.5x faster on FP.   Regards  Andrew Harrison    ------------------------------  % Date: Wed, 31 May 2006 09:47:00 -0700 # From: "Tom LINDEN" <tom@kednos.com> ; Subject: Re: OT: Sun release 8-socket/16-way SMP X64 server ) Message-ID: <op.tafcwmiilvpiaf@hyrrokkin>   I 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 >>I >> And probably has about the performance of the fastest 32-way Alpha. H=  ow2 >> much does one of these set you back these days? >> -- 
 >> Alan Greig  > G > $1,939,268.00 (32 CPU 32GB, 2 x Internal disks)  Can't seem to get it E > configured with 16 GB but halving the memory would save you $56,000 1 > slightly more than the list price of the x4600.  > F > The Opteron is roughly 2x the performance of the EV7 1300 on Int and > 1.3-1.5x faster on FP. > 	 > Regards  > Andrew Harrison  >   G $2 Million , are you serious?  It only has two PCI slots:-)  If you put # in two FC HBA's no more space left.    ------------------------------  % Date: Wed, 31 May 2006 09:37:57 -0700 # From: "Tom LINDEN" <tom@kednos.com> 7 Subject: Re: So how representative is this experience ? ) Message-ID: <op.tafchju4lvpiaf@hyrrokkin>   I On Wed, 31 May 2006 06:45:21 -0700, John Reagan <john.reagan@hp.com> wro=  te:    > Tom LINDEN wrote:  >  >>+ >> What do you do for Cobol, wrt alignment?  >> > E > COBOL is different than the other compilers by defaulting to VAX  =   I > alignment rules.  You can asking for padding, but you don't get it by =   =  F > default.  Other than that, the COBOL should behave like the other  =   > compilers. > I > Binary fields that are known to be aligned can be accessed with a sing=  le  =    > instruction. > H > Binary fields that are known not to be aligned can be accessed with  =  ? > multiple instructions that don't generate an alignment fault.  > I > Character data is manipulated with RTL routines that are byte-oriented=    =   - > so there shouldn't be aligned faults there.  > D > The lack of pointers make it hard to lie and get alignment faults. > H > Now, with all that said, there are a couple of bugs in the compiler  =  I > where the front-end knows a field is unaligned, but it accidently told=    =   D > GEM that the field was aligned.  GEM believes the front-end and  =  I > generates single instruction accesses that fault.  I'll be fixing thos=  e  =  I > over the next few months as I jump into the compiler.  Right now, I ha=  ve  =   I > several COBOL examples that appear to be much slower on I64 than Alpha=    =    > all due to alignment faults. > I Well, the reason I brought it up is that Cobol traditionally has unalign=  edI as default, so, e.g.,  the elements of records might not be on a natural=    =   	 boundary, I resulting in a serious performance hit if you need to ask the kernel to =  fix  it up.     -- =  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Wed, 31 May 2006 13:38:54 +0100 9 From: Alan Adams <alan.adams@orchard-way.freeserve.co.uk> 9 Subject: Re: speeding up LAVC with switch instead of hub? ? Message-ID: <ca06a52f4e.Alan.Adams@orchard-way.freeserve.co.uk>   # In message <e5ig70$lgo$1@online.de> C           helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove   CLOTHES to reply) wrote:  @ > In article <y9_eg.1216$l94.963@news.cpqcorp.net>, Hoff Hoffman# > <hoff-remove-this@hp.com> writes:  > J >>    I still believe that the base limit here is that the VAX systems areH >> correspondingly slow by any current standards (well, by any standardsJ >> other than the "free hardware" standard, and even that one is certainly >> debatable :-),  >  > That's certainly true. > 8 >> and this hardware configuration is attempting to slamJ >> large volumes of data (shadow disk copies, et al) over a very slow IEEED >> 802.3 (AKA Ethernet; 1MB, 10Mb) network link -- and you won't getF >> anywhere near all of the 802.3 link, for that matter.   The fastestC >> network switch in existence just won't make typical VAX hardware $ >> configuration operate any faster. > H > Right.  However, I'm hoping for two things: 1) WHEN the VAXes saturateI > the network with the shadow copies, perhaps this could be isolated from I > other systems by avoiding collisions and 2) the one node in the cluster J > which IS reasonably fast (5305/AS1200) should be able to run at 100 Mb/sI > and full duplex to make the most of the internet connection, especially G > considering that this node is a satellite which is only booted when I  > (or my wife) needs Mozilla.   ; If you connect everything to a switch instead of a repeater   F 1: The VAX won't saturate the network, only its own connection to the  switchB 2: The shadow copy traffic will only exist on the two connections  participating in the copy ; 3: The other systems will be able to operate at full speed  G concurrently, provided they don't use one of the links involved in the   shadow copy.  F If you use more than one switch, be careful that the link between the E switches doesn't become the new bottleneck. Put the systems involved  @ in the shadow copy on one switch, and the most important of the C remaining systems plus the internet connection on the other switch.    --  ! Alan Adams, from Northamptonshire & alan.adams@orchard-way.freeserve.co.uk http://www.nckc.org.uk/    ------------------------------    Date: 31 May 2006 07:09:52 +01002 From: "Dave Weatherall" <djw-nothere@nospam.nohow>M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) ? Message-ID: <DTiotGxQ0bj6-pn2-dUqfUIlQpEUW@dave2_os2.home.ours>   1 On Tue, 30 May 2006 22:01:51 UTC, Karsten Nyblad   <nospam@nospam.nospam> wrote:    > Bob Koehler wrote:[ > > In article <4dpq96F1936phU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:  > > K > >>That's a shell shortcoming and has little. if anything, to do with Unix 6 > >>or the file system.  And, it's easy to get around. > >  > > L > >    It has a lot to do with UNIX.  As in depending on the shell to expand@ > >    wildcards instead of providing an API to the application. > > K > Well in order to get parameters on VMS you have to learn the CLI API and  I > you have to write a CLD file.  Compare that to the *NIX way of passing  I > two parameters to the "main" routine.  The later does not require half  I > as much education.  Further it is my experience that you need to write  I > much more code when using the CLI API than when writing an interpreter  K > for *NIX options.  Further, wildcard processing is not directly included  F > in languages like Pascal.  You end up having to write a lot of code 7 > before you have an interface like VMSes own commands.  > J > Say simple wildcards are not enough, e.g., you need a /since qualifier. H >   On VMS it has to be part of the program or you are out of luck.  On E > *NIX you can pass the output from the find command directly to any  H > command.  It that is not enough, you can either write your own filter K > for the output of, e.g., find or ls.  Then the output of that filter can  K > be passed as command parameter.  You can also generate a file containing  C > a list of files and pass the contents of that file as parameters.  > I > The fact that there is a limit on how many parameters you can pass has  H > been mostly solve on modern *NIXes by raising the limit so high, that  > you seldom run into it.  > K > So if you are a big enough nerd to use, e.g., find, then it is difficult  : > to see that the VMS way is any better than the *NIX way.   Karsten =                  CLD files is one way to get at command line  # parameters. It is not the only way.   F You can get the command line and parse it yourself. CAn't remember theA LIB$ routines and am at home so can't check (LIB$GET_FOREIGN ???)   D You can write a DCL shell and parse the command parameters and pass  them ito your app as symbols.   F Personally, I prefer CLD files for lots of purposes. You don't have toC install 'em in DCLTABLES.  You can link them into the app, get the  F foreign command line and parse it. I find I generate less code becauseD the CLI$ routines have done it all for me. It also helps to keep my 5 user interfaces consistent. (but I'm not perfect :-))   C wrt to wildcards, I suppose it depends on what you want to do with  C them but I've used SYS$SEARCH to resolve wild-carded filespecs and  D STR$ or LIB$MATCH_Something or other to do wildcarded names (ISTR -  was a long time ago)   6 Typical VMS really. More than one way to skin the cat.   --   Cheers - Dave W.   ------------------------------    Date: 31 May 2006 07:09:55 +01002 From: "Dave Weatherall" <djw-nothere@nospam.nohow>M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) ? Message-ID: <DTiotGxQ0bj6-pn2-xmo0OPFdlJg6@dave2_os2.home.ours>   E On Wed, 31 May 2006 01:49:20 UTC, bill@cs.uofs.edu (Bill Gunshannon)   wrote:   > > 9 > > This makes writing robust applications easier on VMS.  > D > If the application requires robustness, then it isn't TCPIP's job,C > it's the applications.  TCPIP provides all the tools needed to do C > that.  You can always write your application using UDP and do all D > of the session management in your application, making it as robust > as you want.  C Agreed Bill but JF's point is that VMS, in general, and DecNet, in  F particular, make it less work for the developer and I believe that to  be the case.  A I have two versions of a server app. One uses DecNet,  the other   TCPIP.  D The DecNet one is more robust partly because of the programming but F mainly because it 'just works' and tells me when and why it doesn't. IF accept that the error handling in the TCPIP one is less effective but D that's because it requires a lot more work to be done and the bloke , who implemented it didn't understand it all.  B I didn't fully understand the DecNet one when I wrote it but it's E still more robust.  Thanks in both cases to the code in xxx$EXAMPLES.    --   Cheers - Dave W.   ------------------------------  % Date: Wed, 31 May 2006 03:33:39 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) , Message-ID: <447D46B6.33AAB4E5@teksavvy.com>   Dave Weatherall wrote:E > The DecNet one is more robust partly because of the programming but G > mainly because it 'just works' and tells me when and why it doesn't.    E You can also look at the terminal driver versus the  TCPIP stack. The G terminal driver has the SS$M_TIMEOUT modifier when you are reading data C from a serial port.  The TCPIP stack doesn't (and that includes the ? socket routines that emulate the unix programming environment).   D So when coding some application, it is much easier to build a robustD application that handles timeouts in i/o on VMS than on UNIX (or VMSF with TCPIP) simply because you have to code the timeouts yourself with tcpip and/or unix.  B ASTs also allow you to build very elegant applications that can beH responsive even when the main loop is busy. (for instance, interrogatingF a server process for its current status, the AST can handle that shortB transaction to tell the system manager that the server is curently processing a transaction).    F Now, I am sure that many could come with examples of Unix being better" when coding certain applications.   F Consider databases. Which OS gave the most capabilities first ? It wasH VMS because of the richness of its system services as well as clusteringB capabilities and built-in distributed queue manager. Oracle had toF re-invent the wheel when it moved from VSm to Unix because Unix lackedH DLM. And that is a lot of work to be done to get the same capabilityu on Unix that you had/have on VMS.      C And by far, one of the biggest advantages of VMS is that the system E services are for the most part, extreemely well documented with smart C argument format and they work as documented and are quite powerfull F because of the structured arguments that let you ask for a whole bunch of items in a single request.    ------------------------------   Date: 31 May 2006 12:31:18 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) , Message-ID: <4e5gklF1cgv0nU1@individual.net>  ? In article <DTiotGxQ0bj6-pn2-xmo0OPFdlJg6@dave2_os2.home.ours>, 5 	"Dave Weatherall" <djw-nothere@nospam.nohow> writes: G > On Wed, 31 May 2006 01:49:20 UTC, bill@cs.uofs.edu (Bill Gunshannon)   > wrote: >  >> >  : >> > This makes writing robust applications easier on VMS. >>  E >> If the application requires robustness, then it isn't TCPIP's job, D >> it's the applications.  TCPIP provides all the tools needed to doD >> that.  You can always write your application using UDP and do allE >> of the session management in your application, making it as robust  >> as you want.  > E > Agreed Bill but JF's point is that VMS, in general, and DecNet, in  H > particular, make it less work for the developer and I believe that to  > be the case.  B Even if it was true, which I don't agree with (I still think it isD more a matter of which one the programmer knows better) it is likelyC due more to differences in the total model of the protocol than any G inherent superiority.  We have undergrads who write servers and clients C for TCPIP, usually in less than 24 hours from the assignement being ? given out and that is with students coming into the course with C absolutely no experience with networking at all.  Of course, I have D no doubt that they could do the same thing with DECNET, but it shows3 that TCPIP is not particularly hard to program for.    > C > I have two versions of a server app. One uses DecNet,  the other   > TCPIP.  F And at the time you wrote them, which one were you more familiar with?3 Or did you have no experience with either protocol?    > F > The DecNet one is more robust partly because of the programming but F > mainly because it 'just works' and tells me when and why it doesn't.  H You keep bringing up this robustness thing.   Be nice to see it defined.K Why?  Because I think it consists mostly of concepts that were specifically E left out of TCP because they didn't belong at that level.  Robustness C belongs at the application level.  And IP allows for that.  TCP has @ robustness too, but probably not the way you are thinking of it.C Query:  What happens to a DECNET connection if the path between two E nodes goes away?  I assume it dies and reports back to both ends that B there is no longer a path.  I assume that is what you are calling E "robustness".  TCPIP on the other hand is robust in quite a different H way.  If the path between two nodes goes away the connection is designedG not to break.  One reason for this is to allow for finding an alternate D path if it exists.  Another is that the path may come back.  Now, ifC the connection is time critical, it becomes the applications job to G know that a path between the nodes no longer exists and to deal with it 0 at the application layer.  Not TCPIP's job, man.  D Like most of the stuff that people argue here, it is not a matter ofG superiority/inferiority, just a matter of different design philosophies G because the designers had different ideas of functionality in mind when  they designed the protocol.   H >                                                                      ID > accept that the error handling in the TCPIP one is less effective   A I don't know what you mean by error handling, but I think you are B lumping a bunch of application layer stuff into the network layer.B How much the network layer handles depends on wether you are using= TCP or UDP and what parameters are are set (like Keep_Alive).   I >                                                                    but  F > that's because it requires a lot more work to be done and the bloke . > who implemented it didn't understand it all.  F I thnk he understood it perfectly well.  He just decided not to do theD application layers work in the network layer.  :-)  Just because youE don't agree with the way he did it doesn't mean he didn't understand.    > D > I didn't fully understand the DecNet one when I wrote it but it's G > still more robust.  Thanks in both cases to the code in xxx$EXAMPLES.   E Like I said, there are different ways to be robust.  Doing one layers G job in another layer does not particularly mean the protocol is robust.    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: 31 May 2006 12:45:41 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) , Message-ID: <4e5hfkF1d335mU1@individual.net>  , In article <447D46B6.33AAB4E5@teksavvy.com>,0 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > Dave Weatherall wrote:F >> The DecNet one is more robust partly because of the programming butH >> mainly because it 'just works' and tells me when and why it doesn't.  > G > You can also look at the terminal driver versus the  TCPIP stack. The I > terminal driver has the SS$M_TIMEOUT modifier when you are reading data E > from a serial port.  The TCPIP stack doesn't (and that includes the A > socket routines that emulate the unix programming environment).   M Well, I certainly don't see what a terminal driver has to do with networking, H but I'll humor you.  What do you want it to timeout on?  Return before aK complete packet has been received?  Or do you mean return on a timeout when I no data is being received.  I would be amazed if none of the TCPIP stacks  for VMS could do that!!    > F > So when coding some application, it is much easier to build a robustF > application that handles timeouts in i/o on VMS than on UNIX (or VMSH > with TCPIP) simply because you have to code the timeouts yourself with > tcpip and/or unix.  F Please describe these "timeouts" you have to code yourself?  And whileD your at it, let's look at wether they belong in the network layer orF the application layer int he first place.  I am beginning to think youJ are talking about application timing issues and not network timing issues.   > D > ASTs also allow you to build very elegant applications that can beJ > responsive even when the main loop is busy. (for instance, interrogatingH > a server process for its current status, the AST can handle that shortD > transaction to tell the system manager that the server is curently > processing a transaction). >  > H > Now, I am sure that many could come with examples of Unix being better$ > when coding certain applications.   E Neither of them is "better", only different.  DECNET does things that B TCPIP doesn't do and TCPIP does thngs that DECNET doesn't do.  TheE target of both designers was different, otherwise, they would both be B exactly the same.  They were designed to work in totally differentC environments and thus they have to behave accordingly for those two  different environments.    > H > Consider databases. Which OS gave the most capabilities first ? It wasJ > VMS because of the richness of its system services as well as clusteringD > capabilities and built-in distributed queue manager. Oracle had toH > re-invent the wheel when it moved from VSm to Unix because Unix lackedJ > DLM. And that is a lot of work to be done to get the same capabilityu on  > Unix that you had/have on VMS.  I And VMS's advantages in clustering have always been one of its strengths. G SO sing its praises to high heaven.  But arguing that because DECNET is G different from TCPIP it is somehow inherently better is just silliness.    >  >  > E > And by far, one of the biggest advantages of VMS is that the system = > services are for the most part, extreemely well documented    B Sigh......  Unix "services" are more than well enough documentd toD satisfy their user communities.  Arguing that you don't like the wayG their written is like arguing that "Faust" is a lousy book cause Goethe & wrote it in German instead of English.  H >                                                             with smart > argument format   A Not sure what "smart argument format" is supposed to be.  Maybe I A need to start inventing my own terms for things too.  Would make   debating much easier.  :-)  . >                 and they work as documented   9 Name one Unix "service" that does not work as documented?   F >                                              and are quite powerfullH > because of the structured arguments that let you ask for a whole bunch > of items in a single request.   G Not sure what this means either.  The called routine should expect well H defined parameters and it sholdn't accept anything else.  But that is so? obvious I must be compeltely missing what you really mean here.    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: 31 May 2006 07:51:25 -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: <5YYdj6UdtO+d@eisner.encompasserve.org>   W In article <4e49anF1c7u84U2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: . > In article <447CDC11.A61BF658@teksavvy.com>,2 > 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: >> bradhamilton wrote:J >>> (many times) has been, "but it's *so* much easier to do X in Unix".  I >>   >>  0 >> But its is easier to do X  *PROPERLY* on VMS. >>   > H > Absolutely no support for this beyond the typical religious arguments. >   C    Depends on what X is.  Yes there are tons of religious arguments G    for or against that statement.  There are also facts which will lend H    themselves to some X on UNIX and some X on VMS and some X on Mac, ...  E    And there are too many people willing to make claims that actually G    boil down to "I know how to do X on Y" and human propensity to think 9    that the first way they learned must be the right one.   H    This even happens in entertainment.  A friend of mine stopped readingC    some books when he realised that it spoiled his enjoyment of the 	    movie.    ------------------------------   Date: 31 May 2006 13:21:31 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) , Message-ID: <4e5jirF1c9vevU1@individual.net>  3 In article <RF5hukbZkzlB@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:Y > In article <4e3vouF1cn7prU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:  >>  G >> Except that this seems to be the only place in the world that thinks H >> Unix is a poor example.  Most people in the industry admit that thereK >> is more than one right way to do most tasks. This little (and shrinking) K >> conclave seems to be unique in in the idea that they have the only right  >> way to do things. > E >    Not the "only right way".  One of several possible better ways.    E "Better" is a matter of opinion.  Different, yes, but not necessarily E better in all cases.  Just like programming languages and hand tools, J one size does not fit all.  The right tool for the job.  VMS has strengthsG that make it the ideal, even perfect, tool for some jobs, but that does E not translate to all jobs and the industry understands that.  VMS and H its advocates need to start concentrating on where they are that perfectJ fit and stop trying to convince the world that they are the do-all, be-allG of the computing industry.  Time for another analogy:  It's like trying M to teach a pig to sing.  Do you remember what Mark Twain said about that? :-)   F >    Anyone who studies human interfaces or learns from the history ofG >    UNIX security issues can discover that the late 1960's approach to # >    each belongs in the late 60's.   C Wait a minute!!!  Human interfaces?  Which one is still primarily a J command line interface?  How 60's can you get?  Which one's GUI technologyF has kept pace with modern changes?  As for security issues, there haveD been massive changes at the OS level to address these issues many ofF which weren't issues until some idiot decided to let the masses on theG INTERNET instead of making them go out and build their own pen to foul.    > A >    You seem to live in a small world.  You should get out more.   F How do I live in a small world?  Are you now going to try and convinceF me that there are more VMS systems in use than Unix?  And that Unix is shrinking while VMS is growing?     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: 31 May 2006 07:37:46 -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: <95X9GptLR3W4@eisner.encompasserve.org>   k In article <447cc09d$0$60781$157c6196@dreader1.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes:   K > Well in order to get parameters on VMS you have to learn the CLI API and  I > you have to write a CLD file.  Compare that to the *NIX way of passing  ' > two parameters to the "main" routine.   E    No.  Passing parameters to main also works on VMS.  As a matter of B    fact it works even if you're not programming in C since you can<    call lib$get_foreign and lib$find_file from any language.  8 > Further, wildcard processing is not directly included  > in languages like Pascal.   E    It's not part of the language, and there's no reason is has to be; A    it's part of the OS.  Since we're discussing OS features, that #    actually makes it more relavent.   @    So tell me, on UNIX how dos a Fortran programmer access those:    pre-expanded command line arguments?  How about Pascal?  C    The UNIX approach means doing something like a shell for loop in G    order to affect the equivalent of a DCL "copy *.a *.b".  So it often D    means programming even for a non-programmer.  Hardly a savings of    code.  /    Do you rally want to start a flame war here?    ------------------------------    Date: 31 May 2006 07:40:28 -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: <RF5hukbZkzlB@eisner.encompasserve.org>   W In article <4e3vouF1cn7prU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:  > F > Except that this seems to be the only place in the world that thinksG > Unix is a poor example.  Most people in the industry admit that there J > is more than one right way to do most tasks. This little (and shrinking)J > conclave seems to be unique in in the idea that they have the only right > way to do things.   C    Not the "only right way".  One of several possible better ways.  D    Anyone who studies human interfaces or learns from the history ofE    UNIX security issues can discover that the late 1960's approach to !    each belongs in the late 60's.   ?    You seem to live in a small world.  You should get out more.    ------------------------------    Date: 31 May 2006 07:43:28 -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: <4nZaGCKDa24s@eisner.encompasserve.org>   ` In article <VZ4fg.1262$9j4.180@news.cpqcorp.net>, Hoff Hoffman <hoff-remove-this@hp.com> writes: > ' > "Perpetual fruitless debate", anyone?  >   G    Yes, we've gotten way off topic here.  Note the title had to do only &    with the speed at which things run.   ------------------------------    Date: 31 May 2006 07:46:42 -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: <NYtqUcLYwHJ+@eisner.encompasserve.org>   W In article <4e4952F1c7u84U1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:   2 > I usually show things to be easier on Unix afterI > someone here either says "Unix can't do that" or they come up with some I > totally convoluted way of doing it on Unix.   It is actually the people J > here who consistantly argue that everything is harder on UNix and easier > on VMS.     C    Oh come now, don't we all know that "rm -f /" is easier to do on ;    UNIX?  Is there any VMS bigot who would claim otherwise?    > F > More power to you. But, remember that this whole thread started withG > someone here posting total drivel about Unix in order to somehow make  > VMS look superior.  H    Look at the title.  The thread started with someone posting FUD about    UNIX being faster.    ------------------------------    Date: 31 May 2006 07:53:57 -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: <m5IRo$mor5sm@eisner.encompasserve.org>   \ In article <447CF378.2DFA184C@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > Bill Gunshannon wrote:G >> And, if you put in the same level of work on a Unix system you would & >> also end out with a better product. >  > C > Not true for everything. Consider DECNET. When you write a decnet G > server, you have a notification mailbos that gets messages when a new E > call comes in, and when a call is dicsonnected. So the server knows A > right away that the connection to a client has been terminated.  > F > For TCPIP, you need to wait for a timeout vecause the TCPIP software1 > doesn't realise that a connection has been cut.  > 7 > This makes writing robust applications easier on VMS.         DECnet != VMS.  IP != UNIX.  G    You can get DECnet for just about every UNIX you can get, and enjoy       the same protocol features.    C    Sometimes you have to use IP on VMS and suffer the same timeout.    ------------------------------   Date: 31 May 2006 13:51:06 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) , Message-ID: <4e5laaF1d0nsrU1@individual.net>  3 In article <95X9GptLR3W4@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:m > In article <447cc09d$0$60781$157c6196@dreader1.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes:  > L >> Well in order to get parameters on VMS you have to learn the CLI API and J >> you have to write a CLD file.  Compare that to the *NIX way of passing ( >> two parameters to the "main" routine. > G >    No.  Passing parameters to main also works on VMS.  As a matter of D >    fact it works even if you're not programming in C since you can> >    call lib$get_foreign and lib$find_file from any language. > 9 >> Further, wildcard processing is not directly included   >> in languages like Pascal. > G >    It's not part of the language, and there's no reason is has to be; C >    it's part of the OS.  Since we're discussing OS features, that % >    actually makes it more relavent.   H And this is yet another difference in philosophy where some people thinkG thier way is the only right way.  Unix philosophy was that this was NOT I the OSes concern but an application problem.  And they provided more than  enough ways to actually do it.   > B >    So tell me, on UNIX how dos a Fortran programmer access those< >    pre-expanded command line arguments?  How about Pascal?  F Well, I would have to look at a book on something more modern than F77H which was the last Fortran i worked extensively with, but at that point,L Fortran had no mechanism for dealing with parameters so it wasn't necessary.G I think some Fortrans had local extensions to do this, but it was not a J part of the language.  While we are at it, how does RSTS or RSX Fortran doG it?  How about VM/CMS?  While it is nice that VMS came up with a way to I do a non-standard thing, it doesn't mean all the others are wrong because H they chose not to do somethng the language didn't specify.  Pascal, as aG language, does not define "passing command line parameters".  So again, F while it is nice that you do it, it is not really PAscal and you can'tD fault those that choose not to do it.  But, just to muddy the watersH even more, I can think of more than one way to get access to the commandD line used to invoke either a Pascal or Fortran program on any of the
 Unixes I use.      > E >    The UNIX approach means doing something like a shell for loop in I >    order to affect the equivalent of a DCL "copy *.a *.b".  So it often F >    means programming even for a non-programmer.  Hardly a savings of
 >    code.  E And, if that had been a problem in the first place someone would have H long ago written a utility specifically to do that task.  Software ToolsG approach.  The basis for most of Unix's philosophy.  The fact that such H a utility doesn't exist tells me it is 1. not very common and 2. trivialJ to deal with using the existing Unix tools.  Oh, and by the way, the firstK method to do this that came to my mind did not involve a "for" loop at all.    > 1 >    Do you rally want to start a flame war here?   K I don't ever want to start a flame war.  I just want people to realize that J VMS isn't the only answer.  And by trying to convince an industry that hasK all but abandoned VMS that they are all wrong and must be idiots to not see E that VMS is the one true religion they are doing more harm than good.   I Once again, VMS has strengths.  Push them.  Look for the places where VMS G can definitely do a better job than Unix or anyh other OS and work hard J to convince those people that they need to use the right tool for the job.G But don't continue to try and prove something that isn't true regarding G VMS vs. Unix using outdated and just plain wrong information.  It makes H both the arguer and VMS look bad and extends this "legacy" understanding
 that VMS has.     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: 31 May 2006 14:01:33 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) , Message-ID: <4e5ltsF1d0nsrU3@individual.net>  3 In article <NYtqUcLYwHJ+@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:Y > In article <4e4952F1c7u84U1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:  > 3 >> I usually show things to be easier on Unix after J >> someone here either says "Unix can't do that" or they come up with someJ >> totally convoluted way of doing it on Unix.   It is actually the peopleK >> here who consistantly argue that everything is harder on UNix and easier  >> on VMS.   > E >    Oh come now, don't we all know that "rm -f /" is easier to do on = >    UNIX?  Is there any VMS bigot who would claim otherwise?   ; And if a regular user does that, what do you think happens?   I Now, if the user with SYSTEM privs (whatever the user name happens to be) H types DEL [000000]*.*;* what happens?  Stupidity is stupidity regardless of which OS it is applied on.    >  >>  G >> More power to you. But, remember that this whole thread started with H >> someone here posting total drivel about Unix in order to somehow make >> VMS look superior.  > J >    Look at the title.  The thread started with someone posting FUD about >    UNIX being faster.    G FUD is in the eye of the beholder.  They were also comparing apples and M oranges because they didn't take into consideration configuration differences J in the default setup of the systems.  Maybe what needs to be done just forI grins is to set up a system with both VMS and Unix and run a bunch of the 9 more common benchmarks.  Which one do you think will win?    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: 31 May 2006 06:40:12 -0700 From: bob@instantwhip.com M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) C Message-ID: <1149082812.133539.265810@j55g2000cwa.googlegroups.com>    Bill Gunshannon wrote: > G > Neither of them is "better", only different.  DECNET does things that D > TCPIP doesn't do and TCPIP does thngs that DECNET doesn't do.  TheG > target of both designers was different, otherwise, they would both be D > exactly the same.  They were designed to work in totally differentE > environments and thus they have to behave accordingly for those two  > different environments.   ? so according to your argument, OpenVMS can do DECNET over IP so  that means it is superior! :)    ------------------------------   Date: 31 May 2006 13:55:23 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) , Message-ID: <4e5liaF1d0nsrU2@individual.net>  3 In article <5YYdj6UdtO+d@eisner.encompasserve.org>, > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:Y > In article <4e49anF1c7u84U2@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: / >> In article <447CDC11.A61BF658@teksavvy.com>, 3 >> 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes:  >>> bradhamilton wrote: K >>>> (many times) has been, "but it's *so* much easier to do X in Unix".  I  >>>  >>> 1 >>> But its is easier to do X  *PROPERLY* on VMS.  >>>  >>  I >> Absolutely no support for this beyond the typical religious arguments.  >>   > E >    Depends on what X is.  Yes there are tons of religious arguments I >    for or against that statement.  There are also facts which will lend J >    themselves to some X on UNIX and some X on VMS and some X on Mac, ... > G >    And there are too many people willing to make claims that actually I >    boil down to "I know how to do X on Y" and human propensity to think ; >    that the first way they learned must be the right one.   A And this is precisely the point I have been trying to get across. D One is not necessarily better than the other, only different.  WhichD one is easier is more likely to be a matter of which you know better% or, often, just Mother Duck Syndrome.    > J >    This even happens in entertainment.  A friend of mine stopped readingE >    some books when he realised that it spoiled his enjoyment of the  >    movie.   C Funny, I find the opposite to be true, which is why I seldom go the  movies any more.   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: Wed, 31 May 2006 15:24:20 GMT ' From: Steve Thompson <smt@vgersoft.com> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) A Message-ID: <Pine.LNX.4.58.0605311123450.10600@vger.vgersoft.com>   $ On Tue, 30 May 2006, JF Mezei wrote:  F > For TCPIP, you need to wait for a timeout vecause the TCPIP software1 > doesn't realise that a connection has been cut.   ' Of course you don't. That's ridiculous.    Steve    ------------------------------  % Date: Wed, 31 May 2006 17:28:15 +0200 + From: Karsten Nyblad <nospam@nospam.nospam> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) = Message-ID: <447db5dd$0$67257$157c6196@dreader2.cybercity.dk>    Bob Koehler wrote:m > In article <447cc09d$0$60781$157c6196@dreader1.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes: G >    No.  Passing parameters to main also works on VMS.  As a matter of D >    fact it works even if you're not programming in C since you can> >    call lib$get_foreign and lib$find_file from any language.  K And?  At best it is an even harder way to get a VMS like command interface.     8 >>Further, wildcard processing is not directly included  >>in languages like Pascal.  >  > G >    It's not part of the language, and there's no reason is has to be; C >    it's part of the OS.  Since we're discussing OS features, that % >    actually makes it more relavent.   G Digital/Compaq/HP has for years been selling compilers for Fortran and  E Pascal with extensions for VMS, yet they have not made it easy to do  H wildcard processing.  You would have to write hundreds of lines of code I if you want wildcard procesing to be like it is in the VMS commands.  It  G is hard for me to see that the VMS way of doing wildcard processing is  H better, when there is so little support for it in the runtime libraries.  B >    So tell me, on UNIX how dos a Fortran programmer access those< >    pre-expanded command line arguments?  How about Pascal?  4 I have never been writing Pascal or Fortran on *NIX.  E >    The UNIX approach means doing something like a shell for loop in I >    order to affect the equivalent of a DCL "copy *.a *.b".  So it often F >    means programming even for a non-programmer.  Hardly a savings of
 >    code.  H Changing the file type is not a common operation on an operating system , where file types are not natively supported.  1 >    Do you rally want to start a flame war here?   G No, but I wonder if you do.  You keep using examples from years ago to  A put down current days *NIX.  Why should anybody take advise from  H somebody doing that?  Do you really think you do VMS any good that way? I   You would do VMS a larger favor by simply stating the you love working  I on VMS and that you want to work on that platform even in cases where it   might not be the best solution.   F Please note that in some cases it is a good idea to select a platform @ simply because the best people you can get like working on that H platform.  E.g., I once read an article advising people to use Linux in F stead of Windows because the best programmers prefer Linux to Windows.   ------------------------------    Date: 31 May 2006 09:27:58 -0700+ From: "Dr. Dweeb" <comp.os.vms@hotmail.com> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) C Message-ID: <1149092878.006283.117110@u72g2000cwu.googlegroups.com>    Bill Gunshannon wrote:. > In article <447D46B6.33AAB4E5@teksavvy.com>,2 > 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > > Dave Weatherall wrote:H > >> The DecNet one is more robust partly because of the programming butI > >> mainly because it 'just works' and tells me when and why it doesn't.  > > I > > You can also look at the terminal driver versus the  TCPIP stack. The K > > terminal driver has the SS$M_TIMEOUT modifier when you are reading data G > > from a serial port.  The TCPIP stack doesn't (and that includes the C > > socket routines that emulate the unix programming environment).  > O > Well, I certainly don't see what a terminal driver has to do with networking, J > but I'll humor you.  What do you want it to timeout on?  Return before aM > complete packet has been received?  Or do you mean return on a timeout when K > no data is being received.  I would be amazed if none of the TCPIP stacks  > for VMS could do that!!  >  > > H > > So when coding some application, it is much easier to build a robustH > > application that handles timeouts in i/o on VMS than on UNIX (or VMSJ > > with TCPIP) simply because you have to code the timeouts yourself with > > tcpip and/or unix. > H > Please describe these "timeouts" you have to code yourself?  And whileF > your at it, let's look at wether they belong in the network layer orH > the application layer int he first place.  I am beginning to think youL > are talking about application timing issues and not network timing issues. >  > > F > > ASTs also allow you to build very elegant applications that can beL > > responsive even when the main loop is busy. (for instance, interrogatingJ > > a server process for its current status, the AST can handle that shortF > > transaction to tell the system manager that the server is curently > > processing a transaction). > >  > > J > > Now, I am sure that many could come with examples of Unix being better% > > when coding certain applications.  > G > Neither of them is "better", only different.  DECNET does things that D > TCPIP doesn't do and TCPIP does thngs that DECNET doesn't do.  TheG > target of both designers was different, otherwise, they would both be  > exactly the same.   F >From an otherwise apparently intelligent person, that is a remarkably. unintelligent, logically invalid thing to say.  1 > They were designed to work in totally different E > environments and thus they have to behave accordingly for those two  > different environments.  >  > > J > > Consider databases. Which OS gave the most capabilities first ? It wasL > > VMS because of the richness of its system services as well as clusteringF > > capabilities and built-in distributed queue manager. Oracle had toJ > > re-invent the wheel when it moved from VSm to Unix because Unix lackedL > > DLM. And that is a lot of work to be done to get the same capabilityu on" > > Unix that you had/have on VMS. > K > And VMS's advantages in clustering have always been one of its strengths. I > SO sing its praises to high heaven.  But arguing that because DECNET is I > different from TCPIP it is somehow inherently better is just silliness.  >  > >  > >  > > G > > And by far, one of the biggest advantages of VMS is that the system > > > services are for the most part, extreemely well documented > D > Sigh......  Unix "services" are more than well enough documentd toF > satisfy their user communities.  Arguing that you don't like the wayI > their written is like arguing that "Faust" is a lousy book cause Goethe ( > wrote it in German instead of English. > J > >                                                             with smart > > argument format  > C > Not sure what "smart argument format" is supposed to be.  Maybe I B > need to start inventing my own terms for things too.  Would make > debating much easier.  :-) > / > >                 and they work as documented  > ; > Name one Unix "service" that does not work as documented?  > H > >                                              and are quite powerfullJ > > because of the structured arguments that let you ask for a whole bunch! > > of items in a single request.  > I > Not sure what this means either.  The called routine should expect well J > defined parameters and it sholdn't accept anything else.  But that is soA > obvious I must be compeltely missing what you really mean here.  >  > bill >  > --L > Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesF > bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. > University of Scranton   |@ > Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------    Date: 31 May 2006 09:32:05 -0700+ From: "Dr. Dweeb" <comp.os.vms@hotmail.com> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) C Message-ID: <1149093125.921723.274460@j55g2000cwa.googlegroups.com>    Bill Gunshannon wrote:A > In article <DTiotGxQ0bj6-pn2-xmo0OPFdlJg6@dave2_os2.home.ours>, 7 > 	"Dave Weatherall" <djw-nothere@nospam.nohow> writes: H > > 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.  > > F > > Agreed Bill but JF's point is that VMS, in general, and DecNet, inI > > 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.  >  > > D > > 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?  >  > > G > > 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 # > belongs at the application level.   D And that would be in the same way that data integrity belongs at the? application leval rather that the adatabase management level ??   G You statement is rather like saying that structural integrity is in the ( walls, not the foundations. WTC anyone ?  " > And IP allows for that.  TCP hasB > 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 C > there is no longer a path.  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. > 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.  > J > >                                                                      IE > > 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).  > J > >                                                                    butG > > 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.  >  > > E > > 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.  >  > bill >  > --L > Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesF > bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. > University of Scranton   |@ > Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------    Date: 31 May 2006 09:53:00 -0700 From: bob@instantwhip.com M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) B Message-ID: <1149094380.215059.62620@j55g2000cwa.googlegroups.com>   Karsten Nyblad wrote: J >   You would do VMS a larger favor by simply stating the you love workingJ > on VMS and that you want to work on that platform even in cases where it! > might not be the best solution.   F and when is the best security, clustering, reliability and TCO not the best	 solution?    ------------------------------  % Date: Wed, 31 May 2006 13:04:14 -0400 ' From: Dave Froble <davef@tsoft-inc.com> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) 9 Message-ID: <vrmdnezKCIpPVuDZnZ2dnUVZ_vqdnZ2d@libcom.com>    Bill Gunshannon wrote:5 > In article <RF5hukbZkzlB@eisner.encompasserve.org>, @ > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:Z >> In article <4e3vouF1cn7prU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:H >>> Except that this seems to be the only place in the world that thinksI >>> Unix is a poor example.  Most people in the industry admit that there L >>> is more than one right way to do most tasks. This little (and shrinking)L >>> conclave seems to be unique in in the idea that they have the only right >>> way to do things. F >>    Not the "only right way".  One of several possible better ways.  > G > "Better" is a matter of opinion.  Different, yes, but not necessarily G > better in all cases.  Just like programming languages and hand tools, L > one size does not fit all.  The right tool for the job.  VMS has strengthsI > that make it the ideal, even perfect, tool for some jobs, but that does G > not translate to all jobs and the industry understands that.  VMS and J > its advocates need to start concentrating on where they are that perfectL > fit and stop trying to convince the world that they are the do-all, be-allI > of the computing industry.  Time for another analogy:  It's like trying O > to teach a pig to sing.  Do you remember what Mark Twain said about that? :-)  > G >>    Anyone who studies human interfaces or learns from the history of H >>    UNIX security issues can discover that the late 1960's approach to$ >>    each belongs in the late 60's. > E > Wait a minute!!!  Human interfaces?  Which one is still primarily a L > command line interface?  How 60's can you get?  Which one's GUI technologyH > has kept pace with modern changes?  As for security issues, there haveF > been massive changes at the OS level to address these issues many ofH > which weren't issues until some idiot decided to let the masses on theI > INTERNET instead of making them go out and build their own pen to foul.  > B >>    You seem to live in a small world.  You should get out more. > H > How do I live in a small world?  Are you now going to try and convinceH > me that there are more VMS systems in use than Unix?  And that Unix is! > shrinking while VMS is growing?  >    > bill >   G I get real tired of reading about how Unix is thriving and VMS is not.  F It's always stated in a manner that suggests that it's the OS that is  causing this effect.  B Can anyone possibly conceive the notion that VMS runs on only one G currently produced CPU and on systems (not the most desired) from only  K one vendor?  Do you think this might have something to do with the numbers?   ? Add to this Palmer driving away hugh numbers of ISVs using VMS.   0 Add to this the lack of any promotion of the OS.  ! Add killing Alpha, and more .....   I Now, once again, tell me just how much of the OS selection is determined   by the OS capabilities.   H I'll suggest that if all else were equal, VMS would be chosen over Unix E more often than not.  As an example, in the 80s, when a rather large  G percentage of computers in use (before PCs) were VAXs, what percentage  & ran VMS, and what percentage ran Unix?  F If you want to talk about reasons there is more use of Unix than VMS, ? I've given you a list, and none of them are about capabilities.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------   Date: 31 May 2006 17:13:56 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) , Message-ID: <4e616kF1d1a31U1@individual.net>  C In article <1149093125.921723.274460@j55g2000cwa.googlegroups.com>, . 	"Dr. Dweeb" <comp.os.vms@hotmail.com> writes: >  > Bill Gunshannon wrote:B >> In article <DTiotGxQ0bj6-pn2-xmo0OPFdlJg6@dave2_os2.home.ours>,8 >> 	"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.  >> >> H >> >> If the application requires robustness, then it isn't TCPIP's job,G >> >> it's the applications.  TCPIP provides all the tools needed to do G >> >> that.  You can always write your application using UDP and do all H >> >> 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.  >>E >> Even if it was true, which I don't agree with (I still think it is G >> more a matter of which one the programmer knows better) it is likely F >> due more to differences in the total model of the protocol than anyJ >> inherent superiority.  We have undergrads who write servers and clientsF >> for TCPIP, usually in less than 24 hours from the assignement beingB >> given out and that is with students coming into the course withF >> absolutely no experience with networking at all.  Of course, I haveG >> no doubt that they could do the same thing with DECNET, but it shows 6 >> that TCPIP is not particularly hard to program for. >> >> >E >> > I have two versions of a server app. One uses DecNet,  the other  >> > TCPIP.  >>I >> And at the time you wrote them, which one were you more familiar with? 6 >> Or did you have no experience with either protocol? >> >> >H >> > The DecNet one is more robust partly because of the programming butI >> > mainly because it 'just works' and tells me when and why it doesn't.  >>K >> You keep bringing up this robustness thing.   Be nice to see it defined. N >> Why?  Because I think it consists mostly of concepts that were specificallyH >> left out of TCP because they didn't belong at that level.  Robustness$ >> belongs at the application level. > F > And that would be in the same way that data integrity belongs at theA > application leval rather that the adatabase management level ??   E The subject was robustness at the network level.  The 7 layered model G (wether you accept the OSI or IP descriptions of said) does not include D a database management layer.  That would, as a matter of fact, be in- the application layer.  Where it belongs. :-)    > I > You statement is rather like saying that structural integrity is in the * > walls, not the foundations. WTC anyone ?  K We were discussing the robustness of two network protocols.  Both have well F defined layers and what goes into them.  Has nothing to do with walls, foundatuions or the WTC.   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: 31 May 2006 17:33:17 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) , Message-ID: <4e62atF1d1bu9U1@individual.net>  9 In article <vrmdnezKCIpPVuDZnZ2dnUVZ_vqdnZ2d@libcom.com>, * 	Dave Froble <davef@tsoft-inc.com> writes: > I > I get real tired of reading about how Unix is thriving and VMS is not.    K I get tired of reading about rising taxes, rising interest rates and rising . crime rates.  Doesn't make them any less true.  H > 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.   > D > Can anyone possibly conceive the notion that VMS runs on only one I > currently produced CPU and on systems (not the most desired) from only  M > one vendor?  Do you think this might have something to do with the numbers?   J And why is that?  Could it be that its last few owners have not thought itI stood a chance competing with the alternatives and chose to milk the cash J cow to death rather than trying to fatten it up enough for it to carry its own weight?    > A > Add to this Palmer driving away hugh numbers of ISVs using VMS.    Why is that?  See above.   > 2 > Add to this the lack of any promotion of the OS. > # > Add killing Alpha, and more .....   H I won't keep repeating the above, but surely the people who did all thisH had to have a reason, even if no one on the outside saw it the same way.   > K > Now, once again, tell me just how much of the OS selection is determined   > by the OS capabilities.   F As late as the early Alpha days, there is little if any doubt that VMSG was superior in capabilities.  But times have changed.  the competition I turned commercial in a big way and moved forward to a greater extent than F VMS did.  With the possible exception of clustering most modern UnixesH 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.   J >                                           VMS would be chosen over Unix 3 > more often than not.  As an example, in the 80s,    G There we go, living int he past again.  Back int he 80's VMS was pretty G much superior to all the available Unixes.  But this isn't the 80's and  Unix didn't stand still.  G >                                                  when a rather large  I > percentage of computers in use (before PCs) were VAXs, what percentage  ( > ran VMS, and what percentage ran Unix?  I It would be interesting to see real (from a source that could be trusted) H numbers.  I know from personal experience backin the 80's I saw more VAXK running VMS than Unix.  But then I saw more systems of other architectures  + than VAX and the majority of them ran Unix.    > H > If you want to talk about reasons there is more use of Unix than VMS, A > I've given you a list, and none of them are about capabilities.   D Yes, but I still hold that the background reason for many of the badD decisions above were that people in a position to make the decisionsE could not see VMS competing.  In any event, it changes nothing.  Unix D is still growing and VMS is shrinking.  Professionals trying to pushE VMS by souting off obviously wrong information about Unix don't help, G they just loose even more credibility with the managers they are trying C to convince and relegate VMS even further to the realm of "legacy".   B Even after my little poll which showed a number of people here who@ actually think VMS is the better OS, most of them still laugh atB the idea of actually using it.  Why do you think that is?  I know,? I'm the one they think is a dinosaur, with all my toys straight  out of the Jurasic Era.     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>       ------------------------------   End of INFO-VAX 2006.301 ************************