1 INFO-VAX	Sat, 07 Apr 2001	Volume 2001 : Issue 194       Contents:' Re: - OpenVMS ever to be on Intel chip? 3 Re: Compaq quitting with Alpha Workstations ???????   Re: DCL question: piping command DCX self extracting archives. ! Re: DCX self extracting archives. ! Re: DCX self extracting archives. 5 does Warrent Sander have an eMail address that works? 9 Re: does Warrent Sander have an eMail address that works? 9 Re: does Warrent Sander have an eMail address that works? / Dueling browsers (was: Another Win for OpenVMS) 3 Re: Dueling browsers (was: Another Win for OpenVMS)  FTP hijacking of VMS sites FTP hijacking of VMS sites RE: FTP hijacking of VMS sites Re: FTP hijacking of VMS sites RE: FTP hijacking of VMS sites Re: FTP hijacking of VMS sites Re: FTP hijacking of VMS sites Re: FTP hijacking of VMS sites2 Galaxy Network Interfaces/cards and TCP/IP SocketsA Re: How do I redefine the alias between SYSCOMMON and VMS$COMMON? A Re: How do I redefine the alias between SYSCOMMON and VMS$COMMON? A Re: How to tell if a system is booting immediately after a crash. $ London, England Technical Update Day0 Re: OVMS Tech Update Presentations [and Mozilla]( Re: Seeking CD-R/CD-RW SCSI INQUIRY data Re: Updated information & Re: VMS equivalent of Unix wc command?& Re: VMS equivalent of Unix wc command?& Re: VMS equivalent of Unix wc command?& Re: VMS equivalent of Unix wc command?& Re: VMS equivalent of Unix wc command?& Re: VMS equivalent of Unix wc command? Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable  Re: VMS-Related: Affordable   F ----------------------------------------------------------------------   Date: 6 Apr 2001 20:34:30 -0500 9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) 0 Subject: Re: - OpenVMS ever to be on Intel chip?3 Message-ID: <pHB4$9VdN4Od@eisner.encompasserve.org>   c In article <9aktmn$2nkq$1@newssvr05-en0.news.prodigy.com>, davidsen@tmr.com (bill davidsen) writes:   @ >   I'd re-ask the previous question, can SMP be used to improveG > performance? And given the relative price and performance of ia86 vs. H > Alpha, isn't the market limited to people who need to run VAX softwareF > (VMS? OpenUNIX?) but can't or won't use a real VAX? If the markey isH > people who can't afford a VAX, I would guess the price of the softwareF > is going to have to be pretty low or they can't afford that, either.  @ I believe the market is people who _cannot_ change, for instanceC because they depend on software whose source is lost (such as being % from a vendor that no longer exists).    ------------------------------   Date: 6 Apr 2001 20:23 CST' From: carl@gerg.tamu.edu (Carl Perkins) < Subject: Re: Compaq quitting with Alpha Workstations ???????, Message-ID: <6APR200120235688@gerg.tamu.edu>  l In article <TGkz6.625$fB6.16807@news.cpqcorp.net>, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes...I }What's a workstation?  IMHO the last "true" workstation we built was the F }VaxStation 4000.  I say that because it is the last platform where weK }actually did something to the platform itself specific to graphics (we put D }the graphics in the memory controller - the LCG).  Other than that,M }workstations have pretty much been servers without some of the RAS features.  }  }The XP900 is a DS10.  } I }The workstation group itself long ago was disbanded, and the function of I }building workstations is part of AlphaServers.  The difference between a B }Server and a Workstation is then how it's packaged, and licensed. }  }_Fred  H I think you have forgotten the XP1000. It may not have "something to theF platform itself specific to graphics", but it has hever been sold in a0 configuration other than the XP1000 workstation.  E I see no reasony why Compaq wouldn't just go with the "workstation is F server with a graphics card" option since, other than the XP1000 whichE is probably about due to be either upgraded in speed or discontinued, C they already are (although the graphics isn't the only difference - H they also have the low-end client NAS license, the XP900 gets the NAS150	 license).    --- Carl  . }Island Computers US Corp wrote in message ...J }>I heard a rumour about Compaq stating they were going to discontinue the$ }>manufacture of Alpha workstations. }>M }>Is this true - in a way I hope so... all the more business for us, but what  }>a stupid move by Compaq.J }>Or are they just trying to squeeze more billy boxen in there where there }>were AStations }>M }>Or - maybe concentrating on Tru64 servers and Linux desktops.... hmmm not a  }>bad idea.  }>G }>After all, Tru64 is a far superior product to VMS, right !?!?!?   ;0)  }> }> }>DT }>--! }>Island Computers US Corporation  }>2700 Gregory Street  }>Suite 150  }>Savannah GA 31404  }>Tel: 912 447 6622  }>Fax: 912 201 0096  }>sales@islandco.com }>www.islandco.com }>E }>This message and any files transmitted with it are confidential and L }>may be privileged and/or subject to the provisions of privacy legislation.J }>They are intended solely for the use of the individual or entity to whomG }>they are addressed. If the reader of this message is not the intended  }>recipient,I }>please notify Island Computers US Corp immediately and then delete this 
 }>message.K }>You are notified that reliance on, disclosure of, distribution or copying   }>of this message is prohibited. }> }> }> }> }  }    ------------------------------  # Date: Sat, 07 Apr 2001 05:02:14 GMT  From: Andy <kicsi2l8@home.com>) Subject: Re: DCL question: piping command ( Message-ID: <3ACE9E51.7DB52CD4@home.com>  @ thanks for the help,....I got it working. I have @home and usingF netscape. Your post I guess didnt come through for a while, but i have it now.    this worked: $ PIPE SHOW QUEUE | - B   SEARCH SYS$PIPE STOPPED/OUTPUT=retain.tmp ; PRINT/QUEUE=whatever
 retain.tmp  : I even added del retain.tmp;* to delete it after printing.  G Thanks again! You'll see my posts here more often. This NG is a whealth 	 of info!!    ------------------------------  % Date: Fri, 06 Apr 2001 17:30:28 -0400 * From: Doug Mallory <dmallory@interlog.com>& Subject: DCX self extracting archives., Message-ID: <3ACE3574.DCDEFB3F@interlog.com>   Hi all, E Does anyone know where I could find the program to make DCX archives? H I have been looking around to see if I could find this, but nothing yet.0 Can anyone point me to a source of this program?  
 Thanks a lot,  Doug.    ------------------------------  # Date: Fri, 06 Apr 2001 22:15:22 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)* Subject: Re: DCX self extracting archives.2 Message-ID: <_drz6.657$fB6.16931@news.cpqcorp.net>  Y In article <3ACE3574.DCDEFB3F@interlog.com>, Doug Mallory <dmallory@interlog.com> writes:   F :Does anyone know where I could find the program to make DCX archives?  H   The self-extracting DCX stuff seen with Compaq ECO kits uses a Compaq F   package known as FTSV, which is unfortunately not readily available    as a standard item.   D   In practice, the self-extracting version of zip (sfx) works ratherE   better than the DCX compression -- and the zip sfx stuff is on the  #   Freeware, in the *zip* directory.   N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Fri, 06 Apr 2001 19:45:40 -0600 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> * Subject: Re: DCX self extracting archives.' Message-ID: <3ACE7144.446185FC@fsi.net>    Hoff Hoffman wrote:  > [ > In article <3ACE3574.DCDEFB3F@interlog.com>, Doug Mallory <dmallory@interlog.com> writes:  > H > :Does anyone know where I could find the program to make DCX archives? > I >   The self-extracting DCX stuff seen with Compaq ECO kits uses a Compaq G >   package known as FTSV, which is unfortunately not readily available  >   as a standard item.  > F >   In practice, the self-extracting version of zip (sfx) works ratherF >   better than the DCX compression -- and the zip sfx stuff is on the% >   Freeware, in the *zip* directory.   * Yeah - gotta second Hoff's recommendation.  D DCX is inefficient compared to Zip's deflation algorithm. You'll get0 almost 2:1 better performance with Zip than DCX.  C ...and anything you can with UNZIP, you can do with UNZIPSFX (well,  almost).   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/   F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.    ------------------------------  # Date: Fri, 06 Apr 2001 19:41:46 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) > Subject: does Warrent Sander have an eMail address that works?0 Message-ID: <009FA238.8D1B270C@SendSpamHere.ORG>  I The eMail address Warrent uses when posting does not work.  If he doesn't I care to publish it in the newsgroup, I would appreciate a personal eMail.    Thanks,  --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              O city, n., 1. a place where trees are cut down and streets are named after them.    ------------------------------  # Date: Fri, 06 Apr 2001 21:31:31 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)B Subject: Re: does Warrent Sander have an eMail address that works?2 Message-ID: <TAqz6.655$fB6.17136@news.cpqcorp.net>  p In article <009FA238.8D1B270C@SendSpamHere.ORG>, system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes:J :The eMail address Warrent uses when posting does not work.  If he doesn'tJ :care to publish it in the newsgroup, I would appreciate a personal eMail.  4   Warren stop Sander at Compaq stop Com should work.  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Fri, 06 Apr 2001 22:49:55 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) B Subject: Re: does Warrent Sander have an eMail address that works?0 Message-ID: <009FA252.D5E37021@SendSpamHere.ORG>  g In article <TAqz6.655$fB6.17136@news.cpqcorp.net>, hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes: q >In article <009FA238.8D1B270C@SendSpamHere.ORG>, system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes: K >:The eMail address Warrent uses when posting does not work.  If he doesn't K >:care to publish it in the newsgroup, I would appreciate a personal eMail.  > 5 >  Warren stop Sander at Compaq stop Com should work.   	 Thanks...  --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              O city, n., 1. a place where trees are cut down and streets are named after them.    ------------------------------   Date: 6 Apr 2001 20:26:49 -0500 9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) 8 Subject: Dueling browsers (was: Another Win for OpenVMS)3 Message-ID: <$NyWJN$3OIck@eisner.encompasserve.org>   t In article <MBkz6.43700$Wz.10513299@typhoon.ne.mediaone.net>, "Terry C. Shannon" <terryshannon@mediaone.net> writes:  I > Ah, Netscape... the browser for crash test dummies. I used to use it on N > Windoze, but got sick of the multiple daily browser crashes and went over to@ > Internet Exploder. At least it is more reliable than Netscape.  C I haven't had Netscape (4.5-98293) problems on the Macintosh (8.6).   * Windows, the OS for crash test dummies :-)   ------------------------------  % Date: Fri, 06 Apr 2001 23:17:21 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> < Subject: Re: Dueling browsers (was: Another Win for OpenVMS), Message-ID: <3ACE86AB.C89FF55C@videotron.ca>   Larry Kilgallen wrote:E > I haven't had Netscape (4.5-98293) problems on the Macintosh (8.6).   L Go to the ericsson site, try to display the FAQ for the R520m phone (the oneN with GPRS). Then try to "increase font size" because that page is coded with aM minuscule font. On Netscape 4.7, it consistently crashes the browser (but not  the computer).  T There are also some pages coded for Microsoft junk which do not display on Netscape.  % Try http://www.aircanada.ca/home.html   K Enter departure and destination cities and a date and click on "GO" for the J schedules. It won't work. Why ? Because Air Canada outsourced web designerN (IBM) doesn't realise that on a MAC, there is no "right click" to save images.J Their javascript code validates the cities when there is a MOUSE-DOWN, andN then submits the form on "MOUSE_UP", but the mac doesn't generate those events2 because of the dual use of the single mose button.  G They need to do both actions at the same time and use ON-CLICK instead. L (letting the browser decide if the user has meant to click on the button, orJ try to pop up the menu that allows to save image, copy link location etc).  N There are plenty of examples where pages of very well known large corporations are poorly designed.   ------------------------------   Date: 6 Apr 2001 22:32:59 GMT * From: bleau@umtof.umd.edu (Lawrence Bleau)# Subject: FTP hijacking of VMS sites ) Message-ID: <9alg6r$bt7$1@hecate.umd.edu>   G Hello, folks.  I just noticed a lot of oddly named files - directories, M actually - in my system's anonymous ftp area.  They weren't created by anyone B associate with our site.  One associate of mine gave me his guess:  ? i don't know if this is the case here, but i read articles from ? people who's anonymous ftp areas have been "hijacked" by people ? distributing large files like movies.  typically, a 1MB file is D uploaded to check the speed.  if the hijacker thinks the speed is ok= lots of directories are created and movie parts are uploaded.   , see http://www.macintouch.com/ftphijack.html  M I think this subject deserves some discussion.  It's the first I heard of it, / and I've been managing VMS systems for a while.   M Has anyone experienced this phenomenon?  Has is cropped up at VMS sites?  Are @ there standard ways of combating it?  Should this be in the FAQ?   Lawrence Bleau University of Maryland" Physics Dept., Space Physics Group 301-405-6223 bleau@umtof.umd.edu    ------------------------------  + Date: Fri, 06 Apr 2001 17:42:43 -0500 (CDT)  From: sms@antinode.org# Subject: FTP hijacking of VMS sites ) Message-ID: <01040617424313@antinode.org>   * From: bleau@umtof.umd.edu (Lawrence Bleau)  I > Hello, folks.  I just noticed a lot of oddly named files - directories, O > actually - in my system's anonymous ftp area.  They weren't created by anyone ! > associate with our site.  [...]   G    I enabled disk quotas on my home system specifically so that I could G limit the storage available for user ANONYMOUS.  (Not having dealt with H a disk quota since my employer gave up on VMS, I had to dust off several0 seldom-explored regions of my long-term memory.)  F    An occasional glance at usage by ANONYMOUS and/or the anonymous FTPE server log ("some_disk:[TCPIP$FTP]TCPIP$FTP_ANONYMOUS.LOG"?) might be  informative.  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)    ------------------------------  % Date: Fri, 06 Apr 2001 17:49:42 -0500 + From: Christopher Smith <csmith@amdocs.com> ' Subject: RE: FTP hijacking of VMS sites L Message-ID: <3B55D7F383B0D31197D9009027541CBF0D9D1D26@cmiexch1.cmi.itds.com>   > -----Original Message-----8 > From: bleau@umtof.umd.edu [mailto:bleau@umtof.umd.edu]  A > i don't know if this is the case here, but i read articles from A > people who's anonymous ftp areas have been "hijacked" by peopleSA > distributing large files like movies.  typically, a 1MB file isnF > uploaded to check the speed.  if the hijacker thinks the speed is ok? > lots of directories are created and movie parts are uploaded.n   That is fairly common.  ; > I think this subject deserves some discussion.  It's the s > first I heard of it,1 > and I've been managing VMS systems for a while.   @ > Has anyone experienced this phenomenon?  Has is cropped up at  > VMS sites?  ArewB > there standard ways of combating it?  Should this be in the FAQ?  L You don't mention whether it is really supposed to be a "public" archive, orJ something else...  The first of these solutions won't work for a site like that, for obvious reasons.  K It happens in FTP sites in general.  Typically there are three methods used L to stop it.  Perhaps the most obvious is to disallow anonymous access.  MakeK an account with a password known only to those people who need access -- or D -- give each their own account. (For several reasons this may not be feasible...)  H A second way, and perhaps more sane(!) is to disallow read access to theL upload directories/files in them. :)  This will prevent your site from beingJ of any use to the culprit, and presumably, they should stop soon.  Lots ofK large sites do this(for instance, wcarchive), probably to keep this kind ofw thing from happening.i  L Another method, and one that I would be tempted to use, is to configure yourH computer to refuse connections _at all_ from any address that does this.I Consider it an abuse of privilege, and revoke the privilege. :)  This maye7 not be acceptable, depending on your amount of traffic.    Regards,   Chrisr  ! Christopher Smith, Perl Developer- Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");g 's   ------------------------------  % Date: Fri, 06 Apr 2001 19:02:31 -0400e# From: Jim Agnew <Agnew@hsc.vcu.edu>a' Subject: Re: FTP hijacking of VMS sites@+ Message-ID: <3ACE4B07.FEEA1951@hsc.vcu.edu>.  ; We had that happen on a Linux box... they uploaded mp3's...s  0 was a username daniel, (all lowercase) involved?   j.   Lawrence Bleau wrote:e > I > Hello, folks.  I just noticed a lot of oddly named files - directories, O > actually - in my system's anonymous ftp area.  They weren't created by anyonerD > associate with our site.  One associate of mine gave me his guess: > A > i don't know if this is the case here, but i read articles fromaA > people who's anonymous ftp areas have been "hijacked" by peopleoA > distributing large files like movies.  typically, a 1MB file isuF > uploaded to check the speed.  if the hijacker thinks the speed is ok? > lots of directories are created and movie parts are uploaded.u > . > see http://www.macintouch.com/ftphijack.html > O > I think this subject deserves some discussion.  It's the first I heard of it,t1 > and I've been managing VMS systems for a while.K > O > Has anyone experienced this phenomenon?  Has is cropped up at VMS sites?  ArelB > there standard ways of combating it?  Should this be in the FAQ? >  > Lawrence Bleau > University of Maryland$ > Physics Dept., Space Physics Group > 301-405-6223 > bleau@umtof.umd.edut   ------------------------------   Date: 6 Apr 2001 20:43:50 -0500w9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)h' Subject: RE: FTP hijacking of VMS sites03 Message-ID: <mwRsesGB$e9R@eisner.encompasserve.org>s  z In article <3B55D7F383B0D31197D9009027541CBF0D9D1D26@cmiexch1.cmi.itds.com>, Christopher Smith <csmith@amdocs.com> writes:  N > You don't mention whether it is really supposed to be a "public" archive, orL > something else...  The first of these solutions won't work for a site like > that, for obvious reasons. > M > It happens in FTP sites in general.  Typically there are three methods usedoN > to stop it.  Perhaps the most obvious is to disallow anonymous access.  MakeM > an account with a password known only to those people who need access -- oriF > -- give each their own account. (For several reasons this may not be > feasible...) > J > A second way, and perhaps more sane(!) is to disallow read access to theN > upload directories/files in them. :)  This will prevent your site from beingL > of any use to the culprit, and presumably, they should stop soon.  Lots ofM > large sites do this(for instance, wcarchive), probably to keep this kind of  > thing from happening.u  8 Obviously if one configures the machine to allow access,4 one is permitting such usage.  One cannot expect the( Internet to operate on the honor system.   ------------------------------   Date: 7 Apr 2001 00:56:46 GMT / From: Hans.Bachner@altavista.net (Hans Bachner) ' Subject: Re: FTP hijacking of VMS sites ( Message-ID: <9alvlc.ao.1@hans.myfqdn.de>  + Lawrence Bleau (bleau@umtof.umd.edu) wrote:>   <snip>, > Are there standard ways of combating it?    I I didn't read everything on the web page mentioned but IMHO the simplest sK way to keep the hijackers out is to disallow writing for anonymous users - e( if this is possible in your environment.  G Also, if I got http://www.macintouch.com/ftphijack.html correctly, the lK intruders (sometimes?) use directory and file names not allowed on OpenVMS t& systems, which let their attacks fail.   Hans.a   ------------------------------    Date: 07 Apr 2001 08:42:33 +0800, From: Paul Repacholi <prep@prep.synonet.com>' Subject: Re: FTP hijacking of VMS sitese- Message-ID: <87bsq9a6bq.fsf@prep.synonet.com>   , bleau@umtof.umd.edu (Lawrence Bleau) writes:  < > Hello, folks.  I just noticed a lot of oddly named files -B > directories, actually - in my system's anonymous ftp area.  TheyF > weren't created by anyone associate with our site.  One associate of > mine gave me his guess:   A > i don't know if this is the case here, but i read articles fromrA > people who's anonymous ftp areas have been "hijacked" by peopleiA > distributing large files like movies.  typically, a 1MB file is.F > uploaded to check the speed.  if the hijacker thinks the speed is ok? > lots of directories are created and movie parts are uploaded.-  . > see http://www.macintouch.com/ftphijack.html  B > I think this subject deserves some discussion.  It's the first I> > heard of it, and I've been managing VMS systems for a while.  C > Has anyone experienced this phenomenon?  Has is cropped up at VMSmE > sites?  Are there standard ways of combating it?  Should this be inh
 > the FAQ?  A Two possibilities. One is that some enterprising local has dumpedaF stuff there so he can get it without large external trafic showing up.  D The other is that you have been Warezed... Someone has dumped a hugeE load of stuff, and will tell others where to get it. Trouble is, lots9A of these people don't check if anyone can read it, jusy write, so,9 making the incoming directory non-readable won't stop it.o  F Best fun is to point the names to something else. A patched FORMAT.EXE was a friends favorite...w   -- p< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.m@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------  % Date: Fri, 06 Apr 2001 23:43:42 -0400-' From: Jim Becker <jbecker@ui.urban.org>a' Subject: Re: FTP hijacking of VMS sites , Message-ID: <3ACE8CEE.BFB5B059@ui.urban.org>  F Security-wise, it's a mistake to allow reading and writing in the same? directory in an ftp service, because of the exact situation younE describe. If the ftp service doesn't need to allow uploads, make it a- read-only service. 0  E If you need to allow uploads, you can set up a write-only "drop" areanB that's separate from a read-only "pub" area. However, this bears aB cost. For one thing, it can be confusing or disturbing to users ifE they can't verify what they just uploaded. Another issue is that manyt@ GUI ftp clients issue an LS after every PUT; even if the PUT wasE successful, the LS fails, so the client reports "access denied" whichqE misleads the user. Even worse, I've seen at least one GUI client thattE tried an LS or the like before the PUT, so the file wouldn't even getc transferred.  B There was some version of UCX (maybe all of 4.x and earlier?) thatB wouldn't let you create a write-only ftp service. I believe TCP/IPD 5.x+ lets you do that, but I don't have it in front of me to verify.  A Setting a disk quota might not solve the problem sufficiently. ItoC keeps the abuse from getting really bad, but at the same time you'daC still be open to a denial-of-service attack if your space is easilyi filled.t  ? Using passwords is in some ways even less secure than anonymousa5 access. Anonymous access doesn't blast an unencryptedeB username/password pair over the Internet. Anonymous access doesn'tC require you to send usernames and passwords to people who might not B protect the passwords very well. If you don't do anything to avoidB easily guessed usernames and passwords, you won't be all that safeE anyway. Basically, password-controlled ftp is like a conventional car4F lock. Anyone who's determined or skilled can get past it, but at least! it deters the casual opportunist.n   Lawrence Bleau wrote:? > I > Hello, folks.  I just noticed a lot of oddly named files - directories, O > actually - in my system's anonymous ftp area.  They weren't created by anyonerD > associate with our site.  One associate of mine gave me his guess: > A > i don't know if this is the case here, but i read articles from A > people who's anonymous ftp areas have been "hijacked" by peopleeA > distributing large files like movies.  typically, a 1MB file iseF > uploaded to check the speed.  if the hijacker thinks the speed is ok? > lots of directories are created and movie parts are uploaded.e > . > see http://www.macintouch.com/ftphijack.html > O > I think this subject deserves some discussion.  It's the first I heard of it,e1 > and I've been managing VMS systems for a while.e > O > Has anyone experienced this phenomenon?  Has is cropped up at VMS sites?  ArehB > there standard ways of combating it?  Should this be in the FAQ? >  > Lawrence Bleau > University of Maryland$ > Physics Dept., Space Physics Group > 301-405-6223 > bleau@umtof.umd.edu-   --
 Jim Becker+ The Urban Institute (http://www.urban.org/)d' Encompass (http://www.encompassus.org/)-. ESILUG (http://encompasserve.org/lugs/esilug/)   ------------------------------  $ Date: Fri, 6 Apr 2001 21:31:35 +0100, From: "Richard Maher" <maher_rj@hotmail.c*m>; Subject: Galaxy Network Interfaces/cards and TCP/IP Sockets>1 Message-ID: <9al923$gk8$1@uranium.btinternet.com>t   Hi,m  < Hardware is not my strong point so please be gentle with me.  J Note: This has *nothing* to do with cluster alias' I cannot take advantage8 of that functionality so let's pretend it doesn't exist.  " 1) NODE1 (in a cluster with NODE2)  D On NODE1 with Alpha VMS 7.2 with two network interfaces 1.2.3.10 andK 1.2.3.20, my listening socket program can choose to listen on INADDR_ANY ornD either of the above two address. If NODE1 goes down and a copy of myL listener program comes up on NODE2 then is there no way for my program to beJ able to send or receive TCP/IP traffic on 1.2.3.10 or .20? (assuming NODE2 has one network card 1.2.3.30)  K 2) GALAXY/WILDFIRE VMS 7.3 One box two virtual nodes (ie a two node clusterg	 in a box)w  J Is it correct that the cards are stuck in the box and available to all hot swapable CPU to node thingies?  I Or put another way, are the Network Cards served/on a bus/controllered sonL that I can have a copy of my server program listening on both internal nodesG at either address. For example, if NODE1 whent down when my program wassF listening at 1.2.3.10 and it was rerun automatically on NODE2 could it) listen and tranceive at the same address?.   Regards Richard MaherM   ------------------------------   Date: 6 Apr 2001 13:53:42 -0500-3 From: malmberg@encompasserve.org (John E. Malmberg)2J Subject: Re: How do I redefine the alias between SYSCOMMON and VMS$COMMON?3 Message-ID: <JATU8bMjzOBM@eisner.encompasserve.org>s  : hammond@not@peek.ppb.cpqcorp.net (Charlie Hammond) writes:/ In article <00256A25.005B3D70.00@quegw01.btyp>,m& Steve.Spires@yellgroup.company writes:  ? >>How do I redefine the alias between SYSCOMMON and VMS$COMMON?  >h9 > I assume you mean SYS$SYSDEVICE:[SYSx]SYSCOMMON.DIR andi9 >                   SYS$SYSDEVICE:[000000]VMS$COMMON.DIR.e >yH > The answer is, if these already exist as separate files (directories),A > then there is no direct way to make them aliases of each other.  >pJ > SYSCOMMON.DIR is normaly created by a SET FILE /ENTER command similar to > the following: >"; >     $ SET FILE /ENTER=SYS$SYSDEVICE:[SYS0]SYSCOMMON.DIR -a. >         SYS$SYSDEVICE:[000000]VMS$COMMON.DIR >hK > But if SYS$SYSDEVICE:[SYS0]SYSCOMMON.DIR already exists, this won't work.  >iJ >>I had a node for which I had restored the system disk from LEGATO backupH >>on to another node [the reasons aren't important in the context of theH >>question], and found that the OPS guys had incorrectly set a switch onK >>the backup command which meant that [SYS0.SYSCOMMON...] wasn't backup up. H >>I restored this from the original disk, but now I wonder, do I need toI >>have a VMS$COMMON structure [via an alias] - the node isn't clustered -g? >>and if so, how do I do this using the SET FILE/ENTER command?  <snip>  C Another thing to consider, is what is in the boot block of the diskm in question?  E I do not know what LEGATO does, but an IMAGE backup/restore is needed$ to make the disk bootable.   If one switch was wrong...   -Johnd wb8tyw@qsl.network Personal Opinion Onlyi   ------------------------------    Date: 07 Apr 2001 04:51:07 +0800, From: Paul Repacholi <prep@prep.synonet.com>J Subject: Re: How do I redefine the alias between SYSCOMMON and VMS$COMMON?- Message-ID: <877l0xbvlw.fsf@prep.synonet.com>v  5 malmberg@encompasserve.org (John E. Malmberg) writes:k  E > Another thing to consider, is what is in the boot block of the diske > in question?  @ > I do not know what LEGATO does, but an IMAGE backup/restore is# > needed to make the disk bootable.o   > If one switch was wrong...  E Perhaps more. On an image backup, backup hunts down the file the boot H block points to, and marks it. When the disk is restored, the boot block  is writen with updated pointers.  C If they are wrong when a backup is done, the new ones will point toiD the wrong place. You may not notice this on a Vax with ROM VMB until  you try to boot another model...  " Writeboot may be needed to fix it.   -- -< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.i@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------   Date: 7 Apr 2001 01:35:39 GMTl* From: bleau@umtof.umd.edu (Lawrence Bleau)J Subject: Re: How to tell if a system is booting immediately after a crash.) Message-ID: <9alqtb$iai$1@hecate.umd.edu>a  e In article <W4Ey6.24163$PF4.36434@news.iol.ie>, "Tom Wade" <t.wade@vms.eurokom.ie.removespam> writes:o >s: >Lyndon Bartels <lbartels@pressenter.com> wrote in message) >news:3AC8D949.281B9C29@pressenter.com...oI >> I want, during a startup, if the system has gone done as a result of aF+ >> crash or power outage or... whatever....T >>J >> Why? So if the system crashes and reboots in the middle of the night, I1 >> can tell the computer to page me or something.  >>E >> I was thinking of having syshtdown.com write out a data file. ThenrE >> during subsequent boot, systartup_vms look for the file, if found, I >> delete all versions of the file, and peacefully exit. If not found, so  >> my alarm procedures.. > H >Rather than generate Unix style flag files, why not use one of the userJ >defined SYSGEN parameters ?  For example, set the parameter USER3 to 1 inH >SYSGEN and WRITE CURRENT. Your system shutdown command file can set theJ >parameter to 0.  The startup file checks the value of USER3.  If it is 0,H >then assume a normal shutdown was done, set the parameter back to 1 andG >exit. If the parameter is 1 already you can assume a crash took place.h  M This sounds good, but it only says if the system crashed, not any other info.y  M On my system, I wanted to know *when* it crashed.  To do this I used a coupled) of "flag files" and a detached process.  n  J First, I wrote a short DCL .com file that I ran as a detached process.  It= WAITs for 10 minutes, then does a open/read/write on the file,L SYS$SPECIFIC:[SYSMGR]SHUTDOWN_TIME.DAT, reads the first (and only) line, andO overwrites it (using write/update) with the current time.  Thus, this file willwM always be within 10 minutes of a system shutdown or crash.  This gets startedt0 during system startup, usually in the END phase.  L Second, I modify SYSHUTDWN.COM to write the reason for the shutdown into theO file SYS$SPECIFIC:[SYSMGR]SHUT_REASON.DAT.  The reason can be obtained from theeG symbol shutdown$reason.  If this symbol is not defined I use the stringw@ "unspecified".  If a system crashes this file is not written to.  O Third, I have a file (RECORD_BOOTTIME.COM) that is executed during system boot.rN It overwrites the file SYS$SPECIFIC:[SYSMGR]BOOT_TIME.DAT with the current VMSL time (again using a DCL read followed by a write/update).  However, it savesL the previous contents of the file's first (and only) line before overwritingL it.  The saved (which I'll call previous) contents is when the system bootedK prior to the current boot; ie, when the system last fully booted before the O crash.  It next reads the contents of SHUTDOWN_TIME.DAT to get an approximationeM of the time the system was shut down or crashed.  It also reads and overwiteslN the file REASON.DAT.  It saves the line it read, then overwites the first lineO with the string "unscheduled".  As noted above, if SYSHUTDWN.COM isn't run then-N REASON.DAT is not changed, so the next boot (ie, after a crash) will have the B reason "unscheduled".  Finally, this procedure appends to the fileG SYS$SPECIFIC:[SYSMGR]UPTIME.DAT a single line containing the boot time,v' shutdown or crash time, and the reason.M  K By examining the UPTIME.DAT file I can tell when a system was shut down for N upgrades or maintenance, when the operator shut it down and just didn't botherL to give a reason, and when it crashed, along with an idea of how long it wasJ down.  This gives me a good estimate of % downtime, which was the originalO motivation.  You can see, however, how easy it would be for RECORD_BOOTTIME.COMnJ to send the short line it creates to some paging software if the reason isJ "unscheduled" but not do so otherwise.  We wouldn't want you getting pagedO every time it reboots during, say, a system upgrade, or if you took it down for H maintenance (that'd really annoy me; as if I didn't know that already!).  H If anyone wants a copy of these procedures I'll be happy to supply them.   Lawrence Bleau University of Maryland" Physics Dept., Space Physics Group 301-405-6223 bleau@umtof.umd.edut   ------------------------------  $ Date: Fri, 6 Apr 2001 15:30:34 -04002 From: "Sue Skonetski" <susan.skonetski@compaq.com>- Subject: London, England Technical Update Dayt2 Message-ID: <PPoz6.648$fB6.17182@news.cpqcorp.net>   Dear Newsgroup,e   As promised.  H Here is the URL for the OpenVMS Technical Update days in London England.  2 http://www.wordsbureau.co.uk/vms-technical-update/  - It works from Netscape and Internet explorer.e  
 Warm Regards,g   Sue    ------------------------------  # Date: Fri, 06 Apr 2001 18:17:42 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)9 Subject: Re: OVMS Tech Update Presentations [and Mozilla]t2 Message-ID: <aLnz6.641$fB6.17003@news.cpqcorp.net>  W In article <C2256A26.004FD4AE.00@jklh21.valmet.com>, norm.raphael@jamesbury.com writes:e  B   Not having seen Rich Marcello's slide(s) in question, Mozilla isB   currently in beta -- that is the status of the code (and of the @   schedule :-) that is presently available from the hard-workingB   (and I do mean that seriously) folks at Mozilla.org, hence that $   is the status of the OpenVMS port.  C   I'll update the Mozilla link rot for the next edition of the FAQ.F  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Fri, 06 Apr 2001 18:11:19 GMTu2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)1 Subject: Re: Seeking CD-R/CD-RW SCSI INQUIRY data 2 Message-ID: <bFnz6.640$fB6.17003@news.cpqcorp.net>   In article <009FA215.CEFA4021.1@CHCLU.CHEMIE.UNI-KONSTANZ.DE>, Eberhard Heuser-Hofmann <vaxinf@chclu.chemie.uni-konstanz.de> writes:H :Not the drives are the problem, but the OS (guess which one I mean...).J :You see this if you switch to linux and the drive runs nicely on the same
 :hardware.  I   The reason here being that the applications are coded to deal with eachiJ   of the three major command sets of CD-R drives, and with some hope that L   the results will work.  The drive interfaces are follow the specificationsK   but are not consistent -- most (all) of the SCSI CD-R drives I've looked eJ   at use the SCSI vendor-specific extensions, and typically operate with a6   variation of any one of the three SCSI command sets.  I :>The question is, if this happens on VMS, who debugs it and supports it?eJ :>There are limited cycles available to do all the work that is requested. :rH :So why people like Joerg Schilling, the author of cdrecord, is able to J :write a program for many platforms and a huge amount of different drives?F :He owns only about five drives, but due to the linux idea many people :share their knowledge.t  H   Ayup, and I've been looking at and learning from various existing CD-RL   tools and associated code.  I've specifically looked at CDwrite15 -- your F   port of that version, of course -- as well as at the CDwrite20 code.   :...# :Here is my "supported" drive list:h : 
 :Yamaha 6420st :Philips CDD2000 :HP 6020
 :TEAC CD-R58So :TEAC CD-W512EB   G   And most of (all of?) these drives either require or offer different t    vendor-specific SCSI commands.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  $ Date: Fri, 6 Apr 2001 16:04:15 -05001 From: "Dave Gudewicz" <david.gudewicz@abbott.com>   Subject: Re: Updated information8 Message-ID: <9alb0r$9vg$1@fizban.fizban.pprd.abbott.com>  ) Funny you should mention Patrick Stewart.   H My son one day cut out his picture and pasted it over mine on my work IDF badge.  I've left it there ever since.  Draws attention and a chuckle.  
 Picard out...M  = "Sue Skonetski" <susan.skonetski@compaq.com> wrote in message , news:sE4z6.605$fB6.16615@news.cpqcorp.net... > Dear Newsgroup,  >  > Just a couple of things. > H > If you are planning on attending either the Dallas or London technicalL > update days please make sure you stop by an introduce yourself. In my mindL > you all look like Harrison Ford or Patrick Stewart (my favorite actors and? > all around handsome dudes) and its really messing up my head!5 >9? > The London URL should be up tomorrow and I will post it here.a >wI > The Dallas URL is  http://www.dfwcug.org    Additionally Jim Becker hastG > kindly posted the presentations from the DC event (thank you Jim) at:eL > <http://encompasserve.org/lugs/esilug/> you may want to take a look so you > know what to expect. >hJ > The question you have to ask your self is "Will Sue throw anything at me orI > just the lighting fixtures?" If you were in DC you would know what thist > means. >l > ALSO >hK > The customer version of OpenVMS Times will be up on the external web sitet? > tomorrow morning (Warren refreshes the web site every evenings >e7 > http://www.openvms.compaq.com/openvmstimes/index.html  >s >      Warm Regards, >r	 >     Suer >e >k >e >e >e >T >o   ------------------------------  % Date: Fri, 06 Apr 2001 14:29:39 -0400   From: jamese@beast.dtsw.army.mil/ Subject: Re: VMS equivalent of Unix wc command?i0 Message-ID: <01040614293904@beast.dtsw.army.mil>   Greg,v  3 "Greg Zymbaluk" <greg.zymbaluk@compaq.com> wrote onmI Fri, 6 Apr 2001 11:01:14 -0600 in <ADmz6.636$fB6.16968@news.cpqcorp.net>:r  9 > Is there a VMS equivalent of the Unix wc -l command to n > count the lines in a file?  D There are several ways to do this. You can use SEARCH, specify /STAT, and give it a nonsense string to search for:  % $ search login.com "^&&^^%%$$$" /stateE Files searched:                 1       Buffered I/O count:        13 E Records searched:             430       Direct I/O count:           9aE Characters searched:        14804       Page faults:               16eH Records matched:                0       Elapsed CPU time:  0 00:00:00.00H Lines printed:                  0       Elapsed time:      0 00:00:00.14' %SEARCH-I-NOMATCHES, no strings matcheda  C Or you can get wc from <ftp://alpha.nuceng.ufl.edu/wc> and use it.  > There was one posted to this list in 1992 that I can send you.  : Ed James                           ed.james@telecomsys.com5 TeleCommunications Systems, Inc.   voice 410-295-1919.; 2024 West Street, Suite 300              800-810-0827 x1919w5 Annapolis, MD 21401-3556           fax   410-280-1094    ------------------------------  % Date: Fri, 06 Apr 2001 15:25:22 -0400u- From: John Reagan <reagan@hiyall.zko.dec.com> / Subject: Re: VMS equivalent of Unix wc command?h2 Message-ID: <3ACDDFE2.6EBB81EA@hiyall.zko.dec.com>   Greg Zymbaluk wrote: >  > Hi,p > M > Is there a VMS equivalent of the Unix wc -l command to count the lines in ab > file?r  7 Another techique for many text files is copy/log to nl:   # $ copy /log sys$login:login.com nl:iF %COPY-S-COPIED, PAS$:[REAGAN]LOGIN.COM;231 copied to NL: (120 records)   -- i John Reagan  Compaq Pascal Project Leader   ------------------------------  # Date: Fri, 06 Apr 2001 22:23:15 GMT + From: Jeff Campbell <jcampbell@ins-msi.com>p/ Subject: Re: VMS equivalent of Unix wc command?i+ Message-ID: <3ACE3BF8.9375BDCE@ins-msi.com>a   Greg Zymbaluk wrote: >  > Hi,o > M > Is there a VMS equivalent of the Unix wc -l command to count the lines in a- > file?- > 	 > Thanks,, >  > Greg  C The closest command for a text file - COPY/LOG FILE.NAME NL:, whichG3 will tell you the number of records (lines) copied.e  
 Jeff Campbell$ n8wxs@arrl.net   ------------------------------   Date: 6 Apr 2001 17:53:09 -0700e< From: babiarz at endor stop com <babiarz_member@newsguy.com>/ Subject: Re: VMS equivalent of Unix wc command?n) Message-ID: <9alodl01r4c@drn.newsguy.com>   H I use SEARCH/STATISTICS myself. It work just fine with other information0 with it. I belive it uses less qio than copy/log   john babiarz  8 In article <3ACE3BF8.9375BDCE@ins-msi.com>, Jeff says... >  >Greg Zymbaluk wrote:o >> w >> Hi, >> oN >> Is there a VMS equivalent of the Unix wc -l command to count the lines in a >> file? >> d
 >> Thanks, >> P >> Grego >.D >The closest command for a text file - COPY/LOG FILE.NAME NL:, which4 >will tell you the number of records (lines) copied. >o >Jeff Campbell >n8wxs@arrl.neti   ------------------------------   Date: 6 Apr 2001 20:44 CST' From: carl@gerg.tamu.edu (Carl Perkins) / Subject: Re: VMS equivalent of Unix wc command?o, Message-ID: <6APR200120441005@gerg.tamu.edu>  4 "Greg Zymbaluk" <greg.zymbaluk@compaq.com> writes...L }Is there a VMS equivalent of the Unix wc -l command to count the lines in a }file? }  }Greg   0 It might depend on what you mean by "lines", but assuming 1 line = 1 record...a  ) There are probably several ways to do it:- $ COPY/LOG foo.bar NL: andeE $ SEARCH/STAT foo.bar somerandomsearchstringthatprobablyisntinthefile  are two of them.   --- Carl   ------------------------------  % Date: Fri, 06 Apr 2001 23:36:08 +020082 From: martin@radiogaga.harz.de (Martin Vorlaender)/ Subject: Re: VMS equivalent of Unix wc command?a; Message-ID: <3ace36c8.524144494f47414741@radiogaga.harz.de>l  / Greg Zymbaluk (greg.zymbaluk@compaq.com) wrote:lM > Is there a VMS equivalent of the Unix wc -l command to count the lines in aS > file?M  ( $ SEARCH /STATISTICS yourfile somestring  5 The field "Records searched" has the number of lines.s   cu,d   Martin --J One OS to rule them all       | Martin Vorlaender  |  VMS & WNT programmer7 One OS to find them           | work: mv@pdv-systeme.dedJ One OS to bring them all      |   http://www.pdv-systeme.de/users/martinv/> And in the Darkness bind them.| home: martin@radiogaga.harz.de   ------------------------------  $ Date: Fri, 6 Apr 2001 15:27:28 -0400' From: "Bill Todd" <billtodd@foo.mv.com> $ Subject: Re: VMS-Related: Affordable( Message-ID: <9al5at$fa7$1@pyrite.mv.net>  < Malcolm Dunnett <nothome@spammers.are.scum> wrote in message& news:7LEm389Vfl8O@malvm1.mala.bc.ca...J > In article <OFF05286E4.BAB0DD32-ON80256A26.00365DC4@qedi.quintiles.com>,( >     steven.reece@quintiles.com writes: > >> > >t > > It's a unix-ism Tim  :-)E > > If you want the write to complete before the completion status isa returnedH > > then use VMS.  If you want to think that it's been written but don't  > > actually care then use Unix. >eJ >     I'm no Unix expert, but it appears that ( at least with Tru64 Unix )1 > there's an option on mount ( sync ) which says:c >/ >   syncI >       Causes all writes to be written immediately to disk as well as tod thet >       buffer cache.l >i# >    This option is off by default.- >-E >    It appears the default is to synchronously write all file system. > metadata updates thought.w  H On some Unix file systems, anyway.  And others provide equivalently-safeK mechanisms via ordering writes (IIRC, Spiralog did something like this at agL lower level).  ext2fs on Linux is a conspicuous exception, however, and many: people believe using it carries considerably greater risk.   >nJ >   From the above it would seem that getting the VMS behaviour on Unix is6 > a lot easier than getting the Unix behaviour on VMS.  I Actually, safer-than-default VMS behavior.  But only on a filesystem-wide G basis (given that it's a mount option), so it's less than ideal - e.g.,tI being able to specify it as a file-access-time option would be convenient H when all writes *by this accessor to that file* should be forced to diskL (this is the Win32 FILE_FLAG_WRITE_THROUGH option, and it somewhat surprisesL me that I can't find a reference to a similar option in RMS), and being ableL to specify it on a per-write-operation basis would mean that you could forceI to disk only the data that needed to go there, rather than all dirty data-A for the file (this would be the file-level equivalent of the SCSIa. per-write-operation 'force unit access' flag).  G Some file systems (VxFS for one, IIRC) also provide a mount option that9; forces all dirty data for the file to disk when the (last?)6E (write-?)accessor closes the file.  This is closer to the default VMSoI sequential-file behavior (and reportedly is there to give default PC-like82 buffering semantics to people who depend on them).  I And my (vague) recollection is that at least some Unix file systems allowuI completely unbuffered (but still file-structured, not 'raw') access as aniF option, though it may only be controllable at mount level (possibly toK facilitate running things like Oracle on top of VxFS without the additional.J and largely useless overhead of file-system-level buffering).  Which wouldH allow an application to roll its own internal buffering very much as RMS does on VMS.  J The bottom line is that Malcolm's comment above is right on the mark.  VMSF *does* in fact *allow* one to obtain a wide range of desired bufferingI behaviors, but usually only with moderate-to-excruciating pain (e.g., thenE need to screw around explicitly with buffer sizes, buffer counts, and H read-ahead/write-behind options - the last of which aren't usable if theH file is write-shared, so explicit global buffering has to be explored toG obtain anything like Unix default behavior).  And I don't think there'smG *any* way to obtain the Unix behavior that allows temporary files to bet@ created, used, and deleted without ever hitting the disk at all.  K The other pertinent observation is that, whereas Unix's default behavior iseH exactly what many (though not all) applications desire, VMS's (actually,A RMS's) *default* behavior for sequential files is desired by *no*oD applications:  the moderately exceptional application that wants theE security of knowing that data is on disk after every insertion/updatetD operation doesn't get it, and the common application that just wantsF performance and is happy to request persistence (by 'flush' or 'sync')4 explicitly when it needs it doesn't get that either.   - bill   >h   ------------------------------   Date: 6 Apr 2001 15:51:59 -0500s+ From: young_r@encompasserve.org (Rob Young)e$ Subject: Re: VMS-Related: Affordable3 Message-ID: <kmld+QTjXhOV@eisner.encompasserve.org>B  ` In article <7LEm389Vfl8O@malvm1.mala.bc.ca>, nothome@spammers.are.scum (Malcolm Dunnett) writes:K > In article <OFF05286E4.BAB0DD32-ON80256A26.00365DC4@qedi.quintiles.com>, i( >     steven.reece@quintiles.com writes: >> n >>   >> It's a unix-ism Tim  :-))M >> If you want the write to complete before the completion status is returned G >> then use VMS.  If you want to think that it's been written but don'ts >> actually care then use Unix.. > J >     I'm no Unix expert, but it appears that ( at least with Tru64 Unix )1 > there's an option on mount ( sync ) which says:s >  >   syncM >       Causes all writes to be written immediately to disk as well as to thei >       buffer cache.n > # >    This option is off by default.U > E >    It appears the default is to synchronously write all file systema > metadata updates thought.  > J >   From the above it would seem that getting the VMS behaviour on Unix is6 > a lot easier than getting the Unix behaviour on VMS. >   H 	Maybe not.  Perhaps even better functionality.  Future versions of XFC G 	support write-behind.  Or more accurately, occasional future roadmaps w# 	do ;-).  Hooks are in place today:t  M http://kuhub.cc.ukans.edu/www/html/721final/6520/6520pro_004.html#index_x_144l  & 	VCC writebehind and VCC writedelay..  	aD 	I remember seeing discussion (where?) regarding this future featureB 	and believe it has some nice granularity associated with it.  PerA 	disk, or per directory or per file, I believe.  But that is fromh# 	memory and you know how that goes.w   				Robt   ------------------------------    Date: 07 Apr 2001 04:12:00 +0800, From: Paul Repacholi <prep@prep.synonet.com>$ Subject: Re: VMS-Related: Affordable- Message-ID: <87k84xbxf3.fsf@prep.synonet.com>o  ) "Bill Todd" <billtodd@foo.mv.com> writes:e  A > The other pertinent observation is that, whereas Unix's defaultyE > behavior is exactly what many (though not all) applications desire,-D > VMS's (actually, RMS's) *default* behavior for sequential files isF > desired by *no* applications: the moderately exceptional applicationE > that wants the security of knowing that data is on disk after everyg; > insertion/update operation doesn't get it, and the commonhA > application that just wants performance and is happy to requestk@ > persistence (by 'flush' or 'sync') explicitly when it needs it > doesn't get that either.  A Eh? A $FLUSH does get it onto the drive. The default behaviour is7B easily tuned by process defaults. The others are in the main, easy= to tweek witha few small source fixes, depending on language.D  B The change that VMS has not kept up with is usage. A single person@ per machine is now very common, so the minimum resource, maximum4 overlap defaults are not well suited to those users.   -- l< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.o@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------  $ Date: Fri, 6 Apr 2001 17:00:38 -0400' From: "Bill Todd" <billtodd@foo.mv.com> $ Subject: Re: VMS-Related: Affordable( Message-ID: <9alapm$l8r$1@pyrite.mv.net>  6 Rob Young <young_r@encompasserve.org> wrote in message- news:kmld+QTjXhOV@eisner.encompasserve.org...-H > In article <7LEm389Vfl8O@malvm1.mala.bc.ca>, nothome@spammers.are.scum (Malcolm Dunnett) writes:    ...-  J >   From the above it would seem that getting the VMS behaviour on Unix is8 > > a lot easier than getting the Unix behaviour on VMS. > >- >D0 > Maybe not.  Perhaps even better functionality.   Could you provide an example?t     Future versions of XFCG > support write-behind.  Or more accurately, occasional future roadmaps.$ > do ;-).  Hooks are in place today: >  > L http://kuhub.cc.ukans.edu/www/html/721final/6520/6520pro_004.html#index_x_14 4  >l& > VCC writebehind and VCC writedelay.. > E > I remember seeing discussion (where?) regarding this future featureoC > and believe it has some nice granularity associated with it.  PernB > disk, or per directory or per file, I believe.  But that is from$ > memory and you know how that goes.  J I'm afraid so.  It's all too reminiscent of the years you spent respondingH to performance criticisms by saying "Just wait for Wildfire - it'll blowK everything else out of the water!"  Now that this prediction hasn't exactly C panned out, you've switched to "Just wait for EV8 and/or Marvel..."i  H There's no question but that XFC improves the situation in general.  TheL currently-shipping version, however, does nothing for writes (the subject ofE this thread), and unless you can point to some credible document thatlH indicates *exactly* what's on the platter for future releases we'll just have to wait and see.n  H No matter what XFC does, there's likely to be some minor performance hitI compared with the Unix approach simply because in making its enhancements K transparent (which I agree is generally a Good Thing) it will result in twosL data copies (once to/from a process's internal RMS buffer, and a second timeH to/from the XFC's lower-level cache) rather than Unix's one.  The C RTL,K since it appears to bypass RMS anyway, could choose to take advantage of an-G extended system interface (if provided) that allowed it to present data H directly to the system (without buffering it itself), just as happens onI Unix, but changing RMS to support such behavior would likely at a minimum-I require a non-transparent extension (since some existing applications mayzH *want* to buffer their data internally, and the XFC is likely far enoughJ away from the process in terms of code path that buffering 'way down there& instead may not really be equivalent).  J Another change that could not always be made transparent is the ability toL have something like a temporary file never hit the disk if it's deleted soonJ enough.  While the system could perhaps do this transparently for any fileL created 'TMD' or 'MKD' (since the deletion is then part of the Close processH and Close could recognize that it didn't have to flush any dirty data inH such a case), for other files just created, closed, and then deleted theK data would be flushed on the Close unless an application made some explicityJ indication that it should not be (rather than the Unix approach which saysL that if an application wants data flushed on Close, *that* must be indicatedL explicitly - by a 'sync' request preceding the Close.  And that still leavesH aside the question of whether such files would perform on-disk directoryH updates on creation and again on deletion (IIRC some Unix file systems -6 e.g., SGI's XFS - can avoid even those disk accesses).  G The above notwithstanding, *if* XFC does everything right *most* of the G actually significant differences between VMS and Unix write performance I should disappear transparently or at worst require only minor applicationi tweaks to make irrelevant.   - bill   >r > Robn >    ------------------------------  $ Date: Fri, 6 Apr 2001 17:34:28 -0400' From: "Bill Todd" <billtodd@foo.mv.com>s$ Subject: Re: VMS-Related: Affordable( Message-ID: <9alcov$nig$1@pyrite.mv.net>  7 Paul Repacholi <prep@prep.synonet.com> wrote in message-' news:87k84xbxf3.fsf@prep.synonet.com...0+ > "Bill Todd" <billtodd@foo.mv.com> writes:t >sC > > The other pertinent observation is that, whereas Unix's default-G > > behavior is exactly what many (though not all) applications desire,eF > > VMS's (actually, RMS's) *default* behavior for sequential files isH > > desired by *no* applications: the moderately exceptional applicationG > > that wants the security of knowing that data is on disk after everya= > > insertion/update operation doesn't get it, and the commoniC > > application that just wants performance and is happy to request B > > persistence (by 'flush' or 'sync') explicitly when it needs it > > doesn't get that either. > * > Eh? A $FLUSH does get it onto the drive.  K Perhaps you didn't understand the statement above:  it simply observes thateG the default RMS sequential-file behavior (poor performance due to smalliI in-process buffers coupled with no guarantee of per-operation persistenceAE despite that poor performance) is not the preferred behavior of *any*lL rational application, whereas the default Unix behavior is quite suitable toG likely the majority of applications (and the availability of the 'sync'eG operation satisfies virtually all of the rest with minimal overhead andW complexity).    The default behaviour is0# > easily tuned by process defaults.   J Is there a process default that forces write-through to disk on every $PUT9 (that's not a rhetorical question:  I really don't know)?l  ? Is there a process default that enables read-ahead/write-behinde1 multi-buffering transparently to the application?   J Is there a process default that enables global buffering for inter-processL sharing (VIOC and now XFC should help here, though - in the absence of writeL activity, anyway - and IIRC there may be a file attribute that causes global buffers to be used)?  K And, of course, while those of the above that *do* exist may be transparent K to the application, *someone* still has to muck around setting them up - as:9 contrasted with the behavior one gets by default on Unix.u  !  The others are in the main, easyc? > to tweek witha few small source fixes, depending on language.m  I The abysmal performance of many applications ported to VMS indicates thatoI many people do not find this worth whatever degree of effort is required.    >sD > The change that VMS has not kept up with is usage. A single personB > per machine is now very common, so the minimum resource, maximum6 > overlap defaults are not well suited to those users.  D Correction:  they're not well-suited to *any* modern system in *any*I context.  What VMS has not kept up with is the availability of relatively I inexpensive memory:  availability of reasonable amounts of system memory,uH more than anything else (coupled with very inexpensive system calls - noJ address-space context-switch required - but largely independent of usage),J is what makes per-process buffering obsolete (and very tight system memoryH constraints, as was true back when VMS was designed, made the ability to> swap buffers along with their associated processes desirable).   - bill   >O > --> > Paul Repacholi                               1 Crescent Rd.,9 > +61 (08) 9257-1001                           Kalamunda.-B >                                              West Australia 60760 > Raw, Cooked or Well-done, it's all half baked.   ------------------------------    Date: 07 Apr 2001 07:25:35 +0800, From: Paul Repacholi <prep@prep.synonet.com>$ Subject: Re: VMS-Related: Affordable- Message-ID: <87wv8xa9w0.fsf@prep.synonet.com>a  ) "Bill Todd" <billtodd@foo.mv.com> writes:a  L > Is there a process default that forces write-through to disk on every $PUT; > (that's not a rhetorical question:  I really don't know)?R  D No, And I doubt you would WANT a disk IO per PUT for every IO! Add aD flush after each PUT if that is needed, where it is needed. And turn= on write checking as well, or you are wasting everyones time.a  A > Is there a process default that enables read-ahead/write-behinde3 > multi-buffering transparently to the application?.  B If you use multi buffering (see SET RMS) it happens automatically.  S> > Is there a process default that enables global buffering forD > inter-process sharing (VIOC and now XFC should help here, though -D > in the absence of write activity, anyway - and IIRC there may be a8 > file attribute that causes global buffers to be used)?  B Yes, it is per file. I suspect that the VFC will be global buffers done over on steriods in P2.  A > And, of course, while those of the above that *do* exist may bedD > transparent to the application, *someone* still has to muck around? > setting them up - as contrasted with the behavior one gets byl > default on Unix.  = Oh, do you mean you don't ever have to tune your unix system?y  # >  The others are in the main, easyeA > > to tweek witha few small source fixes, depending on language.. > K > The abysmal performance of many applications ported to VMS indicates thatmK > many people do not find this worth whatever degree of effort is required.   G No, it indicates no effort, and in some cases, even less understanding.sE If you want a good example, get Sam Leiflers TIFF library and look atwI how that handles the IO. And I don't think SGI are a secret VMS covern :)x   > >uF > > The change that VMS has not kept up with is usage. A single personD > > per machine is now very common, so the minimum resource, maximum8 > > overlap defaults are not well suited to those users.  F > Correction:  they're not well-suited to *any* modern system in *any*K > context.  What VMS has not kept up with is the availability of relativelydK > inexpensive memory:  availability of reasonable amounts of system memory,v  ? DS20 owners would claim that Compaq's memory prices fix that :)m  J > more than anything else (coupled with very inexpensive system calls - noL > address-space context-switch required - but largely independent of usage),L > is what makes per-process buffering obsolete (and very tight system memoryJ > constraints, as was true back when VMS was designed, made the ability to@ > swap buffers along with their associated processes desirable).  F The prices of system and memory is about the same now as ever. PerhapsC about a 2:1 difference. The price of both have dropped like a rock,e& and the performance has shot sky high.  A The big change is that we have gone back to the core days problemGF of huge latency to memory in cpu clocks. Ironically, adding to this byG shoving data around in caches and buffers is the last thing you want toa do.w   -- e< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.-@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------  $ Date: Fri, 6 Apr 2001 22:49:50 -0400' From: "Bill Todd" <billtodd@foo.mv.com>t$ Subject: Re: VMS-Related: Affordable( Message-ID: <9alv8b$921$1@pyrite.mv.net>  7 Paul Repacholi <prep@prep.synonet.com> wrote in messagei' news:87wv8xa9w0.fsf@prep.synonet.com...n+ > "Bill Todd" <billtodd@foo.mv.com> writes:  > I > > Is there a process default that forces write-through to disk on everyp $PUT= > > (that's not a rhetorical question:  I really don't know)?i >p@ > No, And I doubt you would WANT a disk IO per PUT for every IO!  F In most cases, I would agree - but this is exactly what the people whoL *think* that $PUT completion means their record is safely on disk seem to be advocating.n    Add a= > flush after each PUT if that is needed, where it is needed.   I Which is precisely the Unix philosophy - and Unix by default provides the @ buffer space to make the resulting performance close to optimal.  	  And turne? > on write checking as well, or you are wasting everyones time..  H Not really.  Not only are unreported disk write errors and sudden sectorG deterioration several orders of magnitude more rare than, say, power ortC other system interruptions (the principal cause of lost data due tooI write-back caching), but when you throw in the likelihood that people whorJ care that much about their data have made their back-end storage redundantK the marginal utility of write-checking (even ignoring its significant cost)t becomes damn close to nil.   >,C > > Is there a process default that enables read-ahead/write-behindl5 > > multi-buffering transparently to the application?l >bD > If you use multi buffering (see SET RMS) it happens automatically.  7 That form of control is not one I'm familiar with.  ButoJ read-ahead/write-behind do not IIRC happen 'automatically' when one simplyJ specifies multiple buffers via the RAB MBC mechanism:  you have to request them explicitly in ?ROP?.    >f@ > > Is there a process default that enables global buffering forF > > inter-process sharing (VIOC and now XFC should help here, though -F > > in the absence of write activity, anyway - and IIRC there may be a: > > file attribute that causes global buffers to be used)? >rD > Yes, it is per file. I suspect that the VFC will be global buffers > done over on steriods in P2. >uC > > And, of course, while those of the above that *do* exist may be@F > > transparent to the application, *someone* still has to muck aroundA > > setting them up - as contrasted with the behavior one gets byp > > default on Unix. >n? > Oh, do you mean you don't ever have to tune your unix system?   H I don't have a Unix system.  But if I did, that's not an area that wouldH normally require tuning.  Modern commercial Unixes (though AFAIK not yetJ Linux) use a 'unified buffer cache' (similar to NT's) that flexibly allowsF the system to balance use of physical memory between caching and otherB (e.g., process and system) activity.  Not to mention the fact thatI per-process tuning is effectively per-application tuning and thus a majora2 pain in the ass compared with system-level tuning.   >t% > >  The others are in the main, easysC > > > to tweek witha few small source fixes, depending on language.e > > H > > The abysmal performance of many applications ported to VMS indicates thatC > > many people do not find this worth whatever degree of effort isk	 required.a >tI > No, it indicates no effort, and in some cases, even less understanding.#  / Exactly how does that differ from my statement?.  G > If you want a good example, get Sam Leiflers TIFF library and look ateK > how that handles the IO. And I don't think SGI are a secret VMS covern :)o >e > > >tH > > > The change that VMS has not kept up with is usage. A single personF > > > per machine is now very common, so the minimum resource, maximum: > > > overlap defaults are not well suited to those users. >oH > > Correction:  they're not well-suited to *any* modern system in *any*B > > context.  What VMS has not kept up with is the availability of
 relativelyE > > inexpensive memory:  availability of reasonable amounts of systeml memory,n >tA > DS20 owners would claim that Compaq's memory prices fix that :)f  I The key word is 'relatively'.  VMS V1 was designed to run (marginally) inoJ 256 KB of memory (and IIRC using just 2 30 MB RK06 drives, though it mightI have required RK07s).  This left very little room for applications of anyaK size, but it was the minimum supported configuration.  Take a look at VMS'suI minimum supported configuration today, and you'll very likely see that nooK one feels the need to constrain application-available space anywhere nearlytJ this much - because avidly conserving required memory is *relatively* lessL important compared with the virtues of having a more responsive, more usableH system.  And of course the main costs of systems today tend to be peopleI costs rather than hardware costs, which just makes memory even cheaper ine any TCO sense.   >hL > > more than anything else (coupled with very inexpensive system calls - noF > > address-space context-switch required - but largely independent of usage), G > > is what makes per-process buffering obsolete (and very tight systemt memoryL > > constraints, as was true back when VMS was designed, made the ability toB > > swap buffers along with their associated processes desirable). >tH > The prices of system and memory is about the same now as ever. PerhapsE > about a 2:1 difference. The price of both have dropped like a rock,m( > and the performance has shot sky high. >mC > The big change is that we have gone back to the core days problemsH > of huge latency to memory in cpu clocks. Ironically, adding to this byI > shoving data around in caches and buffers is the last thing you want to  > do.   H Incorrect.  It might be the *next-to-last* thing you want to do, but theL *last* thing you want to do is create a need for more disk accesses, becauseI the relative speed of disk access has lagged even farther behind than the " relative speed of memory accesses.  K A few years ago Jim Gray added to his original '5-minute rule' (an InternetrI search should turn up the newer paper, likely somewhere on microsoft.com,rL since that's where he is these days) some estimates of the relative value ofL avoiding disk accesses in terms of instructions executed that bears directlyK on this issue (unless, of course, your system is CPU- or memory-bound - but J most of the applications relevant to the discussion in this thread clearly aren't).   - bill   >l > --> > Paul Repacholi                               1 Crescent Rd.,9 > +61 (08) 9257-1001                           Kalamunda.VB >                                              West Australia 60760 > Raw, Cooked or Well-done, it's all half baked.   ------------------------------   End of INFO-VAX 2001.194 ************************