1 INFO-VAX	Sat, 19 Mar 2005	Volume 2005 : Issue 156       Contents: Re: User disk is soon full.... VMS 8.2 for VAX  Re: VMS 8.2 for VAX  Re: VMS 8.2 for VAX  Re: VMS 8.2 for VAX  Re: VMS 8.2 for VAX  Re: [Announce] FreeVMS 0.1.3 Re: [Announce] FreeVMS 0.1.3 Re: [Announce] FreeVMS 0.1.3 Re: [Announce] FreeVMS 0.1.3 Re: [Announce] FreeVMS 0.1.3  F ----------------------------------------------------------------------  % Date: Sat, 19 Mar 2005 09:24:29 -0500 ) From: "Neil Rieck" <n.rieck@sympatico.ca> ' Subject: Re: User disk is soon full.... ; Message-ID: <zCW_d.76360$Jd2.1679307@news20.bellglobal.com>   1 "Pelle Lind" <pelle@mbox.com.au> wrote in message 7 news:966dea01.0503171845.42002504@posting.google.com...  > Hi,  > E > I'm maintaining an old system and previous owners didn't leave much > > information of what they done or how to continue maintenace. > G > 1. What kind of file maintenance should be done? Any special tools to  > run?B > 2. My user disk is filling up rather quickly at the moment and IG > suspect someone is generating lots of data, how can I find that user?  > 
 > Regards, > Pelle   J Assuming that you've got good backups of all your disks, and assuming thisC is about to become an emergency situation, this is what I would do:    $ sh dev d /size=bytes/mounted  L which will return a list of "disk device names" and their free space similar to this:  J KAWC99$DKA0:      Mounted        0         ALPHASYS        2.64GB    582 1F KAWC99$DKA100: Mounted        0         CSMISUSER1   3.14GB        3 1  C now navigate to the root directory of the disk in question like so:   # $set default kawc99$dka100:[000000]   / now begin a purge of all the log files like so:   $ $pur/log/noconfirm/keep=3 [...]*.log  ? later on you may wish to selectively purge other files like so:     $pur/log/confirm/keep=3 [...]*.*  	 * * * * *   D You may also need to clean up the system disk so here are a few goodH starting points before doing anything as radical as a system disk purge:  > open a new operator log file so you can purge the current one:   $set def sys$manager
 $reply/ena
 $reply/log
 $reply/dis $purge/log/noco *.log   J p.s. it might not be a good idea to do a "reply/dis" if you are working at the system console.   L if you are not required to use the accounting file to bill other departmentsL for using resources on your system, then disable accounting (optional), set . a new accounting file, then purge the old one.   $sh acc  $set acc/dis $set acc/new $pur/log/confirm *.dat  I as a last resort, repeat one of the whole disk purging commands above for  the system disk.  	 * * * * *   L If none of the whole-disk purges work, try dropping the keep value until you get results.    
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  + Date: Sat, 19 Mar 2005 13:29:04 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: VMS 8.2 for VAX$ Message-ID: <d1h9f0$v5j$1@online.de>  E Not long ago, the roadmap was to have VMS 8.2 as a public release for F Itanium, ALPHA and VAX.  (8.0 was for internal use only, 8.1 for earlyC adopters---I don't know if (for those in the field) these were just I Itanium or ALPHA as well.)  What is the current plan?  Will there be 8.2  E for VAX?  If not, up to what version of VMS for ALPHA is 7.3 for VAX  E supported in a cluster?  Just 8.2 or all "-x" releases after 8.2 and  H before 8.3?  Can one say anything about 7.3 VAX/8.3 ALPHA at this point  in time?  C If 7.3 is to be the last version of VMS for VAX, has there been an  I official announcement?  If that is the case, does this mean that layered  A products (compilers, TCPIP, DECnet, DECwindows etc) will also be  H "frozen" on VAX?  Will there be at least patches for 7.3 for a while to ! fix any bugs which might show up?    ------------------------------  % Date: Sat, 19 Mar 2005 06:28:13 -0800 # From: "Tom Linden" <tom@kednos.com>  Subject: Re: VMS 8.2 for VAX( Message-ID: <opsnv2hbu4zgicya@hyrrokkin>  K On Sat, 19 Mar 2005 13:29:04 +0000 (UTC), Phillip Helbig---remove CLOTHES   1 to reply <helbig@astro.multiCLOTHESvax.de> wrote:   G > Not long ago, the roadmap was to have VMS 8.2 as a public release for H > Itanium, ALPHA and VAX.  (8.0 was for internal use only, 8.1 for earlyE > adopters---I don't know if (for those in the field) these were just J > Itanium or ALPHA as well.)  What is the current plan?  Will there be 8.2F > for VAX?  If not, up to what version of VMS for ALPHA is 7.3 for VAXF > supported in a cluster?  Just 8.2 or all "-x" releases after 8.2 andI > before 8.3?  Can one say anything about 7.3 VAX/8.3 ALPHA at this point 
 > in time? > D > If 7.3 is to be the last version of VMS for VAX, has there been anJ > official announcement?  If that is the case, does this mean that layeredB > products (compilers, TCPIP, DECnet, DECwindows etc) will also beI > "frozen" on VAX?  Will there be at least patches for 7.3 for a while to # > fix any bugs which might show up?  >   K Hmmm...  I had stored in my mind the notion that 8.2 was the last version    toI be offered for the VAX.  But looking at the link below (slide 8) it says:     H •VAX releases:  The OpenVMS VAX Version 8.2 release is currently underF investigation as we assess customer demand.  OpenVMS VAX will continue  to be supported into the future.    > http://h71000.www7.hp.com/openvms/roadmap/openvms_roadmaps.htm  H That is a change from my recollection.  There is no date on that page or5 others that I checked, but there is a 2005 copyright.    ------------------------------    Date: 19 Mar 2005 16:36:53 +01006 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) Subject: Re: VMS 8.2 for VAX, Message-ID: <423c5525$1@NEWS.LANGSTOEGER.AT>  w In article <d1h9f0$v5j$1@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: F >Not long ago, the roadmap was to have VMS 8.2 as a public release forG >Itanium, ALPHA and VAX.  (8.0 was for internal use only, 8.1 for early 
 >adopters.  + Indeed, that what was I heard/read as well.   D >           I don't know if (for those in the field) these were just >Itanium or ALPHA as well.)   # V8.0 and V8.1 had been Itanic only.   J >                            What is the current plan?  Will there be 8.2 	 >for VAX?   G Last I heard was that they 'are considering' and 'fieldtest this year'. E Thats a change. But noone seems to notice, care or protest or pay ;-) K I think, with the HP changes (like CEO), VMS future is still not that rosy. L So, we hope, that VMS will survive. And if it must be without VAX, so be it.  H >            If not, up to what version of VMS for ALPHA is 7.3 for VAX F >supported in a cluster?  Just 8.2 or all "-x" releases after 8.2 and  >before 8.3?  @ I haven't heard of any V8.2-x releases for OpenVMS Alpha so far.5 Only of OpenVMS I64 V8.2-1 (which means Itanic only).   I >             Can one say anything about 7.3 VAX/8.3 ALPHA at this point  	 >in time?  > D >If 7.3 is to be the last version of VMS for VAX, has there been an  >official announcement?   - I haven't seen an official announcement, yet. = But currently it looks like V8.2 if not V7.3 is the last one.   K >                         If that is the case, does this mean that layered  B >products (compilers, TCPIP, DECnet, DECwindows etc) will also be  >"frozen" on VAX?   E Some products (like TCPIP, MOTIF) are already frozen, or so it seems.   I >                  Will there be at least patches for 7.3 for a while to  " >fix any bugs which might show up?  I Fix bugs, yup. That's what they call officially supported up to mmmhhmmm. K New features, like changes for coexistance with Itanic or Alpha beyond 8.2, J it depends, I guess. If someone is willing to pay, then VMS engineering is willing to deliver, I believe.   --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Sat, 19 Mar 2005 10:48:38 -0500 2 From: "Stanley F. Quayle" <squayle@insight.rr.com> Subject: Re: VMS 8.2 for VAX. Message-ID: <423C0386.16266.4493CE3@localhost>  = On 19 Mar 2005 at 13:29, Phillip Helbig---remove CLOTH wrote:  > Will there be 8.2 for VAX?    D At a Partner's meeting in November, I asked about VAX, since it had D disappeared from the roadmap.  While reluctant to make any official D announcment, several HP people said privately that the only purpose C in having a VAX V8.2 is to keep the major version the same for all  E members in a cluster.  Instead, they're going to change the rules so  0 that V7.3 on VAX is okay with V8.any of Alpha.    F > Can one say anything about 7.3 VAX/8.3 ALPHA at this point in time?    Don't aks about V9 of Alpha....   D > Will there be at least patches for 7.3 for a while to fix any bugs > which might show up?    C I would expect so -- or why would you pay for software maintenance?   A There are some DCL features in V8.x that should be back-ported to ) V7.3.  Maybe that will be possible now...   
 --Stan Quayle  Quayle Consulting Inc.  
 ----------- Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363 3 8572 North Spring Ct., Pickerington, OH  43147  USA 0 stan-at-stanq-dot-com       http://www.stanq.com   ------------------------------  % Date: Sat, 19 Mar 2005 12:13:23 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca> Subject: Re: VMS 8.2 for VAX- Message-ID: <423C5DB3.EE0BEAB2@vaxination.ca>    Tom Linden wrote: J > •VAX releases:  The OpenVMS VAX Version 8.2 release is currently underH > investigation as we assess customer demand.  OpenVMS VAX will continue" > to be supported into the future.  F Considering that at 8.2, VMS on IA64 is still "Unfinished" and that itG won't be before at least 8.3 that feature parity with Alpha will happen D and that VMS will be able to run on more than just a handful of IA648 models, I don't think that 8.2 will be a "landing zone".  G It might be better at this point in time to ask for 8.3 to be ported to D VAX. Consider all the neat DCL features Guy Peleg has done since theG last vax version came out,  it woudl be nice to have them onto VAX VMS.    ------------------------------   Date: 19 Mar 2005 14:07:40 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)% Subject: Re: [Announce] FreeVMS 0.1.3 , Message-ID: <3a2q1cF64cbu8U1@individual.net>  3 In article <aaA98OreXGZ2@eisner.encompasserve.org>, 0 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:O > In article <XMJ_d.4266$uw6.4216@trnddc06>, John Santos <john@egh.com> writes:  > ? >> This is where C loses.  To write safe code in C, you have to D >> bounds-check everything, and verify all string and buffer lengths >> and do it religiously.  >>  H >> If all your code is reviewed and you always parameterize *everything*F >> (so e.g. when someone changes the maximum size of a variable, everyE >> thing uses the correct new size automatically) and you have a good E >> version control system so everything gets recompiled when it needs @ >> to be, and your subroutines are all prepared to deal with theE >> memory faults they might get when someone passes a null-terminated E >> string and forgets to add the null at the end, etc. etc., then you E >> can use C safely.  But isn't it easier to use a language that does C >> this for you and never forgets to check something, "because it's B >> just a little 1-byte local temp string and what can possibly go
 >> wrong?" > E > Ultimately, the problem is how does one _prove_ that all the proper ' > steps were taken in a giant program ?  > I > Looking at a not-so-giant program, when DEC wrote an A1 Security Kernel E > for the high-end VAX, they wrote it in Pascal, with no RTL allowed, = > in order to support mathematical proof of code correctness.   F And, did the code reviews include looking at the source for the PascalF compiler as well?  If not, then you had no "mathematical proof of codeE correctness".  Some things can not be "proven" to any real degree off 
 certainty.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 19 Mar 2005 14:23:45 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)% Subject: Re: [Announce] FreeVMS 0.1.3 , Message-ID: <3a2qvhF64cbu8U2@individual.net>  ( In article <opsnu79dd6zgicya@hyrrokkin>,& 	"Tom Linden" <tom@kednos.com> writes:L > On 18 Mar 2005 22:06:39 -0500, Rob Brooks <brooks@cuebid.zko.dec.nospam>   > wrote: >  >> Larry Kilgallen wrote:  >>H >>> VMS would be better off if more of it were written in Bliss and lessI >>> in Macro, but that is not what compiler availability permitted.  Note H >>> that VAX Bliss never _did_ get a WFIKPC (Wait for Interrupt and Keep >>> Channel) linkage.  >>J >> This topic is, uh, topical.  Several of us in VMS Engineering were justK >> lamenting the fact that the "founding fathers" did not choose BLISS over H >> MACRO-32 as the language of choice for most of the kernel of VAX/VMS. >>J >> If BLISS had been used wherever possible, the ports to both Alpha and   >> I64 would& >> have taken substantially less time. >>L >> The increased use of C within OpenVMS Alpha did greatly reduce the time   >> and >> effort to port to I64.  >>H > Ah, what might have been.  Had you written it in PL/I, instead of 30  	 > Million L > or so lines of code, it would only have been 10 Million.  I have seen manyJ > examples of projects in the last 40 years where a seemlingly innocuous  
 > decisionM > at some point in time had repercussions that lasted long afterwards.  The    > key toF > writing successful code is to choose the highest level abstraction  
 > appropriate K > to the problem to be addressed.  Macro is too low, bliss is too low and   
 > likewiseJ > C.  Obviously it can be done, as demonstrated, but the cost is too high,M > maintainability is too arduous and extensibility is a challenge.  It is a    > far N > better paradigm to choose a language like PL/I or Ada for that matter, and   > put inK > the extensions need to obviate the need to use assembler,  that is what   	 > IBM did J > with PLS  ans PL8.  Burroughs wrote there OS in Algol, that would have   > been another > good choice.  = I was wondering when Algol would turn in up in these frequent B arguments^H^H^H^H^H^H^H^H^Hdiscussions about "the right language".@ I just assumed I was the only one old enough to remember it. :-)@ (My daughter used to say, "When my mom was young she played with? Barbies.  When my dad was young he played with dinosaurs."  She  didn't mean toys.)   @ Personally, if we are going to talk about older languages with a? long history, I would have to agree with Tom that PL/I would be A the best for doing systems programming.  It has proven it's worth ? many time over.  I often wonder why C was created to write Unix A instead of just using PL/I.  But I would guiess it had more to do 7 with politics or copyright issues than technical merit.    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Sat, 19 Mar 2005 07:11:49 -0800 # From: "Tom Linden" <tom@kednos.com> % Subject: Re: [Announce] FreeVMS 0.1.3 ( Message-ID: <opsnv4hzn6zgicya@hyrrokkin>  F On 19 Mar 2005 14:07:40 GMT, Bill Gunshannon <bill@cs.uofs.edu> wrote:  5 > In article <aaA98OreXGZ2@eisner.encompasserve.org>, 2 > 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:J >> In article <XMJ_d.4266$uw6.4216@trnddc06>, John Santos <john@egh.com>  
 >> writes: >>@ >>> This is where C loses.  To write safe code in C, you have toE >>> bounds-check everything, and verify all string and buffer lengths  >>> and do it religiously. >>> I >>> If all your code is reviewed and you always parameterize *everything* G >>> (so e.g. when someone changes the maximum size of a variable, every F >>> thing uses the correct new size automatically) and you have a goodF >>> version control system so everything gets recompiled when it needsA >>> to be, and your subroutines are all prepared to deal with the F >>> memory faults they might get when someone passes a null-terminatedF >>> string and forgets to add the null at the end, etc. etc., then youF >>> can use C safely.  But isn't it easier to use a language that doesD >>> this for you and never forgets to check something, "because it'sC >>> just a little 1-byte local temp string and what can possibly go  >>> wrong?"  >>F >> Ultimately, the problem is how does one _prove_ that all the proper( >> steps were taken in a giant program ? >>J >> Looking at a not-so-giant program, when DEC wrote an A1 Security KernelF >> for the high-end VAX, they wrote it in Pascal, with no RTL allowed,> >> in order to support mathematical proof of code correctness. > H > And, did the code reviews include looking at the source for the PascalH > compiler as well?  If not, then you had no "mathematical proof of codeG > correctness".  Some things can not be "proven" to any real degree off  > certainty.  A There is still the Trojan horse issue as we have discussed before 3 http://www.acm.org/classics/sep95/  by Ken Thompson  >  > bill >    ------------------------------  % Date: Sat, 19 Mar 2005 07:16:37 -0800 # From: "Tom Linden" <tom@kednos.com> % Subject: Re: [Announce] FreeVMS 0.1.3 ( Message-ID: <opsnv4pzxpzgicya@hyrrokkin>  F On 19 Mar 2005 14:07:40 GMT, Bill Gunshannon <bill@cs.uofs.edu> wrote:  H > And, did the code reviews include looking at the source for the PascalH > compiler as well?  If not, then you had no "mathematical proof of codeG > correctness".  Some things can not be "proven" to any real degree off  > certainty.   Follow on story.  S http://www.dmst.aueb.gr/dds/pubs/jrnl/2003-CACM-Reflections2/html/reflections2.html    ------------------------------   Date: 19 Mar 2005 16:50:26 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)% Subject: Re: [Announce] FreeVMS 0.1.3 , Message-ID: <3a33iiF5vtd52U1@individual.net>  ( In article <opsnv4hzn6zgicya@hyrrokkin>,& 	"Tom Linden" <tom@kednos.com> writes:H > On 19 Mar 2005 14:07:40 GMT, Bill Gunshannon <bill@cs.uofs.edu> wrote: > 6 >> In article <aaA98OreXGZ2@eisner.encompasserve.org>,3 >> 	Kilgallen@SpamCop.net (Larry Kilgallen) writes: K >>> In article <XMJ_d.4266$uw6.4216@trnddc06>, John Santos <john@egh.com>    >>> writes:  >>> A >>>> This is where C loses.  To write safe code in C, you have to F >>>> bounds-check everything, and verify all string and buffer lengths >>>> and do it religiously.  >>>>J >>>> If all your code is reviewed and you always parameterize *everything*H >>>> (so e.g. when someone changes the maximum size of a variable, everyG >>>> thing uses the correct new size automatically) and you have a good G >>>> version control system so everything gets recompiled when it needs B >>>> to be, and your subroutines are all prepared to deal with theG >>>> memory faults they might get when someone passes a null-terminated G >>>> string and forgets to add the null at the end, etc. etc., then you G >>>> can use C safely.  But isn't it easier to use a language that does E >>>> this for you and never forgets to check something, "because it's D >>>> just a little 1-byte local temp string and what can possibly go >>>> wrong?" >>> G >>> Ultimately, the problem is how does one _prove_ that all the proper ) >>> steps were taken in a giant program ?  >>> K >>> Looking at a not-so-giant program, when DEC wrote an A1 Security Kernel G >>> for the high-end VAX, they wrote it in Pascal, with no RTL allowed, ? >>> in order to support mathematical proof of code correctness.  >>I >> And, did the code reviews include looking at the source for the Pascal I >> compiler as well?  If not, then you had no "mathematical proof of code H >> correctness".  Some things can not be "proven" to any real degree off
 >> certainty.  > C > There is still the Trojan horse issue as we have discussed before 5 > http://www.acm.org/classics/sep95/  by Ken Thompson   < That has already been mentioned here inthe recent past but I; also meant it is possible for the compiler to make mistakes < too.  And the more complex the language the more possible it= becomes for an error to sit silently by waiting for the right / combination of code to bring it to the surface.    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   End of INFO-VAX 2005.156 ************************