1 INFO-VAX	Sat, 09 Dec 2000	Volume 2000 : Issue 687       Contents:# (Change topic) Fast skipping to EOT ' Re: (Change topic) Fast skipping to EOT ' Re: (Change topic) Fast skipping to EOT , RE: ??== Allocating only one block per file., Re: ??== Allocating only one block per file., Re: ??== Allocating only one block per file., Re: ??== Allocating only one block per file., Re: ??== Allocating only one block per file., Re: ??== Allocating only one block per file., Re: ??== Allocating only one block per file., Re: ??== Allocating only one block per file., Re: ??== Allocating only one block per file.1 Re: Accessing a VMS system from a SUN workstation  Re: Cable modem woes update...4 Re: Here is my Xmas-Present: cdrecord for IDE-drives INITIALIZE/MAXIMUM_FILES Re: INITIALIZE/MAXIMUM_FILES Re: INITIALIZE/MAXIMUM_FILES Re: INITIALIZE/MAXIMUM_FILES Re: INITIALIZE/MAXIMUM_FILES, It's 20 years since I first logged onto VMS! Re: Microsoft copyrighting bugs  Re: One world, one processor, Re: Port (terminal) driver mbx functionality RE: Sun Cluster / Re: TECO, and how to make meaningful line noise / Re: TECO, and how to make meaningful line noise / Re: TECO, and how to make meaningful line noise , Re: Two NEW SKC Postings at www.acersoft.com  F ----------------------------------------------------------------------  % Date: Sat, 09 Dec 2000 08:15:30 +0000  From: Roy Omond <Roy@Omond.net> , Subject: (Change topic) Fast skipping to EOT) Message-ID: <3A31EA22.194FEBFB@Omond.net>    Syltrem wrote:  L > That's a good way of doing it. The main job would submit a bunch of backup; > jobs to the generic queue. No need for SYNCH or anything.  > B > I will do a test for the rewind question when I have a minute... > M > OK. The minutes has finally come. It does rewind the tape, but getting back G > to EOT is pretty fast. EOT follows a save set that took 45 minutes to 6 > record, but getting back to EOT take about 1 minute.  J Just a little note wrt to getting a tape to skip forward to (logical) EOT:  B Modern drives such as DLTs maintain a directory of where tapemarksD are on the tape.  This "directory" is not "visible" in normal usage.@ Look in Sys$Etc: where you will find a couple of files MKSET.TXT< and MKSET.EXE.  MKSET can be used to tell a DLT drive to use> this information for FASTSKIPping to an arbitrary tapemark, inB particular EOT.   Remember that a DLT tape is written in a spiral,J that is write-forward for the length of the tape using a number of tracks,I write-reverse for the length of the tape using a different set of tracks, A write-forward etc. etc.  Standard VMS (e.g. Backup) will forward- < skip to the EOT by dutifully skipping to every tapemark, and? obviously this could entail multiple scans over the whole tape.   = Now, with VMS 7.2 (or 7.2-1 ?), MKSET is obsolete and running C it tells you to use the new /FAST qualifier to the SET MAG command. > It also tells you to use the HELP SET MAG /FAST for more info.B However (and this is a definite bug, though I have not reported itA since I have no mechanism for doing so (I'm an individual !), the < HELP text has not been updated to include the new qualifier.  < However, using this can *drastically* improve the time takenB to reach EOT, *especially* on a tape containing lots of individual8 savesets already (it can be orders of magnitude faster).  ; Oh yeah, the original problem:  to synchronise among backup ? "threads" consider using logical names in a shared logical name F table (e.g. /GROUP) !  The rest of the solution is left as an exerciseB for the reader :-)  I have used this solution at one customer site= where we were relocating the whole data centre, and we needed ; a complete backup (actually multiple backups) of absolutely = everything.  I kept 4 TZ89 drives streaming for about 9 hours @ at a *sustained* 10 to 11 Mbytes/second, and managed to complete@ the entire backup in the tight window given by the customer, andA was within +/- 10 minutes of the estimated time calculated on the  proverbial back-of-envelope :-)   A Thankfully I am no longer at that particular customer site (those : who know me within Compaq will know where it was ... don't mention the name M*** !).   	 Roy Omond  Blue Bubble Ltd.   ------------------------------  % Date: Sat, 09 Dec 2000 12:06:53 +0100   From: Paul Sture <paul@sture.ch>0 Subject: Re: (Change topic) Fast skipping to EOT+ Message-ID: <VA.000001c8.094a17cd@sture.ch>   : In article <3A31EA22.194FEBFB@Omond.net>, Roy Omond wrote:! > From: Roy Omond <Roy@Omond.net>  > Newsgroups: comp.os.vms . > Subject: (Change topic) Fast skipping to EOT' > Date: Sat, 09 Dec 2000 08:15:30 +0000  >  > Syltrem wrote: > N > > That's a good way of doing it. The main job would submit a bunch of backup= > > jobs to the generic queue. No need for SYNCH or anything.  > > D > > I will do a test for the rewind question when I have a minute... > > O > > OK. The minutes has finally come. It does rewind the tape, but getting back I > > to EOT is pretty fast. EOT follows a save set that took 45 minutes to 8 > > record, but getting back to EOT take about 1 minute. > L > Just a little note wrt to getting a tape to skip forward to (logical) EOT: > D > Modern drives such as DLTs maintain a directory of where tapemarksF > are on the tape.  This "directory" is not "visible" in normal usage.B > Look in Sys$Etc: where you will find a couple of files MKSET.TXT> > and MKSET.EXE.  MKSET can be used to tell a DLT drive to use@ > this information for FASTSKIPping to an arbitrary tapemark, inD > particular EOT.   Remember that a DLT tape is written in a spiral,L > that is write-forward for the length of the tape using a number of tracks,K > write-reverse for the length of the tape using a different set of tracks, C > write-forward etc. etc.  Standard VMS (e.g. Backup) will forward- > > skip to the EOT by dutifully skipping to every tapemark, andA > obviously this could entail multiple scans over the whole tape.  > ? > Now, with VMS 7.2 (or 7.2-1 ?), MKSET is obsolete and running E > it tells you to use the new /FAST qualifier to the SET MAG command. @ > It also tells you to use the HELP SET MAG /FAST for more info.D > However (and this is a definite bug, though I have not reported itC > since I have no mechanism for doing so (I'm an individual !), the > > HELP text has not been updated to include the new qualifier. > 5 You mean the following text? Here on Alpha VMS 7.2-1:    SET   	   MAGTAPE        /FAST_SKIP             /FAST_SKIP=option   4        Allows you to skip by file mark or by record.  *                                       NOTE  B           This tape positioning qualifier is for use on local SCSI           tape drives only.   C        PER_IO          Allows a local MK device to use the skip-by- F        (default)       filemarks function. The tape drive must be ableD                        to do a SCSI READ POSITION command and reportE                        blank check at end-of-data. The IO$M_ALLOWFAST D                         function modifier must be supplied with IO$_D                        SKIPFILE. Otherwise, the tape will skip files:                        using the skip-by-records function.  C        ALWAYS          Allows a local MK device to use the skip-by- F                        filemarks function. The tape drive must be ableE                        to support the skip-by-filemarks function, and D                        no modifications should be needed to the IO$_)                        SKIPFILE function.   D        NEVER           Specifies that a local MK device skip only byD                        records. If you use a utility that depends onG                        the semantics of skipping with skip-records, you G                        may also need to use this option since it causes F                        BACKUP or COPY to use the previous positioning.  D The last paragraph of which confuses me. What is meant by "previous 
 positioning"?   > > However, using this can *drastically* improve the time takenD > to reach EOT, *especially* on a tape containing lots of individual: > savesets already (it can be orders of magnitude faster). > = > Oh yeah, the original problem:  to synchronise among backup A > "threads" consider using logical names in a shared logical name H > table (e.g. /GROUP) !  The rest of the solution is left as an exerciseD > for the reader :-)  I have used this solution at one customer site? > where we were relocating the whole data centre, and we needed = > a complete backup (actually multiple backups) of absolutely ? > everything.  I kept 4 TZ89 drives streaming for about 9 hours B > at a *sustained* 10 to 11 Mbytes/second, and managed to completeB > the entire backup in the tight window given by the customer, andC > was within +/- 10 minutes of the estimated time calculated on the ! > proverbial back-of-envelope :-)  > C > Thankfully I am no longer at that particular customer site (those < > who know me within Compaq will know where it was ... don't > mention the name M*** !).  >  Slough?  ___ 
 Paul Sture Switzerland    ------------------------------  % Date: Sat, 09 Dec 2000 14:32:52 -0500 , From: "Glenn C. Everhart" <Everhart@GCE.com>0 Subject: Re: (Change topic) Fast skipping to EOT& Message-ID: <3A324294.DC6494E@GCE.com>  ) The explanation below is not quite right. > Of old, VMS skipped files by skipping records on tape, so that> ucb$l_record could be maintained. On DLT this can be very very< slow since DLT records serpentine fashion. Thus new behavior? was added which mkset can control: if a skip file request tries > to skip more than 2 filemarks, a tape drive will use scsi skip? by filemarks, which is much faster on the whole and can use the A invisible tape directory on DLT to good advantage. To do this the = drive must report a blank tape error if you get past all data @ and the report position command must work right (so ucb$l_record can still be maintained).   = Some applications write and use data after double EOF on ANSI = format tapes. Their existence forced DEC to keep the old skip = by records behavior as default for random programs. MKset can G force it to use new OR old behavior, or allow it to be programmatically ; switched (e.g., by Backup) where "normal" utility use would 	 speed up.   < The new method is not used for skips of 1 or 2 files because: it requires several extra tape commands after each file to; be sure a SCSI skipfile did NOT leave the tape sitting just D after the second EOF of a double EOF mark on tape; the documentation; states VMS will always leave the tape sitting between the 2 ? EOF marks in that case. This means some extra skipping back and = forth, and if you do this with normal tape directories or the = like, it is way slower than the skip by records method (where ) MKdriver knows what is up more directly).   < The directory on tape stuff is correct though, and note that= it has to be written before you write the first data to tape. : This implies a limited size for the directory of tape EOFs< which I believe implies some limit to the number of EOFs the; tape directory can hold. I've heard of DLTs that have 26000  files on them, but not more. Glenn Everhart   Roy Omond wrote: >  > Syltrem wrote: > N > > That's a good way of doing it. The main job would submit a bunch of backup= > > jobs to the generic queue. No need for SYNCH or anything.  > > D > > I will do a test for the rewind question when I have a minute... > > O > > OK. The minutes has finally come. It does rewind the tape, but getting back I > > to EOT is pretty fast. EOT follows a save set that took 45 minutes to 8 > > record, but getting back to EOT take about 1 minute. > L > Just a little note wrt to getting a tape to skip forward to (logical) EOT: > D > Modern drives such as DLTs maintain a directory of where tapemarksF > are on the tape.  This "directory" is not "visible" in normal usage.B > Look in Sys$Etc: where you will find a couple of files MKSET.TXT> > and MKSET.EXE.  MKSET can be used to tell a DLT drive to use@ > this information for FASTSKIPping to an arbitrary tapemark, inD > particular EOT.   Remember that a DLT tape is written in a spiral,L > that is write-forward for the length of the tape using a number of tracks,K > write-reverse for the length of the tape using a different set of tracks, C > write-forward etc. etc.  Standard VMS (e.g. Backup) will forward- > > skip to the EOT by dutifully skipping to every tapemark, andA > obviously this could entail multiple scans over the whole tape.  > ? > Now, with VMS 7.2 (or 7.2-1 ?), MKSET is obsolete and running E > it tells you to use the new /FAST qualifier to the SET MAG command. @ > It also tells you to use the HELP SET MAG /FAST for more info.D > However (and this is a definite bug, though I have not reported itC > since I have no mechanism for doing so (I'm an individual !), the > > HELP text has not been updated to include the new qualifier. > > > However, using this can *drastically* improve the time takenD > to reach EOT, *especially* on a tape containing lots of individual: > savesets already (it can be orders of magnitude faster). > = > Oh yeah, the original problem:  to synchronise among backup A > "threads" consider using logical names in a shared logical name H > table (e.g. /GROUP) !  The rest of the solution is left as an exerciseD > for the reader :-)  I have used this solution at one customer site? > where we were relocating the whole data centre, and we needed = > a complete backup (actually multiple backups) of absolutely ? > everything.  I kept 4 TZ89 drives streaming for about 9 hours B > at a *sustained* 10 to 11 Mbytes/second, and managed to completeB > the entire backup in the tight window given by the customer, andC > was within +/- 10 minutes of the estimated time calculated on the ! > proverbial back-of-envelope :-)  > C > Thankfully I am no longer at that particular customer site (those < > who know me within Compaq will know where it was ... don't > mention the name M*** !).  >  > Roy Omond  > Blue Bubble Ltd.   ------------------------------   Date: 9 Dec 2000 01:00 CST' From: carl@gerg.tamu.edu (Carl Perkins) 5 Subject: RE: ??== Allocating only one block per file. , Message-ID: <9DEC200001005277@gerg.tamu.edu>   IOlson@dairyworld.com writes... B }>From: aus@vim.uni-wuerzburg.de [mailto:aus@vim.uni-wuerzburg.de] }>J }>Is it possible to allocate only one block per disk file without changing }>the cluster size on the disk?  }  }No   = Unless the disk is already at 1 block per cluster, of course.   D Another thing that may be useful, if reconfiguring the existing diskF or acquiring another one is not practical, is to set up a virtual diskF in a container file. There is a driver for doing this in the freeware.  I }>Our OVMS 7.2-1/Alpha receives approximately 1,000 files daily via a FTP 	 }server.   [...] L }If you do HELP INIT/CLUS you will see the parameters you have to work with.F }Basically you can only break up a disk into about 1 million clusters.K }If the disk is larger than 3 million blocks, then clusters of 3 are out of  }the question.D }>Cheers, Hans M. Aus, Wuerzburg, Germany,  aus@vim.uni-wuerzburg.de  C This is no longer the case in the version VMS that he is using. The 3 limit on the number of clusters is much higher now.    --- Carl   ------------------------------  % Date: Sat, 09 Dec 2000 08:30:21 +0000  From: Roy Omond <Roy@Omond.net> 5 Subject: Re: ??== Allocating only one block per file. ) Message-ID: <3A31ED9E.CBCC5BF1@Omond.net>    "Richard D. Piccard" wrote:    > IOlson@dairyworld.com wrote: >  > > >-----Original Message----- E > > >From: aus@vim.uni-wuerzburg.de [mailto:aus@vim.uni-wuerzburg.de]  > >  > 
 > > [snip] >  > > > , > > >How many files can a directory contain? > > O > > I'm not sure what the limit is, but that isn't what you should be concerned  > > with anyway.O > > I have heard a "rule of thumb" that a directory should have fewer than 1000 G > > files in it. If there are more than that you will start to see some E > > performance degradation when/if you create or delete files in it. L > > Having said that, we've got a few directories with over 10000 files thatN > > don't behave "too badly", and a few that are even bigger than that that DO > > behave badly. K > > I would be EXTREMELY reluctant to create directories with 400000 files.eJ > > Can you sub-divide them into (eg) one day? one week?   Think about it. > >O > > >--CG > > >Cheers, Hans M. Aus, Wuerzburg, Germany,  aus@vim.uni-wuerzburg.der > >. > > Ingemar Olsonn. > > IT Department, Sperling     (604) 444-7367 > > Dairyworld FOODS > Q > The limit, as others have pointed out, is the size of the directory file in allrN > but the most recent versions of VMS.  The 1,000 files is a nice round numberK > that can be used unless the filenames are unusually long.  For example, alG > directory containing 1,000 files having filenames of lnk00000000.dat,oQ > lnk00000001.dat, etc., is 59 blocks.  If the filenames are the full legal size,oG > even 1,000 files would be more than a 127-block directory could list.   F Or even better:  give *all* the files the same name, and vary only the@ version number !  That way you can store 32,767 files using very little directory space.    P.s. ;-)  A I've implemented a generalised archival system at a customer siteu@ here in the UK using a combination of ZIP and the VMS Librarian.@ It's been running non-stop for more than 2 years now, and has at? the last count more than 3,000,000 "files" in it, with end-userrC retrieval of individual files using email (DELIVER) taking a couple-A of seconds.  In fact, I *might* be asked to use the same solutionm= for archival of 200,000 files per *day* (somehow I think thatEG the designers are mis-using files as "transactions" ... but I digress).t  	 Roy Omond  Blue Bubble Ltd.   ------------------------------  % Date: Sat, 09 Dec 2000 17:02:37 +0100d, From: aus@vim.uni-wuerzburg.de (Hans M. Aus)5 Subject: Re: ??== Allocating only one block per file. D Message-ID: <aus-0912001702370001@wvia26.virologie.uni-wuerzburg.de>  2 Once again thanks for the powerful suggestions. :)  J My current thoughts are to split the information retrieval into two parts.  I 1) Sometime after midnight, harvest all the daily files, from the last 24l* hours, into one big indexed, annual file.   J 2) During the day, first check the individual file names for the requested case number.  G 3) If the case number is not found among the new daily files then checkT the indexed annual file.   Another question:L  C How do I shutdown just the FTP server during the nightly harvestingaC procedure? The FTP client can queue files while the files are beingi
 processed.   TCPIP v5.0a    --  B Cheers, Hans M. Aus, Wuerzburg, Germany,  aus@vim.uni-wuerzburg.de   ------------------------------  % Date: Sat, 09 Dec 2000 11:12:58 -0600c7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> 5 Subject: Re: ??== Allocating only one block per file.u- Message-ID: <3A32681A.594B3D19@earthlink.net>h   "Hans M. Aus" wrote: > [snip] > Another question:o > E > How do I shutdown just the FTP server during the nightly harvestingTE > procedure? The FTP client can queue files while the files are beinge > processed.  * Well, you may not need to bother the FTPd.  A Use DIRECTORYX/NOHEAD/NOTRAIL/SINCE=YESTERDAY/BEFORE=TODAY (afterdG midnight, of course) and /OUTPUT=filespec to make a list of files up to.5 a point in time. Then, process the files in the list.i  E BTW: The "X" helps cause DCL to ignore symbols that may have been setu for DIR, DIRECT, DIRECTORY, ...r   --   David J. Dachtera  dba DJE Systemsi http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/e  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.v   ------------------------------  % Date: Sat, 09 Dec 2000 12:19:11 -0500e, From: Howard S Shubs <hshubs@mindspring.com>5 Subject: Re: ??== Allocating only one block per file.e> Message-ID: <hshubs-836873.12191109122000@news.mindspring.com>  E In article <aus-0912001702370001@wvia26.virologie.uni-wuerzburg.de>, o- aus@vim.uni-wuerzburg.de (Hans M. Aus) wrote:   K >My current thoughts are to split the information retrieval into two parts.M > J >1) Sometime after midnight, harvest all the daily files, from the last 24+ >hours, into one big indexed, annual file. a >SK >2) During the day, first check the individual file names for the requestedg
 >case number.1 >0H >3) If the case number is not found among the new daily files then check >the indexed annual file.R  O That's about as good as I would come up with myself.  I know because I started  N thinking in that same direction after my most-recent-but-this-one post. <grin>    D >How do I shutdown just the FTP server during the nightly harvestingD >procedure? The FTP client can queue files while the files are being >processed.d  + Depends on which FTP server you're running.m -- . Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------  % Date: Sat, 09 Dec 2000 12:20:34 -0500s, From: Howard S Shubs <hshubs@mindspring.com>5 Subject: Re: ??== Allocating only one block per file.n> Message-ID: <hshubs-7FC955.12203409122000@news.mindspring.com>  B In article <3A32681A.594B3D19@earthlink.net>, "David J. Dachtera" $ <djesys.nospam@earthlink.net> wrote:  F >BTW: The "X" helps cause DCL to ignore symbols that may have been set  >for DIR, DIRECT, DIRECTORY, ...  O Another way to avoid such a problem is to do the scan using code, invoking the  N appropriate RMS routines directly.  I just did that a month or so ago, though  I can't publish the results. -- r Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------  % Date: Sat, 09 Dec 2000 12:04:56 -0600S7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>O5 Subject: Re: ??== Allocating only one block per file.u- Message-ID: <3A327448.B48E4B1E@earthlink.net>h   Howard S Shubs wrote:t > C > In article <3A32681A.594B3D19@earthlink.net>, "David J. Dachtera" & > <djesys.nospam@earthlink.net> wrote: > H > >BTW: The "X" helps cause DCL to ignore symbols that may have been set" > >for DIR, DIRECT, DIRECTORY, ... > P > Another way to avoid such a problem is to do the scan using code, invoking theO > appropriate RMS routines directly.  I just did that a month or so ago, though. > I can't publish the results.  9 I did that some time ago. The results are "published" at:S  . http://www.djesys.com/vms/freeware.html#ppf012- http://www.djesys.com/freeware/vms/ppf012.zip   D See PPF.BAS in that "kit". You can use this (BASIC) code as a model;> however, you'll have to add in your own code to compare dates.> DIR/SIN/BEF seemed easier (to me) than going through all that.   -- i David J. Dachteraa dba DJE Systemsr http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/   F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.o   ------------------------------  % Date: Sat, 09 Dec 2000 14:23:11 -0500 , From: "Glenn C. Everhart" <Everhart@GCE.com>5 Subject: Re: ??== Allocating only one block per file.p' Message-ID: <3A32404F.6E5B2C49@GCE.com>   @ Another thing that is useful is the compressing readonly virtual; disk off the sigtapes; see cmphighc.zip. It lets you make a ? compressed image of a disk, then treat it as a separate volume.   > If you have to keep things online a long-ish time, it can make< it possible to take much less space doing it. I make virtual@ disks, then make these compressed things from them now and again? for such needs.  When I want listings, for example, this allowse@ me to have 4 CD's worth of listings on one physical CD. Stick in> multi-listing CD, run short .com file to start up 4 compressed? disks and mount them, and voila! dta0: thru dta4: appear as thec= 4 listing CDs. The code runs on vax or alpha but does requirea VMS.  > Doing things like this in effect can use less than 1 block per file.:  = This does not really replace conventional backups but give itl; a try. It uses zlib compression, has so far proven reliablee@ and trouble free for the past few years for me. Note though that> you cannot alter the image; it will silently junk any attempts< to write to the image if you don't mount /nowrite. There's a5 goodly amount of cache so read access is pretty fast.    Free and in source, of course. Glenn Everhart   Carl Perkins wrote:u > ! > IOlson@dairyworld.com writes...nD > }>From: aus@vim.uni-wuerzburg.de [mailto:aus@vim.uni-wuerzburg.de] > }>L > }>Is it possible to allocate only one block per disk file without changing! > }>the cluster size on the disk?  > }  > }Nof > ? > Unless the disk is already at 1 block per cluster, of course.n > F > Another thing that may be useful, if reconfiguring the existing diskH > or acquiring another one is not practical, is to set up a virtual diskH > in a container file. There is a driver for doing this in the freeware. > K > }>Our OVMS 7.2-1/Alpha receives approximately 1,000 files daily via a FTPs
 > }server. > [...]4N > }If you do HELP INIT/CLUS you will see the parameters you have to work with.H > }Basically you can only break up a disk into about 1 million clusters.M > }If the disk is larger than 3 million blocks, then clusters of 3 are out ofu > }the question.F > }>Cheers, Hans M. Aus, Wuerzburg, Germany,  aus@vim.uni-wuerzburg.de > E > This is no longer the case in the version VMS that he is using. The 5 > limit on the number of clusters is much higher now.  > 
 > --- Carl   ------------------------------  % Date: Sat, 09 Dec 2000 13:20:18 -0500r, From: Howard S Shubs <hshubs@mindspring.com>5 Subject: Re: ??== Allocating only one block per file.t> Message-ID: <hshubs-EE8711.13201809122000@news.mindspring.com>  B In article <3A327448.B48E4B1E@earthlink.net>, "David J. Dachtera" $ <djesys.nospam@earthlink.net> wrote:  E >See PPF.BAS in that "kit". You can use this (BASIC) code as a model;h? >however, you'll have to add in your own code to compare dates.c? >DIR/SIN/BEF seemed easier (to me) than going through all that.h  L But it likely requires a LIB$SPAWN[ofHELL!!!!!!](), which I've decided is a J solution of Very Last Resort: it's *slow* and has worse quota issues than  simply calling RMS.   J There are a few other RTL routines I try to avoid, but LIB$SPAWN() is the O worst of them, IMHO.  Generally, I include anything done as a wrapper around a sB system service, which is a description which fits LIB$SPAWN() too.  N IMHO, calling system services directly is cooler: it's faster and more likely O to be exactly what I'm looking for, with fewer side effects and lower resource fM requirements.  And it's no less "portable" than the RTL calls, since none of iM -them- is portable either.  The up-front coding may be a little tougher, but  O it only has to be done -once- whereas the benefits of it last for the lifetime h of the product.f  M If I need a LIB$SPAWN(), I look for ways around it such as non-priv'd groups  K of calls to system services or more efficient RTL routines.  I've only run  L into a few situations where LIB$SPAWN() seemed necessary.  Those related to J times when I was trying to get some kind of information, or do something, M which would require writing kernel-mode code to peek, or poke, around inside dM S0 space.  -Then- I'll use LIB$SPAWN() as the more maintainable solution.  I  N avoid writing kernel-mode code when I'm working on something for other people N which will need to be maintained by others or run on a production box of some  sort.  -- o Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------  $ Date: Sat, 9 Dec 2000 14:14:30 +0100/ From: sbl+news@dd.chalmers.se (Stefan Berglund)n: Subject: Re: Accessing a VMS system from a SUN workstationB Message-ID: <slrn934c1m.cmc.sbl+news@ardamir.local.dd.chalmers.se>  E On Thu, 07 Dec 2000 08:28:35 -0500, jamese@beast.dtsw.army.mil wrote:t3 > "Marc Van Dyck" <marc.vandyck@skynet.be> wrote innC > <90jlsl$b17$1@news1.skynet.be> on Tue, 5 Dec 2000 22:16:24 +0100:d > # > > Thanks to all who have replied.  > > P > > With your help, my Unix specialist has been able to solve the problem, using > > the following method : > > O > > 10 an input file to Xmodmap to re-assign the keys so that they look as muchMN > >    as possible like a VMS keyboard. This also disables the local effect ofJ > >    the 'num lock' key, so that it can act as the usual gold key on the > >    remote machine; > > O > > 20 a second input file to Xmodmap to reset the normal situation, which also ( > >    re-establishes the num lock key ; > > L > > 30 a toggle program, that activates either 10 or 20, driven by two keys,= > >    declared as hot keys in the setup of my motif session.k > > F > > I'm at home so I can not give much more details, but if someone isM > > interested, I can bring the files from the office on a floppy and publishi > > them here. > L > Yes, I'm very interested. Please publish your files to info-vax. Thank you > and thanks to your Unix guru.P  = You can also look at the decxterm script posted to this groupeD (Message-ID: <8m4uph$a44$1@mailint03.im.hou.compaq.com>), search for5 decxterm in comp.os.vms on deja and you will find it. F It starts an xterm and remaps the keyboard to match VMS, it works with Sun, AIX, Linux and Tru64.( I have used in on Sun with good results.  C I like this solution better than xmodmap as it is only the terminaluG connected to the vms-system that is affected by the "strange" keysetup.u   -- t
 			/Stefan 			sbl+news@dd.chalmers.se  " Life - the ultimate practical joke   ------------------------------  % Date: Sat, 09 Dec 2000 11:33:10 -0600 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> ' Subject: Re: Cable modem woes update...n- Message-ID: <3A326CD6.FCDC300B@earthlink.net>-   JF Mezei wrote:  > U > It is most interesting how cable companies are having trouble supporting customers.o > N > It makes the traditional landline telephone companies look 100% perfect. HowL > much time do you spend discussing with the phone company why you don't get > dial-tone on your phone ?s > M > Anyhow, after spending a whole day on the phone (most of it on hold) to theo1 > cable company, I was given the following story:y > S > (Applies to Samsung cable modems, whose motherboard is supposedly made by Cisco).g > O > If the modem has X IP addresses provisioned, it will only route DHCP requests J > from the first X ethernet adresses that the modem will see on the lan no/ > matter what protocol these ether packets are.  > L > So, if you have one IP that is provisioned, and 3 machines, the modem willM > only allow the first machine it sees to transmit DHCP requests even if thata+ > first machine doesn't do any TCPIP stuff.  > N > Sounds to me like a major oversight in the people who designed those modems.   Perhaps.  F ...; however, there is a simple work-around. Not as cheap as one mightE want, and perhaps not what you wanted to "hear"; but that's why theren@ are cable/DSL routers in the world. They essentially perform theE "Internet Connection Sharing" (in gates-ish) function: NAT to the web  and DHCP and even DNS locally.  G This function is also available in 3com's LANmodems and similar devicesB from other manufacturers.D  A I use 3com's LANmodem here to facilitate internet access for thisrE machine, the PC I built for my wife, as well as my hobbyist Alpha andiF MicroVAX machines. When/If we go DSL (cable is also available), I willF replace that with some suitable device to provide the same features we enjoy here now.a   -- h David J. Dachtera  dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/a  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.a   ------------------------------  " Date: Sat, 9 Dec 2000 10:45:34 GMT( From: Terry Kennedy <terry@gate.tmk.com>= Subject: Re: Here is my Xmas-Present: cdrecord for IDE-drives.' Message-ID: <G5Ar7y.4Dn@spcuna.spc.edu>s  C Eberhard Heuser-Hofmann <vaxinf@dg3.chemie.uni-konstanz.de> writes:oM >> I have decided to spend some money and bought a very recent IDE-CDRW-drive J >> with so called "burnproof"-option build in ("Forget the buffer underrun > problem"), >> a TEAC CD-W512EB.  H   Note that you have to specifically ask for the "burn-proof" mode to beH turned on in these recorders - it is *not* the default (except possibly = in manufacturer-supplied utilities that come with the drive).0  4         Terry Kennedy             http://www.tmk.com5         terry@tmk.com             Jersey City, NJ USA    ------------------------------   Date: 9 Dec 2000 10:53:26 GMT * From: helbig@astro.rug.nl (Phillip Helbig)! Subject: INITIALIZE/MAXIMUM_FILESe. Message-ID: <90t2v6$cjb$1@info.service.rug.nl>   I'm doing some disk shuffling.  H Normally, I like the "sensible defaults" on VMS.  However, /HEADERS has G a default of 16, while the recommended value is the number of files on mI the disk!  Thus, for performance reasons, one wants to estimate how many "F files will be on the disk and set /HEADERS to this MUCH larger number.  I There is also the /MAXIMUM_FILES qualifier.  The default seems to be set eG to half the hard-value maximum, and is usually at least a factor of 10 EI larger than the number of files I expect, so I guess I could go with the  I default here.  However, I'm wondering why /MAXIMUM_FILES doesn't default aI to the hard-wired maximum value.  I can think of circumstances where one )H perhaps would want to set it to some (much lower) specific number, so I E can understand why this qualifer exists.  My question is, why is the kF default half the hard-wired maximum?  Is there any sort of penalty in F setting it to the real maximum, twice the default?  This is a crucial D question, since the value can only be changed by reinitializing the  volume.n  H I'll stick with the default /CLUSTER_SIZE for now.  However, this means E that the maximum number of files increases much more slowly than the tI size of the disk.  If one has a big disk with many small files, then one nH might want to lower the cluster size.  Does anyone have a rule of thumb F for estimating the best cluster factor depending on the statistics of F the files on the disk, perhaps with options maximising performance or  minimising wasted disk space.    ------------------------------   Date: 9 Dec 2000 10:58:58 GMT * From: helbig@astro.rug.nl (Phillip Helbig)% Subject: Re: INITIALIZE/MAXIMUM_FILES . Message-ID: <90t39i$cjb$2@info.service.rug.nl>  B In article <90t2v6$cjb$1@info.service.rug.nl>, helbig@astro.rug.nl (Phillip Helbig) writes:    G Is there any way to get the values of /HEADERS and /MAXIMUM_FILES with rD which a disk was initialised?  There is MAXFILES in F$GETDVI, which E returns the default for my disk, which is probably what I used.  Why R; isn't there something similar to get the value of /HEADERS?g   ------------------------------    Date: 10 Dec 2000 00:19:25 +0800, From: Paul Repacholi <prep@prep.synonet.com>% Subject: Re: INITIALIZE/MAXIMUM_FILESt0 Message-ID: <877l59lg8i.fsf@k9.prep.synonet.com>  , helbig@astro.rug.nl (Phillip Helbig) writes:  D > In article <90t2v6$cjb$1@info.service.rug.nl>, helbig@astro.rug.nl > (Phillip Helbig) writes:   > I > Is there any way to get the values of /HEADERS and /MAXIMUM_FILES with oF > which a disk was initialised?  There is MAXFILES in F$GETDVI, which G > returns the default for my disk, which is probably what I used.  Why a= > isn't there something similar to get the value of /HEADERS?s  @ Because it is not explicitly recorded anywhere. You MAY find the? size from dumpimg the header and seeing the size of the extent, C but you can't be sure that indexf.sys was not extended contiguouslyh" before it created an extra extent.  7 I look at the header size in [0,0] and punt from there.o   ~Paul-   ------------------------------  % Date: Sat, 09 Dec 2000 12:15:41 -0600r7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>t% Subject: Re: INITIALIZE/MAXIMUM_FILESi- Message-ID: <3A3276CC.6E92EDC9@earthlink.net>    Phillip Helbig wrote:i > [snip]I > I'll stick with the default /CLUSTER_SIZE for now.  However, this means F > that the maximum number of files increases much more slowly than theJ > size of the disk.  If one has a big disk with many small files, then oneI > might want to lower the cluster size.  Does anyone have a rule of thumb G > for estimating the best cluster factor depending on the statistics of G > the files on the disk, perhaps with options maximising performance orv > minimising wasted disk space.t  H I snipped the earlier stuff because I'm not as well qualified to address% them as others in the group might be.a  C As to cluster size, I just make it a rule to stick with the minimumb. clustersize allowed for any given disk volume.  D One quirk I have developed, however, is that I like to use a defaultG /EXTENSION size of the clustersize squared. This is not always the bestgD rule, especially on a volume that gets many small files very rapidlyF (free space fragmentation builds up more quickly than you might like).F However, in general, it has served its intended purpose: minimize fileD fragmentation where large extents are not otherwise pre-allocated toF files which might need them before they get closed after being created< by a program (OPEN/WRITE in DCL, FOR OUTPUT in BASIC, etc.).   -- g David J. Dachtera  dba DJE Systemst http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/-  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.A   ------------------------------  % Date: Sat, 09 Dec 2000 14:36:25 -0500h, From: "Glenn C. Everhart" <Everhart@GCE.com>% Subject: Re: INITIALIZE/MAXIMUM_FILES ' Message-ID: <3A324369.48172A6F@GCE.com>.  D /headers starts small because occasionally people want to have disks) that have a very few giant files on them.s< /maxfiles specifies how large the index file bitmap will be.? You don't want to waste space making this take up way more room  than you need.  > Admittedly with multigigabyte disks this is less an issue than? it was on RD53 with 70 megs but it is still reasonable to think.$ a bit about usage before setting it.  4 By now too people are used to the existing defaults.   Phillip Helbig wrote:  >   > I'm doing some disk shuffling. > I > Normally, I like the "sensible defaults" on VMS.  However, /HEADERS hasoH > a default of 16, while the recommended value is the number of files onJ > the disk!  Thus, for performance reasons, one wants to estimate how manyH > files will be on the disk and set /HEADERS to this MUCH larger number. > J > There is also the /MAXIMUM_FILES qualifier.  The default seems to be setH > to half the hard-value maximum, and is usually at least a factor of 10J > larger than the number of files I expect, so I guess I could go with theJ > default here.  However, I'm wondering why /MAXIMUM_FILES doesn't defaultJ > to the hard-wired maximum value.  I can think of circumstances where oneI > perhaps would want to set it to some (much lower) specific number, so IhF > can understand why this qualifer exists.  My question is, why is theG > default half the hard-wired maximum?  Is there any sort of penalty in,G > setting it to the real maximum, twice the default?  This is a cruciallE > question, since the value can only be changed by reinitializing the 	 > volume.  > I > I'll stick with the default /CLUSTER_SIZE for now.  However, this meanssF > that the maximum number of files increases much more slowly than theJ > size of the disk.  If one has a big disk with many small files, then oneI > might want to lower the cluster size.  Does anyone have a rule of thumbuG > for estimating the best cluster factor depending on the statistics ofpG > the files on the disk, perhaps with options maximising performance ori > minimising wasted disk space.o   ------------------------------  % Date: Sat, 09 Dec 2000 11:33:34 +0100   From: Paul Sture <paul@sture.ch>5 Subject: It's 20 years since I first logged onto VMS!w+ Message-ID: <VA.000001c7.092b96ea@sture.ch>.  F If I've got my dates right, on 8-DEC-1980, I logged into my first VMS  system.o ___ 
 Paul Sture Switzerlandt   ------------------------------   Date: 9 Dec 2000 14:46:05 GMT / From: Thomas Dickey <dickey@saltmine.radix.net>u( Subject: Re: Microsoft copyrighting bugs* Message-ID: <90tgjd$e6r$1@news1.Radix.Net>  " Shane.F.Smith@healthnet.com wrote:M > Interesting article in the register. Here's the first couple of paragraphs:s  K > - Microsoft is claiming copyright over its security notices and insistinge > thatL > - mailing lists can no longer publish the Beast of Redmond's dire security
 > - warnings.n > -lM > - The lawyers at Microsoft have objected to the publication of its securitypI > - notices by SecurityFocus.com, which runs the popular BugTraq security4 > - mailing list.   L which doesn't preclude fair use (quoting - or paraphrasing - for the purpose of criticism).   --  = Thomas E. Dickey <dickey@radix.net> <dickey@herndon4.his.com>  http://dickey.his.comu ftp://dickey.his.com   ------------------------------   Date: 9 Dec 2000 11:55:40 GMTu' From: david20@alpha2.mdx.ac.uk (D.Webb)l% Subject: Re: One world, one processorh0 Message-ID: <90t6js$c69$1@aquila.news.mdx.ac.uk>  x In article <OF69F1A827.B3F348DC-ON032569AF.005BCF4B@ep-bc.petrobras.com.br>, fabio_compaq@ep-bc.petrobras.com.br writes:: >One world, 5  processors and less operating systems ! ! ! >iE >How many versions of Unixes are running in the market ? 20 on RISC ?@+ > Plus 100 in Intel (Linuxes versions) ????B >4C >Open Systems create hundreds of processors, os. versions, etc ....t$ >Why not consolidate a few of them ? >oI >I am not saying merging Tru64 with Solaris or AIX, but for example, mig=o >ratec* >DG-UX, Sinix  to other processors/unixes. >i4 >Why do we have 3 or 4 versions of Linux for Alpha ? > I >It=B4s WASTE of money, resources, and ideas ..... it=B4s a BIG WASTE to=  > have@ >a company developing software /  drivers for all these OSes.... >g >S >Regards >r >FCe >t >   C I thought you were talking about processors not operating systems. HG The high cost of design and manufacture already mean that the number ofrM companies producing processors is not very large. Further consolidation therem is not required. i  N As to OS's the answer is basically the same. We have so many Operating systemsO because each company percieves that they must be slightly different in order to" compete.  & The classic example of course is UNIX.G Unix salesmen always used to somehow combine two diametrically opposing ' statements when selling UNIX systems :-s  K Our Unix sticks to the standards. With the strong implication that anythingl/ written for any Unix would run on their system. ' ie the There is only one Unix argument.i   andT  O Our Unix is better than all these other Unixes. We've added on all these extra a (non-standard) features.    O There have been Unix standardisation attempts for a generation. There has been  N some success the differences between Unixes have been reduced somewhat howeverH each company needs to be able to differentiate their product in order to survive.  O The alternative is that the companies either go under or end up providing addonbO products to support another companies OS. That way ultimately leads to a singleSG company being in a monopolistic position as we have already seen on thes desktop.  -  N Also remember when talking about the number of different versions of Unix thatO to a large extent Unix was a consolidation of Operating systems. A large numberrO of companies which had their own 'proprietary' Operating systems 'standardised'n on Unix.    M As to the waste argument. This is the classic argument against capitalism and.- in favour of a centrally controlled economy. e      
 David Webb VMS and Unix team leader CCSS Middlesex University   >  >e >p >d >  >  >  >i >y >  >p >y >i >p >a4 >david20@alpha2.axp.mdx.ac.uk em 08/12/2000 11:25:28 >o/ >Favor responder a david20@alpha2.axp.mdx.ac.ukmI >                                                                       =l >    =20I >                                                                       =, >    =20I >                                                                       =0 >    =20 >u >iA >                                                             =20-A >                                                             =20 A >                                                             =20hA > Para:    Info-VAX@Mvb.Saic.Com                              =20oA >                                                             =20dA > cc:      (bcc: Fabio dos Santos Cardoso/E-P-BC/Contratada)  =20 A >                                                             =20iA >                                                             =20 A >                                                             =20eA > Assunto: Re: One world, one processor                       =20eA >                                                             =20m >d >m >  >  >b >= >  >c >In articlekB ><OF93FD230C.0C99E54E-ON032569AF.00457D51@ep-bc.petrobras.com.br>,, >fabio_compaq@ep-bc.petrobras.com.br writes:E >>I believe in the creation of the new wave: PROCESSOR CONSOLIDATION. + >>Stop with this myriad of processors . . .  >> >f) >Rubbish. That is the last thing we need.eI >Consolidation closes down the exploration of alternative paths to impro=  >vedF >performance. If you have only one type of chip you are constrained by@ >the historic design decisions which went into making that chip.I >Why is Intel making the IA-64 chip ? Answer because other companies had=i >hF >moved to 64 bit. If there were no other chips Intel would have littleI >incentive to do anything but keep on marginally improving their current=  >h >chips.yI >There would be no reason to invest lots of money in any radical new des=n >ign.h > G >(True at some point they would have to - but only because some startuph >companyI >had produced or was about to produce a new chip design which offered th=a >eI >improved performance customers wanted. And we might be waiting a long t=t >ime >for? >that to happen because the startup costs would be horrendous).  >mI >Now it might be argued that in a few years time we would have reached t=t >heaF >limits of what can be done with silicon and all the tricks to improveI >performance will have been tried. At that point it could be argued that=i > theeI >final silcon chip design will be created and everything will consolidat=T >e onuI >that. However research is already underway into optical computing and o=t >therdI >designs which means that I'd doubt that such a consolidation would actu=a >allyeC >happen. Instead you might well see a number of radically differenth >approaches A >competing in the market place which would make the architecturalr >differences5 >between IA-64, Alpha and SPARC chips seem miniscule. G >And what drives this research. Answer : The perceived need to increaseA >performance + competition.  >m >h >David Webbe >VMS and Unix team leadere >CCSSt >Middlesex Universityc >sI >>To the end-customer it=3DB4s important to stay with Alpha architecture=h >.. L=3D >>astm >>year we changed ourDI >>Alphaservers 4100 running Windows NT + Lotus Notes to Proliant 8500 + =e >N=3Dv >>T.I >>What mess... transfer 7500 users from one 2 machine cluster to another=y >..=3D >>, >>Just becase Compaq decided stop WNT/Alpha. >>I >>Imagine porting all the Alpha applications to IA-64 ? Wil be the end o=S >f=3De >> >>OpenVMS, because6 >>a lot of customers will decide to port to Unix...... >>I >>The market should have the max of 4, 5 processor lines.....  Alpha, Sp=c >a=3Dn >>rc,v >>Intel, MIPS, Power PC. >> >>It=3DB4s enough....s >>	 >>Regards- >> >>FC >> >> >> >> >> >> >> >>8 >>Alan Greig <agreig@my-deja.com> em 08/12/2000 08:23:44I >>                                                                      =e > =3DD >>    =3D20@I >>                                                                      =. > =3Dt >>    =3D20vI >>                                                                      =w > =3Dc >>    =3D20o >> >>D >>                                                             =3D20D >>                                                             =3D20D >>                                                             =3D20D >> Para:    Info-VAX@Mvb.Saic.Com                              =3D20D >>                                                             =3D20D >> cc:      (bcc: Fabio dos Santos Cardoso/E-P-BC/Contratada)  =3D20D >>                                                             =3D20D >>                                                             =3D20D >>                                                             =3D20D >> Assunto: Re: One world, one processor                       =3D20D >>                                                             =3D20 >> >> >> >> >> >>=3Du >> >>G >>On 08 Dec 2000 02:06:58 GMT, dashw459@aol.comeatspam (Doug W.) wrote:e >>I >>>The following quote was taken from an article ONE WORLD, ONE PROCESSO=M >R=3Dq >> byr0 >>>Linley Gwennap in the December LINUX JOURNAL. >>>eI >>>..."Compaq, HP and SGI have slowed the pace of their architectures (A=o >l=3D  >>pha,I >>>PA-RISC and MIPS, respectively) to the point that they have fallen be=h >h=3DM >>indS >>XeonF >>>in performance in many key applications.  This decline has caused a
 >>downward( >>>spiral in the sales for RISC vendors. >>>lI >>>  As a result, HP and SGI have already announced they will eventually=q >tF >>>discontinue their RISC lines, and Compaq is likely to follow suit." >>E >>And if Compaq don't jump on statements like this then quite bluntlyh= >>they are probably true - whatever Compaq employees are told E >>internally. We keep hearing about all the Alpha development work inRA >>the pipeline but the hard facts are that Alpha should really belA >>shipping at 1.6Ghz EV68 by now. It is difficullt to see all the D >>promised enhancements materialising when the pace has been so slowE >>over the last two years. There hasn't really been any *significant*eI >>upggrades since the 500Mhz EV6 over two years ago. I do not consider a=, >rA >>less than 2:1 performance hike in over two years good progress.k >>F >>If EV8 is not to be the last Alpha chip then Compaq had better start >>taking its gloves off. >>G >>And VMS engineering had better keep their eyes on IA-64 just in case.9 >> >>-- >>Alan Greig >> >> >>=3Dc >> >> >c >1 >= >e >c   ------------------------------   Date: 9 Dec 2000 07:11:43 -0500e9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)i5 Subject: Re: Port (terminal) driver mbx functionalityi+ Message-ID: <UCyPgUBTV+lb@eisner.decus.org>y  O In article <90rqe6$c6e$1@nnrp1.deja.com>, marinto <marinto@my-deja.com> writes:tI > I need to find out how to do some similar things with a port (terminal)0  > device as I do with a mailbox.  E Then you need to read the I/O Users Guide from the VMS Documentation.sC It came on a CD-ROM with your copy of the operating system, or yourPC site may have bought it in hardcopy.  As a last resort you can read.A it on the Internet by starting at http://www.openvms.compaq.com .e  A The bits for all devices are the same -- they just have different  meanings :-)  F The good news is that whatever you want to do can most likely be done,G since over the 22 years of VMS customers have complained about featureseF they felt were lacking, and VMS Development has added them !  If thereD is something still missing that you are the only one in the world to+ notice, it might be added in about 5 years.   N ==============================================================================N Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> ClustersN ==============================================================================   ------------------------------   Date: 9 Dec 2000 07:24:30 -0500R9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)9 Subject: RE: Sun Cluster+ Message-ID: <MtyB71G9tMOB@eisner.decus.org>   | In article <910612C07BCAD1119AF40000F86AF0D805284AC0@kaoexc3.kao.cpqcorp.net>, "Main, Kerry" <Kerry.Main@COMPAQ.com> writes: > Andrew, Andrew ..  > 5 > Come on now, you can do fud much better than this. i > - > The attached is way to easy to blow off .. v > L >>>> but not by being a source of radical ideas or technical inovations. <<< > K > Yep, like "Computers 101" which states one should use ECC on cache if youo# > feel data integrity is important.   C Kerry, you obviously have no understanding of marketing and producteB positioning.  Sun is after that market segment that wants to spendC a million dollars on a machine, but _not_ have reliable operations.oC This is a segment unaddressed by legacy operating systems like VMS,h MVS, and even AS400.  N ==============================================================================N Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> ClustersN ==============================================================================   ------------------------------  % Date: Sat, 09 Dec 2000 15:39:42 +0800g- From: David B Sneddon <dbsneddon@bigpond.com>i8 Subject: Re: TECO, and how to make meaningful line noise? Message-ID: <3.0.6.32.20001209153942.0079d100@mail.bigpond.com>   3 At 06:51 PM 12/8/00 +0000, Christopher Smith wrote:t >/B >I thought this might be sort of ano appropriate place to ask this: >question, even though it's not absolutely VMS specific... >eJ >Does anyone know where I can find a TECO reference?  Electronic, printed,* >or preferably one of each would be great. >e	 >Regards,e >o >Chris  = Goto the software link below, there is a copy of the TECO V40a? user guide and language manual and a couple of others - towardsa the bottom of the page.6     Regards, Dave.eI ------------------------------------------------------------------------- I David B Sneddon (dbs)  OpenVMS Systems Programmer   dbsneddon@bigpond.comcI Sneddo's quick guide...           http://www.users.bigpond.com/dbsneddon/hI DBS freeware at ...   http://www.users.bigpond.com/dbsneddon/software.htm'I "Life is what happens to you while you're busy making other plans" Lennon    ------------------------------   Date: 9 Dec 2000 07:20:08 -0500s9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) 8 Subject: Re: TECO, and how to make meaningful line noise+ Message-ID: <VyNVK4CtUzE5@eisner.decus.org>    In article <Pine.LNX.4.05.10012081849220.2597-100000@Mufasa.pubserv.com>, Christopher Smith <chriss@Mufasa.pubserv.com> writes:o  K > Does anyone know where I can find a TECO reference?  Electronic, printed,h+ > or preferably one of each would be great.a  = I suppose now is a good time to start a rumor that the secondA< Software Developers Kit for VMS V7.3 will contain a new TECO< manual on the CD-ROM.  Of course since this is TECO, a "new"; manual would be anything less than 20 years old and using a0 proportional font.  A If the above were all true, do you suppose that it is responsiblee> for the delay between the first and second Software Developers= Kit for VMS V7.3 ?  V7.2-1H1 was the release for Wildfire, sos< perhaps V7.3 will be the release for the new TECO manual :-)  N ==============================================================================N Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> ClustersN ==============================================================================   ------------------------------  % Date: Sun, 10 Dec 2000 00:23:54 +0800 - From: David B Sneddon <dbsneddon@bigpond.com>C8 Subject: Re: TECO, and how to make meaningful line noise? Message-ID: <3.0.6.32.20001210002354.007a1e90@mail.bigpond.com>o  C At 07:20 AM 12/9/00 -0500, Kilgallen@eisner.decus.org.nospam wrote:iJ >In article <Pine.LNX.4.05.10012081849220.2597-100000@Mufasa.pubserv.com>,5 Christopher Smith <chriss@Mufasa.pubserv.com> writes:t >sL >> Does anyone know where I can find a TECO reference?  Electronic, printed,, >> or preferably one of each would be great. >-> >I suppose now is a good time to start a rumor that the second= >Software Developers Kit for VMS V7.3 will contain a new TECOe= >manual on the CD-ROM.  Of course since this is TECO, a "new"t< >manual would be anything less than 20 years old and using a >proportional font.   9 Does that mean that my Version 40 manual (1985) is "new"?-, Although it is not proportional font...  :-(  B >If the above were all true, do you suppose that it is responsible? >for the delay between the first and second Software Developers>> >Kit for VMS V7.3 ?  V7.2-1H1 was the release for Wildfire, so= >perhaps V7.3 will be the release for the new TECO manual :-)i >sL >=========================================================================== ===lF >Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> ClustersL >=========================================================================== ===r >p   Regards, Dave.cI ------------------------------------------------------------------------- I David B Sneddon (dbs)  OpenVMS Systems Programmer   dbsneddon@bigpond.comrI Sneddo's quick guide ...          http://www.users.bigpond.com/dbsneddon/eI DBS freeware at ...   http://www.users.bigpond.com/dbsneddon/software.htm-I "Life is what happens to you while you're busy making other plans" Lennon2   ------------------------------  $ Date: Sat, 9 Dec 2000 02:11:51 -0500' From: "Bill Todd" <billtodd@foo.mv.com>n5 Subject: Re: Two NEW SKC Postings at www.acersoft.com.( Message-ID: <90slrh$fmt$1@pyrite.mv.net>  = Terry C. Shannon <terryshannon@mediaone.net> wrote in messageg8 news:IchY5.41071$M51.14206170@typhoon.ne.mediaone.net...8 >       OpenVMS: A Renaissance OS for The New Millennium  - "OpenVMS marketing no longer is an oxymoron."n  B ... unless you look for efforts beyond the existing customer base.   >  >       and...? >      Nearer My InfiniBand to Thee: Compaq Debuts ServerNet IIm  J "Significantly, Compaq's efforts will begin with the ProLiant platform..."    Kind of says it all right there.   - bill   ------------------------------   End of INFO-VAX 2000.687 ************************