0 INFO-VAX	Fri, 09 Feb 2001	Volume 2001 : Issue 79      Contents: Re: "Future VMS Site" in PA B Re: 64 bit systems with small memory, was: Higher sized memory forB Re: Alpha loses major third party vendor - Another Compaq mistake? Re: Another missed opportunity Re: Another missed opportunity Re: Another missed opportunity Re: Another missed opportunity Re: Another missed opportunity Re: Another missed opportunity Re: Another missed opportunity Re: apache CGI problem AUTOGEN disabling of GENFILES ! Re: AUTOGEN disabling of GENFILES ! Re: AUTOGEN disabling of GENFILES ! Re: AUTOGEN disabling of GENFILES ! Re: AUTOGEN disabling of GENFILES + Re: CDE or the MOTIF desktop - preferences? + Re: CDE or the MOTIF desktop - preferences? * Re: Changing LA600 from serial to parallel" Re: Compaq and Ally McBeal servers0 Re: Compaq presentation in Montreal. Feb 6, 20010 RE: Compaq presentation in Montreal. Feb 6, 20010 Re: Compaq presentation in Montreal. Feb 6, 2001; Re: Employment opportunity at SLAC (and "So long!" for now)  Re: EV68 833MHz / File Not Found with Pre Expired password logins 3 Re: Firmware upgrade for PWS 600au to use a ZLXp-L1 3 Re: Firmware upgrade for PWS 600au to use a ZLXp-L1 3 Re: Firmware upgrade for PWS 600au to use a ZLXp-L1  FORCING 8BIT COLOR IN DCE? Re: FORCING 8BIT COLOR IN DCE? Re: FTP Needed Re: FTP Needed Re: FTP Needed Re: FTP Needed Re: FTP Needed Re: FTP Needed Re: FTP Needed Re: FTP Needed0 Re: Installing NT 4.0 on a DEC 3000 Alpha Server/ Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours  Re: Lisbon Conference  MIME$MAILCAP.DAT format? Re: MIME$MAILCAP.DAT format? Re: MIME$MAILCAP.DAT format? Re: MMS/MMK Ghostscript problem 
 Northernlight  Re: Northernlight  Re: Northernlight  Re: Northernlight > Not being published: OpenVMS Performance Management book ed 2.B Re: Not being published: OpenVMS Performance Management book ed 2.B Re: Not being published: OpenVMS Performance Management book ed 2.* Re: OpenVMS Alpha 1200 5/533 login problem phone in cluster7 Porting Applications fromVMS to Windows with ISAM files  POSIX 1003.1 & 1003.2 1 PreExpired password accounts get "File Not Found" 1 PreExpired password accounts get "File Not Found"  Question on time comparison.... # Re: Question on time comparison....  Re: set character set? Re: set character set? Re: Status of EV7  Re: Status of EV7  Re: Status of EV7  Re: Status of EV7  Re: Status of EV7  Re: Status of EV7  Re: Status of EV7  Re: Status of EV7  Re: Status of EV7 % Re: Suggested upgrade to VMS (DECnet) " Re: The "deleting many files" myth" Re: The "deleting many files" myth" Re: The "deleting many files" myth" Re: The "deleting many files" myth" Re: The "deleting many files" myth" Re: The "deleting many files" myth" Re: The "deleting many files" myth" Re: The "deleting many files" myth" Re: The "deleting many files" myth" Re: The "deleting many files" myth" Re: The "deleting many files" myth" Re: The "deleting many files" myth" Re: The "deleting many files" myth Re: Try this on Linux or NT/ME Re: Try this on Linux or NT/ME! Re: typo in TCP/IP management doc  USAGE.DAT and missing files  Re: USAGE.DAT and missing files  Re: USAGE.DAT and missing files 9 Re: VAX/VMS 7.2 BACKUP/IMAGE behavior when a file is open ) Re: VMS 7.2-1 Bugcheck In DECW$REINIT.EXE 9 Re: Vote Early and Often... Give up your Browser Security ) Re: what version of VMS are people using? B Re: XML Technology for OpenVMS Alpha now available in C++ and Java  F ----------------------------------------------------------------------   Date: 8 Feb 2001 20:00:49 GMT 1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) $ Subject: Re: "Future VMS Site" in PA, Message-ID: <95utth$1dni$1@info.cs.uofs.edu>  3 In article <j4algm00uukL@eisner.encompasserve.org>, 7  koehler@eisner.encompasserve.org (Bob Koehler) writes: r |> In article <B583VX0srq5I@eisner.encompasserve.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:I |> > Thank you Bill.  My birthday party trip to Scranton is now complete.  |>   |> You hit Steamtown?   > Steamtown!!  that's just another Federal Government boondogle.= You gotta go on the Coal Mine Tour.  Now that's calssic NEPA.   < If you want to ride a train, you take The Stourbridge Lion!!   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  # Date: Thu, 08 Feb 2001 20:37:44 GMT  From: Dirk Munk <munk@home.nl>K Subject: Re: 64 bit systems with small memory, was: Higher sized memory for ' Message-ID: <3A830352.7211373C@home.nl>   & --------------6090A6B5118CDEE156F7A608* Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit   
 Hi Rudolf,  P You can put 4 GB in a DS20.  Camintonn has suitable dimms in their program. ThisP company used to be a Compaq approved supplier untill Compaq changed their policy for business reasons.   9 You will find the DS20 under the brand name Digital -:)).   P We have ES40's equiped with 1 GB dimms from Camintonn. They use IBM memory chipsB on those dimms, and I suppose we can trust IBM to make good chips.   Regards,   Dirk   Rudolf Wingert wrote:    > Hello, > L > we do have the 2GB problem. That's the max. size of physical memory a userK > gets. But for the image understanding programs we need more then the 2GB. I > For the ES40 there are 1GB DIMMS, but this machine is to expensive. For O > the DS20 the actual max. size is 256MB DIMMs. Why did Compaq not use standard I > DIMMs? The DIMMs within the DS20 do have more pins then the standard PC J > DIMMS PC100. Also do the ES40 memory have 200Mhz and the DS20 100Mhz, soK > that we can't use the ES40 memory within the DS20 (I did try that). Or is  > in DS20 a max. size limit? >  > Regards Rudolf Wingert  & --------------6090A6B5118CDEE156F7A608) Content-Type: text/html; charset=us-ascii  Content-Transfer-Encoding: 7bit   > <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html>
 Hi Rudolf,V <p>You can put 4 GB in a DS20.&nbsp; <a href="http://www.camintonn.com/">Camintonn</a>N has suitable dimms in their program. This company used to be a Compaq approvedA supplier untill Compaq changed their policy for business reasons. < <p>You will find the DS20 under the brand name Digital -:)).F <p>We have ES40's equiped with 1 GB dimms from Camintonn. They use IBMH memory chips on those dimms, and I suppose we can trust IBM to make good chips. <p>Regards,  <p>Dirk  <p>Rudolf Wingert wrote: <blockquote TYPE=CITE>Hello,F <p>we do have the 2GB problem. That's the max. size of physical memory a userH <br>gets. But for the image understanding programs we need more then the 2GB.G <br>For the ES40 there are 1GB DIMMS, but this machine is to expensive.  For H <br>the DS20 the actual max. size is 256MB DIMMs. Why did Compaq not use standardH <br>DIMMs? The DIMMs within the DS20 do have more pins then the standard PCI <br>DIMMS PC100. Also do the ES40 memory have 200Mhz and the DS20 100Mhz,  soG <br>that we can't use the ES40 memory within the DS20 (I did try that).  Or is  <br>in DS20 a max. size limit?& <p>Regards Rudolf Wingert</blockquote> </html>   ( --------------6090A6B5118CDEE156F7A608--   ------------------------------   Date: 8 Feb 2001 11:39:56 -0700 1 From: nothome@spammers.are.scum (Malcolm Dunnett) K Subject: Re: Alpha loses major third party vendor - Another Compaq mistake? , Message-ID: <lKNkV4KluiWu@malvm1.mala.bc.ca>  * In article <95uhho$u7u$1@nnrp1.deja.com>, +     Alan Greig <agreig@my-deja.com> writes:  > H > Yeh, I suspect the same. I met some of the NetApp hardware designers aH > couple of years ago and some were ex DEC. The original NetApp even hadC > StorageWorks disks and shelves. They said two years ago they were D > talking to Compaq about Compaq selling a rebadged version. InsteadD > Compaq chose to sell a 'turn-key' W2K box (TaskSmart) as their NASC > solution. Btw, even the lowest end current NetApp box (720) has a G > higher throughput than the NT based Compaq TaskSmart. Compaq describe I > the TaskSmart as having the highest throughput of any NAS server *using . > industry standard components* (my starring). > @     That's truly sad ( that CPQ would use such a deceptive ad to< make a misleading claim against a product based on their own processor ).  >     Perhaps the NetApp folks are switching to Intel processors- so that Compaq can no longer make this claim.    ------------------------------  # Date: Thu, 08 Feb 2001 20:18:49 GMT ; From: Mark Garrett <Mark.Garrett@wedontwantyourspam.com.au> ' Subject: Re: Another missed opportunity C Message-ID: <B6A9478E.11A7F%Mark.Garrett@wedontwantyourspam.com.au>   J in article y4wvb1qymh.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de, JanG Vorbrueggen at jan@mailhost.neuroinformatik.ruhr-uni-bochum.de wrote on  08/02/2001 21:04:   + > "Bill Todd" <billtodd@foo.mv.com> writes:  > O >> Not being a Unix guru, this comes as a surprise to me.  VMS, like RSX before N >> it, has always had system/owner/group/world protection, which I thought wasO >> very similar to Unix's owner/group/world (?) mechanism (save for the lack of A >> a 'system' category).  Perhaps you could expand on this point.  > L > He can only think in implementation, not architecture, that's his problem. > I > The difference is that in Unix, you can be a member of multiple groups, G > although the number of these is usually limited (to something like 15 H > in Solaris, which turns into a real nuisance). Thus, you can use groupH > membership like a primitive ACL: a file that has a group protection ofG > "rx", say, and is owned by group "muddlehead" has the equivalent of a H > VMS ACE of "Identifier=[muddlehead], Access=[r+x]" (sorry if I get theM > syntax wrong). The limitations are obvious: Each file can have only exactly K > one such pseudo-ACE, order is irrelevant, and some others coming from the M > limitations of the group system as such. It's really only a crutch that can K > barely be made to work (and I speak from experience here) until ACLs came J > along. Of course, the problem with ACLs was that they were late, initialK > support was quite incomplete and buggy (especially in the area of editing M > ACLs - VMS has had this problem also, 15 years ago), NFS doesn't sit easily  > with it, and so on.   E     A point that goes missing with a lot of people also is that group K permission on UNIX maybe used to deny, access even though other (aka World) 
 grant it. eg.   : -rwx---rwx   1 root     gcs            0 Feb  9 07:02 fred  E     In this case every one except members of group gcs have access to L Read/Write/eXecute fred ( remember delete access comes from you having write  access to the parent directory )    
     Cheers         Mark :)    ------------------------------  % Date: Thu, 08 Feb 2001 23:56:01 +0000 ) From: Christof Brass <brass@infopuls.com> ' Subject: Re: Another missed opportunity , Message-ID: <3A833211.2F580967@infopuls.com>   Jan Vorbrueggen wrote: > + > "Bill Todd" <billtodd@foo.mv.com> writes:  > P > > Not being a Unix guru, this comes as a surprise to me.  VMS, like RSX beforeO > > it, has always had system/owner/group/world protection, which I thought was P > > very similar to Unix's owner/group/world (?) mechanism (save for the lack ofB > > a 'system' category).  Perhaps you could expand on this point. > L > He can only think in implementation, not architecture, that's his problem. > I > The difference is that in Unix, you can be a member of multiple groups, G > although the number of these is usually limited (to something like 15 H > in Solaris, which turns into a real nuisance). Thus, you can use groupH > membership like a primitive ACL: a file that has a group protection ofG > "rx", say, and is owned by group "muddlehead" has the equivalent of a H > VMS ACE of "Identifier=[muddlehead], Access=[r+x]" (sorry if I get theM > syntax wrong). The limitations are obvious: Each file can have only exactly K > one such pseudo-ACE, order is irrelevant, and some others coming from the M > limitations of the group system as such. It's really only a crutch that can K > barely be made to work (and I speak from experience here) until ACLs came J > along. Of course, the problem with ACLs was that they were late, initialK > support was quite incomplete and buggy (especially in the area of editing M > ACLs - VMS has had this problem also, 15 years ago), NFS doesn't sit easily  > with it, and so on.  > 
 >         Jan   5 Thanks, you made my day. Although I have some lack of ; understanding UNIX (if such as "understanding UNIX" is ever > possible for me) I wrote exactly that in a previous message to< this thread. I only didn't know and therefore didn't mention> that there might be a limit of the number of groups a user can
 be member of.    ------------------------------  % Date: Thu, 08 Feb 2001 23:58:02 +0000 ) From: Christof Brass <brass@infopuls.com> ' Subject: Re: Another missed opportunity , Message-ID: <3A83328A.B5DA80F7@infopuls.com>  @ Is there a limit on the number of ACEs in VMS for a user (rights identifiers) or a file?    ------------------------------  % Date: Fri, 09 Feb 2001 00:01:51 +0000 ) From: Christof Brass <brass@infopuls.com> ' Subject: Re: Another missed opportunity , Message-ID: <3A83336F.7D86B29E@infopuls.com>   Mark Garrett wrote:  > L > in article y4wvb1qymh.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de, JanI > Vorbrueggen at jan@mailhost.neuroinformatik.ruhr-uni-bochum.de wrote on  > 08/02/2001 21:04:  > - > > "Bill Todd" <billtodd@foo.mv.com> writes:  > > Q > >> Not being a Unix guru, this comes as a surprise to me.  VMS, like RSX before P > >> it, has always had system/owner/group/world protection, which I thought wasQ > >> very similar to Unix's owner/group/world (?) mechanism (save for the lack of C > >> a 'system' category).  Perhaps you could expand on this point.  > > N > > He can only think in implementation, not architecture, that's his problem. > > K > > The difference is that in Unix, you can be a member of multiple groups, I > > although the number of these is usually limited (to something like 15 J > > in Solaris, which turns into a real nuisance). Thus, you can use groupJ > > membership like a primitive ACL: a file that has a group protection ofI > > "rx", say, and is owned by group "muddlehead" has the equivalent of a J > > VMS ACE of "Identifier=[muddlehead], Access=[r+x]" (sorry if I get theO > > syntax wrong). The limitations are obvious: Each file can have only exactly M > > one such pseudo-ACE, order is irrelevant, and some others coming from the O > > limitations of the group system as such. It's really only a crutch that can M > > barely be made to work (and I speak from experience here) until ACLs came L > > along. Of course, the problem with ACLs was that they were late, initialM > > support was quite incomplete and buggy (especially in the area of editing O > > ACLs - VMS has had this problem also, 15 years ago), NFS doesn't sit easily  > > with it, and so on.  > G >     A point that goes missing with a lot of people also is that group M > permission on UNIX maybe used to deny, access even though other (aka World)  > grant it. eg.  > < > -rwx---rwx   1 root     gcs            0 Feb  9 07:02 fred > G >     In this case every one except members of group gcs have access to N > Read/Write/eXecute fred ( remember delete access comes from you having write" > access to the parent directory ) >  >     Cheers >         Mark :)   ? I encountered exactly that problem a few day ago and thought it > was an artifact of Linux because I couldn't believe that it is really that sick. > OTH this could be changed without changing the persistent file> data by changing the rule in interpreting the permissions from7 top to bottom and not allowing that a more narrow levele< restricts a more general level, i.e. permissions "other" has= cannot be taken away, permissions "group" has cannot be takent away by "owner".@ Does anybody know a situation where the UNIX way in interpreting$ these permission levels makes sense?   ------------------------------   Date: 8 Feb 2001 19:26:37 -0500n9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)O' Subject: Re: Another missed opportunityi3 Message-ID: <4ZDnl72bvEii@eisner.encompasserve.org>E  X In article <3A83328A.B5DA80F7@infopuls.com>, Christof Brass <brass@infopuls.com> writes:B > Is there a limit on the number of ACEs in VMS for a user (rights > identifiers) or a file?p  @ The amount of CPU time you want to spend processing such things.! Especially for long Rights Lists.e   ------------------------------  $ Date: Thu, 8 Feb 2001 19:53:53 -0500' From: "Bill Todd" <billtodd@foo.mv.com>i' Subject: Re: Another missed opportunityg( Message-ID: <95vept$kqt$1@pyrite.mv.net>  4 Christof Brass <brass@infopuls.com> wrote in message& news:3A83336F.7D86B29E@infopuls.com... > Mark Garrett wrote:p   ...O  I > >     A point that goes missing with a lot of people also is that group H > > permission on UNIX maybe used to deny, access even though other (aka World) > > grant it. eg.e > > > > > -rwx---rwx   1 root     gcs            0 Feb  9 07:02 fred > >rI > >     In this case every one except members of group gcs have access torJ > > Read/Write/eXecute fred ( remember delete access comes from you having writeo$ > > access to the parent directory ) > >S > >     Cheers > >         Mark :)e >dA > I encountered exactly that problem a few day ago and thought itr@ > was an artifact of Linux because I couldn't believe that it is > really that sick.V@ > OTH this could be changed without changing the persistent file@ > data by changing the rule in interpreting the permissions from9 > top to bottom and not allowing that a more narrow levelC> > restricts a more general level, i.e. permissions "other" has? > cannot be taken away, permissions "group" has cannot be takeni > away by "owner".B > Does anybody know a situation where the UNIX way in interpreting& > these permission levels makes sense?  I While it's been far too long since I even read about VMS ACEs to be sure,nH don't they also allow specific restrictions on more general permissions?   - bill   ------------------------------   Date: 8 Feb 2001 21:54 CST' From: carl@gerg.tamu.edu (Carl Perkins)n' Subject: Re: Another missed opportunityw, Message-ID: <8FEB200121544029@gerg.tamu.edu>  = Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes... Y }In article <3A83328A.B5DA80F7@infopuls.com>, Christof Brass <brass@infopuls.com> writes:tC }> Is there a limit on the number of ACEs in VMS for a user (rights  }> identifiers) or a file? } A }The amount of CPU time you want to spend processing such things. " }Especially for long Rights Lists.  K Memory and disk space are also finite, which gives additional upper limits.h   --- Carl   ------------------------------  # Date: Thu, 08 Feb 2001 23:40:39 GMTa2 From: "Gaitan D'Antoni" <gaitan_dantoni@yahoo.com> Subject: Re: apache CGI problemh8 Message-ID: <X7Gg6.485$z5.74185@news1.news.adelphia.net>  J What you have discovered is a limitation of the current CGI implementationF on OpenVMS. However, as Martin pointed out, CGI parameters are usuallyL retrieved via environment variables, not through command line arguments. The5 OpenVMS CSWS documentation includes a section on CGI.e   Gaitan D'Antonin. Apache Web Server for OpenVMS Technical LeaderC http://www.openvms.compaq.com/openvms/products/ips/apache/csws.htmlX Compaq Computer Corporation.    5 "Matthias Koch" <koch@weblab-edv.de> wrote in messager' news:3A816A4D.388204C5@weblab-edv.de...O > Hi!A >aF > While porting a Linux application to VMS, I experienced an irregular+ > behaviour with CSWS-V0100-1-1 using CGIs.e >05 > This litte test program just returns its arguments:  >s > #include <stdio.h> >u  > main(int argc, char *argv[]) { >u' > printf("Content-type: text/plain\n");e > printf("\n");s" > printf("Arguments: %d\n", argc);# > printf("Command: %s\n", argv[0]); & > printf("Argument 1: %s\n", argv[1]);& > printf("Argument 2: %s\n", argv[2]);
 > return (0);p > }a >  >gJ > On the command line under VMS as well as from Apache running under Linux > it reacts like expected: >t
 > $ test 2 > Content-type: text/plain >o > Arguments: 2
 > Command:C > fermat$dka100:[000000.apache.specific.fermat.][cgi-bin]test.exe;1  > Argument 1: 2o > Argument 2: (null) >h >t >bB > But called from Apache under VMS, it gives back wrong arguments: >() > http://www.weblab-edv.de/cgi-bin/test?2c >t > Arguments: 3
 > Command:C > fermat$dka100:[000000.apache.specific.fermat.][cgi-bin]test.exe;1n > Argument 1: test > Argument 2: 2s >i >.@ > This means, that CGIs do not work correctly. Is this an ApacheJ > configuration problem or do I have to change the sourcecode of the CGIs? >h > Bye,
 > Matthias   ------------------------------  % Date: Thu, 08 Feb 2001 15:01:03 -0500-- From: JF Mezei <jfmezei.spamnot@videotron.ca> & Subject: AUTOGEN disabling of GENFILES+ Message-ID: <3A82FAFD.8921039@videotron.ca>a  M On one of my systems I have 2 pagefiles and a swapfile. I have made them big.n  J However, whenever I run autogen to incorporate changed parameters (such asT changing Channelcnt), autogen insists on adjusting or recreating the page/swapfiles.  F What can I put in MODPARAMS.DAT to tell it not to touch these files ?   H Short of editing autogen.com to force it to skip over genfiles, is there2 another way to get it to skip the genfiles phase ?   ------------------------------   Date: 8 Feb 2001 15:06:06 -0500c2 From: young_r@eisner.encompasserve.org (Rob Young)* Subject: Re: AUTOGEN disabling of GENFILES3 Message-ID: <607E7jb6LGr$@eisner.encompasserve.org>i  [ In article <3A82FAFD.8921039@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes:aO > On one of my systems I have 2 pagefiles and a swapfile. I have made them big.  > L > However, whenever I run autogen to incorporate changed parameters (such asV > changing Channelcnt), autogen insists on adjusting or recreating the page/swapfiles. > H > What can I put in MODPARAMS.DAT to tell it not to touch these files ?  >    [cut and paste]   > Once you have set up your new page and swap files, you may not? want AUTOGEN to adjust them.  If so, add the following lines toh MODPARAMS.DAT in SYS$SYSTEM:        PAGEFILE = 0s      SWAPFILE = 0w   			Rob   ------------------------------   Date: 8 Feb 2001 15:47:38 -0500p3 From: maulis@eisner.encompasserve.org (Adam Maulis)p* Subject: Re: AUTOGEN disabling of GENFILES3 Message-ID: <h$srV1K0Ax0A@eisner.encompasserve.org>g  h In article <607E7jb6LGr$@eisner.encompasserve.org>, young_r@eisner.encompasserve.org (Rob Young) writes: > ] > In article <3A82FAFD.8921039@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: P >> On one of my systems I have 2 pagefiles and a swapfile. I have made them big. >> zM >> However, whenever I run autogen to incorporate changed parameters (such assW >> changing Channelcnt), autogen insists on adjusting or recreating the page/swapfiles.o >> nI >> What can I put in MODPARAMS.DAT to tell it not to touch these files ? p >> t >  > [cut and paste]M > @ > Once you have set up your new page and swap files, you may notA > want AUTOGEN to adjust them.  If so, add the following lines to0 > MODPARAMS.DAT in SYS$SYSTEM: >  >      PAGEFILE = 0t >      SWAPFILE = 0a   andr
 	DUMPFILE = 02& 	ERRORLOGDUMP = 0	! Alpha only. v7.x??   >  > 			Rob >      Regards, Adam Maulis-   ------------------------------  % Date: Thu, 08 Feb 2001 16:20:21 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>e* Subject: Re: AUTOGEN disabling of GENFILES, Message-ID: <3A830D8E.9E193F82@videotron.ca>   Adam Maulis wrote: > >      PAGEFILE = 01 > >      SWAPFILE = 0c   thanks   ------------------------------  # Date: Thu, 08 Feb 2001 21:38:53 GMT 1 From: "Mark D. Jilson" <jilly@clarityconnect.com>p* Subject: Re: AUTOGEN disabling of GENFILES2 Message-ID: <3A8312AE.63064CE3@clarityconnect.com>  B I always advocate running AUTOGEN in a 2 pass method and avoid the GENFILES phase.m  ' @SYS$UPDATE:AUTOGEN SAVPARAMS TESTFILES.' @SYS$UPDATE:AUTOGEN SETPARAMS SETPARAMSk  E After the 1st pass review AGEN$PARAMS.REPORT and SETPARAMS.DAT and ifd= you don't like something then edit MODPARAMS.DAT and execute N% @SYS$UPDATE:AUTOGEN GETDATA TESTFILESb3 Once things look right execute the 2nd pass commando   JF Mezei wrote:s > O > On one of my systems I have 2 pagefiles and a swapfile. I have made them big.  > L > However, whenever I run autogen to incorporate changed parameters (such asV > changing Channelcnt), autogen insists on adjusting or recreating the page/swapfiles. > G > What can I put in MODPARAMS.DAT to tell it not to touch these files ?- > J > Short of editing autogen.com to force it to skip over genfiles, is there4 > another way to get it to skip the genfiles phase ?   -- eD Jilly	- Working from Home in the Chemung River Valley - Lockwood, NY0 	- jilly@clarityconnect.com			- Brett Bodine fan. 	- Mark.Jilson@Compaq.com			- since 1975 or so, 	- http://www.jilly.baka.com               -   ------------------------------  % Date: Thu, 08 Feb 2001 11:04:20 -0800v! From: Shane.F.Smith@Healthnet.comU4 Subject: Re: CDE or the MOTIF desktop - preferences?D Message-ID: <OFC4E78DFD.65C0F6D4-ON882569ED.0068A4F3@foundation.com>  I I gave up on CDE after many months of trying to use it. Basically, I keptsE running into bits that hadn't been properly taught about the VMS filexA system, particularly version numbers. I use the old Motif versiont everywhere now.a   Shaner          A djweath@attglobal.net (Dave Weatherall) on 02/07/2001 11:12:06 PM    To:   Info-VAX@Mvb.Saic.Com  cc:e  1 Subject:  CDE or the MOTIF desktop - preferences?l    @ On Wed, 7 Feb 2001 21:52:10, Christof Brass <brass@infopuls.com> wrote:  ? > I don't use CDE. I don't want to have redraw problems and the"A > like. If the colour palettes are huge and the operation is fast  > I'm fine."  B Actually, I still prefer the 'old' Windows Session Manager. MainlyF because I'm used to it . However, I still prefer the simplicity of theE Session Manager pane at the top left to the CDE graphic choice panel.hC The only real advantage I see for CDE is the multiple desktops. ButtF then again I'm english, computing's mother tongue, so english-languageC text menus are no problem to me. How does the rest of the group seet it?    -- Cheers - Dave.   ------------------------------  % Date: Fri, 09 Feb 2001 01:07:22 +0000 ) From: Christof Brass <brass@infopuls.com>y4 Subject: Re: CDE or the MOTIF desktop - preferences?, Message-ID: <3A8342CA.56B08BBC@infopuls.com>   Dave Weatherall wrote: > B > On Wed, 7 Feb 2001 21:52:10, Christof Brass <brass@infopuls.com> > wrote: > A > > I don't use CDE. I don't want to have redraw problems and the7C > > like. If the colour palettes are huge and the operation is fastv
 > > I'm fine.e > D > Actually, I still prefer the 'old' Windows Session Manager. MainlyH > because I'm used to it . However, I still prefer the simplicity of theG > Session Manager pane at the top left to the CDE graphic choice panel.rE > The only real advantage I see for CDE is the multiple desktops. ButpH > then again I'm english, computing's mother tongue, so english-languageE > text menus are no problem to me. How does the rest of the group see  > it?  >  > -- > Cheers - Dave.  @ I think everybody will know what the menus denote after a little= trial and error even if the text were Chinese. At home I onlym< use the DECwindow manager and I'm going to attach three more9 screens to my Alpha box which I prefer over switching the > desktops with CDE what I use at work. I like four real screens more than four virtual screens.    ------------------------------  # Date: Fri, 09 Feb 2001 01:03:58 GMTu$ From: Scott Vieth <svieth@wi.rr.com>3 Subject: Re: Changing LA600 from serial to parallels( Message-ID: <3A834273.6010405@wi.rr.com>  E The menu on the printer was locked-out.  We had to figure out how to g	 unlock itt8 and then we were able to change from serial to parallel.   Thanks,a  
 -Scott :^)   Paul Anderson wrote:  G > In article <95n90u$lhm$1@nnrp1.deja.com>, scottv67@my-deja.com wrote:t > E >> Can anyone tell me how to switch an LA600 from serial to parallel?o >  > H > You can run the LA600 in PARALLEL, SERIAL or SHARED modes.  In SHARED C > mode, both parallel and serial ports are active at the same time.t > E > This setting is under the INSTALLATION | INTERFACE | I/F TYPE menu.r >  > Paul >    ------------------------------  % Date: Thu, 08 Feb 2001 20:31:16 -0600a% From: Keith Brown <kbrown780@isd.net>t+ Subject: Re: Compaq and Ally McBeal servers ' Message-ID: <3A835674.5F4977FB@isd.net>    Bill Todd wrote: > 2 > Keith Brown <kbrown780@isd.net> wrote in message# > news:3A8099F3.2A676759@isd.net... . > > fabio_compaq@ep-bc.petrobras.com.br wrote: > > >e > > > Click at > > >yA > > > http://news.cnet.com/news/0-1003-200-4720537.html?tag=cd_mh  > > >r1 > > > I would like a Juliete Binoche server ! :-)e > > > 
 > > > Regardsr > > >e > > > FC > > K > > I suppose that if you have lots of Intel systems (they seem to multiplymJ > > like hamsters at my place) then it helps if they are small. Or I guess2 > > you could run 2 or 3 Alphaservers instead  :-) > M > Which is the better approach depends on what you're doing.  For example, if I > the servers are simply providing modestly intelligent access to storage5K > (i.e., acting like a storage farm with enough smarts to handle some localsL > application-level processing, such as serving up static Web pages), then aN > lot of cheap servers stuffed to the gills with IDE disks (and mirroring eachM > other at the server level, making the server the modular, replaceable unit)oK > and tied together with inexpensive switched Fast Ethernet is hard to beatsJ > for cost-effectiveness.  That's what Google uses, quite effectively (RobK > Young will now explain that Google is behind the current California power,N > crisis, which is interesting but of questionable relevance:  our society hasG > a long and illustrious history of ignoring the real costs of anythingx# > whenever it's possible to do so).n > E > But that still leaves the question of what application requires the M > greater-than-1U server density that the new thin (how thin?) servers offer. K > Anything density-sensitive obviously uses a hell of a lot of servers, and K > given that people are packing 4 or so disks into 1U servers these days iteL > seems likely that whatever the application is is not using thinner serversL > to increase its *storage* density (since they would likely have difficultyB > holding the same number of drives).  And Beowulf clusters, whileK > interesting, seldom command the kind of volume purchasing that would spur  > Compaq to such 'innovation'. > K > My guess is that it's akin to the fruity colors Macs come in:  thin is ins; > (at least for servers), whether it adds any value or not.b >  > - bill >  > >p > > -- > > Keith Brown  > > kbrown780@isd.netl  A Your point is well taken, however my comment was simply that morelG computers generally take more space and use more electricity. Note thatdF I'm not suggesting that we design systems based only on how much space= and power they consume but it becomes an issue at some point.h   --   Keith Browna kbrown780@isd.net    ------------------------------  % Date: Thu, 08 Feb 2001 14:41:39 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>x9 Subject: Re: Compaq presentation in Montreal. Feb 6, 2001 , Message-ID: <3A82F672.5A78DA91@videotron.ca>   Bob Koehler wrote: > > OpenVMS 7.3 release ". > 1 > So how come I never heard of this announcement?e  I In all fairness to Compaq, the announcement of 7.3 actually went out as a K Compaq PR news release to the world, and quite a few media picked up on it.fM There were a few articles that not only was VMS not dead yet, but that Compaqs; was coming out with a major release with many new features.b  I By the way, in the presentation Marcello said that in initial tests, someo; customers experienced a 20% performance improvement for 7.3l  L The problem with the announcementy is that its value was lost because CompaqM then reverted to its own "ignore VMS" self. VMS needs constant exposure for a ( long period to get some mindshare again.   ------------------------------  % Date: Thu, 08 Feb 2001 14:01:21 -06001+ From: "Main, Kerry" <Kerry.Main@compaq.com>o9 Subject: RE: Compaq presentation in Montreal. Feb 6, 2001pN Message-ID: <910612C07BCAD1119AF40000F86AF0D805284D86@kaoexc3.kao.cpqcorp.net>  K >>> In all fairness to Compaq, the announcement of 7.3 actually went out as ( a Compaq PR news release to the world <<  2 As a fyi, here are the url's to that announcement:H <http://www.compaq.com/newsroom/pr/2000/pr2000100301.html> (OpenVMS only press release)A <http://www.openvms.compaq.com/ebusiness_without_compromise.html>0   Regards,  
 Kerry Main Senior Consultant@ Compaq Canada Inc. Professional Servicesp Voice: 613-592-4660D Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----4 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca] Sent: February 8, 2001 2:42 PM To: Info-VAX@Mvb.Saic.Comi9 Subject: Re: Compaq presentation in Montreal. Feb 6, 2001N     Bob Koehler wrote: > > OpenVMS 7.3 release ". > 1 > So how come I never heard of this announcement?r  I In all fairness to Compaq, the announcement of 7.3 actually went out as aoK Compaq PR news release to the world, and quite a few media picked up on it. F There were a few articles that not only was VMS not dead yet, but that Compaq; was coming out with a major release with many new features.   I By the way, in the presentation Marcello said that in initial tests, somet; customers experienced a 20% performance improvement for 7.3y  L The problem with the announcementy is that its value was lost because CompaqK then reverted to its own "ignore VMS" self. VMS needs constant exposure fort a ( long period to get some mindshare again.   ------------------------------  $ Date: Thu, 8 Feb 2001 15:39:38 -0500& From: "Syltrem" <syltrem@videotron.ca>9 Subject: Re: Compaq presentation in Montreal. Feb 6, 2001 6 Message-ID: <kqDg6.1145$bw1.11773@weber.videotron.net>  G "JF Mezei" <jfmezei.spamnot@videotron.ca> a crit dans le message news:e! 3A81C9DC.95F99FB0@videotron.ca...' > Syltrem wrote: > >fF > > Yesterday January 6, we had a Compaq presentation in Montreal, for OpenVMS- > > and Tru64 customers. >:< > Ahh, were you the other who asked a question to Marcello ?  F Could be. I said there always are 4 full-pages ads in Oracle MagaziineJ promoting Compaq Unix stuff, and no mention of OpenVMS. Sent a copy of theJ pages to Qubec director of marketing yesterday. If they want to publish 4L pages, and there is at least one for OpenVMS and one for Tru64 and I wouln'tG mind. Just so that they tell the world they have more than one Non Stop ; solution. Right now they advertise they Wintel boxes (sic).    >o* > > New TCP IP services will support IPV6. >aL > I didn't catch that one. The Unix presentation spent a lot of time on this7 > issue, but i did not recall Marcello announcing this.   K Possible. I remember it was a subject in the Unix presentation, but I noted6I this as part of my VMS notes... and I can't be 100% sure Marcello said iti (but I think he did).G     --   Sytrem  http://pages.infinit.net/syltrem   ------------------------------   Date: 8 Feb 2001 15:23:08 PSTiT From: Fairfield@SLAC.Stanford.EDU (Ken Fairfield; SLAC: 650-926-2924; FAX: 926-3515)D Subject: Re: Employment opportunity at SLAC (and "So long!" for now)3 Message-ID: <05NLc$m71wPk@mccdev.slac.stanford.edu>/  D In article <paul.r.anderson-9DA2E4.12135306022001@news.compaq.com>, 6     Paul Anderson <paul.r.anderson@compaq.com> writes:  5 > Does this mean you won't be using OpenVMS at work? o  B         No.  It _is_ an OpenVMS position.  How could I possibly do     anything else?  :-)s  H >                                                     In any case, Ken, K > good luck with the move and new job.  Now to whom will I refer all those t9 > people who want to munge DCPS to work with HP printers?u  H         How about Paul Anderson? :-)  Besides, you've promised that V1.9H     will solve all the  outstanding  problems  with HP printers, haven'tH     you?   :-)  :-)  Well,  at least it looks like  you'll  support  theH     currently-unsupported  HP's  we're  using  at   SLAC...    For   newH     upsupported  printers,  people  will just need to use deja and applyH     the general methodology rather  than  looking  for a specific extant
     solution.h           -Ken -- dM  Kenneth H. Fairfield            |  Internet: Fairfield@SLC.Slac.Stanford.Edu-:  SLAC, 2575 Sand Hill Rd, MS 46  |  Voice:    650-926-2924:  Menlo Park, CA  94025           |  FAX:      650-926-3515N  -----------------------------------------------------------------------------B  These opinions are mine, not SLAC's, Stanford's, nor the DOE's...   ------------------------------  # Date: Thu, 08 Feb 2001 22:15:34 GMT-L From: =?iso-8859-1?Q?Andr=E9?= Bastien <bastien.andre.p@hydro-no-spam.qc.ca> Subject: Re: EV68 833MHz3 Message-ID: <3A831B41.1F18BA99@hydro-no-spam.qc.ca>S  ) There are some numbers at the SPEC site :a  ;    http://open.specbench.org/osg/cpu2000/results/res2000q4/a  G Roughly it should give +25% performance gain for the same 25 % increasedE on Mhz for SPEC INT rate.  But it gives only +17% on SPECFP rate.   (g Both with one CPU )g  " ----------------------------------  < Company Name     System Name             #CPU    Base   Peak   CINT2000  ; Compaq    AlphaServer ES40 Model 6/500   1       299    311o; Compaq    AlphaServer ES40 Model 6/833   1       518    544-; Compaq    AlphaServer GS80 Model 6/731   1       352    397i   CFP2000a  ; Compaq    AlphaServer ES40 Model 6/500   1      382     419L; Compaq    AlphaServer ES40 Model 6/833   1      590     658n; Compaq    AlphaServer GS80 Model 6/731   1      405     444p     CINT2000 Rates  < Compaq    AlphaServer ES40 Model 6/667   1      4.82    5.05; Compaq    AlphaServer ES40 Model 6/667   2      9.74   10.3o; Compaq    AlphaServer ES40 Model 6/667   4     18.4    19.8a  < Compaq    AlphaServer ES40 Model 6/833   1      6.00    6.31; Compaq    AlphaServer GS80 Model 6/731   8     33.0    36.0t    
 CFP2000 Ratese  ; Compaq    AlphaServer ES40 Model 6/667   1     5.87    6.50a: Compaq    AlphaServer ES40 Model 6/667   2    11.0    12.2: Compaq    AlphaServer ES40 Model 6/667   4    19.7    21.9  ; Compaq    AlphaServer ES40 Model 6/833   1     6.84    7.63-           David Beatty a crit :  . > Does anyone know what the performance uplift1 > for an ES40 going from an EV67 667MHz processorT1 > to an EV68 833MHz processor?  I can''t find the0+ > numbers on the Compaq website.  Thanks in0
 > advance. >e > David R. Beatty>   --M -----------------------------------------------------------------------------2  B Andre Bastien                           TransEnergie, Hydro-Quebec? Informatique du domaine transport       855, Ste-Catherine est,  Place-DupuisA TEL:(514)840-3000 p.3714                Montreal (Quebec), Canadaa/ FAX:(514)840-5045                       H2L 4P5g bastien.andre.p@hydro.qc.cac   ------------------------------  # Date: Fri, 09 Feb 2001 03:01:32 GMT  From: vjthomas@my-deja.com8 Subject: File Not Found with Pre Expired password logins) Message-ID: <95vmi8$uul$1@nnrp1.deja.com>m   Hopefully a simple one.d3 Just installed two clustered Alphas running VMS 7.2P  B Can login as system fine. Have an 8 user license pak installed oneG each. I created a user with a pre-expired password. When I login as the C new user, enter the old password, then the new one twice, I get the- message,   File not found+ Please try again or press (CTRL/Y) to abortp  . Then it prompts me for the new password again.  
 Any ideas?G (I used to consider myself a 9 out 10 in VMS but haven't touched it for F about 6 years (VMS 5 was last version I worked on). It's slowly comingE back to me. VERY SLOWLY. It's frustrating trying to remember things IJ used to live and breath.)t   THANKS!j     Sent via Deja.comi http://www.deja.com/   ------------------------------  % Date: Fri, 09 Feb 2001 01:01:26 +0000U) From: Christof Brass <brass@infopuls.com>F< Subject: Re: Firmware upgrade for PWS 600au to use a ZLXp-L1, Message-ID: <3A834166.B78E51E6@infopuls.com>   Robert Deininger wrote:R > p > In article <k+Le6EjKDd$V@eisner.encompasserve.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote: > H > > If you are able to do something, please ensure that somebody workingJ > > on it at least has seen how Macintosh handles arrangements of multipleF > > screens from a User Interface perspective.  There is a cute littleC > > applet that allows you to drag around which screen is logicallyeD > > positioned to the left and to the right and above and below each > > other screen.M >  > There'll be an ice-skating party in Hades when X-windows can support multiple screens as well as a Mac could in 1990.  Still, your suggestion is a good one.  Every little bit of improvement helps. > i > I notice Billy-boxes can handle 2 screens now.  I wonder if they have copied all the Mac functionality.. >  > -- > Robert Deininger > rdeininger@mindspring.com.  @ X11 has been supporting multiple heads for ages. The problem has: always been the hardware. With the lates Xfree86 X Display: Server you should be able to arrange *a lot* of screens in@ whatever fashion you like, i.e. you can build your own matrix of@ related screens with holes and overlapping areas. Pretty amazing but for myself not necessary.o   ------------------------------  % Date: Fri, 09 Feb 2001 01:14:16 +0000l) From: Christof Brass <brass@infopuls.com>e< Subject: Re: Firmware upgrade for PWS 600au to use a ZLXp-L1, Message-ID: <3A834468.288016E1@infopuls.com>   Paul Repacholi wrote:b > ? > You can specify the DPI in one of the server startup file forl > each screen. >  > --> > 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.  = If this is really true than I owe you something because I got @ the information that this isn't possible from a Compaq technical7 sales represantative (the one who told me that in Alpha , *servers* only one graphics card will work).   ------------------------------  % Date: Fri, 09 Feb 2001 01:23:29 -0500g2 From: rdeininger@mindspring.com (Robert Deininger)< Subject: Re: Firmware upgrade for PWS 600au to use a ZLXp-L1L Message-ID: <rdeininger-0902010123290001@user-2ivebor.dialup.mindspring.com>  W In article <3A834166.B78E51E6@infopuls.com>, Christof Brass <brass@infopuls.com> wrote:g    3 > X11 has been supporting multiple heads for ages.    # Well, I did say "as well as a Mac".1   > The problem hasa< > always been the hardware. With the lates Xfree86 X Display< > Server you should be able to arrange *a lot* of screens inB > whatever fashion you like, i.e. you can build your own matrix ofB > related screens with holes and overlapping areas. Pretty amazing > but for myself not necessary.r   Can you drag a window around between two (or more) screens?  What happens when a window is placed on 4 screens at once: 1 B&W, 1 8-bit color, 1 16-bit color, and 1 24-bit color?u   -- h Robert Deininger rdeininger@mindspring.comu   ------------------------------   Date: 8 FEB 2001 21:32:38 GMT $ From: mrl@psfc.mit.edu (Mark London)# Subject: FORCING 8BIT COLOR IN DCE?v* Message-ID: <8FEB01.21323884@psfc.mit.edu>  N I have a 24 bit color monitor, but I don't want to use 24 bit color because ofL a problem with an application (ghostscript, see my previous post).  Is thereE anyway to force DCE to start up and use 8 bit color instead?  Thanks.o   Mark London  MRL@PSFC.MIT.EDU   ------------------------------  % Date: Fri, 09 Feb 2001 05:03:39 +0100,2 From: martin@radiogaga.harz.de (Martin Vorlaender)' Subject: Re: FORCING 8BIT COLOR IN DCE? ; Message-ID: <3a836c1b.524144494f47414741@radiogaga.harz.de>.  % Mark London (mrl@psfc.mit.edu) wrote:dM > I have a 24 bit color monitor, but I don't want to use 24 bit color becausegG > of a problem with an application (ghostscript, see my previous post).tG > Is there anyway to force DCE to start up and use 8 bit color instead?o  K I'm not near a DECwindows system right now, but I remember seeing somethingoK like DEFAULT_VISUAL in one of the SYS$MANAGER:DECW$PRIVATE* files (probablyAK DECW$PRIVATE_SERVER_SETUP). Copy from .TEMPLATE to .COM if the .COM doesn't = yet exist, edit appropriately, and then restart DECwindows byP  %   $ @SYS$STARTUP:DECW$STARTUP RESTART-  ' Note that this kills all open sessions!2  G It's also possible for some graphics cards to set the color depth via a G special symbol; dig in the DECW$DEVICE_*.COM for your graphic device tol	 find out.:   cu,    Martin --J One OS to rule them all       | Martin Vorlaender  |  VMS & WNT programmer7 One OS to find them           | work: mv@pdv-systeme.de J 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: Thu, 08 Feb 2001 13:22:52 -0500i+ From: Brad Hamilton <Brad.Hamilton@fmr.com>o Subject: Re: FTP Neededt' Message-ID: <3A82E3FC.B0371442@fmr.com>e   Hi,   D *If* you are using SMTP on the VAX, and *if* you are using a serviceE such as SKYTEL for paging, you could create a batch job on the VAX toiD e-mail pager.dat to <pin-number>@skytel.com every few minutes or so.  G Of course, I am leaving the actual details, error-handling, and cleanups! as a exercise for the reader.	:-)c   Brad   "Webb, William W" wrote: > : > Why not just use Watchdog to page directly from the VAX?= > Heckuva lot less trouble than the kludge you're suggesting.m > < > I mean last time I cared to look, Windows didn't even have$ > batch queues, for crying out loud. >  > WWWebb >  > -----Original Message-----1 > From: Info-VAX-Request@Mvb.Saic.Com at INTERNET , > Sent: Thursday, February 08, 2001 12:57 PM8 > To: Webb, William W; Info-VAX@Mvb.Saic.Com at INTERNET > Subject: FTP Needede > ; > I am looking for an FTP application to run from a Windows 6 > client, connected to an Open VMS server running UCX. > , > The application needs to do the following:3 > 1. Every 2 minutes (or so) connect to the server.e2 > 2. Get all "pager.dat" files out of a directory.J > 3. Remove the "pager.dat" files off of the server, after transfer to the > PC.sG > 4. Ability to rename the files either while they are on the server orr > afteraI >     they are stored on the PC.  The application that will use the filesr5 >    does not like the ";1" ";2", etc version number.e > E > This application is an automated paging system.  Once the files areB > FTP'duH > from the VAX to the PC, we need to be sure that the same files are notF > retransferred on the next session, about once every 2 minutes.  Each > pagingF > message is stored on the VAX in a file called "pager.dat" so we willI > possibly/likely have multiple versions of that file each time we check.  > / > Any suggestions would be greatly appreciated.  >  > jn   ------------------------------  % Date: Thu, 08 Feb 2001 20:22:53 +0000p; From: Malcolm MacArthur <malcolmm@rustic-place.demon.co.uk>t Subject: Re: FTP Needede8 Message-ID: <3A83001D.8F9B9627@rustic-place.demon.co.uk>   Christopher Smith wrote: > M > You haven't looked for a few years, I suppose?  I envy you. :)  Windows hasaN > had batch queue (not queues) since windows 95, I think.  It's trash, really,L > not very good or well supported, but it's there.  I suppose windows NT may5 > have a queue for each user, making it batch queues.    Nope.M  N By default, Windows Nt comes with something called the Schedule service. This,O like the Windows 95 batch system, is flat. There is one queue, all jobs go intoeN it, there are no job limits (you can run an arbitrary number of jobs at once),N there are no process quotas, and there is no priority system. Oh, and they allO run under the user context of the Schedule service - by default this runs as NT K AUTHORITY\SYSTEM (in-built accound used by the system). This means it can'trN access network resources unless you change the user it runs under to a user inP the domain. Oh, and if that user changes their password, the service needs to be7 reconfigured with the new password. Overall, very poor.r  P Installing some version of Internet explorer or other (not sure which - or is itN Office 2000?) does install a replacement for the Schedule service (called TaskQ Scheduler), which also allows you to specify which user jobs should run under. ItaO suffers from the same password-change problem (I think...) that Schedule does -a< change the password and you have to re-authenticate the job!  O All the system calls are there in Windows NT to allow the system to impersonaterP users - but I believe the problem is that, whenever you want to access a networkK address, you need the password of the account. No equivalent of proxies fori) network access - probably just as well...i  K I don't know what Windows 2000 offers by way of replacement, but I bet it'so nowhere near as good.i  O There is some company selling a VMS-like batch system you could bolt on to youra NT box. Anyone know who it is?    E As far as Will's problem goes: if you have Windows NT, write a script 1 that FTPs the files (Not sure if this works, try:  C:\> ftp -i < ftpcommands.dat  ftpcommands.dat is:r quote user usernameo quote pass passwordm
 cd disk:[dir]a lcd c:\destinationdirp mget *.* quit  O (you may have to put a "prompt" command before the mget to turn off interactive 1 mode, but I think that's what the -i does anyway)q  N Have the script sleep for 5 minutes, then re-run. Set it up as a service using% SRVANY. Both are in the Resource kit.n  M On Windows 95, you could do a similar approach- write the batchfile, create a 2 REG_SZ entry (name of entry does not matter) under@ HKLM\Software\Windows\CurrentVersion\Run and have it run "cmd /cO c:\path\to\batch\file\file.bat". But your problem is getting rid of the commandi prompt window.  A However, I think that's quite enough about Windows for one day ;)S  < -Malcolm (who used to be a Windows NT system admin, and then,           became an OpenVMS system admin. ;)   ------------------------------   Date: 8 Feb 2001 20:52:39 GMT@0 From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Subject: Re: FTP Neededa5 Message-ID: <95v0un$eq9$1@newsmaster.cc.columbia.edu>w  4 Webb, William W; Info-VAX@Mvb.Saic.Com at INTERNET: ; : I am looking for an FTP application to run from a Windowss6 : client, connected to an Open VMS server running UCX. : , : The application needs to do the following:3 : 1. Every 2 minutes (or so) connect to the server. 2 : 2. Get all "pager.dat" files out of a directory.N : 3. Remove the "pager.dat" files off of the server, after transfer to the PC.G : 4. Ability to rename the files either while they are on the server oreI :    after they are stored on the PC.  The application that will use the e; :    files does not like the ";1" ";2", etc version number.l : K : This application is an automated paging system.  Once the files are FTP'doH : from the VAX to the PC, we need to be sure that the same files are notM : retransferred on the next session, about once every 2 minutes.  Each paging F : message is stored on the VAX in a file called "pager.dat" so we willI : possibly/likely have multiple versions of that file each time we check.r : / : Any suggestions would be greatly appreciated.0 :  See:  /   http://www.columbia.edu/kermit/ftpclient.htmlf   and:  /   http://www.columbia.edu/kermit/ftpscript.htmlo  I You'll notice that these pages describe a UNIX client, but the exact same@J code and features will be in the next release of Kermit 95 for Windows 95/J 98/ME/NT/2000.  If you're a current K95 user, you can get an Alpha test to experiment with.   - Frankn   ------------------------------   Date: 8 Feb 2001 21:34:18 GMTo3 From: gartmann@immunbio.mpg.de (Christoph Gartmann)  Subject: Re: FTP Needed 0 Message-ID: <95v3cq$ohp$1@n.ruf.uni-freiburg.de>  _ In article <3A82D7FC.EF44DB53@ardemgaz.com>, Judy Nethercutt <jnethercutt@ardemgaz.com> writes:n: >I am looking for an FTP application to run from a Windows5 >client, connected to an Open VMS server running UCX.1 > + >The application needs to do the following: 2 >1. Every 2 minutes (or so) connect to the server.1 >2. Get all "pager.dat" files out of a directory. I >3. Remove the "pager.dat" files off of the server, after transfer to the  >PC.F >4. Ability to rename the files either while they are on the server or >afterH >    they are stored on the PC.  The application that will use the files4 >   does not like the ";1" ";2", etc version number. > D >This application is an automated paging system.  Once the files are >FTP'dG >from the VAX to the PC, we need to be sure that the same files are not5E >retransferred on the next session, about once every 2 minutes.  Each- >paging-E >message is stored on the VAX in a file called "pager.dat" so we will'H >possibly/likely have multiple versions of that file each time we check.  K First, why is the need for the PC? I assume the PC is used to actually callcJ the pager. If this is the case, let VMS do the job, no need for a PC here.J Next, which "Windows" is the PC usign? If it is Win-NT than this one has aO built-in FTP server (it might be that you need to install some additional stuffcM from the Win-NT CD in order to get this functionality). Then you can initiatey! transfer from within VMS via DCL.tM If the PC runs Windows-98 or Win-3.11 you may buy some software to put an FTPa2 server on it. I wouldn't go the client route here.   Regards,    Christoph Gartmann0  H -- --------------------------------------------------------------------+H | Max-Planck-Institut fuer      Phone   : +49-761-5108-464   Fax: -452 |H | Immunbiologie                                                        |H | Postfach 1169                 Internet: gartmann@immunbio.mpg.de     |H | D-79011  Freiburg, FRG                                               |H +--------- http://www.immunbio.mpg.de/home/english/menue.html ---------+   ------------------------------  # Date: Thu, 08 Feb 2001 23:31:38 GMT0/ From: "Tom Simpson" <simpsont@xxx.mediaone.net>l Subject: Re: FTP Needed3F Message-ID: <u%Fg6.11970$En4.196075@typhoon.jacksonville.mediaone.net>  E Why FTP?  If you have Pathworks, simply copy the files there directly7C from the VMS program.  Map that directory as a network drive on the  PC.   C If you must use a PC, look at the WINBATCH product.  It was made tooF do things like this and can do the FTP directly.  (WWW.WINDOWWARE.COM)L I use this product a lot to file exchanges with external clients.  It's easy to learn and use, but...6  @ ...I also strongly advise you to NOT use a PC in your production@ environment if possible.  It's like pasting a big "KICK ME" sign on your backside...-   Regards, Tom-  = "Judy Nethercutt" <jnethercutt@ardemgaz.com> wrote in message & news:3A82D7FC.EF44DB53@ardemgaz.com...; > I am looking for an FTP application to run from a Windows 6 > client, connected to an Open VMS server running UCX. >3, > The application needs to do the following:3 > 1. Every 2 minutes (or so) connect to the server.P2 > 2. Get all "pager.dat" files out of a directory.J > 3. Remove the "pager.dat" files off of the server, after transfer to the > PC. G > 4. Ability to rename the files either while they are on the server orv > after@I >     they are stored on the PC.  The application that will use the filesA5 >    does not like the ";1" ";2", etc version number.e > E > This application is an automated paging system.  Once the files arei > FTP'doH > from the VAX to the PC, we need to be sure that the same files are notF > retransferred on the next session, about once every 2 minutes.  Each > pagingF > message is stored on the VAX in a file called "pager.dat" so we willI > possibly/likely have multiple versions of that file each time we check.o > / > Any suggestions would be greatly appreciated.) >t > jn >    ------------------------------  $ Date: Fri, 9 Feb 2001 13:31:40 +1100/ From: "Phil Howell" <phowell@snowyhydro.com.au>  Subject: Re: FTP Needed// Message-ID: <WBIg6.193$FU5.5223@ozemail.com.au>   ; Judy Nethercutt <jnethercutt@ardemgaz.com> wrote in message<& news:3A82D7FC.EF44DB53@ardemgaz.com...; > I am looking for an FTP application to run from a Windows46 > client, connected to an Open VMS server running UCX. > , > The application needs to do the following:3 > 1. Every 2 minutes (or so) connect to the server.a2 > 2. Get all "pager.dat" files out of a directory.J > 3. Remove the "pager.dat" files off of the server, after transfer to the > PC.aG > 4. Ability to rename the files either while they are on the server ort > afterrI >     they are stored on the PC.  The application that will use the filesi5 >    does not like the ";1" ";2", etc version number.h >nE > This application is an automated paging system.  Once the files area > FTP'dyH > from the VAX to the PC, we need to be sure that the same files are notF > retransferred on the next session, about once every 2 minutes.  Each > pagingF > message is stored on the VAX in a file called "pager.dat" so we willI > possibly/likely have multiple versions of that file each time we check.g > / > Any suggestions would be greatly appreciated.o >n > jn >e5 My suggestion is to use ucx smtp to send the message.a; Pager files are generally small text files - ideal for smtpl% ftp is built to handle large binariest> (and you have to change your ftp syntax on every ucx release!)2 ftp from a client in this way requires a vms login? (what if the password has expired or number of users exceeded?)- something like this should work0 $loop:6 $ if f$search("pager.dat") .eqs. "" then goto waitloop? $ if f$search("pager.txt") .eqs. "" then rename pager.dat; .txtsE $ mail /subject="another page"  pager.txt smtp%pcuser@yourcompany.com  $ rename pager.txt .sent $ goto loop 
 $waitloop: $ wait 00:02 $ goto loop.  F you could cut out the PC and send to smtp%pagernumber@pagercompany.com  7 if you want the pager files processed in the same order @ that they arrive you may want to name them as yymmddhhmmsshs.dat Phil   ------------------------------  % Date: Thu, 08 Feb 2001 21:02:47 -0700a% From: Dean Woodward <deanw@rdrop.com>h Subject: Re: FTP Neededs) Message-ID: <3A836BE7.5668A78A@rdrop.com>    Phil Howell wrote: > 9 > if you want the pager files processed in the same orderwB > that they arrive you may want to name them as yymmddhhmmsshs.dat  H FOO.LIS;-1 will give you the oldest copy of FOO.LIS- FOO.LIS;0 gives the most recent.  G I have a webpage and DCL cgi script that handles sending messages to my1 pager- available on request.   ------------------------------  $ Date: Fri, 9 Feb 2001 15:51:17 +1100/ From: "Phil Howell" <phowell@snowyhydro.com.au>e Subject: Re: FTP Neededa/ Message-ID: <REKg6.260$FU5.8162@ozemail.com.au>a  0 Dean Woodward <deanw@rdrop.com> wrote in message# news:3A836BE7.5668A78A@rdrop.com...  > Phil Howell wrote: > > ; > > if you want the pager files processed in the same order,D > > that they arrive you may want to name them as yymmddhhmmsshs.dat >oJ > FOO.LIS;-1 will give you the oldest copy of FOO.LIS- FOO.LIS;0 gives the > most recent. >uI > I have a webpage and DCL cgi script that handles sending messages to my4 > pager- available on request. I'm sure you meant to say # foo.lis;-0 will give you the oldesti+ foo.lis; or foo.lis;0 gives the most recent-# foo.lis;-1 gives the "last but one"0 Phil   ------------------------------  % Date: Thu, 08 Feb 2001 18:59:43 +0000O  From: steven.reece@quintiles.com9 Subject: Re: Installing NT 4.0 on a DEC 3000 Alpha ServerIH Message-ID: <OF1004E328.62270C43-ON802569ED.00681E13@qedi.quintiles.com>  I I don't *think* that NT is supported (i.e. it will not run) on a DEC 3000uG series Alpha system.  It really predates NT on Alpha to a large extent.U  H Later AlphaServers and Alpha Workstations would play quite happily as NTB systems provided that you had the AlphaNT images and not the Intel (mass-market) NT images.   Steve.        ) sfm1115@bjc.org on 08-02-2001 03:56:00 PM.   To:   Info-VAX@Mvb.Saic.Comd) cc:    (bcc: Steven Reece/QRED/Quintiles),  6 Subject:  Installing NT 4.0 on a DEC 3000 Alpha Server    B I am playing around and would like to install NT 4.0 on a DEC 3000 server.   D Is there something I need to do why it is at the boot prompt to tellD this server it is going to be running NT.  When I boot up in OpenVMSB mode, I am able to mount the CD but not start the install program.  ? Any web pages on how to install NT on an Alpha would be greatly. appreciated.     Thanks   Shawnp   sfm1115@bjc.orge   ------------------------------  % Date: Thu, 08 Feb 2001 10:58:32 -0800 ! From: Shane.F.Smith@Healthnet.comt8 Subject: Re: It's the end for VMS and other Wild RumoursD Message-ID: <OF8F0F02BC.17347A30-ON882569ED.00680E88@foundation.com>  J Not when I brewed the coffee, they aren't. You know the Alien movies? TheyD used my coffee and a little green food colouring for the alien blood effects.....   Shanev          9 Dean Woodward <deanw@rdrop.com> on 02/07/2001 06:58:36 PMe   To:   Info-VAX@Mvb.Saic.ComD cc:s  9 Subject:  Re: It's the end for VMS and other Wild Rumours-    ! mustang@ucc.asn.au.invalid wrote:0 >1, > Christof Brass <brass@infopuls.com> wrote: >nD > : Solaris is dead. SUN is going to drop it in favour of Linux. The> > : only chance for Solaris to survive is that the open source@ > : comunity will adopt it. What about learning Linux instead of > : Solaris? >n* > Christof - crawl back under your bridge./ > Are you an anti-matter-troll Andrew Harrison?s  D If anyone's interested, Compaq keyboards are coffee resistant... ;-)   ------------------------------  % Date: Thu, 08 Feb 2001 21:36:58 +0000 % From: Alan Greig <a.greig@virgin.net>f8 Subject: Re: It's the end for VMS and other Wild Rumours* Message-ID: <3A83117A.27C246C4@virgin.net>   Christopher Smith wrote:  4 > Dylan?  Nah, that was Peter, Paul and Mary, right? >W  C Dylan wrote it. Even seen him perform it live. Peter, Paul and Maryi sing it better though :) --
 Alan Greig   ------------------------------  % Date: Fri, 09 Feb 2001 00:38:47 +0000E) From: Christof Brass <brass@infopuls.com>o8 Subject: Re: It's the end for VMS and other Wild Rumours, Message-ID: <3A833C17.4E279747@infopuls.com>  ! mustang@ucc.asn.au.invalid wrote:  > , > Christof Brass <brass@infopuls.com> wrote: > D > : Solaris is dead. SUN is going to drop it in favour of Linux. The> > : only chance for Solaris to survive is that the open source@ > : comunity will adopt it. What about learning Linux instead of > : Solaris? > * > Christof - crawl back under your bridge./ > Are you an anti-matter-troll Andrew Harrison?  > - > Will you destroy each other upon collision?rE > Can Charlie Matco and Bill Joy shout you a plane ticket to Blighty?e >  > D. > --# > I don't get mad.... I get stabby.o   :-)e  " What does your last sentence mean?  ? To correct you: I'm convinced about SUN's plan to drop Solaris.a> They made some bad decisions in the last years against Solaris9 and they strongly support Linux recently. There is a veryh= serious computer magazin (sorry for that paradoxon) that alsoe> concluded this from what SUN did and said. Anyway I can't be a6 FUDster according to the agreed upon definition as I'm8 publishing within cov *only*. Do you see the difference?   And what about the bridge?   ------------------------------  % Date: Fri, 09 Feb 2001 00:39:47 +0000 ) From: Christof Brass <brass@infopuls.com>p8 Subject: Re: It's the end for VMS and other Wild Rumours, Message-ID: <3A833C53.998111F6@infopuls.com>  ! mustang@ucc.asn.au.invalid wrote:u > , > Christof Brass <brass@infopuls.com> wrote: > D > : Solaris is dead. SUN is going to drop it in favour of Linux. The> > : only chance for Solaris to survive is that the open source@ > : comunity will adopt it. What about learning Linux instead of > : Solaris? > * > Christof - crawl back under your bridge./ > Are you an anti-matter-troll Andrew Harrison?r > - > Will you destroy each other upon collision?yE > Can Charlie Matco and Bill Joy shout you a plane ticket to Blighty?  >  > D. > --# > I don't get mad.... I get stabby.R  : I offer you a publicly controlled bet: Solaris will sooner disappear than VMS.    ------------------------------  % Date: Fri, 09 Feb 2001 00:42:54 +0000a) From: Christof Brass <brass@infopuls.com>t8 Subject: Re: It's the end for VMS and other Wild Rumours, Message-ID: <3A833D0E.7E0BE573@infopuls.com>   Alan Greig wrote:l >  > Christopher Smith wrote: > 6 > > Dylan?  Nah, that was Peter, Paul and Mary, right? > >o > E > Dylan wrote it. Even seen him perform it live. Peter, Paul and Maryt > sing it better though :) > -- > Alan Greig   They really *sing* it ...e   ------------------------------  % Date: Fri, 09 Feb 2001 00:45:15 +0000t) From: Christof Brass <brass@infopuls.com> 8 Subject: Re: It's the end for VMS and other Wild Rumours, Message-ID: <3A833D9B.AE92E388@infopuls.com>  " Shane.F.Smith@Healthnet.com wrote: > L > Not when I brewed the coffee, they aren't. You know the Alien movies? TheyF > used my coffee and a little green food colouring for the alien blood > effects..... >  > Shanec > ; > Dean Woodward <deanw@rdrop.com> on 02/07/2001 06:58:36 PMs >  > To:   Info-VAX@Mvb.Saic.Comk > cc:  > ; > Subject:  Re: It's the end for VMS and other Wild Rumoursy > # > mustang@ucc.asn.au.invalid wrote:e > >a. > > Christof Brass <brass@infopuls.com> wrote: > >eF > > : Solaris is dead. SUN is going to drop it in favour of Linux. The@ > > : only chance for Solaris to survive is that the open sourceB > > : comunity will adopt it. What about learning Linux instead of > > : Solaris? > >e, > > Christof - crawl back under your bridge.1 > > Are you an anti-matter-troll Andrew Harrison?a > F > If anyone's interested, Compaq keyboards are coffee resistant... ;-)  = Aren't you from the USA? We regard USamerican coffee as watero" with a little bit of black colour.> BTW what has the keyboard against coffee resistance to do with Solaris beeing dropped by SUN?   ------------------------------  % Date: Fri, 09 Feb 2001 00:41:42 +0000m) From: Christof Brass <brass@infopuls.com>n8 Subject: Re: It's the end for VMS and other Wild Rumours, Message-ID: <3A833CC6.22AEC984@infopuls.com>   Dean Woodward wrote: > # > mustang@ucc.asn.au.invalid wrote:P > >e. > > Christof Brass <brass@infopuls.com> wrote: > >lF > > : Solaris is dead. SUN is going to drop it in favour of Linux. The@ > > : only chance for Solaris to survive is that the open sourceB > > : comunity will adopt it. What about learning Linux instead of > > : Solaris? > >t, > > Christof - crawl back under your bridge.1 > > Are you an anti-matter-troll Andrew Harrison?l > F > If anyone's interested, Compaq keyboards are coffee resistant... ;-)   What the hell does that mean??< Is there a conspiracy going on to publicly exchange messages; containing only special referings that I don't understand!?    ------------------------------  % Date: Thu, 08 Feb 2001 17:06:59 -0800 ! From: Shane.F.Smith@Healthnet.comu8 Subject: Re: It's the end for VMS and other Wild RumoursD Message-ID: <OF9D32A566.5D96824E-ON882569EE.000593D2@foundation.com>  F WASH YOUR MOUTH OUT/KEYBOARD OFF!!!!!!!!!! Don't you dare accuse me of being American.......   H I'm English, and glad of it. Where we speak real English, the cheese hasI more taste than cardboard, and when we have a world series we invite somee other countries to join in.   H As for the coffee resistance factor, damfino. I was responding to Dean's comment on the subject.-   Shane           = Christof Brass <brass@infopuls.com> on 02/08/2001 04:45:15 PMm   To:   Info-VAX@Mvb.Saic.Com0 cc:   9 Subject:  Re: It's the end for VMS and other Wild Rumours2    " Shane.F.Smith@Healthnet.com wrote: >'G > Not when I brewed the coffee, they aren't. You know the Alien movies?i TheyF > used my coffee and a little green food colouring for the alien blood > effects..... >p > Shanea >n; > Dean Woodward <deanw@rdrop.com> on 02/07/2001 06:58:36 PMa >h > To:   Info-VAX@Mvb.Saic.Comt > cc:s >a; > Subject:  Re: It's the end for VMS and other Wild Rumours2 > # > mustang@ucc.asn.au.invalid wrote:i > >d. > > Christof Brass <brass@infopuls.com> wrote: > >cF > > : Solaris is dead. SUN is going to drop it in favour of Linux. The@ > > : only chance for Solaris to survive is that the open sourceB > > : comunity will adopt it. What about learning Linux instead of > > : Solaris? > > , > > Christof - crawl back under your bridge.1 > > Are you an anti-matter-troll Andrew Harrison?n >lF > If anyone's interested, Compaq keyboards are coffee resistant... ;-)  = Aren't you from the USA? We regard USamerican coffee as water " with a little bit of black colour.> BTW what has the keyboard against coffee resistance to do with Solaris beeing dropped by SUN?   ------------------------------  # Date: Fri, 09 Feb 2001 01:56:47 GMT2L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")8 Subject: Re: It's the end for VMS and other Wild Rumours8 Message-ID: <009F7580.F7CC1CA2@SSRL04.SLAC.STANFORD.EDU>  ; In article <3A833CC6.22AEC984@infopuls.com>, Christof Brass0 <brass@infopuls.com> writes:   >Dean Woodward wrote:  >> c$ >> mustang@ucc.asn.au.invalid wrote: >> >/ >> > Christof Brass <brass@infopuls.com> wrote:  >> >G >> > : Solaris is dead. SUN is going to drop it in favour of Linux. TheiA >> > : only chance for Solaris to survive is that the open sourceaC >> > : comunity will adopt it. What about learning Linux instead ofh >> > : Solaris?  >> >- >> > Christof - crawl back under your bridge.l2 >> > Are you an anti-matter-troll Andrew Harrison? >> AG >> If anyone's interested, Compaq keyboards are coffee resistant... ;-)e >t >What the hell does that mean??-= >Is there a conspiracy going on to publicly exchange messagesn< >containing only special referings that I don't understand!?  B Yup.  But I'm not in on the conspiracy, so I'm allowed to explain.  N The bridge thing is a joke on the fairy-tale meaning of "troll."  In the storyF of the Three Billy Goats Gruff (which I think English speakers know inH translation from the Brothers Grimm), the villain is a troll that lives N under a bridge.  [There's a whole argument about what "troll" means on Usenet,E and it's probably derived from a particular fishing technique, so the " fairy-tale meaning is just a pun.]  L The "coffee-resistant keyboard" thing suggests that Dean was drinking coffeeF when he read the suggestion that you were an "anti-matter-troll AndrewI Harrison" and, caught unawares, choked or laughed or spat coffee onto his 2 keyboard.  (He's lucky he didn't get the monitor.)   Hope this helps!   -- Alani  O ===============================================================================A0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056oM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210tO ===============================================================================t   ------------------------------  % Date: Thu, 08 Feb 2001 21:40:32 -0500l- From: JF Mezei <jfmezei.spamnot@videotron.ca> 8 Subject: Re: It's the end for VMS and other Wild Rumours, Message-ID: <3A835880.4F294BB3@videotron.ca>  " Shane.F.Smith@Healthnet.com wrote: > H > WASH YOUR MOUTH OUT/KEYBOARD OFF!!!!!!!!!! Don't you dare accuse me of > being American.......e  H Don't you live and work in the USA for a USA employer ? If so, you're noF longer a brit, you're just an expat Pom slowly bute surely losing your, heritage and being assimilated into america.   ------------------------------  % Date: Thu, 08 Feb 2001 18:46:36 -0800 ! From: Shane.F.Smith@Healthnet.com 8 Subject: Re: It's the end for VMS and other Wild RumoursD Message-ID: <OFA5717C3A.F1A0C218-ON882569EE.000F0C28@foundation.com>  C Yes, I live in the USA, but I'm surrounded by fellow ex-pats so theyC cultural erosion is considerably slowed. However, I carry a British E passport, and I'm a British citizen, and that is NOT going to change.tI Before I came here, I could honestly say I didn't care either way. Then I # found out what America is like.....s   Shanet          A JF Mezei <jfmezei.spamnot@videotron.ca> on 02/08/2001 06:40:32 PMb   To:   Info-VAX@Mvb.Saic.Com) cc:s  9 Subject:  Re: It's the end for VMS and other Wild Rumourst    " Shane.F.Smith@Healthnet.com wrote: >aH > WASH YOUR MOUTH OUT/KEYBOARD OFF!!!!!!!!!! Don't you dare accuse me of > being American.......   H Don't you live and work in the USA for a USA employer ? If so, you're noF longer a brit, you're just an expat Pom slowly bute surely losing your, heritage and being assimilated into america.   ------------------------------   Date: 8 Feb 2001 18:53:02 GMTl1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)a Subject: Re: Lisbon Conference, Message-ID: <95upue$1bh5$1@info.cs.uofs.edu>  3 In article <9NJvTwA88tXV@eisner.encompasserve.org>,a<  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:\ |> In article <3A829EB5.89FB2A56@bbc.co.uk>, Tim Llewellyn <tim.llewellyn@bbc.co.uk> writes: |> >  K |> > However, people still build on flood plains here in the UK, so I'm nota |> > being smug, really. |>  9 |> Darn, and I thought that technique was a US invention.b |> 'G |> Well, do you folks have government insurance to help them REbuild ont |> the flood plain ?  D They get you coming or going.  I bought a house several hundred feetE above the flood plain.  They made me buy "Mine Subsidence" insurance.    bill   -- iJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   n   ------------------------------   Date: 8 Feb 2001 16:37:56 -0500e4 From: koehler@eisner.encompasserve.org (Bob Koehler)! Subject: MIME$MAILCAP.DAT format?a3 Message-ID: <$tCLssyUMQDm@eisner.encompasserve.org>d  B   Anybody know the format of the MIME$MAILCAP.DAT file used by the   VMS MIME utility?  t  F   I've just got the latest MIME patch and it looks better than it usedK   to be, but it refers me to the non-existant SYS$MANAGER:MIME$MAILCAP.DAT o   with no other details.  @   For the curious:  the new MIME isn't ready to replace munpack.  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporation-= NASA GSFC Flight Software       | Federal Sector, Civil GroupbE                                 | please remove ".aspm" when replyingq   ------------------------------  $ Date: Thu, 8 Feb 2001 17:05:27 -0500- From: "Peter Weaver" <peter.weaver@stelco.ca>c% Subject: Re: MIME$MAILCAP.DAT format? 4 Message-ID: <7LEg6.129439$Z2.1660178@nnrp1.uunet.ca>  A "Bob Koehler" <koehler@eisner.encompasserve.org> wrote in message)- news:$tCLssyUMQDm@eisner.encompasserve.org...a >fD >   Anybody know the format of the MIME$MAILCAP.DAT file used by the >   VMS MIME utility?   F I don't know, but I took a guess (bassed on Netscape's mime file) that it should look something like    $ ty mime$mailcap.datp audio/x-mpeg; mplay %s  = Creating this file with this line gives me a SHOW CONTENT of;l   Known Content-Types:  Content-Type: audio/x-mpegm     View Command:  mplay %s   Content-Type: text/html  Content-Type: text/plain      Edit Command: EDIT/TPU  Content-Type: message/rfc822o   so maybe the %s is not needed.   > C >   I've just got the latest MIME patch and it looks better than itl used/ >   to be, but it refers me to the non-existant  SYS$MANAGER:MIME$MAILCAP.DAT >   with no other details.  D Not much better IMHO. But when I installed it I had nothing complain. that SYS$MANAGER:MIME$MAILCAP.DAT was missing.   >pB >   For the curious:  the new MIME isn't ready to replace munpack.  B I already sent in a list of 5 bugs that I noted in V1.4 and I only installed it about 6 hours ago.M     --   RULES OF THE AIR   ----------------- ?  #24. The three most useless things to a pilot are the altitude-@       above you, runway behind you, and a tenth of a second ago.   ------------------------------  # Date: Fri, 09 Feb 2001 00:06:57 GMTg/ From: Paul Mosteika <paulmosteika@adelphia.net>a% Subject: Re: MIME$MAILCAP.DAT format?,+ Message-ID: <3A8334A9.6652347@adelphia.net>r  G See the MIME help: Overview and also SHOW CONTENT_TYPES. There are also,	 examples.t       TYPE/SUBTYPE VIEW_COMMAND1    !                     Paul Mosteikaf   ------------------------------  % Date: Wed, 07 Feb 2001 17:06:23 -0800 0 From: Mark Berryman <Mark.Berryman@Mvb.Saic.Com>( Subject: Re: MMS/MMK Ghostscript problem, Message-ID: <3A81808F.18175F39@Mvb.Saic.Com>   JF Mezei wrote:h >  > > Mark Berryman wrote:N > > > Let it run.  I built it on a VAX 3900 and it took at least 8 hours for a > > > complete build.k > K > Thanks for the suggestion. It finally did finish its endless checking andg > starts to link GS.EXE. > C > But then it failed on insufficient /BYTLM :-( :-( :-) :-( :-( :-(e > N > So, after some 17 hours of processiung, the final link crashs ! Talk about a > disapointment !!!!!t > O > So, I have started it again, and I reckon it will probably take some 12 hoursp5 > of looping before it actually starts to link GS.EXEw > O > What I find odd is that it seems to spawn a subprocess that runs MMK with theh > same arguments.  > P > I increased BYTLM to 60000 which Authorize says is the default for Alpha. What! > would be a good bytlm for VAX ?-  F I currently use a bytlm of 100000 which is what I've used for years onG both VAX and Alpha systems.  This number has proven sufficient for bothiG code development and the various DECWindows things I tend to play with.W  G You will also need an elevated FILLM (and corresponding CHANNELCNT).  IgG do not know the minimum needed to build ghostscript (but the default of-B 255 is not enough).  I currently have my accounts FILLM at 400 and CHANNELCNT at 500.  
 Mark Berryman    ------------------------------  # Date: Thu, 08 Feb 2001 23:20:06 GMT , From: peterw@u.genie.co.uk (Peter Watkinson) Subject: Northernlight= Message-ID: <3a87290f.27631515@newshost.netscapeonline.co.uk>    Hi,   F I read somewhere in this forum about Northernlight.com running OpenvmsE Alpha servers. And these are advertised on the site too. However when > I looked it up on Netcraft.com it says Apache on Sloaris. What figures?  	  regards,l     Peter Watkinsone Email: peterw@u.genie.co.uk0( Internet: http://you.genie.co.uk/peterw/A Windsurf International.com http://www.windsurf-international.com/e* PW Navigate.com http://www.pwnavigate.com/   ------------------------------  % Date: Thu, 08 Feb 2001 15:51:54 -0800 ! From: Shane.F.Smith@Healthnet.comt Subject: Re: NorthernlightD Message-ID: <OF8010DFDA.9857A5FA-ON882569ED.00830CF4@foundation.com>  K Solaris is the front end. The real work happens on the VMS backend servers,., which are Wildfire class Alphas running VMS.   Shaney          @ peterw@u.genie.co.uk (Peter Watkinson) on 02/08/2001 03:20:06 PM   To:   Info-VAX@Mvb.Saic.Come cc:,   Subject:  Northernlight        Hi,t  F I read somewhere in this forum about Northernlight.com running OpenvmsE Alpha servers. And these are advertised on the site too. However when > I looked it up on Netcraft.com it says Apache on Sloaris. What figures?  	  regards,l     Peter Watkinsonm Email: peterw@u.genie.co.uk ( Internet: http://you.genie.co.uk/peterw/A Windsurf International.com http://www.windsurf-international.com/r* PW Navigate.com http://www.pwnavigate.com/   ------------------------------  % Date: Thu, 08 Feb 2001 18:52:08 -0500 " From: Dan Sugalski <dan@sidhe.org> Subject: Re: Northernlight: Message-ID: <5.0.2.1.0.20010208185117.021d9600@24.8.96.48>  2 At 11:20 PM 2/8/2001 +0000, Peter Watkinson wrote:   >Hi, >cG >I read somewhere in this forum about Northernlight.com running OpenvmstF >Alpha servers. And these are advertised on the site too. However when? >I looked it up on Netcraft.com it says Apache on Sloaris. WhatV	 >figures?e  L Nothing, particularly. The front-end webservers are Sun boxes, the back end   database machines are VMS boxes.   					Dan  I --------------------------------------"it's like this"-------------------A2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and even ;                                       teddy bears get drunkr   ------------------------------  % Date: Thu, 08 Feb 2001 19:01:36 -0500 " From: Dan Sugalski <dan@sidhe.org> Subject: Re: Northernlight: Message-ID: <5.0.2.1.0.20010208190115.01b4b118@24.8.96.48>  > At 03:51 PM 2/8/2001 -0800, Shane.F.Smith@Healthnet.com wrote:  L >Solaris is the front end. The real work happens on the VMS backend servers,- >which are Wildfire class Alphas running VMS.-  = Nah, we're not that new. TurboLaser machines on the back end.u  A >peterw@u.genie.co.uk (Peter Watkinson) on 02/08/2001 03:20:06 PMD >9 >To:   Info-VAX@Mvb.Saic.Com >cc: >t >Subject:  Northernlight >o >s >v >Hi, > G >I read somewhere in this forum about Northernlight.com running OpenvmslF >Alpha servers. And these are advertised on the site too. However when? >I looked it up on Netcraft.com it says Apache on Sloaris. Whats	 >figures?e >, >  regards,  >> >i >Peter Watkinson >Email: peterw@u.genie.co.uk) >Internet: http://you.genie.co.uk/peterw/>B >Windsurf International.com http://www.windsurf-international.com/+ >PW Navigate.com http://www.pwnavigate.com/n     					Dan  I --------------------------------------"it's like this"-------------------y2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and eveno;                                       teddy bears get drunks   ------------------------------  # Date: Thu, 08 Feb 2001 23:09:36 GMT  From: Dirk Munk <munk@home.nl>G Subject: Not being published: OpenVMS Performance Management book ed 2. ' Message-ID: <3A83272D.590CD3CE@home.nl>o   Remember this message ?:      Digital Press establishes    Partnership with Compaq    Computer Corporation OpenVMSe    Group  .    Digital Press has established a partnership+    agreement with Compaq's OpenVMS Group toM3    strengthen and enhance our working relationship.t1    We are collaborating to update current DigitalM1    Press OpenVMS titles, generate new titles, and 3    generally increase the level of our products and./    services we deliver to OpenVMS customers and-	    users.-  H The first new title would be "OpenVms Performance Management ed. 2",  toD be published about a month ago. Now we have been told it will not be
 published.  F Maybe something for Rich Marcello and his marketing team to sort out ?   ------------------------------  # Date: Fri, 09 Feb 2001 00:15:37 GMTa+ From: rjordan@mars.mcs.net (Richard Jordan)MK Subject: Re: Not being published: OpenVMS Performance Management book ed 2.>4 Message-ID: <JEGg6.1243$jE2.130064@news.goodnet.com>  G Last year (or 1999) there was supposed to be a book titled "OpenVMS andnD the Internet" from Digital Press... Amazon and a couple other placesF had it listed for pre-orders.  It also never came out.  Disappointing.   Rich Jordanh rjordan@mcs.netk   ------------------------------   Date: 8 Feb 2001 19:22:43 -0500 9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)fK Subject: Re: Not being published: OpenVMS Performance Management book ed 2.m3 Message-ID: <sUDbv$NHIgLb@eisner.encompasserve.org>x  H In article <3A83272D.590CD3CE@home.nl>, Dirk Munk <munk@home.nl> writes: > Remember this message ?: >  >    Digital Press establishes >    Partnership with Compaq! >    Computer Corporation OpenVMSe
 >    Group > 0 >    Digital Press has established a partnership- >    agreement with Compaq's OpenVMS Group tou5 >    strengthen and enhance our working relationship.M3 >    We are collaborating to update current Digitalh3 >    Press OpenVMS titles, generate new titles, andc5 >    generally increase the level of our products andn1 >    services we deliver to OpenVMS customers and  >    users.E > J > The first new title would be "OpenVms Performance Management ed. 2",  toF > be published about a month ago. Now we have been told it will not be > published. > H > Maybe something for Rich Marcello and his marketing team to sort out ?   Marketing ?k  > If there is no content worth publishing, there is nothing that> marketing can do about it.  You might as well ask Marketing to speed up DUDRIVER.EXE.   ------------------------------  % Date: Thu, 08 Feb 2001 11:00:04 -0800_! From: Shane.F.Smith@Healthnet.coma3 Subject: Re: OpenVMS Alpha 1200 5/533 login problemeD Message-ID: <OFF9EB948B.2F9B31D1-ON882569ED.006846AF@foundation.com>  E Nope. All the cheap PC keyboards worked at the console, but failed in8/ DECwindows. Don't ask me why, coz I don't know.    Shanea          , kkratz@my-deja.com on 02/07/2001 07:22:15 PM   To:   Info-VAX@Mvb.Saic.Comh cc:f  4 Subject:  Re: OpenVMS Alpha 1200 5/533 login problem    G If it were a keyboard problem, wouldn't it start sending the charactersX7 in bootup? This only happens when DECWindows starts up.-    / In article <t83fukhh7s618f@news.supernews.com>,p0   wspencer@ap.nospam.org (Warren Spencer) wrote:< > kkratz@my-deja.com wrote in <95sbis$3ai$1@nnrp1.deja.com>: >rB > >When DECWindows starts We get the console login, but it flashes almostF > >like it is constantly refreshing.  You can't type the login name or> > >password because of this...Any suggestions?  Restarting the
 DECWindows+ > >server does not fix the problem.  Thanksf > >f > >Kee Kratz > >o > >e > >Sent via Deja.com > >http://www.deja.com/y > >f >0C > Sounds like a keyboard malfunction - it may be constantly sending 
 > characters.s >o > ws >c > --5 > << What if there were no hypothetical questions? >>h >s > Warren Spencer > Senior Software Engineer > The Associated Press >sA > ** My employer does not necessarily agree with my statements **h >s     Sent via Deja.como http://www.deja.com/   ------------------------------  $ Date: Thu, 8 Feb 2001 20:44:43 +0100* From: "Johan Koelewijn" <jocoko@hetnet.nl> Subject: phone in cluster1/ Message-ID: <OpKUYggkAHA.306@net037s.hetnet.nl>    Hello,  B We have a vms cluster with 2 nodes. Can I phone to a person who isK (possible) logged on to the other node without specifying the specific nodeg ?c   Thanks Johan Koelewijne VDD.   ------------------------------  # Date: Thu, 08 Feb 2001 19:44:49 GMTo& From: "Rick Cadruvi" <rick@rdperf.com>@ Subject: Porting Applications fromVMS to Windows with ISAM files9 Message-ID: <RGCg6.1611$Li7.183984@dfiatx1-snr1.gtei.net>   F I trust this is not off-topic for this group.  If so, please accept my
 apologies.  C Is there an interest in being able to port ISAM files and having an,? ISAM record system for VMS applications being ported to Windows < or just having direct ISAM file support within Windows apps?  = Do people need this and would they pay for such a developmenth= tool?  It could also include a callable sort package as well.d  9 As part of some other work I needed to do, I wrote a veryg> sophisticated ISAM record system that has features WELL beyondK RMS but includes most if not all RMS ISAM functionallity.  I am consideringdG making this into a developer kit for people needing such functionallityeD if there is an adequate need to justify the packaging work and being, available to support such a development kit.  G I would probably license it with or without sources depending on price.e> This software could easily be made to run in Kernel mode under6 Windows NT/2000 for Driver people who needed that kindA of functionallity.  (Actually, the same is true for VMS.)  I took-H great care to isolate out OS specific issues including memory allocationB so that I could use it in Kernel mode on Windows NT.  As a result,D porting it to other platforms would also be trivial.  The Windows OSI specific code stands at about 1200 lines including comments (the majoritye of the lines are comments).   ; The software is written in C and can also support VMS styleeE Variable Length Sequential files (different internal representation).V? Files can be "CONVERTED" to the new format using a utility thanrA runs under VMS.  VMS FDL files can be used to create these files.	B The appropriate translations are done and there are extensions forB the many features not in RMS that this software contains including3 quite a substantial number of additional data types   E It would also be possible if there is a reasonable interest in makingh; a 99% or so compatible API to the RMS interface supporttinge: the major sys$* functions RMS uses and the data structures  such as RABs, FABs, XABs, etc...  E The software would also work (not quite as well) for testing purposeso? under VMS and could be made easily to work very well under VMS.   @ You can respond to my email directly if you want with questions,B suggestions, or even features you think such software should have.     Rick Cadruvi...  rick@rdperf.comG   ------------------------------  # Date: Thu, 08 Feb 2001 22:22:03 GMTa' From: moi_is_me <moi_is_me@my-deja.com>m Subject: POSIX 1003.1 & 1003.2) Message-ID: <95v664$hlv$1@nnrp1.deja.com>n   Hi,     According to the FAQ at  G Http://www.openvms.compaq.com/solutions/government/coe/dii_COE_Faq.html   * OpenVMS will support POSIX 1003.1 & 1003.2  B However, trying to determine what POSIX 1003.1 & 1003.2 encompass, is a different matter.  A One site suggests that IEEE 1003.1-1996 includes .1b, .1c and .1ip= whereas another suggest that 1003.1b (formerly 1003.4) is NOT. part of 1003.1    A Without upsetting IEEE (dont want the whole doc), anybody care tou@ enlighten me as to what is included in POSIX 1003.1 & 1003.2 ???     TIAc   -Pierre        Sent via Deja.coma http://www.deja.com/   ------------------------------  # Date: Fri, 09 Feb 2001 02:56:51 GMT  From: vjthomas@my-deja.com: Subject: PreExpired password accounts get "File Not Found") Message-ID: <95vm9g$upp$1@nnrp1.deja.com>l   Hopefully a simple one. ) Just installed two Alphas running VMS 7.2s  0 Can login as system fine. Have an 8 user license/ pak installed one each. I created a user with ah- pre-expired password. When I login as the newi. user, enter the old password, then the new one twice, I get the message,r   File not found+ Please try again or press (CTRL/Y) to abort-  . Then it prompts me for the new password again.  
 Any ideas?0 (I used to consider myself a 9 out 10 in VMS but- haven't touched it for about 6 years (VMS 5).m+ It's slowly coming back to me. VERY SLOWLY).   THANKS!n     Sent via Deja.com  http://www.deja.com/   ------------------------------  # Date: Fri, 09 Feb 2001 02:56:53 GMT  From: vjthomas@my-deja.com: Subject: PreExpired password accounts get "File Not Found") Message-ID: <95vm9i$upr$1@nnrp1.deja.com>o   Hopefully a simple one.d) Just installed two Alphas running VMS 7.2f  0 Can login as system fine. Have an 8 user license/ pak installed one each. I created a user with al- pre-expired password. When I login as the newd. user, enter the old password, then the new one twice, I get the message,e   File not found+ Please try again or press (CTRL/Y) to abortg  . Then it prompts me for the new password again.  
 Any ideas?0 (I used to consider myself a 9 out 10 in VMS but- haven't touched it for about 6 years (VMS 5).@+ It's slowly coming back to me. VERY SLOWLY)    THANKS!e     Sent via Deja.com- http://www.deja.com/   ------------------------------  % Date: Thu, 08 Feb 2001 18:44:09 -0500!+ From: Rafael Ruiz <rafael.ruiz@omgroup.com>m( Subject: Question on time comparison....6 Message-ID: <C12569ED.008240F1.00@omext02.omgroup.com>   To whom it may concern,e  N Any tricks to compare the times of dir/time=(created,modified) and get the run time???    Regards,   Rafael Ruiz    ------------------------------  # Date: Fri, 09 Feb 2001 06:04:08 GMT ) From: "Rob Brown" <robbrown@shaw.wave.ca>8, Subject: Re: Question on time comparison....J Message-ID: <01c0925e$22cfd1c0$0f754718@cs918188-a.edmw1.ab.wave.home.com>  6 Rafael Ruiz <rafael.ruiz@omgroup.com> wrote in article- <C12569ED.008240F1.00@omext02.omgroup.com>...   H > Any tricks to compare the times of dir/time=(created,modified) and get the rund	 > time???.  I I seem to recall there are several DCL time manipulation command files at:E telnet://eisner.encompasserve.org/ in the VMS conference, topic 1270.    ------------------------------  $ Date: Thu, 8 Feb 2001 23:19:14 +0100+ From: "Fred A G" <nospam@allowed.localhost>@ Subject: Re: set character set? 5 Message-ID: <eXEg6.1061$It1.3624@nntpserver.swip.net>i  : "Phil Howell" <phowell@snowyhydro.com.au> wrote in message, news:fWlg6.3513$sS4.125922@ozemail.com.au... >a6 > Fred A G <nospam@allowed.localhost> wrote in message0 > news:Iskg6.808$It1.3358@nntpserver.swip.net...? > > I'm having some problems printing from VMS 7.2-1 via telnetn	 symbiont.oG > > The character symbols don't come out right (using only the standard F > > device control library). I guess the character set on the VMS side isF > > some DEC/VT variant, but how do I find out exactly which one? WhatE > > character set are usually available and how do I change it? Filese are1F > > edited over telnet sessions with Reflection emulator on the client side.n > >g* > What character symbols and what printer?  @ Well, almost any character with code 128-255 come out as another character at the printer end.C  < Printers vary, but most are different models of HP Laserjet.  E One HP has a language setting of "PC-8", very close to CP437 (IBM DOSrE US) but characters in the control code ranges, like the smiley faces,> seem to be left out.  ? I guess I'm really looking for what kind of support VMS has forf@ different character sets... (but perhaps DEC MCS could suffice).   >oE > You can find out exactly what the telnet symbiont is up to by using> > (from v7.2 doc)  (...)d  G The symbiont works as expected, i.e. the octets from a printed file are ! the same at the print server end.e   >d* > $ DEFINE /SYSTEM TCPIP$TELNETSYM_DEBUG 4 >e  @ Does TCPIP need to be bounced for this to "take", like with SMTPB debugging? The users are usually too busy for that to be possible.   Regards  /Fad   ------------------------------  $ Date: Thu, 8 Feb 2001 23:25:42 +0100+ From: "Fred A G" <nospam@allowed.localhost>o Subject: Re: set character set?T5 Message-ID: <i1Fg6.1067$It1.3875@nntpserver.swip.net>k  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3A81F74E.DFFC749C@videotron.ca... > Fred A G wrote:e? > > I'm having some problems printing from VMS 7.2-1 via telnet 	 symbiont.iG > > The character symbols don't come out right (using only the standardhF > > device control library). I guess the character set on the VMS side isA > > some DEC/VT variant, but how do I find out exactly which one?r >  >r) > Which symbols are you trying to print ?e  D Character symbols with code in the 128-255 range (the reverse telnet( printing is not the cause here, though).  ' > And where are the documents generated= > using what software ?= >=  H On the VMS side, by hosted application software or with EDIT. All "plain text" files.  = > Is the printer in postscript mode, or some HPCL variation ?:  & Could be PS, PCL or some line-printer.   Regards9 /Fad   ------------------------------   Date: 8 Feb 2001 16:01:54 -0500=2 From: young_r@eisner.encompasserve.org (Rob Young) Subject: Re: Status of EV73 Message-ID: <lVd0MOEhEE+V@eisner.encompasserve.org>a  < In article <95uuce01pb7@news2.newsguy.com>, TTK Ciar writes:  E >>Let's be fair here.  We know that the current Alpha works well, but E >>the EV7 is seriously delayed and is reported to have not moved with E >>the times (e.g. the 1.2 GHz version is reported to burn 125 watts).e >  >   This is very true. > F >   However, we do know that its computational cores are two 21264's, G > which suggests to us we should expect high performance, even if they -E > have not upgraded the compiler technology or its branch prediction . > logic. >   - 	Two cores?  You mean two memory controllers?t  F >   Can we really expect any processor based on the IA64 architecture J > to compare favorably to a modernized 21264?  I'm not trying to be flip, 5 > I'm really interested in hearing people's opinions.v >  	You mean 21264/21364/21464?  ; 	Depends.  Do you have to compare shipping prod to shippinge; 	prod?  Alpha is still winning.  Maybe Intel somehow speedsa< 	up IA64 deliverables and Alpha slips further, then "maybe."  9 	I wouldn't be too hopeful.  After all, Itanium is a 1998e 	part showing up 2H 2001:   G      http://www.zdnet.com/eweek/stories/general/0,11011,2683568,00.html-  O "Going back to '95, the expectation within the company was that [Itanium] wouldiM be out in 1998," said Gwennap, previously the publisher of the Microprocessor4O Report. "The public schedule was that the chip would be out by the end of 2000.:9 They've blown that. It's definitely way behind schedule."   > 	Looking at the title of that, it appears McKinley is slipping 	too:a  K "I think the big issue is that [McKinley] still hasn't taped out yet," said.G processor analyst Linley Gwennap, of the Linley Group, referring to thevM processor's design not being sent off for manufacturing, as was expected lateoB last year. "That's a big milestone for any particular processor."    				Rob    ------------------------------   Date: 8 Feb 2001 20:08:46 GMTt From: TTK Ciar Subject: Re: Status of EV7+ Message-ID: <95uuce01pb7@news2.newsguy.com>i  : Once upon a time, nmm1@cus.cam.ac.uk (Nick Maclaren) said:! >   Date: 8 Feb 2001 09:16:25 GMTn >>J >>> Who knows what the future holds.  We can all spread FUD.  For example,J >>> when those IA64 chips start rolling, don't you think Compaq would love* >>> to ditch the overhead of alpha design? >>E >>  Depends on whether Compaq wants a processor in their systems that ' >>works well (Alpha) or not (McKinley).o > D >Let's be fair here.  We know that the current Alpha works well, butD >the EV7 is seriously delayed and is reported to have not moved withD >the times (e.g. the 1.2 GHz version is reported to burn 125 watts).     This is very true.  D   However, we do know that its computational cores are two 21264's, E which suggests to us we should expect high performance, even if they uC have not upgraded the compiler technology or its branch prediction d logic.  D   Can we really expect any processor based on the IA64 architecture H to compare favorably to a modernized 21264?  I'm not trying to be flip, 3 I'm really interested in hearing people's opinions.i  C >Until it is released, we won't know if it delivers performance pror >rate to its power consumption.m  F   I'm not accustomed to seeing people talk about performance per unit C energy consumed outside the embedded industry.  Why is this metric e+ significant in the Alpha's intended market?o  B >Similarly, we don't yet know what the McKinley will do, though weD >may well have strong suspicions that the software problems that dogD >the Itanium will apply to it, unchanged, even if the chip works and' >can be clocked at its intended speeds.o  D   My thoughts exactly.  I'm honest enough to admit that I really do E not know, in the rigorous sense, that McKinley's performance will be  F low, but I do have strong expectations.  It will take an intellectual B feat of revolutionary proportions for HP's engineers to solve the F problems intrinsic to the IA64 architecture, and HP's engineers don't D strike me as the revolutionary types (though I will admit that they + know their compiler technology quite well).b     -- TTK   ------------------------------   Date: 8 Feb 2001 21:14:04 GMTi( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: Status of EV70 Message-ID: <95v26s$ib4$1@pegasus.csx.cam.ac.uk>  > In article <95uuce01pb7@news2.newsguy.com>,  <TTK Ciar> wrote: >oD >>Until it is released, we won't know if it delivers performance pro  >>rate to its power consumption. > G >  I'm not accustomed to seeing people talk about performance per unit cD >energy consumed outside the embedded industry.  Why is this metric , >significant in the Alpha's intended market?  E Take the University of Cambridge High Performance Computing Facility,nD as an example.  We have a fixed size of machine room, embedded in   = the middle of a building and not expandable.  Worse, the onlye> available roof space is now full up with cooling towers, so we# cannot expand our cooling capacity.   > Similarly, a lot of academic departments would like to installA small number-crunchers or clusters in existing rooms, and are notn@ able (or are unwilling) to provide extra (or often any) cooling.? Quite a lot of them have to downgrade their requirements simply-- because their favoured solution runs too hot.0  @ Power problems are nearly as important in HPC as in the embeddedA market, pace the Japanese installation that is having a dedicated8: power station built adjacent to the computer facility ....     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679:   ------------------------------   Date: 8 Feb 2001 21:19:26 GMTo( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: Status of EV70 Message-ID: <95v2gu$igl$1@pegasus.csx.cam.ac.uk>  3 In article <lVd0MOEhEE+V@eisner.encompasserve.org>,c3 Rob Young <young_r@eisner.encompasserve.org> wrote:- >aE >       Looking at the title of that, it appears McKinley is slippinga >	too: >tL >"I think the big issue is that [McKinley] still hasn't taped out yet," saidH >processor analyst Linley Gwennap, of the Linley Group, referring to theN >processor's design not being sent off for manufacturing, as was expected lateC >last year. "That's a big milestone for any particular processor." w  D One wonders how he is so sure - it may be a big milestone, but isn'tA necessarily publicised.  There was a rumour last year that it HAD E happened, but it was not confirmed.  One possibility is that HP/InteleA have actually made a few thousand and are testing them in boards,r5 but are holding back to avoid overtaking the Itanium.   3 All right, I don't believe it.  But it IS possible.-     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679    ------------------------------  $ Date: Thu, 8 Feb 2001 23:21:48 -0000& From: "Thomas Womack" <tom@womack.net> Subject: Re: Status of EV7. Message-ID: <95vc7i$ovl$2@news6.svr.pol.co.uk>   <TTK Ciar> wrote< > Once upon a time, nmm1@cus.cam.ac.uk (Nick Maclaren) said:  F > >Let's be fair here.  We know that the current Alpha works well, butF > >the EV7 is seriously delayed and is reported to have not moved withF > >the times (e.g. the 1.2 GHz version is reported to burn 125 watts). >. >   This is very true. > E >   However, we do know that its computational cores are two 21264's,SF > which suggests to us we should expect high performance, even if theyD > have not upgraded the compiler technology or its branch prediction > logic.  J Err, isn't the EV7/21364 'just' a 21264 at substantially higher clock rateJ with very large on-die caches (I can't remember whether they were Xeon-ishK L2 or PA8500-ish L1; at that clock rate I'd guess the former), eight RambusnF memory controllers and fast point-to-point interconnect? I thought theK multi-core technology was planned for the EV8, of whose launch date I don't  think anyone has a clue.  H I don't believe Compaq are doing complicated things with enormously longI pipelines, so there won't be the Pentium-4 absolute requirement for magicw branch prediction.  K Doesn't branch prediction rapidly reach the stage of requiring clairvoyancetJ in any case? A lot of the (number-theoretic number-crunching) problems I'mG doing, the irregular branches express the essential irregularity of thenE problem; predicting which branches are taken with any accuracy at alloH (beyond "about 1/p cases will pass stage one") would require solving the% whole non-trivial underlying problem.u  E I suppose on P4-class architectures I should be replacing lots of theeE branches by speculative computations of both sides and CMOVs, or SIMDnG calculation and masking, but it's not clear how possible that is, and I"# don't have the P4 to play with yet.a  E >   Can we really expect any processor based on the IA64 architecturehJ > to compare favourably to a modernised 21264?  I'm not trying to be flip,5 > I'm really interested in hearing people's opinions.g  I On really regular code, I would hope the IA64 could take advantage of thesK piles of functional units and win -- otherwise there was no point at all inIE the ten- (maybe even eleven-)figure expense involved in designing anda3 building the thing. Otherwise I'd bet on the 21264..  K I can't visualise a fully-out-of-order IA64 being anything other than a bignJ hairy Classic OOO RISC Engine with complicated decoder and trace cache; weK know Intel can build those, but I don't see why it would work better than af 128-register x86.u  E > >Until it is released, we won't know if it delivers performance pro-! > >rate to its power consumption.h >0G >   I'm not accustomed to seeing people talk about performance per unitcD > energy consumed outside the embedded industry.  Why is this metric- > significant in the Alpha's intended market?w  K There are cooling considerations, I suppose, but the 125 watts replaces notsJ just the CPU but also the memory controller and at least the local networkI interconnect; I'd guess a sweet spot would be eight EV7s with the networkEG links in a cube, on one large umpteen-layer motherboard covered in RIMM0K sockets. Not sure how much more power RDRAM uses than whatever an ES40 usesoL nowadays. A three-kilowatt 8-CPU 10GFLOP-sustained minicomputer doesn't seemE an unreasonable thing to keep in the corner of a well-air-conditioned. computer room.  J Nick: how much cooling do your current Hitachi and SGI machines require? ID suppose that once you get to liquid-cooled designs you have to startI thinking about purpose-built buildings with refrigeration infrastructure,eK but I'd have thought that an organisation with the wherewithal to procure a F 1024-way EV7 supercomputer will have room in the budget for a two-room( extension to some building to put it in.  G [and no variant of the IA64 has by any measure ever been described as acG low-power chip; you've seen the photos of the house-brick-sized voltage/ regulators for Itanium ...]t  I Tangentially, I read recently a Crusoe person talking about building MPPs9? (not obviously from context anything more than Beowulf-in-a-boxmG shared-nothing designs) out of their low-power processors to target theDG server-farm market. But this may have been nothing but an attempt to be . topical about the Californian power shortages.   Tomc   ------------------------------  % Date: Fri, 09 Feb 2001 00:29:58 +0000 ) From: Christof Brass <brass@infopuls.com>  Subject: Re: Status of EV7, Message-ID: <3A833A06.6E4BC04E@infopuls.com>   Bob Koehler wrote: > Z > In article <3A81C7A7.DFD84E93@infopuls.com>, Christof Brass <brass@infopuls.com> writes: > >a@ > > I heard that MIPS is selling incredible numbers of chips for > > game boxes.e > G > Nintendo 64 is a MIPS R4000.  Nothing new, but it works and it sells.  > H > ----------------------------------------------------------------------A > Bob Koehler                     | Computer Sciences Corporation ? > NASA GSFC Flight Software       | Federal Sector, Civil Group G >                                 | please remove ".aspm" when replying-   Sony's PS2?,   ------------------------------  $ Date: Thu, 8 Feb 2001 19:27:10 -0600$ From: "del cecchi" <dcecchi@msn.com> Subject: Re: Status of EV7) Message-ID: <OQ6H5djkAHA.339@cpmsnbbsa09>   J Got a system with a thousand nodes and it can't lose a few without falling over? Ouch.t  
 del cecchi  1 "Eric C. Fromm" <efromm@sgi.com> wrote in message-! news:3A82A8F5.AAF3DA48@sgi.com...1 > Michael Woodacre wrote:B > >  > > |>J > > |>      Yes, this is why EV7 has lockstep and NSK won't be the only OS toI > > |>      take advantage of lockstep.  Tru64 will too.  Perhaps that isr one.K > > |>      reason Compaq/Tru64 is winning all those supercomputer bids?  I> was I > > |>      almost shocked to learn ASCI White's mean uptime is one week.  Is> > > |>      that right?  Can't find that link... so maybe I am misremembering.a > > |> > > K > > Forgot to reply to this. At SC2000 in Dallas, after the presentation on- the-K > > new ASCI Q machine I asked the guy from LANL what the predicted MTBF of" thepK > > h/w for the system was and his reply was on the order of a few hours, I1 can't.I > > remember the exact amount but maybe I wrote it down somewhere, but itt was significantlyfH > > less than a day. Things get really exciting when you build these big systems.A > > We certainly learned a lot, I guess it's Compaqs turn now ;-)  >'L > Perhaps so. When you have a system with literally hundreds of thousands ofI > components and many millions of component connections, you have a wholei lotnK > of opportunities for something to break. When you do the math, it becomes G > clear that those really big systems can not attain the MTBFs that you I > expect and demand from your average departmental sever. Not unless very L > significant resources are committed to redundancy and resiliency features.L > Those don't come for free and in some cases imply some degree of trade-off# > with performance and/or capacity.t >e > -erice >C > --8 > Eric C. Fromm                           efromm@sgi.comC > Principal Engineer                      Scalable Systems Division = > SGI - Silicon Graphics, Inc.            Chippewa Falls, Wi.m   ------------------------------  % Date: Thu, 08 Feb 2001 23:55:05 -0500i# From: Paul DeMone <pdemone@igs.net>  Subject: Re: Status of EV7' Message-ID: <3A837829.A4C241D4@igs.net>a   Del Cecchi wrote:a > M > In article <y48zni4y2s.fsf_-_@mailhost.neuroinformatik.ruhr-uni-bochum.de>,tL >  Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:1 > |> young_r@eisner.decus.org (Rob Young) writes:T > |>I > |> >    Likewise, when the nasty "Alpha is dead" threads get going, onetJ > |> >    of the strongest arguments to squelch such nonesense is to point= > |> >    to Tandem coming over to Alpha >STARTING< with EV7., > |>Q > |> Which reminds me, Rob. I recently had a look at Bannon's presentation of thetK > |> EV7 (at MPF '98. IIRC). It stated "tapeout 4Q99". It's now almost fiveJ; > |> quarters later. So what has happened in the mean time?s  K A few days ago the word was EV7 would be released to manufacturing shortly,bL whatever that means. Unfortunately the "1 year rule" puts volume shipping at
 roughly 2Q02.t     > |>P > |> The timeline in that talk also had EV68 at 1+ GHz available in 2000. Duh... > |>
 > |>      Jan   K IBM-made copper bulk EV68's (120 mm2) are alive and well and AFAIK hardware J is at select customer sites. General release is imminent. I saw a shmoo ofJ one running at 1388 MHz at room temp, nom Vdd so initial speed grades will% likely be in the 1.0 - 1.2 GHz range.=     --D Paul W. DeMone       The 801 experiment SPARCed an ARMs race of EPICE Kanata, Ontario      proportions to put more PRECISION and POWER intocG demone@mosaid.com    architectures with MIPSed results but ALPHA's welln$ pdemone@igs.net      that ends well.   ------------------------------  % Date: Fri, 09 Feb 2001 00:01:29 -0500r# From: Paul DeMone <pdemone@igs.net>c Subject: Re: Status of EV7' Message-ID: <3A8379A9.2807883E@igs.net>o   Michael Woodacre wrote:1 > j > In article <g9pBNrzMFnl5@eisner.encompasserve.org>, young_r@eisner.encompasserve.org (Rob Young) writes:_ > |> In article <95s913$2hg8n$1@fido.engr.sgi.com>, woodacre@sgi.com (Michael Woodacre) writes:  > |> > |> >J > |> > Sorry to correct you Rob, but MIPS/IRIX has not reached end of lifeJ > |> > Check out http://www.sgi.com/developers/feature/2000/irix_mips.html > |> > > |>D > |>      I didn't say soon, did I?  But if SGI is transitioning offD > |>      of MIPS (note the "maybe" after R18K in the figure there),I > |>      it is only a matter of "when" , not "if."  Same could be arguedp > Q > Who knows what the future holds. We can all spread FUD, for example, when those S > IA64 chips start rolling, don't you think Compaq would love to ditch the overhead  > of alpha design?  J Or maybe they will just ramp down funding and starve the development groupC into mediocrity like SGI has done for about the last five years ;-)4  G IA-64 chips start rolling? LOL! The IA-64 boys can't even deliver theirh0 paper to ISSCC. Presentation 15.7 where are you?       --D Paul W. DeMone       The 801 experiment SPARCed an ARMs race of EPICE Kanata, Ontario      proportions to put more PRECISION and POWER intowG demone@mosaid.com    architectures with MIPSed results but ALPHA's wellu$ pdemone@igs.net      that ends well.   ------------------------------  % Date: Thu, 08 Feb 2001 22:08:34 +0000 % From: Alan Greig <a.greig@virgin.net> . Subject: Re: Suggested upgrade to VMS (DECnet)* Message-ID: <3A8318E2.E35F5C57@virgin.net>   "antonio.carlini" wrote:   > "David J. Dachtera" wrote:L > > Actually, what I'd like to see is a "management layer" on top of all theH > > NCL and other nonsense. We need a way to do things (so it's actually; > > POSSIBLE!) that doesn't get in the way of productivity.r >y0 > I was told (a few years ago) that the original3 > plan was to have a GUI front end to NCL (possiblyt  > a cut down version of DECmcc). > 7 > Obviously this never happened ... whether it ever wasn# > a real plan or not, I don't know.i >M  L I believe it said this somewhere in the original DECNET VAX Extensions earlyG Phase V release documentation. I remember when that extremely large boxhK arrived and my horror when I discovered that it really was full of manuals.a What? Just for DECNET!...    --
 Alan Greig   ------------------------------  # Date: Thu, 08 Feb 2001 19:12:09 GMT & From: "Rick Cadruvi" <rick@rdperf.com>+ Subject: Re: The "deleting many files" myth,9 Message-ID: <dcCg6.1596$Li7.173824@dfiatx1-snr1.gtei.net>   2 The fastest way to delete a large directory is to:  &     $ dir/column=1 [dir-spec] /out=t.t.     $ edit t.t        ! remove the extra lines2     $ dir/full t.t    ! Get size of longest recordG     $ sort t.t t.t /key=(pos:1, size:longest-record-length, char, desc)e  C Now write a simple DCL procedure to read "t.t" and delete each filee
 individually.a  I This will do the delete VERY fast.  When you delete records from the end,n all2 the overhead goes away.b  E I have my own DCL utility that does this somewhere.  If actually usesi f$search to produce the file to sort.   just my opnion,r   Rick Cadruvi...r  B "Ian Burgess" <ccburgess@uqstu.jdstory.uq.edu.au> wrote in message( news:95sp1l$d99$1@bunyip.cc.uq.edu.au...C > A rogue system, that shall remain nameless to protect the guilty,p3 > madly created 280,000 files before we stopped it.oE > The resulting directory size was 28,000 blocks (maybe an unenviables	 record!).o. > It has taken two days to delete the files... >o; > Anyway the point of this message is the frequently asked,t@ > "What is the quickest way to delete a large number of files?". >o? > I deleted four files at the end of the directory, and it tookc
 > 20 seconds.m >e< > Repeating the command, took the same time, just giving the) > "file not found" at 5 second intervals.  >pF > Deleting *.*/log  showed a pattern of deleting 10 files in 5 seconds > then a pause of 5 seconds. > G > So it looks like it is about as fast to shuffle out an empty block ase6 > it is to find the last file in a directory that big! >KL > So the generally accepted wisdom of sorting a directory listing in reverseF > order and deleting from the end of the directory is NOT a good idea! >9G > In the end I just submitted a batch job to delete *.trc;1 and watcheduC > the size of the directory decrease (by 3 blocks/minute at 28,000, 7 > 22/min at 13,000 and so on!).  Took a couple of days.m >o
 > Ian Burgessn > University of Queensland > I.Burgess@its.uq.edu.aue > www.its.uq.edu.aus   ------------------------------  # Date: Thu, 08 Feb 2001 19:32:06 GMT * From: Alan E. Feldman <alan48@my-deja.com>+ Subject: Re: The "deleting many files" mythn) Message-ID: <95us7m$8vt$1@nnrp1.deja.com>e  ) In article <3A82C716.CDF23F4A@Omond.net>,i"   Roy Omond <Roy@Omond.net> wrote: > "Alan E. Feldman" wrote: > . > > In article <95uca5$djr@usenet.pa.dec.com>, > >   "Dan" <x> wrote: > > > I've found thati+ > > >         BACKUP *.*;*/DELETE NL:./SAVEl* > > > seems to be faster than DELETE *.*;* > >s; > > This is much faster than delete, but add/GROUP=0/NOCRC.p > >e= > > The fastest I know of is to get DFU from the Freeware CD.n > >  > > >eC > > > (But don't take this as advice, I'm no VMS expert.  For all I  know,r > > thee! > > > above could be disastrous.)h > > >d > >a	 > > Nope.t >JC > *sigh* ... I really wish people would stop propagating this myth.  >aE > If the files you are deleting are of any significant size, then therF > backup to the null device might dominate the time taken (intuitively@ > obvious IMHO).  The best way is indeed, as others have already  F If, ... *IF* *IF* *IF*!!!, What if *not*?! Usually the files are quiteA small. And if they are very large, (Okay, I forgot this step) runa       $ SET FILE/NOBACKUP *.*;*   F first. Then run the BACKUP/DELETE command. And I find it is rarely theE case that there are so many large files. In fact, if you have so many.F files that they create a 28000 block directory, how large could any ofB them even be!!! Certainly the average size wouldn't be very large.  E > If the files you are deleting are of any significant size, then the,F > backup to the null device might dominate the time taken (intuitively@ > obvious IMHO).  The best way is indeed, as others have alreadyC > ponted out, to use DFU (though the difference in time has reduced   D It is intuitively obvious that you can't read. As is plainly visibleC above, I mentioned DFU in my post as being the best method short ofs initializing the disk.  B > considerably with VMS 7.2 since the block-shuffle is done, ahem, > rather more efficiently).   E Has anyone actually tested that? It may indeed be so, but I'd like tob see a test.u   >IF > If you don't use DFU, then it's a simple exercise to generate a listA > sorted in reverse alphabetic order and to delete (I'm sure HeinG: > van den Heuvel "Mister RMS" posted just such a procedure: > to minimise the number of image activations of DELETE in' > this newsgroup within the last year).r  E It is exactly this method that the original poster claims is no good,-G at least for his 28000-block .DIR file. I have never used this reverse- F DELETE method and therefore will not comment on how well it works. ButG I will say that in the days when I didn't have DFU, BACKUP/DELETE was a E big help to get rid of huge numbers of files. And it always went much1 faster than DELETE *.*;*.t   --F NOTE: If you wish to e-mail me, please do NOT use the deja address. ItD is not a valid address. Instead, use the address below, removing the long wrong part first. Thanks.   Disclaimer: JMHO Alan E. Feldman  &-)( afeldman@gfigroup.ButItSaidItPrinted.com     Sent via Deja.comt http://www.deja.com/   ------------------------------  $ Date: Thu, 8 Feb 2001 15:06:54 -0500- From: "Peter Weaver" <peter.weaver@stelco.ca>2+ Subject: Re: The "deleting many files" myths4 Message-ID: <_%Cg6.129302$Z2.1659372@nnrp1.uunet.ca>  7 "Alan E. Feldman" <alan48@my-deja.com> wrote in messaget# news:95us7m$8vt$1@nnrp1.deja.com... + > In article <3A82C716.CDF23F4A@Omond.net>,a >...D > > considerably with VMS 7.2 since the block-shuffle is done, ahem, > > rather more efficiently).' >eD > Has anyone actually tested that? It may indeed be so, but I'd like to
 > see a test.i >...    D Here is a test I ran the other day on an ES40 running VMS 7.2-1. The disks are on a HSG80;u  > Doing standard delete...   5-FEB-2001 14:52:47.23   5-FEB-2001 15:05:05> Doing reverse delete...    5-FEB-2001 15:46:04.01   5-FEB-2001 15:52:03> Doing standard delete...   5-FEB-2001 16:34:17.02   5-FEB-2001 16:46:59> Doing reverse delete...    5-FEB-2001 17:28:04.94   5-FEB-2001 17:34:22> Doing standard delete...   5-FEB-2001 18:21:01.40   5-FEB-2001 18:33:23> Doing reverse delete...    5-FEB-2001 19:19:56.08   5-FEB-2001 19:26:17> Doing standard delete...   5-FEB-2001 20:06:24.90   5-FEB-2001 20:18:44> Doing reverse delete...    5-FEB-2001 20:57:28.89   5-FEB-2001 21:03:42> Doing standard delete...   5-FEB-2001 21:48:17.15   5-FEB-2001 22:00:20> Doing reverse delete...    5-FEB-2001 22:43:44.40   5-FEB-2001 22:49:55    * Here are the procedures I used to do this;  
 $ ty *.com  ' $1$DGA100:[TEST-DIR]CREATE_FILES.COM;11o   $! $ set nover- $ set proc/prio=5s $! $ x=0t $!9 $ write sys$output "Starting to create files ''f$time()'"i $! $loop: $! $ y = 65 $! $loop2:t $! $ alpha[0,8] = 'y22 $ time = "''f$cvtime(,,"time")'" - ":" - ":" - ".". $ copy create_files.com 'alpha'_'x'_'time'.tmp $ y = y + 1g $ if y .lt. 91 then goto loop2 $! $ x = x + 1  $! $ if x .lt. 1000 then goto loop' $!7 $ write sys$output "Copying *.*;1 to *.*;2 ''f$time()'"  $! $ copy *.tmp;1 *.*;2 $!7 $ write sys$output "Copying *.*;1 to *.*;3 ''f$time()'"p $! $ copy *.tmp;1 *.*;3 $! $ dir [-]*.dir/siz=all $ directory/toto $ directory/tot/ver=1c $!. $ if "''p1'" .nes. "" then goto reverse_delete $!9 $ write sys$output "Doing standard delete... ''f$time()'"t# $ delete/nolog/noconfirm A_0*.tmp;*s# $ delete/nolog/noconfirm A_1*.tmp;*e# $ delete/nolog/noconfirm A_2*.tmp;*o# $ delete/nolog/noconfirm A_3*.tmp;*n# $ delete/nolog/noconfirm A_4*.tmp;*e# $ delete/nolog/noconfirm A_5*.tmp;*e# $ delete/nolog/noconfirm A_6*.tmp;* # $ delete/nolog/noconfirm A_7*.tmp;*R# $ delete/nolog/noconfirm A_8*.tmp;* # $ delete/nolog/noconfirm A_9*.tmp;*0# $ delete/nolog/noconfirm B_0*.tmp;*C# $ delete/nolog/noconfirm B_1*.tmp;*s# $ delete/nolog/noconfirm B_2*.tmp;*e# $ delete/nolog/noconfirm B_3*.tmp;*o# $ delete/nolog/noconfirm B_4*.tmp;*h# $ delete/nolog/noconfirm B_5*.tmp;*S# $ delete/nolog/noconfirm B_6*.tmp;*o# $ delete/nolog/noconfirm B_7*.tmp;*y# $ delete/nolog/noconfirm B_8*.tmp;*o# $ delete/nolog/noconfirm B_9*.tmp;* # $ delete/nolog/noconfirm C_0*.tmp;*t# $ delete/nolog/noconfirm C_1*.tmp;*i# $ delete/nolog/noconfirm C_2*.tmp;*r# $ delete/nolog/noconfirm C_3*.tmp;* # $ delete/nolog/noconfirm C_4*.tmp;*l# $ delete/nolog/noconfirm C_5*.tmp;* # $ delete/nolog/noconfirm C_6*.tmp;*e# $ delete/nolog/noconfirm C_7*.tmp;*o# $ delete/nolog/noconfirm C_8*.tmp;*c# $ delete/nolog/noconfirm C_9*.tmp;*i# $ delete/nolog/noconfirm D_0*.tmp;*n# $ delete/nolog/noconfirm D_1*.tmp;*l# $ delete/nolog/noconfirm D_2*.tmp;*x# $ delete/nolog/noconfirm D_3*.tmp;*m# $ delete/nolog/noconfirm D_4*.tmp;*r# $ delete/nolog/noconfirm D_5*.tmp;* # $ delete/nolog/noconfirm D_6*.tmp;* # $ delete/nolog/noconfirm D_7*.tmp;*o# $ delete/nolog/noconfirm D_8*.tmp;*r# $ delete/nolog/noconfirm D_9*.tmp;*-# $ delete/nolog/noconfirm E_0*.tmp;*0# $ delete/nolog/noconfirm E_1*.tmp;*<# $ delete/nolog/noconfirm E_2*.tmp;*a# $ delete/nolog/noconfirm E_3*.tmp;*B# $ delete/nolog/noconfirm E_4*.tmp;*t# $ delete/nolog/noconfirm E_5*.tmp;*9# $ delete/nolog/noconfirm E_6*.tmp;*s# $ delete/nolog/noconfirm E_7*.tmp;*e# $ delete/nolog/noconfirm E_8*.tmp;*u# $ delete/nolog/noconfirm E_9*.tmp;* # $ delete/nolog/noconfirm F_0*.tmp;*o# $ delete/nolog/noconfirm F_1*.tmp;* # $ delete/nolog/noconfirm F_2*.tmp;*-# $ delete/nolog/noconfirm F_3*.tmp;*-# $ delete/nolog/noconfirm F_4*.tmp;* # $ delete/nolog/noconfirm F_5*.tmp;*A# $ delete/nolog/noconfirm F_6*.tmp;*a# $ delete/nolog/noconfirm F_7*.tmp;* # $ delete/nolog/noconfirm F_8*.tmp;*.# $ delete/nolog/noconfirm F_9*.tmp;* # $ delete/nolog/noconfirm G_0*.tmp;*a# $ delete/nolog/noconfirm G_1*.tmp;*r# $ delete/nolog/noconfirm G_2*.tmp;*u# $ delete/nolog/noconfirm G_3*.tmp;* # $ delete/nolog/noconfirm G_4*.tmp;* # $ delete/nolog/noconfirm G_5*.tmp;* # $ delete/nolog/noconfirm G_6*.tmp;*r# $ delete/nolog/noconfirm G_7*.tmp;*o# $ delete/nolog/noconfirm G_8*.tmp;*-# $ delete/nolog/noconfirm G_9*.tmp;* # $ delete/nolog/noconfirm H_0*.tmp;* # $ delete/nolog/noconfirm H_1*.tmp;*h# $ delete/nolog/noconfirm H_2*.tmp;* # $ delete/nolog/noconfirm H_3*.tmp;* # $ delete/nolog/noconfirm H_4*.tmp;*h# $ delete/nolog/noconfirm H_5*.tmp;*a# $ delete/nolog/noconfirm H_6*.tmp;*p# $ delete/nolog/noconfirm H_7*.tmp;*o# $ delete/nolog/noconfirm H_8*.tmp;* # $ delete/nolog/noconfirm H_9*.tmp;* # $ delete/nolog/noconfirm I_0*.tmp;*s# $ delete/nolog/noconfirm I_1*.tmp;*># $ delete/nolog/noconfirm I_2*.tmp;*A# $ delete/nolog/noconfirm I_3*.tmp;*a# $ delete/nolog/noconfirm I_4*.tmp;*e# $ delete/nolog/noconfirm I_5*.tmp;*r# $ delete/nolog/noconfirm I_6*.tmp;*h# $ delete/nolog/noconfirm I_7*.tmp;* # $ delete/nolog/noconfirm I_8*.tmp;* # $ delete/nolog/noconfirm I_9*.tmp;* # $ delete/nolog/noconfirm J_0*.tmp;* # $ delete/nolog/noconfirm J_1*.tmp;*T# $ delete/nolog/noconfirm J_2*.tmp;*i# $ delete/nolog/noconfirm J_3*.tmp;*n# $ delete/nolog/noconfirm J_4*.tmp;*s# $ delete/nolog/noconfirm J_5*.tmp;*n# $ delete/nolog/noconfirm J_6*.tmp;*d# $ delete/nolog/noconfirm J_7*.tmp;*d# $ delete/nolog/noconfirm J_8*.tmp;*n# $ delete/nolog/noconfirm J_9*.tmp;*r# $ delete/nolog/noconfirm K_0*.tmp;* # $ delete/nolog/noconfirm K_1*.tmp;* # $ delete/nolog/noconfirm K_2*.tmp;* # $ delete/nolog/noconfirm K_3*.tmp;*a# $ delete/nolog/noconfirm K_4*.tmp;*t# $ delete/nolog/noconfirm K_5*.tmp;*c# $ delete/nolog/noconfirm K_6*.tmp;*a# $ delete/nolog/noconfirm K_7*.tmp;* # $ delete/nolog/noconfirm K_8*.tmp;* # $ delete/nolog/noconfirm K_9*.tmp;*h# $ delete/nolog/noconfirm L_0*.tmp;* # $ delete/nolog/noconfirm L_1*.tmp;* # $ delete/nolog/noconfirm L_2*.tmp;* # $ delete/nolog/noconfirm L_3*.tmp;* # $ delete/nolog/noconfirm L_4*.tmp;* # $ delete/nolog/noconfirm L_5*.tmp;*h# $ delete/nolog/noconfirm L_6*.tmp;*-# $ delete/nolog/noconfirm L_7*.tmp;*0# $ delete/nolog/noconfirm L_8*.tmp;* # $ delete/nolog/noconfirm L_9*.tmp;*u# $ delete/nolog/noconfirm M_0*.tmp;*1# $ delete/nolog/noconfirm M_1*.tmp;* # $ delete/nolog/noconfirm M_2*.tmp;*l# $ delete/nolog/noconfirm M_3*.tmp;*d# $ delete/nolog/noconfirm M_4*.tmp;*t# $ delete/nolog/noconfirm M_5*.tmp;*w# $ delete/nolog/noconfirm M_6*.tmp;* # $ delete/nolog/noconfirm M_7*.tmp;* # $ delete/nolog/noconfirm M_8*.tmp;*a# $ delete/nolog/noconfirm M_9*.tmp;* # $ delete/nolog/noconfirm N_0*.tmp;* # $ delete/nolog/noconfirm N_1*.tmp;* # $ delete/nolog/noconfirm N_2*.tmp;*I# $ delete/nolog/noconfirm N_3*.tmp;*n# $ delete/nolog/noconfirm N_4*.tmp;*B# $ delete/nolog/noconfirm N_5*.tmp;*7# $ delete/nolog/noconfirm N_6*.tmp;*u# $ delete/nolog/noconfirm N_7*.tmp;*q# $ delete/nolog/noconfirm N_8*.tmp;*n# $ delete/nolog/noconfirm N_9*.tmp;*e# $ delete/nolog/noconfirm O_0*.tmp;*n# $ delete/nolog/noconfirm O_1*.tmp;*e# $ delete/nolog/noconfirm O_2*.tmp;*p# $ delete/nolog/noconfirm O_3*.tmp;*t# $ delete/nolog/noconfirm O_4*.tmp;* # $ delete/nolog/noconfirm O_5*.tmp;*e# $ delete/nolog/noconfirm O_6*.tmp;* # $ delete/nolog/noconfirm O_7*.tmp;*m# $ delete/nolog/noconfirm O_8*.tmp;*w# $ delete/nolog/noconfirm O_9*.tmp;*n# $ delete/nolog/noconfirm P_0*.tmp;*o# $ delete/nolog/noconfirm P_1*.tmp;* # $ delete/nolog/noconfirm P_2*.tmp;* # $ delete/nolog/noconfirm P_3*.tmp;*r# $ delete/nolog/noconfirm P_4*.tmp;*T# $ delete/nolog/noconfirm P_5*.tmp;*e# $ delete/nolog/noconfirm P_6*.tmp;*t# $ delete/nolog/noconfirm P_7*.tmp;*i# $ delete/nolog/noconfirm P_8*.tmp;*r# $ delete/nolog/noconfirm P_9*.tmp;*l# $ delete/nolog/noconfirm Q_0*.tmp;*l# $ delete/nolog/noconfirm Q_1*.tmp;* # $ delete/nolog/noconfirm Q_2*.tmp;*0# $ delete/nolog/noconfirm Q_3*.tmp;*t# $ delete/nolog/noconfirm Q_4*.tmp;*g# $ delete/nolog/noconfirm Q_5*.tmp;* # $ delete/nolog/noconfirm Q_6*.tmp;*t# $ delete/nolog/noconfirm Q_7*.tmp;*v# $ delete/nolog/noconfirm Q_8*.tmp;*o# $ delete/nolog/noconfirm Q_9*.tmp;*l# $ delete/nolog/noconfirm R_0*.tmp;* # $ delete/nolog/noconfirm R_1*.tmp;*r# $ delete/nolog/noconfirm R_2*.tmp;* # $ delete/nolog/noconfirm R_3*.tmp;*t# $ delete/nolog/noconfirm R_4*.tmp;*t# $ delete/nolog/noconfirm R_5*.tmp;*e# $ delete/nolog/noconfirm R_6*.tmp;* # $ delete/nolog/noconfirm R_7*.tmp;*t# $ delete/nolog/noconfirm R_8*.tmp;* # $ delete/nolog/noconfirm R_9*.tmp;*K# $ delete/nolog/noconfirm S_0*.tmp;*i# $ delete/nolog/noconfirm S_1*.tmp;* # $ delete/nolog/noconfirm S_2*.tmp;*w# $ delete/nolog/noconfirm S_3*.tmp;*p# $ delete/nolog/noconfirm S_4*.tmp;* # $ delete/nolog/noconfirm S_5*.tmp;*h# $ delete/nolog/noconfirm S_6*.tmp;*e# $ delete/nolog/noconfirm S_7*.tmp;*e# $ delete/nolog/noconfirm S_8*.tmp;* # $ delete/nolog/noconfirm S_9*.tmp;*d# $ delete/nolog/noconfirm T_0*.tmp;*h# $ delete/nolog/noconfirm T_1*.tmp;* # $ delete/nolog/noconfirm T_2*.tmp;*n# $ delete/nolog/noconfirm T_3*.tmp;*C# $ delete/nolog/noconfirm T_4*.tmp;* # $ delete/nolog/noconfirm T_5*.tmp;*e# $ delete/nolog/noconfirm T_6*.tmp;*C# $ delete/nolog/noconfirm T_7*.tmp;* # $ delete/nolog/noconfirm T_8*.tmp;*e# $ delete/nolog/noconfirm T_9*.tmp;* # $ delete/nolog/noconfirm U_0*.tmp;*m# $ delete/nolog/noconfirm U_1*.tmp;*-# $ delete/nolog/noconfirm U_2*.tmp;* # $ delete/nolog/noconfirm U_3*.tmp;*m# $ delete/nolog/noconfirm U_4*.tmp;*u# $ delete/nolog/noconfirm U_5*.tmp;*D# $ delete/nolog/noconfirm U_6*.tmp;*7# $ delete/nolog/noconfirm U_7*.tmp;*t# $ delete/nolog/noconfirm U_8*.tmp;* # $ delete/nolog/noconfirm U_9*.tmp;* # $ delete/nolog/noconfirm V_0*.tmp;* # $ delete/nolog/noconfirm V_1*.tmp;* # $ delete/nolog/noconfirm V_2*.tmp;* # $ delete/nolog/noconfirm V_3*.tmp;*w# $ delete/nolog/noconfirm V_4*.tmp;*d# $ delete/nolog/noconfirm V_5*.tmp;* # $ delete/nolog/noconfirm V_6*.tmp;* # $ delete/nolog/noconfirm V_7*.tmp;*o# $ delete/nolog/noconfirm V_8*.tmp;*r# $ delete/nolog/noconfirm V_9*.tmp;* # $ delete/nolog/noconfirm W_0*.tmp;*M# $ delete/nolog/noconfirm W_1*.tmp;*i# $ delete/nolog/noconfirm W_2*.tmp;*e# $ delete/nolog/noconfirm W_3*.tmp;*I# $ delete/nolog/noconfirm W_4*.tmp;*o# $ delete/nolog/noconfirm W_5*.tmp;*o# $ delete/nolog/noconfirm W_6*.tmp;*a# $ delete/nolog/noconfirm W_7*.tmp;*-# $ delete/nolog/noconfirm W_8*.tmp;*-# $ delete/nolog/noconfirm W_9*.tmp;*:# $ delete/nolog/noconfirm X_0*.tmp;*k# $ delete/nolog/noconfirm X_1*.tmp;*i# $ delete/nolog/noconfirm X_2*.tmp;*C# $ delete/nolog/noconfirm X_3*.tmp;*n# $ delete/nolog/noconfirm X_4*.tmp;*a# $ delete/nolog/noconfirm X_5*.tmp;*u# $ delete/nolog/noconfirm X_6*.tmp;*t# $ delete/nolog/noconfirm X_7*.tmp;* # $ delete/nolog/noconfirm X_8*.tmp;*g# $ delete/nolog/noconfirm X_9*.tmp;*p# $ delete/nolog/noconfirm Y_0*.tmp;*r# $ delete/nolog/noconfirm Y_1*.tmp;*o# $ delete/nolog/noconfirm Y_2*.tmp;*f# $ delete/nolog/noconfirm Y_3*.tmp;*t# $ delete/nolog/noconfirm Y_4*.tmp;* # $ delete/nolog/noconfirm Y_5*.tmp;*r# $ delete/nolog/noconfirm Y_6*.tmp;* # $ delete/nolog/noconfirm Y_7*.tmp;* # $ delete/nolog/noconfirm Y_8*.tmp;*t# $ delete/nolog/noconfirm Y_9*.tmp;* # $ delete/nolog/noconfirm Z_0*.tmp;*c# $ delete/nolog/noconfirm Z_1*.tmp;*t# $ delete/nolog/noconfirm Z_2*.tmp;*p# $ delete/nolog/noconfirm Z_3*.tmp;*h# $ delete/nolog/noconfirm Z_4*.tmp;*h# $ delete/nolog/noconfirm Z_5*.tmp;*i# $ delete/nolog/noconfirm Z_6*.tmp;*u# $ delete/nolog/noconfirm Z_7*.tmp;*s# $ delete/nolog/noconfirm Z_8*.tmp;* # $ delete/nolog/noconfirm Z_9*.tmp;*i $ show time  $! $ goto doneo $! $reverse_delete: $!8 $ write sys$output "Doing reverse delete... ''f$time()'"# $ delete/nolog/noconfirm Z_9*.tmp;*e# $ delete/nolog/noconfirm Z_8*.tmp;*o# $ delete/nolog/noconfirm Z_7*.tmp;* # $ delete/nolog/noconfirm Z_6*.tmp;*e# $ delete/nolog/noconfirm Z_5*.tmp;*o# $ delete/nolog/noconfirm Z_4*.tmp;*e# $ delete/nolog/noconfirm Z_3*.tmp;*e# $ delete/nolog/noconfirm Z_2*.tmp;*a# $ delete/nolog/noconfirm Z_1*.tmp;*k# $ delete/nolog/noconfirm Z_0*.tmp;* # $ delete/nolog/noconfirm Y_9*.tmp;*n# $ delete/nolog/noconfirm Y_8*.tmp;*i# $ delete/nolog/noconfirm Y_7*.tmp;*i# $ delete/nolog/noconfirm Y_6*.tmp;*n# $ delete/nolog/noconfirm Y_5*.tmp;*h# $ delete/nolog/noconfirm Y_4*.tmp;*i# $ delete/nolog/noconfirm Y_3*.tmp;*e# $ delete/nolog/noconfirm Y_2*.tmp;*a# $ delete/nolog/noconfirm Y_1*.tmp;*e# $ delete/nolog/noconfirm Y_0*.tmp;* # $ delete/nolog/noconfirm X_9*.tmp;*o# $ delete/nolog/noconfirm X_8*.tmp;*s# $ delete/nolog/noconfirm X_7*.tmp;*u# $ delete/nolog/noconfirm X_6*.tmp;*u# $ delete/nolog/noconfirm X_5*.tmp;*-# $ delete/nolog/noconfirm X_4*.tmp;*M# $ delete/nolog/noconfirm X_3*.tmp;*d# $ delete/nolog/noconfirm X_2*.tmp;*m# $ delete/nolog/noconfirm X_1*.tmp;*$# $ delete/nolog/noconfirm X_0*.tmp;*<# $ delete/nolog/noconfirm W_9*.tmp;* # $ delete/nolog/noconfirm W_8*.tmp;* # $ delete/nolog/noconfirm W_7*.tmp;*e# $ delete/nolog/noconfirm W_6*.tmp;* # $ delete/nolog/noconfirm W_5*.tmp;*t# $ delete/nolog/noconfirm W_4*.tmp;*T# $ delete/nolog/noconfirm W_3*.tmp;*r# $ delete/nolog/noconfirm W_2*.tmp;* # $ delete/nolog/noconfirm W_1*.tmp;*P# $ delete/nolog/noconfirm W_0*.tmp;*n# $ delete/nolog/noconfirm V_9*.tmp;* # $ delete/nolog/noconfirm V_8*.tmp;*t# $ delete/nolog/noconfirm V_7*.tmp;*.# $ delete/nolog/noconfirm V_6*.tmp;* # $ delete/nolog/noconfirm V_5*.tmp;* # $ delete/nolog/noconfirm V_4*.tmp;*r# $ delete/nolog/noconfirm V_3*.tmp;*i# $ delete/nolog/noconfirm V_2*.tmp;*u# $ delete/nolog/noconfirm V_1*.tmp;*s# $ delete/nolog/noconfirm V_0*.tmp;*d# $ delete/nolog/noconfirm U_9*.tmp;*i# $ delete/nolog/noconfirm U_8*.tmp;*t# $ delete/nolog/noconfirm U_7*.tmp;*y# $ delete/nolog/noconfirm U_6*.tmp;*f# $ delete/nolog/noconfirm U_5*.tmp;* # $ delete/nolog/noconfirm U_4*.tmp;*k# $ delete/nolog/noconfirm U_3*.tmp;* # $ delete/nolog/noconfirm U_2*.tmp;*e# $ delete/nolog/noconfirm U_1*.tmp;*I# $ delete/nolog/noconfirm U_0*.tmp;*r# $ delete/nolog/noconfirm T_9*.tmp;*f# $ delete/nolog/noconfirm T_8*.tmp;*r# $ delete/nolog/noconfirm T_7*.tmp;*g# $ delete/nolog/noconfirm T_6*.tmp;*i# $ delete/nolog/noconfirm T_5*.tmp;* # $ delete/nolog/noconfirm T_4*.tmp;*t# $ delete/nolog/noconfirm T_3*.tmp;* # $ delete/nolog/noconfirm T_2*.tmp;*h# $ delete/nolog/noconfirm T_1*.tmp;*y# $ delete/nolog/noconfirm T_0*.tmp;*n# $ delete/nolog/noconfirm S_9*.tmp;*d# $ delete/nolog/noconfirm S_8*.tmp;*c# $ delete/nolog/noconfirm S_7*.tmp;*t# $ delete/nolog/noconfirm S_6*.tmp;* # $ delete/nolog/noconfirm S_5*.tmp;*d# $ delete/nolog/noconfirm S_4*.tmp;*h# $ delete/nolog/noconfirm S_3*.tmp;* # $ delete/nolog/noconfirm S_2*.tmp;*h# $ delete/nolog/noconfirm S_1*.tmp;*h# $ delete/nolog/noconfirm S_0*.tmp;*a# $ delete/nolog/noconfirm R_9*.tmp;* # $ delete/nolog/noconfirm R_8*.tmp;* # $ delete/nolog/noconfirm R_7*.tmp;* # $ delete/nolog/noconfirm R_6*.tmp;* # $ delete/nolog/noconfirm R_5*.tmp;*a# $ delete/nolog/noconfirm R_4*.tmp;*e# $ delete/nolog/noconfirm R_3*.tmp;*h# $ delete/nolog/noconfirm R_2*.tmp;*r# $ delete/nolog/noconfirm R_1*.tmp;* # $ delete/nolog/noconfirm R_0*.tmp;*r# $ delete/nolog/noconfirm Q_9*.tmp;*e# $ delete/nolog/noconfirm Q_8*.tmp;* # $ delete/nolog/noconfirm Q_7*.tmp;*e# $ delete/nolog/noconfirm Q_6*.tmp;*E# $ delete/nolog/noconfirm Q_5*.tmp;*m# $ delete/nolog/noconfirm Q_4*.tmp;*l# $ delete/nolog/noconfirm Q_3*.tmp;*a# $ delete/nolog/noconfirm Q_2*.tmp;*p# $ delete/nolog/noconfirm Q_1*.tmp;* # $ delete/nolog/noconfirm Q_0*.tmp;* # $ delete/nolog/noconfirm P_9*.tmp;*s# $ delete/nolog/noconfirm P_8*.tmp;* # $ delete/nolog/noconfirm P_7*.tmp;*e# $ delete/nolog/noconfirm P_6*.tmp;*e# $ delete/nolog/noconfirm P_5*.tmp;*a# $ delete/nolog/noconfirm P_4*.tmp;*d# $ delete/nolog/noconfirm P_3*.tmp;*I# $ delete/nolog/noconfirm P_2*.tmp;* # $ delete/nolog/noconfirm P_1*.tmp;*-# $ delete/nolog/noconfirm P_0*.tmp;*2# $ delete/nolog/noconfirm O_9*.tmp;*e# $ delete/nolog/noconfirm O_8*.tmp;*:# $ delete/nolog/noconfirm O_7*.tmp;* # $ delete/nolog/noconfirm O_6*.tmp;*n# $ delete/nolog/noconfirm O_5*.tmp;*a# $ delete/nolog/noconfirm O_4*.tmp;* # $ delete/nolog/noconfirm O_3*.tmp;* # $ delete/nolog/noconfirm O_2*.tmp;*.# $ delete/nolog/noconfirm O_1*.tmp;*M# $ delete/nolog/noconfirm O_0*.tmp;*,# $ delete/nolog/noconfirm N_9*.tmp;*'# $ delete/nolog/noconfirm N_8*.tmp;*a# $ delete/nolog/noconfirm N_7*.tmp;* # $ delete/nolog/noconfirm N_6*.tmp;* # $ delete/nolog/noconfirm N_5*.tmp;* # $ delete/nolog/noconfirm N_4*.tmp;*a# $ delete/nolog/noconfirm N_3*.tmp;* # $ delete/nolog/noconfirm N_2*.tmp;* # $ delete/nolog/noconfirm N_1*.tmp;*5# $ delete/nolog/noconfirm N_0*.tmp;*5# $ delete/nolog/noconfirm M_9*.tmp;*F# $ delete/nolog/noconfirm M_8*.tmp;*4# $ delete/nolog/noconfirm M_7*.tmp;*B# $ delete/nolog/noconfirm M_6*.tmp;*:# $ delete/nolog/noconfirm M_5*.tmp;*2# $ delete/nolog/noconfirm M_4*.tmp;*3# $ delete/nolog/noconfirm M_3*.tmp;*0# $ delete/nolog/noconfirm M_2*.tmp;* # $ delete/nolog/noconfirm M_1*.tmp;* # $ delete/nolog/noconfirm M_0*.tmp;*o# $ delete/nolog/noconfirm L_9*.tmp;*0# $ delete/nolog/noconfirm L_8*.tmp;*n# $ delete/nolog/noconfirm L_7*.tmp;*4# $ delete/nolog/noconfirm L_6*.tmp;* # $ delete/nolog/noconfirm L_5*.tmp;*:# $ delete/nolog/noconfirm L_4*.tmp;*e# $ delete/nolog/noconfirm L_3*.tmp;*;# $ delete/nolog/noconfirm L_2*.tmp;*]# $ delete/nolog/noconfirm L_1*.tmp;*e# $ delete/nolog/noconfirm L_0*.tmp;*!# $ delete/nolog/noconfirm K_9*.tmp;*a# $ delete/nolog/noconfirm K_8*.tmp;*!# $ delete/nolog/noconfirm K_7*.tmp;*[# $ delete/nolog/noconfirm K_6*.tmp;*i# $ delete/nolog/noconfirm K_5*.tmp;*t# $ delete/nolog/noconfirm K_4*.tmp;* # $ delete/nolog/noconfirm K_3*.tmp;*l# $ delete/nolog/noconfirm K_2*.tmp;*t# $ delete/nolog/noconfirm K_1*.tmp;*y# $ delete/nolog/noconfirm K_0*.tmp;*t# $ delete/nolog/noconfirm J_9*.tmp;*!# $ delete/nolog/noconfirm J_8*.tmp;*o# $ delete/nolog/noconfirm J_7*.tmp;*p# $ delete/nolog/noconfirm J_6*.tmp;* # $ delete/nolog/noconfirm J_5*.tmp;*=# $ delete/nolog/noconfirm J_4*.tmp;*t# $ delete/nolog/noconfirm J_3*.tmp;*p# $ delete/nolog/noconfirm J_2*.tmp;*(# $ delete/nolog/noconfirm J_1*.tmp;*m# $ delete/nolog/noconfirm J_0*.tmp;*m# $ delete/nolog/noconfirm I_9*.tmp;*m# $ delete/nolog/noconfirm I_8*.tmp;*m# $ delete/nolog/noconfirm I_7*.tmp;*m# $ delete/nolog/noconfirm I_6*.tmp;*m# $ delete/nolog/noconfirm I_5*.tmp;*m# $ delete/nolog/noconfirm I_4*.tmp;*m# $ delete/nolog/noconfirm I_3*.tmp;*m# $ delete/nolog/noconfirm I_2*.tmp;*m# $ delete/nolog/noconfirm I_1*.tmp;*m# $ delete/nolog/noconfirm I_0*.tmp;*m# $ delete/nolog/noconfirm H_9*.tmp;*m# $ delete/nolog/noconfirm H_8*.tmp;*m# $ delete/nolog/noconfirm H_7*.tmp;*m# $ delete/nolog/noconfirm H_6*.tmp;*m# $ delete/nolog/noconfirm H_5*.tmp;*m# $ delete/nolog/noconfirm H_4*.tmp;*m# $ delete/nolog/noconfirm H_3*.tmp;*m# $ delete/nolog/noconfirm H_2*.tmp;*m# $ delete/nolog/noconfirm H_1*.tmp;*m# $ delete/nolog/noconfirm H_0*.tmp;*m# $ delete/nolog/noconfirm G_9*.tmp;*m# $ delete/nolog/noconfirm G_8*.tmp;*m# $ delete/nolog/noconfirm G_7*.tmp;*m# $ delete/nolog/noconfirm G_6*.tmp;*m# $ delete/nolog/noconfirm G_5*.tmp;*m# $ delete/nolog/noconfirm G_4*.tmp;*m# $ delete/nolog/noconfirm G_3*.tmp;*m# $ delete/nolog/noconfirm G_2*.tmp;*m# $ delete/nolog/noconfirm G_1*.tmp;*m# $ delete/nolog/noconfirm G_0*.tmp;*m# $ delete/nolog/noconfirm F_9*.tmp;*m# $ delete/nolog/noconfirm F_8*.tmp;*m# $ delete/nolog/noconfirm F_7*.tmp;*m# $ delete/nolog/noconfirm F_6*.tmp;*m# $ delete/nolog/noconfirm F_5*.tmp;*m# $ delete/nolog/noconfirm F_4*.tmp;*m# $ delete/nolog/noconfirm F_3*.tmp;*m# $ delete/nolog/noconfirm F_2*.tmp;*m# $ delete/nolog/noconfirm F_1*.tmp;*m# $ delete/nolog/noconfirm F_0*.tmp;*m# $ delete/nolog/noconfirm E_9*.tmp;*m# $ delete/nolog/noconfirm E_8*.tmp;*m# $ delete/nolog/noconfirm E_7*.tmp;*m# $ delete/nolog/noconfirm E_6*.tmp;*m# $ delete/nolog/noconfirm E_5*.tmp;*m# $ delete/nolog/noconfirm E_4*.tmp;*m# $ delete/nolog/noconfirm E_3*.tmp;*m# $ delete/nolog/noconfirm E_2*.tmp;*m# $ delete/nolog/noconfirm E_1*.tmp;*m# $ delete/nolog/noconfirm E_0*.tmp;*m# $ delete/nolog/noconfirm D_9*.tmp;*m# $ delete/nolog/noconfirm D_8*.tmp;*m# $ delete/nolog/noconfirm D_7*.tmp;*m# $ delete/nolog/noconfirm D_6*.tmp;*m# $ delete/nolog/noconfirm D_5*.tmp;*m# $ delete/nolog/noconfirm D_4*.tmp;*m# $ delete/nolog/noconfirm D_3*.tmp;*m# $ delete/nolog/noconfirm D_2*.tmp;*m# $ delete/nolog/noconfirm D_1*.tmp;*m# $ delete/nolog/noconfirm D_0*.tmp;*m# $ delete/nolog/noconfirm C_9*.tmp;*m# $ delete/nolog/noconfirm C_8*.tmp;*m# $ delete/nolog/noconfirm C_7*.tmp;*m# $ delete/nolog/noconfirm C_6*.tmp;*m# $ delete/nolog/noconfirm C_5*.tmp;*m# $ delete/nolog/noconfirm C_4*.tmp;*m# $ delete/nolog/noconfirm C_3*.tmp;*m# $ delete/nolog/noconfirm C_2*.tmp;*m# $ delete/nolog/noconfirm C_1*.tmp;*m# $ delete/nolog/noconfirm C_0*.tmp;*m# $ delete/nolog/noconfirm B_9*.tmp;*m# $ delete/nolog/noconfirm B_8*.tmp;*m# $ delete/nolog/noconfirm B_7*.tmp;*m# $ delete/nolog/noconfirm B_6*.tmp;*m# $ delete/nolog/noconfirm B_5*.tmp;*m# $ delete/nolog/noconfirm B_4*.tmp;*m# $ delete/nolog/noconfirm B_3*.tmp;*m# $ delete/nolog/noconfirm B_2*.tmp;*m# $ delete/nolog/noconfirm B_1*.tmp;*m# $ delete/nolog/noconfirm B_0*.tmp;*m# $ delete/nolog/noconfirm A_9*.tmp;*m# $ delete/nolog/noconfirm A_8*.tmp;*m# $ delete/nolog/noconfirm A_7*.tmp;*m# $ delete/nolog/noconfirm A_6*.tmp;*m# $ delete/nolog/noconfirm A_5*.tmp;*m# $ delete/nolog/noconfirm A_4*.tmp;*m# $ delete/nolog/noconfirm A_3*.tmp;*m# $ delete/nolog/noconfirm A_2*.tmp;*m# $ delete/nolog/noconfirm A_1*.tmp;*m# $ delete/nolog/noconfirm A_0*.tmp;*m $ show timee $! $done:  & $1$DGA100:[TEST-DIR]TEST_DELETES.COM;2   $! $ set def $1$DGA100:[TEST-DIR] $ set nover  $! $ x = 1g $! $loop: $ param = "ON"% $ if x / 2 * 2 .ne. x then param = ""e $!D $ write sys$output "Test ''x' Param is ''param' Time is ''f$time()'" $ @create_files 'param $ write sys$output ""g $ write sys$output ""  $ write sys$output ""m $! $ x = x + 1e $ if x .le. 10 then goto loop  $!   --   RULES OF THE AIR   -----------------l>  #23. Remember, gravity is not just a good idea. It's the law.%       And it's not subject to appeal.    ------------------------------  % Date: Thu, 08 Feb 2001 22:00:08 +0000  From: Brian Tyndallm+ Subject: Re: The "deleting many files" mythm8 Message-ID: <5n568to911d14ah040u9nap1hcrfh5sllt@4ax.com>  B On Thu, 08 Feb 2001 19:12:09 GMT, "Rick Cadruvi" <rick@rdperf.com> wrote:  3 >The fastest way to delete a large directory is to:; > ' >    $ dir/column=1 [dir-spec] /out=t.te1 Use /nohead/notrail on the dir. It saved the editc  / >    $ edit t.t        ! remove the extra linesm3 >    $ dir/full t.t    ! Get size of longest recordnH >    $ sort t.t t.t /key=(pos:1, size:longest-record-length, char, desc) >lD >Now write a simple DCL procedure to read "t.t" and delete each file >individually. >MJ >This will do the delete VERY fast.  When you delete records from the end, >all >the overhead goes away. >mF >I have my own DCL utility that does this somewhere.  If actually uses	 >f$searchm >to produce the file to sort.N >. >just my opnion, >g >Rick Cadruvi... >IC >"Ian Burgess" <ccburgess@uqstu.jdstory.uq.edu.au> wrote in message.) >news:95sp1l$d99$1@bunyip.cc.uq.edu.au...7D >> A rogue system, that shall remain nameless to protect the guilty,4 >> madly created 280,000 files before we stopped it.F >> The resulting directory size was 28,000 blocks (maybe an unenviable
 >record!)./ >> It has taken two days to delete the files...2 >>< >> Anyway the point of this message is the frequently asked,A >> "What is the quickest way to delete a large number of files?".n >>@ >> I deleted four files at the end of the directory, and it took >> 20 seconds. >>= >> Repeating the command, took the same time, just giving thel* >> "file not found" at 5 second intervals. >>G >> Deleting *.*/log  showed a pattern of deleting 10 files in 5 secondsn >> then a pause of 5 seconds.g >>H >> So it looks like it is about as fast to shuffle out an empty block as7 >> it is to find the last file in a directory that big!i >>M >> So the generally accepted wisdom of sorting a directory listing in reverseeG >> order and deleting from the end of the directory is NOT a good idea!e >>H >> In the end I just submitted a batch job to delete *.trc;1 and watchedD >> the size of the directory decrease (by 3 blocks/minute at 28,000,8 >> 22/min at 13,000 and so on!).  Took a couple of days. >> >> Ian Burgess >> University of Queenslandm >> I.Burgess@its.uq.edu.au >> www.its.uq.edu.au >n   ------------------------------  $ Date: Thu, 8 Feb 2001 17:38:03 -0500- From: "Peter Weaver" <peter.weaver@stelco.ca>c+ Subject: Re: The "deleting many files" mythR4 Message-ID: <FdFg6.129451$Z2.1660414@nnrp1.uunet.ca>  D I posted this before but it was 22K and has not even shown up on theC news server I posted from. So this is a reduced version that shouldm@ get out. If anyone wants the .COM files I posted in the previous. message then let me know and I will send them.  7 "Alan E. Feldman" <alan48@my-deja.com> wrote in messagen# news:95us7m$8vt$1@nnrp1.deja.com...n+ > In article <3A82C716.CDF23F4A@Omond.net>,m >...D > > considerably with VMS 7.2 since the block-shuffle is done, ahem, > > rather more efficiently).c >iD > Has anyone actually tested that? It may indeed be so, but I'd like to
 > see a test.  >...    D Here is a test I ran the other day on an ES40 running VMS 7.2-1. The disks are on a HSG80;T  > Doing standard delete...   5-FEB-2001 14:52:47.23   5-FEB-2001 15:05:05> Doing reverse delete...    5-FEB-2001 15:46:04.01   5-FEB-2001 15:52:03> Doing standard delete...   5-FEB-2001 16:34:17.02   5-FEB-2001 16:46:59> Doing reverse delete...    5-FEB-2001 17:28:04.94   5-FEB-2001 17:34:22> Doing standard delete...   5-FEB-2001 18:21:01.40   5-FEB-2001 18:33:23> Doing reverse delete...    5-FEB-2001 19:19:56.08   5-FEB-2001 19:26:17> Doing standard delete...   5-FEB-2001 20:06:24.90   5-FEB-2001 20:18:44> Doing reverse delete...    5-FEB-2001 20:57:28.89   5-FEB-2001 21:03:42> Doing standard delete...   5-FEB-2001 21:48:17.15   5-FEB-2001 22:00:20> Doing reverse delete...    5-FEB-2001 22:43:44.40   5-FEB-2001 22:49:55    * Here are the procedures I used to do this;  C [This is the part I cut out, basically the .COM was creating 26,000gE files then copying these files to *.*;2 and then again to *.*;3. ThennB a standard delete was deleting A_0*.TMP.*, A_1*.TMP.*... a reverse2 delete started with Z_9*.TMP.* then Z_8*.TMP.*...]   ------------------------------   Date: 8 Feb 2001 22:43:04 GMTe5 From: ccburgess@uqstu.jdstory.uq.edu.au (Ian Burgess)W+ Subject: Re: The "deleting many files" myth;. Message-ID: <95v7do$a42$1@bunyip.cc.uq.edu.au>  A >Ian Burgess <ccburgess@uqstu.jdstory.uq.edu.au> wrote in message D >> A rogue system, that shall remain nameless to protect the guilty, >why? 4 >> madly created 280,000 files before we stopped it.F >> The resulting directory size was 28,000 blocks (maybe an unenviable
 >record!)./ >> It has taken two days to delete the files...  >>< >> Anyway the point of this message is the frequently asked,A >> "What is the quickest way to delete a large number of files?".n >>@ >> I deleted four files at the end of the directory, and it took >> 20 seconds. >>= >> Repeating the command, took the same time, just giving thei* >> "file not found" at 5 second intervals. >>G >> Deleting *.*/log  showed a pattern of deleting 10 files in 5 seconds. >> then a pause of 5 seconds.m >>H >> So it looks like it is about as fast to shuffle out an empty block as7 >> it is to find the last file in a directory that big!e >>M >> So the generally accepted wisdom of sorting a directory listing in reversenG >> order and deleting from the end of the directory is NOT a good idea!g >> >Your options are:0 >set file/nodir xxx.dir and then delete xxx.dir;D >(I don't know what happens to the "files" so this may take as long) >Use dfu from the freeware cdr >Upgrade to vms 7.2  >Backup/initialise/restore >Phile  2 Well gaining 280,000 lost files is not a solution.C Then I have to ANALY/DISK/REPAIR, (which could well take two days!)7, and still have the same problem in [SYSLOST]
 Thanks-a-lot!g   Ian Burgess  University of Queensland I.Burgess@its.uq.edu.aue www.its.uq.edu.auZ   ------------------------------   Date: 8 Feb 2001 22:56:18 GMTc5 From: ccburgess@uqstu.jdstory.uq.edu.au (Ian Burgess) + Subject: Re: The "deleting many files" mythe. Message-ID: <95v86i$a42$3@bunyip.cc.uq.edu.au>  < In article <95uca5$djr@usenet.pa.dec.com>, "Dan" <x> writes: >I've found that& >        BACKUP *.*;*/DELETE NL:./SAVE% >seems to be faster than DELETE *.*;*Y >.H >(But don't take this as advice, I'm no VMS expert.  For all I know, the >above could be disastrous.) >m >Dan  ; I've heard that solution before.  Never tried it until now.c  ' When I did I omitted the /SAVE and got m3 %BACKUP-F-INVDEVTYP, invalid backup device type NL:   < So I regret I didn't really try that, and I sincerely hope I$ never have another chance like that!   Ian Burgess  University of Queensland I.Burgess@its.uq.edu.aun www.its.uq.edu.au    ------------------------------   Date: 8 Feb 2001 22:48:56 GMTm5 From: ccburgess@uqstu.jdstory.uq.edu.au (Ian Burgess)l+ Subject: Re: The "deleting many files" mythn. Message-ID: <95v7oo$a42$2@bunyip.cc.uq.edu.au>  d In article <0ung6.3596$sS4.127428@ozemail.com.au>, "Phil Howell" <phowell@snowyhydro.com.au> writes: >mA >David J. Dachtera <djesys.nospam@earthlink.net> wrote in messagen >> > Upgrade to vms 7.2e >> >> What does that do?m5 >7.2 can cache directories of (almost) unlimited sizelM >previous versions have to go back to the disk if the size exceeds 128 blocksn   Sorry it is OpenVMS 7.2-1e   >> >> > Backup/initialise/restore >>! >> Selective save/restore, or ???n- >backup everything except the large directoryn >initialise the disk >restore the backupV  O No thanks,  This is a production system. No downtime of that magnitude allowed.;  = The "disk" is actually a RAID set of 177736020 blocks (ODS-5)m   Ian Burgess  University of Queensland I.Burgess@its.uq.edu.aun www.its.uq.edu.auk   ------------------------------   Date: 8 Feb 2001 23:09:05 GMT25 From: ccburgess@uqstu.jdstory.uq.edu.au (Ian Burgess)e+ Subject: Re: The "deleting many files" mythn. Message-ID: <95v8uh$a42$5@bunyip.cc.uq.edu.au>  1 I guess this just no longer applies with VMS 7.2,e  which is why I called it a myth!  b In article <dcCg6.1596$Li7.173824@dfiatx1-snr1.gtei.net>, "Rick Cadruvi" <rick@rdperf.com> writes:3 >The fastest way to delete a large directory is to:e >e' >    $ dir/column=1 [dir-spec] /out=t.tl/ >    $ edit t.t        ! remove the extra linesm3 >    $ dir/full t.t    ! Get size of longest record H >    $ sort t.t t.t /key=(pos:1, size:longest-record-length, char, desc) >eD >Now write a simple DCL procedure to read "t.t" and delete each file >individually. >cJ >This will do the delete VERY fast.  When you delete records from the end, >all the overhead goes away. >g >just my opnion, >a >Rick Cadruvi... >nC >"Ian Burgess" <ccburgess@uqstu.jdstory.uq.edu.au> wrote in messagegD >> A rogue system, that shall remain nameless to protect the guilty,4 >> madly created 280,000 files before we stopped it.F >> The resulting directory size was 28,000 blocks (maybe an unenviable
 >record!)./ >> It has taken two days to delete the files...e >>< >> Anyway the point of this message is the frequently asked,A >> "What is the quickest way to delete a large number of files?".Q >>@ >> I deleted four files at the end of the directory, and it took >> 20 seconds. >>= >> Repeating the command, took the same time, just giving the3* >> "file not found" at 5 second intervals. >>G >> Deleting *.*/log  showed a pattern of deleting 10 files in 5 seconds  >> then a pause of 5 seconds.. >>H >> So it looks like it is about as fast to shuffle out an empty block as7 >> it is to find the last file in a directory that big!g >>M >> So the generally accepted wisdom of sorting a directory listing in reverseiG >> order and deleting from the end of the directory is NOT a good idea!n Ian Burgess  University of Queensland I.Burgess@its.uq.edu.aun www.its.uq.edu.au.   ------------------------------  % Date: Thu, 08 Feb 2001 18:18:30 -0500.- From: JF Mezei <jfmezei.spamnot@videotron.ca> + Subject: Re: The "deleting many files" mythn, Message-ID: <3A832937.41F9C344@videotron.ca>   Ian Burgess wrote:> > So I regret I didn't really try that, and I sincerely hope I& > never have another chance like that!    I Well, as long as the real idiot who generated the 280,000 files still has;M access to your system, you continue to have a chance of the problem happening E again... As since we know that it couldn't possibly have been YOU who;K generated the files, that idiot is still on the loose somewhere :-) :-) :-)  :-) :-) :-) :-) :-) :-) :-)1   ------------------------------   Date: 8 Feb 2001 23:04:32 GMTn5 From: ccburgess@uqstu.jdstory.uq.edu.au (Ian Burgess) + Subject: Re: The "deleting many files" mythe. Message-ID: <95v8m0$a42$4@bunyip.cc.uq.edu.au>  B >*sigh* ... I really wish people would stop propagating this myth. >nD >If the files you are deleting are of any significant size, then theE >backup to the null device might dominate the time taken (intuitivelye? >obvious IMHO).  The best way is indeed, as others have already;B >ponted out, to use DFU (though the difference in time has reducedA >considerably with VMS 7.2 since the block-shuffle is done, ahem,c >rather more efficiently).  E I was willing to experiment with this; the file size was quite small.e. But I got the backup command wrong (no /SAVE).  E >If you don't use DFU, then it's a simple exercise to generate a listg@ >sorted in reverse alphabetic order and to delete (I'm sure Hein9 >van den Heuvel "Mister RMS" posted just such a procedureK9 >to minimise the number of image activations of DELETE inn& >this newsgroup within the last year). >n
 >Roy Omond >Blue Bubble Ltd.n  ) THAT is the Myth I was hoping to dispell!c   Ian Burgess  University of Queensland I.Burgess@its.uq.edu.aun www.its.uq.edu.au.   ------------------------------  % Date: Thu, 08 Feb 2001 18:32:32 -0500." From: Dan Sugalski <dan@sidhe.org>+ Subject: Re: The "deleting many files" mytht: Message-ID: <5.0.2.1.0.20010208182753.022e99d8@24.8.96.48>  . At 11:04 PM 2/8/2001 +0000, Ian Burgess wrote:D > >*sigh* ... I really wish people would stop propagating this myth. > >mF > >If the files you are deleting are of any significant size, then theG > >backup to the null device might dominate the time taken (intuitivelyIA > >obvious IMHO).  The best way is indeed, as others have alreadycD > >ponted out, to use DFU (though the difference in time has reducedC > >considerably with VMS 7.2 since the block-shuffle is done, ahem,e > >rather more efficiently). > F >I was willing to experiment with this; the file size was quite small./ >But I got the backup command wrong (no /SAVE).n  I Hmmm. Still got the files? I'm curious as to how long this chunk of perl:l  
    #! perl -w.    @files = <*>;    foreach (reverse @files) {e      1 while unlink;    }  K would take to clean out the directory. (When run *in* the directory, mind, m3 since it'll nuke all the files in your default dir)g   					Dan  I --------------------------------------"it's like this"-------------------52 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and evenm;                                       teddy bears get drunkc   ------------------------------  % Date: Fri, 09 Feb 2001 00:00:09 +0000c. From: mpatt644 <mpatt644@netscapeonline.co.uk>+ Subject: Re: The "deleting many files" mythm4 Message-ID: <3A833309.1F6D4DE5@netscapeonline.co.uk>  E I too have used the reverse delete on large numbers of files. I can'tlG say how many, and certainly not 280,000 as the original poster did. ButnF when I've used it (and done timed comparisons) it IS much quicker than an ordinary wild card delete.    Brian, Tyndall wrote:E > D > On Thu, 08 Feb 2001 19:12:09 GMT, "Rick Cadruvi" <rick@rdperf.com> > wrote: > 5 > >The fastest way to delete a large directory is to:c > >m) > >    $ dir/column=1 [dir-spec] /out=t.t.3 > Use /nohead/notrail on the dir. It saved the edite > 1 > >    $ edit t.t        ! remove the extra linesD5 > >    $ dir/full t.t    ! Get size of longest recordeJ > >    $ sort t.t t.t /key=(pos:1, size:longest-record-length, char, desc) > >lF > >Now write a simple DCL procedure to read "t.t" and delete each file > >individually. > >mL > >This will do the delete VERY fast.  When you delete records from the end, > >all > >the overhead goes away. > > H > >I have my own DCL utility that does this somewhere.  If actually uses > >f$searchl > >to produce the file to sort.e > >g > >just my opnion, > >  > >Rick Cadruvi... > >5E > >"Ian Burgess" <ccburgess@uqstu.jdstory.uq.edu.au> wrote in messagem+ > >news:95sp1l$d99$1@bunyip.cc.uq.edu.au...mF > >> A rogue system, that shall remain nameless to protect the guilty,6 > >> madly created 280,000 files before we stopped it.H > >> The resulting directory size was 28,000 blocks (maybe an unenviable > >record!).1 > >> It has taken two days to delete the files...; > >>> > >> Anyway the point of this message is the frequently asked,C > >> "What is the quickest way to delete a large number of files?".i > >>B > >> I deleted four files at the end of the directory, and it took > >> 20 seconds. > >>? > >> Repeating the command, took the same time, just giving the;, > >> "file not found" at 5 second intervals. > >>I > >> Deleting *.*/log  showed a pattern of deleting 10 files in 5 secondsn > >> then a pause of 5 seconds.e > >>J > >> So it looks like it is about as fast to shuffle out an empty block as9 > >> it is to find the last file in a directory that big!A > >>O > >> So the generally accepted wisdom of sorting a directory listing in reverse!I > >> order and deleting from the end of the directory is NOT a good idea!" > >>J > >> In the end I just submitted a batch job to delete *.trc;1 and watchedF > >> the size of the directory decrease (by 3 blocks/minute at 28,000,: > >> 22/min at 13,000 and so on!).  Took a couple of days. > >> > >> Ian Burgess > >> University of Queensland- > >> I.Burgess@its.uq.edu.au > >> www.its.uq.edu.au > >    ------------------------------  % Date: Fri, 09 Feb 2001 00:56:29 +0000-) From: Christof Brass <brass@infopuls.com>0' Subject: Re: Try this on Linux or NT/MET, Message-ID: <3A83403D.B40241A7@infopuls.com>   Jan Vorbrueggen wrote: > - > Christof Brass <brass@infopuls.com> writes:T > @ > > I regard this as a modern urban legend in its shortest form.B > > No power outage in Ireland for that long?? I don't believe it. > H > This is Europe, you know, not the 'nighted States of A or the State ofL > California as in its recent incarnation. I can't remember having a generalH > power outage for the last decade at least. We always laugh when we seeM > those crews putting up the wooden stalks with the power et al. wiring againi > after every little storm.  > L > On the other hand, the power sector is being "liberalized" in Europe as weA > speak. Let's see whether we don't manage to emulate California!o > 
 >         Janl  > I lived for 20 years in Germany and we had some (two or three)? power failures because of severe damages (water?). At least one.? of them lasted a few hours. I remember because I came home fromc# school and my mother hadn't cooked.a? I lived for 20 years in Switzerland and I encountered two power2? failures which only one of them hit my VMS system while the PCsz: stopped working on both. The outages were shorter than 0.5; seconds. The VMS continued to work because of it's built in > safety mechanism. It checked if the power was really down when@ it encountered the power down condition first. After checking it> found that the power was already back and decided not to stop.4 The PCs were clueless about power outage and stopped immediately. :-)@ What do you mean by "general power outage"? Do you mean "general4 power fault" like in "general protection fault"? ;-)? Honestly I don't believe that you didn't encounter at least onei: power down situation at your university within the last 10 years, did you?i   ------------------------------  # Date: Fri, 09 Feb 2001 05:46:23 GMTs From: cmremley@my-deja.com' Subject: Re: Try this on Linux or NT/MEe) Message-ID: <96007f$6po$1@nnrp1.deja.com>   G > Heh...I have a Linux system that has an uptime (as of writing) of 394dE > days, 17 hours and 20 minutes.  That system runs multiple web sites  > and a relational database. > H > Another of my Linux systems routinely runs 6 months at a time handlingB > ~10,000 emails per day, primary DNS for 40+ domains, over 30 webG > sites, multiple GBs of FTP, and HTTP proxy cacheing.  The last rebootWG > (which kept the system from hitting a year) was accidental -- someonem > hit the wrong power switch.$ >1G > VMS is certainly not the only system that can sustain serious uptime.  >n > Joeu >n  @ I'd be very surprised not to see Unix systems with comparable up times.     Sent via Deja.coms http://www.deja.com/   ------------------------------  # Date: Thu, 08 Feb 2001 20:22:18 GMTa2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)* Subject: Re: typo in TCP/IP management doc7 Message-ID: <_dDg6.558$cu.2437@gazette.loc1.tandem.com>d  G In article <95tm8d$7iq$1@nnrp1.deja.com>, Didier.Morandi@gmx.fr writes:  :iF :> Isn't there still a form, both on the web and in printed documents,I :> for readers to submit comments on the manuals?  If so, there's no needdK :> to bother Hoff, and your message will get very close to the right peopled :> in one hop. .. :<openvmsdoc@zko.mts.dec.com>:     The usual questions:  L   Did you send directly to this address, or did you send to another address I   (which then forwarded to this address)?  Was the address acquired from  K   somewhere at the website (if so, where?), or was this from some existing F.   (and probably old) hardcopy documentation?    8   IIRC, this looks like the old documentation address...  J   A new address (OpenVMS.documentation@compaq.com) is just coming on-line,=   and email can also be sent to OpenVMSdoc@compaq.com, too.  -  K   The older .dec.com and .digital.com addresses are slowly being retired.   J   At least two older gateways (enet.dec.com and mts.dec.com) are no longerE   available.  Yes, I know all about this stuff as I'm presently stillp3   using one of these older addresses for myself....g  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Thu, 08 Feb 2001 23:07:12 GMTe* From: Edward Heller <ejheller@my-deja.com>$ Subject: USAGE.DAT and missing files) Message-ID: <95v8qr$joo$1@nnrp1.deja.com>t  3 Here is a puzzler, if anyone can take a stab at it:I  F I recently had a disk that approached the max files and started giving@ me errors. I ran ANALYZE/DISK and solved the problem, however inC reviewing the options for ANALYZE, I noticed the option to create alG USAGE.DAT file. The system documentation does not provide a description>> of the file, however, being persistent, I determined the basicH structure. I deciphered enough to get it into an editable file. Here are0 the questions I have, if anyone has the answers:E 1) What is the structure of the binary header data on each record ande< where might I find documentation on the meaning of the data?G 2) Why does the USAGE.DAT file have more records (i.e,, files) than are G shown with a DIR/GRAND [*...] on the disk? Not only that, but there area4 more directory records in the file than on the disk.@ Note that this is not a system disk and does not have duplicated directory trees.   Thanks,b Edward.    --
 Edward Hellerc TransCore, ITS Atlanta, GA, USA     Sent via Deja.com  http://www.deja.com/   ------------------------------  # Date: Fri, 09 Feb 2001 01:14:18 GMT:1 From: "Mark D. Jilson" <jilly@clarityconnect.com> ( Subject: Re: USAGE.DAT and missing files2 Message-ID: <3A83452A.7CCACE23@clarityconnect.com>  H If you have access to DSNlink you'd see the following article that mightG be of use.  I did try to mail it to you as a special one-time favor butA it bounced.u  = Example-MACRO  How To Format The ANALYZE/USAGE USAGE.DAT FileL   Edward Heller wrote: > 5 > Here is a puzzler, if anyone can take a stab at it:u > H > I recently had a disk that approached the max files and started givingB > me errors. I ran ANALYZE/DISK and solved the problem, however inE > reviewing the options for ANALYZE, I noticed the option to create a4I > USAGE.DAT file. The system documentation does not provide a description"@ > of the file, however, being persistent, I determined the basicJ > structure. I deciphered enough to get it into an editable file. Here are2 > the questions I have, if anyone has the answers:G > 1) What is the structure of the binary header data on each record ande> > where might I find documentation on the meaning of the data?I > 2) Why does the USAGE.DAT file have more records (i.e,, files) than are I > shown with a DIR/GRAND [*...] on the disk? Not only that, but there arei6 > more directory records in the file than on the disk.B > Note that this is not a system disk and does not have duplicated > directory trees. > 	 > Thanks, 	 > Edward.  >  > -- > Edward Hellere > TransCore, ITS > Atlanta, GA, USA >  > Sent via Deja.comt > http://www.deja.com/   -- uD Jilly	- Working from Home in the Chemung River Valley - Lockwood, NY0 	- jilly@clarityconnect.com			- Brett Bodine fan. 	- Mark.Jilson@Compaq.com			- since 1975 or so, 	- http://www.jilly.baka.com               -   ------------------------------   Date: 8 Feb 2001 21:50 CST' From: carl@gerg.tamu.edu (Carl Perkins)s( Subject: Re: USAGE.DAT and missing files, Message-ID: <8FEB200121500207@gerg.tamu.edu>  . Edward Heller <ejheller@my-deja.com> writes...4 }Here is a puzzler, if anyone can take a stab at it:  % So we've become comp.os.vms.car-talk?   F }1) What is the structure of the binary header data on each record and= }where might I find documentation on the meaning of the data?lH }2) Why does the USAGE.DAT file have more records (i.e,, files) than areH }shown with a DIR/GRAND [*...] on the disk? Not only that, but there are5 }more directory records in the file than on the disk.mA }Note that this is not a system disk and does not have duplicatede }directory trees.e }--t }Edward Heller  F Set the wayback maching to 31-MAY-1990... That's when I  picked up theF following bits of software from InfoVAX. It was posted by Charles Lane and it consists of:-  C 1) usgdef.h - include file with the definitions of what the data inw&    the usage file is, used by #3 below$ 2) ioinit.c - used by the next thingJ 3) read_usage.c - source for a program that uses the usage file to produce0    a summary by user in a human readable format.  K This examples may help you to interpret the contents of the usage.dat file.m  G I happen to have a copy of what a run of it produced of about that sameT vintage. It looks like this:  <  ANALYZE/USAGE GERGA_10601      at   26-SEP-1990 21:15:14.19*      user                blocks    percent( [TIMECLOCK]               20453    2.62%( [GARY]                       11    0.00%( [DENIS]                       6    0.00%( [DAVE]                     4305    0.55%( [CHRIS]                   23336    2.99%( [KEVIN]                     423    0.05%( [PAUL]                      958    0.12%( [PLOT]                        9    0.00%( [SYSTEM]                 271097   34.72%( [DEBZ]                    36029    4.61%( [NORMAN]                 156642   20.06%( [IAN]                       403    0.05%( [DEFAULT]                241116   30.88%( [CAROLYN]                   878    0.11%( [CARL]                      354    0.05%( [00001,00001]             24775    3.17%+ ===========================================f( Totals                   780795  100.00%  H So if you build it and run it, that is the sort of thing you should get.  G It works with VAX VMS 5.5-2 (and ODS-2 disks, of course). I don't thinktH I've actually run it on anything newer. I would expect it to work on any8 ODS-2 disk, and probably on ODS-5 as well, VAX or Alpha.   --- Carl  % ---------- begin usgdef.h ---------- r #define    USG$K_IDENT     1 #define    USG$K_FILE      2 #define    USG$K_IDENT_LEN 61- #define    USG$C_IDENT_LEN 611 #define    USG$S_USGDEF    61i #define    USG$B_TYPE      0 #define    USG$L_SERIALNUM 1 #define    USG$S_STRUCNAME 12  #define    USG$T_STRUCNAME 5 #define    USG$S_VOLNAME   12I #define    USG$T_VOLNAME   17t #define    USG$S_OWNERNAME 12e #define    USG$T_OWNERNAME 29! #define    USG$S_FORMAT    12  #define    USG$T_FORMAT    41  #define    USG$S_TIME      8 #define    USG$Q_TIME      53  #define    USG$K_FILE_LEN  423 #define    USG$C_FILE_LEN  423 #define    USG$S_USGDEF1   423 #define    USG$L_FILEOWNER 1 #define    USG$W_UICMEMBER 1 #define    USG$W_UICGROUP  3 #define    USG$L_ALLOCATED 5 #define    USG$L_USED      9 #define    USG$W_DIR_LEN   13  #define    USG$W_SPEC_LEN  15t #define    USG$S_FILESPEC  406E #define    USG$T_FILESPEC  17              ;  File spec "[dir]nam.typu  % ---------- begin ioinit.c ---------- yP /******************************************************************************/  F /* IOINIT.C -- I/O redirection subroutine.  Redirects stdin (< or <<);.  *      stdout (> or >>); or stderr ( 2>, 2>>)	  * Usage:b  *      main(nargs, args)s  *      {       ...e%  *              ioinit(&nargs, args);e  *              ... 	  *      }l  */h   #include errno #include stdio   typedef char *STR;   ioinit(nargs, args)  int *nargs; 
 STR *args; {   int argnum;f  /     for (argnum = 1; argnum < *nargs; ++argnum)m/     {   if (strncmp(args[argnum], "<", 1) == 0)t         {   args[argnum] += 1;@             *nargs = u_reopen(*nargs, args, argnum, "r", stdin);             argnum--;n7         } else if (strncmp(args[argnum], ">>", 2) == 0)i         {   args[argnum] += 2;A             *nargs = u_reopen(*nargs, args, argnum, "a", stdout);R             argnum--;L6         } else if (strncmp(args[argnum], ">", 1) == 0)         {   args[argnum] += 1;A             *nargs = u_reopen(*nargs, args, argnum, "w", stdout);-             argnum--;e8         } else if (strncmp(args[argnum], "2>>", 3) == 0)         {   args[argnum] += 3;A             *nargs = u_reopen(*nargs, args, argnum, "a", stderr);2             argnum--;t7         } else if (strncmp(args[argnum], "2>", 2) == 0).         {    args[argnum] += 2; A             *nargs = u_reopen(*nargs, args, argnum, "w", stderr);o             argnum--; 	         }      }  }t  * u_reopen(nargs, args, argnum, acmod, chan) int nargs, argnum; STR *args, acmod;s FILE *chan;e {   char *file;      int offset, i, errornum;        if (args[argnum][0] != '\0')     {   offset = 1;i         file = args[argnum];$     } else if ((argnum + 1) < nargs)     {   offset = 2;.         file = args[argnum+1];
     } elseB     {   fprintf(stderr, "Illegal redirection on command line.\n");         exit(1);/     } for (i = argnum; i < nargs - offset; ++i)l#         args[i] = args[i + offset];lK     if (((*acmod == ' ' || strcmp(acmod,"a+") == 0) && freopen(file, acmod, H         chan ,"rfm=stm") != chan) || freopen(file, acmod, chan) != chan)     {   if (errno == EVMSERR)l&         {       errornum = vaxc$errno;H                 fprintf(stderr, "Failure opening redirected stream.\n");                 exit(errornum);          } else=         {       perror("Failure opening redirected stream.");a                 exit(1);	         }      } return(nargs - offset);r }c  ) ---------- begin read_usage.c ---------- r /*  '         usage --- calculate disk usage.<               usage [filename] */   #include <stdio> #include <ssdef> #include <descrip> #include "usgdef.h"p   union uic {      int fulluic;     struct {&         short int uicmember, uicgroup;     } partuic; };    
 struct user {0     union uic fileowner;     int blocks;v     struct user * next;  } *head = NULL;S   #define NBUFMAX   2048 char buffer[NBUFMAX];      main(argc, argv)	 int argc; 
 char *argv[];2 {      struct user *p;a     int nbytes, allocated;     int j, type, fd;     int total = 0;  3     char volume[USG$S_VOLNAME+1], time[USG$S_TIME];d     union uic owner;     char atime[32];n#     struct dsc$descriptor_s stime = =     { sizeof(atime)-1, DSC$K_DTYPE_T, DSC$K_CLASS_S, atime };l  ,     static int l, id, length1, length2, iss;(     char name1[32], name2[32], name[80];     struct dsc$descriptor_slI         idname1 = {sizeof(name1)-1, DSC$K_DTYPE_T, DSC$K_CLASS_S, name1}, I         idname2 = {sizeof(name2)-1, DSC$K_DTYPE_T, DSC$K_CLASS_S, name2};e         ioinit(&argc, argv);       if (argc != 2) {1         printf("Usage:  Diskusage  datafile \n");t         exit(SS$_NORMAL);      }        fd = open(argv[1],0);      if (fd == -1) { 5         printf("unable to open file %s .\n",argv[1]);"         exit(SS$_NORMAL);t     }r  3     while((nbytes = read(fd,buffer,NBUFMAX)) >0 ) {n"         type = buffer[USG$B_TYPE];!         if (type == USG$K_FILE) {oK             owner.fulluic = (((int)buffer[USG$L_FILEOWNER+3] & 0x0FF)<<24)| K                             (((int)buffer[USG$L_FILEOWNER+2] & 0x0FF)<<16)|rK                             (((int)buffer[USG$L_FILEOWNER+1] & 0x0FF)<<8 )|aL                              ((int)buffer[USG$L_FILEOWNER]   & 0x0FF)      ;K             allocated     = (((int)buffer[USG$L_ALLOCATED+3] & 0x0FF)<<24)| K                             (((int)buffer[USG$L_ALLOCATED+2] & 0x0FF)<<16)|iK                             (((int)buffer[USG$L_ALLOCATED+1] & 0x0FF)<<8 )|tK                              ((int)buffer[USG$L_ALLOCATED]   & 0x0FF)     ;n             p = head;nF             while (p != NULL && p->fileowner.fulluic != owner.fulluic)                 p = p->next;             if (p == NULL){ @                 p = (struct user *) malloc(sizeof(struct user));                 if (p == NULL){gC                     fprintf(stderr,"Unable to allocate memory.\n");d%                     exit(SS$_NORMAL);                  }n5                 p->fileowner.fulluic = owner.fulluic;t                 p->blocks = 0;                 p->next = head;                  head = p;1
             }!  #             p->blocks += allocated;I             total += allocated;e)         } else if (type == USG$K_IDENT) {>A             strncpy(volume,&buffer[USG$T_VOLNAME],USG$S_VOLNAME); )             volume[USG$S_VOLNAME] = '\0';iH             for (j=0; j<USG$S_TIME; j++) time[j] = buffer[USG$Q_TIME+j];	         }D     }4!     sys$asctim(&l,&stime,time,0);o     atime[l] = '\0';;     printf(" ANALYZE/USAGE %s     at   %s\n",volume,atime);a;     printf("     user                blocks    percent\n");o  
     p = head;I     while (p != NULL) {d"         id = p->fileowner.fulluic;         if (id > 0) {n=             iss = sys$idtoasc(id,&length1,&idname1, 0, 0, 0);n$             if (iss != SS$_NORMAL) {+                 sprintf(name,"[%05o,%05o]",e8                 p->fileowner.partuic.uicgroup & 0x0FFFF,9                 p->fileowner.partuic.uicmember& 0x0FFFF);i             } else {6                 idname1.dsc$a_pointer[length1] = '\0';K                 iss = sys$idtoasc(id | 0x0FFFF,&length2,&idname2, 0, 0, 0);e(                 if (iss != SS$_NORMAL) {?                     sprintf(name,"[%s]",idname1.dsc$a_pointer);e                 } else {:                     idname2.dsc$a_pointer[length2] = '\0';  < sprintf(name,"[%s,%s]",idname2.dsc$a_pointer,idname1.dsc$a_p ointer);                 }e
             }i         } else {=             iss = sys$idtoasc(id,&length1,&idname1, 0, 0, 0);y$             if (iss != SS$_NORMAL) {-                 sprintf(name,"[%%X%08X]",id);5             } else {6                 idname1.dsc$a_pointer[length1] = '\0';;                 sprintf(name,"[%s]",idname1.dsc$a_pointer);r
             }w	         }          printf("%s",name);;         for(j = 0; j < 24 - strlen(name); j++) printf(" "); !         printf(" %6d  %6.2f%%\n",u>             p->blocks, (float)p->blocks/(float)total * 100. );         p = p->next;     }g<     printf("===========================================\n");C     printf("Totals                   %6d  %6.2f%%\n",total, 100.0);e }o   ------------------------------  # Date: Thu, 08 Feb 2001 21:16:45 GMT-8 From: hammond@not@peek.ppb.cpqcorp.net (Charlie Hammond)B Subject: Re: VAX/VMS 7.2 BACKUP/IMAGE behavior when a file is open7 Message-ID: <11Eg6.562$cu.2420@gazette.loc1.tandem.com>   0 In article <3a82a9d6.1309573@news.harvard.edu>, % hoke@gse.harvard.edu (Ken Ho) writes:s  E >If there is a data file whose contents are being changed at the timelE >that BACKUP/IMAGE/IGNORE=INTERLOCK gets to it, will the copy that istB >backed up onto tape be an accurate picture of the data before anyE >in-progress (not yet written to disk) changes?  In other words, if I.F >had to restore the file, would the integrity of its data be intact asF >a snapshot in time from when BACKUP got to it, or would the very factG >that it was open for write (whether or not anything was actually beingn9 >changed) prevent BACKUP from making a usable copy of it?a  D The order in which the write I/O that chages the file's contents is F executed relative to the read I/O done by BACKUP cannot be determined.G Therefore the backup copy of the file may contain all, some or none of  J the changes.  Backup copy may or may not be self-consistent; its integrity is not guaranteed.  G The purpose of /IGNORE=INTERLOCK is to say that you don't care, or thatiF YOU (not the file system) will guarantee that no writes are being done( even thought the file is open for write.   -- oK     Charlie Hammond -- Compaq Computer Corporation -- Pompano Beach  FL USApH        (hammond@not@peek.ppb.cpqcorp.net -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------  % Date: Thu, 08 Feb 2001 13:23:59 -0600a/ From: Chris Scheers <chris@applied-synergy.com>,2 Subject: Re: VMS 7.2-1 Bugcheck In DECW$REINIT.EXE3 Message-ID: <3A82F24F.6848BE28@applied-synergy.com>s   Fred Kleinsorge wrote: > H > decw$reinit  is a simple utility that's purpose in life is to call the8 > controller and unit init routines for a device driver. > M > What is the graphics device?  What does a CLUE CRASH and a CLUE CONFIG givew > you on the dump?   FWIW:a  G On an AlphaStation 255 w/ZLXp-L1, DECW$REINIT will produce a SPLIPLHIGHa bugcheck if SYSTEM_CHECK is 1.  ? This occurs with OPEN3D V4.9 on Alpha VMS V7.1, V7.2, and E7.3.s    D Fred, is there any chance of getting the base level graphics driversE moved into OpenVMS?  To use the ZLXp-L1 board with DECwindows, Open3DnE must be loaded to get the drivers, even if you don't want/need Open3De itself.    ------------------------------  % Date: Fri, 09 Feb 2001 01:41:03 +0000:) From: Christof Brass <brass@infopuls.com>9B Subject: Re: Vote Early and Often... Give up your Browser Security, Message-ID: <3A834AAF.43CD97F6@infopuls.com>   David Mathog wrote:e > _ > In article <3A82B621.92C96991@uk.sun.com>, andrew harrison <andrew.nospam@uk.sun.com> writes:  > >JF Mezei wrote: > >>Q > >> I find it interesting that nobody has blasted JAVA yet. I find java far morevN > >> dangerous and insidous than javascript. With javascript, I can do a "VIEW? > >> SOURCE" and see what it is trying to do. Not so with JAVA.e > >e > > 2 > >The Java sandbox scheme was designed to make it3 > >possible to run applets safely without having toa2 > >worry about what the code is trying to do. This2 > >was one of the basic design principles of Java. > >h0 > >Because of this there have been very few Java4 > >security exploits and the ones that have appeared5 > >have been due to bugs in the implimentation of thet1 > >JVM and not in the basic security architectureo
 > >itself. > >c > K > Well yes, but there are a lot of pages out there that lock up the browserSI > for a good long time while a large Java program loads and/or sucks in a-M > huge amount of data over the net.   I only have a modem at my house, so, asJM > the expression goes, "don't try this at home".   It's not a hack so much aseH > a denial of service problem.  And there's never any progress indicatorL > while this is going on, so you can't know if you're in an infinite loop orE > just a few more minutes away from regaining control of the browser.- >  > David Mathog > mathog@seqaxp.bio.caltech.eduL@ > Manager, sequence analysis facility, biology division, Caltech  9 Despite the relatively/moderately good design of the Javae? language and the applet sandbox concept which has recently beenS= extended to the trusted applet concept Java applets are braino< dead because of the different browser plugin JVMs. Hopefully= it's getting better now where the OS's local JVM can be used.f? But as I said only a few Internet sites are using applets. Witht; intranets the situation is a little bit better. But there's & still the performance penalty of Java.   ------------------------------  $ Date: Thu, 8 Feb 2001 16:38:52 -1000& From: Helen Rapozo <rapozo@hawaii.edu>2 Subject: Re: what version of VMS are people using?> Message-ID: <Pine.GSO.4.21.0102081637520.22007-100000@uhunix5>  5 1 VAX at V7.2, another at V6.2 and a third at V5.5-2.l    t1   temporary .sig while I think of something else.i   ------------------------------  # Date: Thu, 08 Feb 2001 20:00:05 GMTh+ From: Craig A. Berry <calepine@my-deja.com>nK Subject: Re: XML Technology for OpenVMS Alpha now available in C++ and Java,) Message-ID: <95uts2$a9c$1@nnrp1.deja.com>w  7 In article <tgBg6.546$cu.2413@gazette.loc1.tandem.com>,g7   "John L Ferguson" <John.L.Ferguson@compaq.com> wrote:	; > C++ and Java ports of the Xerces XML parser and the Xalan5 XSLT stylesheet/4 > processor from xml.apache.org are now available at: > http://www.openvms.compaq.com/openvms/products/ips/xml/.  ? Sounds promising.  I suppose when the info page says the parsers, is "validated" it really means "validating"?  < James Clark's expat non-validating parser in plain C is also@ readily buildable on VMS; Martin Vorlaender posted a patch to do so here:  > <http://www.xray.mpe.mpg.de/mailing-lists/vmsperl/2001-01/msg0
 0032.html>  ! The expat source is available at:   ( <http://sourceforge.net/projects/expat/>  2 expat is at the core of Perl's XML::Parser module.     Sent via Deja.com/ http://www.deja.com/   ------------------------------   End of INFO-VAX 2001.079 ************************