1 INFO-VAX	Sat, 15 Jul 2000	Volume 2000 : Issue 392       Contents: Alpha PWS500a(u) Re: Alpha PWS500a(u)% Re: Apache for Open VMS, performance? 8 Re: Autoconfig and OpenVMS - Was RE: got to remember .... Choosing Values for $ SET FILE/GLOBAL_BUFFER=n2 Re: Choosing Values for $ SET FILE/GLOBAL_BUFFER=n2 Re: Choosing Values for $ SET FILE/GLOBAL_BUFFER=n" Re: CompactTape II sources (TK70)?" Re: CompactTape II sources (TK70)?" Re: CompactTape II sources (TK70)?+ Re: Configuring NFS on VMS 7.1 on alpha box  DCL coding question  Re: DCL coding question  Decwrite: where to get?  Re: Decwrite: where to get?  Re: Find Files utility Re: FTP to/from Alpha boxes 4 Re: got to remember to STOP trying to use OpenVMS...4 Re: got to remember to STOP trying to use OpenVMS...4 Re: got to remember to STOP trying to use OpenVMS...4 Re: got to remember to STOP trying to use OpenVMS...D RE: I/O caching and UNIX evaluations (was: Re: got to remember ..	.)D Re: I/O caching and UNIX evaluations (was: Re: got to remember ..	.)D Re: I/O caching and UNIX evaluations (was: Re: got to remember ..	.)D Re: I/O caching and UNIX evaluations (was: Re: got to remember ..	.)C Re: I/O caching and UNIX evaluations (was: Re: got to remember ...) C Re: I/O caching and UNIX evaluations (was: Re: got to remember ...) C Re: I/O caching and UNIX evaluations (was: Re: got to remember ...) C Re: I/O caching and UNIX evaluations (was: Re: got to remember ...) C Re: I/O caching and UNIX evaluations (was: Re: got to remember ...) C Re: I/O caching and UNIX evaluations (was: Re: got to remember ...) C Re: I/O caching and UNIX evaluations (was: Re: got to remember ...) C Re: I/O caching and UNIX evaluations (was: Re: got to remember ...) C Re: I/O caching and UNIX evaluations (was: Re: got to remember ...)  Re: ibm 18 gig drives  Re: ibm 18 gig drives  Re: ibm 18 gig drives  Re: IDE CD-ROM audio support?  Re: IDE CD-ROM audio support? < Looking for VAX->Alpha SCAN port? (was: VMS Pascal question)) Re: New Posting from Shannon Knows Compaq  Re: Old VMS Manuals, Ver 4.7 Re: Old VMS Manuals, Ver 4.7$ Re: print/delete dows not behave ...* Re: SQL+ODBC options, inexpensive or free?' Re: TCPIP remote node in audit security ' Re: TCPIP remote node in audit security ! Re: UCX 4.2 -> TCPIP 5.0A upgrade  Re: Using CMS and NFS  Re: VMS 7.3 wish list  Re: VMS 7.4 wish list  Re: VMS 7.4 wish list  Re: VMS 7.4 wish list  Re: VMS Pascal question  Re: VMS Pascal question  weight loss products Re: WTB TK50 Cartridges 2 [Q] What SCSI tapes drives does VMS 5.5-2 support?6 Re: [Q] What SCSI tapes drives does VMS 5.5-2 support?6 Re: [Q] What SCSI tapes drives does VMS 5.5-2 support?  F ----------------------------------------------------------------------  % Date: Fri, 14 Jul 2000 21:17:46 -0400 - From: "Island Computers" <sales@islandco.com>  Subject: Alpha PWS500a(u) / Message-ID: <smvem3qgnd6104@corp.supernews.com>    Get em whilst they're hot !!!!  
 Ebay Item#  A  http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=382645921    --   Island Computers US Corporation  2700 Gregory Street  Savannah GA 31404  Tel: 912 447 6622  Fax:912 201 0096 sales@islandco.com   ------------------------------  % Date: Fri, 14 Jul 2000 23:02:45 -0400 2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: Alpha PWS500a(u) L Message-ID: <rdeininger-1407002302450001@user-2ivebgl.dialup.mindspring.com>  ^ In article <smvem3qgnd6104@corp.supernews.com>, "Island Computers" <sales@islandco.com> wrote:    > Get em whilst they're hot !!!! >  > Ebay Item# > C >  http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=382645921  >    David,  E   Maybe I'm just slow this evening, but if the price is firm at $1495 F each, why bother to put them in an auction?  And why start the bidding at $1?   --   Robert Deininger rdeininger@mindspring.com    ------------------------------   Date: 15 Jul 2000 01:35:33 GMT1 From: JONESD@er6.eng.ohio-state.edu (David Jones) . Subject: Re: Apache for Open VMS, performance?: Message-ID: <8kof55$2tn$1@charm.magnus.acs.ohio-state.edu>  , In message <8kn9jn$kg2@gap.cco.caltech.edu>,6   mathog@seqaxp.bio.caltech.edu (David Mathog) writes:J >No need for me to do it - OSU already runs on Tru64.  Or at least it usedJ >to last time I looked.  Interesting question though - how well did it runE >there compared to the OpenVMS version.  DJ - any benchmarks on that?   N It runs faster on DU than OpenVMS, it's been a while since I tested it though.J On my Linux box (a 200Mhz Cyrix-based PC), the OSU server is 10-15% faster> than the Apache (1.3.4) that came with the Linux installation.    < David L. Jones               |      Phone:    (614) 292-6929- Ohio State University        |      Internet: L 140 W. 19th St. Rm. 231a     |               jonesd@er6s1.eng.ohio-state.edu: Columbus, OH 43210           |               vman+@osu.edu  + Disclaimer: Dogs can't tell it's not bacon.    ------------------------------  # Date: Sat, 15 Jul 2000 03:15:30 GMT ' From: nickerson@pundit.ds.boeing.com () A Subject: Re: Autoconfig and OpenVMS - Was RE: got to remember ... ( Message-ID: <FxpyDu.Lxy@news.boeing.com>  , In article <S7Yu14EAE8lD@eisner.decus.org>, 4 malmberg@eisner.decus.org (John E. Malmberg) writes: ..  > [about autoconf, configure, config.h, config.h.in, makefile.in and about their use and abuse] ..A well I snipped it all finally because I couldn't decide what gave D the best context; I give a "me to" rant; those "tools" (sic) surely > are no help on VMS and very difficult to appreciate; they are D frustrating in exponential proportion to their size and complexity;   E I too go through many interations of editing a VMS specific config.h  B based on config.h_in and let the DECC compiler and linker lead me @ along; my last effort on VMS 7.2 with the CVS client had me very? frustrated because the code was not even correctly #ifdef'ed on * common decision points like HAVE_DIRENT_H;  @ coming from VMS land I don't even like them on unix; while they ? allow the most naive system manager to build a tool, they don't > have the flexibility and readability required; for me the same> applies to makefiles - although I know I'm just being stuborn;   --bn (Bart Nickerson)  nickerson@pundit.ds.boeing.com (206) 662-0183   ------------------------------  # Date: Fri, 14 Jul 2000 17:53:59 GMT - From: "Richard D. Piccard" <piccard@ohio.edu> 7 Subject: Choosing Values for $ SET FILE/GLOBAL_BUFFER=n ( Message-ID: <396F53B4.EFEDEBD6@ohio.edu>  D The short version:  How do I choose a value for the number of global$ buffers to use with an indexed file?     The long version:     : System:  VMS 6.2, soon to be 7.2-1, on Alpha 2100, 512 MBy  
 Example file:   3 OHIOU.POS;1                   File ID:  (2007,27,1) 4 Size:      1255716/1255716    Owner:    [WWW_SERVER]" Created:   14-JUL-2000 07:50:18.54& Revised:   14-JUL-2000 08:11:56.27 (2) Expires:   <None specified>  Backup:    <No backup recorded>  Effective: <None specified>  Recording: <None specified> 3 File organization:  Indexed, Prolog: 3, Using 1 key '                              In 2 areas  Shelved state:      OnlineF File attributes:    Allocation: 1255716, Extend: 65535, Maximum bucket size: 8 <                     Global buffer count: 0, No version limit0 Record format:      Fixed length 16 byte records4 Record attributes:  Carriage return carriage control RMS attributes:     None Journaling enabled: None= File protection:    System:RWED, Owner:RWED, Group:RE, World: I Access Cntrl List:  (IDENTIFIER=INDEXER,ACCESS=READ+WRITE+EXECUTE+DELETE+                      CONTROL)  F I want to speed up the responses to queries on this file.  I have used   $ analyze/rms/fdl/output=    and    $ edit/fdl/script=optimize   and    $ convert/fdl=  A I expect that there will be simultaneous accesses to this and its C companion files, and certainly there will be cases where sequential D accesses will occur with relatively little activity on the system in, between.  Thus, I am led to hope that using    $ SET FILE/GLOBAL_BUFFER=n  F will provide quicker responses for some reasonable value of n.  I alsoF suspect that increasing n beyond some point will produce little if anyD further speed-up.  One obvious candidate of such a threshold is "bigH enough to hold the entire index".  How can I estimate a reasonable trial value of n?   G If I go to town on this (there are perhaps three dozen such files, some A bigger and some smaller), what SYSGEN parameters might need to be , increased?  Any other items to be alert for?   				RDP    --  B ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  % Date: Fri, 14 Jul 2000 15:08:23 -0400   From: norm.raphael@jamesbury.com; Subject: Re: Choosing Values for $ SET FILE/GLOBAL_BUFFER=n 4 Message-ID: <C225691C.00683DD2.00@jklh21.valmet.com>  . You will most likely want to enable statistics  and then monitor your hit rates.   SET  FILE    /STATISTICS             /STATISTICS !           /NOSTATISTICS (default)   E        Enables the gathering of RMS statistics on the specified file. ?        These statistics can then be viewed by using the Monitor B        utility, which is invoked with the DCL command MONITOR. TheD        SET FILE/STATISTICS command applies an application ACE to theD        specified file. The ACE does not affect access control and is7        only meaningful to the application assigning it.   + then MONITOR RMS/ITEM=CACHING/FILE=filespec    to see the results.    I have one that shows this:   3                             OpenVMS Monitor Utility 2                               RMS CACHE STATISTICS.                                  on node ASPEN3                             14-JUL-2000 14:38:55.90 ( (Index)  _ddcu:[dir]filename.typ;versionK Active Streams:  59                    CUR        AVE        MIN        MAX   K     Local Cache Hit Percent           5.00       4.82       0.00       9.00   K     Local Cache Attempt Rate         70.00      64.22       5.00     302.66   K     Global Cache Hit Percent         81.00      80.91      73.00      91.00   K     Global Cache Attempt Rate        66.00      60.90       5.00     286.33   K     Global Buf Read I/O Rate         12.00      11.62       0.66      52.00   K     Global Buf Write I/O Rate         0.00       0.00       0.00       0.00   K     Local Buf Read I/O Rate           0.33       0.21       0.00       1.00   K     Local Buf Write I/O Rate          0.66       0.56       0.00       3.00   N This gives me almost 5% from local cache and another 81% from global cache, on average.  There is almost no writing to this file.   O Unfortunately, I know of no way other than trial and error to get to acceptable  performance values. , If anyone has a formula, I'd love to see it.  O I believe RMS global buffers are allocated out of global section memory and can  be seen with* INSTALL LIST/GLOBAL (something like this):  + RMS$GBS^BDISK$USER1      ^@^@^@0A1400010000 O                  (00000000) WRT     DZRO TMP SYS        Pgltcnt/Refcnt=816/2703 *                Owner:       [GROUP,MEMBER]3                Protection:  S:RWE,O:RWE,G:RWE,W:RWE   + RMS$FSB^BDISK$USER1      ^@^@^@0A1400010000 L                  (00000000) WRT     DZRO TMP SYS        Pgltcnt/Refcnt=16/53*                Owner:       [GROUP,MEMBER]3                Protection:  S:RWE,O:RWE,G:RWE,W:RWE    -Norm             * piccard@ohio.edu on 07/14/2000 01:53:59 PM  " Please respond to piccard@ohio.edu   To:   Info-VAX@mvb.saic.com  cc: 8 Subject:  Choosing Values for $ SET FILE/GLOBAL_BUFFER=n          D The short version:  How do I choose a value for the number of global$ buffers to use with an indexed file?     The long version:   : System:  VMS 6.2, soon to be 7.2-1, on Alpha 2100, 512 MBy  
 Example file:   3 OHIOU.POS;1                   File ID:  (2007,27,1) 4 Size:      1255716/1255716    Owner:    [WWW_SERVER]" Created:   14-JUL-2000 07:50:18.54& Revised:   14-JUL-2000 08:11:56.27 (2) Expires:   <None specified>  Backup:    <No backup recorded>  Effective: <None specified>  Recording: <None specified> 3 File organization:  Indexed, Prolog: 3, Using 1 key '                              In 2 areas  Shelved state:      OnlineF File attributes:    Allocation: 1255716, Extend: 65535, Maximum bucket size: 8 <                     Global buffer count: 0, No version limit0 Record format:      Fixed length 16 byte records4 Record attributes:  Carriage return carriage control RMS attributes:     None Journaling enabled: None= File protection:    System:RWED, Owner:RWED, Group:RE, World: I Access Cntrl List:  (IDENTIFIER=INDEXER,ACCESS=READ+WRITE+EXECUTE+DELETE+                      CONTROL)  F I want to speed up the responses to queries on this file.  I have used   $ analyze/rms/fdl/output=    and    $ edit/fdl/script=optimize   and    $ convert/fdl=  A I expect that there will be simultaneous accesses to this and its C companion files, and certainly there will be cases where sequential D accesses will occur with relatively little activity on the system in+ between.  Thus, I am led to hope that using    $ SET FILE/GLOBAL_BUFFER=n  F will provide quicker responses for some reasonable value of n.  I alsoF suspect that increasing n beyond some point will produce little if anyD further speed-up.  One obvious candidate of such a threshold is "bigH enough to hold the entire index".  How can I estimate a reasonable trial value of n?   G If I go to town on this (there are perhaps three dozen such files, some A bigger and some smaller), what SYSGEN parameters might need to be , increased?  Any other items to be alert for?                       RDP    --B ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  % Date: Fri, 14 Jul 2000 15:45:29 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> ; Subject: Re: Choosing Values for $ SET FILE/GLOBAL_BUFFER=n ( Message-ID: <8knqgd$fvf$1@pyrite.mv.net>  6 Richard D. Piccard <piccard@ohio.edu> wrote in message" news:396F53B4.EFEDEBD6@ohio.edu... > F > The short version:  How do I choose a value for the number of global& > buffers to use with an indexed file? >  >  > The long version:  > < > System:  VMS 6.2, soon to be 7.2-1, on Alpha 2100, 512 MBy >  > Example file:  > 5 > OHIOU.POS;1                   File ID:  (2007,27,1) 6 > Size:      1255716/1255716    Owner:    [WWW_SERVER]$ > Created:   14-JUL-2000 07:50:18.54( > Revised:   14-JUL-2000 08:11:56.27 (2) > Expires:   <None specified> ! > Backup:    <No backup recorded>  > Effective: <None specified>  > Recording: <None specified> 5 > File organization:  Indexed, Prolog: 3, Using 1 key ) >                              In 2 areas  > Shelved state:      OnlineH > File attributes:    Allocation: 1255716, Extend: 65535, Maximum bucket	 > size: 8 > >                     Global buffer count: 0, No version limit2 > Record format:      Fixed length 16 byte records6 > Record attributes:  Carriage return carriage control > RMS attributes:     None > Journaling enabled: None? > File protection:    System:RWED, Owner:RWED, Group:RE, World: K > Access Cntrl List:  (IDENTIFIER=INDEXER,ACCESS=READ+WRITE+EXECUTE+DELETE+  >                     CONTROL) > H > I want to speed up the responses to queries on this file.  I have used >  > $ analyze/rms/fdl/output=  >  > and  >  > $ edit/fdl/script=optimize >  > and  >  > $ convert/fdl= > C > I expect that there will be simultaneous accesses to this and its E > companion files, and certainly there will be cases where sequential F > accesses will occur with relatively little activity on the system in
 > between.  E If sequential scans through multiple buckets will occur with any real J frequency, the first thing you should do is increase your data bucket sizeK to reduce the number of individual buckets fetched (assuming that you don't J try to cache the entire file, which given that it looks to be under 700 MB/ in size wouldn't be impossible to contemplate).r  J If you have around 150,000 data-level buckets currently, and index bucketsL that hold around 200 key/pointer pairs on average (rough estimate), then theH index root is likely at level 3.  Double the size of your data and indexJ buckets, and the index root will almost certainly be at level 2 (I thoughtG the utilities provided hints like this...) - and the difference in timelI between transferring 4 KB and 8 KB is negligible compared to the seek ando! rotational latency of the access.   E Once you've reduced the root level to 2, there's only one index leveleF between it and the data buckets.  Thus unless you try to cache a largeK percentage of that one intermediate level in global buffers, there's likelyoL relatively little to be gained by using them - just make sure each accessingL process has an extra buffer in which to keep the root cached.  If you do tryI to cache the intermediate index level, you'd want to cache something likeRK 400 8 KB level-1 index buckets (not an unreasonable number) - but the cachet; might have some difficulty in differentiating between thoseRK infrequently-accessed index buckets and the also-infrequently-accessed datatL buckets, so if you don't try to globally-cache the entire file there may not  be a good intermediate strategy.  K Finally, doesn't the virtual I/O cache perform a function similar to globaloD buffering in this case?  If so, you might be better off not tying upI physical memory in dedicated file-specific global buffers but letting theaF VIOC (and other system-level memory uses) make more global performance
 decisions.  J It's been a long time since I thought about these areas, so I hope someone8 more current will check the above comments for accuracy.   - bill  #   Thus, I am led to hope that usingt >  > $ SET FILE/GLOBAL_BUFFER=n >oH > will provide quicker responses for some reasonable value of n.  I alsoH > suspect that increasing n beyond some point will produce little if anyF > further speed-up.  One obvious candidate of such a threshold is "bigJ > enough to hold the entire index".  How can I estimate a reasonable trial
 > value of n?n >dI > If I go to town on this (there are perhaps three dozen such files, someeC > bigger and some smaller), what SYSGEN parameters might need to be . > increased?  Any other items to be alert for? >e > RDPa >l > --D > ==================================================================D > Dick Piccard                           Academic Technology ManagerD > piccard@ohio.edu                                 Computer ServicesD > http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  # Date: Sat, 15 Jul 2000 01:55:21 GMTt0 From: gilley@nospam.bravewc.com (Charles Gilley)+ Subject: Re: CompactTape II sources (TK70)?e> Message-ID: <XtPb5.18358$MT.365085@news-west.usenetserver.com>  : To close out my own question - it appears that the TK52 is9 marketed as a compatible replacement.  I've already foundrG two US providers that stock these cartridges.  Pricey for 300Mb storagea but that is life.-  &         http://rcpsinc.com/catolog.htm%         http://www.crowncomputer.com/r         > In article <Y7Db5.9874$MT.229607@news-west.usenetserver.com>, 1 gilley@nospam.bravewc.com (Charles Gilley) wrote:lL >I'm in need of 10 TK70 cartridges - good condition used or new (but I know A >they are out of production).  Anyone know where I can find some?o >! >chg >  >y   ------------------------------  % Date: Fri, 14 Jul 2000 21:33:05 -050057 From: "David J. Dachtera" <djesys.nospam@earthlink.net> + Subject: Re: CompactTape II sources (TK70)? - Message-ID: <396FCD61.65A0BD2B@earthlink.net>t   Charles Gilley wrote:- > < > To close out my own question - it appears that the TK52 is; > marketed as a compatible replacement.  I've already foundEI > two US providers that stock these cartridges.  Pricey for 300Mb storage  > but that is life.- > ( >         http://rcpsinc.com/catolog.htm' >         http://www.crowncomputer.com/l >   A Um, well, I guess those part numbers always were a bit confusing.e  H TK50K was the cartridge for TK50. So, we all assumed that TK70K would be" the cartridge for the TK70, right?   NAH! TK52K.w  - Don't think I wanna know 'bout Tx8(x) cart's.v   --   David J. Dachteras dba DJE Systemsr http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/t   ------------------------------  % Date: Sat, 15 Jul 2000 00:02:12 -0500L) From: "John E. Malmberg" <wb8tyw@qsl.net> + Subject: Re: CompactTape II sources (TK70)?o7 Message-ID: <0f2f01bfee19$dc1db230$020a0a0a@xile.realm>t   Charles Gilley wrote:  > < > To close out my own question - it appears that the TK52 is' > marketed as a compatible replacement.m  G The cartridge type for a TK50 drive is known as a CompacTape or TK50 ina	 catalogs.   J The cartridge type for a TK70 drive is known as a CompacTape II or TK52 in	 catalogs.   K HOBBYISTS TAKE NOTE:  If you aquire a system that uses TK50/TK70 drives, it.H can really pay to see if your supplier has any media for the drives.  IfH they are no longer using that type of media, they will probably give youL their entire supply.  Since it usually is stored separately from the system,I they may have forgotten about it when they decided to get rid of it.  [Do + not forget manuals and miscelaneous cables]l    L According to one to the link that was posted some time ago on this forum forL a former manufacturer, that manufacturer used identical media specifications@ for both cartridges, even though they sold for different prices.  L The CompacTape II media is supposed to be of a higher quality than the plain CompacTape.h  L According to some people that I know that did a very instensive search, theyJ could find no vendors with *NEW* CompacTape or CompacTape II cartridges inH stock.  They did a world wide search on this.  It is still possible that  they missed some vendors though.    J Be aware that the first time a CompacTape or (II) cartridge is written on,K it creates a control track that effectively sets the density for it's life. H Bulk erasure is possible, but while some people have had good luck doing that, others have not.  F If you put a cartridge formated as a TK50 in a TK70 drive, it is writeB locked, and while it can be read, a TK70 drive will not update it.  I If you put a cartridge formated as a TK70 in a TK50 drive, and attempt to J write on it, the last time I saw someone attempt this:  It played with theH tape for almost 45 minutes, while the user thought it was backing up theH data, then it aborted with a misleading error about the tape drive beingK defective.  After that, the tape could not be used on either a TK50 or TK7005 drive, as the control track was completely corrupted.x  ? Then you get to see if you have a good enough bulk tape eraser.t   >  I've already foundeI > two US providers that stock these cartridges.  Pricey for 300Mb storage  > but that is life.  > ( >         http://rcpsinc.com/catolog.htm  K Yes, their catalog lists both cartridges.  It also says that they sell used I media sometimes.  So make sure you find out what you are paying the moneyo for.    ' >         http://www.crowncomputer.com/d  L I can not find any references in their catalog to either TK50 or TK52 or any of their alternative names.e   ----   David J. Dachtera wrote:/ : Don't think I wanna know 'bout Tx8(x) cart's.=  I Those are basically marketed as DLTIII and higher.  You may also see some 6 references to CompacTape III or higher roman numerals.  F Of these I am told only DLT-IVs are still being manufactured.  HoweverJ supplies of DLTIII still seem to be good for now.  But note that only TZ88H and later will use the DLT-IV.  Keep this in mind if you are planning on' putting a tape drive on used equipment.u  D DLT cartridges will not work in TK50 or TK70 drives, even if you use! excessive force to make them fit.I    K On a Q-bus machine, if it is a 4000-300 or later, you can put a KZQSA on it G to use DLT or 4mm drives as a replacement.  DSSI DLT drives are also anl" option if you have a DSSI adapter.  L For Q-bus machines older than a 4000-300, the options I am familiar with areI various 3rd party SCSI adapters that make the SCSI tape drive look like aiC TMSCP device, and as such VMS can boot standalone backup from them.m  J I have seen on vmsnet.pdp11 some listings about a Digital/Compaq supportedE MSCP SCSI option for the q-bus that reportably will not work for VMS.=  F And I have seen tape drives as high of density as a TZ87 working on an1 Infoserver, but I do not know if it is supported.    -John  wb8tyw@qsl.network   ------------------------------  % Date: Sat, 15 Jul 2000 05:35:37 +0200r2 From: martin@radiogaga.harz.de (Martin Vorlaender)4 Subject: Re: Configuring NFS on VMS 7.1 on alpha box; Message-ID: <396fdc09.524144494f47414741@radiogaga.harz.de>B  - ian.kennedy@systemc.com (LostAndFound) wrote:1I : I am a vms newbie trying to configure nfs to run on VMS 7.1 on an alphan : box. :iA : Is there a SIMPLE guide to do this (I know it involves starting 0 : PORTMAPPER, MOUNT (MountD?) and NFS services). :g- : Does this process require a SYSTEM RESTART?e  5 Which "process"? Configuring NFS? Most certainly not.h  H Assuming you're talking of "DEC^H^H^HCompaq TCP/IP Services for OpenVMS"E (nee UCX), I hope you will find the appended document helpful. ThougheG it's rather dated (UCX V3.2, current is V5.0A), most of the information ( in it still holds, as far as I can tell.  @ If you're using UCX 5.0, replace "UCX" by "TCPIP" (e.g. it's not0 UCX$CONFIG.COM any more, it's TCPIP$CONFIG.COM).   cu,    Martin    N ------------------------------------------------------------------------------F  Dave Hoggan - djh@uvo.dec.com         TCP/IP Technology Support (UK)     +-+-+-+-+-+-+-+N  |d|i|g|i|t|a|l|   Author of  "The Internet Book: Introduction and Reference"	  +-+-+-+-+-+-+-+          ? 		   "I now begin to understand that which I do not understand"   E  Digital Equipment Company Limited Technical Support - Networks Group 4                     "Networking at its most intense"O ------------------------------------------------------------------------------ l   Preliminarym  K You will need a full UCX licence or a NAS 200/300/400 licence to be able to/G use the NFS server, but a client licence is all you need to use the NFSW Client application.   K The DEC TCP/IP Service for OpenVMS Management manual (which you have on the L documentation CD-ROMs or in hard copy) for V3.2 contains descriptions of theI usage and set up of NFS server (Chapter 8) and NFS client (Chapter 9). IncL V4.0, the documentation covers NFS Concepts (Chapter 8), NFS Server (Chapter 9) and NFS Client (Chapter 10).n     NFS Server setup  F In essence, to set up the NFS server you need to perform the following
 operations :-      Services  J 1) Ensure that the services NFS, MOUNT and PORTMAPPER have been configuredE by the SYS$MANAGER:UCX$CONFIG.COM procedure (see the Installation and ? Configuration Manual to configure them if they are not present)    eg UCX> SHOW SERVICE  L Service             Port  Proto    Process          Address            State  P BIND                  53  TCP,UDP  UCX$BIND         0.0.0.0             Disabled ..O MOUNT                 10  UDP      UCX$NFS_M        0.0.0.0             Enabled O NFS                 2049  UDP      UCX$NFS          0.0.0.0             EnabledPO PORTMAPPER           111  TCP,UDP  UCX$PORTM        0.0.0.0             Enabled7 etc.     Client Hostname setups  9 2) Ensure that the client host is in the local host table   > eg UCX> SET HOST "unixhost"/ADDRESS=194.28.0.30/ALIAS=UNIXHOST     Setup Disk Mapping  = 3) Map the disk you wish to export to a U*ix-style pathname -w   eg UCX> MAP "/dka0" $1$DKA0:  1 4) Save the mapping in the configuration databasen  . eg UCX> SET CONFIGURATION MAP "/dka0" $1$DKA0:  K (you will also need to edit the file SYS$MANAGER:UCX$NFS_SET_FS.COM and addeL the line $ UCX GENERATE MAP _after_ the line $ DEFINE/USER SYS$OUTPUT NLA0:)    
 Setup Exportsx  J 5) Add the directories on the disk to the export database using U*ix-style syntax  ' eg UCX> ADD EXPORT "/dka0/fred" /HOST=*g     Setup Network Proxies:  = 6) Add NFS proxies for your users and for "root" and "nobody"e  - eg UCX> ADD PROXY UCX$NFS /UID=0/GID=1/HOST=*i2    UCX> ADD PROXY UCX$NOBODY /UID=-2/GID=-2/HOST=*-    UCX> ADD PROXY FRED /UID=100/GID=15/HOST=*oH (the UID/GID for the users must match their accounts on the U*ix system)     Unix Client Mountt  F 7) Create a mount point on the U*ix file system and mount the exported	 directoryt   eg # mkdir vms2    # mount vms_host:/dka0/fred /usr/users/fred/vms    " Mount Command for a VMS NFS Client  J To use NFS client there must be exported files on the U*ix system, and theH proxies set up as above, then one would issue a mount command similar to this example :-f  > eg. UCX> MOUNT DNFS0: /HOST="unix_host"/PATH="/usr/users/fred"   --J One OS to rule them all       | Martin Vorlaender  |  VMS & WNT programmer7 One OS to find them           | work: mv@pdv-systeme.de N One OS to bring them all      |       http://www.pdv-systeme.de/users/martinv/> And in the Darkness bind them.| home: martin@radiogaga.harz.de   ------------------------------  # Date: Fri, 14 Jul 2000 21:38:57 GMTe) From: Lonny Balderston <lbalders@gte.net>l Subject: DCL coding question# Message-ID: <396F887E.16DA@gte.net>o  8 Anyone know a more efficient way to DCL-code this, maybe< using "pipe" and "sys$input" to dispense with the cumbersome open/read/close business?:  = $! *** rsh from Alpha to UNIX server to get file's owner namea: $ rsh /log=logfile.tmp4b /user='userid4' /pass='passwd4' -)    'servcur4' ls -l /usr/dgn/'mapnm4'.dof : $! *** open logfile and read server-file's owner name into $! *** variable "filuser4"+ $!          1         2         3         4n> $!012345678901234567890123456789012345678901234567890123456789G $!-rwxrwxr-x   1 jjones   users      16477 Jun 13 08:55 .../c0503b.dof i" $ open/read infile4b logfile.tmp4b $ read infile4b inrec4b04 $ filusr4=f$edit(f$extract(15,9,inrec4b),"collapse") $ close infile4b   We're running VMS 7.1-1H1L   Thank you, Lonny Balderston  email: lbalders at gte dot net   ------------------------------  % Date: Fri, 14 Jul 2000 23:27:56 -0400B2 From: rdeininger@mindspring.com (Robert Deininger)  Subject: Re: DCL coding questionL Message-ID: <rdeininger-1407002327560001@user-2ivebgl.dialup.mindspring.com>  ; In article <396F887E.16DA@gte.net>, lbalders@gte.net wrote:   : > Anyone know a more efficient way to DCL-code this, maybe> > using "pipe" and "sys$input" to dispense with the cumbersome > open/read/close business?:  & I wonder what you mean by "efficient"?  E If it's done and it works, it might be efficient not to spend more ofu your time on it.   I see 4 lines of simple DCL, and apparently that is cumbersome in your neck of the woods.  There is a teensy bit of overhead in making the poor computer< read and parse those four lines.  That might me inefficient.   I believe this might be crammed into one or two lines with a pipe, but personally I would not do it that way.  The pipe would probably spawn a subprocess, which is not as lightweight an operation in VMS as in oonix, for example.  And the subprocess wouldn't do much work before it went away.K I think that might be very inefficient.  But you could try it and see which 
 is faster.  B If you want to make it less cumbersome, you could wrap the 4 linesB in a subroutine or another command file.  Then the call would only= be one line, and would look at least as tidy as a pipe-thing.   H I won't volunteer to write a pipe version.  I'm not good with pipes, and= you can read the manual or the on-line help as well as I can.    > ? > $! *** rsh from Alpha to UNIX server to get file's owner name < > $ rsh /log=logfile.tmp4b /user='userid4' /pass='passwd4' -+ >    'servcur4' ls -l /usr/dgn/'mapnm4'.dofh< > $! *** open logfile and read server-file's owner name into > $! *** variable "filuser4"- > $!          1         2         3         4 @ > $!012345678901234567890123456789012345678901234567890123456789I > $!-rwxrwxr-x   1 jjones   users      16477 Jun 13 08:55 .../c0503b.dof n$ > $ open/read infile4b logfile.tmp4b > $ read infile4b inrec4bu6 > $ filusr4=f$edit(f$extract(15,9,inrec4b),"collapse") > $ close infile4b >  > We're running VMS 7.1-1H1     C VMS 7.1-2 is an easy and cheap (<$20) upgrade.  Many bugs have beens fixed since 7.1-1h1.   -- u Robert Deininger rdeininger@mindspring.coml   ------------------------------   Date: 15 Jul 2000 05:29:49 GMT. From: smith_j@removeit.cqm.co.uk (James Smith)  Subject: Decwrite: where to get?7 Message-ID: <8F723C5C8smithjremoveitcqmcou@212.41.43.3>e  , the hobbyist license seems to cover decwrite  J i've looked about, but cant find a download source - anybody know of one ?       James Se   ------------------------------  # Date: Sat, 15 Jul 2000 04:41:23 GMTe2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>$ Subject: Re: Decwrite: where to get?6 Message-ID: <TXRb5.588$sp6.178001@typhoon.aracnet.com>  / James Smith <smith_j@removeit.cqm.co.uk> wrote:n. > the hobbyist license seems to cover decwrite  L > i've looked about, but cant find a download source - anybody know of one ?  L You can't download it.  In order to get it you'll need to find a CD-ROM withH the kit on it.  Unfortunatly most of the layered products covered by theJ hobbyist program aren't on the Hobbyist CD.  There is only so much you canI fit on one CD and they had to pick and choose the products that they felttK would be the most desired.  An entire Condist set of CD's is something likef 16 CD's for one architecture.    			Zaned  l   ------------------------------    Date: 14 Jul 2000 16:02:32 -0500/ From: jlauret@?.chem.sunysb.edu (Jerome LAURET)i Subject: Re: Find Files utilityi. Message-ID: <396f71d8_1@dilbert.ic.sunysb.edu>  < 	Check out the MadGoat farm for a utility called ... FIND . K URL is http://www2.wku.edu/www/fileserv/fileserv-software.html for example.RH Note that this utility has more usage than finding file by name ... It's relly handy.  @ 	BTW : you may need to set the INDEXF.SYS file as READ for worldH if you want to allow non-priviledged user to be able to us the command. H However, you might not want to do that due to easer security or privacy  reasons.   -- d6                   Jerome LAURET S.U.N.Y. @ Stony Brook$        ,,,,,      Dept. of Chemistry+       ( o o )     Stony Brook NY 11794-3400 ;   ---m---U---m--------------------------------------------- &   E-mail: jlauret@mail.chem.sunysb.edu<   URL   : http://nucwww.chem.sunysb.edu/jlauret/jlauret.html   ------------------------------  % Date: Fri, 14 Jul 2000 21:06:40 -0500 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>o$ Subject: Re: FTP to/from Alpha boxes- Message-ID: <396FC730.3402A301@earthlink.net>-   Jesper Naur wrote: > 7 > When I follow my own instructions on a system near mea6 > (also with UCX 4.2, where ftp works), I get a number > of disturbing differences: > 8 > 1) Most notably, I have no ACL on UCX$FTP.DIR. The ACL? > reported by your customer looks screwed-up, this is indicatedp9 > by the hexadecimal dump, rather than some legible text.    *** WARNING ***P  C THIS ACL MAY HAVE BEEN SET BY PATHWORKS (AKA "ADVANCED SERVER") !!!c  8 DO NOT ATTEMPT TO MODIFY IT WITHOUT FURTHER RESEARCH !!!  : > It is perhaps possible, that the screwed-up ACL prevents> > UCX$FTPD_STARTUP.COM from being executed. It is interesting,> > that it can still create the log file in the same directory. > 2 > FYI: You can delete an ACL from a file by saying >I+ >  $ set security/acl/delete=all <filename>-  - *** WARNING ***-  C THIS ACL MAY HAVE BEEN SET BY PATHWORKS (AKA "ADVANCED SERVER") !!!d  8 DO NOT ATTEMPT TO MODIFY IT WITHOUT FURTHER RESEARCH !!!   > ; > but whether that works on a screwed-up ACL, I don't know.h  e *** WARNING ***   C THIS ACL MAY HAVE BEEN SET BY PATHWORKS (AKA "ADVANCED SERVER") !!!k  8 DO NOT ATTEMPT TO MODIFY IT WITHOUT FURTHER RESEARCH !!!   > = > 2) Your customer's SYS$SYSTEM:UCX$FTPD.EXE has the creation ; > date 18-APR-1995 and size 220 blocks. On my system, I getl; > creation date 18-NOV-1997, size 204 blocks. Since UCX 4.2e; > came out in 1997, a creation date of 1995 is out of line. : > This has not caused you problems yet, since you have not( > yet been able to activate the program. [snip]: > There is unfortunately also the more scary question: Has0 > something else gone wrong on that system disk?   *** DANGER ***  A UNLESS YOU HAVE A KNOWN (PROVEN) GOOD BACKUP OF YOUR SYSTEM DISK,:@ ATTEMPT ALL FURTHER CHANGES ONLY WITH OVERLY EXTREME CAUTION !!!   -- a David J. Dachtera0 dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/d   ------------------------------  % Date: Fri, 14 Jul 2000 16:50:33 -0400 " From: Dan Sugalski <dan@sidhe.org>= Subject: Re: got to remember to STOP trying to use OpenVMS...g: Message-ID: <4.3.2.7.0.20000714164941.00d27220@24.8.96.48>  = At 09:56 AM 7/14/00 -0700, Shane.F.Smith@Healthnet.com wrote:   K >I have to ask, why don't they just pull up the Tru64 sourcecode and take ay >look?  I I expect they will, but they're working against more than just the Tru64 mI folks. If one of the other Unices is better they should go look and find  $ out why and if it can be duplicated.  7 >Dan Sugalski <dan@sidhe.org> on 07/14/2000 09:28:06 AMe, >At 12:04 PM 7/14/00 -0400, Bill Todd wrote: >c@ > >Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> wrote in message2 > >news:8kn8pe$1k$2@mailint03.im.hou.compaq.com... > >d > >... > >oL > > >   One of the OpenVMS engineers has brought up a Linux Alpha box to see > >justfM > > >   what I/O caching scheme features are used there, and to compare it toh > >XFC* > > >   and to OpenVMS caching in general. > >tD > >They might also take a look at *BSD, since that may have features
 >(notably,$ > >soft updates) that Linux may not. >nK >Yanking in a Solaris box (or one of the other commercial Unices as well asdK >Tru64) might not be a bad idea either. Linux is rather substandard in somev >areas, as Unix boxen go.e >a >                          Dan >IJ >--------------------------------------"it's like this"-------------------3 >Dan Sugalski                          even samuraie@ >dan@sidhe.org                         have teddy bears and even= >                                       teddy bears get drunkr     					Dan  I --------------------------------------"it's like this"-------------------y2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and evenm;                                       teddy bears get drunkl   ------------------------------  # Date: Sat, 15 Jul 2000 02:47:12 GMTs4 From: jonadab@bright.net (Jonadab the Unsightly One)= Subject: Re: got to remember to STOP trying to use OpenVMS...0- Message-ID: <396fa661.404999@news.bright.net>r  3 mathog@seqaxp.bio.caltech.edu (David Mathog) wrote:g  : >    "STOP, are you insane?  Don't use OpenVMS for THAT!"  > I > to even start to build this sort of package for OpenVMS requires that IeH > first build it on a Unix box - and if I'm going to do that, why botherI > doing it over again for OpenVMS?   Moreover, there's a fair chance thatoI > that build will work the first time on Unix, whereas to make it work on 7 > OpenVMS will almost certainly require weeks of work, r  ; And on Windows there's a fair chance that you wouldn't havea8 to build at all, you just doubleclick the Setup icon and6 it automatically does whatever it does, and you get a 4 shortcut in your start menu for the new application.  4 People complain in the linux groups that Unix should4 go that direction.  But does that make sense?  Think5 about it.  Automatic installation is convenient, but s5 it has some associated problems.  Most significantly, 2 you get basically no control over the installation2 process.  For people who just want to surf the web0 and forward lists of jokes that aren't funny to 1 everyone in their address book, it's wonderful, Io6 suppose.  I don't mean to say that Windows is useless,5 no.  I'm using as I write this.  And Unix is valuableo1 too -- I have that on one of my other partitions. 0 But I wouldn't want all OSes to be the same, and0 I certainly wouldn't want them all to follow the! everything-happens-automatically r* you-don't-need-to-know-details philosophy.  	 - jonadabl   ------------------------------  # Date: Sat, 15 Jul 2000 02:47:13 GMTm4 From: jonadab@bright.net (Jonadab the Unsightly One)= Subject: Re: got to remember to STOP trying to use OpenVMS... . Message-ID: <396fa90f.1091218@news.bright.net>  + young_r@eisner.decus.org (Rob Young) wrote:w   > 	Galaxy was/is a big push   ; Sadly, Gaylord is moving to NT for their next generation of 8 library automation software (Polaris).  I'm certain this8 will come back to haunt them.  Some other astute company; working out of Unix will probably overtake them eventually.b< (People talk about NT being stable, but they also talk about< crashing it...)  However, Polaris isn't really complete yet,8 and they're still maintaining Galaxy for the time being.; Polaris is nowhere close to the stability of Galaxy yet.  I 1 saw a demo of Polaris at the regional workshop inu; Worthington last month, and besides the numerous greyed-outY8 functions that they simply hadn't implemented yet, there9 were two separate occasions during the twenty-minute demoa9 when they (Gaylord staff) couldn't get it to do what theyf: wanted.  They talk about it being stable, but it's NOTHING9 like Galaxy.  (Downtime?  What's that?  Oh, you mean whenn5 someone trips over a cord, right?)  (Actually, in alln5 fairness, we do take the system down to run quarterly$	 backups.)a  	 - jonadab    ------------------------------  # Date: Sat, 15 Jul 2000 03:21:31 GMT- From: jordan@my-deja.com= Subject: Re: got to remember to STOP trying to use OpenVMS...P) Message-ID: <8kolbh$fsb$1@nnrp1.deja.com>+  0 In article <009ED103.80E619D6@SendSpamHere.ORG>,    system@SendSpamHere.ORG wrote:- > In article <Q+ev0EZj+N24@eisner.decus.org>,o; Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:p/ > >In article <8kl7ki$dfa@gap.cco.caltech.edu>, 4 mathog@seqaxp.bio.caltech.edu (David Mathog) writes: > >"F > >> We all know that for platforms which don't support autoconf etc., most> > >> notably OpenVMS, it is a PITA to deal with these sorts of packages.  ButB > >> what are you going to do - that's the way the Unix guys build packages > >> these days. > >tF > >Don't they have source files ?  I thought "the VMS way" for dealingE > >with arbitrary source files was to run them through MMS asking MMS B > >to generate a dependency graph and the corresponding .MMS file. >) > Larry, >nF > The GNU stuff is psycho!  Think of the most logical and sound way to; > make a software product and then do the compete opposite!  >FF > Most of the psychosis in a GNU make is the brain-damage incorporatedE > to determine what include files and runt-time features exist on therE > particular platform.  Some early GNU developer "fries shy of a com-RF > plete Happy Meal", developed this brain-damaged way to do things andF > many of the other products seemed to adopt it.  It's crazy...  Make-D > file beget C files which are preprocessed to beget more makefiles, > rinse, lather, repeat...  / I think you're referring to autoconf/configure.   > I'm not sure what your criticism is _exactly_.  Without such a< facility, you have to support makefiles and headers for each? flavor of Unix, and the various environmental features of those @ flavors of Unix are moving targets.  Autoconf/configure supportsA a framework where the various attributes of the environments, alloB the subtle semantics of run-time environments, include files, etc.E are discovered and customized makefiles (and include files) are built & that should work on the target system.  = The proof of the pudding is in the eating.  I've been able tot> ./configure;make (configure and build) a number of packages on? systems where I could find no evidence that they had never beenUD supported before.  And they just worked, the first time, no problem.  B Notably, one can bring up a lot of Unix sources that use configure7 on Cygwin (a Posix environment for Windows built on GNUs: technology).  Even if everything doesn't work, it's a huge. headstart over what you have to do without it.  - I know there is a project over at SourceForgeU5 (http://sourceforge.net/projects/gnv/) to bring these = facilities to OpenVMS.  I hope it goes well, and I hope I can/) find some time to support it in some way.e   >s > --C > VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)) TMESIS(dot)COM >n   -Jordan Hendersons jordan@greenapple.comt    & Sent via Deja.com http://www.deja.com/ Before you buy.r   ------------------------------  % Date: Fri, 14 Jul 2000 14:48:03 -0400S) From: "Ebinger . Eric" <EEbinger@drc.com> M Subject: RE: I/O caching and UNIX evaluations (was: Re: got to remember ..	.)mB Message-ID: <7162F87E9EF4D311BA9900805FC1D3AE7A619F@and02.drc.com>   > -----Original Message-----% > From: hoffman@xdelta.zko.dec.nospama( > [mailto:hoffman@xdelta.zko.dec.nospam]% > Sent: Friday, July 14, 2000 1:50 PMv > To: Info-VAX@Mvb.Saic.Comr> > Subject: Re: I/O caching and UNIX evaluations (was: Re: got 
 > to rememberD > ...) >  >  >  > @ >   [Discussions of various favored UNIX flavours expurgated...] > G >   If y'all (customers) wish fast(er) and correspondingly potentially l< >   increasingly "unreliable" I/O (the term "unreliable" is  > here used to kH >   indicate increased use of caching and coorespondingly less frequent H >   disk updates, and is not intended in a derogatory context), then we E >   will look to provide y'all with access to this or to similar I/O gB >   caching support.   Of course, if caching or other related I/O H >   performance tweaks do get implemented, then the support will likely > >   have control knobs to permit tuning or to permit it to be  > specifically   >   disabled or enabled. >   I One "feature" of Un*x-like caching file systems that I would particularlyJE like to see not implemented is the ability to corrupt a filesystem bydG filling the disk.  I would humbly request that if the choice is between A speed and preventing file system corruption, I would prefer that BD preventing file system corruption be the choice.  (Where file systemE corruption is defined as damaging the on-disk structure, not ensuringsE that the contents of a file that was opened for "speed over security"-C remain valid.  If the system or process croaks or the disk fills or B whatever corrupting the open file(s) is acceptable, corrupting theC disk structure, directories, closed files, etc is not acceptable.  p In my opinion.)"   Eric Ebinger   ------------------------------  % Date: Fri, 14 Jul 2000 15:50:15 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>,M Subject: Re: I/O caching and UNIX evaluations (was: Re: got to remember ..	.) ( Message-ID: <8knqpb$gtl$1@pyrite.mv.net>  2 Ebinger . Eric <EEbinger@drc.com> wrote in message< news:7162F87E9EF4D311BA9900805FC1D3AE7A619F@and02.drc.com...   ...   K > One "feature" of Un*x-like caching file systems that I would particularlyoG > like to see not implemented is the ability to corrupt a filesystem byp > filling the disk.a  D Funny, I've never encountered such a feature, though I admit that myD knowledge of Unix-like file systems may well be incomplete.  Are you( possibly confusing a feature with a bug?  6   I would humbly request that if the choice is betweenB > speed and preventing file system corruption, I would prefer that2 > preventing file system corruption be the choice.  K If you're really worried that VMS's engineers would do something like this,iH then I'd suggest finding an operating system in whose engineers you have more confidence.   - bill     (Where file systemG > corruption is defined as damaging the on-disk structure, not ensuringiG > that the contents of a file that was opened for "speed over security"dE > remain valid.  If the system or process croaks or the disk fills orlD > whatever corrupting the open file(s) is acceptable, corrupting theC > disk structure, directories, closed files, etc is not acceptable.5 > In my opinion.)5 >9 > Eric Ebinger >9 >    ------------------------------  % Date: Fri, 14 Jul 2000 21:26:29 -0500 * From: Keith Brown <kbrown780@usfamily.net>M Subject: Re: I/O caching and UNIX evaluations (was: Re: got to remember ..	.) , Message-ID: <396FCBD5.F01270D8@usfamily.net>   Bill Todd wrote: > 4 > Ebinger . Eric <EEbinger@drc.com> wrote in message> > news:7162F87E9EF4D311BA9900805FC1D3AE7A619F@and02.drc.com... >  > ...  > M > > One "feature" of Un*x-like caching file systems that I would particularlyeI > > like to see not implemented is the ability to corrupt a filesystem byD > > filling the disk.e > F > Funny, I've never encountered such a feature, though I admit that myF > knowledge of Unix-like file systems may well be incomplete.  Are you* > possibly confusing a feature with a bug? > 8 >   I would humbly request that if the choice is betweenD > > speed and preventing file system corruption, I would prefer that4 > > preventing file system corruption be the choice. > M > If you're really worried that VMS's engineers would do something like this,sJ > then I'd suggest finding an operating system in whose engineers you have > more confidence. >  > - bill >  >   (Where file systemI > > corruption is defined as damaging the on-disk structure, not ensuringmI > > that the contents of a file that was opened for "speed over security"HG > > remain valid.  If the system or process croaks or the disk fills or F > > whatever corrupting the open file(s) is acceptable, corrupting theE > > disk structure, directories, closed files, etc is not acceptable.h > > In my opinion.)d > >  > > Eric Ebinger > >- > >-    E >Funny, I've never encountered such a feature, though I admit that myrE >knowledge of Unix-like file systems may well be incomplete.  Are you@) >possibly confusing a feature with a bug?d     Hi Bill,  @ While I do not claim to be a Unix expert, our Unix support guys,< who are, say that this is not an uncommon occurrence. I have@ watched (at a distance) as they scurried about trying to recover> from one of these crashes. BTW, we run Oracle on Tru64. At the> same time, we have never had file system damage on our OpenVMS systems. Just an observation.t   -- n Keith Brownd kbrown780@usfamily.net   ------------------------------  % Date: Fri, 14 Jul 2000 23:36:41 -0400y' From: "Bill Todd" <billtodd@foo.mv.com>tM Subject: Re: I/O caching and UNIX evaluations (was: Re: got to remember ..	.)-( Message-ID: <8kom3t$neh$1@pyrite.mv.net>  5 Keith Brown <kbrown780@usfamily.net> wrote in messagem& news:396FCBD5.F01270D8@usfamily.net...   ...-  B > While I do not claim to be a Unix expert, our Unix support guys,7 > who are, say that this is not an uncommon occurrence.:  L And one I've heard of, as well.  I've just never heard it called a 'feature'G before.  But perhaps I was being too subtle (something I'm infrequentlye accused of).   - bill    I have B > watched (at a distance) as they scurried about trying to recover@ > from one of these crashes. BTW, we run Oracle on Tru64. At the@ > same time, we have never had file system damage on our OpenVMS > systems. Just an observation.i >  > --
 > Keith Brown  > kbrown780@usfamily.net   ------------------------------  % Date: Fri, 14 Jul 2000 15:08:35 -0400I' From: "Bill Todd" <billtodd@foo.mv.com>tL Subject: Re: I/O caching and UNIX evaluations (was: Re: got to remember ...)( Message-ID: <8knoba$ckh$1@pyrite.mv.net>  = Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> wrote in message 0 news:8knjrk$32v$1@mailint03.im.hou.compaq.com...   ...   J >   In the context of this discussion, I am not particularly interested inH >   discussing the relative merits of any of the various other operatingI >   systen implementations and variants, though (again, in the context ofrK >   this discussion) I am interested in comparisons of I/O path performanceHI >   and trade-offs and such.  Linux figured rather prominently in earlier K >   I/O performance and I/O caching discussions held here in the newsgroup,:J >   hence the Linux platform is one that we are taking a specific look at.  K Your previous statement that "One of the OpenVMS engineers has brought up a L Linux Alpha box to see just what I/O caching scheme features are used there"I suggests that you're looking for ideas, which is a good start.  The point J people are making is that you won't find all the ideas worth looking at inL any single implementation:  my guess is that you'll at least have to look atK SGI's XFS (for ideas about deferred allocation especially - source code mayTK already be available, since SGI is making an open source version for Linux) F and something supporting soft updates (which XFS may not as fully as -L perhaps - some BSD variants, since the presence of a log likely modifies theI use of soft updates) in addition to 'vanilla' Unix implementations if youu5 want to understand the state of the art in this area.    - bill   >u, >  --------------------------- pure personal# opinion ---------------------------:1 >    Hoff (Stephen) Hoffman   OpenVMS Engineeringo hoffman#xdelta.zko.dec.com >'   ------------------------------   Date: 14 Jul 2000 19:29:08 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)L Subject: Re: I/O caching and UNIX evaluations (was: Re: got to remember ...)6 Message-ID: <8knpm4$4vp$1@mailint03.im.hou.compaq.com>  R In article <8knoba$ckh$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes: :iO :...Your previous statement that "One of the OpenVMS engineers has brought up aaM :Linux Alpha box to see just what I/O caching scheme features are used there" B :suggests that you're looking for ideas, which is a good start....  H   Please see the earlier discussions around I/O performance comparisons.  I   As for "looking for ideas", caching and cache implementations and cache G   designs are well-known among folks here in OpenVMS.  Some of the key oI   factors in the research involve the trade-offs between the performance  H   gains and the corresponding risks to the data integrity, the relative L   differences in the I/O performance seen, complexity, resource consumption,L   and various implementation-related factors.  Very standard caching stuff,    in other words.h  H   What makes this whole task particularly interesting (to me and to someK   of the other engineers) is not so much the technical aspects, but rather  J   involves the differing comfort levels that I expect individual customer E   sites will have with various current and various potential caching aG   enhancements.  Some customers undoubtedly want "extreme" caching and  H   its (hopefully :-) associated performance improvements, and some will 3   undoubtly prefer data integrity over performance.-  F   And as mentioned earlier, please see the earlier discussions around F   the various I/O performance comparisons folks have been pointing to.  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Fri, 14 Jul 2000 16:17:14 -0400g' From: "Bill Todd" <billtodd@foo.mv.com>uL Subject: Re: I/O caching and UNIX evaluations (was: Re: got to remember ...)( Message-ID: <8knsbt$i4f$1@pyrite.mv.net>  = Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> wrote in message,0 news:8knpm4$4vp$1@mailint03.im.hou.compaq.com... >eL > In article <8knoba$ckh$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes:n > :vL > :...Your previous statement that "One of the OpenVMS engineers has brought up aH > :Linux Alpha box to see just what I/O caching scheme features are used there"D > :suggests that you're looking for ideas, which is a good start.... >eJ >   Please see the earlier discussions around I/O performance comparisons. >cK >   As for "looking for ideas", caching and cache implementations and cache 7 >   designs are well-known among folks here in OpenVMS.   I Y'know, I'm inclined to give the folks in VMS engineering a great deal ofnK benefit of the doubt, considering how thoroughly they've been bludgeoned by F corporate politics and plain mis-management over the past decade-plus.  K But given how badly VMS file caching performance sucks compared to the rest J of the world, your statement above seems inexcusably arrogant - especiallyK in its implication (reinforced by your statements below) that other designs-) necessarily entail losses in reliability.-  H It seems reasonable to infer that either VMS engineering doesn't know inH real detail how to cache better (and maintain reliability), or knows butI doesn't consider it important (which in my experience suggests that theiriK knowledge may be at least somewhat superficial, since it's not perceived asaL being an area worthy of real study), or knows but doesn't have the resourcesJ to do anything (which is at least something one can sympathize with).  AndK even you seem to be aware that VMS engineering doesn't know how people wantaI to *use* caching to achieve differing trade-offs between up-to-the-secondkL persistence and performance, which likely implies that certain possibilities. have not received the analysis they may merit.  L The bottom line is that if you're not looking for ideas (including technical ones), you should be.o   - bill     Some of the keynJ >   factors in the research involve the trade-offs between the performanceI >   gains and the corresponding risks to the data integrity, the relativeeA >   differences in the I/O performance seen, complexity, resource  consumption,F >   and various implementation-related factors.  Very standard caching stuff, >   in other words.e > J >   What makes this whole task particularly interesting (to me and to someL >   of the other engineers) is not so much the technical aspects, but ratherK >   involves the differing comfort levels that I expect individual customeraF >   sites will have with various current and various potential cachingH >   enhancements.  Some customers undoubtedly want "extreme" caching andI >   its (hopefully :-) associated performance improvements, and some willj5 >   undoubtly prefer data integrity over performance.s > G >   And as mentioned earlier, please see the earlier discussions around>H >   the various I/O performance comparisons folks have been pointing to. >n, >  --------------------------- pure personal# opinion ---------------------------S1 >    Hoff (Stephen) Hoffman   OpenVMS Engineerings hoffman#xdelta.zko.dec.com >    ------------------------------    Date: 14 Jul 2000 17:29:33 -0500* From: young_r@eisner.decus.org (Rob Young)L Subject: Re: I/O caching and UNIX evaluations (was: Re: got to remember ...)+ Message-ID: <xvQY9bP$ffhA@eisner.decus.org>a  k In article <8knjrk$32v$1@mailint03.im.hou.compaq.com>, hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes:m   Steve,   >  > @ >   [Discussions of various favored UNIX flavours expurgated...] > G >   If y'all (customers) wish fast(er) and correspondingly potentially tI >   increasingly "unreliable" I/O (the term "unreliable" is here used to  H >   indicate increased use of caching and coorespondingly less frequent H >   disk updates, and is not intended in a derogatory context), then we E >   will look to provide y'all with access to this or to similar I/O iB >   caching support.   Of course, if caching or other related I/O H >   performance tweaks do get implemented, then the support will likely K >   have control knobs to permit tuning or to permit it to be specifically y >   disabled or enabled. >    	Along these lines:   J http://www.openvms.digital.com:8000/72final/6520/6520pro_004.html#params_h  ; 	You have VCC_WRITEBEHIND and VCC_WRITEDELAY... enough roper 	to hang ourselves with.    = 	How about some method to exclude files from being cached OR v< 	prioritizing files to be cached at file or directory level?  F 	I'm assuming caching is getting down to block level and all available< 	memory ala the Unices.. maybe the above isn't necessary but= 	would be a shame to have users flushing our caches for thosep; 	with tight memory systems because they are pecking at someh; 	worthless files (Mail?) when that cache could be much moref= 	effective caching what it can of a hot database.  So in thisi9 	case the appropriate SYSGEN flag is set and VMS looks tot/ 	system logicals for inclusion/exclusion lists.    				Robd   ------------------------------   Date: 14 Jul 2000 21:37:39 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)L Subject: Re: I/O caching and UNIX evaluations (was: Re: got to remember ...), Message-ID: <8ko173$74m@gap.cco.caltech.edu>  k In article <8knpm4$4vp$1@mailint03.im.hou.compaq.com>, hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes: I >  What makes this whole task particularly interesting (to me and to someoL >  of the other engineers) is not so much the technical aspects, but rather K >  involves the differing comfort levels that I expect individual customer rF >  sites will have with various current and various potential caching H >  enhancements.  Some customers undoubtedly want "extreme" caching and I >  its (hopefully :-) associated performance improvements, and some will f4 >  undoubtly prefer data integrity over performance.  L Right.  And there is another consideration - the amount of risk you want on E any one system can change rapidly for that system depending upon the   environment.  I For instance, imagine a system protected by a UPS which is nominally gooduJ for 10 minutes after the power fails.  Obviously you should never set suchE a system so that the total time to dump everything from cache to diskiK exceeds 10 minutes, because if you did, you'd lose data even though you hadlK a UPS.  Also, as soon as the power failure was detected you'd normally wantxC to start shrinking the cache area rapidly, so that if a shutdown isoI ordered (power is not restored), it can progress as rapidly as possible. eI Not even folks like me want a race between the fading UPS battery and thekD system madly trying to get everything down onto disk!   If power is 9 restored, the file cache must be allowed to expand again.u  K I'm not sure though how easily you can predict the "time to write cache to oI disk".  The bits can be going all sorts of places with all sorts of awful E interactions and 8 - 10 ms delays associated with head movement.  YounD probably could accurately predict though a worst case "dump cache toE emergency disk storage".  Ie, something like sys$dump, but sys$fcdumpeK instead.  So let's say you've got 200Mb in the file cache and know that youlH can sustain a steady 3.6Mb/sec to the sys$fcdump file, which will get itB all safe on the oxide in about a minute.  So if there is any hurryJ associated with a shutdown it may make more sense to push the data to thatA file.  Faster speeds could be obtained by writing through certainrH controllers, or to sys$fcdump files on multiple disks. Presumably the OSK could load it back into file cache on reboot and dole it out to the correctIH locations on the other disks later. Or maybe not - the interactions withI mount verification would be interesting!  Hmm, if some of those files are7= OS files, that might make for an interesting reboot as well.    C There's certainly no shortage of interesting problems in this area.u   Regards,   David Mathog mathog@seqaxp.bio.caltech.edur? Manager, sequence analysis facility, biology division, Caltech n   ------------------------------  + Date: Fri, 14 Jul 2000 16:21:07 -0600 (MDT)t) From: John Nebel <nebel@athena.csdco.com>bL Subject: Re: I/O caching and UNIX evaluations (was: Re: got to remember ...)G Message-ID: <Pine.OSF.4.21.0007141351380.22765-100000@athena.csdco.com>e   Hi Hoff,  9 >   Some customers undoubtedly want "extreme" caching and I >   its (hopefully :-) associated performance improvements, and some willd5 >   undoubtly prefer data integrity over performance.    Agreed - recent anecdote:   I Today a ES40 Unix box here crashed at 4:00am. I got the call at slightly sB before 5:00am and remotely checked the op console and could see itI struggling to its feet - it was just rebooting. Fsck on those particular  % 600 GB stripe sets takes three hours.r  H It's a Usenet and web server so it's not too critical. Around 6:00am theG owner of the web site sent a "wot's happenen" e-mail - he was loosing a   chunk of his 500,000 hits/day.    E The machine was up at about 7:00, then innd had to start its checkingm process.  Apache was fine.  G If that had been a critical VMS production machine in the middle of ther& day, people would get pretty agitated.  
 John Nebel  # On 14 Jul 2000, Hoff Hoffman wrote:e   > T > In article <8knoba$ckh$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes: > :.Q > :...Your previous statement that "One of the OpenVMS engineers has brought up atO > :Linux Alpha box to see just what I/O caching scheme features are used there" D > :suggests that you're looking for ideas, which is a good start.... > J >   Please see the earlier discussions around I/O performance comparisons. > K >   As for "looking for ideas", caching and cache implementations and cache?I >   designs are well-known among folks here in OpenVMS.  Some of the key nK >   factors in the research involve the trade-offs between the performance  J >   gains and the corresponding risks to the data integrity, the relative N >   differences in the I/O performance seen, complexity, resource consumption,N >   and various implementation-related factors.  Very standard caching stuff,  >   in other words.  > J >   What makes this whole task particularly interesting (to me and to someM >   of the other engineers) is not so much the technical aspects, but rather nL >   involves the differing comfort levels that I expect individual customer G >   sites will have with various current and various potential caching uI >   enhancements.  Some customers undoubtedly want "extreme" caching and dJ >   its (hopefully :-) associated performance improvements, and some will 5 >   undoubtly prefer data integrity over performance.x > H >   And as mentioned earlier, please see the earlier discussions around H >   the various I/O performance comparisons folks have been pointing to. > P >  --------------------------- pure personal opinion ---------------------------N >    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com >  >  >    ------------------------------  % Date: Fri, 14 Jul 2000 19:39:54 -0400 / From: "IanPercival" <IanPercival@email.msn.com>sL Subject: Re: I/O caching and UNIX evaluations (was: Re: got to remember ...)) Message-ID: <edrFJ#e7$GA.278@cpmsnbbsa07>6  H > But given how badly VMS file caching performance sucks compared to the restL > of the world, your statement above seems inexcusably arrogant - especiallyE > in its implication (reinforced by your statements below) that otherm designs6+ > necessarily entail losses in reliability.h > J > It seems reasonable to infer that either VMS engineering doesn't know inJ > real detail how to cache better (and maintain reliability), or knows butK > doesn't consider it important (which in my experience suggests that theirgJ > knowledge may be at least somewhat superficial, since it's not perceived asD > being an area worthy of real study), or knows but doesn't have the	 resourceshL > to do anything (which is at least something one can sympathize with).  AndH > even you seem to be aware that VMS engineering doesn't know how people wantK > to *use* caching to achieve differing trade-offs between up-to-the-second @ > persistence and performance, which likely implies that certain
 possibilitiest0 > have not received the analysis they may merit.  + The above is a highly misleading statement.b  I As Steve Hoff says, it's hardly a revelation to many of the VMS engineersi thatK variants of UNIX (and even may I say NT) have a different file data cachingc scheme. J Writeback caching is always going to outperform writethrough caching as is the currento< VMS cache implementation FOR WRITES on low to medium volume.  7 There is also a VERY strong presence in VMS EngineeringsK of real world talent who have been at the front end of performance problems  for many yearsJ (though of course there are some die hards who need to be educated still - as in any large organisation).F We are working with some very large customers on some very interestingJ issues.  The statement that we in VMS Engineering don't know how customersH want to use caching is quite frankly,grossly incorrect (though of courseJ thats open to interpretation - I'm sure that there are SOME individuals inC Engineering, who have nothing to do with the file system, cache, or  performance who don't know).  H It is  true that VMS was remiss in ignoring the implementation of a more powerfulJ data caching architecture in the past.  This was for a variety of  reasons and IeL don't want to open old wounds as that is fruitless.  This has been gone over3 time and time again in the newsgroup and elsewhere.a  J Some time ago in V5.x days I personally made a lot of money by co-writing,F writing and selling a more powerful set of caching products (I was notG working for Digital/Compaq - and yes - I was as frustrated as many that K Digital would not enhance, merge or otherwise modify its existing product --G find some old copies of Digital Review to see how semi-real independent L testing showed true performance differences between caches).     Some of theG more vociferous members of this conference have NOT written any caching E product anywhere.  Nonetheless they are self styled experts.  YES VMS L currently has performance problems and YES we've been slow to react.  YES weG are now doing something and SORRY it cannot be INSTANTANEOUS!!!!  We DO K believe in testing stuff and making it as robust as we can before releasing : it.  Of necessity this means things happen a bit slower...  J Compaq has now committed to move forward on its data caching architecture.D There will be a LOT of work done over the next few years - with everK increasing performance yields for different situations.    XFC V1.0 is VERYnJ competitive for read I/o caching - and that is BEFORE the performance passJ that will be done on the product before final ship in December.  WritebackJ caching is coming along very shortly afterwards, and it too will be highlyJ competitive methinks - but of course I won't say until the code is frozen.I Other things will be coming along too - which DO NOT EXIST IN UNIX/LINUX.aK Gosh - what will some of the naysayers do then?  Lots I'm sure!!!! :-)  TheuJ author of the top paragraphs is very aware of the fact that there is a newB cache.    Nonetheless it is easy to trash what is there currently. Repeatedly.h  J I want to say that up to the present point, I have not heard ONE idea fromK any of the members of this conference on a new way to cache.  The statement"K seems to be made over and over again that we should look at the Unix modelsnK as examples of how things should be done.  Maybe some of you should chat to L a maintainer or designer of a Unix cache.  I have.  Things are certainly notK as golden as many  would have us believe in terms of data reliability.  Its-J incredibly arrogant of some people here to think that VMS engineers cannotH figure out such concepts as writeback caching,  temp files never hittingF oxide, etc.   Still, I understand the requirement to be visible too!!!  K We anticipate applying for several patents in the V2.0 XFC product, that inlI itself should indicate to some that VMS does not intend to follow, but to. lead.   K Sorry for a slight flame on - but VMS really is actually moving on this now$G ( YES I know this isn't the total solution but its an indicator that wevJ are,and have been doing things for quite some time, yes we've been slow toG react - but we really will deliver something in the next few releases).x  D Please lets move on - or at leat wait to trash XFC when it's finally? released! These discussions will become far more relevant then!t   Ian Percival XFC Project Leader   ian.percival@compaq.comf          0 Bill Todd <billtodd@foo.mv.com> wrote in message" news:8knsbt$i4f$1@pyrite.mv.net... >h? > Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> wrote in message'2 > news:8knpm4$4vp$1@mailint03.im.hou.compaq.com... > > 8 > > In article <8knoba$ckh$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com>d	 > writes:  > > :tF > > :...Your previous statement that "One of the OpenVMS engineers has broughta > up aJ > > :Linux Alpha box to see just what I/O caching scheme features are used > there"F > > :suggests that you're looking for ideas, which is a good start.... > > L > >   Please see the earlier discussions around I/O performance comparisons. > >yG > >   As for "looking for ideas", caching and cache implementations ando cachee9 > >   designs are well-known among folks here in OpenVMS.r >oK > Y'know, I'm inclined to give the folks in VMS engineering a great deal ofhJ > benefit of the doubt, considering how thoroughly they've been bludgeoned byH > corporate politics and plain mis-management over the past decade-plus. >cH > But given how badly VMS file caching performance sucks compared to the restL > of the world, your statement above seems inexcusably arrogant - especiallyE > in its implication (reinforced by your statements below) that othern designss+ > necessarily entail losses in reliability.h >cJ > It seems reasonable to infer that either VMS engineering doesn't know inJ > real detail how to cache better (and maintain reliability), or knows butK > doesn't consider it important (which in my experience suggests that theiraJ > knowledge may be at least somewhat superficial, since it's not perceived asD > being an area worthy of real study), or knows but doesn't have the	 resourcesmL > to do anything (which is at least something one can sympathize with).  AndH > even you seem to be aware that VMS engineering doesn't know how people wantK > to *use* caching to achieve differing trade-offs between up-to-the-secondf@ > persistence and performance, which likely implies that certain
 possibilitiesv0 > have not received the analysis they may merit. >uD > The bottom line is that if you're not looking for ideas (including	 technicali > ones), you should be.m >u > - bill >b >   Some of the keycL > >   factors in the research involve the trade-offs between the performanceK > >   gains and the corresponding risks to the data integrity, the relative C > >   differences in the I/O performance seen, complexity, resource  > consumption,H > >   and various implementation-related factors.  Very standard caching > stuff, > >   in other words.n > >-L > >   What makes this whole task particularly interesting (to me and to someG > >   of the other engineers) is not so much the technical aspects, bute ratherD > >   involves the differing comfort levels that I expect individual customerH > >   sites will have with various current and various potential cachingJ > >   enhancements.  Some customers undoubtedly want "extreme" caching andK > >   its (hopefully :-) associated performance improvements, and some willv7 > >   undoubtly prefer data integrity over performance.a > > I > >   And as mentioned earlier, please see the earlier discussions aroundgJ > >   the various I/O performance comparisons folks have been pointing to. > >e. > >  --------------------------- pure personal% > opinion --------------------------- 3 > >    Hoff (Stephen) Hoffman   OpenVMS Engineeringo > hoffman#xdelta.zko.dec.com > >p >i >y   ------------------------------  % Date: Fri, 14 Jul 2000 22:16:08 -0400r- From: JF Mezei <jfmezei.spamnot@videotron.ca>rL Subject: Re: I/O caching and UNIX evaluations (was: Re: got to remember ...), Message-ID: <396FC967.A92CA741@videotron.ca>   IanPercival wrote:M > We anticipate applying for several patents in the V2.0 XFC product, that incK > itself should indicate to some that VMS does not intend to follow, but ton > lead.T  M Glad to see that. And I hope that Compaq makes as much noise as possible whenx that happens to show that  	1-VMS is still alive  	2-VMS is still a leader  / 	3-VMS performance is not something to sneer ati  L I also hope that the VMS group won't be forced to hand over their secrets to1 the compaq unix folks and to the microsoft folks.s   ------------------------------    Date: 15 Jul 2000 01:46:21 -0500* From: young_r@eisner.decus.org (Rob Young)L Subject: Re: I/O caching and UNIX evaluations (was: Re: got to remember ...)+ Message-ID: <q+7jeRVTiRhh@eisner.decus.org>r  \ In article <396FC967.A92CA741@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > IanPercival wrote:N >> We anticipate applying for several patents in the V2.0 XFC product, that inL >> itself should indicate to some that VMS does not intend to follow, but to >> lead. > O > Glad to see that. And I hope that Compaq makes as much noise as possible when4 > that happens to show that  > 	1-VMS is still alive  > 	2-VMS is still a leader t1 > 	3-VMS performance is not something to sneer att > N > I also hope that the VMS group won't be forced to hand over their secrets to3 > the compaq unix folks and to the microsoft folks.f    < 	Interesting.  Suppose they aren't allowed to hand over APMP= 	to Tru64 folks?  If so, how come at the outset it has alwayse= 	been described as "Galaxy, the first instantiation of APMP". : 	Why not beef up Tru64 likewise?  They would sell a ton of; 	it and it really is all about sales, isn't it?  That beingr9 	the case, where is APMP on Tru64 roadmaps?  It's easy toa@ 	do , no doubt (1).  Point is, if VMS engineering does something< 	that is VERY difficult to do in the Unix paradigm, how long9 	before it shows up in Unix?   Give you a hint... it tooko> 	a while for Unix to get a "Tru Cluster".  In a sense, Unix is< 	broken and always has been but as Cutler stated in the Feb.; 	1992 UnixWorld magazine (paraphrasing of course, my memoryd@ 	isn't all that good):  "what do you expect when you get a bunch( 	of gradual students hacking things up."  B 	So they hand them XFC and explain the algorithms to them, problem< 	is the Unix folks realize that it would require tremendous < 	kernel reworking (gee, guess that 4 ring OS of VMS isn't soA 	stupid after all) they nod politely and go about their business.e     				Robn   (1)  Yeah, right   ------------------------------  # Date: Fri, 14 Jul 2000 19:50:49 GMT  From: mlyczewski@ddpwa.com Subject: Re: ibm 18 gig drives3 Message-ID: <396f6ec1.13859568@client.news.psi.net>   ' I attmpted to use IBM 9gig drive beforet" on the same machine (VMS 7.1), and( experienced the same problem. I ended up# returning the IBM drive and gettings$ a 47gig Seagate. Works like a charm.    . On Wed, 12 Jul 2000 22:07:57 -0700, "loribug1" <loribug1@email.msn.com> wrote:   3 >Does anyone know how to make dnes 18gig drive scsi ( >drive work on alpha station 200 4/233 .8 >with vms firmware sees drive but drive will not spin up# >to init.. system says its online..t  >is there some firmware trick .. >e >help..s >Gary C. >  >t >i >  >s   ------------------------------    Date: 14 Jul 2000 22:53:57 -0500/ From: jlauret@?.chem.sunysb.edu (Jerome LAURET)a Subject: Re: ibm 18 gig drives. Message-ID: <396fd245_2@dilbert.ic.sunysb.edu>  P In article <396f6ec1.13859568@client.news.psi.net>, mlyczewski@ddpwa.com writes:) |>I attmpted to use IBM 9gig drive beforem$ |>on the same machine (VMS 7.1), and* |>experienced the same problem. I ended up% |>returning the IBM drive and gettingo& |>a 47gig Seagate. Works like a charm. |> |>  B 	This post appears to me as casting a cloud of doubts on the IBM'sO drives reliability. No offense but however, from my own experience, I had many -Q problems with Seagate drives (I tried the 9Gb and it was a catastrophe and never a> worked, failure rate is higher than any other brand I tried). C 	I am actually moving away from Seagates. My 36Gb IBM drives works 2L like a charm (on 7.2 ...), several IBM drives I have never had any problems F for many years now ... May be shear luck ... But everyboddy has their  preferred brand I guess.  " 	I thought I would share this ...      -- p6                   Jerome LAURET S.U.N.Y. @ Stony Brook$        ,,,,,      Dept. of Chemistry+       ( o o )     Stony Brook NY 11794-3400 ;   ---m---U---m---------------------------------------------t&   E-mail: jlauret@mail.chem.sunysb.edu<   URL   : http://nucwww.chem.sunysb.edu/jlauret/jlauret.html   ------------------------------    Date: 14 Jul 2000 20:37:27 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)n Subject: Re: ibm 18 gig drives, Message-ID: <oYjRfbdyWfC0@malvm2.mala.bc.ca>  / In article <396fd245_2@dilbert.ic.sunysb.edu>, e4    jlauret@?.chem.sunysb.edu (Jerome LAURET) writes:   > R > In article <396f6ec1.13859568@client.news.psi.net>, mlyczewski@ddpwa.com writes:+ > |>I attmpted to use IBM 9gig drive beforeH& > |>on the same machine (VMS 7.1), and, > |>experienced the same problem. I ended up' > |>returning the IBM drive and gettinge( > |>a 47gig Seagate. Works like a charm. > |> > |> > D > 	This post appears to me as casting a cloud of doubts on the IBM's > drives reliability.   N      I can't speak for the views of the original author, but the problem beingI addressed here is one of software compatibility, not reliability. Certain O IBM drives do not work properly with certain versions of VMS due to differencesiK of opinion about acceptable responses to certain SCSI inquiry commands. TherF symptom is that the console firmware sees the drive but VMS refuses to initialize/mount it.  = > No offense but however, from my own experience, I had many  S > problems with Seagate drives (I tried the 9Gb and it was a catastrophe and never m@ > worked, failure rate is higher than any other brand I tried).   L     So far I've been pretty lucky with both IBM and Seagate drives, but I'll> never buy a Quantum drive again ( personal experience, YMMV ).   ------------------------------  % Date: Fri, 14 Jul 2000 15:58:46 -0400t/ From: "Paul A. Jacobi" <Paul.Jacobi@compaq.com>v& Subject: Re: IDE CD-ROM audio support?+ Message-ID: <8knrk3$5h0$1@lead.zk3.dec.com>m  ) <clark@sander.stsci.edu> wrote in message # news:8khvcq$679$2@tomm.stsci.edu...f >a" >   I went to the artical's link -; > http://www.openvms.compaq.com/openvms/freeware/index.html ( > and found no mention of this software.  H The publication of the files were delayed due to some internal red tape. I'm workingo on making them available ASAP.     Paul A. Jacobi Compaq Computer Corporation-! OpenVMS Systems Group, ZKO3-4/U14  110 Spitbrook Road Nashua, NH 03062-2698l Email: Paul.Jacobi@compaq.com-   ------------------------------   Date: 14 Jul 2000 20:30:45 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)& Subject: Re: IDE CD-ROM audio support?6 Message-ID: <8knt9l$5g1$1@mailint03.im.hou.compaq.com>  ] In article <8knrk3$5h0$1@lead.zk3.dec.com>, "Paul A. Jacobi" <Paul.Jacobi@compaq.com> writes:o* :<clark@sander.stsci.edu> wrote in message$ :news:8khvcq$679$2@tomm.stsci.edu... :># :>   I went to the artical's link -b< :> http://www.openvms.compaq.com/openvms/freeware/index.html) :> and found no mention of this software.e :rI :The publication of the files were delayed due to some internal red tape.i :I'm working :on making them available ASAP.)  >   I'm a major part of the snarl that's slowing this all down.   H   Given my present heads-down work, the files won't make it up onto the :   website until roughly Tuesday or Wednesday of next week.  E   Pending that availability, the files will be available for the nexth   few days at the following:  !     ftp xfer.americas.digital.comu)     username: anonymous (case sensitive) n"     password: (your email address)     cd to_customer     bin      get DQDRIVER.BCK     byec  J   I'll reload the DQDRIVER.BCK file early next week, to keep it available -   until the Freeware website can get updated.   F   If the BACKUP saveset attributes get corrupted by the FTP transfer,    please first try to use the:  '     RESET_BACKUP_SAVESET_ATTRIBUTES.COMn     tool that is available at:  5     http://www.openvms.digital.com/freeware/000tools/c     to reset the attributes.  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Fri, 14 Jul 2000 14:32:00 -0600m- From: Lorin Ricker <Lorin.Ricker@t-netix.com>sE Subject: Looking for VAX->Alpha SCAN port? (was: VMS Pascal question)aI Message-ID: <418E68E524A8D311ACCE00508B78866A7680BF@exchange.t-netix.com>e  ( In a private message, Stan Quayle asked:  : > I'm porting a product from VAX to Alpha.  It's mostly C,: > but here are some modules in SCAN -- but I can't find it4 > on the DECUS site.  Can you point me to somewhere 
 > on the web?l" > Thanks in advance for your help.  J Stan, I've done a quick check on the DECUS online library, and was able to  turn up only the following page:  < http://www.decus.org/libcatalog/description_html/v00576.html  I ...which gets you to the distribution for the old *VAX* SCAN distribution D kit, which DEC kindly contributed into DECUS "freeware" distributionK (perhaps as a sop to mask their embarrassment in not porting and supportingI it on Alpha/VMS? ;-).o  @ However, I *do* remember reading *somewhere* about a package andF distribution which *is* Alpha-bits SCAN (!), but to my own chagrin andF embarrassment, I can't for the life of me remember where... although IB *thought* it was either here in this VMS newsgroup or in the DECUS website(?!?!).  K Perhaps someone else (with better brain-cells ;-) would kindly jump in witha9 a pointer?  I'd like to download and try it too!  Thanks!f  
 cordially,  @ Lorin Ricker                            Lorin.Ricker@T-NETIX.com
 Director, JMS.5 T-NETIX, Inc.                           (303)705-5575w 67 Inverness Drive East 8 Englewood, Colorado 80112      http://www.LockTrack.com/   ------------------------------  % Date: Sat, 15 Jul 2000 00:08:31 -0400 * From: David A Froble <davef@tsoft-inc.com>2 Subject: Re: New Posting from Shannon Knows Compaq- Message-ID: <396FE3BF.622BF9AA@tsoft-inc.com>c   John Nixon wrote:h > M > Is it just me (again) or is the Acersoft site unreachable.  (Dont they sello& > some system reliability tools?  :-))  9 Came right up for me.  12:07 AM Eastern DST July 15, 2000t   Dave   -- h4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  # Date: Fri, 14 Jul 2000 17:58:54 GMTE= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) % Subject: Re: Old VMS Manuals, Ver 4.7h0 Message-ID: <009ED124.1C3AD97E@SendSpamHere.ORG>  j In article <000001bfedb8$3d0b9d80$77c9fbb6@seatimes.com>, Arty Seibert <asei-ele@seattletimes.com> writes:G >I would like to find a User's Manual and a System Manager's Manual forn >MicroVMS Version 4.7.  G I don't have V4.7 but I have a full "gray wall" V5.5 (or thereabout) innG my garage.  A company was going to toss it and asked if I wanted it.  ItF actually for got I had them in the garage until I needed to get to theG electrical service this past week.  I saved them thinking that somebody H might want them (I already have a full 'gray wall', and an 'orange wall'' and a 'blue wall' and a 'white wall'.).k  G I'm in Southern NJ and will gladly meet at some convenient 1/2way point F (within reason) to hand these off to a good home.  So, to quote from aH Paul McCartney lyric written for Badfinger, "If you want it, here it is, come and get it."    --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM    ------------------------------  # Date: Sat, 15 Jul 2000 03:19:50 GMT $ From: nickerson@mirage.boeing.com ()% Subject: Re: Old VMS Manuals, Ver 4.7 ( Message-ID: <FxpyL2.Lyn@news.boeing.com>  : In article <000001bfedb8$3d0b9d80$77c9fbb6@seatimes.com>, 0 Arty Seibert <asei-ele@seattletimes.com> writes:  H |>I would like to find a User's Manual and a System Manager's Manual for |>MicroVMS Version 4.7.i  6 wow there's an old version; out of curriosity can you 9 tell us what the system is used for; I'm here in Seattle i9 and always on the lookout for VMS shops (of any version);$   --bn (Bart Nickerson)h nickerson@pundit.ds.boeing.com (206) 662-0183   ------------------------------    Date: 14 Jul 2000 22:43:54 -0500/ From: jlauret@?.chem.sunysb.edu (Jerome LAURET)t- Subject: Re: print/delete dows not behave ...s. Message-ID: <396fcfea_2@dilbert.ic.sunysb.edu>  ` In article <396b5d1a_3@dilbert.ic.sunysb.edu>, jlauret@?.chem.sunysb.edu (Jerome LAURET) writes:   |>	Richard,u |>> |>	Thanks for confirming this. Now we are making BIG progress.M |>I came up with the same conclusion in my preceding posting/reply (I should nL |>definitly read all articles before answering). For me, whenever the queue M |>manager is on a 7.2 node, the /DELETE fails. If on a 6.2 node, it succeeds lK |>everywhere. This problem did not occur before because we were all at 6.2.iM |>Even older than that, I had not seen this problem neither with 6.1/6.2 mix.e |> |>J |>	Now that we are actually 2 to have seen that (volonteer to try this outH |>in mix environment would be really great), is DEC/Compaq aware of thisM |>and does a patch actually exists for this problem ??? I could not find one.y< |>Anyboddy with a support contract, can you try and call ... |> |> [...]e     	Answering to myself ?  G 	Nope ! But, thanks to everyone who has answered, and especially to theiK posting by Richard Dyson, I think we have cornered the problem to a mix OS bG environment where the QUEUE_MANAGER is starting on an OpenVMS7.2 node. o  H 	I would definitly appreciate if this can be confirmed by anyone who hasR a mixed environment. Starting/stoping the queue manager is not a big job so in can- be done quickly ... and help to confirm this.r 	m  A 	I am hoping that this problem will be seen as serious by Compaq t& support and that a patch will follow.       	Any candidate for more tests ??       --  6                   Jerome LAURET S.U.N.Y. @ Stony Brook$        ,,,,,      Dept. of Chemistry+       ( o o )     Stony Brook NY 11794-3400a;   ---m---U---m--------------------------------------------- &   E-mail: jlauret@mail.chem.sunysb.edu<   URL   : http://nucwww.chem.sunysb.edu/jlauret/jlauret.html   ------------------------------  % Date: Fri, 14 Jul 2000 12:17:06 -0700t3 From: Jeff Coffield <Jeffrey@DigitalSynergyInc.com>m3 Subject: Re: SQL+ODBC options, inexpensive or free?d5 Message-ID: <396F6732.FAD1D23E@DigitalSynergyInc.com>I   David Mathog wrote:m  I > What are the options, if any, for a free (or very inexpensive) SQL+ODBCfF > program for OpenVMS Alpha?   One of my users has a project which mayM > require this, performance shouldn't be that big an issue, but cost will be.  > J > I've seen posts here of people working on, or thinking about working on,H > the various open source database projects.  Have any of these resulted > in a working OpenVMS port? >vI > Am I the only one who finds it odd that the OpenVMS guys are working sotM > hard on Apache without, apparently, having provided in any way for a servereL > database smaller than RDB or Oracle?  I wonder what the intended market isI > for that work anyway.  The only possible market I see is for a swarm ofeI > DS10s running Apache feeding into a GS series RDB/Oracle back end.  Ie, G > there would already have to be a huge investment in the "core" of the I > cluster so that the very high price of the web servers/cluster licensesfH > doesn't _seem_ so very high by comparison.  Because a cluster of DS10sI > without such an expensive core is going to seem just as expensive as itrH > really is - possible customers are going to blink twice at the clusterM > license prices, and drop dead when they see the RDB/Oracle prices, and will1M > probably "make do" with Linux/mysql on the DS10s instead.  Assuming they gonM > with DS10s at all, since they could just as well do Intel based machines if  > they don't need OpenVMS. >t
 > Regards, >  > David Mathog > mathog@seqaxp.bio.caltech.edu @ > Manager, sequence analysis facility, biology division, Caltech  M Perhaps a little off the topic but FastCGI with Apache allows a web server too effectivly use RMS files. OnetL program written in 1980 in Basic on a PDP-11 now runs on an Alpha and can be accessed from the Internet.sL What a concept... Programmers only need to learn a new screen handler (HTML) and everything else we# have been doing for 20 years works.i   ------------------------------   Date: 14 Jul 2000 18:19:37 GMT) From: leslie@clio.rice.edu (Jerry Leslie)c0 Subject: Re: TCPIP remote node in audit security& Message-ID: <8knljp$fr$1@joe.rice.edu>  $ rifepe@langran.iem.csic.espam wrote: :  : Thank you very much.   You're quite welcome.   G : A couple of things, I found that the security audit give me the full u= : address but you need the terminal en 132 columns to see it.m  C Interesting, I haven't been able to persuade VMS Accounting to use 1 the 132 columns; e.g.:     $ set term/wid=132   $ account/since/briefiI         Date / Time      Type     Subtype     Username      ID     Source I    ----------------------------------------------------------------------cI    14-JUL-2000 02:00:00 PROCESS BATCH       SYBASE       00000271         I    14-JUL-2000 02:21:39 PROCESS NETWORK     SYBASE       00000273 SCCS02    7 (The status column truncated to keep post < 76 columns)W  C : From there, I found that my hacker was using an false IP address.a  B It sounds like time to call in the authorities, and let them track down the cracker's system.  7 These folks might have some tools that could be of use:   9   http://www.eeye.com/html/Databases/Software/nmapnt.htmla   eEye Digital Securityt   : Ricardo Fernandez-Perea.    4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------   Date: 14 Jul 2000 19:07:08 GMT# From: rifepe@langran.iem.csic.espama0 Subject: Re: TCPIP remote node in audit security' Message-ID: <8knocs$n3h$1@tejo.csic.es>n  R In article <8knljp$fr$1@joe.rice.edu>, leslie@clio.rice.edu (Jerry Leslie) writes:% >rifepe@langran.iem.csic.espam wrote:l >: >: Thank you very much.e >a >You're quite welcome. >uH >: A couple of things, I found that the security audit give me the full > >: address but you need the terminal en 132 columns to see it. >	D >Interesting, I haven't been able to persuade VMS Accounting to use  >the 132 columns; e.g.:M >  >  $ set term/wid=132c >  $ account/since/briefJ >        Date / Time      Type     Subtype     Username      ID     SourceJ >   ----------------------------------------------------------------------J >   14-JUL-2000 02:00:00 PROCESS BATCH       SYBASE       00000271        J >   14-JUL-2000 02:21:39 PROCESS NETWORK     SYBASE       00000273 SCCS02  >b  A I has not be able to do it either but the output of analyze/auditkM is longer than 80 colums the source is the last field and the end of the namei8 is just what it is farther away from the normal screen.   8 >(The status column truncated to keep post < 76 columns) > D >: From there, I found that my hacker was using an false IP address. > C >It sounds like time to call in the authorities, and let them trackJ >down the cracker's system.i >18 >These folks might have some tools that could be of use: > : >  http://www.eeye.com/html/Databases/Software/nmapnt.html >  eEye Digital Security >t >: Ricardo Fernandez-Perea.b >r > 5 >--Jerry Leslie     (my opinions are strictly my own)   L I am afraid they are too busy with the ones that got into the linux machines
  around here.    Ricardo Fernandez-Pereao   ------------------------------  % Date: Fri, 14 Jul 2000 15:44:47 -0600i- From: Lorin Ricker <Lorin.Ricker@t-netix.com>n* Subject: Re: UCX 4.2 -> TCPIP 5.0A upgradeI Message-ID: <418E68E524A8D311ACCE00508B78866A7680C0@exchange.t-netix.com>a   Chris Sharman wrote:E > I'm considering doing this upgrade in advance of the 7.1 -> 7.2[-1]  > upgrade. ...J > Anyone know which if any of these will need upgrading or re-installing ?H > Any other views/experiences anyone wants to share? Does it co-exist OK. > with UCX 4.2 (and 4.0) in the same cluster ?  J Well, to start with, the "TCP/IP" code in 7.2 *isn't* the same as what wasG used for older "UCX" (pre-v5.0), and *my* war story is about how we goto! burned on a pretty esoteric item.-  G Guess we got burned on the assumption that a code-port done by "the bigyJ boys" will be OK to use without any pre-production testing... ha!  Or thatK "Unix is Unix", i.e., that substituting the "Berkeley code base" TCP/IP for@( the older one would be just ducky... Ha!   <war-story> J Short-form:  We've got a client-server application, a VB "thin-client" appI which talks across the net to its VMS-based server app (Alphas, user-modeEJ applications, and a simple "application private protocol" on top of Telnet. transport... i.e., we just "talk characters").  A After upgrade to VMS 7.2 (summer'99), normal reboots, restarts ofxA everything, including new "TCP/IP" (v5.0) package.  Terminal-cell F "traditional user interface" (TUI!) applications in same suite workingK fine... however, client-server (GUI) applications *cannot connect*... panics( ensues!  Paying customers can't connect!  I After about an hour of frantic debugging at the "watch the character-data K stream" between host and client, we finally figured out that, with this newpG package, the base-level Telnet terminal characteristics negotiation wastE broken (er, had "changed"... so much for RFC's, no?).  Turns out thatsG although our client & server app's were trying to negotiate NO ECHO formF their link, this new TCP/IP code was ignoring the negotiated commands.  I Short-term solution... an ugly kludge in SYLOGIN.COM to force/stomp a SETaJ TERMINAL /NOECHO into the midst of the c-s conversation (that *did* work);I meanwhile, and sometime (and headaches) later, we were at least partially J responsible for the release of the TCP/IP V5.0A fix-up kit, which repaired3 the faulty honoring of Telnet startup negotiations.1  L Morals & lessons learned?  Yes, even us ol' VMS veterans can still manage toL shoot ourselves in the foot by jumping in too quickly where a new release isG concerned.  And we've renewed our respect (contempt!) for the notion of. "portable Unix code"!h </war-story>  E Please pardon any inaccuracies or over-elaborations in the telling of L this... we were just outsiders (victims!) looking in, and I've scant insightK on the inner intricacies of such things.  I know that Frank da Cruz and his.= Kermit team (who have written eloquently on matters of TelnettF term-characteristics negotiation) know much more about this than I do.  K Chris, I do know that, in our experience, *ordinary stuff* like plain old $0I TELNET host and $ FTP host seems to work find, both between two VMS nodes:I running v7.2(-1) and V5.0A, and also seem to function OK with the limitedcI number of non-VMS nodes we've communicated with.  So, IMHO, "plain stuff"<J will probably work OK for you too... but if you've got anything home-grownD and/or off-the-beaten-path, then be sure to check/test/evaluate in a; safe-mode before committing to production or the like!  ;-)/    Hope this helps, not confuses...   regards,  @ Lorin Ricker                            Lorin.Ricker@T-NETIX.com
 Director, JMSe5 T-NETIX, Inc.                           (303)705-5575  67 Inverness Drive Eastn8 Englewood, Colorado 80112      http://www.LockTrack.com/   ------------------------------  % Date: Fri, 14 Jul 2000 20:52:34 -0400l& From: Mickalide <mickalide@empire.net> Subject: Re: Using CMS and NFS* Message-ID: <396FB5D2.2E70D561@empire.net>  H This sounds similar to a problem I worked on last year from an AXP to anJ VAX 5.5 system. If I remember correctly CMS was only sending a partial XABI field. What are the releases of the systems and CMS? When I get back intoQI work on Tuesday I can pull up the IPMT and  find out what ECO the fix wase in.i   -Jim-t   Tony Wright wrote:  I > I have sucessfully mapped a disk from a 433Au onto a ds10. The point oftG > this was to enable us to develop using one CMS library sitting on theaC > 433. Unfortunately when sittingat the DS10 and typing CMS SET LIBt2 > AUdisk:[wherethecmslibraryis] I get the messages >-? > %CMS-E-NOREF, error referencing audisk:[wherethecmslibraryis] F > -CMS-E-NOTCMSLIB, audisk:[wherethecmslibraryis] is not a CMS libraryB > -RMS-E-COD, invalid or unsupported type field in XAB at 001AE8E4' > %CMS-W-UNDEFLIB, library is undefinedk >t, > (AUDISK is a logical that point at dnfs5:) >N$ > Is what I'm trying to do possible?   ------------------------------  # Date: Sat, 15 Jul 2000 02:47:14 GMT 4 From: jonadab@bright.net (Jonadab the Unsightly One) Subject: Re: VMS 7.3 wish list. Message-ID: <396fad65.2201745@news.bright.net>  6 Richard  <maher_rjNOmaSPAM@hotmail.com.invalid> wrote:   >  Add TCP/IP compatibility.  3 A chap at Gaylord told me that the Alpha comes with 3 TCP/IP out of the box, which is why we're upgradinga4 our Vax to an Alpha in preparation for adding WebPAC to our Galaxy system.  a  	 - jonadabo   ------------------------------    Date: 14 Jul 2000 18:58:01 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)e Subject: Re: VMS 7.4 wish list+ Message-ID: <TePjGbJVI$Tu@eisner.decus.org>s  q In article <031c800c.d03031be@usw-ex0110-076.remarq.com>, Richard  <maher_rjNOmaSPAM@hotmail.com.invalid> writes:p  : > I would like to add the following DECdtm enhancements to+ > the wish list for a furure VMS release :-f > 8 >  All system services documented. Especially the branch > management services.  > Generally they keep things undocumented if they think they are@ likely to change them.  I would say the time during which DECdtm2 might be significantly changed is long since gone.   ------------------------------    Date: 14 Jul 2000 19:10:46 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)  Subject: Re: VMS 7.4 wish list+ Message-ID: <3T23ST9eNmLN@eisner.decus.org>   a In article <8kneg7$kg2@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu (David Mathog) writes:0  L > Anyway, as a small but useful step towards a bit more restraint in the OS,L > and better compatibility with other OS's how about at 7.4 simplify the use< > of text file types, so that they all default to stream-lf.  L > What advantage is there in having so many different types of text files?    H Certainly one advantage at this point is that existing programs continue to work.  I > But if you're creating and using the text files _locally_, why use moreF > than one text format?r  B A major reason is to support those people porting in programs from. Unix, where a file is just a stream of bytes !  M > In particular, the two VARIABLE record formats are a real pain to share viaSJ > NFS or SMB. As viewed from Unix or Windows the first one has two "extra"M > bytes at the front of each line and no terminator, the latter has four such0G > bytes and no terminator.  The only way to safely move them to anothereL > system is to use something like ASCII FTP - which if you're going to Unix,1 > converts them to stream-lf on that end anyway. a  D Certainly one of the stream formats is better for sharing with Unix.B And as I recall, a _different_ one of the stream formats is better for sharing with Macintosh !!!  H > However, if everything is to make stream-lf by default, then how aboutI > FINALLY making SORT, TYPE, and the rest of the standard utilities smart'& > enough to handle stream-lf properly?  A Yes, that sounds good.  With some common callable routines to letd? others get the same benefit for their software.  Of course I do < disagree with the idea of changing the default to stream-lf.   ------------------------------  % Date: Fri, 14 Jul 2000 18:20:03 -0600.- From: Lorin Ricker <Lorin.Ricker@t-netix.com>b Subject: Re: VMS 7.4 wish listI Message-ID: <418E68E524A8D311ACCE00508B78866A7680C2@exchange.t-netix.com>9   David Mathog writes:  L > Anyway, as a small but useful step towards a bit more restraint in the OS,L > and better compatibility with other OS's how about at 7.4 simplify the use? > of text file types, so that they all default to stream-lf...    J IMO, I can't think of a worse choice for text files than stream-LF.  GivenK the extreme breakage in mission-critical, already running applications thateL such a change would no doubt cause, this idea gets an adamant "NO" vote fromJ me... especially when I consider the grief that applications would come toK whilst waiting for the dust to settle in all the RTL I/O support that wouldeK have to be modified, debugged, and "unusual cases" dealt with in the field.tJ And it's always seemed to us that VMS's *structured* text-format is a realB strength compared to just-a-long-string-of-undifferentiated-bytes.  K As a matter of fact, I've got text editor tricks and com-files at the readya* to CONVERT stream-LF files to "normal" VMSG variable-length/CR-carriage-control files.  I guess this one's really agI point-of-view problem, David... what's right/desirable for you just ain't,J for me, and visa-versa.  For me, porting Unix source files around isn't anJ issue or concern, while it seems to be high on the list of things that bug' you or you have to cope with routinely.t  I And it seems to me that, at least at one point, old Pathworks was doing aNI fair-to-middling job of "automatically converting, on the fly" text filesnI to-and-from VMS "normal" text-file format to-and-from PC's idea of a text L file (which is something like stream-LF, right?... or is it stream-CRLF? ...K or stream-CR?).  Anyway, at its root, this is just a problem for a com-file  and CONVERT/FDL, isn't it?  J But, yes, extending the standard utilities and appropriate RTL support forJ stream-LF, etc., *does* seem like a desirable thing, 'tho not very high on my own favorites list.  
 Respectfully,n   Lorin Ricker   ------------------------------  % Date: Fri, 14 Jul 2000 14:17:17 -0600o- From: Lorin Ricker <Lorin.Ricker@t-netix.com>n  Subject: Re: VMS Pascal questionI Message-ID: <418E68E524A8D311ACCE00508B78866A7680BE@exchange.t-netix.com>o    koehler@eisner.decus.org writes:  D >  The DEC Pascal User's Guide will contain a discussion of mappingsB > between Pascal data types and VMS data types and how to call VMSE >  routines.  Most of the documentation for VMS routines like SMG$ is = >  language non-specific, with examples in several languages.-  J Yup... pardon me for forgetting the obvious.  The DEC PUG is indeed a goodJ source of information for creating VMS data structures in Pascal.  Guess IG forgot to cite this one 'cause we do so much of it in my shop that it'sfL pretty much "in the fingers"... And I don't mean to sound like I'm boasting;J just trying to encourage you to believe that, with a little practice, it'sL possible to read the basic VMS documentation for, say, a system service, andG code up the Pascal data type straight from that --- the mappings becomes( quite obvious and natural with exposure.  L BTW, does anyone remember Wirth's old textbook "Algorithms + Data StructuresK = Programs" ?  Germane here, yet kind'a marks us old-timers, don't it?  ;-)n   regards,   Lorin Ricker   ------------------------------  % Date: Fri, 14 Jul 2000 15:58:12 -0600l- From: Lorin Ricker <Lorin.Ricker@t-netix.com>e  Subject: Re: VMS Pascal questionI Message-ID: <418E68E524A8D311ACCE00508B78866A7680C1@exchange.t-netix.com>l  5 > And that's why the good old TeX on the VMS platform / > translates WEB into Pascal and not into C ...r   > Ralf > --=20sG >   Ralf G=E4rtner                gaertner@cthulhu.westfalen.de (home & 
 preferred)9 >   =D6tztalerstr. 5b             gaertner@decus.decus.decF >   D - 81373 M=FCnchen           rgaertne@dbmail.debis.de      (work) >   FRGcB >          System/Network Manager & DECUS TeX Developer/MaintainerF >     ~~~  Too old to Rock 'n Roll - too young to die (Jethro Tull)  = ~~~s    I Bravo, Ralf!  I'm also a big TeX fan and user too, which tells you what =u kindF of an old, obsolete anachronism I'm getting to be!  ;-)  Sometimes I = get the G sense that today's vanguard of programmers is interested primarily in =g makingE pretty colored rectangles on screens, not programs that actually *do*i+ anything useful, like compute something!...,  E Actually, as I recall, Don Knuth wrote original versions of TeX *in =c Pascal*,G with full intentions of multi-platform portability... with that kind oftF practical endorsement from one of our profession's "grand wizards", it: really says something for Pascal and data structuring, no?  ( Thanks for the wise & pithy observation!  @ Lorin Ricker                            Lorin.Ricker@T-NETIX.com
 Director, JMSM5 T-NETIX, Inc.                           (303)705-5575s 67 Inverness Drive East-8 Englewood, Colorado 80112      http://www.LockTrack.com/   ------------------------------  % Date: Fri, 14 Jul 2000 18:58:26 -0400i( From: Lori Chapman <lori@chapvision.com> Subject: weight loss productsc5 Message-ID: <200007142258.SAA03942@mail1.syclone.net>q  	 --divider , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit         	 --dividerdG Content-Type: application/octet-stream; name="business opportunity.txt"bD Content-Disposition: attachment; filename="business opportunity.txt"! Content-Transfer-Encoding: base64/  H WW91IGFyZSByZWNlaXZpbmcgdGhpcyBlLW1haWwgYmVjYXVzZSB5b3UgaGF2ZSBiZWVuIHBsH YWNlZCBvbiBhDQptYWlsaW5nIGxpc3QuIElmIHlvdSBkaWQgbm90IHJlcXVlc3QgdG8gYmUgH cHV0IG9uIG91ciBsaXN0LCBvciB5b3Ugbm8NCmxvbmdlciB3aXNoIHRvIHJlY2VpdmUgYW55H IGZ1cnRoZXIgZS1tYWlsIGZyb20gb3VyIG1hcmtldGluZyBsaXN0LA0KeW91IGNhbiBoYXZlH IHlvdXIgbmFtZSByZW1vdmVkIGZyb20gb3VyIGxpc3QgYnkgZm9sbG93aW5nDQp0aGUgJ1JFH TU9WRScgaW5zdHJ1Y3Rpb25zIGF0IHRoZSBlbmQgb2YgdGhpcyBlLW1haWwuDQoNCkhlbGxvH LA0KDQpDaGVjayBvdXQgb3VyIHByb2R1Y3RzIGF0ICBodHRwOi8vd3d3Lm1icmFjZWxpZmUuH Y29tDQogIA0KSWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIG1ha2luZyBleHRyYSBtb25leSBhH bmQgc3RhcnRpbmcgeW91ciBvd24gd29yayBmcm9tIGhvbWUgYnVzaW5lc3MsIA0KDQp2aXNpH dCBodHRwOi8vd3d3LmxpZmViZWdpbnN0b2RheS5jb20NCg0KV291bGQgeW91IGxpa2UgdG8gH YmVjb21lIHBhcnQgb2YgdGhlIGxhcmdlc3QgYW5kIGZhc3Rlc3QgZ3Jvd2luZyBoZWFsdGgsH IG51dHJpdGlvbiAmIHdlaWdodCBsb3NzIGNvbXBhbnkgaW4gdGhlIHdvcmxkLiAgV2UncmUgH bm93IGluIG91ciAyMHRoIHllYXIgaW4gYnVzaW5lc3M7IHdlJ3JlIGxpY2Vuc2VkIGluIDQ4H IGNvdW50cmllczsgYW5kIGxhc3QgeWVhciBvdXIgc2FsZXMgd2VyZSBqdXN0IHVuZGVyICQyH IGJpbGxpb24uICBXZSBhcmUgYWxsIGFib3V0IGhlbHBpbmcgcGVvcGxlIHdpdGggdGhlIG1hH bnkgaGVhbHRoIHJlbGF0ZWQgcHJvYmxlbXMgZHVlIHRvIHBvb3IgbnV0cml0aW9uLiAgVG8gH ZGF0ZSwgb3ZlciAzMSBtaWxsaW9uIHBlb3BsZSBoYXZlIHN1Y2Nlc3NmdWxseSB1c2VkIG91H ciBwcm9kdWN0cy4gIFdlIGhhdmUgcHJvZHVjdHMgdG8gaGVscCBwZW9wbGUgbG9zZSB3ZWlnH aHQsIGdhaW4gd2VpZ2h0IGFuZCBpbmNyZWFzZSBlbmVyZ3kuICBXZSBoYXZlIGhlbHBlZCBtH aWxsaW9ucyBvZiBwZW9wbGUgd2l0aCBoaWdoIGJsb29kIHByZXNzdXJlLCBoaWdoIGNob2xlH c3Rlcm9sLCBtaWdyYWluZXMsIGRpYWJldGVzLCBhbGxlcmdpZXMsIGFzdGhtYSwgdWxjZXJzH LCBoZWFydGJ1cm4sIGNpcmN1bGF0aW9uLCBhbnhpZXR5LCBzdHJlc3MsIHNsZWVwIGRpc29yH ZGVycywgYXJ0aHJpdGlzLCBmeWJyb215YWxnaWEsIG9zdGVvcG9yb3NpcywgUE1TLCBtZW5vH cGF1c2UsIEFERCAmIEFESEQuICBXZSBhbHNvIGNhcnJ5IGFuIGV4Y2x1c2l2ZSBsaW5lIG9mH IHRoZSBhYnNvbHV0ZSBiZXN0IHNraW4gY2FyZSwgaGFpciBjYXJlLCBjb3NtZXRpY3MgYW5kH IHBlcnNvbmFsIGNhcmUgcHJvZHVjdHMuICANCg0KVGhhbmtzIGZvciB5b3VyIHRpbWUuIElmH IHlvdSBrbm93IG9mIG90aGVyIHBlb3BsZSB0aGF0IG1heSBiZSBpbnRlcmVzdGVkIGluIHRoH ZXNlIHByb2R1Y3RzIG9yIGxvb2tpbmcgdG8gbWFrZSBleHRyYSBtb25leSwgYmUgc3VyZSB0H byBzZW5kIHRoZW0gdGhlIGxpbmtzIHRvIG15IHdlYiBwYWdlcy4gWW91IG1heSBlbWFpbCBtH ZSB3aXRoIGFueSBxdWVzdGlvbnMuIA0KDQpMb3JpIA0KDQoNClRoaXMgbWFpbGluZyBpcyBkH b25lIGJ5IGFuIGluZGVwZW5kZW50IG1hcmtldGluZyBjby4NCldlIGFwb2xvZ2l6ZSBpZiB0H aGlzIG1lc3NhZ2UgaGFzIHJlYWNoZWQgeW91IGluIGVycm9yLg0KDQpUaGlzIG1lc3NhZ2UgH aXMgc2VudCBpbiBjb21wbGlhbmNlIG9mIHRoZSBuZXcgZS1tYWlsIGJpbGw6DQpTZW5hdGUgH YmlsbCAxNjE4LCBUaXRsZSAzLCBzZWN0aW9uIDMwMS4NClRPIEJFIFJFTU9WRUQgRlJPTSBUH SEUgTUFJTElORyAgTElTVA0KQW5kIHRvIGVuc3VyZSB5b3UgZG8gbm90IHJlY2lldmUgZnVyH dGhlciB0cmFuc21pc3Npb25zIHRvIHlvdQ0KYnkgdGhlIHNlbmRlciBvZiB0aGlzIGVtYWls< ICBQUkVTUyBSRVBMWSBBTkQgUFVUDQp0aGUgU3ViamVjdCBSRU1PVkUNCg0K   --divider--u   ------------------------------  % Date: Fri, 14 Jul 2000 14:52:36 -0400x* From: Chuck Chopp <ChuckChopp@rtfmcsi.com>  Subject: Re: WTB TK50 Cartridges+ Message-ID: <396F6174.64A40E2F@rtfmcsi.com>n   > unixguys@my-deja.com wrote:i >n6 > > As it says I'm looking for a few carts for a tk50. > >e* > > Sent via Deja.com http://www.deja.com/ > > Before you buy.  >)  G OK, I just dug out the two boxes of TK cartridges that I could find andnH they were all just TK50's.  I could not find any TK70's in the two boxesG that I could find.  I might have one more box of tapes around the housegI some where in storage, but they aren't leaping out at me right now to sayb where they are.u  H I have 101 of the TK50 cartridges in their plastic cases.  About half ofK them were purchased as blanks for use as regular backup media and the otheruH half are software distribution tapes that were only written one time and? then stuff into a vault after we used them to install software.M  H I don't really need all of these TK50 cartridges so if somebody wants toH make an offer on them I'd gladly sell them to get rid of them.  It wouldI make my wife happy if some of this stuff ended up occupying space in somer place other than in our house.     Chuck( -- Chuck Choppe  8 ChuckChopp@rtfmcsi.com            http://www.rtfmcsi.com0                                   ICQ # 22321532@ RTFM Consulting Services Inc.     864 801 2795 voice & voicemail2 103 Autumn Hill Road              864 801 2774 fax4 Greer, SC  29651                  800 400 4935 pagerC                                   8004004935@alphapage.airtouch.comt   ------------------------------   Date: 14 Jul 2000 12:45:17 PDTT From: Fairfield@SLAC.Stanford.EDU (Ken Fairfield; SLAC: 650-926-2924; FAX: 926-3515); Subject: [Q] What SCSI tapes drives does VMS 5.5-2 support? 3 Message-ID: <$EPNU4c0TUGQ@mccdev.slac.stanford.edu>n  H         We have an old VAXstation 3100/38 running VMS 5.5-2 (I think, itH     is definitely some  variation  of  V5.5).   It  is  running a customH     application  for which uses a Kinetic Systems SCSI-CAMAC  controllerH     with the vendor-supplied SCSI device driver.  Because the author  ofH     the  application  has retired, and because it is not clear what workH     would need to be done to get  the device driver running under a moreH     recent  version  of  VMS  (let alone, Alpha/VMS),  we're  not  in  a      position to upgrade the O/S.  H         Amazingly enough, this stand-alone system which runs pretty muchH     7x24 and mostly unattended, has _no_ removable storage!  In order toH     capture a snapshot of its two disks,  I  had to add it to my cluster@     last summer and do backups to my disks (and thence to tape).  H         Therfore, I'd like  recommendations  for  a  tape drive for thisH     system.   The  requirements are that VMS 5.5 support the  drive  andA     that I can build (and boot and run!) STABACKIT on that drive.x  H         My first thought was an 8mm  drive, which would probably need toH     be  an older 8200 variety.  But I can't recall whether STABACKIT canH     be built on 8mm drives.  And personally, I  don't  like  8mm  drives     much at all...  H         Thinking about it, I'd probably prefer  something like a TZ86 orH     TZ87.   Does VMS 5.5 support these drives, and can I get them  (usedH     equipment  certainly)  in  table-top  enclosures?   What  about  4mm     drives?            Thanks, Kenc -- eM  Kenneth H. Fairfield            |  Internet: Fairfield@SLC.Slac.Stanford.EduX:  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: Fri, 14 Jul 2000 23:57:08 -0400p2 From: rdeininger@mindspring.com (Robert Deininger)? Subject: Re: [Q] What SCSI tapes drives does VMS 5.5-2 support?oL Message-ID: <rdeininger-1407002357080001@user-2ivebgl.dialup.mindspring.com>   In article <$EPNU4c0TUGQ@mccdev.slac.stanford.edu>, Fairfield@SLAC.Stanford.EDU (Ken Fairfield; SLAC: 650-926-2924; FAX: 926-3515) wrote:W  J >         We have an old VAXstation 3100/38 running VMS 5.5-2 (I think, itJ >     is definitely some  variation  of  V5.5).   It  is  running a customJ >     application  for which uses a Kinetic Systems SCSI-CAMAC  controllerJ >     with the vendor-supplied SCSI device driver.  Because the author  ofJ >     the  application  has retired, and because it is not clear what workJ >     would need to be done to get  the device driver running under a moreJ >     recent  version  of  VMS  (let alone, Alpha/VMS),  we're  not  in  a" >     position to upgrade the O/S.  H You should perhaps revisit this choice.  We have a microvax 3500 (Q-bus)F talking to CAMAC though an MBD, with a locally-repaired descendent of E very buggy LAMPF Q device driver.  Our driver probably has nothing intE common with yours, so take our experience with a grain of salt.  WhenOE we went from 5.5-2 to 7.1, I'm pretty sure the driver didn't need any F changes.  We definitely re-assembled it, which I think is a documentedG requirement for new OS versions.  Assuming you have the source code, ora can pry it out of Kinetic Systems, I suggest you TRY the driver on a newer version of VMS.  At the very least, ask KS to rebuild the driver for youcJ on VMS 7.1.  Try it on a spare system before you clobber the existing one. (3100s show up on ebay a lot.)  J Device drivers are designed to not break across OS versions, provided theyI follow the documented rules.  I think there's a very good chance it wouldl work without much trouble.  There were some changes required before 5.5-2, but once you got a driver that far, it seemed to stay happy.   b The application that calls the driver  might not even need to be re-linked.  Your milage may vary.  F 7.1 would give you LOTs more tape drive options.  Generic SCSI device  support is pretty good.g  .J >         Amazingly enough, this stand-alone system which runs pretty much= >     7x24 and mostly unattended, has _no_ removable storage!:  F Which part is amazing?  Not the 7x24 unattended, surely.  And the 3100M was pretty low-end when new, and there were no low-end tape drives back then. } (You could get a 3100 with a floppy drive, but that hardly counts.)  So this sounds like a normal situation, not amazing. :-)t   >     In order totJ >     capture a snapshot of its two disks,  I  had to add it to my clusterB >     last summer and do backups to my disks (and thence to tape).   Not a bad solution.  If it's not too often, this seems fine.  Unless the network police have cut off your MOP and SCS traffic to this poor old system.  iJ >         Therfore, I'd like  recommendations  for  a  tape drive for thisJ >     system.   The  requirements are that VMS 5.5 support the  drive  andC >     that I can build (and boot and run!) STABACKIT on that drive.a  G Check the exact OS version.  There is quite a lot of difference betweeno 5.5 and 5.5-2.  sJ >         My first thought was an 8mm  drive, which would probably need toJ >     be  an older 8200 variety.  But I can't recall whether STABACKIT canJ >     be built on 8mm drives.  And personally, I  don't  like  8mm  drives >     much at all...  H I don't know if we could boot from an exabyte 8200 on our system, but weM have a very peculiar SCSI interface.  You'll probably have to try it.  SurelyoI someone can provide an 8200 for a test?  Nobody covets those damn beasts.,I But I agree with you, an 8mm should be last resort.  4mm DAT may be a bitaG less flakey, but I've not used them.  Any sort of DLT-class drive wouldt be far superior.  N I believe there was once a DEC-labeled exabyte of the 8200 class.  If anythingJ would boot, that would be the most likely.  Might be hard to find, though.    J >         Thinking about it, I'd probably prefer  something like a TZ86 orJ >     TZ87.   Does VMS 5.5 support these drives, and can I get them  (usedJ >     equipment  certainly)  in  table-top  enclosures?   What  about  4mm
 >     drives?7  H Dunno.  We skipped from 8200 drives to DLT 4000, so I have no experienceL with TZ8x.  5.5 may be too old.  Getting one to fit into an enclosure should0 be easy.  As a last resort, buy a DLT enclosure.   -- e Robert Deininger rdeininger@mindspring.comd   ------------------------------  % Date: Sat, 15 Jul 2000 00:14:59 -0500i) From: "John E. Malmberg" <wb8tyw@qsl.net>a? Subject: Re: [Q] What SCSI tapes drives does VMS 5.5-2 support?h7 Message-ID: <0f3301bfee1b$a1c08660$020a0a0a@xile.realm>   3 In article <$EPNU4c0TUGQ@mccdev.slac.stanford.edu>,i! Fairfield@SLAC.Stanford.EDUcation 9 (Ken Fairfield; SLAC: 650-926-2924; FAX: 926-3515) wrote:p  J >         We have an old VAXstation 3100/38 running VMS 5.5-2 (I think, itJ >     is definitely some  variation  of  V5.5).   It  is  running a customJ >     application  for which uses a Kinetic Systems SCSI-CAMAC  controllerJ >     with the vendor-supplied SCSI device driver.  Because the author  ofJ >     the  application  has retired, and because it is not clear what workJ >     would need to be done to get  the device driver running under a moreJ >     recent  version  of  VMS  (let alone, Alpha/VMS),  we're  not  in  a" >     position to upgrade the O/S.  I I have not looked up the old VMS 5.5-2 CD-ROM and it's associated S.P.D.,fJ but VMS 5.5-2 seems to have no problems accessing TF86 drives directly, or< TZ85 / TZ86 / T787 / TK50Z drives hung off of an Infoserver.  H I do not remember what version of VMS supports TLZ06 drives, but I thinkJ there may be an ECO to add that on, if VMS 5.5-2 does not directly supportI it.  VMS 5.5-2 is definitely happy with TLZ04 drives, if you can keep the.
 drives alive.)  L Your cheapest option may be to find a used set of small RZ26 drives that can9 be put in an external enclosure and keep multiple copies.d  K You can then connect that SCSI enclosure to a newer system, and back up thenF drives to more modern media.  Possibly putting the files on a bootable) CD-ROM so that you can restore them fast.-   -John  wb8tyw@qsl.network   ------------------------------   End of INFO-VAX 2000.392 ************************