1 INFO-VAX	Mon, 03 Jul 2000	Volume 2000 : Issue 368       Contents:4 Re: Compaq Viewed As a PC-Only Company By Analysts ?4 Re: Compaq Viewed As a PC-Only Company By Analysts ? DCL vs. "real" programming Re: DCL vs. "real" programming Re: DCL vs. "real" programming Re: DCL vs. "real" programming" Re: DECnet-Plus or DECnet Phase IV" Re: DECnet-Plus or DECnet Phase IV" Re: DECnet-Plus or DECnet Phase IV" Re: DECnet-Plus or DECnet Phase IV/ FA: Digital DEC Mouse Model VSXXX-AA NO RESERVE 5 FA: Reflection 4 PC to Digital/UNIX Host connectivity : FA: Reflection 4+ For DOS  PC to VAX connection NO RESERVE: FA: Reflection 4+ For DOS  PC to VAX connection NO RESERVE Funny Singing Fish& Re: good news (for me,  I think) . . .) Re: highwater marking, speed vs. security ) Re: highwater marking, speed vs. security ) Re: highwater marking, speed vs. security ) Re: highwater marking, speed vs. security ) Re: highwater marking, speed vs. security  ISDN on ALPHAstation Re: ISDN on ALPHAstation Re: ISDN on ALPHAstation Re: ISDN on ALPHAstation  F ----------------------------------------------------------------------  " Date: Sun, 2 Jul 2000 16:25:25 GMT0 From: "Terry C. Shannon" <shannon@world.std.com>= Subject: Re: Compaq Viewed As a PC-Only Company By Analysts ? & Message-ID: <Fx2w3M.7yD@world.std.com>  5 "Nikita V. Belenki" <kit@nospam.net> wrote in message 2 news:QBh75.960$0x.29664@nuq-read.news.verio.net...C > "Jerry Leslie" <LESLIE@209-16-45-102.insync.net> wrote in message $ > news:by075.1010$5L3.5335@insync... > H > >    As the second quarter comes to an end, analysts are still at odds overK > >    the financial and strategic health of personal computer maker Compaq  > >    Computer.L > >    Today, Salomon Smith Barney analyst Richard Gardner downgraded CompaqJ > >    to "neutral" from "buy" and cut the company's near-term share priceK > >    target to $25 from $45. Gardner cited perceived weakness in PC sales  > >    for the downgrade."H > > There's NO mention of Compaq's non-PC products and services, such as > Tru64, > > OpenVMS, et.al.  > - > What? Compaq losing its money on them, too?   > Of course not. CPQ garners the lion's share of its profit fromL enterprise-class systems, storage, and services. The subject line summarizesB the problem the firm faces. Capellas and Heil and several of theirH lieutenants have said as much, so it's not as if they are unaware of the problem.  I Educating the Wall Street beancounters and the trade press will be easier K said than done, but until CPQ is evaluated as an enterprise vendor, it will ; continue to suffer from being relegated to the PC basement.    ------------------------------  $ Date: Sun, 2 Jul 2000 17:09:53 -0700* From: "Nikita V. Belenki" <kit@nospam.net>= Subject: Re: Compaq Viewed As a PC-Only Company By Analysts ? 9 Message-ID: <4VQ75.1110$0x.33963@nuq-read.news.verio.net>   ; "Terry C. Shannon" <shannon@world.std.com> wrote in message   news:Fx2w3M.7yD@world.std.com...  G > > >    Today, Salomon Smith Barney analyst Richard Gardner downgraded  CompaqL > > >    to "neutral" from "buy" and cut the company's near-term share priceG > > >    target to $25 from $45. Gardner cited perceived weakness in PC  sales  > > >    for the downgrade."J > > > There's NO mention of Compaq's non-PC products and services, such as > > > Tru64, OpenVMS, et.al./ > > What? Compaq losing its money on them, too? @ > Of course not. CPQ garners the lion's share of its profit from2 > enterprise-class systems, storage, and services.  I But a half of its revenues is from PC sales. So if PC sales go bad, there . *is* a reason to worry about Compaq's profits.  9 > The subject line summarizes the problem the firm faces.   K No. The problem is that *customers* think of Compaq as a "PC-only" company.   K You should not blame market analyst for just doing their job. Compaq *is* a J PC company from the market point of view. Look at the Note 9 in their lastC 10-Q and see which segment is growing and which ones are declining.   J Yes, I know that Compaq hopes to sell $1B worth of WildFires by the end ofI the year. But to convince the stock market it must show the result in its  financial documents ;)  ( > Capellas and Heil and several of theirJ > lieutenants have said as much, so it's not as if they are unaware of the
 > problem.K > Educating the Wall Street beancounters and the trade press will be easier  > said than done,   D One or two quarterly reports will do it *if* Compaq is growing as an enterprise vendor.  = > but until CPQ is evaluated as an enterprise vendor, it will = > continue to suffer from being relegated to the PC basement.   J Well, if some of Compaq's potential customers are on the Wall Street, then- Compaq should educate the Wall Street, too ;)    Kit. kit # kits.net   ------------------------------   Date: 2 Jul 2000 16:57:28 GMT * From: helbig@astro.rug.nl (Phillip Helbig)# Subject: DCL vs. "real" programming . Message-ID: <8jns9o$eo4$2@info.service.rug.nl>  G For example, when writing an application which processes a lot of MAIL  B files, would one achieve much better performance by writing it in B Fortran or whatever and using the callable MAIL interface than by  writing .COM files etc in DCL?   ------------------------------  $ Date: Sun, 2 Jul 2000 13:05:26 -0500* From: "Mark E. Levy" <levy@sysman-inc.com>' Subject: Re: DCL vs. "real" programming . Message-ID: <slv0sikkop316@corp.supernews.com>  7 "Phillip Helbig" <helbig@astro.rug.nl> wrote in message ( news:8jns9o$eo4$2@info.service.rug.nl...H > For example, when writing an application which processes a lot of MAILC > files, would one achieve much better performance by writing it in C > Fortran or whatever and using the callable MAIL interface than by   > writing .COM files etc in DCL?  J If it's a one-time shot, use DCL. If you plan to run this procedure often,I use an HLL like Fortran. The difference in run time (and CPU utilization) F can be dramatic. I had a procedure that scanned text files for certainK strings. It ran over 24 hours. Rewritten in Basic, it ran in under an hour.  --E ---------------------------------------------------------------------  Mark E. Levy, President " System Management Associates, Inc.! 888-291-5055 x202 (Illinois Only) $ 847-291-1550 x202 (Outside Illinois) 847-291-3866 fax www.sysman-inc.com levy@sysman-inc.com E ---------------------------------------------------------------------    ------------------------------   Date: 2 Jul 2000 21:12:59 GMT * From: helbig@astro.rug.nl (Phillip Helbig)' Subject: Re: DCL vs. "real" programming . Message-ID: <8job8r$j8u$1@info.service.rug.nl>  [ In article <slv0sikkop316@corp.supernews.com>, "Mark E. Levy" <levy@sysman-inc.com> writes:   8 >"Phillip Helbig" <helbig@astro.rug.nl> wrote in message) >news:8jns9o$eo4$2@info.service.rug.nl... I >> For example, when writing an application which processes a lot of MAIL D >> files, would one achieve much better performance by writing it inD >> Fortran or whatever and using the callable MAIL interface than by! >> writing .COM files etc in DCL?  > K >If it's a one-time shot, use DCL. If you plan to run this procedure often, J >use an HLL like Fortran. The difference in run time (and CPU utilization)G >can be dramatic. I had a procedure that scanned text files for certain L >strings. It ran over 24 hours. Rewritten in Basic, it ran in under an hour. >-- F >--------------------------------------------------------------------- >Mark E. Levy, President# >System Management Associates, Inc. " >888-291-5055 x202 (Illinois Only)% >847-291-1550 x202 (Outside Illinois)  >847-291-3866 fax  >www.sysman-inc.com  >levy@sysman-inc.comF >--------------------------------------------------------------------- >  >     G It's not a one-shot (for which I would certainly use DCL), so it looks  G like it's F$ time.  This reminds me, someone once mentioned here a DCL  G compiler which would take a .COM file and convert it to the equivalent  E FORTRAN with system calls etc and compile that.  Who can point me to   this?   F Not to be confused with another DCL ""compiler" which did things like E upcase everything, get rid of spaces etcso that the .COM files would  F parse faster (I guess this would be relatively easy to write oneself.)   ------------------------------  % Date: Sun, 02 Jul 2000 20:03:06 -0500 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> ' Subject: Re: DCL vs. "real" programming - Message-ID: <395FE64A.F55F1124@earthlink.net>    Phillip Helbig wrote:  > ] > In article <slv0sikkop316@corp.supernews.com>, "Mark E. Levy" <levy@sysman-inc.com> writes:  > : > >"Phillip Helbig" <helbig@astro.rug.nl> wrote in message+ > >news:8jns9o$eo4$2@info.service.rug.nl... K > >> For example, when writing an application which processes a lot of MAIL F > >> files, would one achieve much better performance by writing it inF > >> Fortran or whatever and using the callable MAIL interface than by# > >> writing .COM files etc in DCL?  > > M > >If it's a one-time shot, use DCL. If you plan to run this procedure often, L > >use an HLL like Fortran. The difference in run time (and CPU utilization)I > >can be dramatic. I had a procedure that scanned text files for certain N > >strings. It ran over 24 hours. Rewritten in Basic, it ran in under an hour. > >-- H > >--------------------------------------------------------------------- > >Mark E. Levy, President% > >System Management Associates, Inc. $ > >888-291-5055 x202 (Illinois Only)' > >847-291-1550 x202 (Outside Illinois)  > >847-291-3866 fax  > >www.sysman-inc.com  > >levy@sysman-inc.comH > >--------------------------------------------------------------------- > >  > >  > H > It's not a one-shot (for which I would certainly use DCL), so it looksH > like it's F$ time.  This reminds me, someone once mentioned here a DCLH > compiler which would take a .COM file and convert it to the equivalentF > FORTRAN with system calls etc and compile that.  Who can point me to > this?   G Yeah - that was the problem: it produced FORTRAN source code (rather an A expensive 3GL) instead of MACRO32 (which comes with every OpenVMS H system, even OpenVMS Alpha). Consequently, it never caught on as well as it could have.   G > Not to be confused with another DCL ""compiler" which did things like F > upcase everything, get rid of spaces etcso that the .COM files wouldH > parse faster (I guess this would be relatively easy to write oneself.)  F You're talking about "DCL diet", right? That removes comments, surplusH spaces, etc. It makes DCL more efficient, but does nothing for the logic of the proc. itself.   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Sun, 02 Jul 2000 10:45:58 -0500 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> + Subject: Re: DECnet-Plus or DECnet Phase IV - Message-ID: <395F63B6.608093B4@earthlink.net>    Timothy Stark wrote: >  > Hello Folks: > D > About OpenVMS v7.2 installation, I have a question for you.  I sawH > different two DECnet products.  What is difference between DECnet-Plus > and DECnet Phase IV products?   E DECnet-IV (aka phase-IV) is the older product. It is stable, reliable C and very "set it and forget it". It has many limitations aside from H being proprietary. Six(6) character node names tend to be a bit cryptic,B also. On the other hand, it is relatively "quiet" (few or no OPCOMF messages when the network is operating normally) and can tolerate someD rather adverse network conditions with few or no complaints. You can> zero line and circuit counters on a regular basis as an aid in% monitoring the health of the network.   F DECnet-V (pka DECnet-OSI, aka phase-V) is the newer product. It can beG problematic in environments where Phase-IV networks previously operated D trouble-free. It usually needs more "care and feeding" than phase-IVE also. Tasks that were simple in phase-IV can take as long as a day or H more to set up and troubleshoot in phase-V. Phase-IV's management agent,E NCP, uses commands that are concise, even terse. Phase-V's management C agent, NCL,  uses commands that even the on-line help can't explain G since phase-V "objects" typically don't exist until they are created by D another NCL command. DECnet-V puts out many more OPCOM messages thanD phase-IV, most of them unnecessary or meaningful only to the phase-VF developers. DECnet-V complains a lot more (via OPCOM) about conditionsF that phase-IV handled quietly. The volume of messages generated is notH easily controllable and in many cases cannot be controlled at all unlessC ALL messages are simply turned off. Entity counters on DECnet-V are H created when the object is created, and increment normally due to eventsG occuring during operation; however, DECnet-V does not allow for zeroing D of counters. This can make monitoring the health of the network more2 manual effort intensive than it is under phase-IV.  F Features such MOP "line service" and "remote console" are not providedE by DECnet-V, and must be facilitated by extension (external) programs H which simply exploit the existing DECnet stack. These are supplied along? with DECnet-V (LANCP, "SET HOST/MOP"); so no additional cost is 	 incurred.   G On the other hand, DECnet-V (aka phase-V DECent) does facilitate DECnet D over IP when used with a suitable IP stack. So this does work in its) favor where this functionality is needed.   C Most long-time sysadmin's don't want to be bothered with DECnet-V's D verbosity, resource requirements or management-intensiveness. If youE don't need the advanced features, better off to stay with the proven,  reliable, quiet DECnet-IV.  H Remember also that since "the rest of the world" generally talks TCP/IP,? you can survive without DECnet (IV or V) in a great many cases. G Something else to consider when setting up an OpenVMS system where none E previously existed. Even an OpenVMS cluster can exist without DECnet.    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/    ------------------------------  $ Date: Sun, 2 Jul 2000 12:58:55 -0500* From: "Mark E. Levy" <levy@sysman-inc.com>+ Subject: Re: DECnet-Plus or DECnet Phase IV . Message-ID: <slv0mfi3op321@corp.supernews.com>  4 "John E. Malmberg" <wb8tyw@qsl.net> wrote in message1 news:0d1001bfe3e2$dee35e20$020a0a0a@xile.realm... I > One of the new features is the ability to tunnel DECnet traffic through K > TCP/IP networks so theorectically hobbyist's with full time connection to D > the Internet could set up somewhat trusted tranparent connections.  L Both Multinet and TCPware come with DNIP (DecNet over IP) which allow one toK do this also.  Both products are avilalable from Process under the hobbyist  license progam.    > -John  > wb8tyw@qsl.network  	 73, N9RXF    --E ---------------------------------------------------------------------  Mark E. Levy, President " System Management Associates, Inc.! 888-291-5055 x202 (Illinois Only) $ 847-291-1550 x202 (Outside Illinois) 847-291-3866 fax www.sysman-inc.com levy@sysman-inc.com E ---------------------------------------------------------------------    ------------------------------  $ Date: Sun, 2 Jul 2000 20:37:46 -0500) From: "John E. Malmberg" <wb8tyw@qsl.net> + Subject: Re: DECnet-Plus or DECnet Phase IV . Message-ID: <slvr7jnoop319@corp.supernews.com>  - Mark E. Levy <levy@sysman-inc.company> wrote: K > Both Multinet and TCPware come with DNIP (DecNet over IP) which allow one  toD > do this also.  Both products are avilalable from Process under the hobbyist > license progam.   I Can the Decnet over IP from Multinet and TCPware interoperate with DECnet , over IP using DECNET OSI and Digital TCP/IP?  F IIRC: Digital/Compaq was making some of that information available for> programmers, but not sure where it is, because I never looked.   -John    ------------------------------   Date: 2 Jul 2000 23:46:13 -0400 4 From: "Robert Deininger" <rdeininger@mindspring.com>+ Subject: Re: DECnet-Plus or DECnet Phase IV * Message-ID: <B58584C8-1975C@165.247.43.34>  E On Sun, Jul 2, 2000 9:37 PM, John E. Malmberg <wb8tyw@qsl.net> wrote:  >J. >Mark E. Levy <levy@sysman-inc.company> wrote:H >> Both Multinet and TCPware come with DNIP (DecNet over IP) which allow oneP >toyE >> do this also.  Both products are avilalable from Process under thep	 >hobbyist  >> license progam. >rJ >Can the Decnet over IP from Multinet and TCPware interoperate with DECnet- >over IP using DECNET OSI and Digital TCP/IP?P  F They are two different critters.  I don't know anything about TCPware.G Multinet comes with a protocol that can talk DECnet to another multineto4 machine over tcpip.  It can't talk to a UCX machine.  G DECnet plus supports Decnet over tcpip between any machines with DecnetR plus  D and a tcpip product that supports the pathworks interchange protocol (PWIP).nG Both UCX (TCPIP) and multinet support PWIP; I don't know about TCPware.i  G So yes, multinet and ucx can interoperate, using decnet plus with PWIP.rI I believe the original multinet decnet over tcpip scheme is NOT active in  this situation.i       ---------------------------S Robert Deininger rdeininger@mindspring.com-   ------------------------------  # Date: Sun, 02 Jul 2000 23:42:04 GMT65 From: "headley sappleton" <hsappleton@sprintmail.com>.8 Subject: FA: Digital DEC Mouse Model VSXXX-AA NO RESERVEE Message-ID: <grQ75.28841$_b3.701535@newsread1.prod.itd.earthlink.net>i  @ http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=372805407H Auction Ends on:                 Wednesday, Jul 12, 2000 at 15:45:05 PDT   ------------------------------  # Date: Mon, 03 Jul 2000 00:13:36 GMT 5 From: "headley sappleton" <hsappleton@sprintmail.com>d> Subject: FA: Reflection 4 PC to Digital/UNIX Host connectivityE Message-ID: <QUQ75.28892$_b3.703140@newsread1.prod.itd.earthlink.net>a  @ http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=372814657H Auction Ends on:                 Wednesday, Jul 12, 2000 at 15:56:47 PDT   ------------------------------  # Date: Sun, 02 Jul 2000 23:50:54 GMTe5 From: "headley sappleton" <hsappleton@sprintmail.com> C Subject: FA: Reflection 4+ For DOS  PC to VAX connection NO RESERVE E Message-ID: <yzQ75.28856$_b3.702530@newsread1.prod.itd.earthlink.net>e  @ http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=372809036H Auction Ends on:                 Wednesday, Jul 12, 2000 at 15:49:15 PDT   ------------------------------  # Date: Mon, 03 Jul 2000 00:03:12 GMT,5 From: "headley sappleton" <hsappleton@sprintmail.com> C Subject: FA: Reflection 4+ For DOS  PC to VAX connection NO RESERVEsE Message-ID: <4LQ75.28873$_b3.703398@newsread1.prod.itd.earthlink.net>r  @ http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=372809036H Auction Ends on:                 Wednesday, Jul 12, 2000 at 15:49:15 PDT   ------------------------------  % Date: Mon, 03 Jul 2000 02:12:42 +0001d' From: Jane <jane_bygraves@mailroom.com>s Subject: Funny Singing Fishn- Message-ID: <0FX30072LKN7SE@mx.west.saic.com><  V Remember we spoke about that funny singing fish Billy Bass? well I found the web site X www.absolutebigmouthbillybass.com and know you said that you wanted to buy one and they 7 say that theyare in stock.  Let me know if you get one.   : Call me next week and we'll go to the new Jim Carey movie.   Love Jane   ------------------------------  " Date: Sunday, 2 JUL 2000 22:46 EDT- From: Bryan Jensen <bjj+3@arlvax.arl.psu.edu>r/ Subject: Re: good news (for me,  I think) . . . , Message-ID: <8jovra$1aks@r02n01.cac.psu.edu>  2 In article <ye9cOYAug+5Uw+sj+3gHcIKNUEjU@4ax.com>,:    "Larry D Bohan, Jr" <LBohan@dbc.spam_less..com> writes:F >On Fri, 30 Jun 2000 12:15:10 -0400, "Bill Todd" <billtodd@foo.mv.com> >wrote:a >tM >>Or one could take the viewpoint that in the Unix world, it's common to take K >>advantage of the file system for use as a catalogue/library (in ways thaty >>VMS doesn't support as well).  >lD >true., but it was my impression  this approach was typical in unix,> >because there's no common unix api for text libraries, afaik. >i? >saving on file file open/closes, and the ability to do lookupso? >via multiple keys (if needed)  would be a win on unix as well.   H UNIX would do well to take the "everything is a file" approach but they  are blowing it.  For instance:  D 1)  ioctl is a kludge.  UNIX could have used control files where you,     write ASCII commands to control devices.  F     Likewise for network sockets.  No new calls should have been added      to implement a TCP/IP stack.  G 2)  You have nightmarish creations like tar and zip.  How come archivesiJ     aren't implemented as filesystems?  Then users wouldn't have to learn L     an entirely different command syntax to access files in an archive file.I     By this, I don't mean that a tar file would have a different internaloG     structure from what was used, just that there would be code to make-.     this structure accessible as a filesystem.  F This type thing actually would be a real win for UNIX except they are C so enamored with the 1970's that initiative is nearly non-existant.    ------------------------------  % Date: Sun, 02 Jul 2000 10:51:36 -0400,+ From: Tim Shoppa <shoppa@trailing-edge.com> 2 Subject: Re: highwater marking, speed vs. security1 Message-ID: <395F1EB8.40094B98@trailing-edge.com>e   David Mathog wrote:- > L > R. Gilbert started me looking closely at high water marking.  If a disk is+ > mounted that way and a file created with:" >  >  $ create/fdle > M > it takes a very long time to complete.  On my system, about 6 seconds for anB > 40000 block file.  During that time the file is apparently being# > overwritten with "0000000" bytes.n  @ That's about 3 Mbytes per second, which may or may not be "fast"A depending on what your standards are.  Go back to doing highwaterhB marking on a 11/750 with Massbus disks attached and I'm sure it'll be orders of magnitude slower.  E > Dismount the disk and remount it /nohighwater, then the same createT1 > operation completes "quickly" (under a second.)a > K > The purpose of /highwater is to prevent unpriv'd users from being able to D > pick up data off the disk.  But is writing the pattern on the diskH > really any more secure than attaching a variable "lastbyte" to it, andH > simply returning nulled out data (or an error, as appropriate) for any? > operation which tries to read past that position in the file?9  ? It depends on what your ratio of file creates to file reads is.-@ If you create a file just as often (or more often) than you read9 it, then you're right, your method may be more efficient.   G But if you create files rarely, and read/write to them much more often,g? then it's more efficient to do all the "security overhead" oncetA and once only, rather than do a check on every read and write.  In> suspect that this is the far more common model of file access.   >  The positionwK > of this end of data is already marked in the file, and can be viewed withcE > ANAL/RMS, so the concept is there, even if the method of preservingbM > highwater is not. The overhead required to check such a value would seem tolL > be relatively small.  RMS could handle this for most things, but somethingK > special might be needed for files which were memory mapped or accessed in  > other nonRMS ways.  ? Remember, if you have read access to a file, there's nothing to @ force you to access it via RMS.  If I remember correctly, if youC can read a file via RMS, you can read raw blocks from the file with-> QIO's.  (There are at least some exceptions - for example, you; can mark a file as append/write-only, then I think that RMSI must come in.)  ? Personally, I'd rather not have additional checking done at the8E QIO level if it can be avoided.  I think the "erase at creation time"-$ is the best choice for most systems.   Tim.   ------------------------------   Date: 2 Jul 2000 11:26:29 -0400r4 From: "Robert Deininger" <rdeininger@mindspring.com>2 Subject: Re: highwater marking, speed vs. security+ Message-ID: <B584D767-636D4@165.247.43.115>v  I On Sat, Jul 1, 2000 6:24 PM, David Mathog <mathog@seqaxp.bio.caltech.edu>W wrote:  D >Dismount the disk and remount it /nohighwater, then the same create1 >operation completes "quickly" (under a second.) o  I You don't need to dismount/remount.  Set volume/nohighwater is available.   K >The purpose of /highwater is to prevent unpriv'd users from being able to >C >pick up data off the disk.  But is writing the pattern on the disk G >really any more secure than attaching a variable "lastbyte" to it, and G >simply returning nulled out data (or an error, as appropriate) for anya> >operation which tries to read past that position in the file?  H I always understood that highwater marking DOES try to avoid writing theD zeros when files are extended, if possible. In particular, I thought- that sequential writes were handled this way.t  E But recently I caught highwater marking causing a big performance hit J on our oldest microvax (with slow disks that can't afford the extra pain).I The files in question were sequential with fixed-length records, and wereiK created from Fortran using direct access mode (i.e. by record number). EveneG though the file was written almost totally in sequential order, RMS was-> definitely doing something to every block on each file extend.    & From the VMS Guide to System Security:  , 8.9.5.2 Prevention Through Highwater Marking  H Highwater marking refers to a technique that tracks the furthest extent K to which each file has been written and prohibits user attempts at reading d data beyond that point.   J The operating system implements true highwater marking for all sequential,I exclusively accessed files, such as the set of files output from various -K text editors, compilers, and linkers, that is, most files a process writes.n  F The highwater mark is updated in the file header whenever the logical ? end-of-file mark is updated (usually when the file is closed). d  I For shared files (both indexed and sequential), the operating system usese themB principle of erase-on-allocate to achieve a result similar to true	 highwater7C marking. When a file is about to be created or extended, the system0
 determinesH how much disk space (the extent of the file) is required and applies theI security erasure pattern of zeros to the areas (extents) it allocates for_J writing.  The file is then written into the area just erased for it. Thus,D if any user gains access to the file (including its full extent) and attemptsG to read the area beyond where the file has been written, only the data  $ security erase pattern is readable.    (end of quote from the manual)  G I'm not sure which part of this I ran up against.  I suspect the direct F access mode triggers erase-on-allocate for sequential files, even when they aren't shared.i  F >By the way, can somebody explain exactly what happens when a file is K >extended (20 blocks) on a small write (100 bytes) on a disk with highwater-H >marking enabled?  Does the system first write the 100 bytes of data andE >then blank out the remaining new disk area, or does it blank out the7 entireK >new extended region and then overwite part of that with the 100 bytes?  IfaK >the latter, it seems incredibly wasteful if extend is just slightly largeruD >than the size of a large write, for instance where one writes 32256% >bytes for an extend of 32768 bytes! m  G I think the last paragraph I quoted from the manual answers this -- and-G not the way you would wish!  We would have to check the source listingsaA to see if the manual accurately reflects what's done by the code.e  I Doing it the "efficient" way you suggest would complicate the code, sinceeC extend and write are separate operations in RMS.  Making the extendh	 zero-fill_H "just enough" of the new space would require it to know about the write,E or would require the write to know how to do an extend.  The couplingiH of these routines would be nasty. (How many different kinds of write are there?)   K There IS a security hole with highwater marking disabled.  A file protected J against read access loses that protection after it is deleted or moved, ifK the bytes are still on the disk.  Then it is possible to scavenge them, buteI it may be difficult to arrange to allocate the particular blocks you needo to	 scavenge.   J I guess highwater marking is partly intended to remove the need for erase-G on-delete, since it makes it "safe" to leave your bytes behind when youNE delete (or move) a file.  To the extent that files are mostly written K sequentially without sharing, highwater marking will cause less performancevG loss that would universal erase-on-delete.  Even in the worst case, HWMh wouldoG cost no more than erase-on-delete.  Turning both mechanisms on seems toy* be a big waste with almost nothing gained.   ---------------------------n Robert Deininger rdeininger@mindspring.com    ------------------------------   Date: 2 Jul 2000 11:33:35 -0400r4 From: "Robert Deininger" <rdeininger@mindspring.com>2 Subject: Re: highwater marking, speed vs. security+ Message-ID: <B584D911-69AEC@165.247.43.115>l  I On Sat, Jul 1, 2000 6:24 PM, David Mathog <mathog@seqaxp.bio.caltech.edu>  wrote:> >R. Gilbert started me looking closely at high water marking.   G A short addendum to my previous reply.  MONITOR FCP will show the eraselH rate, which can tell you how much extra I/O is being caused by highwaterB marking.  (As discussed in OpenVMS Performance Management, section
 12.1.2.3.)   ---------------------------l Robert Deininger rdeininger@mindspring.comn   ------------------------------  # Date: Sun, 02 Jul 2000 21:19:26 GMTk$ From: Ed Wilts <ewilts@mediaone.net>2 Subject: Re: highwater marking, speed vs. security, Message-ID: <395FB1DF.99FBF673@mediaone.net>   David Mathog wrote:" > L > R. Gilbert started me looking closely at high water marking.  If a disk is+ > mounted that way and a file created with:  >  >  $ create/fdle > M > it takes a very long time to complete.  On my system, about 6 seconds for afB > 40000 block file.  During that time the file is apparently being# > overwritten with "0000000" bytes.   H You should really post your FDL.  I would suspect that a sequential fileE create would be fairly quick, yet an indexed file would not be.  WhensE you think about how the file will be accessed, you'll quickly see theaF difference.  With a sequential file, it's easy to flag the end-of-fileE and return nulls when a user reads past it.  However, with an indexed H file, your access will be random, so you really have no choice except toF zero the entire file unless you think a setting on every record is the right thing to do.  K > The purpose of /highwater is to prevent unpriv'd users from being able toyD > pick up data off the disk.  But is writing the pattern on the diskH > really any more secure than attaching a variable "lastbyte" to it, andH > simply returning nulled out data (or an error, as appropriate) for anyM > operation which tries to read past that position in the file?  The position K > of this end of data is already marked in the file, and can be viewed withoE > ANAL/RMS, so the concept is there, even if the method of preservings > highwater is not.   F Again, this makes sense for sequential files, but not for fixed-length or index files.o   Cheers,g 	.../Edm   > David Mathog   -- e Ed Wilts Mounds View, MN, USA mailto:ewilts@mediaone.net   ------------------------------  $ Date: Sun, 2 Jul 2000 21:58:25 -0400' From: "Bill Todd" <billtodd@foo.mv.com>a2 Subject: Re: highwater marking, speed vs. security( Message-ID: <8jortv$sjc$1@pyrite.mv.net>  = David Mathog <mathog@seqaxp.bio.caltech.edu> wrote in message & news:8jlr32$mdh@gap.cco.caltech.edu...   ...n  K > The purpose of /highwater is to prevent unpriv'd users from being able todD > pick up data off the disk.  But is writing the pattern on the diskH > really any more secure than attaching a variable "lastbyte" to it, andH > simply returning nulled out data (or an error, as appropriate) for any? > operation which tries to read past that position in the file?R  D No, it isn't any more secure - unless you write the pattern when youK *release* space from a sensitive file, which guards against the possibilityoE that at some *future* time the physical disk will be accessed by somerJ mechanism that bypasses ODS-x's security.  Of course, that's assuming thatI you *do* ensure that no unwritten 'hole' can be left in the file prior tobK the last byte written (otherwise, you'd have to keep a full map of what hadeH been written and what hadn't - though that's not all that different from) what one does to support 'sparse' files).e     The positionK > of this end of data is already marked in the file, and can be viewed with E > ANAL/RMS, so the concept is there, even if the method of preservingyJ > highwater is not. The overhead required to check such a value would seem to > be relatively small.  L Well, it could be very small indeed - a few instructions at most - but thereK may be issues in the current implementation that tend to increase the cost;a
 see below.  6   RMS could handle this for most things, but somethingK > special might be needed for files which were memory mapped or accessed ins > other nonRMS ways.  J Exactly (part of the comment above):  the protection must be enforced at aK level below the lowest level through which an application can access a filerL (QIO, IIRC) - and since that level may not know whether it was called by theI application directly or via RMS (indeed, it may not be *able* to know), a-  check in RMS would be redundant.  I That RMS is a separate system layer that communicates through a lower buteL application-level interface with the file management mechanisms is somethingJ of a historical accident.  RMS originated in the PDP-11 environment, whereJ adding just the *code* required to support RMS to the base systems was notL practical:  RMS at first was simply linked into each application that wishedL to use it, and while it later became available in sharable resident run-timeI libraries it remained an optional, albeit bundled, portion of the system.q  J VMS inherited this structure, in part because VMS also was originally veryJ sensitive to available physical memory:  not only did keeping RMS separateK make it easier to avoid any memory RMS code overhead if it wasn't used, butML maintaining RMS's buffers in application (P1, I think) space made for a moreJ efficient swapping environment than a central cache would have (one of theG reasons I've never criticized the lack of a central VMS cache 'way backCK when:  it made sense at the time).  The fact that RMS presents an extremelyeK complex application interface compared with the QIO interface may also havesI influenced the decision not to funnel all access through RMS (and while IlK believe that *could* have been done without adding greatly to the code pathpA of QIO-style access, it would have likely added noticeably to theeK integration effort required for VMS V1.0 - not a very desirable thing to do-
 at the time).,  E The consequence of this split, however, is that it requires importantrH in-file protection mechanisms, such as those required to protect againstI disk-scavenging, to reside below the RMS layer - while the RMS layer must:L still perform some otherwise atypical operations within a file that could beK done more efficiently if those checks were performed at a level *above* the J RMS operation.  An example is the use of 'areas' in an indexed file:  it'sL desirable to be able to pre-allocate space in such areas for future use, butK there's no guarantee that this pre-allocated space will be used in anything K like increasing-virtual-address order within the file.  Hence there will beCF unwritten 'holes' left in the file which must be pattern-filled by theL system to protect against scavenging:  the application couldn't get at thoseL holes using RMS record management mechanisms, but there's nothing to preventF it opening the file with QIOs (or even RMS block I/O) and reading them# (after all, that's how Copy works).n  J A simpler example, of course, is that of a file populated randomly.  WhileK it often makes sense to initialize such a file (e.g., filling it with nullspG to indicate that unpopulated entries are in fact empty), it's certainlyhL possible to accomplish the same thing using a separate bit-map - and in suchK a case, unpopulated entries would be easy to use for scavenging if the filet! system did nothing to prevent it.c  I One could observe that a file-mapping mechanism that recognized unwritten D 'holes' would solve such layering  and random-write problems withoutK requiring pattern-filling, but ODS-x wasn't designed that way (and changingnL the map layout later, while perhaps feasible, would not have been trivial, IK suspect; mapping holes also adds to map overhead, but I think it's possiblemG to do in such a way that it only adds overhead if in fact holes exist).n  G So file system method of scavenging-protection is two-ply:  it uses thedC 'high water mark' to indicate the highest byte written, and returnswK something other than the disk contents for reads past that point (since therH 'end of file' mark is purely an application-level mechanism with no realH enforceability), and ensures that any unwritten bytes preceding the highG water mark are pattern-filled.  (Plus the more paranoid mechanisms that)J pattern-fill on allocation and/or deallocation.)  So far, that's just what1 one would expect (and in fact what you expected).   E The behavior I don't quite understand is that which, when the file isaJ (write-?)shared *or* randomly-accessible (or was it randomly-*writable*?),D automatically pattern-fills on allocation when high-water marking isG enabled.  Especially in the (non-write-shared) random-writing case, I'd'K expect the high-water mark to be used for protection whenever possible, and'I only if a new write operation left a hole to see the pattern applied (andeF this is something the low-level file-system code could handle, withoutI involving RMS):  it's not clear that there's any performance advantage to L pattern-filling the entire new allocation at one time, since pattern-fillingH only when a hole was left would still always occur in conjunction with aJ write operation that was necessary anyway (i.e., the total number of writeL operations would actually decrease by one compared with an initial full-fillD operation, and the total number of bytes written could be as much as7 halved - in the case where no holes actually occurred).-  K The write-sharing case may be more easily explained:  if multiple accessors3E try to write beyond the high-water mark at the same time to otherwisemD unconflicting byte ranges, then fill-on-write could cause one's fillF operation to race with the other's write operation (you could probablyL handle this with a special exclusive 'filling' file-level lock, but it wouldA have to be acquired - in shared mode - on every non-filling writeoI operation), whereas fill-on-extend preceding the write would interlock on I the file extension operation before either write occurred.  Once again, a H different implementation in which the low-level file-system code handledI extensions (and extension defaults) in an on-demand manner similar to thekF Unix automatic-extend-on-write approach could avoid such problems, but0 that's not the way the VMS architecture evolved.  I It's entirely possible that such things occurred to Andy back when he was-J designing ODS-2, but both the desire to maintain upward compatibility withC ODS-1 and the need to get it out and running may have kept him fromJH exploring them:  it would have been a major semantic change from the RSXH (and RSTS) platforms with which VMS was maintaining at least a degree of8 cultural compatibility (and more, in the case of RSX andK 'compatibility-mode' operation) - and I'm not even sure that VMS V1.0 *had* G ODS-2 on board, which would have made simple VMS upward-compatibility amF concern.  But for whatever reason, the result is a bit hobbling today.  J In any event, much of the above is somewhat speculative, so should someoneB have a more knowledgeable explanation to offer, I'll be listening.  5    In terms of security, if the data was left on disk F > (no delete/erase) then it is pretty insecure anyway - somebody couldL > physically access the system and steal the disk (especially in Los Alamos,H > sigh) in which case they can certainly read every byte on its surface.L > Barring physical access, is the "write over it with null bytes" really any@ > more secure than "do not allow access past last written byte"? >gF > By the way, can somebody explain exactly what happens when a file isL > extended (20 blocks) on a small write (100 bytes) on a disk with highwaterI > marking enabled?  Does the system first write the 100 bytes of data anddF > then blank out the remaining new disk area, or does it blank out the entireL > new extended region and then overwite part of that with the 100 bytes?  IfL > the latter, it seems incredibly wasteful if extend is just slightly largerE > than the size of a large write, for instance where one writes 32256 % > bytes for an extend of 32768 bytes!n  H Think I covered that above, if my guess that the pattern-fill was taking? advantage of the file-level extension interlocking was correct.e  J There are ways in which slightly different DLM semantics might also help aL lot of this be a bit better-performing.  Once again, not something one couldK expect to have been foreseen in 1975, but isn't it about time to use what'sl been learned in the interim?   - bill   >i
 > Regards, >c > David Mathog > mathog@seqaxp.bio.caltech.edur@ > Manager, sequence analysis facility, biology division, CaltechL > **************************************************************************L > *                                RIP VMS                                 *L > **************************************************************************   ------------------------------   Date: 2 Jul 2000 16:55:56 GMTd* From: helbig@astro.rug.nl (Phillip Helbig) Subject: ISDN on ALPHAstationp. Message-ID: <8jns6s$eo4$1@info.service.rug.nl>  ; What can one do with the ISDN socket on some ALPHAstations?d   ------------------------------  $ Date: Sun, 2 Jul 2000 13:02:11 -0500* From: "Mark E. Levy" <levy@sysman-inc.com>! Subject: Re: ISDN on ALPHAstation . Message-ID: <slv0mgn1op324@corp.supernews.com>  7 "Phillip Helbig" <helbig@astro.rug.nl> wrote in message ( news:8jns6s$eo4$1@info.service.rug.nl...= > What can one do with the ISDN socket on some ALPHAstations?s  K If you're running OpenVMS, nothing. DEC (yes, it was still DEC at the time)j' never provided drivers for this device.n   --E ---------------------------------------------------------------------r Mark E. Levy, Presidenth" System Management Associates, Inc.! 888-291-5055 x202 (Illinois Only) $ 847-291-1550 x202 (Outside Illinois) 847-291-3866 fax www.sysman-inc.com levy@sysman-inc.comtE ---------------------------------------------------------------------,   ------------------------------  # Date: Sun, 02 Jul 2000 19:02:39 GMTc( From: Jay Olson <jjo@triton.com.no.spam>! Subject: Re: ISDN on ALPHAstation 2 Message-ID: <395F904D.E5762D19@triton.com.no.spam>   Phillip Helbig wrote:i > . > What can one do with the ISDN socket on some > ALPHAstations?  G They are (or at least were) supported by the Digital Unix X.25 product,i8 but only if your ISDN switch supports 5ESS or Euro-ISDN.  ( 	- Jay Olson (jjo "at" triton "dot" com) 	Triton Software Group LLC   ------------------------------   Date: 2 Jul 2000 23:50:36 -0400r4 From: "Robert Deininger" <rdeininger@mindspring.com>! Subject: Re: ISDN on ALPHAstationr* Message-ID: <B58585D0-1D549@165.247.43.34>  I On Sun, Jul 2, 2000 12:55 PM, Phillip Helbig <helbig@astro.rug.nl> wrote:   < >What can one do with the ISDN socket on some ALPHAstations?  D I think you can hide an M&M in there, for when you get really hungry1 and don't have any money for the vending machine.o  / (Melts in your mouth, not in your ISDN socket.)e     ---------------------------w Robert Deininger rdeininger@mindspring.comx   ------------------------------   End of INFO-VAX 2000.368 ************************