1 INFO-VAX	Mon, 02 May 2005	Volume 2005 : Issue 243       Contents:! finding the (biggest) bottle neck 8 Re: Maybe HP should get out of the hardware business....8 Re: Maybe HP should get out of the hardware business....8 Re: Maybe HP should get out of the hardware business....6 Re: Optimising Alpha Cobol application on OpenVMS IA64 PPP (Poor Prior Planning)  question on directory sizes  Re: question on directory sizes  Re: question on directory sizes ) Re: SYS$SYSROOT and similar logical names ) Re: SYS$SYSROOT and similar logical names ) Re: SYS$SYSROOT and similar logical names + Re: What is Different or Special About VMS? + Re: What is Different or Special About VMS? + Re: What is Different or Special About VMS? + Re: What is Different or Special About VMS? + RE: What is Different or Special About VMS? + Re: What is Different or Special About VMS? + Re: What is Different or Special About VMS?   F ----------------------------------------------------------------------  # Date: Mon, 02 May 2005 02:38:33 GMT + From: Jack Patteeuw <jjpatteeuw@nospam.net> * Subject: finding the (biggest) bottle neckB Message-ID: <Jogde.2783$7F4.2447@newsread2.news.atl.earthlink.net>  F I have just recently gotten back into VMS after 10 years on the "dark  side" (Tru64 and Solaris).  E The biggest problem we have with our mixed VAX (3 - 7630)/Alpha (1 -  F GS140) cluster is backups.  Full backups can take over 14 hours using 	 ABS/MDMS.   D All disk are on one CI, with HSJ40 and HSJ50 controllers.  Most are K JBOD, but we want to RAID 5 some, which I know will probably slow disk I/O.   B All tape (TZ88's) are on another CI using a different HSJ50.  The G previous Sys Admin says adding more tape drives to the process did not  < improve thing (we are only using 4-6, but have 12 available)  F We have an extremely limited budget, so I need to figure out where to I get the "most bang for the buck" with any upgrade.  My gut says, upgrade  @ the tapes to TZ89, but I need some proof.  Or would we get more ) performance out of a HSJ80 on the disks ?   G I need suggestions on how to measure the "capacity" of each CI as well  = as the throughput of the HSJ's and the processors themselves.    ------------------------------  % Date: Sun, 01 May 2005 17:02:42 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> A Subject: Re: Maybe HP should get out of the hardware business.... B Message-ID: <1114981490.a97d4665a2824658f6b883a20f016241@teranews>   icerq4a@spray.se wrote: H > Really?, Intel usually makes the most money on it's CPU and especiallyC > on it's x86 CPUs. Do they have very little competition in the CPU # > business and in the x86 business?   H It isn't a question of whether Intel makes money or not. The question isQ whether Intel is as profitable as it could be if it canned unprofitable products.   E Wall Street Casino analysts have begun to see AMD as an instrument to E lower profitability of the Intel 8086 line and as a result, they want E Intel to cut its expensive pet projects that aren't going anywhere to G cut expenses and hence maintain high profitability despite lower prices  in the 8086 market.   ? And IA64 is an expensive pet project that isn't going anywhere.    ------------------------------  % Date: Sun, 01 May 2005 18:50:33 -0400 ' From: Dave Froble <davef@tsoft-inc.com> A Subject: Re: Maybe HP should get out of the hardware business.... 0 Message-ID: <117an9ngjbub53f@corp.supernews.com>   icerq4a@spray.se wrote:   F > I don't think so. The only thing thing Xeon was late with was 64-bit
 > support,   Late?   LATE?????   @ What type of revisionist history are you attempting to practice?  F Intel's mantra was, no 64 bits for x86, it's not needed, and it won't I happen, no way, no how, no where.  It wasn't late!  It wasn't suppost to   ever happen!  F Then one fine day, their course hit a brick wall, bounced off it, and B departed in an entirely different direction, a direction they had , maintained that just WOULD  NOT  HAPPEN!!!!!  G And could they even come up with their own design?  No way!  Microsoft  F let them know that there would be only one version of x86-64 windows,  and it would be AMD's version.  H And even after they had to copy AMD's chips, they still left off the on A chip memory controller, and their product just isn't competitive.   C I think the statement "late with 64 bits" is way too easy on Intel.    --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------   Date: 1 May 2005 19:47:31 -0700  From: bob@instantwhip.com A Subject: Re: Maybe HP should get out of the hardware business.... C Message-ID: <1115002051.231096.218740@f14g2000cwb.googlegroups.com>   A intel could still start making alpha ev79s and put the alpha team = back on ev8 ... and windows 2000 runs on alpha ... makes good > sense ... alpha and xeon would be a formidable lineup againset& ams or anyone else for that matter ...   ------------------------------   Date: 1 May 2005 18:51:52 -0700 * From: "Don Braffitt" <don.braffitt@hp.com>? Subject: Re: Optimising Alpha Cobol application on OpenVMS IA64 C Message-ID: <1114998712.532368.303200@o13g2000cwo.googlegroups.com>    > $ COBOL/STANDARD=3 > G > All the code compiled, and we have linked it and it runs. We now want C > to optimise it. Does anyone have any suggestions on what compiler B > switches to use, or what we need to do to optimise it for IA64 ?   One thing to consider is   $ COBOL/STANDARD=V3/ALIGN   C /ALIGN will probably improve performance on both Alpha and I64, but B the amount of performance improvement will depend on how well yourE data structures are already aligned. If you are reading files created E with byte alignment, you may want to look at use of /ALIGN along with G the alignment directives. You can use the alignment directives to force D byte alignment for certain data structures while obtaining Alpha/I64: natural alignment for the rest of the program with /ALIGN.   The details are here  H http://h71000.www7.hp.com/doc/82final/6297/6297pro_110.html#index_x_2171   - Don BraffittE   project leader, HP COBOL, SORT32, Hypersort for OpenVMS, Tru64 UNIX    ------------------------------   Date: 1 May 2005 21:27:55 GMT ( From: bill@cs.uofs.edu (Bill Gunshannon)" Subject: PPP (Poor Prior Planning), Message-ID: <3dkvurF6oebujU1@individual.net>  C Sometime ago I gave away a Star Coupler to someone because I really D never anticipated having a system large enough to actually need one. Well, I was wrong.    B Is there any chance there is someone here with a Star Coupler theyA find they have no need for that would be willing to part with it?   D And in the "feeling out the waters" department.  Is there any marketF for a used TL812?  I have one here that I don't think we will be usingE as my boss opted for a different backup strategy.  The big difference D in this case is this isn't mine and if they opt to get rid of it theG "U" will want to get something for it.  So, any interest or suggestions 2 about what it might be worth would be appreciated.   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: 1 May 2005 15:17:18 -0700 - From: "derek pietro" <djpietro@earthlink.net> $ Subject: question on directory sizesC Message-ID: <1114985838.253358.117050@z14g2000cwz.googlegroups.com>   D I must copy a large number of files to a disk from an optical deviceG then use another process to copy them off of the vms machine to another  machine.8 I must also use long file names as part of this process.  C In other experiences, I've learned to check for enough space on the  disk during such an adventure.D The problem I'm encountering is that I'm (apparently) running out ofD directory space, as opposed to (what I'd expect) running out of disk space.  G I was using disk space as a throttling mechanism, but never runningout.   D I need to use directory entries space as a throttle, or simply put aE counter inside the c-code and limit myself with some hard count as to  the number of files created.G I'd prefer to be able to see how much dir space is available and "wait" ? on it as it is provides a more consise mechanism to "sleep" on.   B I've tried to find - with no success yet - a means to see how much# directory space is available to me.   - this is being done in C, on VMS 7.2 on alpha. 0 Can someone shed some light that may be helpful?E When things get all hung up for me, I've about 27000 files on my disk 7 that I end up having to copy off then delete, manually.   G As a lesser topic, can someone tell me how to nfs mount to a linux box?   D If I were nfs mounted - is it still possible to use RMS to copy to a destination thats nfs mounted?  G I have very little vms knowledge, and must be very careful with the VMS F box as its used in a production system. Rebooting the box is something I am NOT allowed to do.....    Thanks!    ------------------------------   Date: 1 May 2005 15:27:38 -0700 - From: "derek pietro" <djpietro@earthlink.net> ( Subject: Re: question on directory sizesC Message-ID: <1114986458.041801.148930@f14g2000cwb.googlegroups.com>   D As an aside on this - perhaps just a means to obtain - from  c - the? total number of files in my directory would be another means to   throttle my large copy exercise.   ------------------------------  % Date: Sun, 01 May 2005 19:47:03 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ( Subject: Re: question on directory sizesB Message-ID: <1114991219.6e4e60056cb4201ff48a28d0d038803c@teranews>   derek pietro wrote: F > The problem I'm encountering is that I'm (apparently) running out ofF > directory space, as opposed to (what I'd expect) running out of disk > space.  D prior to initiating the copy operation, create the directory with an alreayd large allocation.    $HELP CREATE /DIR /ALLOC  F (on VAX, it says that this applies only to ODS2 volumes, but I suspectD it is a relic from older file systems anot not an indication that it doesn't apply to ODS-5.   Q If you need a thorttling mechanism between 2 processes, consider using a mailbox.   B One process writes to the mailbox a messqage for every file it hasG copied. The other process reads the mesage from the mailbox when it has P finished processing a file. You can create the mailbox to buffer a few messages.  D This way, when the mailbox is full, the writing process will go intoF RWMBX state until the reading process has read one or more messages toF free up some buffer space, at which point, the write will complete and" your writing process can continue.   ------------------------------   Date: 1 May 2005 19:52:22 -0700 $ From: "AEF" <spamsink2001@yahoo.com>2 Subject: Re: SYS$SYSROOT and similar logical namesC Message-ID: <1115002342.228461.238760@f14g2000cwb.googlegroups.com>   / Phillip Helbig---remove CLOTHES to reply wrote:  > This is the default setup: > % > $ dir sys$manager:systartup_vms.com  >   > Directory SYS$SYSROOT:[SYSMGR] >  > SYSTARTUP_VMS.COM;2  >  > Total of 1 file. >  > Directory SYS$COMMON:[SYSMGR]  >  > SYSTARTUP_VMS.COM;202  >  > Total of 1 file. > ( > Grand total of 2 directories, 2 files. > $ sh log sys$sysroot: >    "SYS$SYSROOT" = "DSA133:[SYS0.]" [concealed,terminal] (LNM$SYSTEM_TABLE) >         = "SYS$COMMON:" C > 1  "SYS$COMMON" = "DSA133:[SYS0.SYSCOMMON.]" [concealed,terminal]  (LNM$SYSTEM_TABLE) > $ > This raises a number of questions. > E > First, why is SYS$SYSROOT used in two contexts: as the logical name ; > itself, and as the alias for the concealed directory name A > DSA133:[SYS0.]?  In other words, as a logical name, SYS$SYSROOT  points/ > to two directories, namely DSA133:[SYS0.] and  DSA133:[SYS0.SYSCOMMON.]. G > However, with the DIRECTORY command, SYS$SYSROOT shows up as the name  ofG > only the first directory, the second showing up as SYS$COMMON (which,  of: > course, is in turn defined as DSA133:[SYS0.SYSCOMMON.]). > A > It seems it would make much more sense to define SYS$SYSROOT as  > $ >    "SYS$SYSROOT" = "SYS$SPECIFIC:"9 > 1  SYS$SPECIFIC = "DSA133:[SYS0.]" [concealed,terminal]  (LNM$SYSTEM_TABLE) >         = "SYS$COMMON:" C > 1  "SYS$COMMON" = "DSA133:[SYS0.SYSCOMMON.]" [concealed,terminal] 
 (LNM$SYSTEM_T  > G > This would have several advantages.  First, it would put SYS$SPECIFIC   B > and SYS$COMMON on the same footing.  (Note that the SYS$SPECIFIC logical @ > is defined by default, but it is not used in the definition OfG > SYS$SYSROOT.)  Second, it would make clear that SYS$SYSROOT refers to   C > both SYS$SPECIFIC and SYS$COMMON, as now in the definition of the C > logical SYS$SYSROOT (except that the translation of SYS$SPECIFIC,  ratherC > than SYS$SPECIFIC, is used in that definition) and not create any F > confusion with the DIRECTORY command by suggesting that it refers to > only the former.  C This would have the disadvantage of losing the search list in parse 0 operations. For exmaple, consider the expression  '     F$PARSE("SYS$SYSTEM:.DAT","SYSUAF")   C With your suggestion, you would get SYS$SPECIFIC:[SYSEXE]SYSUAF.DAT E whereas in the current scheme you get SYS$SYSROOT:[SYSEXE]SYSUAF.DAT, F preserving the serach list. (This answer was posted by someone else in& this newsgroup; I can't remember who.)   > E > Second question: Since SYS$SYSROOT is defined as a search list, why  not ? > use VMS$COMMON:[000000.] rather than [SYS0.SYSCOMMON.] in the G > definition?  This would make it unnecessary to have [SYS0.SYSCOMMON.]  beA > an alias for VMS$COMMON:[000000.] in the first place.  The only > > advantage I can see in the current scheme is that one can do	 something 7 > like $ DIR [SYS0...] and have it pick up the stuff in ' > VMS$COMMON:[000000...] via the alias.  > A > (At first I thought that the search-list functionality might be  neededE > during system startup before the software (which might be somewhere  in9 > the search list) is running, thus one would have to use G > [SYS0.SYSCOMMON.] explicitly rather than using SYS$SYSROOT.  However,  in@ > that case one could just use VMS$COMMON:[000000.] explicitly.)  F I've asked the very same question. The best I can figure is that it isF this way "for historical reasons". Without knowing the full history ofC this it is difficult to see why it is the way it is. NO ONE IN THIS + NEWSGROUP KNOW THE ANSWER TO THIS QUESTION!    > G > Third, it is probably not supported, but it would make sense to me to ? > add a third translation for SYS$SYSROOT, namely pointing to a 	 directory F > on a non-system disk shared by all members of a cluster, for exampleF > containing common SYSUAF.DAT etc.  This would allow one redefinition> > (which could be done, for example, only if this directory is
 available)D > rather than defining SYSUAF and all the other logicals explicitly.  C I see no reason not to do this if you're careful and as long as you B don't add any directories in front of the sys$specific search list element.   > G > Actually, one might want to have two such additional definitions, one B > preceeding the standard two and one following them.  Things likeC > SYSUAF.DAT could be in the first directory of the search list, so  thatB > all machines (satellites or boot nodes) would use them no matter what.   E No, see above. Well, you could if you drop the concealed attribute of F the sys$specific element and move it to your new first element so that@ parsing would give you the search list instead of just its first element.  C > In the fourth directory in the search list, one could have things  which C > are used only if there is no entry in a previous directory in the  search= > list, which would allow one to put stuff in SYS$COMMON on a 
 particularF > system disk so that it is used by all nodes booting from that systemE > disk, but not by those booting from other system disks (which would  pick  6 > it up from the fourth directory in the search list).   ------------------------------   Date: 1 May 2005 20:14:38 -0700 $ From: "AEF" <spamsink2001@yahoo.com>2 Subject: Re: SYS$SYSROOT and similar logical namesB Message-ID: <1115003678.485357.27440@z14g2000cwz.googlegroups.com>   JF Mezei wrote: 1 > Phillip Helbig---remove CLOTHES to reply wrote: ' > > $ dir sys$manager:systartup_vms.com " > > Directory SYS$SYSROOT:[SYSMGR]! > > Directory SYS$COMMON:[SYSMGR]  > * > > Grand total of 2 directories, 2 files. > > $ sh log sys$sysroot< > >    "SYS$SYSROOT" = "DSA133:[SYS0.]" [concealed,terminal] (LNM$SYSTEM_TABLE) > >         = "SYS$COMMON:" E > > 1  "SYS$COMMON" = "DSA133:[SYS0.SYSCOMMON.]" [concealed,terminal]  (LNM$SYSTEM_TABLE) > G > > First, why is SYS$SYSROOT used in two contexts: as the logical name = > > itself, and as the alias for the concealed directory name  [...]   ( Referring to SYS$SPECIFIC and SYS$COMMON  C > If they had both values their specific ones (eg: disk:[SYS0.] and @ > disk:[sys0.syscommon.] , then both directories would appear as< > SYS$SYSROOT:[SYSMGR] and that would be far more confusing.  6 Not if you drop /tran=concealed in the DEFINE command:  9 $ DEFINE AEF_ROOT DKA100:[SYS0.],DKA100:[SYS0.SYSCOMMON.] % $ DEFINE AEF_SYSTEM AEF_ROOT:[SYSEXE]  $ DIREC/TOTAL AEF_SYSTEM    Directory DKA100:[SYS0.][SYSEXE]   Total of 674 files.   * Directory DKA100:[SYS0.SYSCOMMON.][SYSEXE]   Total of 308 files.    ( Grand total of 2 directories, 982 files. $    [...]    ------------------------------  * Date: Mon, 2 May 2005 05:19:16 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)2 Subject: Re: SYS$SYSROOT and similar logical names$ Message-ID: <d54d8k$n18$1@online.de>  C In article <1115002342.228461.238760@f14g2000cwb.googlegroups.com>, ' "AEF" <spamsink2001@yahoo.com> writes:    E > This would have the disadvantage of losing the search list in parse 2 > operations. For exmaple, consider the expression > ) >     F$PARSE("SYS$SYSTEM:.DAT","SYSUAF")  > E > With your suggestion, you would get SYS$SPECIFIC:[SYSEXE]SYSUAF.DAT G > whereas in the current scheme you get SYS$SYSROOT:[SYSEXE]SYSUAF.DAT, H > preserving the serach list. (This answer was posted by someone else in( > this newsgroup; I can't remember who.)   Makes sense.    H On a side note, I was thinking that such code was used to determine the I file spec of SYSUAF, which might be a logical name (otherwise, one could  F just use SYS$SYSTEM:SYSUAF.DAT directly).  On my cluster, SYSUAF is a ; logical name, but the parse command returns something else:    $ sh log sysuaf <    "SYSUAF" = "CLUSTER_SYSTEM:SYSUAF.DAT" (LNM$SYSTEM_TABLE)  6 $ write sys$output F$PARSE("SYS$SYSTEM:.DAT","SYSUAF") SYS$SYSROOT:[SYSEXE]SYSUAF.DAT;   D    Also, by default the F$PARSE function translates logical names if.    they are provided in any of the arguments.   H > I've asked the very same question. The best I can figure is that it isH > this way "for historical reasons". Without knowing the full history ofE > this it is difficult to see why it is the way it is. NO ONE IN THIS - > NEWSGROUP KNOW THE ANSWER TO THIS QUESTION!   H Interesting claim.  I suppose that the first person to answer this will 5 get the title "Really, really stupendous VMS wizard"!    ------------------------------  $ Date: Sun, 1 May 2005 14:39:58 -0400# From: "John Smith" <a@nonymous.com> 4 Subject: Re: What is Different or Special About VMS?, Message-ID: <a-Sdna4Vk8IZv-jfRVn-gA@igs.net>   JF Mezei wrote:  > A > Note that in terms of industrial espoonage, Westjet (a canadian 
 > airline)E > is king, and it hacked into web pages available to ex eemployees of  > Air G > Canada and Jetsgo which provided Wesjet with confidential information H > about load factors for each individual flights and average yield. (eg:G > if 5 persons paid $20 but 95 paid $100, then the yield is $96 on that F > flight, and that is information that is extremely confidential since > the F > public only ever sees the ads for the $20 fare and competitors neverD > knwo how many seats at $20 are available on a competitor's flight. >  > H > This had nothing to do with system security or hacking per say. It hadH > to do with stupid application managers who didn't realise that many exC > empooyees were now employees at a competitor and that they really C > shouldn't have access to this information, and also never thought  > about B > putting a daily transaction limit on each ex employee usernames./ > (westjet would do thousands of transactions).     J This was a systems management / HR / policies & procedures failure - not a8 hack / crack / break-in, or any other technical failure.     --F OpenVMS - The never advertised operating system with the dwindling ISV base.    ------------------------------  $ Date: Sun, 1 May 2005 14:42:33 -0400# From: "John Smith" <a@nonymous.com> 4 Subject: Re: What is Different or Special About VMS?, Message-ID: <VLydnUm3yLO6vujfRVn-vw@igs.net>   Main, Kerry wrote: > D > And then - oh, by the way, the judges at a hackers conference also& > voted OpenVMS "cool and unhackable".      9 So "cool" is now an official part of the Common Criteria?   2 Which section / sub-section can I find that under?   --F OpenVMS - The never advertised operating system with the dwindling ISV base.    ------------------------------  % Date: Sun, 01 May 2005 16:50:57 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 4 Subject: Re: What is Different or Special About VMS?B Message-ID: <1114980729.1964630cc156c02b0bed5fe746ce18f4@teranews>   Bill Gunshannon wrote:D > number of likely VMS hackers compared to Unix and Windows hackers.D > Unless your going to tell us now that the infamous 411,000 systems+ > is off by at least 2 orders of magnitude.   ) Could it really be down to 4110 systems ?    :-)    ------------------------------  % Date: Sun, 01 May 2005 17:18:44 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 4 Subject: Re: What is Different or Special About VMS?B Message-ID: <1114982349.513ccf9ac4c11210596528ac42e160bf@teranews>   John Smith wrote: L > This was a systems management / HR / policies & procedures failure - not a: > hack / crack / break-in, or any other technical failure.  G It was a technical failure in that the IT folks, in implementing the HR H policy, failed to see the security issues with allowing former employees/ to freely access very sensitive corporate data.   / Here is the reason they were given this access:   F Ex employees, per union contracts, get access to very reduced fares toF travel on stand-by on any Air Canada flight. But instead of showing upG at airport and truly "stand by", they search through flight bookings to G find the flights that has the best likelyhood of having a free seat and ' show up at the airport for that flight.   G So if an ex employee wants to fly Montreal-Toronto on a certain day, he H may in fact lookup all flights on that day to see which ones to focus onH due to better chances of having a free seat. That would be perhaps 20 orE 30 lookups (for outbound and inbound flights). Not the thousands that - Westjet was doing using ex employee accounts.   E Westjet found what seems to be a fairly common IT mistake (since both F Air Canada and Jetsgo were victims of this ploy).  By definition, this would be hacking.   F Remember that the the pre-windows days, hacking usually meant that theF hacker obtained a username/password to get access (as opposed to bruteF force guessing). Again, not too different from what Westjet did. (hireE some willing ex-employee and use their username/password to get to AC  and Jetsgo's data.  G Where VMS differs from Windows is that it offers very vew opportunities E to gain access to raw data due to OS faults. With Windows, there have E been exploits where hackers got copies of certain files by implanting D some virus which was then able to give them the data. (for instance,G credit card lists, customer lists etc). This wasn't through application 9 design problems (as was the case with Air Canada/Jetsgo).   H However, another aspect is that many shops chose Windows because of easyD avalability of cheap support personel. The cheap support personel is1 also responsible for not thinking about security.    ------------------------------  $ Date: Sun, 1 May 2005 21:38:05 -0400' From: "Main, Kerry" <kerry.main@hp.com> 4 Subject: RE: What is Different or Special About VMS?R Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB5ECF14@tayexc19.americas.cpqcorp.net>   > -----Original Message------ > From: John Smith [mailto:a@nonymous.com]=20  > Sent: May 1, 2005 2:43 PM  > To: Info-VAX@Mvb.Saic.Com 6 > Subject: Re: What is Different or Special About VMS? >=20 > Main, Kerry wrote: > > F > > And then - oh, by the way, the judges at a hackers conference also( > > voted OpenVMS "cool and unhackable". >=20 >=20 >=20; > So "cool" is now an official part of the Common Criteria?  >=204 > Which section / sub-section can I find that under? >=20  E I am not saying it is not important or that it is not required, but I H suspect many CIO's would be more impressed with the "hackers conference"F reference because most of them that do not deal directly with the Govt7 will typically have no idea what common criteria means.   ) They are to busy with SOX, HIPPA etc. =20      Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  $ "OpenVMS has always had integrity .. Now, Integrity has OpenVMS .."   ------------------------------   Date: 1 May 2005 20:22:02 -0700 $ From: "AEF" <spamsink2001@yahoo.com>4 Subject: Re: What is Different or Special About VMS?B Message-ID: <1115004122.697774.28730@o13g2000cwo.googlegroups.com>   Bill Gunshannon wrote:5 > In article <W7XGj34KL$Yw@eisner.encompasserve.org>, 2 > 	Kilgallen@SpamCop.net (Larry Kilgallen) writes:G > > In article <3dg968F6rrre3U1@individual.net>, bill@cs.uofs.edu (Bill  Gunshannon) writes:  > > F > >> point.  Surely if VMS is still in the favor of the government and@ > >> DOD as many here keep insisting you can come up with a more credible > >> source to show it.  > > : > > Many government agencies have rules against publicity. > > > I wasn't talking about Public Affairs driven dog&pony shows.> > In order to be used in many places in the goverment, systems@ > have to meet certain criteria.  This is done before the agencyB > involved even gets permission to buy it.  Publishing the resultsC > of these certifications would go a lot further than the ramblings 5 > of some teenage computer geek without a girlfriend.   G So you're saying that hackers without girlfriends can only hack Windows G and Linux? Or that having a girlfriend lends a hacker credibility? Huh?    [...]    ------------------------------  * Date: Mon, 2 May 2005 05:07:33 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)4 Subject: Re: What is Different or Special About VMS?$ Message-ID: <d54cil$lb8$2@online.de>  H In article <1115004122.697774.28730@o13g2000cwo.googlegroups.com>, "AEF"! <spamsink2001@yahoo.com> writes:    I > So you're saying that hackers without girlfriends can only hack Windows I > and Linux? Or that having a girlfriend lends a hacker credibility? Huh?   . I have this is in my collection of quotations:  H You are in big trouble when you start writing software to impress girls.  N                                  ---Bruce Ellis, THE HITCHHIKER'S GUIDE TO VMS  H On a more serious note, I seem to recall that quite a few women play(ed)? key roles in the development of VMS, at least compared to other H operating systems.  Is this impression correct?  Let's make a list; I'll% start by mentioning Ruth Goldenberg.     ------------------------------   End of INFO-VAX 2005.243 ************************