1 INFO-VAX	Tue, 13 Jun 2000	Volume 2000 : Issue 328       Contents:P All Users are the same - Right? (was Re: Canadian Association of Compaq Users SyP All Users Groups are the same - right? (Was Re: Canadian Association of Compaq U Re: Autogen  Autogen  Re: Autogen > Re: Canadian Association of Compaq Users Symposium rescheduled> Re: Canadian Association of Compaq Users Symposium rescheduled" Re: CMQ/Dec with a sense of Humor?" Re: CMQ/Dec with a sense of Humor?" Re: CMQ/Dec with a sense of Humor?" Re: CMQ/Dec with a sense of Humor?" Re: CMQ/Dec with a sense of Humor?" Re: CMQ/Dec with a sense of Humor? DCPS 1.7 and HP 6MP * Re: Files-11 ODS-2 Readability for FreeBSD* Re: Files-11 ODS-2 Readability for FreeBSD* Re: Files-11 ODS-2 Readability for FreeBSD* Re: Files-11 ODS-2 Readability for FreeBSD FS: toasted AlphaStation 600 Info on VAXstation 400-VLC Re: Internet VMSCluster  Re: MMOV 2.2 and VMS 7.1 Re: MMOV 2.2 and VMS 7.1, MRTG (Multi Router Traffic Grapher) for VMS? novityA Re: OpenVMS commentaries (was Re: Gartner commentary on Wildfire) 0 Re: Qt2.1.0 GUI library now available on OpenVMS0 Re: Qt2.1.0 GUI library now available on OpenVMS/ Re: Question on using ASTs for output (Summary) 9 Re: ramdisk vs. file cache, and the winner is, file cache 9 Re: ramdisk vs. file cache, and the winner is, file cache  Re: Recording CD's on VMS  Re: Recording CD's on VMS  Re: stand alone backup, Re: Submit /After delta time format question/ Re: Tru64 Unix Clustering with OpenVMS Clusters / Re: Tru64 Unix Clustering with OpenVMS Clusters / Re: Tru64 Unix Clustering with OpenVMS Clusters % Re: UCX problems after network glitch  Re: VAX on Intel?  Re: VAX on Intel?  Re: VMS Security features  Re: VMS Security features  Re: VMS Security features  Re: VMS Security features   F ----------------------------------------------------------------------  % Date: Mon, 12 Jun 2000 21:59:47 -0400 & From: "Jeff Killeen" <Jeff@Killeen.cc>Y Subject: All Users are the same - Right? (was Re: Canadian Association of Compaq Users Sy % Message-ID: <39459414@news.toast.net>   ? Having spent some time around our ITUG friends FWIW IMO careful L consideration should be given to just how natural a fit there is between theJ DECUS and ITUG communities.  Digital Style Computing comes from a heritageD of distributed loosely coupled network computers.  While key DigitalF heritage technologies have evolved into mission critical big boxes theF technology is still department/workgroup deployment friendly.  This isE especially true when you factor in Windows 2000.  The Tandem style of J computing appears to me based upon more the classic mainframe "big box" inI the center style of computing with a radial view of the world rather than 2 the distributed networked boxes view of the world.  L Tandem technology appears to be an integrated form of technology with a veryI tight coupling between the OS, the database, and the storage sub-systems. I For example SAN technology appears to be at odds with the Tandem concept. K Also with the DB being part of the OS an issue like Oracle versus Sybase is ' a non-issue because there is no option.   L Middleware in the Tandem world appears to be making the other things look toL applications like standard Tandem APIs'.  Middleware in the Digital world is! conforming to industry standards.   K Tandem folks seem to be highly focused on that unique range of applications L that truly require 99.99999 non-stop availability and are willing to pay theH price for it.  Digital platforms are very general purpose platforms i.e. jack-of-all-trades.   J In the end it will be interesting to see how much synergy there is betweenH the DECUS folks who tend to be in-depth technologist focused on buildingH generic IT enterprise class infrastructure and ITUG folks who tend to beK focused on building very specialized centralized non-stop environments.  It J also appears to me the ITUG folks build a lot more of their infrastructure right in the big box.   H I suspect the ITUG folks may feel more are home in a IBM user group thanK DECUS.  I also suspect the DECUS folks would feel more at home with UNIX or B W2K user groups than ITUG.  While both are users of Compaq brandedL technology the application fundamentals they deal with on a day to day basisJ are different.  Last weekend, when meeting with ITUG folks, I was remindedE again as to what the concept of 5 9's (99.99999)  really means.  Your K multi-million dollar computer infrastructure is NOT non-stop if when you go L to execute a stock trade the laser printer that produces the market order isI out of paper.  The 1-2 minutes it can take to refill the paper tray could G mean millions of dollars.  There really is difference in how one thinks K about an application that is 99.99 versus 99.99999 non-stop - and the price < you are willing to pay to build a 99.99999 infrastructure...       --     Jeff Killeen - www.Killeen.cc E ===================================================================== F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message% news:O$z87hKWOhc4@eisner.decus.org... ? > In article <skaevqj9h5167@corp.supernews.com>, "Peter Weaver"   <peter.weaver@stelco.ca> writes:G > > Larry Kilgallen wrote in message <6iJNoVN1Cj$2@eisner.decus.org>...   J > > "Canadian Tandem Users Group" but I went back to read Joseph's note toC > > make sure I had the name correct. In his note he said "I am the B > > current President for the Canadian Tandem Users Group, and theF > > Director of Finance for the Canadian Association of Compaq Users."G > > Does that mean that Tandem still has an user group? I was under the H > > impression that both DECUS and CTUG had both been killed to form the > > new CACU???? > B > Not specific to Canada, but my impression is that DECUS and ITUGA > have sufficiently different cultures and needs that there is no B > simple way to just make them one.  ITUG, for instance, has theirA > yearly symposium in San Jose, and I presume that is to maximize $ > participation by Tandem engineers.   ------------------------------  % Date: Mon, 12 Jun 2000 21:57:04 -0400 7 From: "Information CETS2000" <Information@CETS2000.com> Y Subject: All Users Groups are the same - right? (Was Re: Canadian Association of Compaq U % Message-ID: <39459370@news.toast.net>   ? Having spent some time around our ITUG friends FWIW IMO careful L consideration should be given to just how natural a fit there is between theJ DECUS and ITUG communities.  Digital Style Computing comes from a heritageD of distributed loosely coupled network computers.  While key DigitalF heritage technologies have evolved into mission critical big boxes theF technology is still department/workgroup deployment friendly.  This isE especially true when you factor in Windows 2000.  The Tandem style of J computing appears to me based upon more the classic mainframe "big box" inI the center style of computing with a radial view of the world rather than 2 the distributed networked boxes view of the world.  L Tandem technology appears to be an integrated form of technology with a veryI tight coupling between the OS, the database, and the storage sub-systems. I For example SAN technology appears to be at odds with the Tandem concept. K Also with the DB being part of the OS an issue like Oracle versus Sybase is ' a non-issue because there is no option.   L Middleware in the Tandem world appears to be making the other things look toL applications like standard Tandem APIs'.  Middleware in the Digital world is! conforming to industry standards.   K Tandem folks seem to be highly focused on that unique range of applications L that truly require 99.99999 non-stop availability and are willing to pay theH price for it.  Digital platforms are very general purpose platforms i.e. jack-of-all-trades.   J In the end it will be interesting to see how much synergy there is betweenH the DECUS folks who tend to be in-depth technologist focused on buildingH generic IT enterprise class infrastructure and ITUG folks who tend to beK focused on building very specialized centralized non-stop environments.  It J also appears to me the ITUG folks build a lot more of their infrastructure right in the big box.   H I suspect the ITUG folks may feel more are home in a IBM user group thanK DECUS.  I also suspect the DECUS folks would feel more at home with UNIX or B W2K user groups than ITUG.  While both are users of Compaq brandedL technology the application fundamentals they deal with on a day to day basisJ are different.  Last weekend, when meeting with ITUG folks, I was remindedE again as to what the concept of 5 9's (99.99999)  really means.  Your K multi-million dollar computer infrastructure is NOT non-stop if when you go L to execute a stock trade the laser printer that produces the market order isI out of paper.  The 1-2 minutes it can take to refill the paper tray could G mean millions of dollars.  There really is difference in how one thinks K about an application that is 99.99 versus 99.99999 non-stop - and the price < you are willing to pay to build a 99.99999 infrastructure...       --     Jeff Killeen - www.Killeen.cc E ===================================================================== F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message% news:O$z87hKWOhc4@eisner.decus.org... ? > In article <skaevqj9h5167@corp.supernews.com>, "Peter Weaver"   <peter.weaver@stelco.ca> writes:G > > Larry Kilgallen wrote in message <6iJNoVN1Cj$2@eisner.decus.org>...   J > > "Canadian Tandem Users Group" but I went back to read Joseph's note toC > > make sure I had the name correct. In his note he said "I am the B > > current President for the Canadian Tandem Users Group, and theF > > Director of Finance for the Canadian Association of Compaq Users."G > > Does that mean that Tandem still has an user group? I was under the H > > impression that both DECUS and CTUG had both been killed to form the > > new CACU???? > B > Not specific to Canada, but my impression is that DECUS and ITUGA > have sufficiently different cultures and needs that there is no B > simple way to just make them one.  ITUG, for instance, has theirA > yearly symposium in San Jose, and I presume that is to maximize $ > participation by Tandem engineers.   ------------------------------  # Date: Mon, 12 Jun 2000 18:04:49 GMT / From: "John Nixon" <jorlnixon@worldnet.att.net>  Subject: Re: AutogenE Message-ID: <5D915.6898$iy.527441@bgtnsc06-news.ops.worldnet.att.net>   9 If you use teh parameters "savparams setparams feedback",   K It will use feedback from the running system.  Be sure your system has been % running during nomal to high activity  since the last reboot.  H It will go through all the phases between savparams and setparams, which includes genparams.   I It will set the new values into the "current file", which means that next I time you reboot, those values will be used.  They will  not be used until * you reboot, or otherwise make them active.   Hope this helps.  H By the way, if you have not been running autogen, or if you are not sure  that MODPARAMS     has been kept! current, I suggest the following:   " 1.   Assign you out put to a file, 2.   MCR SYSGEN,           Use Current            show /all  3.  Deassign sys$output K 4.  Run autogen  (Savparams setparams feedback)   (feedback is not necesary " if you system has been up > 24hrs)% 5.  Assign sys$output to another file H 6.  Run sysgen again, use current again, and show your paramaters again. 7.  Deass sys$outputH 8.  Compare your two output files and make sure you can account for, and explain, and understand       all the differences.  9   REBOOT.   L There are other ways to achieve this.  This is just one very straightforward way.  6 "Shawn" <sfm1115@bjcmail.carenet.org> wrote in message+ news:3944f6e9.329380844@news.starnet.net... 9 > If I were to run Autogen with the following parameters:  >  > savparams setparams feedback > C > will this get feedback from the running system and set the values . > without a reboot, or should I use genparams. > H > The system is an Alpha 2100, running OpenVMS 7.2-1, TCP/IP 5.0 and all > the necessary patches. >  > Thanks >  > Shawn  >    ------------------------------  % Date: Mon, 12 Jun 2000 19:19:08 -0400 2 From: "Richard B. Gilbert" <DRAGON@compuserve.com> Subject: Autogen6 Message-ID: <200006121919_MC2-A86F-D42@compuserve.com>  4         You can't "set" the values without a reboot.  G         The SETPARAMS phase writes a new parameters file (AUTOGEN.PAR?) J that will be used the next time you reboot.   Some parameters are Dynamic=  > and can be set "on the fly".  Most, however, require a reboot.            I would suggest running:  ) $ @SYS$UPDATE:AUTOGEN SAVPARAMS TESTFILES A check SYS$SYSTEM:AGEN$PARAMS.REPORT for planned actions that look # unreasonable and, if it's okay, run ) $ @SYS$UPDATE:AUTOGEN GENPARAMS SETPARAMS E and reboot at your earliest convenience.  If your convenience is now,  substitute REBOOT for 
 SETPARAMS.   Message text written by Shawn 8 >If I were to run Autogen with the following parameters:   savparams setparams feedback  A will this get feedback from the running system and set the values , without a reboot, or should I use genparams.  F The system is an Alpha 2100, running OpenVMS 7.2-1, TCP/IP 5.0 and all the necessary patches. <    ------------------------------  % Date: Mon, 12 Jun 2000 21:44:17 -0500 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>  Subject: Re: Autogen- Message-ID: <3945A001.16E27300@earthlink.net>    Shawn wrote: > 9 > If I were to run Autogen with the following parameters:  >  > savparams setparams feedback > C > will this get feedback from the running system and set the values . > without a reboot, or should I use genparams.  6 SETPARAMS will create a new boot-time parameters file.  D GENPARAMS will generate a new version of the intermediate files that9 AUTOGEN uses during the later phases (such as STEPARAMS).   H So, SETPARAMS is likely what you want, if you simply want to prepare for the next reboot.   --   David J. Dachtera  dba DJE Systems " http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/    ------------------------------  % Date: Mon, 12 Jun 2000 15:37:13 -0400 - From: "Peter Weaver" <peter.weaver@stelco.ca> G Subject: Re: Canadian Association of Compaq Users Symposium rescheduled . Message-ID: <skaevqj9h5167@corp.supernews.com>  C Larry Kilgallen wrote in message <6iJNoVN1Cj$2@eisner.decus.org>...  > ... > >From Canada, however, the complaints have continued unabated.; >There was apparently a clearly named individual at CACU to = >contact, and no reported success stories at getting into the  >VMS hobbyist plan.  > ...   A I was able to get the Hobbyist licenses using my old DECUS Canada 8 membership number so that is at least one success story.  ? In a previous life I was at a company where we had 7 or 8 DECUS A members when the $50 fee first came in. I was the only one in the > group who paid my membership mainly because I really liked theF newsletter that came out of the Rainbow User group in Vancouver. SinceF that group no longer has a newsletter the only reason I have now to beB in a DECUS group is the Hobbyist program. It was the only thing ofC value that I received from my last $50 membership fee and it is the . only reason I am considering joining the CACU.  C If any other DECUS group would post a message saying that they will F take members from other countries then I would send in my application.  C As a side note, are there any DECUS groups in the world that charge D money for membership? Was the Canadian DECUS group the only one thatF charged membership fees when it died? I was going to ask about the oldF "Canadian Tandem Users Group" but I went back to read Joseph's note to? make sure I had the name correct. In his note he said "I am the > current President for the Canadian Tandem Users Group, and theB Director of Finance for the Canadian Association of Compaq Users."C Does that mean that Tandem still has an user group? I was under the D impression that both DECUS and CTUG had both been killed to form the new CACU????   -- Peter Weaver   ------------------------------  # Date: Mon, 12 Jun 2000 23:27:18 GMTu9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)sG Subject: Re: Canadian Association of Compaq Users Symposium rescheduledm+ Message-ID: <O$z87hKWOhc4@eisner.decus.org>o  ^ In article <skaevqj9h5167@corp.supernews.com>, "Peter Weaver" <peter.weaver@stelco.ca> writes:E > Larry Kilgallen wrote in message <6iJNoVN1Cj$2@eisner.decus.org>...l >> ...? >>From Canada, however, the complaints have continued unabated.?< >>There was apparently a clearly named individual at CACU to> >>contact, and no reported success stories at getting into the >>VMS hobbyist plan. >> ... > C > I was able to get the Hobbyist licenses using my old DECUS Canada2: > membership number so that is at least one success story.  D Thank you.  The reports of success seem to be made less eagerly than those of failure.   E > As a side note, are there any DECUS groups in the world that chargeeF > money for membership? Was the Canadian DECUS group the only one thatH > charged membership fees when it died? I was going to ask about the old  ? The US DECUS chapter had a voluntary higher level of membershipi= lately that required a fee.  It may have gone away. DECUServeo> formerly had a fee, but as I understand the cost of collecting it overwhelmed the revenue.   H > "Canadian Tandem Users Group" but I went back to read Joseph's note toA > make sure I had the name correct. In his note he said "I am thee@ > current President for the Canadian Tandem Users Group, and theD > Director of Finance for the Canadian Association of Compaq Users."E > Does that mean that Tandem still has an user group? I was under thegF > impression that both DECUS and CTUG had both been killed to form the > new CACU????  @ Not specific to Canada, but my impression is that DECUS and ITUG? have sufficiently different cultures and needs that there is no-@ simple way to just make them one.  ITUG, for instance, has their? yearly symposium in San Jose, and I presume that is to maximizeh" participation by Tandem engineers.   ------------------------------  % Date: Mon, 12 Jun 2000 14:50:07 -0400m" From: Dan Sugalski <dan@sidhe.org>+ Subject: Re: CMQ/Dec with a sense of Humor?o: Message-ID: <4.3.2.7.0.20000612144932.01c65ca0@24.8.96.48>  * At 12:24 AM 6/12/00 -0400, JF Mezei wrote: >Antony Wardle wrote:r. > > I wasn't sure if I had the hold screen, so- > > I thought that I would try a control T tod > > see if there was any life. > > $ > > Well, I got a message up sayine: > >p$ > > dead_eater waiting for dead_beef >uN >I know that at least one DEC engineer was a fan of Monthy Python. Sounds likeF >a reference to a famous sketch (where one is invited to eat his dead  >mother in law).  I More likely it's looking for a quadword with the value 0xDEADBEEF in it. oJ One of the fun words and phrases you can actually spell entirely in hex...   					Dan  I --------------------------------------"it's like this"-------------------s2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and even ;                                       teddy bears get drunkh   ------------------------------  % Date: Mon, 12 Jun 2000 15:20:03 -0400h' From: "Bill Todd" <billtodd@foo.mv.com> + Subject: Re: CMQ/Dec with a sense of Humor?i( Message-ID: <8i3cuk$13h$1@pyrite.mv.net>  - Dan Sugalski <dan@sidhe.org> wrote in messageo4 news:4.3.2.7.0.20000612144932.01c65ca0@24.8.96.48..., > At 12:24 AM 6/12/00 -0400, JF Mezei wrote: > >Antony Wardle wrote: 0 > > > I wasn't sure if I had the hold screen, so/ > > > I thought that I would try a control T toi  > > > see if there was any life. > > >e& > > > Well, I got a message up sayine: > > >t& > > > dead_eater waiting for dead_beef > >gK > >I know that at least one DEC engineer was a fan of Monthy Python. Soundso likeG > >a reference to a famous sketch (where one is invited to eat his deado > >mother in law). > J > More likely it's looking for a quadword with the value 0xDEADBEEF in it.L > One of the fun words and phrases you can actually spell entirely in hex...  I And in at least some environments it's not just a random fun word but thesE pattern used to identify uninitialized memory (which can be useful toy9 human-type eyes squinting at a dump or debugging screen).y   - bill   >f > Dan  >tK > --------------------------------------"it's like this"-------------------c4 > Dan Sugalski                          even samuraiA > dan@sidhe.org                         have teddy bears and evenu= >                                       teddy bears get drunkt >m >e   ------------------------------  # Date: Mon, 12 Jun 2000 22:50:48 GMTr# From: Mark Sterk <strong@chello.nl>s+ Subject: Re: CMQ/Dec with a sense of Humor?k) Message-ID: <394568A3.E3391190@chello.nl>u   Dan Sugalski wrote:n  , > At 12:24 AM 6/12/00 -0400, JF Mezei wrote: > >Antony Wardle wrote:.0 > > > I wasn't sure if I had the hold screen, so/ > > > I thought that I would try a control T to=  > > > see if there was any life. > > >l& > > > Well, I got a message up sayine: > > >e& > > > dead_eater waiting for dead_beef > >nP > >I know that at least one DEC engineer was a fan of Monthy Python. Sounds likeG > >a reference to a famous sketch (where one is invited to eat his deade > >mother in law). >nJ > More likely it's looking for a quadword with the value 0xDEADBEEF in it.L > One of the fun words and phrases you can actually spell entirely in hex... >n- >                                         Dan  > K > --------------------------------------"it's like this"-------------------t4 > Dan Sugalski                          even samuraiA > dan@sidhe.org                         have teddy bears and evenl= >                                       teddy bears get drunk   ? No it's the name of the 'idle' process under the alpha console.rR If you press ^T you could see it if you are lucky, but you can better use the 'ps' command.   Mark   ------------------------------  # Date: Tue, 13 Jun 2000 00:10:04 GMT 9 From: stu@c49395-a.wodhvn1.mi.home.com (Stuart R. Fuller)-+ Subject: Re: CMQ/Dec with a sense of Humor?0% Message-ID: <3dt3i8.amu.ln@localhost><  # Dan Sugalski (dan@sidhe.org) wrote:l, : At 12:24 AM 6/12/00 -0400, JF Mezei wrote: : >Antony Wardle wrote:m0 : > > I wasn't sure if I had the hold screen, so/ : > > I thought that I would try a control T toI  : > > see if there was any life. : > >i& : > > Well, I got a message up sayine: : > >t& : > > dead_eater waiting for dead_beef : >eP : >I know that at least one DEC engineer was a fan of Monthy Python. Sounds likeH : >a reference to a famous sketch (where one is invited to eat his dead  : >mother in law). : K : More likely it's looking for a quadword with the value 0xDEADBEEF in it. yL : One of the fun words and phrases you can actually spell entirely in hex...  " Oh, my stomach hurts.  I must have           8BADF00D                  Stuo   ------------------------------  % Date: Mon, 12 Jun 2000 19:51:49 -0500r* From: Keith Brown <kbrown780@usfamily.net>+ Subject: Re: CMQ/Dec with a sense of Humor?h, Message-ID: <394585A5.3E88CA4B@usfamily.net>   "Stuart R. Fuller" wrote:o > % > Dan Sugalski (dan@sidhe.org) wrote:o. > : At 12:24 AM 6/12/00 -0400, JF Mezei wrote: > : >Antony Wardle wrote:p2 > : > > I wasn't sure if I had the hold screen, so1 > : > > I thought that I would try a control T toe" > : > > see if there was any life. > : > > ( > : > > Well, I got a message up sayine: > : > >d( > : > > dead_eater waiting for dead_beef > : >sR > : >I know that at least one DEC engineer was a fan of Monthy Python. Sounds likeI > : >a reference to a famous sketch (where one is invited to eat his deadl > : >mother in law). > :pL > : More likely it's looking for a quadword with the value 0xDEADBEEF in it.N > : One of the fun words and phrases you can actually spell entirely in hex... > $ > Oh, my stomach hurts.  I must have >  >         8BADF00D > 
 >         Stuo  @ An engineer I once worked with wrote low level diagnostics which< upon failure stored the value DEADBABE in a prominent place.   -- n Keith Brownm kbrown780@usfamily.net   ------------------------------  % Date: Mon, 12 Jun 2000 23:35:25 -0400e, From: Howard S Shubs <hshubs@mindspring.com>+ Subject: Re: CMQ/Dec with a sense of Humor?U> Message-ID: <hshubs-B8B0B8.23352512062000@news.mindspring.com>  > In article <3dt3i8.amu.ln@localhost>, stufuller@usa.net wrote:  # >Oh, my stomach hurts.  I must havef >a >        8BADF00Di	 >          >        Stu   You ate a bad stu?   --   Howard S Shubs, the Denim Adepta   ------------------------------  % Date: Mon, 12 Jun 2000 15:40:25 -0400 - From: "Mitchell, David R." <mitchell@WPI.EDU>c Subject: DCPS 1.7 and HP 6MPB Message-ID: <FE1835D68492D311BF7900508B5BEB0D0DE7EF@petra.WPI.EDU>  H I have an HP 6MP printer that started giving DCPS errors recently when aJ Win98 PC user connecting via Advanced Server 7.2-1 (VMS 7.2-1) attempts toG print 1 page Word mail merge documents.  The printer has an external HPoH Jetdirect box connecting it to the network and the queue is setup to useK IP_RawTCP on port 9100.  The PC is using a Postscript driver.  I suspect it=H is a lack of resources (memory - as it only has 3MB) that is causing theL problem as smaller documents print successfully.  But at this point I'm just2 guessing as all I have to go on is the DCPS error:  8 "%DCPS-E-FLUSHING, Rest of Job (to EOJ) will be ignored"  K I realize that this configuration is unsupported by DCPS but then again, sonK are most of our printers and we've always managed to work around any of thesL relatively few problems that have cropped up.  Does anyone have any guidanceF to offer on troubleshooting generic DCPS errors such as this.  Thanks.   David    ------------------------------  % Date: Mon, 12 Jun 2000 21:13:12 -0500l7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> 3 Subject: Re: Files-11 ODS-2 Readability for FreeBSD - Message-ID: <394598B8.59D0126A@earthlink.net>    mccrobie@my-deja.com wrote:  > I > I've been working on a READ-ONLY Files-11 ODS2 file system for FreeBSD. F > This file system is an installable kernel module and provides access8 > to files as a "true" mountable file system on FreeBSD. > 9 > Currently supported are the following FreeBSD versions:- >  >     FreeBSD 3.3, >     FreeBSD 4.04 > F > I am currently looking for beta testers who wish to read their ODS-2I > file systems on FreeBSD - my motivation has been the optical world, but H > as long as FreeBSD recognizes the device, the file system should work. > H > Sorry, automatic record type and file organization conversions are notJ > available, yet.  I'm guaging the interest in this product before I spend > anymore time with it.p > F > I should note that I plan this to be a commerical product which willG > cost actual money.  However, I'm open to discussions on license fees,eD > terms, etc.  Beta testers will probably receive a free copy of the2 > final production file system - some incentive... > E > For you Linux and Solaris users, I may be persuaded to add support.tF > Sorry for the Compaq Tru64 users - Compaq wants too much money for a > development machine... >  > If you are interested: >   > Chuck McCrobie (** MAD VAX **) > mccrobie@my-deja.com  G Well, for reasons which will become obvious when you check the links insB my sig., I would recommend either extremely low pricing or an Open Source release.   A I would also recommend working on adding write capability as this G currently does not exist in any ODS-2 code (to my knowledge) outside of  the OpenVMS world.   -- i David J. Dachtera  dba DJE Systemse" http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/t   ------------------------------  % Date: Mon, 12 Jun 2000 23:00:08 -0400I* From: Chuck McCrobie <mccrobi@apl.jhu.edu>3 Subject: Re: Files-11 ODS-2 Readability for FreeBSDi+ Message-ID: <3945A3B8.1D189D16@apl.jhu.edu>a   <sarcasm on>  C Well, given the overwhelming response I've had so far, I doubt this + product/project will make the light of day.5  F Adding write support is far beyond the scope of what I planned to do -C and I don't see any need for writing ODS-2 on FreeBSD to be read by E OpenVMS.  Why would you recommend adding write support?  Simply blast H your data to a CD-RW in ISO9660 mode and have the VMS system read it... H There's lots of burner software available for FreeBSD and Windows NT andE Macintosh and Digital Unix and ...  Then "erase" that CD-RW and blast  another image of data...  H Perhaps a Windows NT/2000 installable file system driver would be betterH received...  Oh well, long live Microsoft - may Bill Gates get even more richer!I  H I suppose there's not much interest in software the extends the range ofE OpenVMS systems.  After all, it may have held some incentive for somePF shops moving to Open Source to at least consider keeping their OpenVMS systems around.  I guess= the trend is to rid ourselves of all legacy systems and theirt "droppings".  
 <sarcasm off>g   Chuck McCrobie (** MAD VAX **)   "David J. Dachtera" wrote: >  > mccrobie@my-deja.com wrote:s > >eK > > I've been working on a READ-ONLY Files-11 ODS2 file system for FreeBSD.pH > > This file system is an installable kernel module and provides access: > > to files as a "true" mountable file system on FreeBSD. > >2  # [ description of software snipped ]a   > I > Well, for reasons which will become obvious when you check the links in2D > my sig., I would recommend either extremely low pricing or an Open > Source release.a > C > I would also recommend working on adding write capability as thisaI > currently does not exist in any ODS-2 code (to my knowledge) outside ofl > the OpenVMS world. >  > -- > David J. Dachterat > dba DJE Systemsl$ > http://home.earthlink.net/~djesys/ > < > Unofficial Affordable OpenVMS Home Page and Message Board:- > http://home.earthlink.net/~djesys/vms/soho/    ------------------------------  % Date: Mon, 12 Jun 2000 23:34:15 -0400., From: Howard S Shubs <hshubs@mindspring.com>3 Subject: Re: Files-11 ODS-2 Readability for FreeBSDf> Message-ID: <hshubs-6F5744.23341512062000@news.mindspring.com>  ; In article <3945A3B8.1D189D16@apl.jhu.edu>, Chuck McCrobie   <mccrobi@apl.jhu.edu> wrote:  
 ><sarcasm on>P [mild rant deleted]e ><sarcasm off>  J That doesn't sound like sarcasm; it sounds like a statement of position.  F Let me clue you, from my POV and apparently others: if you want to do H this, do it.  Don't expect to make money off it directly.  While you're  at it, try doing ODS-5.n  H As far as I can figure, the only way to "make money" off Open Source is E to get a really great rep from the quality of your code and get jobs S	 that way.l   --   Howard S Shubs, the Denim Adeptb   ------------------------------  % Date: Mon, 12 Jun 2000 22:30:38 -0500e7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>o3 Subject: Re: Files-11 ODS-2 Readability for FreeBSD0- Message-ID: <3945AADD.BBD92809@earthlink.net>    Chuck McCrobie wrote:h >  > <sarcasm on> > E > Well, given the overwhelming response I've had so far, I doubt thisc- > product/project will make the light of day.t  E Well, it's just that there are already at least two ODS-2 readers foro, DOS/WIN, W/9x and/or UN*X (including Linux).  iH > Adding write support is far beyond the scope of what I planned to do -E > and I don't see any need for writing ODS-2 on FreeBSD to be read byg: > OpenVMS.  Why would you recommend adding write support?   H ...and if you could dual boot *BSD/Linux and OpenVMS? (...and of course,@ you can!), would you not want to share data between the o.s.-es?  iJ > Perhaps a Windows NT/2000 installable file system driver would be betterJ > received...  Oh well, long live Microsoft - may Bill Gates get even more	 > richer!e   Like to live dangerously, huh?  e -- e David J. Dachteras dba DJE Systemsu" http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/n   ------------------------------  # Date: Mon, 12 Jun 2000 18:14:32 GMTo( From: Jay Olson <jjo@triton.com.no.spam>% Subject: FS: toasted AlphaStation 600v2 Message-ID: <3945271E.BC5ED8D4@triton.com.no.spam>  F My AlphaStation 600 appears to have been toasted while being moved. ItA has been sitting idle for close to a year, and when I unpacked itsE recently, it didn't seem to work any more. If you have such a machinetF and need some spare parts, or if you want to try tinker around and fix it, please make me an offer.  G It fails in the startup self-tests with error code F5, which is "BcacheC data path error".   A The system has 128 Mb of memory, 1 Gb and 2 Gb hard disks, CDROM,yH PGXGB-AA graphics, and a combo 2-channel SCSI and ethernet baord. It ranG VMS when it ran, but of course other operating systems will also run on 
 this machine.c  G If you wish to make an offer, or if you have a suggestion on how to fixn it, e-mail me.  ( 	- Jay Olson (jjo "at" triton "dot" com) 	Triton Software Group LLC   ------------------------------  % Date: Mon, 12 Jun 2000 23:15:42 -0500 ' From: Bill Bradford <mrbill@mrbill.net>p# Subject: Info on VAXstation 400-VLCl. Message-ID: <20000612231542.F29500@mrbill.net>  = Anybody know where I can find a user's manual for this thing?a5 (VAXstation 4000-VLC).  Specifically, I need to know:u  : 	- Type of RAM (I know its 72pin parity, but can I fill it
 	  with 16s?)u  : 	- Position of "S3" switch to enable serial console (all I 	  have is a VT320).  ? Of course, if anyone has an owner's manual for this unit or can ; point me somewhere online, it would be greatly appreciated.r  9 Thanks!  This machine will soon be running the decvax.org 
 web site. 8-)a   Bill   -- a* +--------------------+-------------------+* |   Bill Bradford    |   Austin, Texas   |* +--------------------+-------------------+* | mrbill@sunhelp.org | mrbill@mrbill.net |* +--------------------+-------------------+   ------------------------------  % Date: Mon, 12 Jun 2000 21:18:35 -0400t, From: Andrew Robert <robert_a@ix.netcom.com>  Subject: Re: Internet VMSCluster- Message-ID: <39458BEB.B3DD9473@ix.netcom.com>e  A Multinet from Process software works great for IP load balancing.r  F When configuring the application, you assign a dedicated IP address to6 the individual systems and a cluster alias IP address.  H Users connect via the cluster alias IP address and Multinet balances the load accordingly.t   I recommend you check it out.    Regards,
 Andrew Roberte Principal Systems Analysth  Massachusetts Financial Services   ------------------------------   Date: 12 Jun 2000 18:41:41 GMT0 From: sander@vmsbiz.enet.dec.com (Warren Sander)! Subject: Re: MMOV 2.2 and VMS 7.1e* Message-ID: <8i3at5$9hf@usenet.pa.dec.com>  4 	Http://www.openvms.compaq.com/openvms/products/mmov --  B ------------------------------------------------------------------6 Warren Sander                        OpenVMS MarketingD Compaq Computer Corporation          Work:  warren.sander@compaq.comB 200 Forest Street MR01-3/J1          Personal: sander@ultranet.com3 Marlboro, MA 01752                   (508) 467-4875 6    My opinions are my own and I only speak for myself /           Read http://www.openvms.digital.com/ sB ------------------------------------------------------------------   ------------------------------  # Date: Mon, 12 Jun 2000 18:51:30 GMT 3 From: Eric Dittman <dittman@narnia.int.dittman.net>j! Subject: Re: MMOV 2.2 and VMS 7.1m> Message-ID: <Sia15.4911$nh5.249992@news-west.usenetserver.com>  1 Warren Sander <sander@vmsbiz.enet.dec.com> wrote:06 : 	Http://www.openvms.compaq.com/openvms/products/mmov   Thanks, Warren!t --   Eric Dittman dittman@dittman.netn   ------------------------------  % Date: Mon, 12 Jun 2000 19:13:10 +0100n, From: Ted Allwood <support@leva.leeds.ac.uk>5 Subject: MRTG (Multi Router Traffic Grapher) for VMS? 3 Message-ID: <009EB82A.B65BC647.18@leva.leeds.ac.uk>o  G MRTG (Multi Router Traffic Grapher) is a Perl/C utility for collecting  G network performance data from devices via SNMP.  Results are presented  K in a graphical form suitable for web-based monitoring.  Its available from:l8 http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html  F Has anyone got MRTG running under OpenVMS?  Comments within the sourceG code indicate that progress has been made in this direction but its notiH clear if the port is complete.  With MRTG 2.8.12, I can issue queries toL a network device using the cfgmaker tool and obtain plausible configuration F details but subsequent attempts to collect traffic data have failed.  F Any VMS-based examples or work-around hints would be much appreciated.     Regards, Tedb  K -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- K Support@leva.leeds.ac.uk                                Tel:  0113 233 2167MG School of Mechanical Engineering,  University of Leeds,  Leeds  LS2 9JTs   ------------------------------  % Date: Mon, 12 Jun 2000 20:17:59 +0200o' From: "ilnodo.it" <ilnodo.it@ilnodo.it>e Subject: novityt2 Message-ID: <8i39eo$p58$9@fe1.cs.interbusiness.it>  $                        www.ilnodo.it   ------------------------------  % Date: Mon, 12 Jun 2000 19:58:15 -0500 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>rJ Subject: Re: OpenVMS commentaries (was Re: Gartner commentary on Wildfire)- Message-ID: <39458727.9D3A8E84@earthlink.net>n   Hoff Hoffman wrote:w > c > In article <802568F2.0041F477.00@qedilc01.qedi.quintiles.com>, steven.reece@quintiles.com writes:iF > :The tide of OpenVMS is dead has not turned yet.  I was talking to aN > :representative of a recruitment company earlier this week who believes thatR > :OpenVMS is dead or is on the way.  She was very surprised that there is so muchK > :good work being done at Compaq to reverse this trend.  I take this as an N > :indicator that the companies which she deals with are moving away from VMS. > F >   Or she's not been contacted for folks looking for OpenVMS -- we'reC >   currently hiring, for instance.  The OpenVMS VP, Rich Marcello,rD >   recently mentioned that one thing under serious consideration isA >   the inclusion of a recruitment or jobs website for folks withm2 >   OpenVMS skills via the Compaq OpenVMS website.  4 Should have been done along time ago. Why the delay?  DP > :Perhaps the new marketing materials should be send out in paper copy a little > :more widely  H Try __A__ __L__O__T__ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  ...more widely !!!  F As I've said before: Show me the prime-time TV ads (I have at least 15H scripts on my computer right here). Show me the full-page trade-rag ads.G Show me the billboards. Show me the bus benches and ads on the sides of 
 the buses.  A > (not just to existing customers who are still heavily committed J > :to VMS) but to companies with only one or two small systems in a bigger0 > :environment (the small fish in the big pond). > C >   I can't speak for the marketing plans for OpenVMS and certainlynB >   not for the contents of the press.  I can say that there are aD >   number of OpenVMS sites looking for OpenVMS-trained folks.  (eg: >   us.)  H Yeah - and when they can't find 'em, they say, "Screw it! At least LinuxA geeks are a dime a dozen! ...and Linus doesn't screw us on either- license or support pricing."  eO > :I would like to see a complete "Porting to VMS" manual.  This would probably P > :also be of use to ISVs who can't get enough VMS resource to be able to tackle. > :a port of their software to the VMS market. > H >   Part of this is tied into the COE work, which is an environment thatH >   makes porting C code from Sun Solaris over to OpenVMS rather simple.  & ...but where's the economic incentive?   J > :The mention of host-based InfoServer interests me too - I would like toI > :be able to leave the VMS documentation CDs in my InfoServer full-time,aI > :but we just don't have enough CD drives around the place to be able to 	 > :do it.l > ? >   Getting more CD-ROM drives would be a quick fix, obviously.t  lI > :My fear, as I've stated before and still seems to be the case, is that N > :although VMS Engineering is working hard to give customers new developmentsN > :and improvements and guaranteed support for x number of years and the otherN > :excellent stuff that they're doing, there are significant numbers of peopleN > :out there in "User Land" that won't believe that there's any committment toM > :VMS anyway and it's all just a big show by Compaq before they pull the rugb) > :out from under all of their customers.> > F >   The ten and fifteen year commitment letters should be interesting,F >   but the only real cure is the continued support (and enhancements)B >   for OpenVMS and various direct visits and updates from OpenVMS6 >   management and engineering.  (And from marketing.)  F Sorry - marketing _H_A_S_ to come first! If the market doesn't believeE it, it doesn't matter HOW many commitment letters come out of Compaq.E  0H > :A pet peeve at the moment is the issue of Prior Version Support.  TheF > :UK CSC is apparently going to support VMS v7.1, 7.1-1h1 and 7.1-1h2H > :without the backup of VMS Engineering following the 1st of July 2000. > G >   Donno about notifications (which I would have expected to have beeneF >   sent out), but there is information on Prior Version Support plansF >   referenced in the OpenVMS FAQ.  (Please search for "Prior Version"" >   for a pointer to the details.)  H Sorry to be so sour, Hoff and everyone, but my patience is nearly spent.  F Am _I_ the only one out here with enough balls to put OpenVMS where it? belongs in the marketplace? ...or do we have to wait until somerF corporate types think it's either politically or economically correct?   -- w David J. Dachtera  dba DJE Systemsy" http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/    ------------------------------  % Date: Mon, 12 Jun 2000 17:07:21 -0600 1 From: Glen Martin <GLENMARK@utxvms.cc.utexas.edu> 9 Subject: Re: Qt2.1.0 GUI library now available on OpenVMS 4 Message-ID: <394518C9.4298BC44@utxvms.cc.utexas.edu>   Zane H. Healy wrote:  N > Hey, this sounds better than getting Gnome ported!  Personally as a whole, IL > prefer KDE to Gnome.  Although both have some good apps that would be nice > to see on OpenVMS.  H Egads. Do you realize that KDE apps can only be written in C++? Gnome is8 language-independant (much like OpenVMS system calls)...   Glen   ------------------------------  # Date: Mon, 12 Jun 2000 22:43:00 GMTi2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>9 Subject: Re: Qt2.1.0 GUI library now available on OpenVMSs6 Message-ID: <UHd15.500$ru5.154682@typhoon.aracnet.com>  2 Glen Martin <GLENMARK@utxvms.cc.utexas.edu> wrote: > Zane H. Healy wrote:  O >> Hey, this sounds better than getting Gnome ported!  Personally as a whole, I M >> prefer KDE to Gnome.  Although both have some good apps that would be nice  >> to see on OpenVMS.o  J > Egads. Do you realize that KDE apps can only be written in C++? Gnome is: > language-independant (much like OpenVMS system calls)...   > Glen  K Worse, I don't write C++.  However, from a user standpoint I prefer the KDErK stuff.  Just a matter of preference from the user side.  Still it's gettingCI to the point where you really need both, if you want the new stuff that'se coming out.   H OTOH, I've no idea how hard it would be to port any of the stuff over toF OpenVMS.  I do a little programing, but I try to stay away from GUI's.   				Zane   ------------------------------  % Date: Mon, 12 Jun 2000 15:07:43 -0700l@ From: "Russell E. Owen" <owen@astroNOJNK.washington.edu.invalid>8 Subject: Re: Question on using ASTs for output (Summary)2 Message-ID: <8i3mvg$54vq$1@nntp6.u.washington.edu>  F Much thanks to all who replied, including Jesper Naur, JF Mezei, Carl I Perkins and Dave Weatherall. There were many excellent suggestions and I e- really appreciate the fast and accurate help.-  C A brief summary of the problem: my program has a loop that reads a bD command via fortran read and executes it, occasionally reporting an G error via fortran write. Meanwhile it also queues a SYS$QIOW read of a eF message mailbox that ran an AST whenever a message is received in the D mailbox. The AST writes the message to the user using fortran write.   Problems include:p - redundant I/O errors: - if the user types anything it blocks output from the ASTF - commands the user types overwrite the last line of output (cosmetic)  G The worst problem is that the FORTRAN RTL (used for read and write) is  I not reentrant and so doesn't like ASTs doing a write at the same time as aF an existing write. Perhaps simply setting /reentr=ast on the compiler E will work for modern compilers (which I don't have quite yet). Also, s+ fortran read blocks the write from the AST.e  G Suggestions included (summarized, read the messages for useful details s* and caveats; copies available on request):H - Disable ASTs using sys$SetAST during error message writes (so the AST ' doesn't try to write at the same time).SD - Use sys$BrkThruW (or sys$qio or lib$put_output) to write. All are E AST-safe, and sys$BrkThruW breaks through a pending fortran read and d* even fixes the cosmetic overwrite problem.H - Change the reading technique to be AST safe and avoid blocking output:&   - sys$qio, possibly single character   - SMG-D - Use asynchronous read, as well as asynchronous write. A very nice 8 idea, especially since output is more common than input.H - Use threads (once I finish upgrading all our computers to the current  VMS and compiler)   E So far I have implemented the first two suggestions -- blocking ASTs eD during error message write and doing all writes  with sys$BrkThruW. I Though now that I'm using sys$BrkThruW and no fortran writes I suspect I i no longer need to block ASTs.   H This fixed all of the problems I was having and introduced or exposed a G new one -- probably due to the fact that I'm still using fortran read.  C Normally it works very well, but if I really flood the system with MF commands and messages I can get it into a hung state where it outputs $ messages but does not read commands.  G I figure that my next step is to try one of the techniques for reading.m  G Thank you again for all your help. I am overwhelmed by the kindness of gE those who responded and the high quality and detail of the responses.<  
 -- Russell   ------------------------------   Date: 12 Jun 2000 18:22:30 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)B Subject: Re: ramdisk vs. file cache, and the winner is, file cache, Message-ID: <8i39p6$s7a@gap.cco.caltech.edu>  a In article <8hug3h$s81@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu (David Mathog) writes:e  B Here is some more data.  I've refined the test procedures slightlyH so that they break out different functions of the original test program.< If anybody wants to run these benchmarks themselves pick up:  =    http://seqaxp.bio.caltech.edu/pub/SOFTWARE/mybenchmark.zip   I You'll need a C compiler.  There are test versions for OpenVMS and Linux/oB Alpha.  For OpenVMS unpack on the ramdisk, enter the "mybenchmark" directory and do:    $ @makeB $ @testsplit   For Linux, do:   # ./make.shh # ./testsplit.sh  I In the results shown here mda0 was set to 64000 blocks, caching disabled,cC no highwater. For Linux/Alpha I used default settings (file cache).hG I'd really appreciate it if somebody with a Tru64 DS10 could run these rI tests.  I suspect it will come out near Linux, but at this point I'm not eH going to give much credence to that guess anything until I see the data.  F Times shown are in 1/100ths of a second in all cases. Ops is the deltaI change in the number of operations shown on the mda0 caased by the test.  G On Linux all I had was "date", so each operation was performed 10 timeseE sequentially and the resulting time was divided by 10.  Ratio is the d> OpenVMS time divided by the Linux/Alpha time (where possible).  =                                      OpenVMS      Linux/AlphauB Program    tests                   time   Ops     time       ratio@ MAKETEST   Creating test file        77  3480       30       2.5? MYSTART    Program startup speed      1     8        0        --? MYOPENIN   + open speed               1    14        0        -M@ MYREAD     + read only speed         38  1036       10       3.8@ MYOPEN     + file creation speed     67  2269       10       6.7@ MYSPLIT    + file write speed       138  6200       40       3.5  F RMS parameters apparently do have an affect even when using a RAMDISK:  8            Extend=0   Extend=0    Extend=0    Extend=2057            block=0    block=127   block=127   block=127b8            buffer=0   buffer=0    buffer=255  buffer=255  8 Program    time   Ops time   Ops  time   Ops  time   Ops8 MAKETEST     77  3480   48  473     49   479    49   5468 MYSTART       1     8    1  8        1     8     1     88 MYOPENIN      1    14    1  12       1    12     8    128 MYREAD       38  1036   25  144     31   148    26   1428 MYOPEN       67  2269   60  1381    63  1386    61  13798 MYSPLIT     138  6200  100  2023   113  2028   101  2029  D I also tried changing the output directory to NLA0: inside the test D procedure before running MYOPEN and MYSPLIT.  That dropped the timesE down to 44 and 73 respectively.  So the NULL device is faster than a t3 RAMdisk, but STILL not as fast as Linux file cache.   K Any way you cut it Linux using file cache is much faster than OpenVMS using C a Ramdisk on every single one of these tests on identical hardware.uJ Moreover, in all cases that could be compared (where Linux wasn't too fastK to measure) it was by factors of hundreds of percent.  (CPU intensive tests I usually come out the same to within a few percent on the two platforms.) a  J So the question remains, since CPU speed is the same, Memory speed is the D same, compilers are essentially the same, and both sets of tests areJ essentially just CPU /Memory tests when they go to file cache/RAMdisk, why# is OpenVMS STILL so much slower??? 0  H The obvious culprits for this overhead are RMS and the C RTL.  Is there J any program that does IO at a comparable speed?  Yes.  Compare the resultsJ of copy10.com and copy100.sh.  Times shown are in seconds and indicate the@ UNIT time for the operation (total time / number of iterations)   >                            OpenVMS   Linux  (times in SECONDS)@ copy test.nfa foo.nfa          .08          (from 10 iterations)A cp   test.nfa foo.nfa                  .11  (from 100 iterations)l> append test.nfa foo.nfa       1.65          (from 1 iteration)A cat test.nfa >> foo.nfa                .17  (from 100 iterations)y  G I don't have the source code for OpenVMS, but it is certain that APPENDbF must use RMS, and it seems likely that COPY does not in this instance.E Given their age, I suspect neither is written in C (somebody with therI source code please check), so that would seem to indicate that RMS is thesE primary culprit for the poor IO performance of OpenVMS versus Linux. s  $ This is all very disappointing. :-(.   Regards,   David Mathog mathog@seqaxp.bio.caltech.edur? Manager, sequence analysis facility, biology division, Caltech  J **************************************************************************J *                                RIP VMS                                 *J **************************************************************************   ------------------------------  % Date: Mon, 12 Jun 2000 21:11:01 -0400r, From: Andrew Robert <robert_a@ix.netcom.com>B Subject: Re: ramdisk vs. file cache, and the winner is, file cache- Message-ID: <39458A25.EB4449C8@ix.netcom.com>-   David Mathog wrote:  > G > I had to do some system maintenance this weekend and thought that I'd.G > revisit the file caching performance issue by installing a ramdisk ongH > my system.  So after 2.3 was installed I ran the programs which follow@ > my signature on a 32 Mb RAMdisk on a DS10, with these results: >  > $ r maketest! > $ mysplit:==$mda0:[temp]mysplit  > $ create testsplit.com > $ sho time  > $ define/user sys$output nla0: > $ mysplit test.nfa 200 > $ sho time > ^Z > $ @testsplit >   10-JUN-2000 15:03:22 >   10-JUN-2000 15:03:23 > 9 > (delta varied between 1 and 2 seconds in multiple runs)r >  > $ sho dev mda0 > L > Disk SEQAXP$MDA0:, device type RAM Disk, is online, mounted, file-oriented >     device, shareable. > Q >     Error count                    0    Operations completed             216498eQ >     Owner process                 ""    Owner UIC               [SYSMGR,SYSTEM]aQ >     Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W Q >     Reference count                1    Default buffer size                 512aQ >     Total blocks               64000    Sectors per track                    64 Q >     Total cylinders               32    Tracks per cylinder                  32e > Q >     Volume label              "MDA0"    Relative volume number                0eQ >     Cluster size                   3    Transaction count                     1uQ >     Free blocks                62700    Maximum files allowed              8000hQ >     Extend quantity                5    Mount count                           1 Q >     Mount status              System    Cache name      "_SEQAXP$DKA0:XQPCACHE"sQ >     Volume owner UIC [SYSMGR,SYSTEM]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD  > R >   Volume Status:  ODS-2, subject to mount verification, file high-water marking, >       caching is disabled. > H > That's MUCH faster than I could ever achieve by RMS tuning, but oddly,A > STILL not as fast as the same code run on Linux on an otherwisehF > similar DS10.  It runs there about 2-3X faster as judged by the rateD > at which the names of the created files scroll by (it completes inB > under a second, so hard to time it precisely.)  This is when theH > mysplit program is run without suppressing the messages.  A small partE > of the speed difference may be a longer image activation on the VMS H > side, but once it gets rolling it is clearly taking longer per file on > the OpenVMS end.  I triedl >  > $ set RMS/extend=204 > H > (the size of the output files) but that didn't speed things up at all.G > Caching was disabled already (it's pointless when going to a RAMDISK,t@ > isn't it?).  Turning off highwater marking didn't help either. >  > So this is the situation:l > ! > OS             OpenVMS    Linuxp& > Version        7.2-1      RedHat 6.2  > Machine        DS10       DS10& > input file     ramdisk    file cache& > output files   ramdisk    file cache& > program        ramdisk    file cache* > C RTL          disk       file cache (?)$ > compiler       Compaq C   Compaq C+ > version        V6.2-007   ccc-6.2.9.002-2h0 > Run time       1-2        0.5        (seconds) > H > So why does OpenVMS STILL run slower than Linux?  While 2-3X slower isC > certainly better than the 100X slower it registered "vanilla" thesD > result seems very wrong because CPU intensive programs usually runH > within a few percent of each other on the two platforms, and here I'veC > essentially reduced this disk IO application to a pure CPU/memoryf; > application, and yet there's still a 2-3 fold difference.d > F > I wonder if it may not be related to the earlier result in my TCP/IPH > tests, where TCP/IP services sending data through a pipe to itself did0 > so slower than Linux did - by a similar ratio. > G > Anybody care to speculate about what accounts for the remaining large'  > difference in the performance? > 
 > Regards, >  > David Mathog > mathog@seqaxp.bio.caltech.eduo@ > Manager, sequence analysis facility, biology division, Caltech > H > ********************************************************************** >  > /* MAKETEST.ClF >    makes a 16000 entry fasta file, each containing a 500 bp sequence > */ > #include <stdlib.h>  > #include <stdio.h> >  > void main(void){
 > int i,j; > FILE *fd;e >    fd=fopen("test.nfa","w"); >    for(i=0; i< 16000; i++){ + >       (void) fprintf(fd,">test%.4d\n",i);l >       for(j=0; j < 10; j++){U >          (void) fprintf(fd,"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n"); 	 >       }m >    } > }i > H > ********************************************************************** >  > /*  MYSPLIT.Cm7 > quicky program.  It splits a fasta file into a series 6 > of new files at N line intervals.  First argument is6 > the filename and second is the number of entries per@ > file fragment.  Single long sequence lines will not be handled* > properly if they exceed the buffer size. > */ >  > #include <stdlib.h>m > #include <stdio.h> > #include <unistd.h>a > #define MYMAXSTRING 100000# > int main(int argc, char *argv[]){y > char *infile;e > char *outfile; > char root[]="frag";t > char bigstring[MYMAXSTRING]; > char outname[200]; > int  n,count,fragcount;t > FILE *fin;
 > FILE *fout;s >  >  >   fout=NULL; >   fragcount=0; >   count=0; >   n=0;; >   if(argc != 3 || (sscanf(argv[2],"%d",&n)==EOF) || n<1){M\ >     (void) printf("Usage:  mysplit infile N, where N is number of entries perfragment\n"); >     exit(0); Quick question.s  F Why didn't you use the VMS virtual I/O file cache and do a true apples to apples comparison?o  D The VIOC file cache resides in P0 space and has a max size of 1gig.   G Depending on the system memory installed on your system, you may not be D able to allocate 1gig but you will definitely see a huge performance boost.   Regards,
 Andrew Robert0 Principal Systems Analyst1  Massachusetts Financial Services   ------------------------------  % Date: Mon, 12 Jun 2000 23:03:19 -04000* From: Chuck McCrobie <mccrobi@apl.jhu.edu>" Subject: Re: Recording CD's on VMS+ Message-ID: <3945A477.2FBD7A76@apl.jhu.edu>s  E Does this newsgroup think a supported CD-R solution to be worthwhile?.7 Would support for the freeware utilities be worthwhile?nH Would a completely commerical (i.e. NO freeware) solution be worthwhile?   Chuck McCrobie (** MAD VAX **)  ! steven.reece@quintiles.com wrote:  >  > Arne wrote/quoted: > >>>Alexey Efron wrote:H > >     Can anybody advice me on a way of creating CD's readable on VMS?+ > >     I've got HP SpeedWriter 9200, SCSI.oP > >     Is there any software for VMS or NT that allows creation and duplication > > of CD's in VMS format? >  > The simple approach is to:4 >   - create a CD image on VMS with DFY$VMS_CD or LD1 >   - transfer that file to a PC with a CD burner3 >   - burn the image > > > But it is also possible to connect a CD burner directly to a
 > VMS box.<<<i > N > I'm not sure if you could use the resulting CD for a master in a duplicationQ > process, but over the last few days I've had some success using LD062 (from theaP > freeware CD) to create a virtual disk device on an AlphaServer which I've then9 > been able to burn on a Yamaha CD-R drive using CDWRITE.c > R > Although the resulting CDs seem to have an issue with the Storage Control Block,P > one of the disks did have a minimum boot/backup kit for Alpha on it and it did > boot successfully. > H > As with all of these solutions, YMMV and it isn't supported by Compaq. >  > Steve.   ------------------------------  % Date: Mon, 12 Jun 2000 22:32:36 -0500r7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>q" Subject: Re: Recording CD's on VMS- Message-ID: <3945AB54.82582329@earthlink.net>R   Chuck McCrobie wrote:: > G > Does this newsgroup think a supported CD-R solution to be worthwhile?   G Certainly! ...just make sure it has BOTH a command-line interface *AND*/ a GUI!  9 > Would support for the freeware utilities be worthwhile?-   Absolutely!-  J > Would a completely commerical (i.e. NO freeware) solution be worthwhile?   Absolutely!c   ...IMHO.   -- a David J. Dachterat dba DJE SystemsM" http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/H   ------------------------------  % Date: Mon, 12 Jun 2000 21:37:11 -0500 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>- Subject: Re: stand alone backup - Message-ID: <39459E57.B5D8FBCA@earthlink.net>t   vmsinmich wrote: > E > I would like to know the commands or procedure to use a stand alone2= > backup. The back up is on floppies and there are 18 of themG  4 1. Determine the device name of your diskette drive.  B On a VAXstation 2000, it may be either DUA1 or DUA2. I believe you4 mentioned VAXstation 2000 in an earlier post, right?  A 2. Insert the first diskette, and enter this command at the "dead. sergeant" prompt:g  
 >>> B DUA1   (if DUA1 is the diskette drive)h  ( 3. Change diskettes as you are prompted.  F Stand-alone backup uses the same syntax as the on-line backup command." Only BACKUP commands are accepted.   -- e David J. Dachterat dba DJE Systemsa" http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/n   ------------------------------  % Date: Mon, 12 Jun 2000 21:25:01 -0500=7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> 5 Subject: Re: Submit /After delta time format question - Message-ID: <39459B7D.12BD9738@earthlink.net>g   Mark-Simon Pope wrote: > 4 > BAL780::L72> submit test.com /after="+1- 04:00:00"G > Job TEST (queue L72_BATCH, entry 244) holding until 10-JUN-2000 14:29n > BAL780::L72> sh time >    9-JUN-2000 10:29:53 > K > I want to be able to submit the above job for 4am the next day.  I know I-I > could easly write a DCL routine to calculate the correct time. I'm justd? > wondering if there is a correct delta time format to do this.S >  > Mark-Simon PopeG  + $ SUBMIT/NOPRINT proc_name/AFTER="04:00+1-"4   ...works for me.   -- t David J. Dachteraw dba DJE Systemsa" http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/e   ------------------------------  % Date: Mon, 12 Jun 2000 22:15:54 +0200t= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>.8 Subject: Re: Tru64 Unix Clustering with OpenVMS Clusters) Message-ID: <394544FA.DEEC9C39@gtech.com>n   Gregory P Lechkun wrote:H > I've heard that Compaq is making Tru64 Unix "clusterable" with OpenVMS* > clusters, has anyone else heard of this?   No.k  > And I think if it was true, then it would be with very limited functionality.  + If we look at the advantages of clustering:h   1) sharing of system disko   2) sharing of user databasec   3) sharing of queue database   4) sharing of disksk  2 then I would only consider #2 possible in practice to implement cross VMS-Tru64.    Arne   ------------------------------   Date: 12 Jun 2000 21:05:03 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)8 Subject: Re: Tru64 Unix Clustering with OpenVMS Clusters, Message-ID: <8i3j9v$56l@gap.cco.caltech.edu>  _ In article <39451FD3.14FDB17@dteenergy.com>, Gregory P Lechkun <lechkung@dteenergy.com> writes:.G >I've heard that Compaq is making Tru64 Unix "clusterable" with OpenVMS ) >clusters, has anyone else heard of this?t   No.h  J Check your source again.   Maybe what you "heard" was actually a referenceJ to the transfer of OpenVMS cluster technologies for use on Tru64 clusters.J But moving parts of the lock manager from OpenVMS to Tru64 by itself isn't9 going to enable you to cluster OpenVMS and Tru64 systems.e  H I'm not going to even try to guess if fixing the IO system in OpenVMS soH that it runs at Tru64 speeds would be more or less work than patching upF Tru64 so that it clusters as well as OpenVMS.  But I will offer up theJ opinion that getting a really useful OpenVMS - Tru64 cluster would require  that both tasks be completed.     J If OpenVMS engineering did bring the speed of the IO systems on OpenVMS upC to snuff (see my other threads on that) there wouldn't be much of a J performance difference left between Tru64 and OpenVMS.   For CPU intensiveE work it's basically even now, even though Tru64 gets all the best CPUlK optimization tools first (and sometimes, ever.)  The base compilers alreadydI do a pretty decent job of optimization, and I've never seen anybody claim G that the Tru64 specific tools give more than a few percent beyond that. H Tru64 does get all the parallel development tools and OpenVMS gets none,J but that isn't a "clustering" issue per se.  Still, I can't help wonderingG if we won't eventually see some sort of OpenVMS cluster based on the SC  interconnect hardware. g   Regards,   David Mathog mathog@seqaxp.bio.caltech.edut? Manager, sequence analysis facility, biology division, Caltech e   ------------------------------  % Date: Mon, 12 Jun 2000 17:34:42 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> 8 Subject: Re: Tru64 Unix Clustering with OpenVMS Clusters( Message-ID: <8i3kra$7tb$1@pyrite.mv.net>  G Just as a plug (one more time), this is the kind of functionality I was I proposing be implemented with a SAN file system (about 3 months ago, withrE essentially no interest expressed here, in the Tru64 newsgroup, or in J comp.sys.dec).  Such a new file system would allow shared-disk access fromJ heterogeneous environments, could support things like the caching featuresA VMS currently lacks (as well as the VMS features - e.g., RMS-like H facilities - that Unix and NT currently lack), and by maintaining only aE shared file system environment could avoid the knottier heterogeneity B problems of a far more intimately-connected cluster configuration.  D An observation made elsewhere recently was that such a heterogeneousL shared-disk SAN file system would offer the Unix and NT communities at leastI semi-standardized features that they are missing (while maintaining thosexB they currently value) and offer VMS far better ability to fit intoF heterogeneous environments plus some performance features it's missingL (while maintaining the things VMS values).  And if Compaq doesn't build suchG a system, you can be sure that whoever does (and several already exist,oH including products recently purchased by IBM and HP which one can assumeF they purchased for a reason) won't be interested in including VMS as aI supported environment, let alone any features of specific interest to the  VMS community.   - bill  = David Mathog <mathog@seqaxp.bio.caltech.edu> wrote in messageo& news:8i3j9v$56l@gap.cco.caltech.edu...@ > In article <39451FD3.14FDB17@dteenergy.com>, Gregory P Lechkun  <lechkung@dteenergy.com> writes:I > >I've heard that Compaq is making Tru64 Unix "clusterable" with OpenVMSo+ > >clusters, has anyone else heard of this?t >  > No.t > L > Check your source again.   Maybe what you "heard" was actually a referenceL > to the transfer of OpenVMS cluster technologies for use on Tru64 clusters.L > But moving parts of the lock manager from OpenVMS to Tru64 by itself isn't; > going to enable you to cluster OpenVMS and Tru64 systems.e >nJ > I'm not going to even try to guess if fixing the IO system in OpenVMS soJ > that it runs at Tru64 speeds would be more or less work than patching upH > Tru64 so that it clusters as well as OpenVMS.  But I will offer up theL > opinion that getting a really useful OpenVMS - Tru64 cluster would require > that both tasks be completed.h >RL > If OpenVMS engineering did bring the speed of the IO systems on OpenVMS upE > to snuff (see my other threads on that) there wouldn't be much of agL > performance difference left between Tru64 and OpenVMS.   For CPU intensiveG > work it's basically even now, even though Tru64 gets all the best CPU*E > optimization tools first (and sometimes, ever.)  The base compilers  already K > do a pretty decent job of optimization, and I've never seen anybody claim*I > that the Tru64 specific tools give more than a few percent beyond that.2J > Tru64 does get all the parallel development tools and OpenVMS gets none,L > but that isn't a "clustering" issue per se.  Still, I can't help wonderingI > if we won't eventually see some sort of OpenVMS cluster based on the SCe > interconnect hardware. >d
 > Regards, >' > David Mathog > mathog@seqaxp.bio.caltech.edub@ > Manager, sequence analysis facility, biology division, Caltech   ------------------------------  % Date: Tue, 13 Jun 2000 07:04:17 +0800D- From: David B Sneddon <dbsneddon@bigpond.com> . Subject: Re: UCX problems after network glitch+ Message-ID: <39456C71.840D6CA6@bigpond.com>$   Mike Price wrote:p > 3 > I hope someone has seen this before and can help. ? > We are running UCX version 4.2 - planning to go to 5 in a feweB > months - and we seem to get problems whenever there is a networkA > glitch. This problem only happens on the VMS systems - the UNIXf@ > boxes and everything else recover OK - hence the network group- > end up blaming us fro the network problem!! = > The problem is that when the network falls over and then isIA > fixed sometimes a VMS system will end up not being able to talk0 > to any other IP boxes.< > LAT will be OK, decnet wil be OK by IP is useless. We have@ > identified that the main proble is that we cannot ping (telnet > or anything) the gateways.B > There are normally strange routes set up in the database (we useA > static routing) and sometimes if we get rid of these everythinglB > comes back to life but normally the only solution is to stop and > re-start UCX.i > What I would like to know is= > a) has anyone else seen this and is it fixed with version 5 B > b) Does anyone know what UCX does when it comes up that makes itA > talk to other systems - and is there a way to do this without a : > stop and restart. A pointer to some information would be > appreciated here; > c)is there anyway you know of that can stop it happening.  >  > Hope someone can help  >  > Thanks in advanceD >  > Mike > N > * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *I > The fastest and easiest way to search and participate in Usenet - Free!    Mike,   I When the "problem" happens, what does UCX SHOW COMMUNICATION/MEMORY show?uH I had (and still have) similar problems with UCX 4.2 (with/without ECOs)C and found that upgrading to TCP/IP V5.0A seems to fix it (I haven'trH had the problem since upgrading).  I logged a call with CSC at one stage$ and their only answer was "upgrade".   --   Regards, Dave.eI -------------------------------------------------------------------------sI David B Sneddon (dbs)  OpenVMS Systems Programmer   dbsneddon@bigpond.comeI DBS software at ...   http://www.users.bigpond.com/dbsneddon/software.htmaI "Life is what happens to you while you're busy making other plans" Lennont   ------------------------------  % Date: Mon, 12 Jun 2000 17:16:54 -0400g" From: Dan Sugalski <dan@sidhe.org> Subject: Re: VAX on Intel?: Message-ID: <4.3.2.7.0.20000612171343.01c51580@24.8.96.48>  . At 10:59 AM 6/10/00 -0600, Carl Perkins wrote:8 >Christopher Smith <chriss@Mufasa.pubserv.com> writes...) >}On Fri, 9 Jun 2000, Dan Sugalski wrote: A >}> I don't know that Alphas run cool enough to put in a laptop, r >unfortunately.  >}> They run awfully warm... >}5 >}You do know that it's been done once before, right?  > H >And even if a high speed 21264 was too hot, why not just run it slower?C >Instead of a 600+ MHz Alpha laptop, why not a 300MHz version? This ' >would be sufficient for most purposes.   B I'm not sure you can. One of the tricks that are used to get more H performance out of CPUs is to run parts of the inside clockless. Rather F than use an externally or internally generated clock signal, you take H advantage of the fact that electrons will go X nanometers in Y seconds. I Shift the clock speed too much and these unclocked bits get out of sync, dK returning their signals too late or (in this case) too early. It puts both a; an upper and lower limit on how fast a chip can be clocked.   K I don't know if the Alphas do this or not, but if they do then slowing the a chip too much wouldn't work.   					Dan  I --------------------------------------"it's like this"-------------------*2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and evenf;                                       teddy bears get drunke   ------------------------------  % Date: Mon, 12 Jun 2000 22:24:54 -0500I7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>< Subject: Re: VAX on Intel?- Message-ID: <3945A986.FD0E0421@earthlink.net>=   Larry Kilgallen wrote: > j > In article <elkZ4.61$ru5.1966@typhoon.aracnet.com>, "Zane H. Healy" <healyzh@shell1.aracnet.com> writes:L > > In comp.org.decus David J. Dachtera <djesys.nospam@earthlink.net> wrote:F > >> Looks like someone ELSE sees the value/potential of VMS on Intel. > >f6 > >> Wonder what they know that DEC/Compaq doesn't.... > A > They know that they (SRI) are not required to make a profit fori > shareholders ?  4 DAMNIT I'M TIRED OF THESE "SHAREHOLDER" FANTASIES!!!  H Someone tell me something: under EXACTLY what conditions would expandingA the OpenVMS user base harm Compaq's stock price or its investors?g  4 OpenVMS: 450,000 sites.		Compaq stock price: < $40US  4 Micro$hit: 200,000,000+ sites	M$ stock price: > $120  H ...and if the US Dept. of Justice succeeds in breaking up M$ before theyG move to Canada, expect that stock price to more than double, even after - the inevitable drop at the time of the split.|  F So, someone tell me: under EXACTLY what conditions would expanding theB OpenVMS user base harm Compaq's stock price or its investors???!!!  iB > For those who are really concerned about "support", the questionA > would be how much will DEQ charge for a service contract on VMS  > running on an Intel machine.  G Until it's officially certified by the Q, consider it unsupported undert Charon-VAX.i  G I find it interesting that the "Charon" name was chosen. If I'm not toowC badly mistaken, that is the character in Greek mythology who is thesG Ferryman on the River Styx - guides (takes) the dead to the underworld,0= y'know. Strangely prophetic, if true (but hardly unexpected).c   -- C David J. Dachtera- dba DJE SystemsD" http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/w   ------------------------------  % Date: Mon, 12 Jun 2000 15:21:56 -0400h" From: Dan Sugalski <dan@sidhe.org>" Subject: Re: VMS Security features: Message-ID: <4.3.2.7.0.20000612151839.01c33540@24.8.96.48>  1 At 01:51 AM 6/12/00 +0000, Larry Kilgallen wrote: L >In article <Pine.LNX.4.10.10006111819280.736-100000@tuatha.sidhe.org>, Dan ! >Sugalski <dan@sidhe.org> writes:a >wM > > In general, the pages allocated to the stack on VMS aren't executable. IfcN > > you try and execute code on the stack your process will throw an error andC > > die. Memory a process allocates is also generally not marked astJ > > executable, and attempts to execute randomly allocated data will fail. >'@ >I disagree.  The notion of marking something as "executable" toB >distinguish it from "readable" applies to object protection masks, >(e.g., files) but not to memory protection.  J I was under the impression that VMS set the fault-on-execute bit on pages I allocated as data (the stack and memory gotten via the memory allocation sK library and system service routines) so that if execution was attempted it dI threw an error and the process ultimately died. I can't find the docs on u0 that at the moment, so I may be mis-remembering.   					Dan  I --------------------------------------"it's like this"------------------- 2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and even';                                       teddy bears get drunkh   ------------------------------    Date: 12 Jun 2000 16:48:22 -0500 From: briggs@eisner.decus.org " Subject: Re: VMS Security features+ Message-ID: <C$n55XwBdPP6@eisner.decus.org>   _ In article <4.3.2.7.0.20000612151839.01c33540@24.8.96.48>, Dan Sugalski <dan@sidhe.org> writes:y3 > At 01:51 AM 6/12/00 +0000, Larry Kilgallen wrote:?M >>In article <Pine.LNX.4.10.10006111819280.736-100000@tuatha.sidhe.org>, Dan p" >>Sugalski <dan@sidhe.org> writes: >>N >> > In general, the pages allocated to the stack on VMS aren't executable. IfO >> > you try and execute code on the stack your process will throw an error and:D >> > die. Memory a process allocates is also generally not marked asK >> > executable, and attempts to execute randomly allocated data will fail.n >>A >>I disagree.  The notion of marking something as "executable" tooC >>distinguish it from "readable" applies to object protection masksd- >>(e.g., files) but not to memory protection.c > L > I was under the impression that VMS set the fault-on-execute bit on pages K > allocated as data (the stack and memory gotten via the memory allocation .M > library and system service routines) so that if execution was attempted it mK > threw an error and the process ultimately died. I can't find the docs on  2 > that at the moment, so I may be mis-remembering.  ' On VAX, at least, there is no such bit.    A PTE contains:s   Bit 31:     Valid/Invalid O Bit 30-27:  Protection (no access, UR, SR, ER, KR, URSW, UREW, URKW, SREW, etc)A  Bit 26:	    Modified (dirty bit) Bit 25:	    MBZp, Bit 24-23:  Software use:  Owner access mode> Bit 22-21:  Software use:  Copy on reference, Demand zero, etc Bit 20-0:   PFNv  D Hardware need only look at bits 27-31 to arbitrate access to a page.G Whether a read access is for the instruction stream or a data stream isn irrelevant.  On VAX.  ; 	John Briggs                        briggs@eisner.decus.org0   ------------------------------  % Date: Mon, 12 Jun 2000 16:01:40 -0400n" From: Dan Sugalski <dan@sidhe.org>" Subject: Re: VMS Security features: Message-ID: <4.3.2.7.0.20000612155836.01c5d530@24.8.96.48>  9 At 04:48 PM 6/12/00 -0500, briggs@eisner.decus.org wrote:tI >In article <4.3.2.7.0.20000612151839.01c33540@24.8.96.48>, Dan Sugalski h ><dan@sidhe.org> writes:5 > > At 01:51 AM 6/12/00 +0000, Larry Kilgallen wrote:.N > >>In article <Pine.LNX.4.10.10006111819280.736-100000@tuatha.sidhe.org>, Dan$ > >>Sugalski <dan@sidhe.org> writes: > >>B > >> > In general, the pages allocated to the stack on VMS aren't  > executable. IfH > >> > you try and execute code on the stack your process will throw an  > error andoF > >> > die. Memory a process allocates is also generally not marked asM > >> > executable, and attempts to execute randomly allocated data will fail.  > >>C > >>I disagree.  The notion of marking something as "executable" touE > >>distinguish it from "readable" applies to object protection maskso/ > >>(e.g., files) but not to memory protection.e > > M > > I was under the impression that VMS set the fault-on-execute bit on pages L > > allocated as data (the stack and memory gotten via the memory allocationN > > library and system service routines) so that if execution was attempted itL > > threw an error and the process ultimately died. I can't find the docs on4 > > that at the moment, so I may be mis-remembering. >q( >On VAX, at least, there is no such bit.  L Gotcha. I'm unfamiliar with the low-level bits on VAXen, unfortunately. All & my docs are for Alpha. A PTE there is:   bit 61-32: Page frame number bit 31-16: Reservedd  bit 15-8:  USEK read, USEK write bit 7:     Reservedn bit 6-5:   Granularity hintt bit 4:     Address space match( bit 3-1:   Fault on execute, write, read bit 0:     Valid       					Dan  I --------------------------------------"it's like this"-------------------g2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and evene;                                       teddy bears get drunko   ------------------------------  % Date: Mon, 12 Jun 2000 19:24:43 -0400s2 From: "Richard B. Gilbert" <DRAGON@compuserve.com>" Subject: Re: VMS Security features7 Message-ID: <200006121924_MC2-A874-7DD4@compuserve.com>t  J         You should probably start out with the "VAX Architecture Referenc= eeJ Manual".  The VAX Architecture and the VMS Operating System were designed=  F together.  The hardware people and the software people worked togetherJ deciding what should be implemented in hardware and what in software.  Al= soE see "Alpha Architecture Reference Manual".  One of the Alpha's designbD objectives was to make it possible for VMS to run on a RISC machine.  A         Read this in conjunction with "VAX VMS Internals and Datav Structures".  H         Look carefully at: memory protection, the four access modes, andG how a program changes mode to one of the inner access modes.  OperatingsH system code is protected against write access.  Some O/S data structuresJ are even protected against read acess.  Note the FOUR stacks, one for eac= hSJ access mode.   Trashing the user mode stack will trash your program or yo= ur process but not the O/S.  =n    J         Gaining "privilege" is THE VMS "exploit".  With privilege you are=  J limited only by your knowledge and programming ability.  Without it there=   are no "exploits" available.  / Message text written by "David Andreas Alderud"$J >I'm looking for the internals, the other stuff is interesting too, but m= ycJ main interest is in the core OS design. Since most security holes have to=   doF with buffer overruns, I'm really interested in hearing about the stackG design. Or like distributed services, realtime features and filesystem,k etc.J Why I'm I so interested in the technical solutions? Well, I'm doing my M = ScJ thesis this summer, I'm a UNIX hardcore and I know how bad the UNIX desig= niJ is. I'm going to write the paper about how other OSs, that are better fro= my amH security standpoint, does to handle security and why one should use them where security matters.lF If I find the correct material to read, you can probably look at it as% promotion of your favourite platform.i  J Right now, I'm reading up on QNX4 and Neutrino2, they look really good, I= 'd love to take a stab at VMS too.  <n   ------------------------------   End of INFO-VAX 2000.328 ************************