1 INFO-VAX	Wed, 07 Jun 2006	Volume 2006 : Issue 314       Contents: Re: DCL: IF   and .AND.  logic/ Re: SA 5300A, changing system disk breaks ACUXE  Re: Unix runs faster, maybe  RE: Unix runs faster, maybe  Re: Unix runs faster, maybe  Re: Unix runs faster, maybe  Re: Unix runs faster, maybe  Re: Unix runs faster, maybe  Re: Unix runs faster, maybe  Re: Unix runs faster, maybe  Re: Unix runs faster, maybe D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D RE: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)D Re: Unix runs faster, maybe (was: Re: Educating potential VMS users)( Re: Wanted:MAIL.MAI structure definition( Re: Wanted:MAIL.MAI structure definition( Re: Wanted:MAIL.MAI structure definition( Re: Wanted:MAIL.MAI structure definition( Re: Wanted:MAIL.MAI structure definition( Re: Wanted:MAIL.MAI structure definition( Re: Wanted:MAIL.MAI structure definition( Re: Wanted:MAIL.MAI structure definition( Re: Wanted:MAIL.MAI structure definition  F ----------------------------------------------------------------------  % Date: Tue, 06 Jun 2006 20:59:49 -0500 6 From: "David J. Dachtera" <djesys.no@spam.comcast.net>' Subject: Re: DCL: IF   and .AND.  logic 0 Message-ID: <44863315.EFCEAFC1@spam.comcast.net>   JF Mezei wrote:  >  > $A = 2 > $B = 3H > $ IF (A .AND. B) THEN WRITE SYS$OUTPUT "Chocolate"    ! writes nothing > Q > $ IF (A .AND. B) .ne. 0 then WRITE SYS$OUTPUT "Rasberry"    ! writes "Rasberry"   7 $ IF .NOT. (A .AND. B) then WRITE SYS$OUTPUT "Rasberry"    ...will do the same.   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------   Date: 6 Jun 2006 11:17:29 -0700 ( From: "Rich Jordan" <jordan@ccs4vms.com>8 Subject: Re: SA 5300A, changing system disk breaks ACUXEC Message-ID: <1149617849.266136.234510@c74g2000cwc.googlegroups.com>   G Still no go on getting ACUXE running again.  I've deinstalled it, WBEM, C removed the SNMP configuration and rebuilt it, reinstalled WBEM and C ACUXE, still get the same access violation when trying to run ACUXE C although WBEM works fine.  When I boot the spare disk on DKA0: (the ? drive the raid-located system disk was copied from) ACUXE works 
 perfectly.  C There are no remaining references to DKAx on the raid drive.  Since F this is a 'used' system (albeit with new licenses) I don't have accessE to support for the product.  Any ideas on where to go from here short 3 of a full VMS rebuild would be greatly appreciated.    Rich   ------------------------------  % Date: Tue, 06 Jun 2006 14:18:19 -0600  From: Kevin Handy <kth@srv.net> $ Subject: Re: Unix runs faster, maybe3 Message-ID: <1149623851_39515@sp6iad.superfeed.net>    Dave Froble wrote:  F > If VMS ran on only itanic, and Unix also ran only on itanic, do you F > truly feel that Unix would enjoy such greater numbers of users?  No C > bullshitting around, just answer the question as it's posed.  No  B > bullshit about the real world as a way of avoiding the question. >     @ Which would you choose? Based on perceptions and facts, known to the intended users/purchasers:  D 1. VMS: A $1400 per cpu OS license for a system few people have evenD     heard of, (more $$$ if you don't want to use obsolete version ofB     the hardware), which gives you a single user license with some>     network capabilities (make sure you don't lose the licenseA     paperwork), few user/developer programs included. There is an ?     extra cost $$$ for more users, programming languages, etc.. >     Some additional programs (most of which are ports from the6     other OS) available on the internet, but expect to8     tinker with them a lot to get them to work properly.A     Expect to may more $$$ if you decide to upgrade the hardware. A     No advertisements, except a few odd ones in obscure journals.   E 2. Linux: A $10 per site OS (cost of a CD dist) with unlimited users, >     full networking capabilities, no licensing hassels (unless>     you want to deal with SCO), numerous programming languagesB     and user programs included, source code freely available, withC     a very active, well known, and vocal user/developer base. It is 8     considered to be as secure as #1 by its users. It is3     periodically advertised on TV and in magazines.   2 These perceptions are just the tip of the iceberg.  = If you were a department on a limited budget, which would you < choose? Which one would give you the most bang for the buck:= a $1400+ (per cpu) with no applications, or a $10 (toal cost) & system with thousands of applications?  Q ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- S http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups K ----= East and West-Coast Server Farms - Total Privacy via Encryption =----    ------------------------------  $ Date: Tue, 6 Jun 2006 17:17:34 -0400' From: "Main, Kerry" <Kerry.Main@hp.com> $ Subject: RE: Unix runs faster, maybeT Message-ID: <FA60F2C4B72A584DBFC6091F6A2B86840150AE3D@tayexc19.americas.cpqcorp.net>   > -----Original Message-----+ > From: Kevin Handy [mailto:kth@srv.net]=20  > Sent: June 6, 2006 4:18 PM > To: Info-VAX@Mvb.Saic.Com & > Subject: Re: Unix runs faster, maybe >=20 > Dave Froble wrote: >=20J > > If VMS ran on only itanic, and Unix also ran only on itanic, do you=20J > > truly feel that Unix would enjoy such greater numbers of users?  No=20G > > bullshitting around, just answer the question as it's posed.  No=20 D > > bullshit about the real world as a way of avoiding the question. > >=20 >=20 >=20B > Which would you choose? Based on perceptions and facts, known to  > the intended users/purchasers: >=20F > 1. VMS: A $1400 per cpu OS license for a system few people have evenF >     heard of, (more $$$ if you don't want to use obsolete version ofD >     the hardware), which gives you a single user license with some@ >     network capabilities (make sure you don't lose the licenseC >     paperwork), few user/developer programs included. There is an A >     extra cost $$$ for more users, programming languages, etc.. @ >     Some additional programs (most of which are ports from the8 >     other OS) available on the internet, but expect to: >     tinker with them a lot to get them to work properly.C >     Expect to may more $$$ if you decide to upgrade the hardware. C >     No advertisements, except a few odd ones in obscure journals.  >=20  > Lets compare apples to apples .. I am not saying there are not6 differences, but you need to get a few facts straight.  : - OpenVMS hobbyist license =3D less than $100 (media kit).C - OpenVMS base OS on IA64 includes unlimited users, full networking  capability. B - IA64 servers to keep + full 3 day dev workshop are available for USD$2K. F - number of OpenVMS securiity patches per year =3D less than number ofF fingers on 1 hand. Linux security patches are released at approx 10-20H *per month*. For Prod shops that test OS/security patches impact on prodE applications before releasing, this is huge, huge impact. Check RH we  site: E https://www.redhat.com/archives/enterprise-watch-list/ (click on each  month). D - For Linux users that say their OS is secure, ask them if they haveF verified and/or installed all the security patches that are applicableH to their environment. Keep in mind that a number of these patch headingsE are bundled patches and do not fully describe all that they do in the  heading.C - OpenVMS app's on IA64 can be found at: (more cooking as we speak) F http://h71000.www7.hp.com/solutions/matrix/i64partner_A.html (click on  each letter for various vendors)    G > 2. Linux: A $10 per site OS (cost of a CD dist) with unlimited users, @ >     full networking capabilities, no licensing hassels (unless@ >     you want to deal with SCO), numerous programming languagesD >     and user programs included, source code freely available, withE >     a very active, well known, and vocal user/developer base. It is : >     considered to be as secure as #1 by its users. It is5 >     periodically advertised on TV and in magazines.  >=204 > These perceptions are just the tip of the iceberg. >=20  & And a very "coloured iceberg" at that.  ? > If you were a department on a limited budget, which would you > > choose? Which one would give you the most bang for the buck:? > a $1400+ (per cpu) with no applications, or a $10 (toal cost) ( > system with thousands of applications? >=20* > ----=3D=3D Posted via Newsfeeds.Com -=205 > Unlimited-Unrestricted-Secure Usenet News=3D=3D---- = > http://www.newsfeeds.com The #1 Newsgroup Service in the=20  > World! 120,000+ NewsgroupsA > ----=3D East and West-Coast Server Farms - Total Privacy via=20  > Encryption =3D---- >=20   ------------------------------  % Date: Tue, 06 Jun 2006 17:43:58 -0400 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>$ Subject: Re: Unix runs faster, maybe- Message-ID: <4485F710.E6342878@vaxination.ca>    "Main, Kerry" wrote:F > - number of OpenVMS securiity patches per year = less than number of > fingers on 1 hand.  B Don't brag about this. This can be spun into the image that VMS isI lethargic and that there is nobody ensuring that no patches are required.   H At least with Linux, when a generic vulnerability has been found, I knowD to expect a patch to be issued if it affects the Linux version. WithD VMS, there is no way to know if bno patch is needed ir whether there9 have not been any resources allocated to even study this.   G Or does it take a number of paying customers to make formal requests to H HP to allocate resources to confirm whether the VMS version of some Unix software requires patching ?      6 > > These perceptions are just the tip of the iceberg. > >  > ( > And a very "coloured iceberg" at that.   Perceptions are very important.    ------------------------------  % Date: Tue, 06 Jun 2006 18:58:44 -0400 - From: bradhamilton <bradhamilton@comcast.net> $ Subject: Re: Unix runs faster, maybe* Message-ID: <448608A4.5060203@comcast.net>   Main, Kerry wrote: [...] G >> 1. VMS: A $1400 per cpu OS license for a system few people have even G >>     heard of, (more $$$ if you don't want to use obsolete version of E >>     the hardware), which gives you a single user license with some A >>     network capabilities (make sure you don't lose the license D >>     paperwork), few user/developer programs included. There is anB >>     extra cost $$$ for more users, programming languages, etc..A >>     Some additional programs (most of which are ports from the 9 >>     other OS) available on the internet, but expect to ; >>     tinker with them a lot to get them to work properly. D >>     Expect to may more $$$ if you decide to upgrade the hardware.D >>     No advertisements, except a few odd ones in obscure journals. >> > @ > Lets compare apples to apples .. I am not saying there are not8 > differences, but you need to get a few facts straight.   OK - let's...	:-)   : > - OpenVMS hobbyist license = less than $100 (media kit).  G But you can't run a business (or even develop a business app) with the  K hobbyist license!  Looks as though you forgot this (very important) fact...    [...]   H >> 2. Linux: A $10 per site OS (cost of a CD dist) with unlimited users,A >>     full networking capabilities, no licensing hassels (unless A >>     you want to deal with SCO), numerous programming languages E >>     and user programs included, source code freely available, with F >>     a very active, well known, and vocal user/developer base. It is; >>     considered to be as secure as #1 by its users. It is 6 >>     periodically advertised on TV and in magazines.  E Hmmmm...$10 for a platform on which you can develop an app, and then  F make money on it, vs. ~$30 (for the media alone, plus another $XX for H the Encompass membership) for a platform which you can't develop or run # a money-making app.  Hard choice...   H I'm not saying VMS has its advantages - but initial cost of acquisition  is not of one of them.   [...]    ------------------------------  # Date: Wed, 07 Jun 2006 00:55:59 GMT + From: "Villy Madsen" <Villy.Madsen@shaw.ca> $ Subject: Re: Unix runs faster, maybe, Message-ID: <zuphg.248645$7a.55035@pd7tw1no>   Another thought   L on VMS - you have to go out of your way to write an application that will be' vulnerable to a buffer overflow attack.   H on *ix - you really have to know what you are doing in order to write anI application that isn't vulnerable to a buffer overflow. (then there is of H course RDB & Oracle which I understand actually uses self modifying code (double gag!))  E I at one time would say that it isn't even possible to write a buffer K overflow vulnerable application on OS/400, but I don't know how far the *ix " virus has invaded that platform...       Villy      > OK - more importantly  > ) > How many identified vulnerabilities ???  > 8 > many vulnerabilities - few patches  ==> a BAAAAD thing > 8 > many vulnerabilities - man patches =====> lots of work >  > B > few vulnerabilities & few patches ====> I can sleep at night.... >  > L > It's interesting, one of the few VAX "vulnerabilities" that I can remember > was a SNMP problem.  > < > On *ix the problem resulted in people taking over systems. > J > on VMS the SNMP server crashed (and was automatically restarted by VMS). > L > Similar issues with OS/400 (or whatever it's called these days) - not muchF > in the way of vulnerabilities - and therefore not much in the way of
 > patches. > K > It also seems to me that a significant # of the problems that did develop  > were as a resultE > of things that were ported from *ix. (TCPIP on VMS), Apache on both  > platforms. > G > Having said that - I do believe that part of the problem has been the J > historically high cost of ownership of both of these quite excellent (inJ > their own way) platforms- and I speak from the view point of someone whoI > spent over 20 years supporting VMS and supported OS/400 from just about  its   > birth until about 3 years ago. > D > Lifetime cost of ownership may be a lot lower  than people realize (because> > OS maintenance (your people costs) are so much lower for the aforementionedE > platforms, but that doesn't seem to be as important as the one time  hit.. - J > and the arguably high cost of the year to year manufacturer maintenance. > K > I never worked *ix support -- not my cup of tea at all.  Yes it's getting K > better, but you still don't know what a -I or a -i will do.  I'm not case B > sensitive either so that makes me a cripple as far as *ix & C is > concerned....  >  > Villy  >  >  >  > = > "JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message ) > news:4485F710.E6342878@vaxination.ca...  > > "Main, Kerry" wrote:J > > > - number of OpenVMS securiity patches per year = less than number of > > > fingers on 1 hand. > > F > > Don't brag about this. This can be spun into the image that VMS isC > > lethargic and that there is nobody ensuring that no patches are 	 required.  > > L > > At least with Linux, when a generic vulnerability has been found, I knowH > > to expect a patch to be issued if it affects the Linux version. WithH > > VMS, there is no way to know if bno patch is needed ir whether there= > > have not been any resources allocated to even study this.  > > K > > Or does it take a number of paying customers to make formal requests to L > > HP to allocate resources to confirm whether the VMS version of some Unix  > > software requires patching ? > >  > >  > > : > > > > These perceptions are just the tip of the iceberg. > > > >  > > > , > > > And a very "coloured iceberg" at that. > > # > > Perceptions are very important.  >  >    ------------------------------  # Date: Wed, 07 Jun 2006 00:47:58 GMT + From: "Villy Madsen" <Villy.Madsen@shaw.ca> $ Subject: Re: Unix runs faster, maybe. Message-ID: <2nphg.249213$P01.202024@pd7tw3no>   OK - more importantly   ' How many identified vulnerabilities ???   6 many vulnerabilities - few patches  ==> a BAAAAD thing  6 many vulnerabilities - man patches =====> lots of work    @ few vulnerabilities & few patches ====> I can sleep at night....    J It's interesting, one of the few VAX "vulnerabilities" that I can remember was a SNMP problem.   : On *ix the problem resulted in people taking over systems.  H on VMS the SNMP server crashed (and was automatically restarted by VMS).  J Similar issues with OS/400 (or whatever it's called these days) - not muchD in the way of vulnerabilities - and therefore not much in the way of patches.  I It also seems to me that a significant # of the problems that did develop  were as a resultC of things that were ported from *ix. (TCPIP on VMS), Apache on both 
 platforms.  E Having said that - I do believe that part of the problem has been the H historically high cost of ownership of both of these quite excellent (inH their own way) platforms- and I speak from the view point of someone whoK spent over 20 years supporting VMS and supported OS/400 from just about its  birth until about 3 years ago.  K Lifetime cost of ownership may be a lot lower  than people realize (because K OS maintenance (your people costs) are so much lower for the aforementioned K platforms, but that doesn't seem to be as important as the one time hit.. - H and the arguably high cost of the year to year manufacturer maintenance.  I I never worked *ix support -- not my cup of tea at all.  Yes it's getting I better, but you still don't know what a -I or a -i will do.  I'm not case @ sensitive either so that makes me a cripple as far as *ix & C is
 concerned....    Villy         ; "JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message ' news:4485F710.E6342878@vaxination.ca...  > "Main, Kerry" wrote:H > > - number of OpenVMS securiity patches per year = less than number of > > fingers on 1 hand. > D > Don't brag about this. This can be spun into the image that VMS isK > lethargic and that there is nobody ensuring that no patches are required.  > J > At least with Linux, when a generic vulnerability has been found, I knowF > to expect a patch to be issued if it affects the Linux version. WithF > VMS, there is no way to know if bno patch is needed ir whether there; > have not been any resources allocated to even study this.  > I > Or does it take a number of paying customers to make formal requests to J > HP to allocate resources to confirm whether the VMS version of some Unix > software requires patching ? >  >  > 8 > > > These perceptions are just the tip of the iceberg. > > >  > > * > > And a very "coloured iceberg" at that. > ! > Perceptions are very important.    ------------------------------  % Date: Tue, 06 Jun 2006 21:24:10 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> $ Subject: Re: Unix runs faster, maybe, Message-ID: <44862A9D.A7FDC60E@teksavvy.com>   Villy Madsen wrote:  >  > Another thought  > N > on VMS - you have to go out of your way to write an application that will be) > vulnerable to a buffer overflow attack.   ( Buffer overflow is not the only problem.  F Consider the POP server on VMS. It was loaded with SYSPRV. And someoneC found out long after it was distributied to many customers that any G unprovileged user could defined the pop server as a foreign command and G invoke it with a log file speficication. The application, given SYSPRV, F was able to create a logfile ANYWHERE on the system, allowing any user0 to essentially overwrite any file on the system.  D A patch was not issued as I recall. Just a suggestion to temporarilyH disable SYSPRV from the pop server image until the new version came out.    B Remember that many apps in the TCPIP stack are installed with very powerful privileges.   ------------------------------  # Date: Wed, 07 Jun 2006 01:42:34 GMT , From: "Villy Madsen" <Villy .madsen@shaw.ca>$ Subject: Re: Unix runs faster, maybe, Message-ID: <eaqhg.248966$7a.67380@pd7tw1no>  . Yes the TCPIP under VMS products have problems   guess where it came from.....   K (they couldn't even convert the time and date stuff to use the standard VMS I datetime - I wonder if that has been fixed, or whether the whole shooting / match will croak - in what 2014 or something..)    Villy   : "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message& news:44862A9D.A7FDC60E@teksavvy.com... > Villy Madsen wrote:  > >  > > Another thought  > > H > > on VMS - you have to go out of your way to write an application that will be + > > vulnerable to a buffer overflow attack.  > * > Buffer overflow is not the only problem. > H > Consider the POP server on VMS. It was loaded with SYSPRV. And someoneE > found out long after it was distributied to many customers that any I > unprovileged user could defined the pop server as a foreign command and I > invoke it with a log file speficication. The application, given SYSPRV, H > was able to create a logfile ANYWHERE on the system, allowing any user2 > to essentially overwrite any file on the system. > F > A patch was not issued as I recall. Just a suggestion to temporarilyJ > disable SYSPRV from the pop server image until the new version came out. >  > D > Remember that many apps in the TCPIP stack are installed with very > powerful privileges.   ------------------------------  % Date: Wed, 07 Jun 2006 01:33:29 -0400 ' From: Dave Froble <davef@tsoft-inc.com> $ Subject: Re: Unix runs faster, maybe9 Message-ID: <C66dnT0uFJiJ-RvZnZ2dnUVZ_rKdnZ2d@libcom.com>    Main, Kerry wrote: >> -----Original Message----- * >> From: Kevin Handy [mailto:kth@srv.net]  >> Sent: June 6, 2006 4:18 PM  >> To: Info-VAX@Mvb.Saic.Com' >> Subject: Re: Unix runs faster, maybe  >> >> Dave Froble wrote:  >>H >>> If VMS ran on only itanic, and Unix also ran only on itanic, do you H >>> truly feel that Unix would enjoy such greater numbers of users?  No E >>> bullshitting around, just answer the question as it's posed.  No  D >>> bullshit about the real world as a way of avoiding the question. >>>  >>C >> Which would you choose? Based on perceptions and facts, known to ! >> the intended users/purchasers:   < First, if Unix only ran on a single platform, not x86, then:  & 1) There never would have been a Linux+ 2) There would not be a hugh Unix user base 2 3) There would not be a hugh Unix application base .  .  .   D Seems like another who choose to not understand the question, or to  answer it as asked.   G >> 1. VMS: A $1400 per cpu OS license for a system few people have even G >>     heard of, (more $$$ if you don't want to use obsolete version of E >>     the hardware), which gives you a single user license with some A >>     network capabilities (make sure you don't lose the license D >>     paperwork), few user/developer programs included. There is anB >>     extra cost $$$ for more users, programming languages, etc..A >>     Some additional programs (most of which are ports from the 9 >>     other OS) available on the internet, but expect to ; >>     tinker with them a lot to get them to work properly. D >>     Expect to may more $$$ if you decide to upgrade the hardware.D >>     No advertisements, except a few odd ones in obscure journals. >> > @ > Lets compare apples to apples .. I am not saying there are not8 > differences, but you need to get a few facts straight. > : > - OpenVMS hobbyist license = less than $100 (media kit).   Meaningless for commercial use.   E > - OpenVMS base OS on IA64 includes unlimited users, full networking 
 > capability. D > - IA64 servers to keep + full 3 day dev workshop are available for	 > USD$2K. F > - number of OpenVMS securiity patches per year = less than number ofH > fingers on 1 hand. Linux security patches are released at approx 10-20J > *per month*. For Prod shops that test OS/security patches impact on prodG > applications before releasing, this is huge, huge impact. Check RH we  > site:   F Once the statement "considered to be as secure as #1 by its users" is I made, then you can assume that such people will not consider vetting any   patches.  G > https://www.redhat.com/archives/enterprise-watch-list/ (click on each 	 > month). F > - For Linux users that say their OS is secure, ask them if they haveH > verified and/or installed all the security patches that are applicableJ > to their environment. Keep in mind that a number of these patch headingsG > are bundled patches and do not fully describe all that they do in the 
 > heading.E > - OpenVMS app's on IA64 can be found at: (more cooking as we speak) H > http://h71000.www7.hp.com/solutions/matrix/i64partner_A.html (click on" > each letter for various vendors) >  > H >> 2. Linux: A $10 per site OS (cost of a CD dist) with unlimited users,A >>     full networking capabilities, no licensing hassels (unless A >>     you want to deal with SCO), numerous programming languages E >>     and user programs included, source code freely available, with F >>     a very active, well known, and vocal user/developer base. It is; >>     considered to be as secure as #1 by its users. It is 6 >>     periodically advertised on TV and in magazines. >>5 >> These perceptions are just the tip of the iceberg.  >> > ( > And a very "coloured iceberg" at that.   Rainbow!  @ >> If you were a department on a limited budget, which would you? >> choose? Which one would give you the most bang for the buck: @ >> a $1400+ (per cpu) with no applications, or a $10 (toal cost)) >> system with thousands of applications?  >>% >> ----== Posted via Newsfeeds.Com -  2 >> Unlimited-Unrestricted-Secure Usenet News==----< >> http://www.newsfeeds.com The #1 Newsgroup Service in the  >> World! 120,000+ Newsgroups > >> ----= East and West-Coast Server Farms - Total Privacy via  >> Encryption =----  >>     --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Tue, 06 Jun 2006 14:00:24 -0400  From: BobH <bobh@x.y> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) & Message-ID: <Sojhg.24$pa4.20@fe02.lga>   Bill Todd wrote: > Main, Kerry wrote: ... F >> The environments I am talking about in the majority of Windows/UNIXG >> servers today are not CPU lite, but disk IO heavy. They are just not 6 >> utilized that much at all in peak periods - period. >  > I > That's what I just suggested, Kerry:  they're limited by disk I/O, not  F > CPU, and hence CPU utilization *will* be low, even if the disks are ! > working their little tails off.  > K > And any file system optimizations that will reduce the load on the disks  F > (as Unix's do far better by default than VMS does) *will* be useful. >  >>I >> Part of this might be attributed to the one-app, one server philosophy K >> as repeated refreshes makes for a much faster server at lower costs, but @ >> if the workload does not increase that much, then the overallJ >> utilization goes down. Multiply this by hundreds of x86 servers in manyF >> environments and you have one of the basic reasons why CIO's are so. >> concerned about their Windows environments. >  > J > Yadda, yadda, yadda:  so what?  This has nothing to do with the subject ! > at hand, as I already observed.  >  > ...  > G >> And btw, a server with low cpu utilization, but heavy IO makes for a % >> poor candidate for virtualization.  >  > I > But since you seem to insist on this digression:  horseshit.  A server  J > with very low CPU utilization is a *good* candidate for virtualization, C > since it's got lots of horsepower left over for other tasks that  K > (especially in Windows environments) admins might be reluctant to run on  K > the same OS instance:  just hook up some more disks to service the added  ! > application(s) and let 'er rip.  > $ >  Remember that virtualization adds > 7 >> another level of overhead for both IO and CPU loads.  >  > I > As far as disk I/O goes, horseshit again:  the CPU overhead, even with  J > virtualization added, is a relatively small component of the latency in J > a disk access, and since you've already posited that the CPU has cycles E > to burn, the added CPU overhead of virtualization is not a problem.  >  > - bill  I I don't follow the analysis above.  If you have a server that is running  I heavy I/O, light CPU work, then it certainly could handle additional CPU  A heavy work, be it in a "virtualized" configuration, or under one  G instance of the OS.  Doing it under seperate instances of the O/S is a  I symptom of an O/S that is not well suited to the traditional server role  A (Windows is not so good, VMS and, I am told UNIX, are better for  3 example),  But I don't understand the I/O analysis.   F I think the question was stated in terms of adding more of that heavy I I/O work to a server that already has heavy on I/O.  Number of disks and  H latency are interesting parts of that analysis, but total I/O bandwidth I seems to me to be the limiting issue.  Any given computer has a limit on  I its available I/O bandwidth.  Things like the bandwidth of the paths the  F I/O travels over, particularly on the backplane or on the motherboard G and its chips, including memory.  Only so many bits can be Ied and Oed  E in a given amount of time by a particular hardware design.  If those  H limits did not exist then even a very modest computer could do a nearly F unlimited amount of I/O by just hanging more and more disks off of it.  H By definition the question was a server that was already heavily loaded G on the I/O side.  That says it is already pushing the I/O capabilities  @ of the system.  Adding more of that kind of work will result in E performance problems since there will not be enough I/O to go around.   I The performance analysis here is no different in the multiple apps under  I one O/S instance and the multiple virtualized O/Ss case (other than that  H extra overhead that is added at the virtualization level in that case). G   The fundamental limitations remain the total available I/O bandwidth  G the machine can provide and/or the total CPU if you do get a case with   CPU intensive apps.   D Besides issues with the O/S, perhaps that is a reason for all those G single app servers.  For the workloads in question perhaps the typical  H PC server hardware may not have an adequate balance between CPU and I/O = capacities.  Wasn't that the fundamental distinction between  F minicomputers and mainframes?  Relatively speaking, didn't mainframes 1 have a lot more invested in the I/O capabilities?   
 Bob Hassinger    ------------------------------  % Date: Tue, 06 Jun 2006 16:00:43 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) , Message-ID: <4485DEE3.1C20E1EF@teksavvy.com>   re: virtualisation    G If a VMS takes 10% of resources. You still end up a winner by combining F two machines that are 40% busy into one machine with "VM". 40% + 40% +& 10% = 90% of the pwoer of one machine.  H If you have two machines that are at 60%, then you end up with net loss 0 since you need 130% of the power of one machine.   ------------------------------  $ Date: Tue, 6 Jun 2006 17:50:16 -0400' From: "Main, Kerry" <Kerry.Main@hp.com> M Subject: RE: Unix runs faster, maybe (was: Re: Educating potential VMS users) T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B86840150AE72@tayexc19.americas.cpqcorp.net>   > -----Original Message-----4 > From: Bill Todd [mailto:billtodd@metrocast.net]=20 > Sent: June 6, 2006 1:36 AM > To: Info-VAX@Mvb.Saic.Com = > Subject: Re: Unix runs faster, maybe (was: Re: Educating=20  > potential VMS users) >=20 [snip..]   > >=20G > > The environments I am talking about in the majority of Windows/UNIX H > > servers today are not CPU lite, but disk IO heavy. They are just not7 > > utilized that much at all in peak periods - period.  >=20B > That's what I just suggested, Kerry:  they're limited by disk=20
 > I/O, not=20 H > CPU, and hence CPU utilization *will* be low, even if the disks are=20! > working their little tails off.  >=20  * Apologies, I did not make myself clear.=20  G While there is typically a very small number of servers that are fairly A heavy utilized, the majority of Wintel and UNIX servers today are H neither CPU *or* disk IO heavy. They are just plain idling - period. AndH this is not just me stating this, there are a number of Gartner, IDC etcE type reports that support this statement as one of the reasons for IT  consolidation.  @ > And any file system optimizations that will reduce the load=20 > on the disks=20 F > (as Unix's do far better by default than VMS does) *will* be useful. >=20  G Most admins on any platform I know would tune their OS's / file systems F etc before releasing to production. The same is true for OpenVMS. VeryH few ever release the default config into production, so at best, this is a theoretical viewpoint.   > >=20B > > Part of this might be attributed to the one-app, one server=20 > philosophy> > > as repeated refreshes makes for a much faster server at=20 > lower costs, butA > > if the workload does not increase that much, then the overall > > > utilization goes down. Multiply this by hundreds of x86=20 > servers in many G > > environments and you have one of the basic reasons why CIO's are so / > > concerned about their Windows environments.  >=20@ > Yadda, yadda, yadda:  so what?  This has nothing to do with=20 > the subject=20! > at hand, as I already observed.  >=20 > ...  >=20H > > And btw, a server with low cpu utilization, but heavy IO makes for a& > > poor candidate for virtualization. >=20B > But since you seem to insist on this digression:  horseshit. =20
 > A server=20 < > with very low CPU utilization is a *good* candidate for=20 > virtualization,=20E > since it's got lots of horsepower left over for other tasks that=20 9 > (especially in Windows environments) admins might be=20  > reluctant to run on=20; > the same OS instance:  just hook up some more disks to=20  > service the added=20! > application(s) and let 'er rip.  >=20  F While it can be done, keep in mind the impact on total bandwidth (needF to balance), CPU cache thrashing and virtual drivers overhead. A heavyE IO application will likely depend on cpu caching, but if the other OS E instances are constantly invalidating the CPU cache, then most of the + heavy IO's will go directly to memory/disk.   	 [snip...]   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works. >=20   ------------------------------  % Date: Wed, 07 Jun 2006 00:16:58 -0400 ( From: Bill Todd <billtodd@metrocast.net>M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) G Message-ID: <OL-dnQxtVbanzhvZnZ2dnUVZ_smdnZ2d@metrocastcablevision.com>    Doug Phillips wrote: > Bill Todd wrote: >> Main, Kerry wrote: H >>> And btw, a server with low cpu utilization, but heavy IO makes for a& >>> poor candidate for virtualization.& >>   Remember that virtualization adds8 >>> another level of overhead for both IO and CPU loads.I >> As far as disk I/O goes, horseshit again:  the CPU overhead, even with J >> virtualization added, is a relatively small component of the latency inJ >> a disk access, and since you've already posited that the CPU has cyclesF >> to burn, the added CPU overhead of virtualization is not a problem. >> > ! > Buzzword alert! Buzzword alert!  > D >>From Wikipedia: Virtualization "is a broad term that refers to the= > abstraction of resources across many aspects of computing."  > F > It looks to me like there are as many flavors of "virtualization" as: > there are marketing companies abusing the word. The wordH > "virtualization", used without further definition, is not deserving ofF > a "horseshit" rebuttal; it is deserving of a buzzword alert, though.  F Perhaps you should better acquaint yourself with the context in which H Kerry used the term (and to which I responded):  it's fairly clear what G kind of 'virtualization' he was talking about (but should you still be  G in any doubt you could clarify your insight further by seeing how he's   touted it in the past).    - bill   ------------------------------  % Date: Wed, 07 Jun 2006 00:13:45 -0400 ( From: Bill Todd <billtodd@metrocast.net>M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) G Message-ID: <OL-dnQ1tVbbnzxvZnZ2dnUVZ_smdnZ2d@metrocastcablevision.com>    Main, Kerry wrote: >> -----Original Message----- 3 >> From: Bill Todd [mailto:billtodd@metrocast.net]   >> Sent: June 6, 2006 1:36 AM  >> To: Info-VAX@Mvb.Saic.Com< >> Subject: Re: Unix runs faster, maybe (was: Re: Educating  >> potential VMS users)  >>
 > [snip..] > G >>> The environments I am talking about in the majority of Windows/UNIX H >>> servers today are not CPU lite, but disk IO heavy. They are just not7 >>> utilized that much at all in peak periods - period. A >> That's what I just suggested, Kerry:  they're limited by disk   >> I/O, not G >> CPU, and hence CPU utilization *will* be low, even if the disks are  " >> working their little tails off. >> > * > Apologies, I did not make myself clear.   ? No:  you either misspoke, or are now covering up an attempt to   back-pedal - see below.    > I > While there is typically a very small number of servers that are fairly C > heavy utilized, the majority of Wintel and UNIX servers today are ! > neither CPU *or* disk IO heavy.   D That is *not* what you said above:  you said "The environments I am H talking about in the majority of Windows/UNIX servers today are not CPU H lite, but disk IO heavy" (*not* "neither CPU *or* [sic] disk IO heavy", H as you would now like us to think), and that's the statement to which I 	 responded    ...     ? >> And any file system optimizations that will reduce the load   >> on the disks G >> (as Unix's do far better by default than VMS does) *will* be useful.  >> > I > Most admins on any platform I know would tune their OS's / file systems H > etc before releasing to production. The same is true for OpenVMS. VeryJ > few ever release the default config into production, so at best, this is > a theoretical viewpoint.  H I notice that you're continuing to skate around the question of exactly H how much experience you have with the administration of other OSs (Unix I in particular being central to the current context).  Until such time as  G you're ready to claim significant experience with Unix administration,  @ let's leave this open for more qualified people to comment upon.   ...   H >>> And btw, a server with low cpu utilization, but heavy IO makes for a& >>> poor candidate for virtualization.A >> But since you seem to insist on this digression:  horseshit.    >> A server ; >> with very low CPU utilization is a *good* candidate for   >> virtualization,  D >> since it's got lots of horsepower left over for other tasks that 8 >> (especially in Windows environments) admins might be  >> reluctant to run on  : >> the same OS instance:  just hook up some more disks to  >> service the added  " >> application(s) and let 'er rip. >> > H > While it can be done, keep in mind the impact on total bandwidth (need@ > to balance), CPU cache thrashing and virtual drivers overhead.  G Waving your hands vigorously won't cut it, Kerry - you really ought to   have learned that by now.   	   A heavy G > IO application will likely depend on cpu caching, but if the other OS G > instances are constantly invalidating the CPU cache, then most of the - > heavy IO's will go directly to memory/disk.   F Let's not confuse CPU cache with file-system cache, shall we?  If the H 'heavy I/O application' is not managing to tax the CPU(s) much, then it F pretty much by definition is *not* depending much on CPU caching, nor H with DMA mechanisms (which have been common for decades now) is most of B the data necessarily even *passing through* the CPU caches on its  journey from input to output.   I And of course other OS instances 'constantly invalidating the CPU cache'  C will *never* affect disk accesses, only (at worst) send occasional  B references to RAM which might have otherwise hit in the CPU cache.  8 Your horseshit is rapidly turning into bullshit, I fear.   - bill   ------------------------------  % Date: Wed, 07 Jun 2006 00:46:26 -0400 ( From: Bill Todd <billtodd@metrocast.net>M Subject: Re: Unix runs faster, maybe (was: Re: Educating potential VMS users) G Message-ID: <JcqdnfGyBci_xxvZnZ2dnUVZ_t2dnZ2d@metrocastcablevision.com>    BobH wrote:  > Bill Todd wrote: >> Main, Kerry wrote:  > ... G >>> The environments I am talking about in the majority of Windows/UNIX H >>> servers today are not CPU lite, but disk IO heavy. They are just not7 >>> utilized that much at all in peak periods - period.  >> >>J >> That's what I just suggested, Kerry:  they're limited by disk I/O, not G >> CPU, and hence CPU utilization *will* be low, even if the disks are  " >> working their little tails off. >>F >> And any file system optimizations that will reduce the load on the F >> disks (as Unix's do far better by default than VMS does) *will* be 
 >> useful. >> >>> J >>> Part of this might be attributed to the one-app, one server philosophyL >>> as repeated refreshes makes for a much faster server at lower costs, butA >>> if the workload does not increase that much, then the overall K >>> utilization goes down. Multiply this by hundreds of x86 servers in many G >>> environments and you have one of the basic reasons why CIO's are so / >>> concerned about their Windows environments.  >> >>C >> Yadda, yadda, yadda:  so what?  This has nothing to do with the  * >> subject at hand, as I already observed. >> >> ... >>H >>> And btw, a server with low cpu utilization, but heavy IO makes for a& >>> poor candidate for virtualization. >> >>J >> But since you seem to insist on this digression:  horseshit.  A server ; >> with very low CPU utilization is a *good* candidate for  I >> virtualization, since it's got lots of horsepower left over for other  C >> tasks that (especially in Windows environments) admins might be  E >> reluctant to run on the same OS instance:  just hook up some more  = >> disks to service the added application(s) and let 'er rip.  >>% >>  Remember that virtualization adds  >>8 >>> another level of overhead for both IO and CPU loads. >> >>J >> As far as disk I/O goes, horseshit again:  the CPU overhead, even with H >> virtualization added, is a relatively small component of the latency G >> in a disk access, and since you've already posited that the CPU has  E >> cycles to burn, the added CPU overhead of virtualization is not a   >> problem.  >>	 >> - bill   # Hi, Bob - long (LONG) time, no-see.    ...   H > I think the question was stated in terms of adding more of that heavy K > I/O work to a server that already has heavy on I/O.  Number of disks and  J > latency are interesting parts of that analysis, but total I/O bandwidth K > seems to me to be the limiting issue.  Any given computer has a limit on  K > its available I/O bandwidth.  Things like the bandwidth of the paths the  H > I/O travels over, particularly on the backplane or on the motherboard I > and its chips, including memory.  Only so many bits can be Ied and Oed  G > in a given amount of time by a particular hardware design.  If those  J > limits did not exist then even a very modest computer could do a nearly H > unlimited amount of I/O by just hanging more and more disks off of it. > J > By definition the question was a server that was already heavily loaded I > on the I/O side.  That says it is already pushing the I/O capabilities  B > of the system.  Adding more of that kind of work will result in G > performance problems since there will not be enough I/O to go around.   G Not necessarily:  there are plenty of situations in which a system can  G be I/O-bound but only stressing the capabilities of its disks, to wit,  I when doing lots of relatively small I/O operations (Web-serving being an  I excellent - and common - example, since Web pages tend to be composed of  H many, many itsy-bitsy files and if you're dishing out a large number of H pages, each with its own large set of associated small files, then even E a good-sized file cache won't be all that effective in reducing disk  E load; database access is also often characterized by many small disk  G requests, but in that case there's often more data-processing going on  C rather than the kind of simple data-shuffling that leaves the CPUs   relatively idle).   H In such a case, you can keep adding disks for a *long* time (whether to I the same OS instance or an added one) before taxing the I/O capabilities  G of the box hardware.  Just to get a rough idea, if your disks can each  I generate 80 - 160 4KB disk accesses per second (for ATA/SATA or SCSI/FC,  E respectively), that's only 320KB - 640KB/second (or twice that if it  H must travel over the same path both in-coming and out-going).  Even the H lowliest obsolete desktop-level PCI bus is capable of handling over 100 H MB/second in such cases (and PC memory bandwidth these days is measured D in GB/sec), so you could literally service 100 or more drives under I these circumstances with a 1990s desktop PC without breaking a bandwidth  @ sweat (though you might start running into other issues such as  interrupt saturation).  H Whereas for something like a streaming video server, I agree completely H with your analysis above:  current drives can stream sequential data at E 40 - 80 MB/sec, so it doesn't take more than a couple to saturate an  E old-style PCI bus (though server 64/66 PCIs can handle more like 500  I MB/sec, PCI-X 1 GB/sec, and I think PCI-Express a whole lot more) - even  ' though the CPU may be pretty much idle.   I I suspect that Web servers are a lot more common than video servers, and  E a decade ago file servers tended to see small (8 KB and under) files  G dominate access patterns (though that size may have increased with the  D increased popularity of images, audio, and video, plus the constant F ballooning of Microsoft Word document sizes, so a typical file server I today may see something intermediate in terms of bandwidth requirement).  F   In any event, I was (tacitly) assuming this kind of workload when I 
 commented.   - bill   ------------------------------  # Date: Tue, 06 Jun 2006 18:25:46 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>1 Subject: Re: Wanted:MAIL.MAI structure definition 1 Message-ID: <KMjhg.1558$BU1.382@news.cpqcorp.net>    Ruslan R. Laishev wrote:  @ >     Under high load and concurrent access with POP3 and other H > application to VMS mailbox we have frequent problems when MAIL.MAI is J > empty but user home contains MAIL$****.MAI files. I'd like to embending J > an additional functionality to POP3 server to checking losen MAIL$*.MAI & > files and deleting it. Just for FUY.  E    Sounds like there's a bug somewhere, and I'm not sure I'd want to  B have a POP3 tool deleting files from underneath MAIL.  (I'd be as H interested in why there's an error like this lurking, and what software  here is at fault.)  I    The code necessary to verify the component MAIL files is available on  + the Freeware.  It's known as VFYMAIL, IIRC.    ------------------------------  % Date: Tue, 06 Jun 2006 11:56:57 -0700 # From: "Tom Linden" <tom@kednos.com> 1 Subject: Re: Wanted:MAIL.MAI structure definition ) Message-ID: <op.taqmw7n6zgicya@hyrrokkin>   I On Tue, 06 Jun 2006 11:25:46 -0700, Hoff Hoffman <hoff-remove-this@hp.co=  m>  =    wrote:   > Ruslan R. Laishev wrote: > C >>     Under high load and concurrent access with POP3 and other  =   I >> application to VMS mailbox we have frequent problems when MAIL.MAI is=    =   I >> empty but user home contains MAIL$****.MAI files. I'd like to embendi=  ng  =   I >> an additional functionality to POP3 server to checking losen MAIL$*.M=  AI  =   ' >> files and deleting it. Just for FUY.  > I >    Sounds like there's a bug somewhere, and I'm not sure I'd want to  =   F > have a POP3 tool deleting files from underneath MAIL.  (I'd be as  =  I > interested in why there's an error like this lurking, and what softwar=  e  =   > here is at fault.) > I >    The code necessary to verify the component MAIL files is available =  on  =   - > the Freeware.  It's known as VFYMAIL, IIRC.   I I understand that the layout is subject to change, but why couldn't the =   =  
 definition& be included in starlet.  Just curious.   Tom    ------------------------------  % Date: Tue, 06 Jun 2006 16:05:01 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 1 Subject: Re: Wanted:MAIL.MAI structure definition , Message-ID: <4485DFE5.62821DA3@teksavvy.com>   Tom Linden wrote: I > I understand that the layout is subject to change, but why couldn't the  > definition( > be included in starlet.  Just curious.    G OK, what are the odds that HP would give permission to VMS engineers to A make even simple modifications to an application on VMS (MAIL) ?    G Looks to me that the most that we, users, can expect is improvements to H DCL by Guy Peleg, with the rest of the resources dedicated to the actualE OS itself (cluster interconnects, file system, caches etc, stuff that  users don't see).   H However, MAIL is the one area where huge improvemenst/changes are neededF in order for it to allow internet email much more gracefully. ConsiderA just the time stamp, which would need to be the time stamp of the B message, not the date that the message was received on that node).  F So if one day engineers are unleashed are are allowed to work on stuffE like TPU, MAIL and other applciations that haven't been touched since D the last century, I can see the need to make big changes to the file5 format, so you might want to keep hacks to a minimum.   F On the other hand, if HP makes a firm annoucnement that no applicationG on VMS will ever be updated again, then by all means, all hacks to MAIL / should be allowed and its source code released.    ------------------------------  # Date: Tue, 06 Jun 2006 20:20:41 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>1 Subject: Re: Wanted:MAIL.MAI structure definition 1 Message-ID: <tslhg.1564$kY1.203@news.cpqcorp.net>    Tom Linden wrote:   J > I understand that the layout is subject to change, but why couldn't the 3 > definition be included in starlet.  Just curious.   F    Before any further discussion here: I am aware of no plans to make H the MAIL definitions externally visible -- the recommended approach for I most operations involves the use the MAIL calling interface, and the use  I of the available itemcodes and structures associated with that interface.   G    OpenVMS source code facilities (and most layered products, for that  I matter) that weren't intending or intended to share their data structure  D definitions outside the facility tend to have them located locally; E within the OpenVMS facility.  If you have to reach into the facility  I directories within an OpenVMS build, you tend to realize you're using an  . unpublished and volatile interface, after all.  E    Nothing technically prevents relocating the definitions, but this  E would obviously also include a requirement to recode and rebuild the  F facility -- and the folks maintaining the facility would also have to G accept some number of folks "locking into" the definitions, too.   The  E reloocation is easily feasible.  Convincing various of the engineers  : involved around the need to open the API is the challenge.  G    FWIW, STARLET is the "published" area.  LIB is the "volatile" area;  G the area where the system- and version and semi-documented definitions   tend to reside.   G    In this particular corruption case, I'd still focus on figuring out  I where the problem is lurking -- an approach based on having to re-verify  G the mail files for corruptions seems to be somewhat less than optimal.  F (And if it's MAIL that's involved, the obvious approach would include G fixing the error, and (if needed) the addition of the necessary repair  ? tool(s) into one of the MAIL facilities within OpenVMS itself.)    ------------------------------  % Date: Tue, 06 Jun 2006 16:20:30 -0700 # From: "Tom Linden" <tom@kednos.com> 1 Subject: Re: Wanted:MAIL.MAI structure definition ) Message-ID: <op.taqy4gt8zgicya@hyrrokkin>   I On Tue, 06 Jun 2006 13:20:41 -0700, Hoff Hoffman <hoff-remove-this@hp.co=  m>  =    wrote:   > Tom Linden wrote:  > I >> I understand that the layout is subject to change, but why couldn't t=  he  =   4 >> definition be included in starlet.  Just curious. > I >    Before any further discussion here: I am aware of no plans to make =   =  I > the MAIL definitions externally visible -- the recommended approach fo=  r  =  I > most operations involves the use the MAIL calling interface, and the u=  se  =   I > of the available itemcodes and structures associated with that interfa=  ce.  > I >    OpenVMS source code facilities (and most layered products, for that=    =   I > matter) that weren't intending or intended to share their data structu=  re  =   H > definitions outside the facility tend to have them located locally;  =  I > within the OpenVMS facility.  If you have to reach into the facility  =   I > directories within an OpenVMS build, you tend to realize you're using =  an  =   0 > unpublished and volatile interface, after all. > I >    Nothing technically prevents relocating the definitions, but this  =   I > would obviously also include a requirement to recode and rebuild the  =   I > facility -- and the folks maintaining the facility would also have to =   =  I > accept some number of folks "locking into" the definitions, too.   The=    =   I > reloocation is easily feasible.  Convincing various of the engineers  =   < > involved around the need to open the API is the challenge. > I >    FWIW, STARLET is the "published" area.  LIB is the "volatile" area;=    =   I > the area where the system- and version and semi-documented definitions=    =    > tend to reside.  > I >    In this particular corruption case, I'd still focus on figuring out=    =   I > where the problem is lurking -- an approach based on having to re-veri=  fy  =   I > the mail files for corruptions seems to be somewhat less than optimal.=    =   I > (And if it's MAIL that's involved, the obvious approach would include =   =  I > fixing the error, and (if needed) the addition of the necessary repair=    =   A > tool(s) into one of the MAIL facilities within OpenVMS itself.)  > I As I said, it was just curiosity.  If there is not a compelling reason t=  o I keep something proprietary, then starlet it. There, I created a new verb=  .    ------------------------------  # Date: Tue, 06 Jun 2006 23:44:00 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>1 Subject: Re: Wanted:MAIL.MAI structure definition 1 Message-ID: <4rohg.1581$G32.814@news.cpqcorp.net>    Tom Linden wrote:   K > As I said, it was just curiosity.  If there is not a compelling reason to K > keep something proprietary, then starlet it. There, I created a new verb.   F    I'd flip that over.  If there's not a compelling reason to share a G particular interface -- to render the interface public, or at least to  > allow some sort of sharing -- then keep the interface private.  H    Opening any arbitrary interface runs contrary to the typical opacity @ of the internal interfaces and of application modularity and of A long-standing programming practices.  And it makes the usual and  H expected application compatibility far more difficult to achieve and to 	 maintain.   @    If I had the cycles to re-implement MAIL all over again, for F instance, we'd be using XML and/or a relational database, and some of F these pieces would be (far) more visible.  But opening up traditional E internal APIs or database file organizations to visibility obviously  G invites folks to use the APIs, and this is access is most definitely a  D two-edged sword.   With XML or a relational database -- or a way to E export to same -- maintaining compatibility is easier, and defending  C against corruptions -- whether in the code, or in something that a  6 programmer has hooked into the interface -- is easier.  H    There have been changes to the naming of various MAIL files over the G years, for instance, and there are definite limits to the current MAIL  H design.  If we open the database API, we effectively codify the current B design in concrete, and make it far harder (if not impossible) to 6 re-work these interfaces and these designs compatibly.  D    If there are particular requirements not met within the existing F interface(s), then these should be addressed through callable MAIL or F similar extensions.  Opening up the internals of an arbitrary hunk of G code serves no purpose, and (in my experience) tends to cause problems  G for everybody involved.  I've ported code, for instance, that expected  H modifications directly to the underlying operating system in support of 1 the application code -- kernel patches.  Shudder.    ------------------------------  % Date: Tue, 06 Jun 2006 19:39:19 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 1 Subject: Re: Wanted:MAIL.MAI structure definition , Message-ID: <44861211.57A27EB0@teksavvy.com>   Tom Linden wrote: K > As I said, it was just curiosity.  If there is not a compelling reason to K > keep something proprietary, then starlet it. There, I created a new verb.   D Yes, but it begs the question: which came first: the library, or the" node ? (starlet)   :-) :-) :-) :-)    6 To starlet or not to starlet, that is the question :-)   ------------------------------  % Date: Tue, 06 Jun 2006 20:11:26 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 1 Subject: Re: Wanted:MAIL.MAI structure definition + Message-ID: <44861996.9A0FFFD@teksavvy.com>    Hoff Hoffman wrote: G > instance, we'd be using XML and/or a relational database, and some of + > these pieces would be (far) more visible.     . Why XML ? Why not use simple RFC822 concepts ?  @ And why a relational database instead of a simple indexed file ?   ------------------------------  # Date: Wed, 07 Jun 2006 01:01:40 GMT   From: John Santos <john@egh.com>1 Subject: Re: Wanted:MAIL.MAI structure definition * Message-ID: <Uzphg.9661$3i3.8801@trnddc08>   JF Mezei wrote:  > Hoff Hoffman wrote:  > G >>instance, we'd be using XML and/or a relational database, and some of + >>these pieces would be (far) more visible.  >  >  > 0 > Why XML ? Why not use simple RFC822 concepts ? >   C If I am not mistaken, RFC822 relates to mail transport, not to mail F storage.  The mail.mai structure has nothing to do with mail transport' and everything to do with mail storage.   D I think XML provides a portable, extensible way to deal with variousE mail headers (traditional DEC mail as well as SMTP headers) and other D information about mail (organization of local storage, key words forB lookup, threading, etc.), which would provide the basis for a muchH quicker and more versatile user interface program than current mail.exe.  G (I use VMS Pine as a mail program.  It uses the standard mail.mai files D and callable mail, but it attempts to impose some structure, such asC threading the messages and selectively displaying RFC-style headers E and manufacturing them from the DEC mail headers if they aren't there C (i.e. for local mail or mail received over DECnet.)  It is far from H ideal, and very slow, even though its searching abilities, address book,C and so forth are much better than standard VMS mail.  There is huge G room for improvement here.  For example, I simulate a multilevel folder E structure by naming my folders "cat1-subcat1", "cat1-subcat2", "cat2- G subcat1", "cat2-subcat1-subsubcat1", etc. which makes them sort nicely, F but there is no way, for example to display a subtree or to search it.F If I know I got mail in about something that is probably in one of theH "Cat3-..." folders sometime between 1999 and 2003, I need to iterativelyD select each or the cat3* folders in turn, specify a date range (PineG will do this), and then search.  Repeat until fingers fall off.  Or the D easier way, just use DCL search [.mail]*.mai "something to look for"0 with a big window and hope it isn't too common.)  B > And why a relational database instead of a simple indexed file ?  E It's much easier and faster to do ad hoc searches and summary display @ organization and navigation, all of which are basically database@ queries, with a database than with a simple indexed file.  (BTW,D the user doesn't need to know anything of the implementation detailsB to use this stuff, unless he wants to write his own user interface	 program.)    --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------   End of INFO-VAX 2006.314 ************************                                                                                                                                    nfo-vaxk1 >>> 250 Connected to /disk$misc/decus/info-vax.k	 <<< PWD/; >>> 257 "/disk$misc/decus/info-vax" is current directory.  <<< TYPE I >>> 200 Type I ok. <<< LIST -la 2005_409.txta >>> 150 List started.o >>> 226 Transfer completed. <<< PORT 24,5,236,254,15,1354 >>> 200 Port 15.135 at Host 24.5.236.254 accepted. <<< LIST 2005_409.txtr >>> 150 List started.r >>> 226 Transfer completed.0 <<< PORT 24,5,236,254,15,1364 >>> 200 Port 15.136 at Host 24.5.236.254 accepted. <<< RETR 2005_409.txteY >>> 150 IMAGE retrieve of /disk$misc/decus/info-vax/2005_409.txt (21242 bytes) started.e; >>> 226 Transfer completed.  20050 (8) bytes transferred.T <<< CWD /info-vax1 >>> 250 Connected to /disk$misc/decus/info-vax.d	 <<< PWDO; >>> 257 "/disk$misc/decus/info-vax" is current directory.6 <<< PORT 24,5,236,254,15,1374 >>> 200 Port 15.137 at Host 24.5.236.254 accepted. <<< REST 200507 >>> 500 I never heard of the REST command.  Try HELP.  <<< CWD /info-vax.1 >>> 250 Connected to /disk$misc/decus/info-vax.e	 <<< PWDi; >>> 257 "/disk$misc/decus/info-vax" is current directory.  <<< REST 200507 >>> 500 I never heard of the REST command.  Try HELP. <<< CWD /info-vax 1 >>> 250 Connected to /disk$misc/decus/info-vax.5	 <<< PWDs; >>> 257 "/disk$misc/decus/info-vax" is current directory., <<< REST 200507 >>> 500 I never heard of the REST command.  Try HELP.T <<< CWD /info-vaxe1 >>> 250 Connected to /disk$misc/decus/info-vax.W	 <<< PWD.; >>> 257 "/disk$misc/decus/info-vax" is current directory.W <<< REST 200507 >>> 500 I never heard of the REST command.  Try HELP.T  <<< CWD /info-vax/2005_408.txt9 >>> 550 You are not permitted to access this directory.  <<< CWD /info-vaxk1 >>> 250 Connected to /disk$misc/decus/info-vax.k	 <<< PWD/; >>> 257 "/disk$misc/decus/info-vax" is current directory.  <<< TYPE I >>> 200 Type I ok. <<< LIST -la 2005_408.txta >>> 150 List started.o >>> 226 Transfer completed. <<< PORT 24,5,236,254,15,1694 >>> 200 Port 15.169 at Host 24.5.236.254 accepted. <<< LIST 2005_408.txtr >>> 150 List started.r >>> 226 Transfer completed.0 <<< PORT 24,5,236,254,15,1704 >>> 200 Port 15.170 at Host 24.5.236.254 accepted. <<< RETR 2005_408.txteY >>> 150 IMAGE retrieve of /disk$misc/decus/info-vax/2005_408.txt (24800 bytes) started.e; >>> 226 Transfer completed.  23438 (8) bytes transferred.T <<< CWD /info-vax1 >>> 250 Connected to /disk$misc/decus/info-vax.d	 <<< PWDO; >>> 257 "/disk$misc/decus/info-vax" is current directory.6 <<< PORT 24,5,236,254,15,1834 >>> 200 Port 15.183 at Host 24.5.236.254 accepted. <<< REST 234387 >>> 500 I never heard of the REST command.  Try HELP.  <<< CWD /info-vax.1 >>> 250 Connected to /disk$misc/decus/info-vax.e	 <<< PWDi; >>> 257 "/disk$misc/decus/info-vax" is current directory.  <<< REST 234387 >>> 500 I never heard of the REST command.  Try HELP. <<< CWD /info-vax 1 >>> 250 Connected to /disk$misc/decus/info-vax.5	 <<< PWDs; >>> 257 "/disk$misc/decus/info-vax" is current directory., <<< REST 234387 >>> 500 I never heard of the REST command.  Try HELP.T <<< CWD /info-vaxe1 >>> 250 Connected to /disk$misc/decus/info-vax.W	 <<< PWD.; >>> 257 "/disk$misc/decus/info-vax" is current directory.W <<< REST 234387 >>> 500 I never heard of the REST command.  Try HELP.T  <<< CWD /info-vax/2005_407.txt9 >>> 550 You are not permitted to access this directory.  <<< CWD /info-vaxk1 >>> 