1 INFO-VAX	Sat, 27 May 2000	Volume 2000 : Issue 295       Contents:< Re: ??== OpenVMS and Windows NT Integration for Dummies bookK Re: Absolute fastest way to get a 100% correct record count for RMS  files? J Re: Absolute fastest way to get a 100% correct record count for RMS files?J Re: Absolute fastest way to get a 100% correct record count for RMS files?I Re: Absolute fastest way to get a 100% correct record count for RMSfiles?  Re: Capellas supports Microsoft  Re: ES40 Configuration Get Paid To Read Email!  5502 6 Re: How to export contents of RMS file to .csv format? Re: Jabber on OpenVMS?" Re: Looking for PW API information Re: MicroVMS 4.4 Re: MicroVMS 4.42 Re: OpenVMS and Windows NT Integration for Dummies* Re: OpenVMS vs Tru64 Pathworks performance* Re: OpenVMS vs Tru64 Pathworks performance& TCPIP$SMTP_RECV_RUN.LOG;32767 problem?* Re: TCPIP$SMTP_RECV_RUN.LOG;32767 problem? Re: TCPware window size ! Tru64 Unix Moving to Open Source?   F ----------------------------------------------------------------------  % Date: Sat, 27 May 2000 13:46:15 +0200 2 From: "Frits A.M. Storms" <frits@storms.tmfweb.nl>E Subject: Re: ??== OpenVMS and Windows NT Integration for Dummies book * Message-ID: <8gofu5$a6d$1@cyan.nl.gxn.net>  J Go to a Wild Fire meeting Compaq announced. I got my copy there this week.A It is very nice ! Full of ammo for silencing the NT & Unix buffs. = Longest uptime for a VMSsystem ? EIGHTEEN YEARS ! etcetera...  bye !  Frits x "Hans M. Aus" <aus@vim.uni-wuerzburg.de> wrote in message news:aus-2205000957420001@wvia21.virologie.uni-wuerzburg.de.... > These is any interesting OpenVMS article on: > 1 > http://www.theregister.co.uk/000521-000002.html  >  > K > How do I obtain a complimentary copy of the Dummies book mentioned at the  > end of the article?  >  > L > "Compaq is distributing its OpenVMS and Windows NT Integration for Dummies > book to the installed base." >  > --  D > Cheers, Hans M. Aus, Wuerzburg, Germany,  aus@vim.uni-wuerzburg.de   ------------------------------  % Date: Sat, 27 May 2000 06:27:27 +0200 $ From: Paul Sture <sture.ch@sture.ch>T Subject: Re: Absolute fastest way to get a 100% correct record count for RMS  files?+ Message-ID: <VA.0000005c.0690970f@sture.ch>   = In article <392E6C17.735A6EA5@mci.com>, Lonnie Carreau wrote: / > From: Lonnie Carreau <Lonnie.Carreau@mci.com>  > Newsgroups: comp.os.vms O > Subject: Re: Absolute fastest way to get a 100% correct record count for RMS  	 >  files? % > Date: Fri, 26 May 2000 12:20:31 GMT  > 4 > If you were going to use DCL, I would prefer this: > ' > $convert/nocreate/stat <filename> nl:  > N Nope. Search has intelligence and tries to use buffering. You can get convert P working faster if you up the RMS buffer size (SET RMS), but then again, you can M run out of dynamic memory. Search somehow works out what it can get and uses  ' that (I've never looked at the sources.    A very rough benchmark example:   O $ dir/siz=all ACCOUNTNG.DAT;4 ! This file is closed, so we don't have to worry   about locks    Directory SYS$SYSROOT:[SYSMGR]  " ACCOUNTNG.DAT;4        20527/20574  $ Total of 1 file, 20527/20574 blocks.' $ sea/stat ACCOUNTNG.DAT;4 "" /window=0 # SYS$SYSROOT:[SYSMGR]ACCOUNTNG.DAT;4   E Files searched:                 1       Buffered I/O count:         6 E Records searched:           60567       Direct I/O count:        1283 E Characters searched:     10361940       Page faults:               21 H Records matched:            60567       Elapsed CPU time:  0 00:00:00.58H Lines printed:                  1       Elapsed time:      0 00:00:07.70 $ conv/stat ACCOUNTNG.DAT;4 nl:     CONVERT Statistics $ Number of Files Processed:         1H Total Records Processed:       60567    Buffered I/O Count:            6H Total Exception Records:           0    Direct I/O Count:          61851H Total Valid Records:           60567    Page Faults:                  20H Elapsed Time:          0 00:00:07.52    CPU Time:          0 00:00:03.09  ! (Done on an 8400 with 6GB memory)   O As you can see, the elapsed times are similar, but this is only a 10MB file (I  # didn't check how fragmented it is).   M Compare the cpu times and direcot I/Os, and you will see that search is much   more efficient.   M The convert may have even benefitted from the file being in cache (repeating  E both tests did result in dramatically reduced cpu and elasped times).   P Plea to OpenVMS Engineering. It has been my long standing complaint, ever since M it was first released, that convert is so slow. Surely lifting the code from  + search would greatly benefit convert times?    >  > Phil Howell wrote: > G > > Using the theory "you can do an anything in dcl if you really want" . > > $search/log/noout/stat <filename> <string>$ > > will give you an accurate figure= > > You will have to compare it with other methods for speed.  > > Phil > > : > > Dann Corbit <dcorbit@solutionsiq.com> wrote in message& > > news:EgiX4.1939$pE1.2272@client...K > > > I want to get the fastest possible 100% accurate record count for RMS 
 > > files. > > > O > > > I tried both sys$get() and sys$find() and was astonished to see that they N > > > were the same speed.  I would think that sys$find() would be much faster7 > > > since it does not have to actually read the data.  > > > L > > > I don't care about indexes or anything of that nature.  I just want to > > know) > > > exactly how many records there are.  > > > L > > > I thought about simply doing an ordinary fopen(), seek to the end, andP > > > ftell() but record compression might screw up that calculation.  I do want > > > the exact current count. > > > L > > > I suspect that there is some brilliant way to do this that many of you > > guruL > > > types are aware of.  Please help an ignorant sack of cat dung find the > > > proper solution. > > >  > > > Many thanks in advance.  > > >  > > > --6 > > > C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html* > > >  "The C-FAQ Book" ISBN 0-201-84519-97 > > > C.A.P. Newsgroup   http://www.dejanews.com/~c_a_p O > > > C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm  > > >  >    ___ 
 Paul Sture Switzerland    ------------------------------  % Date: Sat, 27 May 2000 06:33:01 +0200   From: Paul Sture <paul@sture.ch>S Subject: Re: Absolute fastest way to get a 100% correct record count for RMS files? + Message-ID: <VA.0000005d.0695b139@sture.ch>   B In article <9DF6llOPrTvg@eisner.decus.org>, Larry Kilgallen wrote: >  [snip]C > Depending on your file and how you maintain it, there may be some D > greater locality of reference on the primary key, but I think thatB > would likely get lost in the noise when you consider that reallyB > one is dealing with "buckets" rather than "blocks".  To the bestB > of my knowledge, RMS does not engage in "read ahead" behavior on > indexed files. > [ But you can get very substantial gains by increasing the RMS buffer size. This _does_ give  C "read ahead" behaviour. Obviously not recommended for random reads.   E > And all of my comments are just based on shooting from the hip with H > a Usenet answer, not on actual experience.  Since you are the one withG > the need, you are the one who gets to experiment.  Please report back ) > with your results, so others can learn.  > W As always. His file, his circumstances. As you point out, a small piece of application  / code could be the real solution to the problem.  ___ 
 Paul Sture Switzerland    ------------------------------  % Date: Sat, 27 May 2000 09:42:06 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> S Subject: Re: Absolute fastest way to get a 100% correct record count for RMS files? ( Message-ID: <8goj66$ce5$1@pyrite.mv.net>  + Paul Sture <paul@sture.ch> wrote in message % news:VA.0000005d.0695b139@sture.ch... D > In article <9DF6llOPrTvg@eisner.decus.org>, Larry Kilgallen wrote: > >  > [snip]E > > Depending on your file and how you maintain it, there may be some F > > greater locality of reference on the primary key, but I think thatD > > would likely get lost in the noise when you consider that reallyD > > one is dealing with "buckets" rather than "blocks".  To the bestD > > of my knowledge, RMS does not engage in "read ahead" behavior on > > indexed files. > > K > But you can get very substantial gains by increasing the RMS buffer size.  This _does_ giveE > "read ahead" behaviour. Obviously not recommended for random reads.   L Are you referring to the RMS *bucket* size?  I guess increasing that (if oneL has the option) could be considered somewhat equivalent to 'read-ahead', butL the kind of 'read-ahead' I suspect Larry meant is the posting of disk accessI requests in advance of the need for the data (i.e., multi-buffering), not L simply requesting more data than you may immediately need in a single access, request (which larger buckets would enable).   - bill   > G > > And all of my comments are just based on shooting from the hip with J > > a Usenet answer, not on actual experience.  Since you are the one withI > > the need, you are the one who gets to experiment.  Please report back + > > with your results, so others can learn.  > > L > As always. His file, his circumstances. As you point out, a small piece of application 1 > code could be the real solution to the problem.  > ___  > Paul Sture
 > Switzerland  >    ------------------------------  % Date: Sat, 27 May 2000 11:58:29 -0400 * From: David A Froble <davef@tsoft-inc.com>R Subject: Re: Absolute fastest way to get a 100% correct record count for RMSfiles?- Message-ID: <392FF0A5.CCF959C8@tsoft-inc.com>    Bill Todd wrote: > - > Paul Sture <paul@sture.ch> wrote in message ' > news:VA.0000005d.0695b139@sture.ch... F > > In article <9DF6llOPrTvg@eisner.decus.org>, Larry Kilgallen wrote: > > > 
 > > [snip]G > > > Depending on your file and how you maintain it, there may be some H > > > greater locality of reference on the primary key, but I think thatF > > > would likely get lost in the noise when you consider that reallyF > > > one is dealing with "buckets" rather than "blocks".  To the bestF > > > of my knowledge, RMS does not engage in "read ahead" behavior on > > > indexed files. > > > M > > But you can get very substantial gains by increasing the RMS buffer size.  > This _does_ giveG > > "read ahead" behaviour. Obviously not recommended for random reads.  > N > Are you referring to the RMS *bucket* size?  I guess increasing that (if oneN > has the option) could be considered somewhat equivalent to 'read-ahead', butN > the kind of 'read-ahead' I suspect Larry meant is the posting of disk accessK > requests in advance of the need for the data (i.e., multi-buffering), not N > simply requesting more data than you may immediately need in a single access. > request (which larger buckets would enable).  N Nope.  Paul is correct with the word BUFFER.  RMS will (as far as I know) readP enough data to fill the I/O buffer.  The larger the buffer, the more data read. N Then subsequent record reads are from the buffer, not the disk, until a recordM outside the buffer is required.  Since RMS records are stored in buckets, the L bucket size is relavent, but it's the buffer that determinae the size of the I/O.  K That doesn't mean it's one 'read' for the disk, but the physical disk reads 5 should be a constant for purposes of this discussion.    Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.com  Vanderbilt, PA  15486    ------------------------------  % Date: Sat, 27 May 2000 02:34:36 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> ( Subject: Re: Capellas supports Microsoft( Message-ID: <8gnq4l$eb6$1@pyrite.mv.net>  7 Bill McLaughlin <mcbill20@hotmail.com> wrote in message . news:20000526212052.40542.qmail@hotmail.com...   ...    > Hey, guys... > I > I don't presume to speak for the entire group...but I would assume that  many > feel as I do--  % You might even be able to include me.   K Terry has an unfortunate propensity to sprinkle his anti-Clinton sentiments H into otherwise unrelated areas, and I'm occasionally inclined to provideL some balance (if you ever catch me *initiating* such diversion, feel free toI chastise me for it).  But I agree that it can too easily get out of hand.    - bill   > H > There is enough politics everywhere else. I for one enjoy my job and II > consider it a big plus to be able to take a break from society/politics  and , > bury my head in technology (office Dilbert > issues aside). >   > This newsgroup is COMP.OS.VMS: >  > COMP    : COMPUTER > OS      : OPERATING SYSTEM6 > VMS     : THE BEST GENERAL PURPOSE OPERATING SYSTEM* > C >   * - Sorry, I just had to add that last 'political' view; but AT  > LEAST it's COMPUTER related. > 8 > So, can't we take the political discussions elsewhere? > 
 > Just my .02  > 	 > Thanks.  > Bill McLaughlin J > ________________________________________________________________________J > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com >  >    ------------------------------  % Date: Sat, 27 May 2000 11:53:27 -0500 * From: Keith Brown <kbrown780@usfamily.net> Subject: Re: ES40 Configuration , Message-ID: <392FFD87.77D9B8C9@usfamily.net>   Stanley Hippler wrote: > H > From our local sales rep, we requested an ES40 configuration; dual 667C > processors, 4 gigabytes ram, roughly 200 gigabytes Raid-5 capable H > disk.  The response included dual HSZ80 controllers, twenty-four 9 gig& > disks to meet the disk requirements. > J > While this is skimpy information I am supplying, what I want to know is:- >     1) Is this really a one-node "cluster"? < >     2) Does this seem like a reasonable disk configurationA >     3) Given the associated costs of using the HSZ80s, is there @ >        some other I/O configuration that should be considered? > H > I can set up and run a cluster.  However, this is a single machine.  IA > would prefer a more simple I/O solution, without the clustering  > management overhead. > F > The main software applications will include SCT's Plus2000 packages,/ > email for up to 8000 students, OSU webserver.  > , > Any responses will be greatly appreciated. >  > Stanley Hippler  > McNeese State University > ( > Sent via Deja.com http://www.deja.com/ > Before you buy.   @ I recently purchased an ES40 with the configuration below.  This> is certainly not the only way to do it but it fit the bill for us.    This is a standalone machine ES40 2 500Mhz CPUs 4 GB RAM5 Dual HSZ70 Controllers with 64MB cache configured for  redundancy.  RA7000 Storage array System disk is 18GB mirror set< Application disk is 18GB mirror set - The application we run hits this disk hard @ Historical data disk is 6X36GB raid5 set for 180GB usable space.! 18GB hot spare and 36GB hot spare   ? This configuration replaced a VAX 6650 which was long over due. < The ES40 has been running for about 1 1/2 months now with no, problems and absolutely awesome performance.   --   Keith Brown  kbrown780@usfamily.net   ------------------------------   Date: 27 May 2000 13:34:31 GMT From: xhigzc@earthlink.net& Subject: Get Paid To Read Email!  5502+ Message-ID: <8goit7$7lc$934@WWW1.relcom.ru>    This is awesome!  . I just had to tell you about SendMoreInfo.com! You get paid to read email! . They send you information about things you are/ interested in and they pay you to check it out!  Here's the link:  $ http://www.sendmoreinfo.com/id/98292  = I know you are going to love this web site! Talk to you soon!     d ekchowtbyxgyhygtxelclewqniofbdglurlmxtxzbyckiyzlbehzitozwscslfihdfhndnvvqtbqdvhruoezepwvfluuichrbhuw   ------------------------------   Date: 27 May 2000 06:04:34 GMT- From: djweath@attglobal.net (Dave Weatherall) ? Subject: Re: How to export contents of RMS file to .csv format? 5 Message-ID: <DTiotGxQ0bj6-pn2-8q20MNJWf5pn@localhost>   C On Sun, 24 May 3900 00:07:33, David A Froble <davef@tsoft-inc.com>   wrote:  O > Ok, I've followed this thread for several days.  Finally built the resolve to 9 > admit my ignorance.  Just what the heck is a .csv file?  >  > Dave    0 Thank heaven someone had the gumption to ask :-)   Cheers - Dave.   ------------------------------  % Date: Sat, 27 May 2000 10:00:29 -0500u) From: "John E. Malmberg" <wb8tyw@qsl.net>? Subject: Re: Jabber on OpenVMS?t7 Message-ID: <02ab01bfc7ec$4da82e20$020a0a0a@xile.realm>0  / David A Froble <davef@tsoft-inc.company> wrote:u  * > alphaman@hsv.sungardtrust.company wrote:  5 > > Has anyone looked into porting Jabber to OpenVMS?% > >eC > > For those who aren't familiar, Jabber is an open source instant%J > > messaging client and SERVER (!) that is compatible with a long list ofJ > > other IM clients.  From what I've seen, it's about the only IM server,2 > > and one of the few open-source kits out there. > >eK > > The potential for IM behind firewalls looks really attractive; I'd liken1 > > to see this on OpenVMS (no U*X in this shop).n > K > Not sure what you're describing.  Inter-process messages?  Something likeC PHONE?  G Yes, Something like PHONE, typically with a GUI.  And some of them witheJ banner advertisements in the header or footer of the window to pay for the server.-  K Either the Source or Specifications for the America Online Instant Messager1H were available before their issues with Microsoft.  It may still be.  In- that case it could probably be ported to VMS.m  H Unlike PHONE, the AOL Instant Messager is limited to 2 participants at aL time.  It also gives you a window (with advertisements) that shows if anyone? that you have in your directory has a connection to the server.r   -Johnt wb8tyw@qsl.network   Tip:= Do not read Janet Simon's resume, she is a friend of Melissa.>  5 http://www.icsa.net/html/hypeorhot/index.shtml#resumeg   ------------------------------  % Date: Sat, 27 May 2000 21:30:46 +0400 + From: "Ruslan R. Laishev" <laishev@dls.net>h+ Subject: Re: Looking for PW API informationr@ Message-ID: <SyTX4.82476$681.1602285@news-east.usenetserver.com>   Pathworks News wrote in messagen- <8glg6u$oj2$1@mailint03.im.hou.compaq.com>...m >David,o >tA >At this point in time you can't check the password change times.g: >We are working on a change on this to make this possible.* >So, for this I can only say, be patience. >0K >About the API, yes I expected an Microsoft/workstation application because   >on OpenVMS we don't have API's.E     Hmmm... It's very strange , how in this case works ADMIN MOD USERtG /PASS=, directly write a password to the PW database, and to SYSUAF (byC
 $setuai) ?   ------------------------------    Date: 27 May 2000 10:42:53 -04004 From: "Robert Deininger" <rdeininger@mindspring.com> Subject: Re: MicroVMS 4.4 + Message-ID: <B5555730-48364@165.247.44.178>w  2 On Fri, May 26, 2000 12:36 PM, Hoff Hoffman wrote: >tH >In article <8gjvpl$2qaa$1@info.cs.uofs.edu>, bill@cs.scranton.edu (Bill >Gunshannon) writes:H >:It's a long story, but I have installed MicroVMS 4.4 on a MicroVAX II. >uI >  Whoa.  Send me a copy of your distribution kit when you're done (as it I >  looks readable), and I'll archive it in the antiques section.  (I haveeH >  a MicroVMS V4.4 kit on RX50 in a box, but I have no idea if the RX50 / >  media will itself still read correctly.) :-)k  G If you really have gaps in your library, I've got drawers full of TK50s I going back to that era.  Some of our own, and a lot more that we recentlyoH inherited.  I don't have a complete inventory, but I know I've seen someF microVMS 4.x labels in there.  Also a TU58 boot tape for a Vax 11/750 G (version 5.something I think), but it says 1/2 on the label and I don't1A have its mate.  We even got a large stack of 8" floppies with the H nice orange DEC labels - but no way to read these.  Best of all, severalE cases of fan-folded punched paper tape - part of a RT-11 distributionA (oops, wrong newsgroup.)  I Let me know if there are specific TK50s you need, and I'll look for them.6  E How does one clean a TK70 drive?  First step seems to be removing the G dust-bunnies with tongs.  Then what?  The head doesn't seem accessible.6) Would a DLT cleaning cart work in a TK70?l  @ This past week, our service group decided to throw out all their Vax-relatednI spare parts. (THEY don't have any more VMS machines, but WE do.)  Lots of,E hex-width unibus boards from 11/785s and machines of similar vintage. H Probably some Vax 6000 stuff too.  I got a 1 MB memory "SIMM" for a 750.  E Power supplies, fans, stepper motors for printers, air pumps for tapehJ drives, the whole works.  Most new in the box, but being good tree-huggersE they put the cardboard in one dumpster, the documentation in another,eG and the parts in a third.  What a mess.  I managed to rescue some brandoF new keyboards and rodents for our vaxstation 4000s.  (They hauled thisC stuff past two working 4000-90s on the way to the dumpster.)  They  : half-filled a big dumpster with nice old parts.  Very sad.  6 Anyone need a MASSBUS cable?  Neat connector on those.       ---------------------------  Robert Deininger rdeininger@mindspring.comr   ------------------------------  % Date: Sat, 27 May 2000 10:33:31 -0500n) From: "John E. Malmberg" <wb8tyw@qsl.net>n Subject: Re: MicroVMS 4.4h7 Message-ID: <02bb01bfc7f0$eadc2e40$020a0a0a@xile.realm>   7 Robert Deininger <rdeininger@mindspring.company> wrote:(  G > How does one clean a TK70 drive?  First step seems to be removing the I > dust-bunnies with tongs.  Then what?  The head doesn't seem accessible. + > Would a DLT cleaning cart work in a TK70?'  K If you push hard enough it will go in.  The service people will not be very L amused but after they pry it out, the TK70 drive appears to still be usable.  H There is a specific cleaning kit for TK50/TK70 drives.  It has a plasticL guide and a number of cleaning strips with some solution.  I do not have the4 part numbers, but it should not be too hard to find.   -Johny wb8tyw@qsl.network   ------------------------------  % Date: Sat, 27 May 2000 05:56:27 +0200   From: Paul Sture <paul@sture.ch>; Subject: Re: OpenVMS and Windows NT Integration for Dummies + Message-ID: <VA.0000005b.06743208@sture.ch>c  < In article <392B6156.A664755C@videotron.ca>, JF Mezei wrote:/ > From: JF Mezei <jfmezei.spamnot@videotron.ca>_ > Newsgroups: comp.os.vms:= > Subject: Re: OpenVMS and Windows NT Integration for Dummies ' > Date: Wed, 24 May 2000 00:58:00 -0400  >  > Paul Sture wrote:-R > > Paul Sture (whose 2 non-IT brothers sat me down 2 years ago and lectured me onN > > taking a wrong career move by not going for an MSCE and sticking with MS). > M > Yep. Stuck in that one-way-VMS-street going nowhere in Montreal. Those moste3 > loyal to VMS are the ones that are the worse off.e >dS Au contraire, mon ami! I _did_ take time out to get acquainted with NT (and indeed eR found that my mainframe / VMS background stood me in good stead), just to see the Q marketplace filled with MSCEs who thought that the piece of paper they held made  R them superior. I have lost count of the number of businesses who were taken in by G these folks, only to encounter disaster a little further down the road.t  Q And you missed the key item in my statement above: "non-IT". These are folks who nN are in positions to make key decisions or give advice on such. They have been S taken in by the M$ hype, and unfortunately the UK nowadays seems to be PR hype and   spin, with little substance.  S I am glad to be back in the VMS world, and working with some good professionals. I a7 assure you I do _not_ feel stuck in any one-way street.p  S PS If you feel "stuck" in Montreal, just look at the OpenVMS site and see how many m@ stock exchanges around the world may be able to use your skills. ___ 
 Paul Sture Switzerland:   ------------------------------  % Date: Sat, 27 May 2000 13:22:39 +0111t9 From: Mark Iline - Info-VAX account <ivax@meng.ucl.ac.uk>l3 Subject: Re: OpenVMS vs Tru64 Pathworks performancel0 Message-ID: <009EAB67.17D843E8.7@meng.ucl.ac.uk>  H From:	MX%"davef@tsoft-inc.com"  "David A Froble" 27-MAY-2000 04:39:14.57  N > Sorry to have to say this, but from my experiences, the best file server forM > windoz is a windoz system.  I don't really like that answer, but the answery > never asked my opinion.  >   I I could accept this (though I wouldn't be impressed that the 'extensible iK high end to Windows NT' actually performed worse than the bargain basement SF low-end of NT itself (ie a 1-2k pound PC)) except that Tru64 seems to G perform a lot better than NT does. And on a several year old mid-range eL Alpha Workstation, compared to a 6 month old Intel 'server'. Which (Wintel)  dumps all over a VMS DS20.  G I'm starting to wonder if I (and the whole VMS community) really is in   denial.o  P > Get a cheap windoz system and use the DS20 for some real computing, using VMS.  I Trouble is, this 'real computing' is exactly the kind of application VMS tL doesn't seem to support anymore, since the plug got pulled on technical VMS  apps.y  ( The DS20 does run BACKUP well, though...  L Anyway, I'd like to stay focussed on PW performance on VMS vs TRu64, before % we wander off into those rants... ;-)m     Mark    Mark Iline	system@meng.ucl.ac.uk- Dept Mech Eng, University College, London. UK    			Read at your own risk.h   ------------------------------  % Date: Sat, 27 May 2000 14:32:03 +0200s" From: "Hans Vlems" <hvlems@iae.nl>3 Subject: Re: OpenVMS vs Tru64 Pathworks performancei( Message-ID: <8goepa$q1l$1@news.IAEhv.nl>  B We changed our VMS Pathworks (V5.0E) servers to WNT 4.0 SP4 on the same hardware.I Three out of  four servers were nearly identical: alpha 1000 4/533's with  192 MB of memory.fK Number four was an alpha 1200, two cpu's, 512 MB memory and also ran at 533u MHz. NIC: FDDI DAS, protocol TCP/IP..I We were worried about the behaviour under WNT. With VMS nearly all memoryc
 was in use: and both cpu's ran at least at 80%, usually higher levels.4 The machine served fileshares to around 300 clients.D Once the machine ran WNT the second cpu was no longer necessary. The
 remaining oneh" was used for 50% during rush hour.E Now since TRU64 uses the same pathworks code as VMS you migh see somee improvementsK over VMS performance since unix is quite similar to DOS with respect to its  filesystem, that is 
 rather basic.   I What I learned is that billyboxes speak best to other billyboxes whatevern GUI (I refuse to call it an OS) they are running.  
 Hans Vlems  9 Mark Iline - Info-VAX account heeft geschreven in berichtr( <009EAAE3.37FF59D8.24@meng.ucl.ac.uk>...I >Has anyone know of any performance figure comparing Pathworks on OpenVMS K >against Pathworks on Tru64 (on comparable hardware) ? A comparison againsth2 >NT Advanced Server on Intel would be interesting. >-> >I'm aware that measuring performance peoperly is not trivial. >sK >I currently seem to be seeing a well-specified OpenVMS dual processor DS20yK >being significantly slower at serving files to PC clients than a bog-stockuI >Proliant 1600, which is significantly slower than a PW500au running PW &  >Tru64.E > J >I'm not asking why this is - I know this isn't a trivial question. What IH >would like to know is whether the Pathworks on OpenVMS product performsJ >significantly worse than its Tru64 counterpart in a comparable situation.7 >That information will help me decide where to go next.s > L >[I'm being beaten up to ditch VMS for Tru64 on the DS20 on the basis of the3 >lacklustre performance. Which I'd rather not do...h >cH >Just for interest, copying a 10 Mbyte file from an RA3000 (it's totallyJ >cached in the RA cache - I'm watching the indicators) on the DS20 to a PCD >client takes ~6 seconds. Interestingly, we get up to about 150% CPU; >utilisation during that time - Interrupt & Kernel mostly.]  >- >- >Mark- >-! >Mark Iline system@meng.ucl.ac.uk0. >Dept Mech Eng, University College, London. UK >. > Read at your own risk. >a >u   ------------------------------  + Date: Sat, 27 May 2000 10:42:32 -0500 (CDT)b From: sms@antinode.org/ Subject: TCPIP$SMTP_RECV_RUN.LOG;32767 problem?m) Message-ID: <00052710423204@antinode.org>   H    The SMTP queue on my hobbyist AlpSta 200 4/233 (VMS V7.2, TCPIP V5.0)F jammed recently.  (Queue was stopped, ENABLE AUTO and START left it inC "starting" mode.)  Normal shutdown hung trying to stop the queues.  3 Before the crash and reboot, I found (and deleted):y  
 ALP $ sho defi   SYS$SPECIFIC:[TCPIP$SMTP] # ALP $ dir /siz /dat /pro *recv*.log   # Directory SYS$SPECIFIC:[TCPIP$SMTP]    TCPIP$SMTP_RECV_RUN.LOG;32767tF                            1  23-MAR-2000 17:06:51.17  (RWED,RWED,RE,) TCPIP$SMTP_RECV_RUN.LOG;32766IF                            1  23-MAR-2000 17:03:00.61  (RWED,RWED,RE,) TCPIP$SMTP_RECV_RUN.LOG;32765eF                            1  23-MAR-2000 17:01:24.33  (RWED,RWED,RE,) [...]:  ?    Any chance that the whole thing was caused by version number  exhaustion on these log files?  H ------------------------------------------------------------------------  C    Steven M. Schweda               (+1) 651-699-9818  (voice, home) C    382 South Warwick Street        (+1) 763-781-0308  (voice, work) G    Saint Paul  MN  55105-2547      (+1) 763-781-0309  (facsimile, work)_9    sms@antinode.org                sms@provis.com  (work)M   ------------------------------  % Date: Sat, 27 May 2000 12:16:05 -0400-* From: David A Froble <davef@tsoft-inc.com>3 Subject: Re: TCPIP$SMTP_RECV_RUN.LOG;32767 problem?:- Message-ID: <392FF4C5.29E74C8A@tsoft-inc.com>.  P Without being an expert on the TCPIP software, I'd guess that when an attempt toE create version 32768 was/would be made, something 'BAD' would happen.a   Dave     sms@antinode.org wrote:l > J >    The SMTP queue on my hobbyist AlpSta 200 4/233 (VMS V7.2, TCPIP V5.0)H > jammed recently.  (Queue was stopped, ENABLE AUTO and START left it inD > "starting" mode.)  Normal shutdown hung trying to stop the queues.5 > Before the crash and reboot, I found (and deleted):a >  > ALP $ sho defa >   SYS$SPECIFIC:[TCPIP$SMTP]a% > ALP $ dir /siz /dat /pro *recv*.log  > % > Directory SYS$SPECIFIC:[TCPIP$SMTP]t >  > TCPIP$SMTP_RECV_RUN.LOG;32767eH >                            1  23-MAR-2000 17:06:51.17  (RWED,RWED,RE,) > TCPIP$SMTP_RECV_RUN.LOG;32766wH >                            1  23-MAR-2000 17:03:00.61  (RWED,RWED,RE,) > TCPIP$SMTP_RECV_RUN.LOG;32765sH >                            1  23-MAR-2000 17:01:24.33  (RWED,RWED,RE,) > [...]e > A >    Any chance that the whole thing was caused by version number   > exhaustion on these log files? > J > ------------------------------------------------------------------------ > E >    Steven M. Schweda               (+1) 651-699-9818  (voice, home)iE >    382 South Warwick Street        (+1) 763-781-0308  (voice, work) I >    Saint Paul  MN  55105-2547      (+1) 763-781-0309  (facsimile, work)u; >    sms@antinode.org                sms@provis.com  (work)t   -- c4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.como Vanderbilt, PA  15486u   ------------------------------  % Date: Sat, 27 May 2000 08:38:24 +0200n> From: "Jean-Franois Marchal" <jean-francois.marchal@x9000.fr>  Subject: Re: TCPware window size3 Message-ID: <8gnqe6$2o3e$1@s2.feed.news.oleane.net>-   Thank you ! 
 Jean-Franois0    @ "Michael Corbett" <corbett@epp.ne.mediaone.net> wrote in message7 news:K7zX4.29267$Ft1.1314404@typhoon.ne.mediaone.net... I > On 25 May 2000,  Jean-Franois Marchal <jean-francois.marchal@x9000.fr>  wrote: > >Bonjour  tous !y > > D > >How can I see what window size is in effect under TCPware 5.3-3 ?@ > >I've found NETCU START/TCP has a /MWS qualifier to set it ...> > >We have problems with printers attached to RapidPrint boxes6 > >with "ECONNRESET connection reset by peer" messages > >y
 > >Merci ! > >h > >Jean-Franois Marchal > >X900 - LYON > >- >-I > The window size changes depending on what the application specified foraF > its receive buffer and host much space is left in the buffer when itB > sends a TCP segment.  You can view the window size when by usingH > NETCU DEBUG/TCP  to capture the traffic between the TCPware system and( > the RapidPrint boxes, something like - >a5 > $ NETCU DEBUG/TCP/DIA=<ipaddress_of_RapidPrint_box>d > J > The output will look something like the the example below.  The "W=xxxx" > is the window size - >o< > 04:08.81 RCVD    60 bytes INET12:   198.115.142.10,1054 -> 198.115.142.43,23 ; >          LISTEN   SEQ=3677275507 D=0 ACK=0 W=6144 CTL=SYNl: > 04:08.81 XMIT    48 bytes INET0:    198.115.142.43,23 -> 198.115.142.10,10540> > SYN-RCVD SEQ=499885985 D=0 ACK=3677275508 W=4096 CTL=SYN!ACK >u > G > My guess is that the problem is not with the window size but with thepH > MSS, maximum segment size, which TCPware 5.3-3 incorrectly advertises.4 > This problem is corrected in the following patch - >R9 > ftp://ftp.process.com/support/53_3/drivers_v533p040.zipM >i, > The readme for the patch can be found at - >MA > http://vms.process.com/scripts/eco/eco_tlb.com?DRIVERS_V533P040  > 	 > regardsa	 > Michaelh >  > -- > K +-------------------------------------------------------------------------+sF > Michael Corbett                           Email: Corbett@process.comD > Process Software Corporation              Phone: 800 722-7770 x369D > 959 Concord St.                                  508 879-6994 x369? > Framingham MA 01701-4682                  FAX:   508 879-0042u   ------------------------------  % Date: Sat, 27 May 2000 12:04:02 -0500b* From: Keith Brown <kbrown780@usfamily.net>* Subject: Tru64 Unix Moving to Open Source?, Message-ID: <39300002.BD30F3E6@usfamily.net>  9 http://www.crn.com/sections/news/news.asp?ArticleID=17020   @ I'm not sure what this means to Compaq, though it seems they may7 have some trouble differentiating Tru64 from Linux. Anye	 comments?J   -- b   Keith Brownk kbrown780@usfamily.net   ------------------------------   End of INFO-VAX 2000.295 ************************