1 INFO-VAX	Thu, 15 Mar 2001	Volume 2001 : Issue 147       Contents:' Re: - OpenVMS ever to be on Intel chip? ' Re: - OpenVMS ever to be on Intel chip? ! 9GB System Disk for an 8GB ES40 ? : Booting stand-alone with VMS 7.2-1 and fibre channel disksP Re: Cannot issue any system() calls from a C program running under a captive accP Re: Cannot issue any system() calls from a C program running under acaptive acco. Re: Dates (was Re: OpenVMS and Supercomputing). Re: Dates (was Re: OpenVMS and Supercomputing)P Re: Dumbing Down VMS with UNIX Elements? (was Re: OpenVMSEducational     ProgramP Re: Dumbing Down VMS with UNIX Elements? (was Re: OpenVMSEducationalProgram) EduP RE: Dumbing Down VMS with UNIX Elements? (was Re: OpenVMSEducationalProgram) EduP Re: Dumbing Down VMS with UNIX Elements? (was Re: OpenVMSEducationalProgram) Pro! How does one become a VMS guru ?? % Re: How does one become a VMS guru ?? % Re: How does one become a VMS guru ?? % Re: How does one become a VMS guru ?? % Re: How does one become a VMS guru ?? % Re: How does one become a VMS guru ??  Re: HP Printer on VMS 6.2  LICENSE PURGE ?  Re: LICENSE PURGE ?  Re: LICENSE PURGE ?  Re: Merging multiple disks MOUNT/BIND too slow ! Re: Obtaining 7.2-1 and TCPIP 5.1 ! Re: Obtaining 7.2-1 and TCPIP 5.1 ! Re: Obtaining 7.2-1 and TCPIP 5.1  Re: OpenVMS Educational Program  RE: OpenVMS Educational Program  Re: OpenVMS Educational Program  Re: OpenVMS Educational Program  Re: OpenVMS Educational Program  Re: OpenVMS Educational Program   Re: Possible security hole in...  Re: Possible security hole in...  Re: Possible security hole in...  Re: Possible security hole in... Splitting a Large File Re: Splitting a Large File  Re: TPU SORT procedure requested. Re: Volume Shadowing merge rates on Big Disks?. Re: Volume Shadowing merge rates on Big Disks?. Re: Volume Shadowing merge rates on Big Disks?. Re: Volume Shadowing merge rates on Big Disks?. Re: Volume Shadowing merge rates on Big Disks?. Re: Volume Shadowing merge rates on Big Disks?. Re: Volume Shadowing merge rates on Big Disks?. Re: Volume Shadowing merge rates on Big Disks?. Re: Volume Shadowing merge rates on Big Disks?. Re: Volume Shadowing merge rates on Big Disks?- Re: [INFO] ES40 EV67 is faster than its clock ! Re: [Q] skip [vms$common] parsing   F ----------------------------------------------------------------------  % Date: Thu, 15 Mar 2001 11:07:22 +0010 % From: paddy.o'brien@zzz.tg.nsw.gov.au 0 Subject: Re: - OpenVMS ever to be on Intel chip?5 Message-ID: <01K18252U2DU00AZIM@tgmail.tg.nsw.gov.au>   5 >On Mon, 12 Mar 2001 00:50:16 GMT, "Terry C. Shannon" # ><terryshannon@mediaone.net> wrote: 5 >>The OpenVMS Group already has a Marketing Director.  > 	 >Does it?  >  >		-jon.  A It's probably their euphemism for their "skeleton in the closet".    Regards, Paddy   ------------------------------   Date: 15 Mar 2001 06:10:01 GMT- From: djweath@attglobal.net (Dave Weatherall) 0 Subject: Re: - OpenVMS ever to be on Intel chip?5 Message-ID: <DTiotGxQ0bj6-pn2-dO13EFYdIgvz@localhost>   E On Tue, 13 Mar 2001 19:06:23, kaplow_r@eisner.encompasserve.org.mars   (Bob Kaplow) wrote:   f > In article <QUtr6.8$na.430@news.enterprise.net>, "NewsReader" <NewsReader@NotOnYourLife.Com> writes:N > > I read the tech .pdfs for Charon & it says for PC memory emulation is 16Mb* > > max. Surely this is a little limiting? > N > The current version emulates a MicroVAX-II. The MV2 was limited to 16 MB. So2 > it's as limiting as the hardware it's emulating. > J > An MV3000 is supposed to be in the works. And some folks probably need aH > 6000 or 7000 class emulator. I wonder if they can do SMP emulation :-)  " Could one run ELN on it I wonder.    --   Cheers - Dave.   ------------------------------  % Date: Wed, 14 Mar 2001 15:13:55 -0500 2 From: "Richard B. Gilbert" <DRAGON@compuserve.com>* Subject: 9GB System Disk for an 8GB ES40 ?7 Message-ID: <200103141514_MC2-C8D9-F785@compuserve.com>    Message text written by "Kark"H >Does anyone think a 9GB StorageWorks disk would be too small to contain the OSJ and the paging file for an 8GB memory option?  I'm kind of stuck with the=   9GB 3 disk if I want to do RAID1 with a KZPAC controller.  <   J How big do you want your page and swap files to be?  I run an Alphastatio= n J 200 off an RZ26; that's 1Gb and holds the system, page(524,928 blocks), a= nd/ swap(14,976 blocks)  files for a 96Mb system. =     4 I have an ES40 with 4Gb and it VERY SELDOM pages!  =    J A bigger concern might be a dump file.  If you need to write a full crash=  J dump for an 8Gb machine, only 8Gb of disk will do.  The dump file does no= t  have to be on the system disk!D The page file(s) need not be on the system disk either.  It's highlyJ recommended that you have at least a small one on the system disk.  If yo= u J expect to do a lot of paging, you will probably need several page files o= n  several different disks.  J I would suggest starting withat least  80,000 to 100,000 blocks of pagefi= leF on the system disk and at least two additional page files on differentJ disks; I'd make them 2,000,000 to 4,000,000 blocks each.  If you need mor= e J pagefile space or more spindles, adjust my numbers to fit your situation.=   ------------------------------  # Date: Thu, 15 Mar 2001 03:16:11 GMT $ From: Scott Vieth <svieth@wi.rr.com>C Subject: Booting stand-alone with VMS 7.2-1 and fibre channel disks ( Message-ID: <3AB0332F.2000401@wi.rr.com>  G These questions are for you brave souls who have gone to 7.2-1 and have C HSG80s connected to your VMS system.  I recently joined that crowd.   C Q1.  I swear that when I booted my 4100 (KGPSAs were installed and  ! cabled, HSGs were configged) from E the 7.2-1 CD, I couldn't see any of the DGA devices from "standalone  % environment".  Is that right?  Is the C 7.2-1 CD incapable of seeing fc disks when you boot the standalone   environment?  D Q2. Has anyone built another disk to boot standalone from using the ' @SYS$SYSTEM:AXPVMS$PCSI_INSTALL_MIN.COM G command procedure?  If you build it on a local SCSI disk, can you boot  * standalone from it and see your fc drives?  I Q3. Has anyone used that com to build a minimum boot disk on a different  3 fc disk (a disk other than your fc system disk) and , booted from it?  Can you see your fc drives?  C I spoke to a few folks from the CSC today and I got "That's a good  & question."  more than a few times. ;^)  H I don't have a test environment setup right now to test this.  Any tips . or pointers will help out.  Our next scheduledH window for downtime on this system is coming up on Sunday night so I'll   be able to test these things out first-hand.    Thanks,    -Scott , fc plumber :^)    ------------------------------  # Date: Wed, 14 Mar 2001 21:58:07 GMT - From: "news-server" <dpeacock@bigpond.net.au> Y Subject: Re: Cannot issue any system() calls from a C program running under a captive acc 7 Message-ID: <PPRr6.7$992.93@news-server.bigpond.net.au>    OK.   F So the Captive account , is setup to only run one COM procedure in the Sysuaf account. F The System() comand  actually  spawns a subprocess. which then creates4 another process, runnning the Captive COM procedure.H then it wants to run the comand you placed in System() and becuase its aK captive account wont let that happen. Because its end the process after the  Captive COM procedure finishes  J So you can either get the Captive.com to take the Command line and process it.    Cheers    1 "Norman Woo" <nwoo@videotron.ca> wrote in message 2 news:giotatsp5aes3i43eh8ln2k6qt4aha27jg@4ax.com...
 > Hi folks > H > We are porting over an application coded in C from a DEC VAX VMS 5.5-2F > to a Compaq Alpha DS20E OpenVMS 7.1-2.  Our users accounts are setupF > as captive accounts.  One of the things that we were able to performH > under the old environment was to issue a system() call from within the> > application to spawn a subprocess.  However, under the newerH > environment, we are now getting an error return code from the system()F > command.   Checking the manuals, it says that we are able to issue aF > spawn command through the /TRUSTED flag.  We tried this and it stillB > fails.  Issuing any system calls, for example, a simple DIR also	 > failed.  > @ > The funny thing is that running a DCL script under the captiveE > account, we can issue any system calls with no problems.  It's only E > under the C application where this fails.  Is there a compiler flag H > that we should be using?  The Compaq C Compiler is version 6.2-003 andB > we are using the /STANDARD=VAXC flag for the porting from VAX to	 > COMPAQ.  > , > Anyone has this working please contact me. >  > Thanks in advance. >    ------------------------------  # Date: Wed, 14 Mar 2001 21:58:08 GMT - From: "news-server" <dpeacock@bigpond.net.au> Y Subject: Re: Cannot issue any system() calls from a C program running under acaptive acco 7 Message-ID: <QPRr6.8$992.93@news-server.bigpond.net.au>    OK.   F So the Captive account , is setup to only run one COM procedure in the Sysuaf account. F The System() comand  actually  spawns a subprocess. which then creates4 another process, runnning the Captive COM procedure.H then it wants to run the comand you placed in System() and becuase its aK captive account wont let that happen. Because its end the process after the  Captive COM procedure finishes  J So you can either get the Captive.com to take the Command line and process it.    Cheers    2 <paddy.o'brien@zzz.tg.nsw.gov.au> wrote in message/ news:01K177W233SI00B05Q@tgmail.tg.nsw.gov.au...  > Danco@pebble.org wrote: L > >On Tue, 13 Mar 2001 22:26:07 -0500, Norman Woo <nwoo@videotron.ca> wrote: > >  > >> It's onlyH > >> under the C application where this fails.  Is there a compiler flagK > >> that we should be using?  The Compaq C Compiler is version 6.2-003 and E > >> we are using the /STANDARD=VAXC flag for the porting from VAX to  > >> COMPAQ. > > H > >How about calling lib$spawn() directly instead of system().  Then you= > >can set the CLI$M_TRUSTED flag bit in the flags parameter.  >  >  > First point, to Norman: C > Bite the bullet.  Re-compile under DEC/Compaq C (i.e. without the  /standard). I > It's more up-to-date and does not fall into the multitude of traps that 	 the VAX c L > compiler did.  It's based on the old Kernighan and Ritchie stuff which has beenI > way superseded.  You'll likely get a lot of warnings, but if corrected,  your8 > program is more portable, and more current C standard. > D > There is unlikely to be a CC compiler flag.  Understand the issues	 regarding H > captive or restricted.  And what can you do in DCL (i.e., the command) that youE > cannot do from system() -- I would judge that you cannot do it from 	 lib$spawn E > either, but I do not know the implications of the flag bit that Dan 
 mentioned. >  > Regards, Paddy >  > Paddy O'Brien, > Transmission Development,  > TransGrid, > PO Box A1000, Sydney South,  > NSW 2000, Australia  >  > Tel:   +61 2 9284-3063 > Fax:   +61 2 9284-3050( > Email: paddy.o'brien@zzz.tg.nsw.gov.au > G > Either "\'" or "\s" (to escape the apostrophe) seems to work for most  people, = > but that little whizz-bang apostrophe gives me little spam.  >    ------------------------------   Date: 15 Mar 2001 00:02:38 GMT% From: afeldman@elsewhere.gfigroup.com 7 Subject: Re: Dates (was Re: OpenVMS and Supercomputing) * Message-ID: <98p0qu$ruu$1@news.netmar.com>      Djesys posted:    O >------------------------------------------------------------------------------  -- > 8 >From: "David J. Dachtera" <djesys.nospam@earthlink.net> >Newsgroups: comp.os.vms8 >Subject: Re: Dates (was Re: OpenVMS and Supercomputing)& >Date: Tue, 13 Mar 2001 20:24:20 -0600A >Path: news.nntpserver.com news-out.nibble.net news-in.nibble.net 7 news.maxwell.syr.edu sn-xit-03 sn-post-01 supernews.com   >corp.supernews.com not-for-mail > G >Had to post this to the newsgroup. Your return e-mail address is bogus G >and i didn't want to take the time to figure out how to demangle it...    9 Right under it it said to remove elsewhere. Not too hard.    G *** SHEEEEESH! I WAS DEFENDING YOUR ARGUMENT THAT 12:00 PM WAS NOON AND F NOW ALL YOU DO IS ATTACK EVERYTHING I SAY. AND SINCE I AGREED WITH YOU2 ABOUT THAT POINT, YOU'RE ATTACKING YOURSELF!!! ***    > ) >At 12:00 PM 03/12/2001 -0500, you wrote:  >>I >>Quoted from a newsreader that actually has the article, but posted from 1 >>another from which I can actually post a reply!  >> >>> Message 23 in thread9 >>> From: David J. Dachtera (djesys.nospam@earthlink.net) ; >>> Subject: Re: Dates (was Re: OpenVMS and Supercomputing)  >>> Newsgroups: comp.os.vms ! >>> Date: 2001-03-09 19:47:12 PST  >>* >>> afeldman@elsewhere.gfigroup.com wrote: >>> > > > [snip]D >>> > > > "David J. Dachtera" <djesys.nospam@earthlink.net> wrote in, >>> > > > <3A971A4A.83B74895@earthlink.net>:
 >>> [snip]    [...]    
 >>> [snip]L >>> Well, remember too, o modern one, that the 12-hour clock has been around >> ^^^^^^^^^^^^ H >>So much for your request for not attacking posters. And I was actually- >>defending your argument! Gee, thanks a lot.  > G >Well, it's not an attack, believe it or not. What I find silly is that H >young(er) people are so quick to dismiss that which has its root in theB >years before their own birth just because it's "old". It has beenF >speculated that GM is dropping the Oldsmobile product line because ofD >the first syllable of the name - "old". If we do not learn from theF >mistakes of the past, we are doomed to repeat them. By dismissing theE >past out of hand, we condemn ourselves to repeat the mistakes of our  >predecessors.   F I reject overly literal interpretations of AM and PM. If you interpretH everything else that literally, you'll never be able to communicate withH anyone. I reject the strict literal Latin definitions not simply becauseF they are too old, but because they are to old to be relevant. Newton'sD theory of gravity is about as old, but is still relevant. It is rareD that anyone needs to use General Relativity (a theory of gravity) toE perform any gravimetric or orbit calculations because for terrestrial H uses (and for trajectories through our Solar System), Newton's theory isE more than accurate enough. OK? This is an example of something that's E quite old, but still immensely useful. General Relativity is good for E cosmology, calculating the decay rate of the orbital period of double B pulsars, and the like. But ante meridiem and post meridiem are not useful for 12:00.    I >>> for a very long time, also. Back then, the questions of night and day H >>> were a little more obvious than in today's global community ("Night?L >>> Where? and "Day? Where?"). The need for 24-hour time is relatively new -1 >>> since the dawn of global navigation, I think.  >>B >>What's your point? Magellan circled the earth quite a while ago. > G >....and long *AFTER* the invention of what we now know as the "clock".  >What'  *YOUR* point?    C What questions of day or night are you talking about? We're talking F about 12:00AM/PM *** LOCAL TIME ***. It is quite easy to tell day from night locally.    >  >> Besides, I >>we're not talking about night and day. We're also not talking about the  needM >>for time zones. We're talking about how to interpret 12:00 AM and 12:00 PM. $ >>Try to stick to the subject, okay? >  >Funny. Thought I had...    Nope.     [snip] >>M >>Your taking the word "midnight" a little too literally. And you're actually E >>wrong even in the nitpicking sense. The equation of time (as in the 	 analemma, L >>that figure-8 that desribes the sun's track if you take a photograph of it atL >>the same time every day) means that midnight actually occurs a few minutesL >>late or early on the equinoxes (I don't have a chart of the analemma handy to. >>look up when it's early and when it's late). >>A >>Actually, this depends on how you define "middle of the night".  > > >Rather literally: the mid-point between dusk and first light.   H And how do you define "dusk" and "first light"? There is no clear momentF when either occurs. What are you talking about? Nobody cares about theH exact middle of the night. But midnight is 12:00 AM in the AM/PM system,D and 0000 hours in the 24 hour system. What else do you need to know?    >  >> The argument IeK >>just gave would define "middle of the night" as 12 hours after noon wherepI >>noon is determined from "local time". (You could even nitpick *that* byaL >>saying that half a day has passed so that "true midnight" has shifted ever soJ >>slightly, but let's not go there!) Local time is determined by where the suniK >>actually is. But because of the equation of time, the sun gets as much asaF >>approx. 15 minutes slow or fast. This is due to both the tilt of the earth's?J >>axis (23.5 degrees) and the fact that the earth's orbit is very slightlyM >>elliptical. The tilt causes the sun to move eastward relative to the "fixedEJ >>stars" at an uneven rate. The earth's being in an elliptical orbit means thatK >>the earth speeds up and slows down slightly which has a smaller effect onu the H >>sun's motion against the fixed stars. The deviation of local time from4 >>uniform time is descrbied by the equation of time. >>J >>Obviously, your knowledge of astronomy is not even at the amateur level. >i >Not worthy of comment.   G That's because I'm right.     >EJ >>> for the ninth hour since daybreak/sunrise - does the sun rise at 03:00H >>> (a.m.) where you are?) are of little value, really. Noon is a moment >>9 >>You're just proving my point about archaic definitions.n >  >How so?  rE You use the archaic definition of "night hour since daybreak/sunrise"aG and show that its literal interpretaion is a ridiculous sunrise at 3:00eD am (actually, in some areas the sun can rise that early!). So you'veH shown that the archaic definition is not of any use, which is exactly my point!  e >eJ >>> (choose a length). Midnight is frequently confused between "the end of: >>> (x)day" (24:00) and "the beginning of (y)day" (00:00). >>L >>I believe I said all that. What about A.D. and B.C.? Historians agree that5 >>Jesus was born somewhere between maybe 2 and 6 B.C.m >e@ >Historians also agree that the reason for this is the lack of aH >consistent definition of calendars and time. Seems our problems are not# >so different from "archiac" times.S  oD Maybe AM/PM and A.D. and B.C. are a problem for you, but most of the rest of us have it figured out.   t I'll repeat it:   eE 12:00 AM is at midnight, or the 60-second interval after 11:59 PM, if-> you wish, or the time between 11:59 PM and 12:01 AM, whatever.  2F 12:00 PM is the 12:00 that occurs or starts at noon, depending on your
 viewpoint.  IG The current year is 2001 A.D., regardless of what A.D. orignally meant. E The guy who started the system in the sixth century blew it by 2 to 6a years.  o >  >> So the whole A.D./B.C.d >a; >Anno Domini (Year of (Our) Lord) = (the) Common Era (C.E.)s >o, >Before Christ = Before the Common Era (BCE)  cE These definitions don't work. They are simply the original intent and5F short definitions of convenience, and all that matters now is that theF current year is A.D. 2001 and other years can be referenced therefrom.E Common era can be interpreted as A.D. 1 and forward and it works, butw$ A.D. and B.C. are still much in use.  K >oC >>system falls apart using literal interpretations. And the literals: >>interpretation of A.D. depends on your religous beliefs. >tJ >....or cultural/genetic heritage. What year is it in the Jewish calendar?# >....Chinese Calendar? ...(others)?    G The Hebrew year is 5761. The Chinese year, I don't know. What does that D have to do with this? Could you be a little more vauge? What is your point?  oD Now, most of the civilized world goes by the Gregorian calendar withB A.D. and B.C. defined as I have already defined them. The reason IF brought up A.D./B.C. is to illustrate the pointlessness of relying too much on literal translations.0  1 >3 >> The "sensible"RK >>interpretation of A.D. and B.C. is that the current year is A.D. 2001 andG you0I >>count backwards from there, with 1 B.C. being the year before A.D. 1, 2t B.C.L >>being the year before 1 B.C., etc. The sensible interpretation of 12am andI >>12pm is 0000 and 1200, respectively. *** This is what everyone is usingfF >>anyway. *** (I'm just using A.D./B.C. to illustrate the absurdity ofL >>insisting on overly literal interpretations of things like AM/PM, etc., so it >>*is* relevant.)  >>L >>> Anyway, this is rather an old thread and most folks have forgotten it or( >>> have added it to their kill filters. >>; >> Well, obviously, it didn't make into *your* kill filter!g >c) >....because you sent it to me by e-mail!o  iG So why didn't you set up a kill filter for your e-mail? You can't knockhC a thread and then keep responding to it. What sense does that make?l NONE.e  o >eC >Are you trying to take debate lessons from Bill Todd or something?tB >Don't! You've seen what he does when HE's backed into a corner...  oH Only *you* thinks he was backed into a corner. And I may well follow hisF example if you keep posting nonsense. And after all this, I don't evenB know where you stand on this issue and I don't even care any more.  gG *** SHEEEEESH! I WAS DEFENDING YOUR ARGUMENT THAT 12:00 PM WAS NOON ANDeF NOW ALL YOU DO IS ATTACK EVERYTHING I SAY. AND SINCE I AGREED WITH YOU2 ABOUT THAT POINT, YOU'RE ATTACKING YOURSELF!!! ***  -F My point is that the original Latin, or any translations (phase I, II,H or any other phases) you wish to make, of AM and PM, are not relevant inF today's world and any insistence on using them is not helpful. Noon is= 12:00:00.000...PM and midnight is 12:00:00.0000...AM, period.s  n >t >--  >David J. Dachtera >dba DJE Systems >http://www.djesys.com/r >a; >Unofficial Affordable OpenVMS Home Page and Message Board:   >http://www.djesys.com/vms/soho/ > G >This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings" >is to be expected.  > A >Feel free to exercise your rights of free speech and expression.e > G >However, attacks against individual posters, or groups of posters, are  >strongly discouraged.  V) I suggest you re-read your own sig above.?  f >u Alan E. Feldmanc afeldman@elsewhere.gfigroup.comn  o remove	 elsewherey    O  -----  Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web  -----eM   http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groupsCI    NewsOne.Net prohibits users from posting spam.  If this or other posts L made through NewsOne.Net violate posting guidelines, email abuse@newsone.net   ------------------------------  % Date: Wed, 14 Mar 2001 21:03:19 -0600i7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>t7 Subject: Re: Dates (was Re: OpenVMS and Supercomputing) - Message-ID: <3AB030F7.B4181B1F@earthlink.net>s  & afeldman@elsewhere.gfigroup.com wrote:+ > >At 12:00 PM 03/12/2001 -0500, you wrote:0; > >>> From: David J. Dachtera (djesys.nospam@earthlink.net)u= > >>> Subject: Re: Dates (was Re: OpenVMS and Supercomputing)a > >>> Newsgroups: comp.os.vms # > >>> Date: 2001-03-09 19:47:12 PSTe > >>, > >>> afeldman@elsewhere.gfigroup.com wrote: > >>> > > > [snip]F > >>> > > > "David J. Dachtera" <djesys.nospam@earthlink.net> wrote in. > >>> > > > <3A971A4A.83B74895@earthlink.net>: > >>> [snip]I > >Well, it's not an attack, believe it or not. What I find silly is that J > >young(er) people are so quick to dismiss that which has its root in theD > >years before their own birth just because it's "old". It has beenH > >speculated that GM is dropping the Oldsmobile product line because ofF > >the first syllable of the name - "old". If we do not learn from theH > >mistakes of the past, we are doomed to repeat them. By dismissing theG > >past out of hand, we condemn ourselves to repeat the mistakes of our  > >predecessors. > 7 > I reject overly literal interpretations of AM and PM.p  E Good luck telling and recording time on Planet Earth! ...or any otherh planet, for that matter!   > If you interpretJ > everything else that literally, you'll never be able to communicate with	 > anyone.o  B I doubt any one of any scientific background would agree with thatH statement. Literal definitions and interpretations are the *ONLY* way toC conduct *ANY* kind of scientific activity, much less any meaningfula human communication.  B > I reject the strict literal Latin definitions not simply because? > they are too old, but because they are to old to be relevant.w  F Really? Has there been a change in global geography or navigation thatD the rest of us have not yet heard about? Do we not still measure the6 earth's surface in longitude (meridians) and latitude?  G I'm fairly certain that these units of measure are still in use. I just B sold one house and bought another. The legal descriptions of theirD locations are expressed in terms (among others) of their offset fromH "the third principal meridian". So, I feel confident in saying that "theG old, latin terms" remain relevant, and will remain so for many decades,e even centuries to come.-  
 > Newton'sF > theory of gravity is about as old, but is still relevant. It is rareF > that anyone needs to use General Relativity (a theory of gravity) toG > perform any gravimetric or orbit calculations because for terrestrialrJ > uses (and for trajectories through our Solar System), Newton's theory isG > more than accurate enough. OK? This is an example of something that'saG > quite old, but still immensely useful. General Relativity is good forhG > cosmology, calculating the decay rate of the orbital period of doublepD > pulsars, and the like. But ante meridiem and post meridiem are not > useful for 12:00.W  F Yes, they are. They are the *ONLY* meanings that are globally acceptedH across the many scientific disciplines. The fact that they are expressedG in a language which is not widely in use today is meaningless. "AM" haseC always meant "before the (sun crosses the) meridian", and it alwaysrH will. "PM" has always meant "after the (sun cross the) meridian", and it always will. Get over it.>  H Scientists today frequently use UTC. Not so of some early scientists whoG recorded their findings in their journals in terms of local time, AM orrD PM. In order to determine the meaning of their findings by reviewing; their journals, AM and PM *MUST* have meaning. Get over it.m   > [snip]7 > What questions of day or night are you talking about?h  F You'll have to tell me. I don't recall, and reviewing these posts does; not reveal, my asking or raising questions of day or night.t   > We're talkingfH > about 12:00AM/PM *** LOCAL TIME ***. It is quite easy to tell day from > night locally.  ) Well, I'm glad we can agree on SOMEthing!n  h > >u
 > >> Besides, K > >>we're not talking about night and day. We're also not talking about thet > needO > >>for time zones. We're talking about how to interpret 12:00 AM and 12:00 PM.   H No, *YOU'RE* trying to interpret 12:00 AM and 12:00 PM. I explained that8 in a much earlier post (one of many that pissed BT off).  & > >>Try to stick to the subject, okay? > >A > >Funny. Thought I had... >  > Nope.i   In your opinion.  9 > [snip]C > >>Actually, this depends on how you define "middle of the night".  > >i@ > >Rather literally: the mid-point between dusk and first light. > 1 > And how do you define "dusk" and "first light"?i  H One of the government agencies who defines this is known as the FAA. PerA the FAA, dusk is defined (in Chicago's latitude) as the half-hourRF immediately following local sunset (dont' you *DARE* ask what "sunset"= is!), and dawn ("first light" is inaccurate) as the half-hour-E immediately prior to local sunrise (no, don't even ask what "sunrise" 
 is, either!)..   > There is no clear momentH > when either occurs. What are you talking about? Nobody cares about theJ > exact middle of the night. But midnight is 12:00 AM in the AM/PM system,F > and 0000 hours in the 24 hour system. What else do you need to know? > 
 > > [snip]L > >>Obviously, your knowledge of astronomy is not even at the amateur level. > >t > >Not worthy of comment.- >  > That's because I'm right.d  	 Prove it.a   > [snip]; > >>You're just proving my point about archaic definitions.a > > 
 > >How so? > G > You use the archaic definition of "night hour since daybreak/sunrise"2I > and show that its literal interpretaion is a ridiculous sunrise at 3:00I > am  H Go back and read the original post and I'm sure it will clarify that for you.  C > (actually, in some areas the sun can rise that early!). So you'vecJ > shown that the archaic definition is not of any use, which is exactly my > point!  H Excuse me? I've only shown that the middle English from which "non" (theA ninth hour since sunrise) evolved into "noon" is not a meaningfuluG definition of "noon" in modern English. I don't know where you got that1 rubbish.   > [snip]F > Maybe AM/PM and A.D. and B.C. are a problem for you, but most of the! > rest of us have it figured out.n  H Now, tell me: exactly where did THAT come from? Name (quote) one posting< where I expressed any "confusion" about what AM and PM mean.   > [snip] > >c > >> So the whole A.D./B.C.^ > >^= > >Anno Domini (Year of (Our) Lord) = (the) Common Era (C.E.)  > >c. > >Before Christ = Before the Common Era (BCE) >  > These definitions don't work.,  E Well, perhaps they don't work for you. They work fine for the rest ofq
 the world.  ) > They are simply the original intent andfH > short definitions of convenience, and all that matters now is that theH > current year is A.D. 2001 and other years can be referenced therefrom.  - So, *THIS* is the mystical "year zero", huh? e  ? I doubt that the scientific community is prepared to adopt yourgD definition of 2001 AD as the "zero" point on "The Feldman Timeline".  G > Common era can be interpreted as A.D. 1 and forward and it works, butn& > A.D. and B.C. are still much in use.  $ See? You just contradicted yourself.   > [snip]F > Now, most of the civilized world goes by the Gregorian calendar withD > A.D. and B.C. defined as I have already defined them. The reason IH > brought up A.D./B.C. is to illustrate the pointlessness of relying too > much on literal translations.n  @ Literal translations are the *ONLY* translations that make *ANY* scientific sense.    > [snip]H > My point is that the original Latin, or any translations (phase I, II,J > or any other phases) you wish to make, of AM and PM, are not relevant in@ > today's world and any insistence on using them is not helpful.  > According to you. I've yet to find anyone who agrees with you.  	 > Noon isd? > 12:00:00.000...PM and midnight is 12:00:00.0000...AM, period.m  D Seems to me I read that somewhere - maybe it was in a posting I made back around 23-Feb-2001.  E AM and PM are scientifically defined and are globally accepted by thetF scientific, aviation and maritime communities, even though they preferF to use UTC (Universal Coordinated Time) to avoid confusion across time zones in a global society. a  G These definitions have not changed for many, many years. They remain astH accurate and as relevant as they were in the decades before the birth ofG any currently active participant in this group, and will remain so long2 after we're gone.T   Get over it.   -- s David J. Dachtera  dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/   F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.i   ------------------------------  % Date: Wed, 14 Mar 2001 21:47:40 +0000-) From: Christof Brass <brass@infopuls.com> Y Subject: Re: Dumbing Down VMS with UNIX Elements? (was Re: OpenVMSEducational     Programw, Message-ID: <3AAFE6FC.D628A3DE@infopuls.com>   Brian Wheeler wrote: > . > In article <3AAE5EA9.311BD545@infopuls.com>,5 >         Christof Brass <brass@infopuls.com> writes:o > > Brian Wheeler wrote: > >>. > >> In article <3AAE30C5.20D69B88@bbc.co.uk>,< > >>         Tim Llewellyn <tim.llewellyn@bbc.co.uk> writes: > >> > > >> > > >> > Jan Vorbrueggen wrote:e > >> >3 > >> >> Christof Brass <brass@infopuls.com> writes:  > >> >>dM > >> >> > > BTW, in at least one case the use of Unixy C code has resulted iniV > >> >> > > relaxation of a not-so-useful restriction in a set of VMS system services.B > >> >> > What was this relaxation? Didn't it break existing code? > >> >>nP > >> >> The output format of $ASCTIM for delta times is defined to be limited toR > >> >> 10000 days minus a tick; the binary format itself, useful for calculationsO > >> >> of all sorts, is of course not so restricted (the limit is around 32000.T > >> >> years). However, all other time-related system services were also restrictedU > >> >> to that 10000 day limit. This broke when the audit server used the delta timehP > >> >> format to compute a time_t - 10000 days after 1-JAN-1970. So this changeA > >> >> actually made existing code work, instead of breaking it.  > >> >>  > >> >>         Janl > >> >3 > >> > However, 1-JAN-19970 is a unix thing anyway.o > >> > > >> > >> <sarcasm>I > >>         Yeah, nobody but a unix loser would ever use 1-JAN-1970 as af > >> base for delta time!  > >> </sarcasm>  > >>8 > >> Isn't this whole topic getting a little bit stupid? > >>Q > >> Its been a constant Unix vs VMS war which, as we all know, is pointless.  IfeO > >> Compaq decides to add more unix interfaces on top of VMS, what's the harm?nM > >> How does adding an interface dumb down the system, or lower its quality?  > >e2 > > This depends where it is implemented and what.i > > If it's in the kernel then it makes things more complicated and will reduce quality in many respects.n > > If the UNIX API requires functionality which is in contradiction to VMS system services the view of the system might be inconsistent.e > O > Granted, but since nobody knows how its going to be implemented, then there'seN > no way one can argue that adding unix apis will bring the quality of the VMS > kernel down.   This was exactly my point: before the choir applauses it must be clear how it is accomplished. If it is done the wrong way the outcome will be a disadvantage.   > >> IfdO > >> it is buggy, its not unix's fault...but the implementation on VMS.  AddingcL > >> interfaces to an OS doesn't weaken it...it can only strengthen it.  DidL > >> adding a C compiler to VMS lower the quality of the OS?  Did the TCP/IP0 > >> libaries from Tru64 unix lower the quality? > >og > > Libraries and tools are not part of the kernel. I wonder what your experience in OS development is.o > K > Again, we don't know how the Unix API would be added to VMS, so it may be I > a tools/libraries issue and not touch the kernel at all.  Ok, that is a ) > bit unlikely, but still, a possibility.a   See above. And there is still the problem of offering the wrong way (the UNIX) to solve things which will complicate the day to day work of VMS admins, programmers and users.  P > I was arguing from the point that there seems to be an overriding feeling that? > anything related to unix is unclean and must not be near VMS.    Exactly. Dump UNIX which is pure crap (not only from the architecture point of view but also from point of implemetation quality, user interface aso; only the price might be okay if you get payed for using it).  O > >> There are two major APIs out there:  Unix and Windows.  If compaq wants totS > >> expand VMS's marketshare, it is going to have to provide a good implementationgN > >> of one of those two...and I don't see the Windows API being chosen.  OnceN > >> developers see VMS as "just another target", they're more likely to startO > >> writing pieces of code which take advantage of VMS...compared to now where ) > >> a port is nearly a complete rewrite.? > > I > > Is it that difficult to understand that we don't need another UNIX???a > G > That's fine...except that unless VMS conforms to something other than/L > itself, vendors are not going to bother porting software to it because itsH > not important (or: profitable) to justify a complete rewrite to make a > VMS application.  &Why isn't that bad? Does any Micro$oft product conform to anything other than itself? To what does a UNIX version conform? Why would it be helpful to have UNIX apps on VMS?? If you want to take advantage of VMS you have to write a real VMS app. What is the point in having another UNIX version?  X > > Think about Apple. Would Steve Jobs argue that Apple should drop their superior API," UI and so on for UNIX or Windoze?? > M > Have you seen Mac OS X?  It is _BSD_ with Apple specific APIs built on top.tI > It is another unix.  You can run unix apps and mac apps...so if someone G > want to run an open source database it doesn't take months to make it $ > compile (let alone work correctly)  We all know this. Do you know NeXTSTEP? Would any Mac user accept a UNIX app? I know of a long term Mac user who is afraid of MacOS X because he thinks that he might get in touch with the UNIX underneath. But anyway: MacOS X adds something on top, doesn't change the kernel. MacOS X adds functionality instead of dublicating it. Having UNIX API on VMS is redundant, superflous and completely unecessary.l   > >Who would like to have another Windoze instead of a Mac? There are other much more efficient and technically much better solutions to the "VMS problem" (how some of this NG would phrase the lack of a few desktop and a few enterprise apps). > K > What is that solution?  Compaq (and Digital's) Marketing always seemed toaJ > be focused on preaching to the choir, but that doesn't help.  OutrageousH > costs for OS licenses doesn't help.  No entry-level-priced machines to# > seed the market isn't helping....2  } I published several techical solutions already and I'm getting tired now - some people will be happy to read that, I know ...s7 You will find them by yourself they are not farfetched.d   >  > Brian    ------------------------------  # Date: Wed, 14 Mar 2001 20:27:45 GMTs4 From: "Terry C. Shannon" <terryshannon@mediaone.net>Y Subject: Re: Dumbing Down VMS with UNIX Elements? (was Re: OpenVMSEducationalProgram) Edur< Message-ID: <5vQr6.4116$mH4.1667452@typhoon.ne.mediaone.net>  - <steven.reece@quintiles.com> wrote in messagerB news:OFB16FE0E4.B7AA644C-ON80256A0F.005CD2EA@qedi.quintiles.com... >gH > But I seem to remember that even Gartner are looking on VMS positively
 > these days.) > Times do indeed change.... > Steve.  G Well, given that VMS revenues did not fall off consistent with DECpaq's K expectations (remember the 97 prediction that the installed base would falleI to ~200K systems by 2000-2001?) this is not entirely surprising. But just E think what CPQ could do if it adopted a proactive marketing strategy.i   ------------------------------  % Date: Wed, 14 Mar 2001 15:05:46 -0600t+ From: Christopher Smith <csmith@amdocs.com>sY Subject: RE: Dumbing Down VMS with UNIX Elements? (was Re: OpenVMSEducationalProgram) Edu L Message-ID: <3B55D7F383B0D31197D9009027541CBF0BDD546D@cmiexch1.cmi.itds.com>   > -----Original Message-----; > From: Terry C. Shannon [mailto:terryshannon@mediaone.net]   < > Well, given that VMS revenues did not fall off consistent  > with DECpaq'sm> > expectations (remember the 97 prediction that the installed  > base would falla7 > to ~200K systems by 2000-2001?) this is not entirely 9 > surprising. But justG > think what CPQ could do if it adopted a proactive marketing strategy.t  K Yep, and when you're done with that, just imagine what could happen if pigsh
 had wings. :)t  B Seriously, how long have we been waiting on a "proactive marketing
 strategy?"   Regards,   Chrisp  ! Christopher Smith, Perl Developers Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");o 'd   ------------------------------  % Date: Thu, 15 Mar 2001 00:24:16 +0000e) From: Christof Brass <brass@infopuls.com>eY Subject: Re: Dumbing Down VMS with UNIX Elements? (was Re: OpenVMSEducationalProgram) Pron, Message-ID: <3AB00BB0.D182A547@infopuls.com>  @ Okay you hit a nerve and that's why I responde to your bullshit.   Brian Wheeler wrote: > . > In article <3AAEB3E0.285370BF@infopuls.com>,5 >         Christof Brass <brass@infopuls.com> writes:e > > Fred Kleinsorge wrote: > >>7 > >> Not to speak for the US DOD, OpenVMS, or Compaq...c > >>L > >> DII/COE is an attempt to create a magic bullet that allows code re-use.J > >> This would allow code that was written for mission X to be reused forQ > >> mission Y.  This hasn't really happened yet.  None the least of the problemseM > >> is figuring out how those developing the code for mission X will get any O > >> benefit (read: profit) by allowing their code to be re-used for some other)C > >> mission.  So in current use, you end up with Segments that aresM > >> architecture-specific (which you have anyway, since binary compatability O > >> isn't a goal), and which use vendor specific features.  BUT these guys aretK > >> serious, and eventually there will be a lot of COE software in the DODl > >> world.e > >>O > >> The unfortunate aspect of DII/COE is that the design center of those doingtO > >> the development was Sun/Solaris (being practical, they also had to includehJ > >> Windows - which has it's own features and non-features).  So what COEL > >> provides is a common look & feel for the application environment, whichN > >> tends to drill down all the way to the UNIX command line interfaces.  YouO > >> also have some "standards" - like POSIX and JAVA - which if people writingiD > >> new segments adhere to, would allow source level compatability. > >>O > >> VMS COE (the product) is not something that will be generally available to P > >> *anyone* off the street.  It is a product that includes the OS - as well as= > >> the COE environment and other required layered products.n > >>P > >> Long term, the OS capabilities that were required, will show up in the baseM > >> OS.  The intent is to make the C interfaces on VMS compatable with POSIXsQ > >> (more likely long term - UNIX98 or LINUX).  This will make porting code fromsO > >> UNIX/Linux a simpler task - no different than any generic UNIX->UNIX port.lN > >> In addition, there will also be a shell environment that would allow UNIXP > >> users to get something more familiar than DCL.  Lastly are things like fileJ > >> system modifications that allow UNIX semantics and syntax to be used. > >>Q > >> This does not "replace" anything that VMS currently does, or even weaken it.oP > >> All the capabilities are incremental, or supplemental.  But as always, poorM > >> UNIX code will work poorly, and good UNIX code will work well.  I expect2P > >> that when someone wants the code to "mesh" into a VMS environment, they mayM > >> have work to do beyond a simple port - or they can choose to live with ar > >> UNIX fish in a VMS pond.a > >> > >>  _Freda > >> > > l > > I'm shocked. It's by far worse than I thought. This could be an important step to the real death of VMS.d > > - The business effect is *very* doubtful if these COE additions are only there for DoD projects. > L > Indeed, it would be, but if it helps port more software to VMS then it can! > have positive business effects.    Wrong. Having another UNIX is no advantage. Everybody who can afford VMS can afford another PC to run Linux, Solaris or whatever. No need for VMS to run UNIX crap SW.   > > - Writing SW for a niche is the stupidest thing you can do. SW should be sold to as many customers as possible because copying SW is almost free.( > M > YEP, WRITING SOFTWARE FOR NICHE MARKETS IS STUPID, WHICH IS WHY VMS IS VERY J > NEARLY DEAD.  If the COE initiative allows 'commodity' unix source to be? > compiled on VMS then VMS is that much less of a niche player.v   Idiot. *IDIOT*.e VMS is not dead. VMS is artificially made to a niche OS by several other idiots like you. Study history! Stay away from VMS, you don't deserve it! Use UNIX! Use UNIX SW.   >  > > - Offering bad ways like UNIX shells to accomplish tasks is a safe method to kill the productivity of VMS. Today we know how things are solved properly. Tomorrow we will never know.  > L > Get off it.  UNIX != "bad ways", no matter how many times you keep tellingN > yourself that.  Its different.  That's all.  VMS has one bad side to it:  noN > matter how well designed it is, it is PROPRIETARY.  Unix, as a whole is not,O > which gives it a huge advantage in my book over VMS.  With unix I can move to05 > another vendor if there are quality or cost issues.s  [You don't understand a clue. This proprietary argument has long disproved. UNIX and Windoze are another form of beeing proprietary with UNIX having the disadvantage of never beeing the same if you change the vendor. If 60% of market were owned by VMS nobody would talk about proprietarity. Read the UNIX-Haters Handbook! Leave VMS alone! Use UNIX!   z > > I'm too tired to continue this list. Every educated engineer will understand that this is a major attempt to kill VMS. > O > If by "educated" you mean "anything but pure VMS is evil and we don't need tolI > be interoperable with anyone but ourselves", then I guess you're right.    Silly.   > > My hope and wish: the good VMS engineers stay with the normal version. The COE version will be so crappy and full of bugs that it will never be usable.f > P > This is an interesting statement.  So, anything Unixy is so inheritly unstableJ > that just by implementing it brings the whole OS down?  You're on crack.N > If they do a shit-awful job of bringing unix services to vms, then its their > own damned fault.  Period.  Stupid. As explained several times: introducing unecessary complexity, superflous or redundant functions and ways to accomplish tasks which are in contradiction to the desing principles of VMS is a safe way to ruin it all. This has nothing to do with implementation quality.  L > Attitudes like this is why VMS is dead.  Its a wonder that TCP/IP was everH > added to VMS with attitudes like this....DECNet is the pure networking2 > protocol!  LAT is the way to true enlightenment!  Do you like democracy?? You know, the kind of organising a state in which the people who have money buy the people who simulate decision processes (politicians) or a dumb majority can decide if one plus one is three or four? Is TCP/IP better because the majority is using it?c  K > WAIT A MINUTE!  If VMS is so great, and unix so bad, why is it that I spyn > this line in your headers: > 9 > X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.0.36 i586)n > J > Huh.  Looks like you're just a troll...or a hypocrite.  Not only are you8 > using a unix to do your mail, you're doing it on a PC. >  > Ugh. > Brian:   As I stated several months ago: I'm in a process to moving back to VMS because I'm tired of the wrong promises of UNIX land. UNIX is crap. Believe me! I have 7 years first hand experience mostly with Solaris and Linux, but some others also.  [ I also publicly offered to put money into a fund to get a full VMS Opera port. No response.e  Q Do you know on what platform Navigator has been developed? Could it be UNIX crap?a Navigator is crap. I use it to avoid Micro$oft although some people say the IE is the better browser. If there is a decent VMS browser available I'll switch to that.s  2 Do you think that your contribution has any value?   Any questions?   ------------------------------  # Date: Wed, 14 Mar 2001 22:29:09 GMTf, From: "Dr Evil !" <sbudak1@optushome.com.au>* Subject: How does one become a VMS guru ??C Message-ID: <VgSr6.11222$pG5.39608@news1.rdc1.nsw.optushome.com.au>n  H Howdy Guys, I'm interested in getting into VMS and am after some helpful advice on doing just that.  H Most of my qualifications thus far are Microsoft based, but I have spentD time at uni doing a Computer Science degree and have solid amount of industry experience.  K But as you can imagine, the brain dead simplicity and lack of any real truelG enterprise ability in the MS product (as well as not wanting to just be67 another MS drone) has lead me to look for alternatives.t  C I love Unix, I love Linux and enjoy playing with them, but am truly@I impressed by what I have heard of VMS by some people I know who work withA it..F As such, that is what I'd really like to look into doing. Playing with$ VMS/Alpha systems in the enterprise.  L So if anybody has any good suggestions or helpful hints for the best path to3 take to achieve this, I would be very appreciative.h  K I was looking at getting the Open VMS technical resource kit and then doinguK the certification exam, but wasn't sure whether that would be enough to getaI a start and work on a real understanding of VMS. I would like to get somefI hands on experience with VMS, but the opportunities here in Australia (asn( far as I am aware) are somewhat limited.  E Anyway, any suggestions, ideas or insightful information is welcomed.(  K Surely getting more people into VMS/Alpha can only be a good thing (so longt as they are capable : )   )t   Cheers.    S.   ------------------------------    Date: 15 Mar 2001 08:58:31 +0800, From: Paul Repacholi <prep@prep.synonet.com>. Subject: Re: How does one become a VMS guru ??- Message-ID: <87itlbsv9k.fsf@prep.synonet.com>e  . "Dr Evil !" <sbudak1@optushome.com.au> writes:  D > Most of my qualifications thus far are Microsoft based, but I haveB > spent time at uni doing a Computer Science degree and have solid  > amount of industry experience.  
 Oh dear...  C > But as you can imagine, the brain dead simplicity and lack of anyb@ > real true enterprise ability in the MS product (as well as not> > wanting to just be another MS drone) has lead me to look for > alternatives.e   OK  E > I love Unix, I love Linux and enjoy playing with them, but am truly F > impressed by what I have heard of VMS by some people I know who work> > with it.  As such, that is what I'd really like to look into: > doing. Playing with VMS/Alpha systems in the enterprise.  B You don't 'play' in the enterprise. Not more than once anyway. You? play at home, or if you are VERY luck, with your test and smashs cluster.  F > So if anybody has any good suggestions or helpful hints for the best= > path to take to achieve this, I would be very appreciative.r  F Ring Decus, join. find out when the next LUG meeting is and get along.  B > I was looking at getting the Open VMS technical resource kit andA > then doing the certification exam, but wasn't sure whether that>D > would be enough to get a start and work on a real understanding ofE > VMS. I would like to get some hands on experience with VMS, but thenE > opportunities here in Australia (as far as I am aware) are somewhatt
 > limited.  E Start reading everything you can get. Code, help files, The internals # book if you buy or can borrow them.o   -- e< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.t@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------    Date: 14 Mar 2001 20:51:04 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)h. Subject: Re: How does one become a VMS guru ??3 Message-ID: <EWPrANG5UTwB@eisner.encompasserve.org>e  r In article <VgSr6.11222$pG5.39608@news1.rdc1.nsw.optushome.com.au>, "Dr Evil !" <sbudak1@optushome.com.au> writes:  M > I was looking at getting the Open VMS technical resource kit and then doingnM > the certification exam, but wasn't sure whether that would be enough to getyK > a start and work on a real understanding of VMS. I would like to get someoK > hands on experience with VMS, but the opportunities here in Australia (asM* > far as I am aware) are somewhat limited.  A I don't know what "the Open VMS technical resource kit" is, and IeD have been doing VMS for 22 years now.  My general impression is that3 VMS shops don't put much weight on "certification".w  A As for how to get started, I would strongly recommend reading theh? _entire_ documentation set, cover to cover to cover to cover...    ------------------------------  % Date: Wed, 14 Mar 2001 23:42:24 -0500t* From: "Andy Stoffel" <acs@fcgnetworks.net>. Subject: Re: How does one become a VMS guru ??8 Message-ID: <jLXr6.59587$lj4.1467062@news6.giganews.com>  F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:EWPrANG5UTwB@eisner.encompasserve.org...MI > In article <VgSr6.11222$pG5.39608@news1.rdc1.nsw.optushome.com.au>, "Dr * Evil !" <sbudak1@optushome.com.au> writes: >eI > > I was looking at getting the Open VMS technical resource kit and thena doingMK > > the certification exam, but wasn't sure whether that would be enough top getWH > > a start and work on a real understanding of VMS. I would like to get someI > > hands on experience with VMS, but the opportunities here in Australia  (asf, > > far as I am aware) are somewhat limited.  C > I don't know what "the Open VMS technical resource kit" is, and Io' > have been doing VMS for 22 years now.s  G I can answer that :-).... see http://www.compaq.com/training/cd-os.htmly5 which says (following a list of VMS training courses)   F     In addition to instructor-led training provided by our IndependentI     Training Partners, Compaq has available an OpenVMS Technical ResourcedB     Kit (TRK), NAT001/0699. This TRK contains the same print-basedE     information which is delivered in the instructor-led classes. Theu@     TRK is designed to be a test preparation (Sylvan test seriesE     ID #010-140), self-learning tool for students that have a workingn     knowledge of OpenVMS.o  A Last time I saw it it was a CD full of PDF's. Not sure it's worthc= the $499 (US) if you have access to a complete set of the VMSh documentation.  ? Is becoming an "Instant" VMS Guru a "worthy" goal ? Personally,r; I would like to be considered a RPVA (Reasonably Proficiento< VMS Acolyte") :-). Guru seems too much a "Unixy" designation? or a title you give to someone selling New Age psuedo-religion.a   -Andy-     -- SUB/signature/witty_saying/r   ------------------------------    Date: 15 Mar 2001 00:14:51 -0500+ From: young_r@encompasserve.org (Rob Young)d. Subject: Re: How does one become a VMS guru ??3 Message-ID: <5rdTGoMuJTcv@eisner.encompasserve.org>T  e In article <jLXr6.59587$lj4.1467062@news6.giganews.com>, "Andy Stoffel" <acs@fcgnetworks.net> writes:O   > A > Is becoming an "Instant" VMS Guru a "worthy" goal ? Personally,o= > I would like to be considered a RPVA (Reasonably Proficients> > VMS Acolyte") :-). Guru seems too much a "Unixy" designationA > or a title you give to someone selling New Age psuedo-religion.g >   9 	After taking a group's VMS test, I was told I was a "VMS B 	hotshot."  Not a guru, that is reserved for the gurus apparently.G 	I guess being a hotshot is okay... sounds like someone wants to punch l! 	you though , so I'm not so sure.e   				Rob2   ------------------------------   Date: 15 Mar 2001 00:10 CSTc' From: carl@gerg.tamu.edu (Carl Perkins)n. Subject: Re: How does one become a VMS guru ??- Message-ID: <15MAR200100105115@gerg.tamu.edu>   . "Andy Stoffel" <acs@fcgnetworks.net> writes...@ }Is becoming an "Instant" VMS Guru a "worthy" goal ? Personally,< }I would like to be considered a RPVA (Reasonably Proficient= }VMS Acolyte") :-). Guru seems too much a "Unixy" designation @ }or a title you give to someone selling New Age psuedo-religion. }  }-Andy-h  4 Instead of "VMS Guru", might I suggest "VMS Vizier"?   --- Carl   ------------------------------  % Date: Thu, 15 Mar 2001 16:47:45 +1100l/ From: "Phil Howell" <phowell@snowyhydro.com.au> " Subject: Re: HP Printer on VMS 6.22 Message-ID: <SFYr6.3550$zW2.152066@ozemail.com.au>  ; Jason McCormick <jason.mccormick@lexi.com> wrote in messages, news:3aafb655$0$5744@wodc7nh0.news.uu.net...C >   Hello, I'm trying to create some TLBs for an HP printer and wasr	 wonderingaE > if anyone could help me out.  We have Pager, which is a typesettingo program.A > It creates Postscript-formatted documents.  These documents arer legal-paper"G > sized (8.5 X 14).  However they will not print to the tray with legal  paper:J > in it so I'm trying to write a module to be specified at print time with thewI > /setup() function.  I have many working ASCII modules I wrote using PCL- thatK > print legal and duplex but they don't seem to traslate well into wrappingn PSG > jobs.  In a nutshell, I guess I'm asking for how to make a legal-size7 paperoI > formatted PS job print on legal paper from "Tray 3" and also be able tod turn. > on the duplexer as needed.  Can anyone help? >DC see http://www.hp.com/cposupport/printers/support_doc/bpl01378.htmla  2 notably the example on switching printer languages, your setup module should look something like (where Ec = <27>)>- Ec%-12345X@PJL ENTER LANGUAGE = PCL <CR> <LF>N Ec&l1H - tray 2t Ec&l3a - legal* @PJL ENTER LANGUAGE = POSTSCRIPT <CR> <LF>6 (the postscript job that follows should start with %!)H you may also want a "reset module" that sets the printer back to a known statecL some printers also have options of pcl/postscript/automatic on their control panel  Phil   ------------------------------    Date: 15 Mar 2001 00:45:53 +0100* From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: LICENSE PURGE ?( Message-ID: <3ab002b1@news.kapsch.co.at>  I Since the VMS hobbyist program is there (many thanks for that !!), I havehH a bunch of licenses loaded which starts to terminate now. And I start to5 feel tired of deleting yet another expired license...o  ? Is there a LMF command to delete all expired licenses at once ?    -- i< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888d< <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------  # Date: Thu, 15 Mar 2001 03:09:42 GMTi- From: goathunter@goatley.com (Hunter Goatley)e Subject: Re: LICENSE PURGE ?0 Message-ID: <3ab03053.16479566@swen.process.com>  J On 15 Mar 2001 00:45:53 +0100, eplan@kapsch.net (Peter LANGSTOEGER) wrote:  J >Since the VMS hobbyist program is there (many thanks for that !!), I haveI >a bunch of licenses loaded which starts to terminate now. And I start to 6 >feel tired of deleting yet another expired license... >i@ >Is there a LMF command to delete all expired licenses at once ? >i% $ delete sys$system:lmf$license.ldb;*t   A bit drastic, but it works.   $ LICENSE DELETE *  @ also works, but, again, is a bit drastic.  Less drastic, and one@ that will probably do exactly what you want (delete the hobbyist% licenses and leave any other intact):x  , $ LICENSE DELETE */AUTHORIZATION=DECUS-USA-*  2 or whatever common authorization string they have.   Or:A  & $ LICENSE DISABLE */AUTHOR=DECUS-USA-*" $ LICENSE DELETE */STATUS=DISABLED   Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/ 9 goathunter@goatley.com     http://www.goatley.com/hunter/e   ------------------------------  % Date: Thu, 15 Mar 2001 04:37:40 +0100a2 From: martin@radiogaga.harz.de (Martin Vorlaender) Subject: Re: LICENSE PURGE ?; Message-ID: <3ab03904.524144494f47414741@radiogaga.harz.de>i  + Peter LANGSTOEGER (eplan@kapsch.net) wrote:oK > Since the VMS hobbyist program is there (many thanks for that !!), I haverJ > a bunch of licenses loaded which starts to terminate now. And I start to7 > feel tired of deleting yet another expired license...i >sA > Is there a LMF command to delete all expired licenses at once ?   E I solved (or circumvented) that problem by issuing a $ LICENSE CREATErF before executing the command procedures that register the new hobbyistI licenses. But then, the hobbyist licenses are the only ones on my system.   E I guess one could write a quick perl script to look over OPERATOR.LOG 0 and issue appropriate $ LICENSE DELETE commands.   cu,    Martin -- fJ One OS to rule them all       | Martin Vorlaender  |  VMS & WNT programmer7 One OS to find them           | work: mv@pdv-systeme.de*J One OS to bring them all      |   http://www.pdv-systeme.de/users/martinv/> And in the Darkness bind them.| home: martin@radiogaga.harz.de   ------------------------------  % Date: Wed, 14 Mar 2001 17:49:09 +0000e8 From: David J. Dachtera <donotreply@interbulletin.bogus># Subject: Re: Merging multiple disksw1 Message-ID: <3AAFAF15.76DF87DA@interbulletin.com>e  , steven.reece@quintiles.com wrote in article ? <OF9D6758E8.ECBF7AE8-ON80256A0F.00465426@qedi.quintiles.com> : t >iJ >Depends what the disks are, how big they are, whether they include system9 >disks or just user data with no alias entries and so on.  >hD >If they just contain user files I might be tempted to create rootedE >directory logical names so that if one has DISK$USER1 and DISK$USER2o >merging onto DKA200 you'd havei= >$ DEFINE/SYSTEM/TRANSLATION_ATTRIBUTE=(CONCEALED) DISK$USER1  >DKA200:[USER1.]= >$ DEFINE/SYSTEM/TRANSLATION_ATTRIBUTE=(CONCEALED) DISK$USER2s >DKA200:[USER2.] > J >Then you could refer to DISK$USER1:[JOHN.DOE] or DISK$USER2:[JANE.DOE] asK >you would have done previously.  You could also move the DISK$USER1 "disk"oL >and the DISK$USER2 "disk" to other devices at various times, depending uponF >usage, free disk space, speed of access, growth rate etc etc etc etc. >nJ >For a user disk with no aliased file entries I'd transfer the files usingK >BACKUP, either doing straight disk to disk backups from [000000...] or, ifhF >this was not feasible, do a backup to a saveset and then transfer the	 >saveset.r >y/ >There are, obviously, other options available.  >Steve.s >  >Mark Hemker wrote:eH >>>>I am going to be migrating to some new disks this weekend and I needB >to merge the contents from multiple disks onto a single new disk.E >Does anyone have any suggestions on the best/fastest way to do this?a@ >Some of the disks have the same directory names and file names.  + One caveat I would add to Steve's comments:n  P Some application code (usually DCL proc.'s) will not tolerate or permit the use E of rooted logicals. Speaking from experience on a customer site here.   K Go ahead and try it; but, have a plan B in case that fails. It SHOULD work aJ (famous last words) - I've done it before. Application coders and vendors : have a knack for making useful features unusable, however.   -- David J. Dachtera, dba DJE Systems? http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/e  / _______________________________________________ ; Submitted via WebNewsReader of http://www.interbulletin.coma   ------------------------------  % Date: Thu, 15 Mar 2001 00:23:12 -0300a) From: fabio_compaq@ep-bc.petrobras.com.bru Subject: MOUNT/BIND too slowL Message-ID: <OF4A2A04B6.EB7E373A-ON03256A10.001238FA@ep-bc.petrobras.com.br>  ? I mounted two disks  in RAID-5  (each) with the /BIND to createo7 a bigger (??) volume (16GB)  and the DBA exported a RDB:- database but he told me it was extremly slow.o   Any  idea ?b  < The disks were initialized with /NOHIGHWATER and are located) in a StorageWorks with HSZ-70 controller.i   My OpenVMS version  in 7.1-1H2   Regardsi   FC   ------------------------------  % Date: Wed, 14 Mar 2001 17:59:29 -0500   From: John Santos <JOHN@egh.com>* Subject: Re: Obtaining 7.2-1 and TCPIP 5.15 Message-ID: <1010314175423.3369A-100000@Ives.egh.com>a  + On Tue, 13 Mar 2001 sms@antinode.org wrote:g  4 > From: "Zane H. Healy" <healyzh@shell1.aracnet.com> > N > > Out of curiosity, is there an affordable way for a Hobbyist to get OpenVMS% > > 7.2-1 or TCPIP 5.1 for the Alpha?i > G >    If there is one, it would be news to me.  (Welcome news, in fact.)f > + > >   The current Hobbyist kit is about twouG > > years old, and is starting to be a little long in the tooth.  [...]6 > A >    I agree.  VMS V7.3 and TCPIP V5.1 seem to offer a conveniente: > opportunity for a new kit.  (What's Compaq C up to now?) > L > > It would be nice if OpenVMS had a Hobbyist Kit like Tru64 does.  You can> > > even upgrade from V5 Hobbyist to V5.1 Hobbyist with Tru64! > 8 >    Also true.  For those who have not recently visitedI > "http://tru64unix.compaq.com/noncommercial-unix/", the first-time price J > is $99.  The V5.1 upgrade kit is $39.  The kit contents appear to be the > same, namely CD-ROMs:s > ? >    1 OS                                 2 Associated ProductsrJ >    1 Software Documentation             1 Open Source Internet Solutions >    1 Firmwarec > F > and a couple of handy quick installation guides, and non-terminatingI > PAKs for OSF-BASE, OSF-USR, OSF-SVR, and OSF-DEV, which seem to cover ap > lot.   Sounds good.   > G >    It's a "Technology Enthusiast Product" which offers enough for thet; > money to generate a little enthusiasm for the technology.l > J >    The Tru64 home page ("http://tru64unix.compaq.com/") looks pretty bad3 > using Netscape 3.03, by the way, but it's usable.C > J >    I probably won't switch antinode.org from VMS to Tru64 any time soon,I > but it is rather refreshing to be able to run an up-to-date Web browser G > and PDF viewer for a change.  (It's also fun to run a Unix C compiler D > which can produce a list file, just like a _real_ C compiler.  The( > family resemblance is pretty obvious.) > C >    I appreciate all the work that went into prying a hobbyist VMS(J > program out of the vendor, but it does not compare very well against theC > Tru64 program, or Solaris, for that matter.  (What's the compilerrD > situation on Solaris?  Anyone know?  It's not obvious that the $75C > Solaris kit includes anything from the Forte package, or whateverc  > they're calling it this week.)  @ For the VMS Hobbyist license (and Tru64, IIRC) you get the real,A top-grade compilers for practically everything.  Don't know abouty Solaris.   > " > From: John Santos <JOHN@egh.com> > F > > 1) I think you can still get a V7.3-FT2 SDK for about $40.  It has > > TCPIP 5.1 on it.< > > 2) Form a pool with other hobbyists to buy a shared kit. > > 3) Borrow a kit from work. >    What you're proposing is:m  A 4) Get Compaq to release either a hobbyist kit or the regular VMS5' kit to hobbyists at a reasonable price.   > The only problem I see with 4) is getting Compaq to do it.  MyE original proposals are all things Zane can do on his own immediately.   I >    1) Sure, but prepare to be advised to upgrade to the real V7.3 everyt > time you ask about a problem.n > J >    2)  That's convenient.  Then all we'd need to do is make bootleg CD-RH > copies, and it'd be almost as good as being able to buy the real thing > for a reasonable price.S > I >    3) They quit using VMS where I work long ago.  Bad price/performance ; > and decreasing application availability were the reasons.i >  > G >    If the goal is to discourage potential (low-budget) users, whetherCH > they be hobbyists or educational institutions or whoever, just provide9 > an ample set of hoops through which everyone must jump.S > E >    If the goal is to gain mind share or market share or applicationw= > availability, a different approach might be more effective..  % Clearly this should be the goal.  :-)-   --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Thu, 15 Mar 2001 04:52:09 +010002 From: martin@radiogaga.harz.de (Martin Vorlaender)* Subject: Re: Obtaining 7.2-1 and TCPIP 5.1; Message-ID: <3ab03c69.524144494f47414741@radiogaga.harz.de>,  1 Zane H. Healy (healyzh@shell1.aracnet.com) wrote:oL > Out of curiosity, is there an affordable way for a Hobbyist to get OpenVMSJ > 7.2-1 or TCPIP 5.1 for the Alpha?  The current Hobbyist kit is about twoH > years old, and is starting to be a little long in the tooth.  The onlyL > option I see is the "OpenVMS Alpha Software Layered Products and OperatingB > System Library Package", but at $1258, that's not affordable :^( >tJ > Basically I *really* need TCPIP 5.1 for the Anti-Spam features, however,A > I'd also like to also have the benefit of the patches in 7.2-1.t  C If it were only for the Anti-Spam features, and you were willing toNH invest at least some money, I'd suggest buying MX v5 (about $400, IIRC).  See www.madgoat.com for details.   cu,w   Martin  3 P.S.: Std disclaimer: Just a satisfied MX customer.o -- aJ One OS to rule them all       | Martin Vorlaender  |  VMS & WNT programmer7 One OS to find them           | work: mv@pdv-systeme.delJ One OS to bring them all      |   http://www.pdv-systeme.de/users/martinv/> And in the Darkness bind them.| home: martin@radiogaga.harz.de   ------------------------------  # Date: Thu, 15 Mar 2001 04:54:46 GMTi2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>* Subject: Re: Obtaining 7.2-1 and TCPIP 5.16 Message-ID: <qWXr6.11662$a3.25467@typhoon.aracnet.com>  3 Martin Vorlaender <martin@radiogaga.harz.de> wrote:eE > If it were only for the Anti-Spam features, and you were willing toEJ > invest at least some money, I'd suggest buying MX v5 (about $400, IIRC)." > See www.madgoat.com for details.  L Well, there is also the fact they've finally added XDMCP to TCPIP.  ActuallyJ I was looking at MX last night, and it looks like it would cost $500.  I'dH be better off putting that $500 towards the full Condist and OS set.  ItI would be kind of nice if MX or PMDF was available with a Hobbyist licensee :^)v  J BTW, I'm not opposed to paying for the software, it's just that the pricesF are more than I can justify for hobby systems.  I wouldn't mind at all@ paying something like $2-300 for a ConDist/OS set for Hobbyists.   			Zanea   ------------------------------  % Date: Wed, 14 Mar 2001 10:53:40 -0800v! From: Shane.F.Smith@Healthnet.comt( Subject: Re: OpenVMS Educational ProgramD Message-ID: <OFFCF8BC5A.B71882B2-ON88256A0F.0067A728@foundation.com>  ? My God, Andrew just supported my position on something! Now I'mh worried....... :-/   Shanes          D andrew harrison <andrew.nospam@uk.sun.com> on 03/14/2001 01:55:47 AM   To:   Info-VAX@Mvb.Saic.Comd cc:h  ) Subject:  Re: OpenVMS Educational Program     " Shane.F.Smith@Healthnet.com wrote: >sJ > From a technical point of view, as you say, we have no concrete details.J > Let's see what VMS Engineering deliver first. From a real world point ofI > view, COE certification is intended to garner a larger userbase for VMSO inJ > the military, guarantee its survival for many years to come, and lead toG > more apps becoming available. These are all extremely important right  now.H > Keeping VMS "pure" (for want of a better word) is NOT going to keep itI > alive. You only have to look at Windows to see how much weight an idealeF > design has in the current market - it's crap but it rules the world. >RK > This is a fight for survival. We can't afford the luxury of anyone's ideaa> > of a perfect environment. Not yours, not mine, not anyone's. >o  4 The sad thing about this discussion is that it isn't4 remotely new. Every year or so someone suggests that/ OpenVMS should support some UNIXism which wouldc1 make it easier to get UNIX apps to run on OpenVMS(/ and every year someone else complains that thish. would compromise the architectural purity that is OpenVMS.   2 Since the architectural purity is at best arguable4 it is difficult to see how this negative approach is2 remotely helpfull to OpenVMS itself. It needs apps1 to save it from extinction, the apps it needs are92 mostly developed on UNIX so anything that makes it/ easier to get those apps onto OpenVMS has to be  a good thing for OpenVMS.@  - Exactly the same scenario has been played oute- with Java, on one side people have complainedh/ justifiably about Compaqs poor support for Javas- on OpenVMS because it makes it more difficultO. to get Java apps to run. On the other side the0 negativitists argue that Java is crap (generally0 because they don't have a clue) so why would you. want to pollute OpenVMS by running Java on it.  1 OpenVMS supporting COE is only one step, it would 2 make it easier to port apps. But anyone who things3 that it is the magic button is deluding themselves,a2 Compaq will need to vastly improve their marketing1 they will need to offer ISV's other incentives toc0 get their apps onto OpenVMS. COE support without/ the ISV programs from Compaq will not result inw- the flood of apps that people are hoping for.i   Regardsm Andrew Harrisoni Enterprise IT Architect    ------------------------------    Date: 14 Mar 2001 16:48:31 -0500- From: koehler@encompasserve.org (Bob Koehler) ( Subject: RE: OpenVMS Educational Program3 Message-ID: <3Rb58bMsl5SR@eisner.encompasserve.org>   z In article <3B55D7F383B0D31197D9009027541CBF0BDD5468@cmiexch1.cmi.itds.com>, Christopher Smith <csmith@amdocs.com> writes: [...]A > until you can run a seriousV6 > java app on a modern CPU it will be next to useless.  G We do.  Of course, we picked apps where the performance requirement wasg* "better than pure DCL on a VAX 4000 M200".  H In fact, much better, but of course not competing with native languages.  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporation = NASA GSFC Flight Software       | Federal Sector, Civil GroupeE                                 | please remove ".aspm" when replyingr   ------------------------------  % Date: Wed, 14 Mar 2001 22:16:05 +0000b) From: Christof Brass <brass@infopuls.com>l( Subject: Re: OpenVMS Educational Program, Message-ID: <3AAFEDA5.C2F44F2D@infopuls.com>   Bill Gunshannon wrote: > . > In article <3AADE84B.C5B9BCF5@infopuls.com>,. >  Christof Brass <brass@infopuls.com> writes: > |> > |>J > |> Standard on the platform which makes life a lot easier. If there wereG > |> only VMS something like Java or the Oracle Java installer wouldn'te > |> be needed.o > I > And if english were the only language in the world communications wouldaJ > be a lot easier.  But reality is different.  And it doesn't make French,/ > German or Spanish flawed, deficient or wrong.t  & I really don't get it. Are you stupid? Your example would be correct if you've said that someone invents a new language (which in fact has been done with esperanto a well know wide spread language).a  R 1.Introducing unecessary complexity and choices into VMS is a disadvantage per se.` 2.Yes, the UNIX way sucks and spoils VMS. We don't need these UNIX morons hacking around on VMS.  To explain it on kindergarten level: VMS is created by engineers, languages have been evolved over time without a central authority. I would perfectly agree to have only one language all over the world - but surely it wouldn't be English because English has too many flaws. The mismatch of scripture and pronounciation is simply ridiculous. But this shouldn't change into a thread about natural languages so I stop here.  u I ask listeners of this thread (if there are any remaining): is this natural language example a well chosen argument?d   > |>H > |> > |> With UNIX you aren't sure about the shell you will have to use > |> >O > |> > Shell is a user selectable option.  It's what the "chsh" command is for. P > |> > All Unix machines I have ever seen offer at least 2 to choose from.  SomeQ > |> > offer many more.  I would expect that most Unix sys admins would, like me,nO > |> > consider adding other shells if their users wanted them. (within reason,  > |> > of course.) > |>F > |> I know, I know. But what if the shell you are accustomed to isn'tG > |> offered and the sysadmins like at the Swiss Exchange have a policym > |> not offer the bash? > E > That's a social issue.  If your going to work for someone, you need?G > to make sure you know all the rules up front.  What if you were hiredrI > build a house and after agreeing to do it found out you weren't allowedtJ > to use any tool but a hammer??  My guess is you would have a really hardA > time doing your job.  But that doesn't make it the fault of thes( > screwdriver makers or the lumberyards.   You are good in chosing wrong examples. While your example has basically a point it misses the problem: the lack of standardisation or basic infrastructure of UNIX.   > |>V > |> > |>                                                                and if *your*U > |> > |> aliases can be set up automatically (what if you have to type them in everyoV > |> > |> time you login because you don't have the right to change anything permamentG > |> > |> of youer account on a certain machine at a customer's site?).e > |> >U > |> > The designation of aliases is done in your .login file in your home directory.mQ > |> > If you are not even allowed to manipulate something as basic as this, your T > |> > account is virtually useless anyway.  Either the sys admin is an idiot or youS > |> > need to pick your customers from a more realistic list.  Can you imagine notrB > |> > having the necessary permissions to modify your LOGIN.COM?? > |>L > |> Been there, done that, even on VMS with accounts which I wasn't allowedK > |> to change the LOGIN.COM. I was talking about the legal right to changee( > |> something e.g. on a bank's machine. > L > That's a social problem and has nothing to do with Unix.  What if you wereL > hired to Administer a VMS machine but you weren't allowed to login or evenM > go into the building where the system was??  Would that make the difficulty  > a VMS problem??a  Great example! The problem as stated above is the lack of standards. With VMS you are accustomed to VMS. With UNIX you are accustomed to something vage, ever changing moving target. Where is the hosts file? - it depends. Where is the mount table? - it depends.  V > |> > |> Look at the Oracle installation on UNIX. They provide at least two different= > |> > |> sets of scripts for two shells. Major step forward!a > |> >M > |> > Actually, I would guess that what they provide are two scripts for twosL > |> > different families of shells, which means they actually cover all but0 > |> > maybe the most obscure of private shells. > |>D > |> And this is exactly what I was talking about: the necessity forE > |> superflous work and the risk of having bugs or an old version ine6 > |> one of these scripts and not in the other a.s.o.. > J > There's not much point in contiuning this.  You have now complained thatK > some shells don't offer the features you want and that there are too many H > shells.  So what is it, the only usefull feature set is what you like.   ???? You really dont' get the point. This seems to be a severe UNIX sickness. Let me propose a cure: stop using UNIX for a short while (let's say 20 years) and come back then. 1.There is not UNIX shell which is in any respect acceptable. All UNIX shells suck severely and not only from the features they offer but basically from the concept they handle user interaction. 2.The fact itself that there are several shells shows that nobody is content with what is there. Is this that difficult to understand? The fact that there are no standards wrt the shells is a superflous problem.i& Did you read the UNIX-Haters Handbook?  	 > |> > |>pL > |> > |> I'm not sure if this is true. I do UNIX administration since 1996. > |> >K > |> > And you still didn't know that the user could change his own shell??i > |> > (see above) > |> > |> I do, I do, see above.n > J > Then it isn't a Unix problem, is it.  It's a social problem.  Technology7 > has never been successful at solving social problems.a  E See above, it is exactly a UNIX problem because no other OS has this!e  A > |> > |> > The Unix haters here are so blinded by their religioncC > |> > |> > that they are missing the whole point and have led thisy@ > |> > |> > to deteriorate into little more than ahouting match.	 > |> > |>cN > |> > |> The flaws of UNIX are no invention of VMS people/advocates. They are2 > |> > |> *inherent*, they are 'architectured' in. > |> >D > |> > The "flaws" as you call them are only flaws to you.  They areG > |> > design decisions to unix people.  Unix files are just streams of4B > |> > bytes because that is the way Unix wants them.  Not a flaw.G > |> > Different is not flawed, just different.  You may not understandmC > |> > the rationale behind the differences, you may not like them, . > |> > but that still doesn't make them flaws. > |>4 > |> No, these flaws are partially lack of services, > H > Funny, Unix programmers have written thousands of usefull programs forH > which there is no VMS equivalent and done all this without missing anyF > of these "services".  One would think that the superiority of VMS in< > this regard would have meant the tables would be reversed.  A statistical argument, not a technical. You are exchanging OS services and programs. If these programs had been developed on VMS it would have needed less time. The UNIX programmer's attitude is to write his own service package or to use one of these libraries but never the same in different products. You are so blindly UNIX addicted that you even don't understand the UNIX problems if they are explained to you. Sad enough. This could be named a "social problem".o  I > |>                                                 missing concepts andu > < > You mean like "fork", oops, that's the one VMS is missing. >  > |> standards > E > "Standards" like DECNET rather than TCPIP??  The "standard" for therH > desktop is Microsoft Windows.  Should we all embrace that "standard"??   ????  I > |>            or simply poorly thought through "design decisions" basedtG > |>  on the UNIX "philosophy" to offer only half of a solution lettinge& > |>  the rest be solved by the users. > H > I would love to see your examples of these, although I can pretty muchE > guess.  They are most likely based on the idea that the data centere0 > knows best what the user "really" wants to do.  7 You really don't get it. Read the UNIX-Haters Handbook.S Basically the point is that feature richness is there to be used and will be used by all good programmers when appropriate. But there is no force or law to use something inappropriate because simpler abstractions are also there.  J > |>                                    Unfortunately you never defend theG > |>  technical examples of brokeness that I gave many times. Repeatingt+ > |>  what you again did isn't an argument.C > G > ??  What technical examples??  Name some specific "missing services",   G All are getting tired: a file system with a notion of structured files.C  D > "missing concepts" and uncomplied with "standards".  But remember,  &Missing concept: parameter and option language, regularity between different commands and systematic implementation of offered services (e.g. the pipe service is not bad, but the implementation of several commands is broken wrt this service and therefore renders it useless or very restricted).  F > not implementing DECNET is not a Unix idea.  It is a proprietary DECE > protocol and even without any assistance from the only one with thee+ > actual definition it is still being done.  >  > bill >  > --L > Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesF > bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. > University of Scranton   |@ > Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------  % Date: Wed, 14 Mar 2001 22:19:36 +0000h) From: Christof Brass <brass@infopuls.com>e( Subject: Re: OpenVMS Educational Program, Message-ID: <3AAFEE78.9D1F85E9@infopuls.com>   Bill Gunshannon wrote: > . > In article <3AADE93D.FBF4E2EE@infopuls.com>,. >  Christof Brass <brass@infopuls.com> writes: > |>C > |> I should have emphasised that little "your account". I've seendB > |> UNIX environments at Swiss banks where you weren't allowed toB > |> change any of the startup scripts (.bashrc, .profile etc.) of@ > |> the root account even if they gave you the root password to > |> install e.g. Oracle.f > @ > First off, I would imagine that if an outsider came into a VMS? > site and started modifying the setup of the SYSTEM account ond> > someone else's machine they would be shown the door in short< > order.  That's not even a social problem, that's just good > system management. >  > |>B > |> Why is it that Oracle provides two sets of scripts? Why don't# > |> they rely on the Bourne shell?  > ? > No satisfying some people.  Because everyone doesn't like thea@ > same shell they provide two scripts which use a minimal set ofC > the features contained in the two families of shells (all currentgA > shells are advancements on either the Bourne Shell, the C-shellwA > or a hybrid of both).  This all but guarantees they will run on B > your favorite shell thus not requiring you to use an unfamiliar,D > uncomfortable shell for even the onetime install of their product. > * > I guess some people are never satisfied.  QThis is not the problem, but rather the history you revealed. Doesn't tell you this history something? Why would it be that there isn't such a history with VMS CLIs? I'm really tired about this shell problem. The shell syntax and concept is severely broken and therefore no shell adhering to this UNIX "standard" will ever be satisfying.m   > bill >  > --L > Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesF > bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. > University of Scranton   |@ > Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------  % Date: Wed, 14 Mar 2001 22:27:28 +0000s) From: Christof Brass <brass@infopuls.com>f( Subject: Re: OpenVMS Educational Program, Message-ID: <3AAFF050.3394F7A0@infopuls.com>  " Shane.F.Smith@Healthnet.com wrote: > J > From a technical point of view, as you say, we have no concrete details.J > Let's see what VMS Engineering deliver first. From a real world point ofL > view, COE certification is intended to garner a larger userbase for VMS inJ > the military, guarantee its survival for many years to come, and lead toL > more apps becoming available. These are all extremely important right now.H > Keeping VMS "pure" (for want of a better word) is NOT going to keep itI > alive. You only have to look at Windows to see how much weight an ideal F > design has in the current market - it's crap but it rules the world. > K > This is a fight for survival. We can't afford the luxury of anyone's ideaj> > of a perfect environment. Not yours, not mine, not anyone's.  It has been written that these COE amendments would for a certain period (I assume at least 5 to 10 years) not be available to the public. So your argument wouldn't fit. But my fear also wouldn't be appropriate. But my point is that technically this is something very risky and done the wrong way will kill VMS technically. Why would one use VMS with UNIX apps instead of using UNIX? And putting engineering effort in that COE niche market project will reduce the engineering power spent for the public version.  Insane, isn't it?m  VI'm sure that even the COE UNIX API would already be there this wouldn't help VMS. Instead it might well kill VMS also from the marketing point of view because the real VMS apps will vanish and there will no apps remain using the real power of VMS. And there will be a lot of apps spoiling VMS by not using its features like structured files.   > Shanen > ? > Christof Brass <brass@infopuls.com> on 03/13/2001 03:20:40 PMN >  > To:   Info-VAX@Mvb.Saic.Comr > cc:s > + > Subject:  Re: OpenVMS Educational Programe > # > steven.reece@quintiles.com wrote:S > > I > > This is getting to be something of a flame war come religious war.  Ih@ > > didn't expect the Spanish Inquisition and all that.......... > >eM > > Complexity of code is something that is almost part and parcel of presentoK > > product offerings.  This is because people are expecting more functionso > and D > > more displays and in the case of some environments cruddy little > paperclipsH > > that come up when you least expect/need/want them and flying bits of > paperJG > > that take up CPU time when you should actually be copying the file.  > > Grrrrr!t > >iG > > I would expect that stuff like cluster transition capabilities, SCSnM > > connections over switched LANs, memory channel and other interconnects is.K > > pretty complex to get right, as are a fair number of other parts of thet > VMSBM > > operating system (not just the kernel).  Would you say that VMS is low onpL > > quality?  No.  Would you say that these bells and whistles should not be$ > > added in (along with APMP)?  No. > >pC > > What you're getting with the work that is being carried out areuJ > > capabilities on VMS to present Unix-like environment features.  Or, as > FredJ > > Kleinsorge (not speaking for Compaq or OpenVMS or the US DoD) put it : > > G > > >>>So what COE provides is a common look & feel for the applicationRJ > > environment, which tends to drill down all the way to the UNIX command > lineM > > interfaces.  You also have some "standards" - like POSIX and JAVA - which,F > > if people writing new segments adhere to, would allow source level > > compatability.<<<a > > - > > then later in the same message he wrote :d > >fH > > >>>This does not "replace" anything that VMS currently does, or even > weakenF > > it. All the capabilities are incremental, or supplemental.  But as	 > always,tJ > > poor UNIX code will work poorly, and good UNIX code will work well.  IM > > expect that when someone wants the code to "mesh" into a VMS environment, I > > they may have work to do beyond a simple port - or they can choose to  > live& > > with a UNIX fish in a VMS pond.<<< > >y > > Christof Brass wrote:-B > > >>>Quality is dependent on time and complexity i.e. effort and > skilfulness.M > > Having UNIX on VMS raises complexity and hence imposes more difficulty in2 > > achieving quality. > >G# > > Why do we want another UNIX?<<<A > L > While I'm not satified with these general statements of the well estimatedK > Fred Kleinsorge and while I'm still expecting hard problems with this COErD > stuff I have to admit that I can't prove it with concrete details.K > Unnecessary complexity reduces quality with given time frames/milestones.tI > The VMS feature rich environment doesn't need any adaption to any thirdtJ > party (DoD) rules - especially if these rules are strongly influenced by > UNIX crap.K > The complexity of VMS is needed for delivering its features and thereforedC > the tradeoff has been made to implement this quality features andhM > sacrificing simplicity. UNIX is the opposite. Quality is lowered if you addlA > something you don't need or which destroys the design or offersIJ > possiblities you better don't want to have because they don't fit in the" > way things are best done so far. > H > Why would you like any of this COE stupidity from a technical point ofM > view? And keep in mind that other things wouldn't be implemented because ofa! > the effort this COE task needs.o   ------------------------------  % Date: Wed, 14 Mar 2001 15:55:59 -0800t! From: Shane.F.Smith@Healthnet.comd( Subject: Re: OpenVMS Educational ProgramD Message-ID: <OF740CDF96.B3803880-ON88256A0F.0082D796@foundation.com>  J Turn it around, Christof. Why don't people use VMS, if Unix sucks so much?K Because that's where the apps run. If you make those same apps available onhH VMS then VMS becomes a viable option in many areas where it is currentlyJ not viable now. You try selling a manager VMS for a web server that serves" out Real Networks streaming media:  J Manager: I want to provide streaming Real Networks media to our customers.+ Techie: Can I interest you in a VMS system?r- Manager: Does Real Networks server run on it?s+ Techie: Well, no, but it's really robust...IJ Manager looks at Techie as if he's grown a second head, and makes a mental2 note to surf Dice.com looking for a new techie....   Shanen          = Christof Brass <brass@infopuls.com> on 03/14/2001 02:27:28 PMo   To:   Info-VAX@Mvb.Saic.Com  cc:y  ) Subject:  Re: OpenVMS Educational Programw    " Shane.F.Smith@Healthnet.com wrote: >iJ > From a technical point of view, as you say, we have no concrete details.J > Let's see what VMS Engineering deliver first. From a real world point ofI > view, COE certification is intended to garner a larger userbase for VMS. inJ > the military, guarantee its survival for many years to come, and lead toG > more apps becoming available. These are all extremely important rightu now.H > Keeping VMS "pure" (for want of a better word) is NOT going to keep itI > alive. You only have to look at Windows to see how much weight an ideallF > design has in the current market - it's crap but it rules the world. >eK > This is a fight for survival. We can't afford the luxury of anyone's ideac> > of a perfect environment. Not yours, not mine, not anyone's.  K It has been written that these COE amendments would for a certain period (IyF assume at least 5 to 10 years) not be available to the public. So yourG argument wouldn't fit. But my fear also wouldn't be appropriate. But myyI point is that technically this is something very risky and done the wrongrK way will kill VMS technically. Why would one use VMS with UNIX apps instead F of using UNIX? And putting engineering effort in that COE niche marketG project will reduce the engineering power spent for the public version.a Insane, isn't it?   H I'm sure that even the COE UNIX API would already be there this wouldn'tI help VMS. Instead it might well kill VMS also from the marketing point ofiH view because the real VMS apps will vanish and there will no apps remainI using the real power of VMS. And there will be a lot of apps spoiling VMSt0 by not using its features like structured files.   > Shaned >o? > Christof Brass <brass@infopuls.com> on 03/13/2001 03:20:40 PMW >  > To:   Info-VAX@Mvb.Saic.Comt > cc:g >e+ > Subject:  Re: OpenVMS Educational Programs >l# > steven.reece@quintiles.com wrote:a > >-I > > This is getting to be something of a flame war come religious war.  Iv@ > > didn't expect the Spanish Inquisition and all that.......... > >aE > > Complexity of code is something that is almost part and parcel ofe present K > > product offerings.  This is because people are expecting more functionse > andlD > > more displays and in the case of some environments cruddy little > paperclipsH > > that come up when you least expect/need/want them and flying bits of > paperdG > > that take up CPU time when you should actually be copying the file.  > > Grrrrr!e > >rG > > I would expect that stuff like cluster transition capabilities, SCScJ > > connections over switched LANs, memory channel and other interconnects isK > > pretty complex to get right, as are a fair number of other parts of they > VMS.J > > operating system (not just the kernel).  Would you say that VMS is low onI > > quality?  No.  Would you say that these bells and whistles should note be$ > > added in (along with APMP)?  No. > >hC > > What you're getting with the work that is being carried out are J > > capabilities on VMS to present Unix-like environment features.  Or, as > FredJ > > Kleinsorge (not speaking for Compaq or OpenVMS or the US DoD) put it : > >bG > > >>>So what COE provides is a common look & feel for the applicationTJ > > environment, which tends to drill down all the way to the UNIX command > lineG > > interfaces.  You also have some "standards" - like POSIX and JAVA -  which F > > if people writing new segments adhere to, would allow source level > > compatability.<<<s > >u- > > then later in the same message he wrote :  > > H > > >>>This does not "replace" anything that VMS currently does, or even > weakenF > > it. All the capabilities are incremental, or supplemental.  But as	 > always, J > > poor UNIX code will work poorly, and good UNIX code will work well.  I@ > > expect that when someone wants the code to "mesh" into a VMS environment,I > > they may have work to do beyond a simple port - or they can choose tot > live& > > with a UNIX fish in a VMS pond.<<< > >> > > Christof Brass wrote:fB > > >>>Quality is dependent on time and complexity i.e. effort and > skilfulness.J > > Having UNIX on VMS raises complexity and hence imposes more difficulty in > > achieving quality. > >># > > Why do we want another UNIX?<<<i >iB > While I'm not satified with these general statements of the well	 estimated K > Fred Kleinsorge and while I'm still expecting hard problems with this COEdD > stuff I have to admit that I can't prove it with concrete details.K > Unnecessary complexity reduces quality with given time frames/milestones.eI > The VMS feature rich environment doesn't need any adaption to any thirdwJ > party (DoD) rules - especially if these rules are strongly influenced by > UNIX crap.K > The complexity of VMS is needed for delivering its features and thereforepC > the tradeoff has been made to implement this quality features andeI > sacrificing simplicity. UNIX is the opposite. Quality is lowered if youS addiA > something you don't need or which destroys the design or offersuJ > possiblities you better don't want to have because they don't fit in the" > way things are best done so far. > H > Why would you like any of this COE stupidity from a technical point ofJ > view? And keep in mind that other things wouldn't be implemented because of! > the effort this COE task needs.    ------------------------------  % Date: Wed, 14 Mar 2001 20:16:09 +0000 0 From: andrew harrison <andrew.nospam@uk.sun.com>) Subject: Re: Possible security hole in....) Message-ID: <3AAFD189.51C86BA@uk.sun.com>e   jlsue wrote: > 5 > On Wed, 14 Mar 2001 10:21:12 +0000, andrew harrisont# > <andrew.nospam@uk.sun.com> wrote: 0 > >Forgive me for my cynicism but your responses1 > >in the past have almost always fallen into the : > >"what he says is true, but the message is uncomfortable4 > >so lets try to discredit the messenger" category. > G > Prove that statement.  I have no issue with identifying real problems H > so that we can address them.  I have never had a "shoot the messenger"E > attitude, only one of "if you're going to make a claim, provide all.H > the supporting evidence".  And that supporting evidence better be more! > than just your humble opinions.e >   . The previous posts in this thread from you are) perfectly adequate proof that this is thep case.   0 I could understand you forgetting our clustering0 discussuions it was a few weeks ago and memories fade but in this thread ???? > >i > >xF > >> And still, I don't  see anything in there that says whether we'reK > >> prone to those attacks.  You *assume* that we are, but I see no proof.sF > >> And if the solution for other vendors is outside of their systemsI > >> (i.e., add firewalls), then I don't see why OpenVMS shouldn't advisehI > >> the same (though I still haven't seen where that advice comes from).a > >e; > >Read the advisories, it would help. If you had you wouldt; > >discover that IBM and Sun for example provided fixes fort9 > >their respective OS's which do not require a Firewall.s > G > You happily avoid my challenge, once again.  You claim it *must* be anG > problem on OpenVMS, but I've never seen it.  So on what basis are youeE > making the claim that it needs to be fixed?  For all I know, it mayt: > have been fixed a long time ago, but you just avoid that > (conveniently).| >  > >rK > >How about Ping of Death. The POD advisory was orgionally another OpenVMShG > >free zone causing at least one poster to believe that OpenVMS wasn'tnA > >vunerable. Due probably to Hoff Hoffman's sharp jab in the eye-D > >this has been updated and we know find that OpenVMS was vunerable
 > >all along.< > H > Well, I *know* about the POD because I was a customer at that time.  ID > remember some very active responses from Digital (at that time) toF > provide fixes to UCX V4.x for that problem.  Note:  This is UCX (the@ > networking software), not a patch to OpenVMS.  And I know fromG > experience how & why this caused problems on UCX with OpenVMS (ACCVIO B > in kernel-mode code/driver, iirc).  The reason for the ACCVIO onF > OpenVMS is because of the page protection mechanisms, something thatG > makes it  very difficult, if not impossible, to actually execute codee4 > in a buffer overflow, unlike some other platforms. >   9 Look every time someone says OpenVMS is vunerable to thiss7 or that, someone like you comes back with the trite old . line, UCX isn't part of OpenVMS or CDE isn't.   5 Its funny that Compaq themselves don't actually agreer3 with you, they have issued responses to advisories e! under OpenVMS which refer to UCX.   8 People like you are also the first to claim that OpenVMS7 does ship with an IP stack (UCX) when someone complainsi2 that an OS without an IP stack in this day and age is pretty stupid.   8 Which is it, either UCX is part of OpenVMS in which case2 Compaq need to support it properly which includes 0 security risks associated with it or it isn't in/ which case OpenVMS is the only major OS without, a properly supported IP stack.  G > Funny thing about the POD:  I showed that the same base-code was also G > used in the firmware for HP printers' lan cards.  Using POD on one ofdD > them would put it into an error state that required power cycling. >   7 Thats probably because HP's printer IP stack was based   on the BSD stack.s  l > >a> > >If you are an OpenVMS advocate then I would advise steering= > >well clear of any mentions of CERT, its a shambles from an  > >OpenVMS standpoint. > < > Prove that statement.  How do you define this?  Is this anD > industry-standard definition?  Or just your own?  Is this *really*% > leaving OpenVMS systems vulnerable.  >   D I allready have. It is an indesputable fact that the CERT advisories> in respect to OpenVMS are either inaccurate, unhelpfull or non: existant, when there have been actual exploits that would ; effect OpenVMS. I have given you examples of all three what  more do you need.l     > > @ > >Note I am not making any suggestions that OpenVMS is insecure= > >but at least on the basis of CERT any claims for OpenVMS'sf; > >security relative to any other OS (Ok you can exclude NTs > >here) is anecdotal at best. > >  > > > Sure, but it makes a bit more sense than using the "lack" of- > information as proof that it is vulnerable.b  7 Soory you missed the point again. There are documented  ; examples of Compaq not posting responses to CERT advisoriest4 where Compaqs own documentation reveals that OpenVMS was vunerable. d   Regards  Andrew Harrisonr Enterprise IT Architectt   ------------------------------    Date: 14 Mar 2001 16:54:07 -0500- From: koehler@encompasserve.org (Bob Koehler)t) Subject: Re: Possible security hole in...n3 Message-ID: <SCUPp5IKYvYy@eisner.encompasserve.org>   \ In article <3AAFD189.51C86BA@uk.sun.com>, andrew harrison <andrew.nospam@uk.sun.com> writes: > : > Which is it, either UCX is part of OpenVMS in which case4 > Compaq need to support it properly which includes 2 > security risks associated with it or it isn't in1 > which case OpenVMS is the only major OS withouts  > a properly supported IP stack. >   G Sorry, Andrew, but you can't change the facts to make them match you'reoD preconceptions.  UCX is not a part of VMS and it does ship with VMS.. VMS has multiple properly supported IP stacks.  H In comparison, if I don't like Sun's IP stack on Solaris, who can I turn to to buy an alternate?h  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporationu= NASA GSFC Flight Software       | Federal Sector, Civil GroupiE                                 | please remove ".aspm" when replying    ------------------------------  # Date: Wed, 14 Mar 2001 22:24:06 GMTr  From: jlsue <jlsuexxxz@home.com>) Subject: Re: Possible security hole in...o8 Message-ID: <guovatc6gcudkrn6raitui6s0sr9qhlmnr@4ax.com>  3 On Wed, 14 Mar 2001 20:16:09 +0000, andrew harrison.! <andrew.nospam@uk.sun.com> wrote:i  
 >jlsue wrote:i >> o6 >> On Wed, 14 Mar 2001 10:21:12 +0000, andrew harrison$ >> <andrew.nospam@uk.sun.com> wrote:1 >> >Forgive me for my cynicism but your responsese2 >> >in the past have almost always fallen into the; >> >"what he says is true, but the message is uncomfortable 5 >> >so lets try to discredit the messenger" category.n >> sH >> Prove that statement.  I have no issue with identifying real problemsI >> so that we can address them.  I have never had a "shoot the messenger"vF >> attitude, only one of "if you're going to make a claim, provide allI >> the supporting evidence".  And that supporting evidence better be more " >> than just your humble opinions. >> ) >W/ >The previous posts in this thread from you areo* >perfectly adequate proof that this is the >case.    < Once again, when asked for specifics, you provide some vagueE accusation.  This is *exactly* what I am objecting to about your parti of this entire discussion.  B And all I've done in this entire thread is call into question yourA supposed "facts" about vulnerabilities in OpenVMS.  If you've gott" specific vulnerabilities, show me.   > 1 >I could understand you forgetting our clusteringr1 >discussuions it was a few weeks ago and memories  >fade but in this thread ????m  D What the heck are you talking about?  Do you really want to bring upB that discussion again?  I'm ready when you are, go on back to thatA thread to continue it.  I happen to have access to *every* single>D article in that thread.  It is you who has fogotten that thread.  InB every line of discussion I ask you to prove your position, and you? come back with vague notions & insinuations based on one or twogF examples.  In fact, I can say that in the last discussion, you dropped? off the topic for a few weeks without answering my last points.t  C This is yet *another* of your tactics.  When you can't possibly winU@ (in that case because you really don't know what the heck you're@ talking about), you drop it and then return weeks later claiming> victory.  But you never, EVER answer someone's point with real information.   >> >G >> >> And still, I don't  see anything in there that says whether we'reAL >> >> prone to those attacks.  You *assume* that we are, but I see no proof.G >> >> And if the solution for other vendors is outside of their systemstJ >> >> (i.e., add firewalls), then I don't see why OpenVMS shouldn't adviseJ >> >> the same (though I still haven't seen where that advice comes from). >> >< >> >Read the advisories, it would help. If you had you would< >> >discover that IBM and Sun for example provided fixes for: >> >their respective OS's which do not require a Firewall.  D Okay, I've been through the advisories, now you tell me where any ofF them say that OpenVMS is susceptible?  You are merely assuming that it< is, but you have yet to offer me proof.  Don't continue thisB discussion until you can give me something I can actually look at.  E First of all, not all OpenVMS systems use UCX.  Not even systems thatnE use UCX.  Do you know why?  Because there are other products offeringoE TCP/IP on OpenVMS like Multinet and TCPWARE.  And even sites that aredF running TCP/IP V5.0 and above aren't running the UCX software anymore.A It has been completely re-written and comes ported from the Tru641 code.0  F Now, of the CERT advisories you mention, only two are post-1998 (i.e.,B post V5.0), and they certainly don't even count anymore since that& older version of UCX is not supported.  F One of the later ones (CA-2000-13) I have found referenced in a CompaqB response, and that response only talks about issues on Tru64 Unix.: Does it have a problem on OpenVMS, it doesn't appear so.    @ Why can I make that statement?  Well, because I've checked a few@ others, (e.g., patches to cover Tru64 for CERT CA-2000-20 & CERT< CA-2001-02 ) that specifically that OpenVMS is not affected.  B What this tells me is that you can NOT automatically assume that a" vulnerability will affect OpenVMS.   >> lH >> You happily avoid my challenge, once again.  You claim it *must* be aH >> problem on OpenVMS, but I've never seen it.  So on what basis are youF >> making the claim that it needs to be fixed?  For all I know, it may; >> have been fixed a long time ago, but you just avoid thaty >> (conveniently). >>   >> >L >> >How about Ping of Death. The POD advisory was orgionally another OpenVMSH >> >free zone causing at least one poster to believe that OpenVMS wasn'tB >> >vunerable. Due probably to Hoff Hoffman's sharp jab in the eyeE >> >this has been updated and we know find that OpenVMS was vunerable  >> >all along. >> nI >> Well, I *know* about the POD because I was a customer at that time.  IaE >> remember some very active responses from Digital (at that time) to G >> provide fixes to UCX V4.x for that problem.  Note:  This is UCX (theoA >> networking software), not a patch to OpenVMS.  And I know fromiH >> experience how & why this caused problems on UCX with OpenVMS (ACCVIOC >> in kernel-mode code/driver, iirc).  The reason for the ACCVIO oneG >> OpenVMS is because of the page protection mechanisms, something thathH >> makes it  very difficult, if not impossible, to actually execute code5 >> in a buffer overflow, unlike some other platforms.p >> . > : >Look every time someone says OpenVMS is vunerable to this8 >or that, someone like you comes back with the trite old/ >line, UCX isn't part of OpenVMS or CDE isn't. l >M6 >Its funny that Compaq themselves don't actually agree4 >with you, they have issued responses to advisories " >under OpenVMS which refer to UCX.  E Okay, so what's your point?  That won't help someone with Multinet or'5 TCPware.  Those systems may or may not be vulnerable.e > 9 >People like you are also the first to claim that OpenVMSl8 >does ship with an IP stack (UCX) when someone complains3 >that an OS without an IP stack in this day and agen >is pretty stupid. r > 9 >Which is it, either UCX is part of OpenVMS in which caseu3 >Compaq need to support it properly which includes  1 >security risks associated with it or it isn't in20 >which case OpenVMS is the only major OS without >a properly supported IP stack.p  E Ah, I see now.  You're trying to muddy the waters with ambiguities so-> that you can push more FUD.  Again, what about those who use aB different vendor's IP stack?  If Oracle has a bug, do you say that9 OpenVMS is vulnerable?  Or do you say that Oracle has it?i  C Sure, the IP stack can have bugs, and on OpenVMS they will manifest D themselves in ways that may not be the same as on Unix.  What's your point?     >  >> >? >> >If you are an OpenVMS advocate then I would advise steeringe> >> >well clear of any mentions of CERT, its a shambles from an >> >OpenVMS standpoint.  >> y= >> Prove that statement.  How do you define this?  Is this an E >> industry-standard definition?  Or just your own?  Is this *really* & >> leaving OpenVMS systems vulnerable. >> a >lE >I allready have. It is an indesputable fact that the CERT advisories ? >in respect to OpenVMS are either inaccurate, unhelpfull or non(; >existant, when there have been actual exploits that would  < >effect OpenVMS. I have given you examples of all three what >more do you need.  D Again, you "claim" that there have been exploits where there haven'tD been fixes.  Show me.  Your example of the POD is invalid because itE was fixed, and there was no problem with the (then Digital) method ofp; addressing it.  So, give me something concrete, or shut up.   E When you begin providing concrete examples of real problems (not just # imagined ones) I'll not bother you.o   ------------------------------    Date: 15 Mar 2001 08:46:03 +0800, From: Paul Repacholi <prep@prep.synonet.com>) Subject: Re: Possible security hole in...s- Message-ID: <87n1ansvuc.fsf@prep.synonet.com>t  / koehler@encompasserve.org (Bob Koehler) writes:a  ; > In article <3AAFD189.51C86BA@uk.sun.com>, andrew harrisonh$ > <andrew.nospam@uk.sun.com> writes:  C > > Which is it, either UCX is part of OpenVMS in which case Compaq = > > need to support it properly which includes security risksND > > associated with it or it isn't in which case OpenVMS is the only3 > > major OS without a properly supported IP stack.v  B > Sorry, Andrew, but you can't change the facts to make them matchC > you're preconceptions.  UCX is not a part of VMS and it does shipf; > with VMS.  VMS has multiple properly supported IP stacks.o  E > In comparison, if I don't like Sun's IP stack on Solaris, who can Ie > turn to to buy an alternate?  ? If you have to keep you uptime stable, you could get Win98.  :)i   -- l< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.n@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------  % Date: Wed, 14 Mar 2001 22:00:48 -0000 . From: "robert.glen" <robert.glen@ntlworld.com> Subject: Splitting a Large FileuA Message-ID: <iSRr6.2511$y47.527428@news2-win.server.ntlworld.com>c  = I have a large file which I can open up in my editor ( LSE ).e  K However I wish to split the file into two parts ( approx 6000 lines each ).e  F Is there a command to do this with, similar to the Unix split command?  G I have tried using the Read and Write commands but get errors regardingo running out of buffer space.I I have tried using type /tail=6000 and re-directing the output to a file, 0 but the lines are too long for the type command.   Any suggestions appreciated.   Robert   ------------------------------  # Date: Thu, 15 Mar 2001 01:46:57 GMTe3 From: Michael Austin <michaelaustininc@hotmail.com>-# Subject: Re: Splitting a Large Files+ Message-ID: <3AB01EF9.466D7C77@hotmail.com>u  K What is the record size?  do a dir/full on the file to get the record size.IC what is the file type? streamlf? sequential? (also in the dir/full)o   if you can use LSE (TPU)   $LSE <filename>o   press select commando                   line 6000y cutn commandl                   get <filepart1> pasted ^Z     save both fileso  N OR if the record size is small enough this should work..  If not then you will4 need to write a C,Basic, FORTRAN program to do it...  " $open/read  ifile <input filename>  $open/write ofile1 <outputfile1>  $open/write ofile2 <outputfile2> $cnt = 1 $loop: $read/end=end ifile recr $if cnt .LE. 6000o $then> $write ofile1 reco $elset $write ofile2 reci $endif $cnt = cnt+1
 $goto loop $end:r $close ifile
 $close ofile1 
 $close ofile2' $exite       "robert.glen" wrote:  ? > I have a large file which I can open up in my editor ( LSE ).e >vM > However I wish to split the file into two parts ( approx 6000 lines each ).  >mH > Is there a command to do this with, similar to the Unix split command? >wI > I have tried using the Read and Write commands but get errors regardingf > running out of buffer space.K > I have tried using type /tail=6000 and re-directing the output to a file,o2 > but the lines are too long for the type command. >  > Any suggestions appreciated. >. > Robert   ------------------------------  % Date: Wed, 14 Mar 2001 18:11:47 -0500 % From: "Brian Tillman" <tillman_brian>e) Subject: Re: TPU SORT procedure requestede$ Message-ID: <3aaffaf4$1@news.si.com>  C >Where can I find a SORT procedure to be added in my $section file,r >please?   Here's one that works in LSEDIT  --A Brian Tillman                   Internet: tillman_brian at si.com A Smiths Aerospace                          tillman at swdev.si.comr= 3290 Patterson Ave. SE, MS      Addresses modified to preventX< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company  	 !SORT.TPUa !tI ! This routine sorts the selected range of lines into alphabetical order.r !.E ! Note -- this routine uses the external routines Get_Line_Number and  !         String_Compare.o !  PROCEDURE lsi_sort_select_range   <   LOCAL mode, nrecs, orgpos, precs, rec1, rec2, ridx, tidx ; !t ! Error Handler. !t
   ON_ERROR     POSITION (orgpos) ;t     SET (mode,CURRENT_BUFFER) ;nA     MESSAGE (FAO("!AS, line number !UL",error_text,error_line)) ;l#     MESSAGE ("Command cancelled") ;n     RETURN 0 ;   ENDON_ERROR; ! E ! If a range is not selected, output a message and abort.  Otherwise, C ! establish markers to the beginning and end of the selected range.a !d$   IF NOT LSE$SELECT_IN_PROGRESS THEN%     MESSAGE ("No selection active") ;a#     MESSAGE ("Command cancelled") ;S     RETURN 0 ;   ELSE     LSE$CREATE_SELECT_RANGE ;t	   ENDIF ;  !n7 ! Save insert/overstrike mode, then set mode to insert.a !n,   mode := GET_INFO (CURRENT_BUFFER,"mode") ;    SET (INSERT, CURRENT_BUFFER) ; !>G ! Save current position, then determine the number of lines to sort andm( ! position the cursor to the first line. !c   orgpos := MARK(NONE) ;'   POSITION (END_OF(LSE$SELECT_RANGE)) ;    nrecs := Get_Line_Number ;-   POSITION (BEGINNING_OF(LSE$SELECT_RANGE)) ;,(   nrecs := nrecs - Get_Line_Number + 1 ;   precs := nrecs ; !hI ! Keep looping through the range, each time decreasing the partition sized5 ! in half, until the partition size is less then one.S !    LOOP     precs := precs / 2 ;     EXITIF (precs < 1) ;     ridx := 1 ;      LOOP%       EXITIF (ridx + precs > nrecs) ;        tidx := ridx ; !fE ! Compare each record in a partition with the corresponding record insF ! the next partition and swap them if the first is greater.  If a swapD ! is performed, continue to swap the lesser with previous partitions ! until no swap is made. !e
       LOOP         rec1 := CURRENT_LINE ;         MOVE_VERTICAL (precs) ;r         rec2 := CURRENT_LINE ;2         EXITIF (String_Compare (rec1,rec2) <> 1) ;         COPY_TEXT (rec1) ;         SPLIT_LINE ;         ERASE_LINE ;"         MOVE_VERTICAL (-precs-1) ;         COPY_TEXT (rec2) ;         SPLIT_LINE ;         ERASE_LINE ;!         MOVE_VERTICAL (precs-1) ;           EXITIF (tidx <= precs) ;"         MOVE_VERTICAL (-2*precs) ;         tidx := tidx - precs ;       ENDLOOP ;n)       MOVE_VERTICAL (ridx-tidx-precs+1) ;o       ridx := ridx + 1 ;
     ENDLOOP ;s!     MOVE_VERTICAL (precs-nrecs) ;w   ENDLOOP ;n ! % ! Restore original mode and position.l !u   SET (mode,CURRENT_BUFFER) ;    POSITION (orgpos) ;m     ENDPROCEDURE ! Sort_Ranges !-L !--------------------------------------------------------------------------- ---- ! ? ! This routine returns the line number of the current position.l !    PROCEDURE Get_Line_Number   (   LOCAL org_pos, org_lin, nline, delta ; !n> ! Save the original cursor position and disable screen update. !e   org_pos := MARK (NONE) ;   SET (SCREEN_UPDATE, OFF) ; !yJ ! Mark the begining of the line, then move to the beginning of the buffer. ! %   MOVE_HORIZONTAL (-CURRENT_OFFSET) ;n   org_lin := MARK (NONE) ;+   POSITION (BEGINNING_OF(CURRENT_BUFFER)) ;f ! H ! Perform a binary search to determine original line number.  InitializeG ! the line number to one and the search range to total number of lines.l !d   nline := 1 ;6   delta := GET_INFO (CURRENT_BUFFER, "record_count") ;     LOOP     EXITIF delta = 0 ;     delta := (delta + 1) / 2 ;!     IF MARK (NONE) < org_lin THENt       MOVE_VERTICAL (delta) ;.       nline := nline + delta ;     ELSE#       IF MARK (NONE) > org_lin THEN"          MOVE_VERTICAL (-delta) ;          nline := nline - delta ;
       ELSE         delta := 0 ;
       ENDIF ;e     ENDIF ;    ENDLOOP ;e !wB ! Restore original position, then restore screen update and return ! line number. !    POSITION (org_pos) ;   SET (SCREEN_UPDATE, ON) ;n   RETURN nline ;      ENDPROCEDURE ! Get_Line_Number !)L !--------------------------------------------------------------------------- ---- !+E ! This routine compares two strings, and returns one of the followingl	 ! values,h !  !      1 if str1 > str2a !      0 if str1 = str2m !     -1 if str1 < str2v !r; ! Note -- this routine is case sensitive (i.e. - "a" > "A"). !.'   PROCEDURE String_Compare (str1, str2)u  -   LOCAL idx, chr1, chr2, len1, len2, result ;  !pI ! Initialize the string index, then determine the lengths of the strings.  !l   idx := 1 ;   len1 := length (str1) ;    len2 := length (str2) ;e !eG ! Initialize the result based on the lengths of the records.  If string H ! 1 is longer then string 2, initialize the result to 1.  If the stringsG ! are equal length, initialize the result to 0.  If string 1 is shorterS- ! then string 2, initialize the result to -1.s !    IF len1 > len2 THEN      result := 1 ;    ELSE     IF len1 = len2 THENu       result := 0 ;n     ELSE       result := -1 ;     ENDIF ;,	   ENDIF ;g !WH ! Loop through the strings until the end of one is reached (or until one# ! is found greater then the other).  !    LOOP     EXITIF (len1 < idx) ;      EXITIF (len2 < idx) ; !     chr1 := SUBSTR (str1,idx,1) ;e!     chr2 := SUBSTR (str2,idx,1) ;.     IF (chr1 > chr2) THEN-       RETURN 1 ;     ENDIF ;1     IF (chr1 < chr2) THENb       RETURN -1 ;l     ENDIF ;o     idx := idx + 1 ;   ENDLOOP ;u     RETURN result ;2     ENDPROCEDURE ! String_Comparew   ------------------------------  % Date: Wed, 14 Mar 2001 12:40:08 -0700e$ From: Lee Y T Mah <lytmah@cha.ab.ca>7 Subject: Re: Volume Shadowing merge rates on Big Disks?c) Message-ID: <3AAFC918.A2064B4A@cha.ab.ca>    Real life experience:t     VMS 7.1-2.D     Four homogeneous clustered AlphaServer 1200's.  Two nodes in two separate computer rooms.      Host-based volume shadowing.F     Two HSJ40 and two HSJ50 controllers in each computer room.  Mix of  4.3GB  and 9.1GB shadow members.4     Over forty shadow members in each computer room.:     Rough time to shadow copy a 4.3GB: less than one hour.H     I have had to shadow copy all members of a whole room several times.$ Total elapsed time: less than a day.   John Jansen wrote:   > Hi,c >RH > Currently we use a Alpha 4100/300 with 4 gig and 9 gig disks in shadow > sets.u* > A shadow merge can take over a full day. >0H > We are considering the purchase of a dse20 with 9 gig and 18 gig disksF > in shadow sets. This system is supposed to be 4 times as fast as ourG > current one, but no one seems to be able to give me and indication ofeF > how long it would take for a shadow set merge of the 18 gig disks on > this system. > J > Has any one had a real life experience of how long a merge would take. ID > am looking to get an indication as to whether it will be and hour, > hours, days??e >c > Thanking you for you helpp >i	 > Regards" >A > John Jansen. >e > --B > ________________________________________________________________
 > John Jansenh > Group I.T Managere > Truck Investments Limiteda' > Phone - Work    (64 6) 356-7179 x 826a! > or direct Line  (64 6) 351-9826i! > Fax             (64 6) 356 5586n  > E-mail  JJansen@tilgroup.co.nzB > ________________________________________________________________   -- Leee  ; Lee Y T Mah                        Capital Health Authoritya? Email: lytmah@cha.ab.ca            Information Systems, RAH CSCo4 Phone:  (780) 477-4725, 477-4233   10240 Kingsway NW? Fax:      (780) 491-5119, 491-5619    Edmonton, AB, CAN  T5H3V9m   ------------------------------  % Date: Thu, 15 Mar 2001 09:39:08 +1300a* From: John Jansen <jjansen@tilgroup.co.nz>7 Subject: Re: Volume Shadowing merge rates on Big Disks?i. Message-ID: <3AAFD6E8.45855E6C@tilgroup.co.nz>  L Thank you for the Real life example. My copy times are about 1.5 hours for 4K gig and 3 hours for 9 gig. It is the merge time which is of concern for me.n= On the current system that is over a day for the 9 gig disks.x   Thanks   JJ --     Lee Y T Mah wrote:   > Real life experience:u >     VMS 7.1-2.F >     Four homogeneous clustered AlphaServer 1200's.  Two nodes in two > separate computer rooms." >     Host-based volume shadowing.H >     Two HSJ40 and two HSJ50 controllers in each computer room.  Mix of" > 4.3GB  and 9.1GB shadow members.6 >     Over forty shadow members in each computer room.< >     Rough time to shadow copy a 4.3GB: less than one hour.J >     I have had to shadow copy all members of a whole room several times.& > Total elapsed time: less than a day. >  > John Jansen wrote: >. > > Hi,t > >lJ > > Currently we use a Alpha 4100/300 with 4 gig and 9 gig disks in shadow	 > > sets.o, > > A shadow merge can take over a full day. > > J > > We are considering the purchase of a dse20 with 9 gig and 18 gig disksH > > in shadow sets. This system is supposed to be 4 times as fast as ourI > > current one, but no one seems to be able to give me and indication oflH > > how long it would take for a shadow set merge of the 18 gig disks on > > this system. > >eL > > Has any one had a real life experience of how long a merge would take. IF > > am looking to get an indication as to whether it will be and hour, > > hours, days??  > >e > > Thanking you for you helph > >  > > Regardsu > >s > > John Jansen. > >  > > --D > > ________________________________________________________________ > > John Jansen  > > Group I.T Managera > > Truck Investments Limitedi) > > Phone - Work    (64 6) 356-7179 x 826y# > > or direct Line  (64 6) 351-9826 # > > Fax             (64 6) 356 5586i" > > E-mail  JJansen@tilgroup.co.nzD > > ________________________________________________________________ >' > -- > Leea >O= > Lee Y T Mah                        Capital Health AuthoritytA > Email: lytmah@cha.ab.ca            Information Systems, RAH CSCo6 > Phone:  (780) 477-4725, 477-4233   10240 Kingsway NWA > Fax:      (780) 491-5119, 491-5619    Edmonton, AB, CAN  T5H3V9t   --@ ________________________________________________________________ John Jansenw Group I.T ManagerB Truck Investments Limited % Phone - Work    (64 6) 356-7179 x 826d or direct Line  (64 6) 351-9826f Fax             (64 6) 356 5586b E-mail  JJansen@tilgroup.co.nz@ ________________________________________________________________   ------------------------------  % Date: Thu, 15 Mar 2001 09:55:16 +1300 * From: John Jansen <jjansen@tilgroup.co.nz>7 Subject: Re: Volume Shadowing merge rates on Big Disks?R. Message-ID: <3AAFDAB0.AFB76C42@tilgroup.co.nz>   Thank you for your reply,   E My merge times on the current system for a 4 gig 3 disk shadow set isS# (system disk) about 12 to 16 hours.r  . The 9 gig Data disks are taking 24 to 30 hours  E This has is only of concern after a crash. Copies are much faster andn* acceptable at 1.5 and 3 hour respectively.  H My question is prompted by the need for speed in recovery after a systemB crash an if necessary getting a valid backup before another crash.I Fortunately under VMS those are few and far between. With the larger disk H size it is a big concern to me as to how long a merge will take. That is- why I am looking for some indicative timings.h   Many thanks for your input regards.   JJ  :-)    Paul Repacholi wrote:d  . > John Jansen <jjansen@tilgroup.co.nz> writes: >-C > > Currently we use a Alpha 4100/300 with 4 gig and 9 gig disks in : > > shadow sets.  A shadow merge can take over a full day. > A > My 3000/600 merged a 4GB set in about 2 1/2 Hrs today. ( *Ugly*e< > details later ) What is the sysgen shadow_max_copy set to? >o >aD > > We are considering the purchase of a dse20 with 9 gig and 18 gigG > > disks in shadow sets. This system is supposed to be 4 times as fastcB > > as our current one, but no one seems to be able to give me andF > > indication of how long it would take for a shadow set merge of the  > > 18 gig disks on this system. >nD > > Has any one had a real life experience of how long a merge wouldG > > take. I am looking to get an indication as to whether it will be an  > > hour, hours, days??n >mD > You have to pick the trade off of time vs kicking your system intoC > the weeds. Faster the copies, more of a IO hit you take. The time-F > will depend on IO layout details. ( You don't have both disks on the > one SCSI bus I hope? ) >FG > Also the controller type. Mylexs are limited in the IO count to about * > a couple of hundred IOs/sec from memory. >y > --> > Paul Repacholi                               1 Crescent Rd.,9 > +61 (08) 9257-1001                           Kalamunda.sB >                                              West Australia 60760 > Raw, Cooked or Well-done, it's all half baked.   --@ ________________________________________________________________ John Jansen> Group I.T Manager1 Truck Investments Limitedr% Phone - Work    (64 6) 356-7179 x 826t or direct Line  (64 6) 351-9826m Fax             (64 6) 356 5586p E-mail  JJansen@tilgroup.co.nz@ ________________________________________________________________   ------------------------------  % Date: Thu, 15 Mar 2001 10:03:39 +1300t* From: John Jansen <jjansen@tilgroup.co.nz>7 Subject: Re: Volume Shadowing merge rates on Big Disks?v. Message-ID: <3AAFDCA7.B4D4BCEE@tilgroup.co.nz>   Than you for your reply,I The link provided is and interesting one I had no seen before. Thank you.p  * I have SHAD$MERGE_DELAY_FACTOR set to 500.  / The system I am evaluating will have will use ;t@ 1 x 9GB 15K RPM ULTRA3 UNIVERSAL HOT PLUG DRIVE for inside DS20EA 2 x 18GB 15K RPM ULTRA3 UNIVERSAL HOT PLUG DRIVE for inside DS20Ev, 2 x 1 Channel WIDE ULTRA-2(LVD) SCSI adapterG 1 x 7 Device Ultra Blue Pedestal (split bus, 1 x 180 watt power supply)n6 4 x 18.2GB 10000 RPM Ultra SCSI 16 Bit Wide Disk Drive* 2 x 9GB 10K RPM ULTRA SCSI  HOT PLUG DRIVE  2 These will be used to make 3 x 3 disk shadow sets.  J Before proceeding I need to be confident these shadows sets can merge in a reasonable time frame.   Thanks for you help, Regards    JJ  :-)e   "Thomas H. Pauli" wrote:   > John Jansen wrote: >u > > Hi,a > > J > > Currently we use a Alpha 4100/300 with 4 gig and 9 gig disks in shadow	 > > sets. , > > A shadow merge can take over a full day. > >n > > J > > We are considering the purchase of a dse20 with 9 gig and 18 gig disksH > > in shadow sets. This system is supposed to be 4 times as fast as ourI > > current one, but no one seems to be able to give me and indication of H > > how long it would take for a shadow set merge of the 18 gig disks on > > this system. > ><L > > Has any one had a real life experience of how long a merge would take. IF > > am looking to get an indication as to whether it will be and hour, > > hours, days??d > >  > >a > > Thanking you for you helpf > >t > > Regards  > >t > > John Jansen. > >R > >o > > --D > > ________________________________________________________________ > > John Jansen/ > > Group I.T Managere > > Truck Investments Limited=) > > Phone - Work    (64 6) 356-7179 x 826 # > > or direct Line  (64 6) 351-9826i# > > Fax             (64 6) 356 5586 " > > E-mail  JJansen@tilgroup.co.nzD > > ________________________________________________________________ >l
 > Hi John, > G > as so often in this world: it depends. It depends mostly on what kindiH > of hardware these disks are connected to. What controllers, busses andH > last but not least, if it's host based shadowing, how much CPU-time is< > left for these operations. And, then there ist the logical > SHAD$MERGE_DELAY_FACTOR (SeeJ > http://www.openvms.compaq.com:8000/721final/5423/5423pro_009.html for an: > explanation). The fastest results could be achieved widhG > FC-Configurations, which are IMHO the only ones one can live with and ' > shadowed disks of more than 9GB size.  >m > Greetings, Thomasl   --@ ________________________________________________________________ John Jansens Group I.T Managerc Truck Investments Limitedt% Phone - Work    (64 6) 356-7179 x 826s or direct Line  (64 6) 351-9826E Fax             (64 6) 356 5586  E-mail  JJansen@tilgroup.co.nz@ ________________________________________________________________   ------------------------------  # Date: Thu, 15 Mar 2001 00:59:20 GMTn/ From: StevenU@POBoxes.com (Steven P. Underwood)e7 Subject: Re: Volume Shadowing merge rates on Big Disks?t2 Message-ID: <3aaffc1a.593516675@news.telocity.com>  E Just happened to have my 9.1GB mirrored system disk replaced today athD noon.  These drives are both attached to the internal bus of my ES40D (I know, not a good idea to have both on the same bus, but the pennyF pinchers won that argument).  Just over an hour to complete the merge.  8 %%%%%%%%%%%  OPCOM  14-MAR-2001 12:08:54.07  %%%%%%%%%%%" Message from user SYSTEM on ALPHA1C %SHADOW_SERVER-I-SSRVINICPY, initiating copy operation on _DSA1: at  LBN: 0, I/On2 size: 127 blocks, ID number: 140003F8, Factor 200.  8 %%%%%%%%%%%  OPCOM  14-MAR-2001 13:13:44.23  %%%%%%%%%%%" Message from user SYSTEM on ALPHA1D %SHADOW_SERVER-I-SSRVNORMAL, successful completion of copy operation on device _G, DSA1: at LBN: 17773524, ID number: 140003F8.  	 Good lucke   Steve     / On Thu, 15 Mar 2001 09:55:16 +1300, John Jansen  <jjansen@tilgroup.co.nz> wrote:r   >Thank you for your reply, >eF >My merge times on the current system for a 4 gig 3 disk shadow set is$ >(system disk) about 12 to 16 hours. >t/ >The 9 gig Data disks are taking 24 to 30 hoursn > F >This has is only of concern after a crash. Copies are much faster and+ >acceptable at 1.5 and 3 hour respectively.r > I >My question is prompted by the need for speed in recovery after a systemcC >crash an if necessary getting a valid backup before another crash.oJ >Fortunately under VMS those are few and far between. With the larger diskI >size it is a big concern to me as to how long a merge will take. That iss. >why I am looking for some indicative timings. >  >Many thanks for your input+	 >regards.e >  >JJ  :-) >x >Paul Repacholi wrote: >a/ >> John Jansen <jjansen@tilgroup.co.nz> writes:e >>D >> > Currently we use a Alpha 4100/300 with 4 gig and 9 gig disks in; >> > shadow sets.  A shadow merge can take over a full day.i >>B >> My 3000/600 merged a 4GB set in about 2 1/2 Hrs today. ( *Ugly*= >> details later ) What is the sysgen shadow_max_copy set to?2 >> >>E >> > We are considering the purchase of a dse20 with 9 gig and 18 gig H >> > disks in shadow sets. This system is supposed to be 4 times as fastC >> > as our current one, but no one seems to be able to give me andIG >> > indication of how long it would take for a shadow set merge of theX! >> > 18 gig disks on this system.E >>E >> > Has any one had a real life experience of how long a merge would H >> > take. I am looking to get an indication as to whether it will be an >> > hour, hours, days?? >>E >> You have to pick the trade off of time vs kicking your system intolD >> the weeds. Faster the copies, more of a IO hit you take. The timeG >> will depend on IO layout details. ( You don't have both disks on the- >> one SCSI bus I hope? )- >>H >> Also the controller type. Mylexs are limited in the IO count to about+ >> a couple of hundred IOs/sec from memory.  >> >> --g? >> Paul Repacholi                               1 Crescent Rd., : >> +61 (08) 9257-1001                           Kalamunda.C >>                                              West Australia 6076o1 >> Raw, Cooked or Well-done, it's all half baked.Z >A >--UA >_________________________________________________________________ >John Jansen >Group I.T Manager >Truck Investments Limited& >Phone - Work    (64 6) 356-7179 x 826  >or direct Line  (64 6) 351-9826  >Fax             (64 6) 356 5586 >E-mail  JJansen@tilgroup.co.nz A >________________________________________________________________F >l >=   Steven P. Underwood,DNRC Whitinsville,MAM StevenU@POBoxes.comT   ------------------------------    Date: 15 Mar 2001 08:41:59 +0800, From: Paul Repacholi <prep@prep.synonet.com>7 Subject: Re: Volume Shadowing merge rates on Big Disks?e- Message-ID: <87r8zzsw14.fsf@prep.synonet.com>   , John Jansen <jjansen@tilgroup.co.nz> writes:  1 > The system I am evaluating will have will use ; B > 1 x 9GB 15K RPM ULTRA3 UNIVERSAL HOT PLUG DRIVE for inside DS20EC > 2 x 18GB 15K RPM ULTRA3 UNIVERSAL HOT PLUG DRIVE for inside DS20Er. > 2 x 1 Channel WIDE ULTRA-2(LVD) SCSI adapterI > 1 x 7 Device Ultra Blue Pedestal (split bus, 1 x 180 watt power supply)t8 > 4 x 18.2GB 10000 RPM Ultra SCSI 16 Bit Wide Disk Drive, > 2 x 9GB 10K RPM ULTRA SCSI  HOT PLUG DRIVE > 4 > These will be used to make 3 x 3 disk shadow sets.  D If you have 3 member sets, I would recomend another controller. ThisD enables you to not force bus contention by haveing 2 member of a setE on the one bus, and will get you to the performance sweet spot of 2-3 F drives per bus. ( The later seems to be a constant, over a 20 odd year; span from comp.arch.storage postings ove the last decade. )e  B DON'T put tapes or CDs on these buses. The reselect time will kill performance.   -- s< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.1@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------  % Date: Thu, 15 Mar 2001 14:18:11 +1300s* From: John Jansen <jjansen@tilgroup.co.nz>7 Subject: Re: Volume Shadowing merge rates on Big Disks?P. Message-ID: <3AB01846.C9EA50BA@tilgroup.co.nz>  E Sorry to disappoint you but this timing is for a copy which is alwaysxK considerably faster than a merge. Typically you have a merge after a crash.h   Thanks for the thought.U   JJ :-)   "Steven P. Underwood" wrote:  G > Just happened to have my 9.1GB mirrored system disk replaced today at F > noon.  These drives are both attached to the internal bus of my ES40F > (I know, not a good idea to have both on the same bus, but the pennyH > pinchers won that argument).  Just over an hour to complete the merge. >l: > %%%%%%%%%%%  OPCOM  14-MAR-2001 12:08:54.07  %%%%%%%%%%%$ > Message from user SYSTEM on ALPHA1E > %SHADOW_SERVER-I-SSRVINICPY, initiating copy operation on _DSA1: at 
 > LBN: 0, I/Ow4 > size: 127 blocks, ID number: 140003F8, Factor 200. > : > %%%%%%%%%%%  OPCOM  14-MAR-2001 13:13:44.23  %%%%%%%%%%%$ > Message from user SYSTEM on ALPHA1F > %SHADOW_SERVER-I-SSRVNORMAL, successful completion of copy operation
 > on device _f. > DSA1: at LBN: 17773524, ID number: 140003F8. >e > Good luck. >  > Stevee >r1 > On Thu, 15 Mar 2001 09:55:16 +1300, John Jansen/! > <jjansen@tilgroup.co.nz> wrote:h >w > >Thank you for your reply, > >kH > >My merge times on the current system for a 4 gig 3 disk shadow set is& > >(system disk) about 12 to 16 hours. > >s1 > >The 9 gig Data disks are taking 24 to 30 hours  > >nH > >This has is only of concern after a crash. Copies are much faster and- > >acceptable at 1.5 and 3 hour respectively.1 > > K > >My question is prompted by the need for speed in recovery after a system E > >crash an if necessary getting a valid backup before another crash.tL > >Fortunately under VMS those are few and far between. With the larger diskK > >size it is a big concern to me as to how long a merge will take. That is_0 > >why I am looking for some indicative timings. > >r > >Many thanks for your inputt > >regards.a > >h
 > >JJ  :-) > >  > >Paul Repacholi wrote: > > 1 > >> John Jansen <jjansen@tilgroup.co.nz> writes:6 > >>F > >> > Currently we use a Alpha 4100/300 with 4 gig and 9 gig disks in= > >> > shadow sets.  A shadow merge can take over a full day.  > >>D > >> My 3000/600 merged a 4GB set in about 2 1/2 Hrs today. ( *Ugly*? > >> details later ) What is the sysgen shadow_max_copy set to?3 > >> > >>G > >> > We are considering the purchase of a dse20 with 9 gig and 18 gigmJ > >> > disks in shadow sets. This system is supposed to be 4 times as fastE > >> > as our current one, but no one seems to be able to give me andwI > >> > indication of how long it would take for a shadow set merge of then# > >> > 18 gig disks on this system.m > >>G > >> > Has any one had a real life experience of how long a merge wouldtJ > >> > take. I am looking to get an indication as to whether it will be an > >> > hour, hours, days?? > >>G > >> You have to pick the trade off of time vs kicking your system into F > >> the weeds. Faster the copies, more of a IO hit you take. The timeI > >> will depend on IO layout details. ( You don't have both disks on the. > >> one SCSI bus I hope? )5 > >>J > >> Also the controller type. Mylexs are limited in the IO count to about- > >> a couple of hundred IOs/sec from memory.r > >> > >> --oA > >> Paul Repacholi                               1 Crescent Rd.,h< > >> +61 (08) 9257-1001                           Kalamunda.E > >>                                              West Australia 6076 3 > >> Raw, Cooked or Well-done, it's all half baked.i > >g > >--9C > >________________________________________________________________f > >John Jansen > >Group I.T Manager > >Truck Investments Limited( > >Phone - Work    (64 6) 356-7179 x 826" > >or direct Line  (64 6) 351-9826" > >Fax             (64 6) 356 5586! > >E-mail  JJansen@tilgroup.co.nzeC > >________________________________________________________________e > >f > >1 >i > Steven P. Underwood,DNRC > Whitinsville,MA  > StevenU@POBoxes.come   --@ ________________________________________________________________ John Jansenh Group I.T Managerd Truck Investments Limited % Phone - Work    (64 6) 356-7179 x 826  or direct Line  (64 6) 351-9826J Fax             (64 6) 356 5586_ E-mail  JJansen@tilgroup.co.nz@ ________________________________________________________________   ------------------------------  # Date: Thu, 15 Mar 2001 02:32:10 GMT2/ From: StevenU@POBoxes.com (Steven P. Underwood) 7 Subject: Re: Volume Shadowing merge rates on Big Disks?p2 Message-ID: <3ab0293c.605072686@news.telocity.com>  A Thanks for the information and sorry for any confusion I may have 8 caused.  This is the first system I have used shadowing.   Steve   / On Thu, 15 Mar 2001 14:18:11 +1300, John Jansen  <jjansen@tilgroup.co.nz> wrote:K  F >Sorry to disappoint you but this timing is for a copy which is alwaysL >considerably faster than a merge. Typically you have a merge after a crash. >n >Thanks for the thought. >  >JJ :-)e >e >"Steven P. Underwood" wrote:6 >)H >> Just happened to have my 9.1GB mirrored system disk replaced today atG >> noon.  These drives are both attached to the internal bus of my ES40_G >> (I know, not a good idea to have both on the same bus, but the pennyaI >> pinchers won that argument).  Just over an hour to complete the merge.o >>; >> %%%%%%%%%%%  OPCOM  14-MAR-2001 12:08:54.07  %%%%%%%%%%%e% >> Message from user SYSTEM on ALPHA1oF >> %SHADOW_SERVER-I-SSRVINICPY, initiating copy operation on _DSA1: at >> LBN: 0, I/O5 >> size: 127 blocks, ID number: 140003F8, Factor 200.s >>; >> %%%%%%%%%%%  OPCOM  14-MAR-2001 13:13:44.23  %%%%%%%%%%%i% >> Message from user SYSTEM on ALPHA1 G >> %SHADOW_SERVER-I-SSRVNORMAL, successful completion of copy operatione >> on device _/ >> DSA1: at LBN: 17773524, ID number: 140003F8.m >> >> Good luck >> >> Steve >>2 >> On Thu, 15 Mar 2001 09:55:16 +1300, John Jansen" >> <jjansen@tilgroup.co.nz> wrote: >> >> >Thank you for your reply,b >> >I >> >My merge times on the current system for a 4 gig 3 disk shadow set iss' >> >(system disk) about 12 to 16 hours.o >> >2 >> >The 9 gig Data disks are taking 24 to 30 hours >> >I >> >This has is only of concern after a crash. Copies are much faster andA. >> >acceptable at 1.5 and 3 hour respectively. >> >L >> >My question is prompted by the need for speed in recovery after a systemF >> >crash an if necessary getting a valid backup before another crash.M >> >Fortunately under VMS those are few and far between. With the larger disk L >> >size it is a big concern to me as to how long a merge will take. That is1 >> >why I am looking for some indicative timings.e >> > >> >Many thanks for your input >> >regards. >> > >> >JJ  :-)g >> > >> >Paul Repacholi wrote:e >> >2 >> >> John Jansen <jjansen@tilgroup.co.nz> writes: >> >> G >> >> > Currently we use a Alpha 4100/300 with 4 gig and 9 gig disks ini> >> >> > shadow sets.  A shadow merge can take over a full day. >> >>dE >> >> My 3000/600 merged a 4GB set in about 2 1/2 Hrs today. ( *Ugly*s@ >> >> details later ) What is the sysgen shadow_max_copy set to? >> >>t >> >> H >> >> > We are considering the purchase of a dse20 with 9 gig and 18 gigK >> >> > disks in shadow sets. This system is supposed to be 4 times as fasthF >> >> > as our current one, but no one seems to be able to give me andJ >> >> > indication of how long it would take for a shadow set merge of the$ >> >> > 18 gig disks on this system. >> >>nH >> >> > Has any one had a real life experience of how long a merge wouldK >> >> > take. I am looking to get an indication as to whether it will be an_ >> >> > hour, hours, days??_ >> >>_H >> >> You have to pick the trade off of time vs kicking your system intoG >> >> the weeds. Faster the copies, more of a IO hit you take. The time J >> >> will depend on IO layout details. ( You don't have both disks on the >> >> one SCSI bus I hope? ) >> >>_K >> >> Also the controller type. Mylexs are limited in the IO count to about3. >> >> a couple of hundred IOs/sec from memory. >> >>u >> >> --B >> >> Paul Repacholi                               1 Crescent Rd.,= >> >> +61 (08) 9257-1001                           Kalamunda.pF >> >>                                              West Australia 60764 >> >> Raw, Cooked or Well-done, it's all half baked. >> > >> >--D >> >________________________________________________________________ >> >John JansenE >> >Group I.T ManagerA >> >Truck Investments Limitedi) >> >Phone - Work    (64 6) 356-7179 x 826D# >> >or direct Line  (64 6) 351-9826u# >> >Fax             (64 6) 356 5586o" >> >E-mail  JJansen@tilgroup.co.nzD >> >________________________________________________________________ >> > >> > >> >> Steven P. Underwood,DNRCs >> Whitinsville,MA >> StevenU@POBoxes.com >e >--iA >________________________________________________________________h >John Jansen >Group I.T Manager >Truck Investments Limited& >Phone - Work    (64 6) 356-7179 x 826  >or direct Line  (64 6) 351-9826  >Fax             (64 6) 356 5586 >E-mail  JJansen@tilgroup.co.nz A >________________________________________________________________c >i >i   Steven P. Underwood,DNRC Whitinsville,MAg StevenU@POBoxes.como   ------------------------------  % Date: Wed, 14 Mar 2001 21:46:40 -0600n7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>o7 Subject: Re: Volume Shadowing merge rates on Big Disks?t- Message-ID: <3AB03B20.DF2D8B4D@earthlink.net>    John Jansen wrote: >  > Hi,i > H > Currently we use a Alpha 4100/300 with 4 gig and 9 gig disks in shadow > sets.e* > A shadow merge can take over a full day.  G That's why we abandoned shadow-sets in favor of mirror-sets on a formero
 site of mine.R   --   David J. Dachtera_ dba DJE Systems_ http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/h  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.i   ------------------------------    Date: 15 Mar 2001 00:11:53 -0500+ From: young_r@encompasserve.org (Rob Young) 7 Subject: Re: Volume Shadowing merge rates on Big Disks?o3 Message-ID: <XCO7ur3qP1ez@eisner.encompasserve.org>n  g In article <3AB03B20.DF2D8B4D@earthlink.net>, "David J. Dachtera" <djesys.nospam@earthlink.net> writes:1 > John Jansen wrote: >>   >> Hi, >> lI >> Currently we use a Alpha 4100/300 with 4 gig and 9 gig disks in shadoww >> sets.+ >> A shadow merge can take over a full day.h > I > That's why we abandoned shadow-sets in favor of mirror-sets on a former_ > site of mine._ >   : 	Downsides to Volume Shadowing are a few.  Having a single= 	node and not a cluster and non-HSJ controllers (HSC, but why7= 	bother at that point?) , a node crash can be very painful as : 	a merge results.  However, if you are fortunate enough to> 	be with HSJ technology (and it meets your needs!) and several> 	members in a cluster, a node crash mostly will be a non-event> 	as the HSJs support shadow mini-merge and the merge literally9 	takes a few seconds as the HSJs have write history logs.f  D 	As we know, write history logging for shadow mini-merge are planned? 	for HSG80s.  Couple that with shadow mini-copy in OpenVMS 7.3:a  B http://www.openvms.compaq.com/openvms/roadmap/openvms_roadmaps.htm  A 	No disrespect to blind people... but if you have trouble reading C 	that above, you aren't going blind.  But see slide 3 for mini-copyR 	roadmap bullet.  @ 	Coupling that... it gives host based RAID a much greater leg upA 	on hardware based RAID for a couple reasons.  Maybe greatest oneiF 	is availability.  Hardware based RAID implies that the members resideB 	in the same cab sharing a controller pair.  They don't do well ifD 	someone pulls the power or pours water on them , etc.  Whereas withB 	fibre everywhere it wouldn't be much to stick one controller pair> 	in one building and another pair a few thousand feet away andF 	gain a great measure of availability for little cost.  Spend a littleC 	(or a lot) more and go up to 10K away (much further now, but let'so? 	not spend real big bucks) and gain an even greater measure of t 	availability.  D 	Now I am selling futures here somewhat and this isn't for everyone.@ 	Given you have a single node (and maybe no budget and inherited? 	a Volume Shadowing license) you may be doing the best you can,y 	and that is okay!!a   				Robc   ------------------------------  % Date: Wed, 14 Mar 2001 19:55:55 +0100S5 From: "GWDVMS::MOELLER" <moeller@gwdvms.dnet.gwdg.de>s6 Subject: Re: [INFO] ES40 EV67 is faster than its clock. Message-ID: <E14dGR9-0008Ue-00@gwdu42.gwdg.de>  . Didier Morandi <Didier.Morandi@GMX.CH> writes:  ' > Jan, tell me how to do that from DCL.h >  > D. >  > Jan Vorbrueggen wrote: > >oP > > Are you using the 64 bit time value? THen do what MAIL does: add one to thatR > > value until RMS doesn't choke anymore. Remember, there are 10^7 such units per
 > > second...    I can assure you thatH  E ftp.gwdg.de::"pub/vms/dnetdate.com"  		(cf. $ COPY/FTP/ANONYMOUS ...)   ; - *not* an MS-DOS executable - has always worked for me :-)2  M Wolfgang J. Moeller, Tel. +49 551 201-1516/-1510, moeller@gwdvms.dnet.gwdg.deeM GWDG, D-37077 Goettingen, F.R.Germany     |    Disclaimer: No claim intended!mM http://www.gwdg.de/~moeller/ ---- <moeller@gwdg.de> ---- <w.moeller@ieee.org>X   ------------------------------   Date: 14 MAR 2001 19:05:35 GMT+ From: Dave Greenwood <greenwoodde@ornl.gov> * Subject: Re: [Q] skip [vms$common] parsing2 Message-ID: <14MAR01.19053540@feda01.fed.ornl.gov>  - Didier Morandi <Didier.Morandi@gmx.ch> wrote:  > ISLKP1_dmo> def sy0 $1$DGA1: > ISLKP1_dmo> sh log sy0+ >    "SY0" = "$1$DGA1:" (LNM$PROCESS_TABLE)w" > ISLKP1_dmo> set def sy0:[000000]; > ISLKP1_dmo> dir sy0:[*...]/excl=[*.syscommon...]*.*;*/tot  > (many lines removed)3 > Directory $1$DGA1:[VMS$COMMON.VUE$LIBRARY.SYSTEM] $ > Total of 39 files, 168/720 blocks.1 > Directory $1$DGA1:[VMS$COMMON.VUE$LIBRARY.USER]   > Total of 1 file, 15/18 blocks.- > Directory $1$DGA1:[VMS$COMMON.XDPS$INCLUDE] $ > Total of 10 files, 183/306 blocks. >   F > Grand total of 254 directories, 10467 files, 5718485/5939370 blocks. >  a > ???d > D. >  U > "David J. Dachtera" wrote: > >  > > $ SHOW LOG SY0, > >    "SY0" = "$3$DKB0:" (LNM$JOB_81075E00)D > > $ SET DEF SY0:[000000] ! This makes valid the /EXCLUDE filespec.? > > $ dir sy0:[*...]/excl=[*.syscommon...]*.*;*/out=dirtest/tot6  < But I'll bet you didn't see any directories that looked like  ! $1$DGA1:[SYS0.SYSCOMMON.<mumble>]F  = and all you said was to eliminate files with names like that.O Change your command to  F   dir sy0:[*...]/excl=([*.syscommon...]*.*;*,[vms$common...]*.*;*)/tot   Dave --------------9 Dave Greenwood                Email: Greenwoodde@ORNL.GOVsH Oak Ridge National Lab        %STD-W-DISCLAIMER, I only speak for myself   ------------------------------   End of INFO-VAX 2001.147 ************************