1 INFO-VAX	Sat, 22 Dec 2001	Volume 2001 : Issue 709       Contents: Re: 100% FREE SPAM  2891 Re: 100% FREE SPAM  2891 Re: 100% FREE SPAM  2891 RE: A mouse friendly OpenVMSJ Re: Buffer Overflows - again Was: (Re: Congratulations for the festive seaJ Re: Buffer Overflows - again Was: (Re: Congratulations for the festive seaJ Re: Buffer Overflows - again Was: (Re: Congratulations for the festive seaJ Re: Buffer Overflows - again Was: (Re: Congratulations for the festive seaP Re: Buffer Overflows - again Was: (Re: Congratulations for the festive sea festiP Re: Buffer Overflows - again Was: (Re: Congratulations for the festive sea festi* Re: Buffer Overflows - different direction2 Re: Compaq still tries to spin Alphacide both ways2 Re: Compaq still tries to spin Alphacide both ways2 Re: Compaq still tries to spin Alphacide both ways2 Re: Compaq still tries to spin Alphacide both ways2 Re: Compaq still tries to spin Alphacide both ways2 Re: Compaq still tries to spin Alphacide both ways2 Re: Compaq still tries to spin Alphacide both ways* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season* Re: Congratulations for the festive season  Re: CXX and the Hobbyist license4 RE: DDS4 (20/40 GB) tape drives in a Alphaserver 8004 Re: DDS4 (20/40 GB) tape drives in a Alphaserver 8001 DECWindows weirdness - high interrupt stack usage 9 Re: Definition of timesharing (was: VMS missing features) 9 Re: Definition of timesharing (was: VMS missing features) > Re: Disaster Recovery Experts Recovering Disks From WTC Attack$ Re: Excitement -- and disappointment7 FBI warns Windoze XP unsecure - VMS now more than ever! 1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 1 RE: historical evidence of what went wrong at DEC 0 Re: HP admits it will kill VMS if merger suceeds0 Re: HP admits it will kill VMS if merger suceeds  Logging in on a Graphics console1 Re: MPE-Tru64 compromise?  VMS-HPux new platform?  OpenSSL version 0.9.6c released > Re: OT: FBI & Pentagon Quiz Microsoft Over Windows XP Problems> Re: OT: FBI & Pentagon Quiz Microsoft Over Windows XP Problems> Re: OT: FBI & Pentagon Quiz Microsoft Over Windows XP Problems; Re: PDP-10 architectural flaws? (was: VMS missing features) ; Re: PDP-10 architectural flaws? (was: VMS missing features) ; Re: PDP-10 architectural flaws? (was: VMS missing features) ; Re: PDP-10 architectural flaws? (was: VMS missing features) ; Re: PDP-10 architectural flaws? (was: VMS missing features) P Re: Proof!  I can secure UNIX faster than VMS! Was: Congratulations for the festG Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations G Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations P Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the P Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the P Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the P Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the P Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the P Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the  Re: QIOs, ASTs, and Event Flags  Re: QIOs, ASTs, and Event Flags  Re: QIOs, ASTs, and Event Flags  Re: QIOs, ASTs, and Event Flags  Re: QIOs, ASTs, and Event Flags  Re: Strange quorum disk problem 7 Re: VMS missing features (was how to do deamons on VMS) F Re: [anounce] Sanity Kit for Compaq C++ V6.5 for OpenVMS Alpha systems  F ----------------------------------------------------------------------  # Date: Sat, 22 Dec 2001 16:42:22 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>! Subject: Re: 100% FREE SPAM  2891 > Message-ID: <OJ2V7.25970$Sj1.12845934@typhoon.ne.mediaone.net>  0 As per SpamCop, abuse@casema.nl for followups...  % <evxsqn@hotmail.com> wrote in message . news:dF2V7.14961$TJ5.1410@castor.casema.net... > http://home.wanadoo.nl/cap/  > 100% FREE SEX MOVIES! ? > luibmgpqsmfiliudfrezdpljosxnrdwqoztomhkripyroknhyqloefqvzbhti  >    ------------------------------  % Date: Sat, 22 Dec 2001 18:16:49 +0100 1 From: John McLean <mcleanj@swissonline.delete.ch> ! Subject: Re: 100% FREE SPAM  2891 5 Message-ID: <3C24C001.5FBB70DC@swissonline.delete.ch>    "Terry C. Shannon" wrote:  > 2 > As per SpamCop, abuse@casema.nl for followups... > ' > <evxsqn@hotmail.com> wrote in message 0 > news:dF2V7.14961$TJ5.1410@castor.casema.net... > > http://home.wanadoo.nl/cap/  > > 100% FREE SEX MOVIES! A > > luibmgpqsmfiliudfrezdpljosxnrdwqoztomhkripyroknhyqloefqvzbhti  > >    Note theF "luibmgpqsmfiliudfrezdpljosxnrdwqoztomhkripyroknhyqloefqvzbhti".  ThatB has just has to be Welsh - the country that gave us the village of; Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.      John McLean    ------------------------------  # Date: Sat, 22 Dec 2001 17:27:22 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>! Subject: Re: 100% FREE SPAM  2891 > Message-ID: <_n3V7.26181$Sj1.12873411@typhoon.ne.mediaone.net>  > "John McLean" <mcleanj@swissonline.delete.ch> wrote in message/ news:3C24C001.5FBB70DC@swissonline.delete.ch...  >  >  > "Terry C. Shannon" wrote:  > > 4 > > As per SpamCop, abuse@casema.nl for followups... > > ) > > <evxsqn@hotmail.com> wrote in message 2 > > news:dF2V7.14961$TJ5.1410@castor.casema.net...! > > > http://home.wanadoo.nl/cap/  > > > 100% FREE SEX MOVIES! C > > > luibmgpqsmfiliudfrezdpljosxnrdwqoztomhkripyroknhyqloefqvzbhti  > > >  > 
 > Note theH > "luibmgpqsmfiliudfrezdpljosxnrdwqoztomhkripyroknhyqloefqvzbhti".  ThatD > has just has to be Welsh - the country that gave us the village of= > Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.  >   H I looked for this village on a map, but there ain't no map big enough to house the aforementioned name.  > Might there be a contraction or acronym for the official name?   ------------------------------  # Date: Sat, 22 Dec 2001 12:13:09 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) % Subject: RE: A mouse friendly OpenVMS 0 Message-ID: <00A06E40.930EAB24@SendSpamHere.ORG>   In article <35666012DF4CD411BE940090279FA240010BF194@ppnt41.physics.ox.ac.uk>, John Macallister <J.Macallister1@physics.ox.ac.uk> writes: M >> Ummm..  I am unfamiliar with any ability in Windows to cut&paste graphics.  > G >You can cut and paste from IE, Word, Excel, PowerPoint, ... into WORD, D >PowerPoint, Origin, etc just by using Leftclick -> Copy followed byK >Rightclick -> Paste. This works for any "well-behaved" Windows application  >which supports Graphics.   B This is always confusing to me in the "right-handed biases" world.  H I tried a left-click and then a right-click from word to word and it did= nothing.  I event restored the mouse to being "right-handed".    --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              J   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes    ------------------------------  # Date: Sat, 22 Dec 2001 12:36:04 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) S Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the festive sea 0 Message-ID: <00A06E43.C678B19F@SendSpamHere.ORG>  a In article <hO42RwhQI2bm@eisner.encompasserve.org>, young_r@encompasserve.org (Rob Young) writes:  >In article <Pine.NXT.4.50.0112210740180.6674-100000@Tomobiki-Cho.CAC.Washington.EDU>, Mark Crispin <mrc@CAC.Washington.EDU> writes:. >> On Fri, 21 Dec 2001, John J Francini wrote:J >>> Hence, buffer overflows and other nastiness.  This philosophy is by NOO >>> MEANS restricted to Unix; it is very much evident in Microsoft-written OSes M >>> and applications (like Exchange, IIS, and many others), as well as plenty  >>> of other products. >>  K >> Including VMS.  The reason why there aren't many buffer overflow attacks K >> on VMS is that the target is uncommon and uninteresting to the bad guys. - >> It's a form of security through obscurity.  >>   >	@ >	This is a myth or legend.  Bart Z. Lederman succinctly refuted. >	such a myth recently.  Here is what he said:  K If you pulled this from deja, two responses later I countered with a little C demonstration of the invalid assumptions made in Bart's statements.    --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              J   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes    ------------------------------  # Date: Sat, 22 Dec 2001 12:38:21 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) S Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the festive sea 0 Message-ID: <00A06E44.1820CE35@SendSpamHere.ORG>  a In article <gIw7WGLS6HWI@eisner.encompasserve.org>, young_r@encompasserve.org (Rob Young) writes: [ >In article <9vvt7m$hu2@weyl.math.psu.edu>, viro@weyl.math.psu.edu (Alexander Viro) writes: 6 >> In article <hO42RwhQI2bm@eisner.encompasserve.org>,0 >> Rob Young <young_r@encompasserve.org> quoted: >>  N >>>I would be a bit surprised if you could exploit this type of a hole on VMS,P >>>particularly on Alpha.  Programs are divided into code and data segments, andP >>>you can't execute something in a data segment.  This is moderatly enforced on >>  Q >> ... so instead of return into data buffer you do return into library function. L >> Non-executable data segment does _not_ stop buffer overrun attacks.  ThatK >> had been demonstrated again and again - exploits are slightly different,  >> but not noticably harder. >>  O >> IOW, instead of putting your code into buffer and overwriting return address I >> with address of the buffer you overwrite the return address with entry I >> point of library function and create a fake stack frame so that return C >> would enter that function with arguments of your choice.  BFD...  >>   > # >	Tell us what you mean by example.  > E >	It sounds like you are trying to insert your own code somewhere and H >	run it.  That is how I am interpreting this:  "instead of putting yourC >	code into buffer".  This code you would attempt to run or exploit D >	has to be written somewhere.  If you write it in a data PSECT, youA >	can't run it.  If you attempt to write it in a code section, it H >	won't let you.  Hence "buffer overflow" exploits are nearly impossible >	on Alpha VMS.   I http://groups.google.com/groups?hl=en&threadm=9i1dum%24m8l%241%40venus. - I telepac.pt&rnum=1&prev=/groups%3Fq%3Dexploitable%2Bbuffer%2Boverflows%2 - B Bin%2BVMS%2Bpossible%253F%26hl%3Den%26meta%3Dgroup%253Dcomp.os.vms   > E >	Are you attempting to exploit (buffer overflow) an existing program ' >	on VMS?  Go from theory to example...  >  >				Rob >  --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              J   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes    ------------------------------    Date: 22 Dec 2001 06:55:31 -0800( From: bob@instantwhip.com (Bob Ceculski)S Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the festive sea = Message-ID: <d7791aa1.0112220655.139bb111@posting.google.com>    Mark Crispin <mrc@CAC.Washington.EDU> wrote in message news:<Pine.NXT.4.50.0112211759180.7301-100000@Tomobiki-Cho.CAC.Washington.EDU>...% > On 21 Dec 2001, Bob Ceculski wrote: Q > > are you saying you can overflow buffers on vms and create privs you never had N > > to begin with?  this isn't windoze you know, you need privs to do anything > > on vms ... > L > It may surprise you, but NT has privileges just like VMS.  Perhaps you are> > too young to know about the relationship between VMS and NT. > I > I won't clue you in on that point (you'll have to find that out on your K > own), but I will clue you in on how security gets broken.  It has nothing E > to do with a user task getting corrupted by something like a buffer  > overflow.  > J > It has everything to do with a privileged task being subverted to do theK > bad guy's bidding.  One of many ways is to cause a buffer overflow in the K > privileged task.  Another way is to identify a flaw in the means by which H > a privileged task determines the authorization of a user request.  YetJ > another is to hide an unauthorized payload inside an authorized request. > I > I'm only scratching the surface here, but you should be able to get the  > gist.  >  > -- Mark -- > ! > http://staff.washington.edu/mrc H > Science does not emerge from voting, party politics, or public debate.  M I know all about Dave Cutler and the stolen Dec West Mica code that was found M in NT, but it still didn't turn NT into VMS, did it?  As for hacking, I don't L think there are many program holes in VMS ... 3 cert advisories in 10 years,N while no one yet has found a way to run dcl coms thru vmsmail, though they areK still trying ... by the way, when are you going to give us a decent version N of pine for vms?  And one that you can run as a foreign command?  I would likeM to have a program send mail w/html attachment and don't want to go to vms 7.2 L to do it, but the 3.91 version of pine will not run like vmsmail where I can say          $ mail sample.html fred ; whoever was supporting pine on vms has not been keeping up!    ------------------------------    Date: 22 Dec 2001 11:55:46 -0600+ From: young_r@encompasserve.org (Rob Young) S Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the festive sea 3 Message-ID: <OmnLr8Cgbkdi@eisner.encompasserve.org>   p In article <00A06E43.C678B19F@SendSpamHere.ORG>, system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes:c > In article <hO42RwhQI2bm@eisner.encompasserve.org>, young_r@encompasserve.org (Rob Young) writes:  >>In article <Pine.NXT.4.50.0112210740180.6674-100000@Tomobiki-Cho.CAC.Washington.EDU>, Mark Crispin <mrc@CAC.Washington.EDU> writes: / >>> On Fri, 21 Dec 2001, John J Francini wrote: K >>>> Hence, buffer overflows and other nastiness.  This philosophy is by NO P >>>> MEANS restricted to Unix; it is very much evident in Microsoft-written OSesN >>>> and applications (like Exchange, IIS, and many others), as well as plenty >>>> of other products.  >>> L >>> Including VMS.  The reason why there aren't many buffer overflow attacksL >>> on VMS is that the target is uncommon and uninteresting to the bad guys.. >>> It's a form of security through obscurity. >>>  >>	 A >>	This is a myth or legend.  Bart Z. Lederman succinctly refuted / >>	such a myth recently.  Here is what he said:  > M > If you pulled this from deja, two responses later I countered with a little E > demonstration of the invalid assumptions made in Bart's statements.  >   @ 	Yeah, I remember that.  Proof by counter example.  You went andB 	ruined half the fun.  The other half of course is that only folksE 	with APE certification know about such things and how to hack things  	up like that.   				Rob    > --Q > VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM 
 >                ------------------------------  ! Date: Sat, 22 Dec 01 10:16:22 GMT  From: jmfbahciv@aol.com Y Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the festive sea festi + Message-ID: <a01tsc$sbe$1@bob.news.rcn.net>    In article  J <Pine.NXT.4.50.0112211312160.6883-100000@Tomobiki-Cho.CAC.Washington.EDU>,/    Mark Crispin <mrc@CAC.Washington.EDU> wrote:e) >On Fri, 21 Dec 2001, Hoff Hoffman wrote:EJ >>   No myth.  No legend.  OpenVMS can potentially be and has occasionallyH >>   actually been found to be vulnerable to security problems resulting/ >>   from buffer overrun errors.  This is fact.s >r >So far, so good.e >uK >>   If you believe you have encountered a security problem, please contactfH >>   a Compaq representative directly.  In deference to the security of  othereE >>   OpenVMS users, please do not post security problem reports here.  >fJ >This should be a call to arms to post those problems.  After all, that isK >what UNIX and Windows users have been suffering for years.  Why should VMSa >users be treated specially?; So far, VMS takes security problems seriously.  Posting thet: security flaws BEFORE giving them a chance to stop them is: foolish, stupid, and impertinent.  I have no problems with< posting such things IF, AND ONLY IF, the distributor doesn't+ give a shit...as we've just seen in MIsoft.t   /BAH  ' Subtract a hundred and four for e-mail.    ------------------------------  % Date: Sat, 22 Dec 2001 10:10:39 -0800t+ From: Mark Crispin <mrc@CAC.Washington.EDU>vY Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the festive sea festieU Message-ID: <Pine.NXT.4.50.0112221004440.7962-100000@Tomobiki-Cho.CAC.Washington.EDU>e  # On 22 Dec 2001, Bob Ceculski wrote:v< > by the way, when are you going to give us a decent version > of pine for vms?  B Never.  There is no funding for development work on dead operatingJ systems.  I make sure that the c-client library continues to build on VMS,> and that mtest will establish an IMAP connection.  That's all.  F We didn't do the VMS port of Pine.  I know that a school in Israel didJ one, but they are probably no longer using VMS since we haven't heard fromI them in ages.  There was also a company did one, but it no longer exists.n  H Now, if you'd like to pay me to do it, we can talk.  My consulting ratesJ start at $10,000/week.  Prices higher for clients in California, New York, Massachusetts, and DC.  
 -- Mark --   http://staff.washington.edu/mrc F Science does not emerge from voting, party politics, or public debate.   ------------------------------  # Date: Sat, 22 Dec 2001 15:25:22 GMTs' From: bad bob <sfmc68@bellatlantic.net>t3 Subject: Re: Buffer Overflows - different directionr0 Message-ID: <3C24A759.30E69904@bellatlantic.net>  E I have searched this set of NG data on this thread and find no ref toSE E-eye.  E-eye seems to have exceptional skills at finding BO (buffer oC overflow) exploits in MS products.  Rumor has it that they have an eC special tool suite that is rather effective.  E-eye seems to be then! source of the latest angst on XP.b  C I do not recall e-eye really looking at VMS or Tops or MVS or VM oreG VSE or PRIMOS. Might just be a business reason for that but it would beaA quite interesting to have some commercial or public team do a bite of testing.... bobM   ------------------------------  # Date: Sat, 22 Dec 2001 08:47:11 GMTe* From: "Bill Todd" <billtodd@metrocast.net>; Subject: Re: Compaq still tries to spin Alphacide both waysw> Message-ID: <jMXU7.251811$YD.19710176@news2.aus1.giganews.com>  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message+ news:v0IU7.318$sK3.5185@news.cpqcorp.net...i   ...e  " > Good lord, more swill from Bill.  J If you don't like swill, stop working for (and vigorously defending) pigs.   ...   H > The truth is that the day that the decision was announced, I heard the: > initial version of what Bill calls the "ammended" story.  H Good for you.  The rest of the world didn't:  they heard first that 'theD Alpha engineers themselves' came up with the idea that maintaining aC performance lead would be a problem, and the obvious intent of that K statement was to suggest that it was the engineers responsible for creating K said performance, rather than some other group of engineers responsible for G putting it to use, who had done so.  Only after the EV8 team vigorouslyI7 disputed this assertion was the public version changed.e  H By the way, I didn't call it the "ammended" story:  I know how to spell.     And within days, IH > heard the story directly from the horses mouth.  I did not feel that I could-I > "replay" this story in public, since it wasn't told to us in a way thatr* > indicated that it should be made public. >jI > Chip builders design chips, system designers design systems.  They botho wantK > to make the best product they can provide.  They both believe strongly inoF > what they are doing.  Just like people working on VMS believe in ourF > product.  Could the EV8 design have been the best thing since sliced bread?H > Probably.  Just like EV6 was, and just like EV7 will be.  But business isn't-L > always just about being the best - or Betamax would have won the VCR wars.  D There's no shame in losing a war because you got out-maneuvered by aL resourceful enemy.  That's a lot different from not even showing up to fightH after having urged your customers to commit to your product for the long3 term because *you* were absolutely committed to it.t   - bill   ------------------------------   Date: 22 Dec 2001 18:28:57 GMT0 From: Dave Cherkus <cherkus777@777unimaster.com>; Subject: Re: Compaq still tries to spin Alphacide both waysl2 Message-ID: <Xns917F88CA63AFEidtoken@199.125.85.9>  , nmm1@cus.cam.ac.uk (Nick Maclaren) wrote in ( news:9vvjf9$3u2$1@pegasus.csx.cam.ac.uk:- >|> nmm1@cus.cam.ac.uk (Nick Maclaren) writesLG >|> > Note that by "the EVx" I am also referring to chipsets and so on, H >|> > without which the chip is useless and cannot support faster clock E >|> > speeds even on the same chip - witness the 1 GHz Alpha and ES45m >|> > shambles. C > The DS10/DS20/ES40 boards were already inadequate for the 667 MHz2F > Alphas, both because of memory bandwidth and because of their 33 MHzB > PCI bus.  The latter was particularly painful for HPC customers,A > because they could get a faster network (Quadrics) but the damn9 > boards wouldn't drive it!.  I I think some of these points are pretty important and not being heard in u this thread.  G I've thought all along a big reason it was easy for CPQ to toss in the lJ towel on Alpha was it would releave them of the burden of not just having I to keep up with competing CPUs, but the burden of having to keep up with wC all the related technologies, such as memory and IO technologies.  r  J The evidence shows they're having a hard time doing this with the current L generation (see Nick's points above, and also consider the IO technology in G the first-generation Wildfires, etc) and continuing to do so across at ML least three different hardware design points (desktop/small server with 1-2 G CPUs, departmental server with 4-8 CPUs, enterprise server with 32-128 .@ CPUs) is incredibly expensive in terms of software and hardware - development, testing, deployment and support.i  J And the decision was being made during the dot.com boom, and I personally J know CPQ was having a hard time retaining employees, so there was lots of L concern around having enough of the right kind of talent needed to keep the L Alpha platform viable long term.  Now the world has changed in that regard, ( but it's hard to reverse time, isn't it?  F By going to Itanium, you can just use Intel reference designs and CPQ I Wintel products for the bottom two tiers of hardware, and concentrate on  J coming up with a box with competitive differentiation for the high-margin K enterprise market. It's pretty clear Intel has been pretty good at getting (I best-in-class memory and IO technology into their products in the bottom aJ two tiers.  It's also clear that the folks calling the shots at CPQ think J they can come up with best-in-class products in the enterprise class.  Of K course, that's open to some debate, which is what we all like about USENET.X  K I thought that strategy was solid right up till the CPQ/HP merger fiasco.   L Now it looks like all the UNIX business is fleeing, and I wonder if there's H enough VMS business left to keep this business model afloat.  But, then ? again, if the world is still supporting the continuance of the 06 Burroughs/Sperry/Univac product lines, it can be done.   ------------------------------  % Date: Sat, 22 Dec 2001 13:33:01 -0500>5 From: "Robert R Kircher, Jr." <rrkircher@hotmail.com>i; Subject: Re: Compaq still tries to spin Alphacide both waysc+ Message-ID: <a02jku$dr3$1@bob.news.rcn.net>   H The Alpha chips fate was sealed the moment Digital was bought by Compaq.   Robr    5 "Bill Todd" <billtodd@metrocast.net> wrote in messager: news:H1tU7.68658$Zd.6364033@bin1.nnrp.aus1.giganews.com...I > Despite Compaq's public declarations of Alpha's inability to maintain auD > significant performance lead over The Good Ship Itanic, some pesky	 customers F > still aren't convinced about the desirability of the migration.  But CompaqK > has a story for them as well, just not a consistent one:  Itanic may be atH > pig, but the Alpha team will miraculously transform it into a pig with flies % > (er, sorry, a pig *that* flies...).V >aH > Kerry Main floated this rationale the day of the announcement and MarkJ > Gorham tried to feed it to Alphaman a few days later, but it then seemed toH > disappear (I'd like to think in some small part because I spread it toG > comp.arch and comp.sys.intel and Intel was not amused - perhaps HP ash well).L > But it's alive and well out in preferred-customer-persuasion land, as thisJ > email I answered yesterday demonstrates.  JF may be right:  Compaq isn'tH > much interested in new Alpha system business or in many small existingJ > customers, but cares enough about a few important current clients to say< > whatever it takes to keep them on board the sinking liner. >hD > Anyway, you can be a fly on the wall listening in on our (slightlyL > expurgated, to remove identity clues and one private piece of information)+ > conversation, and conclude what you will:a >P >r > > Hi Bill, > >o? > > ... I told our Compaq account manager in no uncertain terms K > > how I thought about the infamous Itanic move. Of course he replied thatrK > > everyone else was very happy etc. (specially management guys), and thataL > > we were the only ones unhappy. That wasn't true of course, but hey he is > > a sales person.- > >oJ > > But he was very quick to act, and today we had another guy who told usJ > > what is actually the case, and how it all came to this. He is a former4 > > DEC support guy, and he was refreshingly honest. >sK > He may have believed what he said (a lot of people at Compaq seem to havehI > swallowed the party line as gospel), but the information he imparted isDI > dramatically inconsistent with the information I have received from EV8yJ > developers now at Intel - and on the subject at hand, I know whom I find > more credible. >i > >iJ > > I told him again my vision on the Itanic (didn't differ very much fromI > > your vision with regard to the technical side of things) and he could  > > understand it very well. > > E > > But then he gave us some more information about the whole matter.f > >vK > > First of all he said that the whole marketing presentation of this movegJ > > was done in good old Digital fashion, as stupid as it can be. As if we > > didn't know. :-))o > >eH > > What happened was that the EV8 development team went to Capellas andJ > > said that without a lot more funding it would be impossible to keep up= > > with the X86 class of processors (and possibly Itanium ?)  > J > I very much doubt that any such mission to Capellas occurred - it soundsK > much more like the spin Compaq tried to palm off as part of the June 25thoL > announcement that the decision had started with the Alpha engineers.  TheyK > later amended this to saying that it originated with some of the *server* J > (not processor) designers - and there's an interesting political tensionI > between the two groups involving the migration of much of what had beene% > server 'turf' onto the chip in EV7.9 >1K > There was *no question whatsoever* in the minds of the EV8 team that theyaJ > would extend, not simply maintain, Alpha's current performance advantage > over Itanic. >eI > Keeping ahead of IA32 processors would have been more difficult but farn fromL > impossible, at least for Intel variants (Hammer might be harder to match):L > EV7's on-chip memory control (with its dramatically improved bandwidth andL > latency) will hit the streets next year with nothing similar from Intel onI > any road map (32-bit *or* 64-bit), and while Intel will debut 2-way SMTo soonJ > in IA32 (again, nothing on any road map for IA64) EV8's 4-way SMT shouldL > have been a more than adequate response.  And in any event IA32 just isn't= > (and shows no sign of becoming) much of a threat to Alpha'se bread-and-butter
 > markets. >a	 >  We arebL > > speaking here in terms of raw processor speed of course, not the qualityH > > of the OS. Of course the intellectual capacity is there, but not the > > funding. >cA > The funding *was* there, until June 25th, to continue the Alphae performancenE > road map that has been public for years and showed no sign of being I > inadequate (or unduly expensive).  Again, I'm reasonably sure that yourhB > informant was feeding you misinformation, though not necessarily
 knowingly. >oB >  And indeed, the performance of the fastest X86 class processorsK > > at the moment is about the same as that of the fastest present Alpha's.nJ > > Only now we have 1 GHz Alpha's, I had expected them at least 1.5 yearsC > > earlier. Development is slowing down, and so is the performance1 > > advantage of the Alpha.s >uK > If IA32 were truly Alpha's competition, that argument might have at leasthI > some merit.  But if a 32-bit architecture were considered sufficient inn thatF > market, there would have been absolutely no reason for Intel to haveL > developed a 64-bit machine that shows no evidence that it will *ever* comeJ > even close to catching up with IA32 on simple speed benchmarks (with theL > possible exception of FP-style code, which is not the main source of Alpha
 > income). >- > >-K > > It was the EV8 development team who suggested joining forces with Intelp > > to design a new processor. >RK > No, it was not.  I don't know how tightly-knit the European DEC communityeJ > is, but if you know <name deleted> I think he may have additional insideE > information from a source that I don't (he's another person who wasrI > initially fed a load of crap but then discovered what it was from othero > sources he trusted). >b, >  This processor is now known in the CompaqK > > presentations as the Itanium 2, and apparently it has almost nothing in@> > > common with the present Itanium, but instead is EV8 based. >iL > More bullshit, I'm afraid.  This is another lie that Compaq tried to floatD > to make the decision easier to swallow, but it doesn't stand up toB > examination (nor, incidentally, do I believe you will find *any*
 indicationI > from *Intel* that this is what's planned - so Compaq is asking for your K > trust - hah! - while ignoring the signals from the architecture's owner).t >tF > First of all, *if* Compaq recognized that Itanic was the disaster it appears I > to be and that Alpha technology would remain far superior, why on earthmL > wouldn't they have vigorously capitalized on this asset rather than handedH > it over to Intel supposedly so that Intel could rescue Itanic with it?H > After all, if Itanic *wasn't* destined to change the 64-bit landscape, thenH > Alpha would have remained as competitive (with any marketing) as ever, with: > increased leadership clearly visible in the near future. > I > Second, I've received private confirmation from one of the transplantedtE > Alpha designers that my guesstimate of 2006 as the earliest such anAG > Alphabetized Itanic could appear is a good one, which puts it about 3- years-J > behind the date when the same technology would have appeared in EV8.  SoL > *even after having given the technology away* Compaq will now have to wait 3tL > more years to make use of it than would have been the case if EV8 had goneK > ahead, while POWER4 reaps the rewards of lack of any high-end competitioniH > and Hammer may start grabbing large chunks of the mid-range-to-low-end	 > market.N >yJ > Whatever Itanic will come after Madison is far more likely to be an EPICL > architecture with Alpha-inspired tweaks than an Alpha architecture running > the Itanic instruction set.t >  >  TheH > > instruction set will be different of course, but as I understand the2 > > overall design will be very much like the EV8. >rH > One of Alpha's strengths was its instruction set, which was explicitlyI > designed to allow performance enhancements.  The design behind Itanic'stL > instruction set was based on completely different (EPIC) assumptions whichK > are less amenable to using Alpha-style performance approaches even if thel* > entire EPIC implementation is abandoned. >l >  Why they still use thefG > > infamous name Itanium for that new processor is unclear, but we allp4 > > agreed that this again is very stupid marketing. > > D > > The Alpha technology has not been sold to Intel, but it has beenK > > licensed. The Itanium 2 / EV8 team hasn't moved, but are still at their-K > > own desks at Compaq. The only difference is they have Intel badges now.i9 > > But what's in a badge as Shakespeare might have said.w > J > It's not the badge, its the architecture.  Alpha is an eagle, and Itanic isI > a pig.  Compaq has just given Intel the means to streamline the pig and  put0I > wings on it, but in the end it's still a pig:  all instruction sets areeH > *not* created equal (just look at IA32 for a cautionary example of how much3 > more effort it takes to make a poor one perform).c >i > >iK > > So in essence your vision on the Itanium (1) is right, it is a piece ofcF > > shit Compaq agrees. In fact Dell has stopped selling Itanium based/ > > systems as I read in a newspaper over here.n > >g= > > Compaq however has so much confidence in the Itanium 2...w > > (Don't publish this please, , > > don't know if this is official already). >eK > It sounds like the so-called 'golden blanket', and given that even if thehJ > mythical Itanium 2 does appear it won't be before 2006 this is just moreF > smoke being blown to try to make an indefensible position palatable. >nL > It is possible that some of the on-chip memory and multi-processor supportK > could be grafted onto the McKinley/Madison core by 2005, and there's someuF > indication that this may be what you are referring to as 'Itanium 2' (i.e.,L > a processor core with absolutely no Alpha technology in it, and hence justH > as much a pig as McKinley/Madison will be).  And while Compaq has beenI > promoting the fiction that it might appear in 2004, again this does noth seemG > to be consistent with private information from the transplanted Alpha  team.o >h > >eI > > It seems that at the Los Angeles presentation there were several veryMI > > important customers that were very unhappy with the way Capellas etc.tD > > answered their questions. Only after these customers talked withJ > > technical staff they were satisfied that the Itanium move was ok. That8 > > again proves how poor the marketing is in this case. >r- > No, it just proves how gullible people are.s >  > >cF > > Compaq ... is visiting all important customers now to explain themI > > what is happening. And sure enough there were other customers too who H > > were planning to leave Compaq because of the Itanium move. But after7 > > this guy paid them a visit they changed their mind.  >  > See above. >e  > > ...  It seems to be sure nowG > > that HP UX and Tru64 will be merged to one Unix, even if the mergeraL > > doesn't go ahead. The best of both (in Unix ?? :-)  ) will be in the new	 > > Unix.d >dC > Except that it will be big-endian, so even if the amalgamation is 	 performedeK > perfectly the little-endian Tru64 people will be faced with a non-trivialtD > port.  Not to mention that the HP/UX kernel is a large, antiquated	 monolith,c. > which bodes poorly for its long-term future. >g9 > > So maybe things are not as gloomy as I (we?) thought.h >d > J > Yeah.  Right.  Thus concludes another small chapter in Compaq's on-goingL > soap opera.  If you know people who, for some reason, are still willing toL > trust Compaq's "This time for sure!" promises, you might want to give them a K > heads-up about this particular offensive (and 'offensive' certainly seems,I > the proper term):  even Bullwinkle eventually realized that he needed aa newb > hat. >  > - bill >  >i >c   ------------------------------  # Date: Sat, 22 Dec 2001 18:31:11 GMTe4 From: "Terry C. Shannon" <terryshannon@mediaone.net>; Subject: Re: Compaq still tries to spin Alphacide both waysM> Message-ID: <Pj4V7.26464$Sj1.12910678@typhoon.ne.mediaone.net>  = "Dave Cherkus" <cherkus777@777unimaster.com> wrote in message , news:Xns917F88CA63AFEidtoken@199.125.85.9...- > nmm1@cus.cam.ac.uk (Nick Maclaren) wrote ina* > news:9vvjf9$3u2$1@pegasus.csx.cam.ac.uk:/ > >|> nmm1@cus.cam.ac.uk (Nick Maclaren) writesuI > >|> > Note that by "the EVx" I am also referring to chipsets and so on,gI > >|> > without which the chip is useless and cannot support faster clockoG > >|> > speeds even on the same chip - witness the 1 GHz Alpha and ES45l > >|> > shambles.-E > > The DS10/DS20/ES40 boards were already inadequate for the 667 MHzhH > > Alphas, both because of memory bandwidth and because of their 33 MHzD > > PCI bus.  The latter was particularly painful for HPC customers,C > > because they could get a faster network (Quadrics) but the damnu > > boards wouldn't drive it!c >aJ > I think some of these points are pretty important and not being heard in > this thread. >sH > I've thought all along a big reason it was easy for CPQ to toss in theK > towel on Alpha was it would releave them of the burden of not just havingmJ > to keep up with competing CPUs, but the burden of having to keep up withC > all the related technologies, such as memory and IO technologies.o >hK > The evidence shows they're having a hard time doing this with the current,J > generation (see Nick's points above, and also consider the IO technology inH > the first-generation Wildfires, etc) and continuing to do so across atI > least three different hardware design points (desktop/small server with  1-2sH > CPUs, departmental server with 4-8 CPUs, enterprise server with 32-128A > CPUs) is incredibly expensive in terms of software and hardwareu/ > development, testing, deployment and support.  >aK > And the decision was being made during the dot.com boom, and I personallysK > know CPQ was having a hard time retaining employees, so there was lots ofkI > concern around having enough of the right kind of talent needed to keepi thelE > Alpha platform viable long term.  Now the world has changed in that  regard,d* > but it's hard to reverse time, isn't it? >PG > By going to Itanium, you can just use Intel reference designs and CPQPJ > Wintel products for the bottom two tiers of hardware, and concentrate onK > coming up with a box with competitive differentiation for the high-margintL > enterprise market. It's pretty clear Intel has been pretty good at gettingJ > best-in-class memory and IO technology into their products in the bottomK > two tiers.  It's also clear that the folks calling the shots at CPQ think K > they can come up with best-in-class products in the enterprise class.  Of E > course, that's open to some debate, which is what we all like about  USENET.p >uK > I thought that strategy was solid right up till the CPQ/HP merger fiasco.h  J Looked to me like it might fly as well. Better than staying the course andJ spending more and more selling less and less until everything was spent on selling nothing.  E > Now it looks like all the UNIX business is fleeing, and I wonder ifh there'slI > enough VMS business left to keep this business model afloat.  But, thend@ > again, if the world is still supporting the continuance of the8 > Burroughs/Sperry/Univac product lines, it can be done.  J Well, Unisys at least did some marketing. As a CPQ stockholder I am not atK amused by the ROI Compaq gets for the >$250M a year it spends on all thingsV marketing-related.   ------------------------------  # Date: Sat, 22 Dec 2001 18:34:32 GMTl4 From: "Terry C. Shannon" <terryshannon@mediaone.net>; Subject: Re: Compaq still tries to spin Alphacide both ways-> Message-ID: <Ym4V7.26477$Sj1.12912646@typhoon.ne.mediaone.net>  @ "Robert R Kircher, Jr." <rrkircher@hotmail.com> wrote in message% news:a02jku$dr3$1@bob.news.rcn.net... J > The Alpha chips fate was sealed the moment Digital was bought by Compaq. >  > Robe   In hindsight, absolutely.a   ------------------------------  % Date: Sat, 22 Dec 2001 13:51:47 -0500s5 From: "Robert R Kircher, Jr." <rrkircher@hotmail.com> ; Subject: Re: Compaq still tries to spin Alphacide both wayso+ Message-ID: <a02ko4$hfp$1@bob.news.rcn.net>o  ? "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messagen8 news:Ym4V7.26477$Sj1.12912646@typhoon.ne.mediaone.net... > B > "Robert R Kircher, Jr." <rrkircher@hotmail.com> wrote in message' > news:a02jku$dr3$1@bob.news.rcn.net...mL > > The Alpha chips fate was sealed the moment Digital was bought by Compaq. > >. > > Rob  >e > In hindsight, absolutely.l >h  H I used to work with a company that was a dgital partner up until the buyI out.  We where told by our rep that the alpha didn't stand a chance.  MayoJ have been his opinion at the time but I still think the writing was on the wall.n   Robe   ------------------------------  # Date: Sat, 22 Dec 2001 18:55:37 GMTs4 From: "Terry C. Shannon" <terryshannon@mediaone.net>; Subject: Re: Compaq still tries to spin Alphacide both waysi> Message-ID: <JG4V7.26540$Sj1.12923662@typhoon.ne.mediaone.net>  @ "Robert R Kircher, Jr." <rrkircher@hotmail.com> wrote in message% news:a02ko4$hfp$1@bob.news.rcn.net...hA > "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messageh: > news:Ym4V7.26477$Sj1.12912646@typhoon.ne.mediaone.net... > >nD > > "Robert R Kircher, Jr." <rrkircher@hotmail.com> wrote in message) > > news:a02jku$dr3$1@bob.news.rcn.net...lF > > > The Alpha chips fate was sealed the moment Digital was bought by Compaq.o > > >u	 > > > Robh > >a > > In hindsight, absolutely.r > >d >aJ > I used to work with a company that was a dgital partner up until the buyK > out.  We where told by our rep that the alpha didn't stand a chance.  MayhL > have been his opinion at the time but I still think the writing was on the > wall.o  E Well, it was definitely WRIT LARGE by the time August 19, 1999 rolledtG around. A shame that the Sculptor project was killed. That IMHO was thes final nail in the coffin.v   ------------------------------  # Date: Sat, 22 Dec 2001 04:23:02 GMT 2 From: Arthur Krewat <krewat@bartek.dontspamme.net>3 Subject: Re: Congratulations for the festive seasoni5 Message-ID: <3C2409FA.EEA6A58D@bartek.dontspamme.net>    Bob Ceculski wrote:  > d > peter@taronga.com (Peter da Silva) wrote in message news:<9vvs1t$13r9$1@citadel.in.taronga.com>...R > > >But then, it takes ten seconds to start a shell with everything on my current1 > > >Solaris box also, so where's the difference?  > >uN > > If it takes 10 seconds to start a shell on your Solaris box, you're eitherK > > trying to run Solaris 8 on a Sparcstation I with 16M RAM and a 3600 RPM K > > drive to swap into, or you have a boatload of crap in your rc file thattM > > should only be run on login (if that). I have an AT&T 3b1 with 2M of RAM, L > > a 12 MHz 68010 CPU, and a 40M MFM hard disk (ie, something somewhat lessN > > powerful than a typical 11/750: it doesn't even support demand paging) andH > > it starts a new shell fast enough that it's basically instantaneous. > I > no, she is probably running a 512 cpu sparcserver that still can't beat $ > a single processor Alphaserver ...  & Now I know you're smoking something...   aakm   ------------------------------  # Date: Sat, 22 Dec 2001 04:18:05 GMTt2 From: Arthur Krewat <krewat@bartek.dontspamme.net>3 Subject: Re: Congratulations for the festive seasont5 Message-ID: <3C2408DE.50FEEB82@bartek.dontspamme.net>    Bob Ceculski wrote:  > ) > I have been on VMS for 16 years now and  > have never had an OS crash!   F Me too - and I've seen more VMS crashes than I can count. 5.x liked toI reboot itself when the cluster quorum changed. 6.0 liked to reboot itselfmH too. (for the life of me, I can't recall what VMS called a panic) I haveH yet to get my 7.2 VS3100 to do it, but I haven't had it turned on in the last year...  0 > Can you say that about your unix (gag!) boxes?Q > Want to have a clustering contest?  For disaster recovery, unix would be toast!t" > VMS withstood the 9/11 disaster!  I In what way? Having a VMS cluster on the 100th floor of one of the towersM' when it came down? I don't understand. e  0 > What happened to unix?  The last I heard, onlyM > VMS clusters withstood the test ... are the defcon9 people idiots?  Did theaN > worlds top hacker lie to congress a few years ago when he testified that theR > White House mail system ran on VMS (All-in-1) and that was one OS he could never > hack into?    K Must have been an amateur - I hacked VMS between '81 and '85 for fun. Can'teL remember all the university computers I was into - even places like nationalG research labs (I won't name the place). Defense computers? even easier.   ? >Unix is hack city!  It is a VMS wanna be written by a bunch ofnO > people who want something for nothing!  Windows NT is in the same boat!  DavesP > Cutler failed to turn VMS into NT with the Dec West Mica project code!  VMS is3 > the best!  Use it or lose it (your hair that is)!x   You're delusions are showing :)    aak.   ------------------------------  # Date: Sat, 22 Dec 2001 04:38:02 GMTf2 From: Arthur Krewat <krewat@bartek.dontspamme.net>3 Subject: Re: Congratulations for the festive seasonr5 Message-ID: <3C240D29.C7F79AA2@bartek.dontspamme.net>c   Eric Smith wrote:k > 6 > Arthur Krewat <krewat@bartek.dontspamme.net> writes:J > > In some cases I have purposely removed the finger guard and still haveK > > all 10 fingers. I'm not stupid enough to put my fingers near the blade.h > H > That's exactly my point.  If you sell table saws with no finger guardsI > to experts, they *usually* won't cut their fingers off.  It will happeneI > occasionally.  If you sell them to the vast unwashed masses, it's goingwF > to happen frequently.  So a vendor selling table saws with no fingerI > guards is considered to be somewhat irresponsible, even though it's then# > end user that is really at fault.(  I I don't accept the fact that programmers can be "unwashed masses". PeoplerI playing with their Excel spreadsheets? Yeah, they shouldn't have to worrysI about optimizing their formulas. But programmers writing C code should beyF at a much higher level then one of the unwashed, and I expect them to H write code that doesn't allow exploitation and at the very least doesn't SIGSEGV.  H > Similarly, you can expect that expert C programmers will usually writeI > appropriate bounds checking, while the unwashed masses of C programmersnH > will not.  Guess which group writes the majority of code?  Given that,: > are you really willing to claim that C is not a problem?  I C is NOT the problem, the problem is the programmers. Either way you takedG it, they ARE the problem. If C is bad, use something else - they don't.l   J > It's been known since the 1960s that there are certain classes of commonA > errors that programmers make, and that it is possible to designoE > languages such that many of them are caught at compile time.  It iscG > really a crock that brain-damaged languages like C and C++ became thea# > standards in the 1980s and 1990s.m  J I look at C like a slightly higher-level than machine code. I don't expectH it to coddle me. I expect to have to work to make sure my software works( right - and that's the way it should be.  tJ > Computers are supposed to be labor-saving devices.  Since it is entirelyJ > possible and even easy to design a programming language that can supportH > bounds checking, how can anyone maintain that it is a good idea to useH > a language that can't, and thus shift that burden onto the programmer?  I Exactly - again, it's the programmers. They decide to use C. case closed.R  eG > Note that I'm not criticizing C when used as was originally intended,aI > for systems programming hosted on and targeted to small computers.  ButtI > it's completely inappropriate for modern systems.  Even when developinghC > for small embedded systems, the development is normally hosted ongA > machines with plenty of memory and CPU cycles, on which using ai@ > cross-compiler for a reasonable language is entirely feasible.  . What is a reasonable language? Very curious :)   aaks   ------------------------------   Date: 22 Dec 2001 09:44:30 GMT) From: leslie@clio.rice.edu (Jerry Leslie)s3 Subject: Re: Congratulations for the festive seasonc' Message-ID: <a01klu$c3n$3@joe.rice.edu>i  3 Arthur Krewat (krewat@bartek.dontspamme.net) wrote:e : Bob Ceculski wrote:l2 : > Can you say that about your unix (gag!) boxes?J : > Want to have a clustering contest?  For disaster recovery, unix would 
 : > be toast!w$ : > VMS withstood the 9/11 disaster! :yK : In what way? Having a VMS cluster on the 100th floor of one of the towers,) : when it came down? I don't understand.   : I Bob is referring to multisite VMSClusters, where one node can be lost dueeG to a WTC-type disaster, and the remaining nodes still have enough votesg5 to keep the cluster going, without loss of data, etc.b  G Several institutions lost VMS systems on September 11, but continued too  operate.  Here's one such story:  M   http://www.success-stories.digital.com/css/cgi-bin/cssextusr/s=display/i=30g"   Success Stories: Credit Lyonnais   VMS Clusters' Trial By FireA  4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------    Date: 22 Dec 2001 07:40:49 +0800, From: Paul Repacholi <prep@prep.synonet.com>3 Subject: Re: Congratulations for the festive seasons- Message-ID: <87adwc3zwe.fsf@prep.synonet.com>r  - Mark Crispin <mrc@CAC.Washington.EDU> writes:h  - > On Fri, 21 Dec 2001, John J Francini wrote:w  D > > Hence, buffer overflows and other nastiness.  This philosophy is> > > by NO MEANS restricted to Unix; it is very much evident inD > > Microsoft-written OSes and applications (like Exchange, IIS, and6 > > many others), as well as plenty of other products.  yB > Including VMS.  The reason why there aren't many buffer overflowD > attacks on VMS is that the target is uncommon and uninteresting to; > the bad guys.  It's a form of security through obscurity.s  uB > If VMS had achieved the level of success that UNIX did, and UNIXD > faded into obscurity the way VMS did, then CERT bulletins would beD > filled with the latest VMS buffer overflow attacks, and UNIX users+ > would be snickering about VMS insecurity.t  E VMS had a pile of security nits, pre v5.5/6.0 or so. One of the firstsC things CERT did was cancel a post I did on the image activator. And B Mitnik caused a huge amount of pressure frm NASA and the US Mil toA get it, if not idiot proof, then at least idiot resitant. VMS hadtB a pile of weak spots, and they where not all FIELD/SERVICE either!  D VMS has had in its favour, a more complete memory protection scheme,@ and the multiple privilages rather than the unix all/none model.@ The multiple language implementation and the near total abscence& of null termination also helped a lot.   -- a< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  ! Date: Sat, 22 Dec 01 11:44:58 GMTe From: jmfbahciv@aol.com 3 Subject: Re: Congratulations for the festive seasonw+ Message-ID: <a0232f$bdi$2@bob.news.rcn.net>g  2 In article <9vvmkd$1126$1@citadel.in.taronga.com>,,    peter@taronga.com (Peter da Silva) wrote: >In article @ <francini1026-ya02408000R2112010135240001@news.ne.mediaone.net>,. >John J Francini <francini1026@mac.com> wrote:L >>        "We went to lunch afterward, and I remarked to Dennis that easily  half )H >>        the code I was writing in Multics was error recovery code. He 
 said, "We E >>        left all that stuff out. If there's an error, we have this t routine K >>        called panic, and when it is called, the machine crashes, and you  >>holler       -- >>        down the hall, 'Hey, reboot it.'" "i > H >It's worse today. At least UNIX has error *detection* code, and code isH >rewritten now and then to allow recovery from more errors, and there isF >an actual system call interface where security and overflow checks on >system calls can be made. >aF >In Windows, there is no single system call interface. Every call thatK >crosses a protection boundary has to invent its own protection mechanisms,uJ >because it's all based on regular shared library calls rather than traps. >nI >And, of course, instead of having 30 or 40 system calls (less on earliervJ >systems, more on later) you have tens of thousands of calls that run withE >elevated privileges that really need to exhaustively check all theira >arguments.  > @ Windows checks?  It was definitely my gut feel that they didn't  bother.    /BAH  ' Subtract a hundred and four for e-mail.A   ------------------------------  ! Date: Sat, 22 Dec 01 11:59:54 GMTa From: jmfbahciv@aol.com 3 Subject: Re: Congratulations for the festive seasonh+ Message-ID: <a023uf$bdi$3@bob.news.rcn.net>h  ? In article <3C23EA72.48874137@gce.com>, gce <ge@gce.com> wrote:h <snip>  J >Two: The process that creates VMS asks about security and customer data,  not G >just by code review, but asks at investigation time, at design review n time,sI >at function spec time, and at code review time. This makes it relativelyt7 >hard to slip things by. The culture insists on polish.  > F >Three: Much of VMS has been to the wars, gotten badly hurt, and been  replaced/ >so that much has changed since V1, V2, or V3. i > & >THAT is why VMS gets so few problems.   <pins>  < And that's why throwing out an operating system because it's: mature is stupid.  Unix is just starting that process.  It: takes an organized effort by a common group of people over( a decade to get the damn thing polished.  < It's not the code that's important; it's the people who know; how to get that code out to the field in a sane set of bitst7 that is important.  Once you break up that team, the OSv can be considered shit.  h  = Oh, yea.  A key ingredient of this team is that they are able > to learn from previous mistakes (not something that Misoft has
 done at all).n   /BAH  ' Subtract a hundred and four for e-mail.s   ------------------------------    Date: 22 Dec 2001 07:27:24 -0800( From: bob@instantwhip.com (Bob Ceculski)3 Subject: Re: Congratulations for the festive season = Message-ID: <d7791aa1.0112220727.1661c371@posting.google.com>   X leslie@clio.rice.edu (Jerry Leslie) wrote in message news:<a01klu$c3n$3@joe.rice.edu>...5 > Arthur Krewat (krewat@bartek.dontspamme.net) wrote:t > : Bob Ceculski wrote:b4 > : > Can you say that about your unix (gag!) boxes?L > : > Want to have a clustering contest?  For disaster recovery, unix would  > : > be toast!s& > : > VMS withstood the 9/11 disaster! > :sM > : In what way? Having a VMS cluster on the 100th floor of one of the towersa+ > : when it came down? I don't understand. - > : K > Bob is referring to multisite VMSClusters, where one node can be lost due I > to a WTC-type disaster, and the remaining nodes still have enough votesa7 > to keep the cluster going, without loss of data, etc.d > I > Several institutions lost VMS systems on September 11, but continued tom" > operate.  Here's one such story: > O >   http://www.success-stories.digital.com/css/cgi-bin/cssextusr/s=display/i=30s$ >   Success Stories: Credit Lyonnais >   VMS Clusters' Trial By Firet > 6 > --Jerry Leslie     (my opinions are strictly my own)  F Sorry, I forgot these are unix people ... they don't understand "real" clustering ... ;)e   ------------------------------  # Date: Sat, 22 Dec 2001 15:45:57 GMTs' From: bad bob <sfmc68@bellatlantic.net> 3 Subject: Re: Congratulations for the festive seasoni0 Message-ID: <3C24AC29.14FD8AD2@bellatlantic.net>   Bob Ceculski wrote:2 > Z > leslie@clio.rice.edu (Jerry Leslie) wrote in message news:<a01klu$c3n$3@joe.rice.edu>...7 > > Arthur Krewat (krewat@bartek.dontspamme.net) wrote:  > > : Bob Ceculski wrote:y6 > > : > Can you say that about your unix (gag!) boxes?M > > : > Want to have a clustering contest?  For disaster recovery, unix wouldh > > : > be toast!w( > > : > VMS withstood the 9/11 disaster! > > :.O > > : In what way? Having a VMS cluster on the 100th floor of one of the towersa, > > : when it came down? I don't understand. > > : M > > Bob is referring to multisite VMSClusters, where one node can be lost due K > > to a WTC-type disaster, and the remaining nodes still have enough votesC9 > > to keep the cluster going, without loss of data, etc.e > >4K > > Several institutions lost VMS systems on September 11, but continued to.$ > > operate.  Here's one such story: > > Q > >   http://www.success-stories.digital.com/css/cgi-bin/cssextusr/s=display/i=30o& > >   Success Stories: Credit Lyonnais! > >   VMS Clusters' Trial By Fireo > >y8 > > --Jerry Leslie     (my opinions are strictly my own) > H > Sorry, I forgot these are unix people ... they don't understand "real" > clustering ... ;)o Bob, Bob, Bob,F clustering = in PDP10 land back in the bygone era = was called loosely coupled-I multiprocessing.  I don't recall the origination of the term clustering,  H I don't recall the origination of the terms Loosely coupled multiproc orE symetrical multiprocessing...I don't want to drop a name and use the 6E wrong name, my recollection is a collection of folks kicked the ideasl around.t  H Small point of order, your use of the phrase "these are unix people ... G they don't understand "real" clustering" is a rather trite troll, quite2A beneath what I have come to expect from yoru posts.  This thread rC has contributors and readers who might object to such a stereotype.s  E I will give you some slack tho, there are a number of NT products nowsE available that bring new meaning to the term "clustering".  I believeuE a couple of those vendors may be basing their use of clustering as a t@ term of art on a different application, the famous Fuster Cluck.  G VMS folks really did perfect clustering and turn it into a distributed, D high availability tool.  Really does work. Kudos for that. The usualH Sun weenie trolls not withstanding any dec or vms news group discussion,E beowolf and other clustering efforts in the linux and BSD worlds are fG attempting to get that same level of reliability and availablity out of F commodity hardware.  Certainly not a bad effort and worth the results.  E Seriously, if we step back and look at dec HW, we have stuff that wasrF designed to be available.  We made an awesome amount of profit off of G selling service contracts that were really insurance policies that wellmD designed systems would provide little need for more than regular PM.  F If we look at all the OS developments, we certainly have some industryC leading innovations, we have some me too stuff, and we had some gody awfuliF stuff.  But the categorization of what falls into what category is notD mine to make = I am biased.  I lived thru the killing off of variousF products, cultures and the move towards a borg centric effort - all in the E name of good business.  Does not change my feelings.  My alternative iG views on what could have been or might have been can not be resolved...t the time is gone.d bobn   ------------------------------  % Date: Sat, 22 Dec 2001 16:51:22 +0100e( From: Paul Sture <paul.sture@bluewin.ch>3 Subject: Re: Congratulations for the festive seasone- Message-ID: <VA.000004f9.00bf0554@bluewin.ch>   S In article <francini1026-ya02408000R2112010135240001@news.ne.mediaone.net>, John J 1 Francini wrote:rI > For better or for worse, Mark Crispin is not a troll.  He has worked onoL > PDP-10 systems for many, many years and wrote many useful programs for the > 10/20 community. > & > He also has a way of being divisive. >   A I've never heard of the guy before this. First impressions count.r  H > While he's probably baiting people in the newsgroup (and has obviouslyJ > grown more ornery compared to his prior posts from 16 years ago (see theE > one that Alan Grieg dug up from 1984 via Google which was much more 7 > balanced), I don't think he deserves killfile status..  H I have to agree that Alan's example showed him in a completely different< light. As to killfile status, life is sometimes too short...   > M > I do not know Mark at all, have never met him, and disagree with several offI > his positions.  However, I don't like seeing someone who is very much ah@ > part of the PDP-10 family considered an ordinary USENET troll. > G > In the post that you decided was baiting by a troll, he posits a VERYe > important question.  > H > UNIX systems can often be made to misbehave, grant privleged access toK > users who don't deserve it, and even crash by being handed more data thanaK > they're expecting to handle -- the buffer overflow problem.  So can othereJ > modern OSes and applications.  It's a pervasive, pernicious problem that( > plagues much software developed today. > H > The most obvious one that comes to mind is just a few years ago when aM > bunch of UNIX vendors, as well as Microsoft and Apple, had to issue patchestF > for a problem where ICMP (ping) packets that were larger than the OS > expected would cause crashes.U > F > According to one paper published by the Oregon Graduate Institute ofL > Science and Technology, summarized in a C|NET article (see pointer below),I > the buffer overflow was the biggest computer vulnerability of the 90s. tM > UNIX had plenty of them; Windows and applications like Exchange are riddledm > with them.   > J > The article is here: <http://news.cnet.com/news/0-1003-200-1462855.html> > I > Why?  Because the logic to painstakingly check the data being handed to J > kernel and driver routines for sizing problems, data type mismatches, orA > invalid content was left out or incomplete, especially in earlyrI > implementations.  Why was it left out?  Because it costs people time toeK > write these checks, they take up space in the code, and it costs CPU timewM > to execute them.  UNIX was initially implemented first on the DEC PDP-7 andrG > then almost immediately ported to the PDP-11.  Address space was at an4 > premium.  Significant error checking was a luxury. >cF I never used a PDP-7, but PDP-11s running RT-11 then RSX, yes. My biasM has always been towards commercial applications, where I/O is more often thanrH not the bottleneck. Comprehensive error checking has always been part ofL that culture, for me at least (although I _have_ seen some pretty diabolical  lapses by others along the way).  K > Many of the older OSes, including Multics, TOPS-10/20, and also including H > VMS, were designed by people who cared deeply about making sure the OS+ > would keep running and would stay secure.h >o  L > Here's a pithy example of the difference.  The following quote is from theI > Multics history site at www.multicians.org.  It's a snippet of the pagemI > <http:www.multicians.org/unix.html>, in which Tom Van Vleck, one of thetL > longtime Multics designers, discusses the relationship between Multics and > its famous child, UNIX:  > K >         "I was working for MIT in those days, and one thing I did was to uN >         organize an MIT PDP-11 users' group and encourage them to look into R >         Unix. The idea of a free, non-vendor-supported operating system was new R >         to them. I invited Dennis Ritchie [one of the founders of UNIX] to come  >         up and talk to them.   > Q >         "We went to lunch afterward, and I remarked to Dennis that easily half  R >         the code I was writing in Multics was error recovery code. He said, "We M >         left all that stuff out. If there's an error, we have this routine kK >         called panic, and when it is called, the machine crashes, and you  > holler       h- >         down the hall, 'Hey, reboot it.'" "  >   J Interesting story, thanks. It does rather confirm a long held suspicion of mine...   H > Hence, buffer overflows and other nastiness.  This philosophy is by NOM > MEANS restricted to Unix; it is very much evident in Microsoft-written OSespK > and applications (like Exchange, IIS, and many others), as well as plentysF > of other products.   It's evident when keeping to software schedulesM > determined by marketing expediencies is deemed more important than spendingeO > the time to do a correct design and to test every conceivable failure mode.   J > It's evident any time that developers decide to not bother writing errorJ > checking code because it's "not interesting" and are allowed to get away1 > with it because doing so will impact schedules.u > O I came across similar examples in NT a few years ago. Not just buffer overflows L but the opposite when a stray null got into a string, effectively truncating+ it (I call it buffer underflow (tm) :-) ).    N I can distinctly recall tracking down an example of file date/time conversionsL in NT (they are quite sensibly held on disk as UTC date/times in NTFS). WithL my background it was quite a surprise when the example I found did _no error< checking whatsoever_. Needless to say, my rewrite of it did.  N Actually the buffer "underflow"/overflow problem has also stung me with COBOL G programs on VMS where someone from a C background decided not to bothern@ checking a length parameter, but look for a null instead. Nasty.  H I've always been used to passing binary buffers to and from subroutines,( usually by one of the following methods:   o - counted stringse o - a length parameterD o - passed by descriptor as per the VMS calling standard (if on VMS)  ; And always returned some kind of error code, which I check.>  C Guess what? I've disliked null terminated strings ever since I cameaD across them, at that was long before I picked up my first book on C.  N Further, when I was supporting literally hundreds of COBOL programs, I quietlyF sneaked in the compiler options /CHECK=(PERFORM,BOUNDS). The resultingN error reports made fixing problems in those areas child's play. The processor ? overhead was trivial in comparison to the rest of the workload.e  H > This is a long reply, and has wandered somewhat off the topic, but theI > point is still fairly clear: Mark Crispin is NOT a troll, even if he isn= > fanning the flames a fair bit.  His points _do_ have merit.o > F I too have wandered off, but I felt your response was worth a rational& reply. You also have private email :-) ___d
 Paul Sture Switzerlandl   ------------------------------  % Date: Sat, 22 Dec 2001 16:51:22 +0100 ( From: Paul Sture <paul.sture@bluewin.ch>3 Subject: Re: Congratulations for the festive seasonr- Message-ID: <VA.000004fa.00bf055f@bluewin.ch>c  I In article <1011221190540.59837B-100000@Ives.egh.com>, John Santos wrote:p >s [snip]  D > This turns out not to be the case.  Most VMS languages use countedC > strings and the OTS routines that do string copies that check theDB > counts when copying to fixed-length buffers, and truncate and/orC > warn you (but never, ever write past the end of the destination.)xG > This philosophy has been present since day one - ever notice the very 9 > non-RISCy MOVC5 instruction in the VAX instruction set?a > E > Sure this hurts performance sometimes: you have to store, maintain,0D > check and pass around all those pesky counts, and you can't do theB > cheap trick of copy bytes until you hit a <nul> in a tight loop.D > Instead you have to compare source and destination sizes, set yourA > loop counter to the minimum, and copy.  Sometimes you don't get2D > to stop early if the source string is short, since you may need toB > fill the destination.  On the other hand, <nul> is not a specialA > character in strings.  (In-band flow control is generally a bad  > idea.) > 8 > But what's a few nano-seconds if it saves you hours ofD > crash/reboot/recovery time and debugging?  Especially when the fixC > is to manually insert code that does the same bounds checking, ina > a less efficient manner? >s> Here's a point though. Those extra nano seconds mean that yourG subroutines (APIs, whatever), don't have to scan up a string themselves  to determine its length.  I For any program dealing with fixed length records, determining the recordcH length during its initialization phase means it's then available for any5 routine to use, for the program's execution lifetime.r  K I'd suggest that the CPU consumed on a Windows machine continually scanningmJ every buffer passed its APIs is probably many times greater than that usedF by a mechanism of passing the length (which you calculated once at the beginning anyway).  M Variable length records are only slightly harder - if you are constructing a sG variable string you likely know how long it is already, as part of the i construction process.   @ > Most (all?) exceptions to the above are in C programs that use@ > <nul>-terminated strings, and most of those were imported fromC > Unix, so I don't understand why the Unix users would be laughing.o? > I think they would be too busy fixing their own systems to be  > worrying about others. > D > Or maybe if the implementors of most of the public-domain software@ > (TCP/IP, etc., etc.) had grown up on VMS instead of Unix, theyE > would have been dismayed on discovering the lack of buffer overflows@ > protection in the usual C libraries and would have insisted on> > (or implemented themselves) a standard set of counted stringA > functions that everyone would use, and would have soon acquiredeF > direct support in ANSI C (for counted string literals and constants)C > and buffer overflow attacks on Unix would be a thing of the past.n   Good point.w ___.
 Paul Sture Switzerlandt   ------------------------------  # Date: Sat, 22 Dec 2001 16:08:02 GMTu2 From: Arthur Krewat <krewat@bartek.dontspamme.net>3 Subject: Re: Congratulations for the festive season15 Message-ID: <3C24AF98.EB06DD41@bartek.dontspamme.net>m   Bob Ceculski wrote:t > Z > leslie@clio.rice.edu (Jerry Leslie) wrote in message news:<a01klu$c3n$3@joe.rice.edu>...7 > > Arthur Krewat (krewat@bartek.dontspamme.net) wrote:r > > : Bob Ceculski wrote:e6 > > : > Can you say that about your unix (gag!) boxes?M > > : > Want to have a clustering contest?  For disaster recovery, unix would  > > : > be toast!t( > > : > VMS withstood the 9/11 disaster! > > :aO > > : In what way? Having a VMS cluster on the 100th floor of one of the towers , > > : when it came down? I don't understand. > > :eM > > Bob is referring to multisite VMSClusters, where one node can be lost dueaK > > to a WTC-type disaster, and the remaining nodes still have enough votes79 > > to keep the cluster going, without loss of data, etc.j > >RK > > Several institutions lost VMS systems on September 11, but continued to1$ > > operate.  Here's one such story: > >.Q > >   http://www.success-stories.digital.com/css/cgi-bin/cssextusr/s=display/i=30h& > >   Success Stories: Credit Lyonnais! > >   VMS Clusters' Trial By Fire  > > 8 > > --Jerry Leslie     (my opinions are strictly my own) > H > Sorry, I forgot these are unix people ... they don't understand "real" > clustering ... ;)h  K Yeah, I guess I lost all those years working on VMS clusters when I started0< using UNIX... my IQ must have gone down a whole 20 points...  L If anyone needs VMS clustering to recover from large disasters like the WTC,L they are not doing their jobs. I've been doing the same thing with Oracle on UNIX for the last 10 years...    aak    ------------------------------  % Date: Fri, 21 Dec 2001 22:25:45 -0700t+ From: Ben Franchuk <bfranchuk@jetnet.ab.ca>r3 Subject: Re: Congratulations for the festive seasone, Message-ID: <3C241959.79281F28@jetnet.ab.ca>   jmfbahciv@aol.com wrote:  ? > Oh, yea.  A key ingredient of this team is that they are able-@ > to learn from previous mistakes (not something that Misoft has > done at all).xD M$ is great at marketing! Not computer software. Why else could they sellE BASIC (yuck),DOS a (CP/M clone),WINDOWS! (apple clone?). The customero has not learned yet! --  ' Ben Franchuk --- Pre-historic Cpu's -- s+ www.jetnet.ab.ca/users/bfranchuk/index.htmlb   ------------------------------   Date: 22 Dec 2001 17:00:39 GMT0 From: Dave Cherkus <cherkus777@777unimaster.com>3 Subject: Re: Congratulations for the festive seasond1 Message-ID: <Xns917F79F8FAADidtoken@199.125.85.9>   9 gce <ge@gce.com> wrote in news:3C23EA72.48874137@gce.com: 	 > Not so.aC > The reason for the lack of buffer overflows is due to a number of D > factors. One: VMS habitually has used descriptors to pass strings, > which have sizes passed. e   Interesting.  - Was this true in the PDP11 operating systems?w  C I ask because the first place I saw the practice of zero-terminateduB strings was when using a PDP11 MACRO assembler, which provided the0 ASCIZ directive (ascii string, zero terminated).  @ I always thought that's where UNIX picked up the practice, since? UNIX was mainly written on a PDP11, and perhaps used MACRO as ai bootstrap language..   Dave   ------------------------------    Date: 22 Dec 2001 12:06:10 -0600+ From: young_r@encompasserve.org (Rob Young)u3 Subject: Re: Congratulations for the festive seasonr3 Message-ID: <elvMuVgB4DbZ@eisner.encompasserve.org>n  j In article <3C24AF98.EB06DD41@bartek.dontspamme.net>, Arthur Krewat <krewat@bartek.dontspamme.net> writes:   >> .I >> Sorry, I forgot these are unix people ... they don't understand "real"a >> clustering ... ;) > M > Yeah, I guess I lost all those years working on VMS clusters when I started > > using UNIX... my IQ must have gone down a whole 20 points... > N > If anyone needs VMS clustering to recover from large disasters like the WTC,N > they are not doing their jobs. I've been doing the same thing with Oracle on > UNIX for the last 10 years...  >   D 	Not everyone is using Oracle nor should they be.  Likewise, certain> 	folks "answer" is Veritas.  Okay, go out and buy something to? 	make your OS less handicapped.  Fine.  You do the best you cana! 	with what you have to work with.r   				Rob    ------------------------------  # Date: Sat, 22 Dec 2001 18:27:52 GMTv* From: "Bill Todd" <billtodd@metrocast.net>3 Subject: Re: Congratulations for the festive seasona@ Message-ID: <Ig4V7.82850$Zd.7883931@bin1.nnrp.aus1.giganews.com>  5 "Paul Sture" <paul.sture@bluewin.ch> wrote in messagee' news:VA.000004f9.00bf0554@bluewin.ch...n > In articleG <francini1026-ya02408000R2112010135240001@news.ne.mediaone.net>, John Jl > Francini wrote:    ...h  K > > Why?  Because the logic to painstakingly check the data being handed tofL > > kernel and driver routines for sizing problems, data type mismatches, orC > > invalid content was left out or incomplete, especially in earlytK > > implementations.  Why was it left out?  Because it costs people time totH > > write these checks, they take up space in the code, and it costs CPU timeK > > to execute them.  UNIX was initially implemented first on the DEC PDP-7e andcI > > then almost immediately ported to the PDP-11.  Address space was at ag6 > > premium.  Significant error checking was a luxury.  J I wrote quite a bit of PDP-11 code and made major efforts to eliminate allK possible fat, but even so in my experience 'significant error checking' was J *not* considered 'a luxury' - even in RMS-11, where the code was executingJ in the task context and could only trash that task if things went awry due to bad application input.o   ...n  J > > Here's a pithy example of the difference.  The following quote is from the K > > Multics history site at www.multicians.org.  It's a snippet of the page-K > > <http:www.multicians.org/unix.html>, in which Tom Van Vleck, one of thelJ > > longtime Multics designers, discusses the relationship between Multics ando > > its famous child, UNIX:0 > >5L > >         "I was working for MIT in those days, and one thing I did was toJ > >         organize an MIT PDP-11 users' group and encourage them to look intoK > >         Unix. The idea of a free, non-vendor-supported operating systemn was newaK > >         to them. I invited Dennis Ritchie [one of the founders of UNIX]i to comev  > >         up and talk to them. > >eF > >         "We went to lunch afterward, and I remarked to Dennis that easily halfeI > >         the code I was writing in Multics was error recovery code. He 	 said, "WerF > >         left all that stuff out. If there's an error, we have this routinemI > >         called panic, and when it is called, the machine crashes, and  you 
 > > holler/ > >         down the hall, 'Hey, reboot it.'" "h > >  >kL > Interesting story, thanks. It does rather confirm a long held suspicion of	 > mine...e  J Interesting, yes, but if you read it carefully you'll see that it does notK relate to error-checking but to error *recovery*.  The clear implication isrI that Ritchie checked for errors (which really does take very little extragI code or work) but chose to PANIC rather than attempt to recover from themc3 (which can take a great deal more code and effort).   K This trade-off can be a reasonable one in some circumstances (e.g., dealingaI with a piece of flakey hardware in a fully-mirrored environment where theeL other machine can just take over), whereas failure to check at all is almost always not.u   - bill   ------------------------------  % Date: Sat, 22 Dec 2001 13:58:35 -0500   From: John Santos <JOHN@egh.com>3 Subject: Re: Congratulations for the festive seasons6 Message-ID: <1011222135245.59837A-100000@Ives.egh.com>  - On Sat, 22 Dec 2001, David J. Dachtera wrote:u   > Christopher Stacy wrote: > >=20E > > >>>>> On 21 Dec 2001 18:48:48 -0800, Bob Ceculski ("Bob") writes:oH > >  Bob> Did the worlds top hacker lie to congress a few years ago whenB > >  Bob> he testified that the White House mail system ran on VMSB > >  Bob> (All-in-1) and that was one OS he could never hack into? > >=20; > > I wouldn't put too much stock in that particular point.n >=20. > So, you're saying he was less than truthful?  D From=20what I've read, it appears that Kevin Mitnick is an extremely@ good social engineer and fairly good at exploiting problems that< other people have found, but he isn't that proficient from aB purely technical standpoint.  In other words, he probably believedG what he said, (and, since he was saying something good about VMS, he=20sE probably is correct :-), but he doesn't really have the competence to  be making that judgement.a   --=20e John Santosd Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Sat, 22 Dec 2001 18:58:12 GMT * From: "Bill Todd" <billtodd@metrocast.net>3 Subject: Re: Congratulations for the festive seasoneB Message-ID: <8J4V7.301892$uB.32180084@bin3.nnrp.aus1.giganews.com>  = "Dave Cherkus" <cherkus777@777unimaster.com> wrote in messagea+ news:Xns917F79F8FAADidtoken@199.125.85.9... ; > gce <ge@gce.com> wrote in news:3C23EA72.48874137@gce.com:  > > Not so.tE > > The reason for the lack of buffer overflows is due to a number ofoF > > factors. One: VMS habitually has used descriptors to pass strings, > > which have sizes passed. >t > Interesting. >i/ > Was this true in the PDP11 operating systems?t  F Certainly on RSX, though RSTS may have had greater affection for ASCIZ strings.  J Where they could be used safely (and efficiently, which was not always theH case), they did have advantages.  Byte-by-byte processing is at least asK efficient when dealing with a short string as the set-up involved in tryinghI to process it word-by-word, and condition codes make the loop-terminationrL check close to free (and without requiring the use of a counting register, a7 resource which the 11 did not have in great profusion).d   - bill   ------------------------------  # Date: Sat, 22 Dec 2001 18:58:12 GMTe* From: "Bill Todd" <billtodd@metrocast.net>3 Subject: Re: Congratulations for the festive season B Message-ID: <8J4V7.301893$uB.32180110@bin3.nnrp.aus1.giganews.com>  = "Dave Cherkus" <cherkus777@777unimaster.com> wrote in messager+ news:Xns917F79F8FAADidtoken@199.125.85.9...n; > gce <ge@gce.com> wrote in news:3C23EA72.48874137@gce.com:o > > Not so. E > > The reason for the lack of buffer overflows is due to a number of,F > > factors. One: VMS habitually has used descriptors to pass strings, > > which have sizes passed. >  > Interesting. >i/ > Was this true in the PDP11 operating systems?i  F Certainly on RSX, though RSTS may have had greater affection for ASCIZ strings.  J Where they could be used safely (and efficiently, which was not always theH case), they did have advantages.  Byte-by-byte processing is at least asK efficient when dealing with a short string as the set-up involved in tryingnI to process it word-by-word, and condition codes make the loop-terminationdL check close to free (and without requiring the use of a counting register, a7 resource which the 11 did not have in great profusion).a   - bill   ------------------------------  % Date: Sat, 22 Dec 2001 10:37:42 +0100y* From: dwparsons@t-online.de (Dave Parsons)) Subject: Re: CXX and the Hobbyist licenseiP Message-ID: <Ej0w7lFo08Zw-pn2-cSYEBT0HZu6d@jupiter.dwparsons.dialin.t-online.de>  K On Fri, 21 Dec 2001 22:07:00, "Kenneth Block" <krblock@computer.org> wrote:   L > > If you have a C++ license and just need the binary kit,  you may be able > toB > > use the beta kit. The beta kit is available for download from: > >wH > > ftp://ftp.compaq.com/pub/products/c-cxx/openvms/cxx/beta/ftindex.htm > >rL > > The sanity kit (final beta kit) for V6.5 should be available shortly. WeL > > will annouce this kit in comp.os.vms as soon as it is available. I would? > > wait until the sanity kit was available before downloading.p > " > The sanity kit is now available.  F Ahh, yes great. See my reply to your announcement, I found that first.   Dave   ------------------------------  % Date: Sat, 22 Dec 2001 10:03:29 -0500f+ From: "Main, Kerry" <Kerry.Main@compaq.com>e= Subject: RE: DDS4 (20/40 GB) tape drives in a Alphaserver 800rT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4016CE782@kaoexc01.americas.cpqcorp.net>   Bob,  C >>> ... also you may want to get a firmware cd to upgrade the 800'sL+ firmware, I think they are on 5.9 now ...<<   G Just a quick clarification - V6.1 is the current Alpha console firmwarer release.   For future reference: . http://ftp.digital.com/pub/DEC/Alpha/firmware/   Regardse    
 Kerry Main Senior Consultant  Compaq Canada Corp.a Professional Services  Voice: 613-592-4660n Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----/ From: Bob Ceculski [mailto:bob@instantwhip.com]  Sent: December 12, 2001 2:42 PMI To: Info-VAX@Mvb.Saic.Comt= Subject: Re: DDS4 (20/40 GB) tape drives in a Alphaserver 800l    * becherini@vortex.ufrgs.br wrote in message( news:<01121211012945@vortex.ufrgs.br>...< > Received:	by vortex.ufrgs.br (V5.0A-1, OpenVMS V7.2 Alpha)- > From:		Fabio Becherini <becherini@ufrgs.br>g  > Reply-to:	<becherini@ufrgs.br>> > Comments:	@vortex.ufrgs.br, vortex(46.451)::, psi%........::4 > References:	BR, TCHE, UFRGS, CPD network, Cia-INFO/ > Organization:	Cia-INFO /DRS /CPD-UFRGS /UFRGSd> > ____________________________________________________________ >=20 >=20 > 	Hi, >=209 > 	We have an AlphaServer 800 5/500 running OpenVMS V7.2.u >=205 > 	Is it possible to upgrade our DAT DDS3 tape drives  > 	to DDS4 (20/40 GB) drives ? >=20# > 	Is it possible with OpenVMS V7.2o" > 	or we need to upgrade VMS too ? >=20 > 	Best regards, >=20  G you may need a patch kit from Q w/updated mk drivers, also you may wantn toH get a firmware cd to upgrade the 800's firmware, I think they are on 5.9 now ...    ------------------------------  # Date: Sat, 22 Dec 2001 16:57:08 GMTr# From: Jim <krait1@worldnet.att.net> = Subject: Re: DDS4 (20/40 GB) tape drives in a Alphaserver 8002/ Message-ID: <3C24BB61.7040408@worldnet.att.net>s   Main, Kerry wrote:   > Bob, >  > C >>>>... also you may want to get a firmware cd to upgrade the 800'sn >>>>- > firmware, I think they are on 5.9 now ...<<a > I > Just a quick clarification - V6.1 is the current Alpha console firmwaret
 > release. >  > For future reference: 0 > http://ftp.digital.com/pub/DEC/Alpha/firmware/ >  >[snip]o    5 Actually, although the CD says 6.1, its 5.8-16 for ana AlphaServer 800.   -- a krait1@worldnet.att.neto   ------------------------------   Date: 22 Dec 2001 18:37:29 GMT1 From: JONESD@er6.eng.ohio-state.edu (David Jones)a: Subject: DECWindows weirdness - high interrupt stack usage: Message-ID: <a02jt9$5r8$1@charm.magnus.acs.ohio-state.edu>  H I was logging in remotely to my new DS10 and noticed the interrupt stackF time was over 60%.  Monitor IO showed no activity.  If I restarted theK DECwindows server, interrupt stack time would go to near-zero for 8 minutesdM or so then go back to 60-62%.  If I did disk activity, the IS time would dropnK for a few seconds, then go back to 60-62%.  I ran a CPU-intensive benchmark D program to test if the IS time reported was an artifact of a flaw in; monitor - the program's performance was slowed down by 60%.   ? Thinking the problem had to do with the screen saver, I edittedt@ decw$private_server_setup.com to define the screen saver relatedF symbols (decw$server_screen_saver_[interval|timeout|prefer_blanking]).E The presence of those logicals in decw$server0_table seems to placate.@ the server so it doesn't go wild with the interrupt stack usage.   Configuration:     DS10 (600 Mhz)'     KZPAC with 18 GB disk in JBOD mode.o"     VMS 7.2-1 (FIS configuration).C     3DLabs Oxygen VX1 graphics card (patch VMS721_VX1 V1.0 applied) B     DECwindows Motif V1.2-5 (patch VMS721_DW_MOT_MUP V1.0 applied)  @ I suspect the problem is with the VX1 driver, but can't be sure.      < David L. Jones               |      Phone:    (614) 292-6929- Ohio State University        |      Internet:oL 140 W. 19th St. Rm. 231a     |               jonesd@er6s1.eng.ohio-state.edu: Columbus, OH 43210           |               vman+@osu.edu  1 Disclaimer: I'm looking for marbles all day long.    ------------------------------  ! Date: Sat, 22 Dec 01 12:19:54 GMTs From: jmfbahciv@aol.com B Subject: Re: Definition of timesharing (was: VMS missing features)+ Message-ID: <a0253u$ib1$2@bob.news.rcn.net>t  / In article <858zbyrovv.fsf_-_@junk.nocrew.org>, /    Lars Brinkhoff <lars.spam@nocrew.org> wrote:o >jmfbahciv@aol.com writes:C >> I've learned that people out there have a strange idea about the G >> definition of timesharing.  Now, it is perfectly possible that it is F >> me who has the strange definition because I'm firmly TOPS-10 biased >> out of habit. > A >What is your definition of timesharing, exactly?  (I'm genuinelyi= >curious, since your use of the word sometimes surprises me.)t >u  > Sorry for the delay.  I had to think long and hard about this.  > I speak about an _ideal_ timesharing system since, in reality,: all implementations have to have tradeoffs; it also avoidsD reproducing the OS war we're currently having in another thread ;-).  B An ideal timesharing system, gives each user the warm feeling thatC all computing resources are immediately available for his/her use; hF the ideal timesharing system does this for all users at the same time.  D An ideal timesharing system can do asynchronous things synchronously% and synchronous thing asynchronously.l  B An ideal timesharing system is merely a tool for the user and acts? accordingly.  In other words, the user doesn't have to wait nor0. wrestle with the OS to get his real work done.   /BAH  ' Subtract a hundred and four for e-mail.    ------------------------------  % Date: Fri, 21 Dec 2001 22:34:32 -0700I+ From: Ben Franchuk <bfranchuk@jetnet.ab.ca> B Subject: Re: Definition of timesharing (was: VMS missing features), Message-ID: <3C241B68.1CA765DF@jetnet.ab.ca>   jmfbahciv@aol.com wrote: > 1 > In article <858zbyrovv.fsf_-_@junk.nocrew.org>,e1 >    Lars Brinkhoff <lars.spam@nocrew.org> wrote:t > >jmfbahciv@aol.com writes:E > >> I've learned that people out there have a strange idea about theaI > >> definition of timesharing.  Now, it is perfectly possible that it isoH > >> me who has the strange definition because I'm firmly TOPS-10 biased > >> out of habit. > >cC > >What is your definition of timesharing, exactly?  (I'm genuinely ? > >curious, since your use of the word sometimes surprises me.). > >t > @ > Sorry for the delay.  I had to think long and hard about this. > @ > I speak about an _ideal_ timesharing system since, in reality,< > all implementations have to have tradeoffs; it also avoidsF > reproducing the OS war we're currently having in another thread ;-). > D > An ideal timesharing system, gives each user the warm feeling thatD > all computing resources are immediately available for his/her use;H > the ideal timesharing system does this for all users at the same time. > F > An ideal timesharing system can do asynchronous things synchronously' > and synchronous thing asynchronously.h > D > An ideal timesharing system is merely a tool for the user and actsA > accordingly.  In other words, the user doesn't have to wait norn0 > wrestle with the OS to get his real work done.  0 Or crash halfway thru a large downloads like M$.H Note Linux can be real bad too for crashing -- every so often when I hadE linux on my computer I would get thrashing with X-windows and virtual D memory. You can't hard reset cause the disk is going, you can't soft0 reset because you can't acknowledge a keypress.  > /BAHF The problem with C is that nowadays you have a large unix library thatG everybody needs a tiny bit of. What ever happened to the idea that OS'syG make life easy for programing rather than re-inventing the wheel again?u -- n' Ben Franchuk --- Pre-historic Cpu's -- t+ www.jetnet.ab.ca/users/bfranchuk/index.htmlr   ------------------------------   Date: 22 Dec 2001 09:25:54 GMT) From: leslie@clio.rice.edu (Jerry Leslie)eG Subject: Re: Disaster Recovery Experts Recovering Disks From WTC Attack.' Message-ID: <a01jj2$c3n$2@joe.rice.edu>l  * Jerry Leslie (leslie@clio.rice.edu) wrote:I : Disk data recovery is an expense that multisite VMSClusters could have s : avoided.   :tL : Hopefully, there will be a government after action report on what systems 7 : minimized loss of data from the September 11 attacks.i :rA It sounds like there might be such a report, but it won't mention 
 "clusters"...M  E    http://www.computerworld.com/storyba/0,4125,NAV47_STO66774,00.htmlo>    Decentralization called key to infrastructure protection | &    Computerworld News & Features Story      By PATRICK THIBODEAU>    (December 19, 2001) V  H   "WASHINGTON -- Decentralized systems, such as those used by electronicF    communications networks (ECN) to trade securities, are a good modelE    for protecting systems from catastrophic attacks such as Sept. 11, =    financial executives told a U.S. House subcommittee today.   G    "Currently, we have a very high centralization" in security trading,sE    said Kim Bang, president of Bloomberg Tradebook LLC, an electronic G    broker, and "I think it would behoove the industry to have more thanh;    one hub ... and ECN, certainly, is a venue well suited."s  D    Appearing before the Subcommittee on Commerce, Trade and ConsumerG    Protection, Bang and others testified on the impact of the terroristi0    attacks on the communications infrastructure.  G    ECNs bring security traders together without a middleman; buyers andeC    sellers meet electronically through private networks that can be G    located anywhere. Increased use of decentralized systems "could helpgD    in the future to absorb shocks," said Joel Steinmetz, senior viceE    president at New York-based Instinet Corp., which operates an ECN.e  F    Internet traffic continued to flow following the terrorist attacks,G    and it's the Internet-like structure of ECNs that drew the attention.B    of the committee. "An ECN is not unlike the Internet in that itB    provides a platform that allows perfect strangers to enter fromA    anywhere and meet in an anonymous environment," said committeer&    Chairman Clifford Stearns (R-Fla.).  H    A key problem that affected Instinet and other businesses after Sept.G    11 was the destruction of Verizon Communications' telecommunicationspB    facilities in lower Manhattan, which knocked out phone service.  D    Catherine Kinney, a vice president at the New York Stock ExchangeD    Inc., said debate should focus on the issue of telecommunicationsG    connectivity "and ensuring that in the future there are alternativesg'    and contingencies well planned for."   D    "It's critical to understand that disasters such as these are notH    averted by hardening a single point of failure," said Steven Randich,F    CIO at Nasdaq Stock Market Inc. in Washington. "They are avoided byF    having resilience built into the network and backup connections andG    backup vendors. This is the key [IT infrastructure] lesson from thisf    tragedy."  "f      4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------  % Date: Sat, 22 Dec 2001 19:34:19 +1100r. From: Burnie M <burniem.NOSPAM@ozemail.com.au>- Subject: Re: Excitement -- and disappointmentn8 Message-ID: <vbh82u46l2v6qqjonvautsur9jqjdglhik@4ax.com>  4 On Sat, 22 Dec 2001 00:07:18 GMT, "Terry C. Shannon"" <terryshannon@mediaone.net> wrote:   > ? >"John McLean" <mcleanj@swissonline.delete.ch> wrote in messagei0 >news:3C23CA7C.F51D6214@swissonline.delete.ch... >>" >> So the future of VMS is Tru64 ? >oK >Lord, I hope not. Surely you know what Hewlett Parkard's HP-UX Group calls  >Tru64 UNIX....  >0 >  >m >o >S >o >J >@ >. >> >u >c >R >C >r >an ORGAN DONOR. >sL >with apologies all the incumbent Microsoft Business Partners who sadly bear >the same appellation  >h   ------------------------------    Date: 22 Dec 2001 10:51:53 -0800( From: bob@instantwhip.com (Bob Ceculski)@ Subject: FBI warns Windoze XP unsecure - VMS now more than ever!= Message-ID: <d7791aa1.0112221051.60abbfe6@posting.google.com>   ) here's your windoze ... you can have it!!a  ' http://www.theinquirer.net/22120101.htm?  # FBI warns WinXP patch 'not enough' t   Shut down Plug'n'Pray & By Mike Magee, 22/12/2001 11:58:01 BST    E THE US Federal Bureau of Investigation (FBI) has warned end users andiD businesses that the patch Microsoft has made available may not offerA enough protection against hackers breaking into systems remotely.rE It cautioned yesterday that companies using XP should also switch offdC Universal Plug'n'Pray as a further protection against the cavernouse$ security hole exposed last Thursday.  D But Microsoft is maintaining that the patch, which is also availableC for Win98, Win98SE and ME, is sufficient to close any security gap.9  C Disabling this feature will affect features specifically built intoME WinXP to make using PCs "even easier than before", as Microsoft mightt say.  F But if there are any other bugs lurking in PnP, then the FBI's cautionE might be wise. However, there may well be other holes lying around ini" wait that no-one's discovered yet.  F After all, Windows 98 was introduced years ago and no one picked up onA the bug that was carried forward into SE and ME until a few weeksl back.d  
 We hope.   E * AND TALKING 'bout the Great Vole, there's an interesting piece hereg> at Business Week exploring the EU's investigation into alleged monopolistic practices.e   See Also9 Major security hole found in WinXP, Win98, Win98SE, WinMEa   ------------------------------  ! Date: Sat, 22 Dec 01 10:23:38 GMTf From: jmfbahciv@aol.coml: Subject: Re: historical evidence of what went wrong at DEC+ Message-ID: <a01ua0$sbe$2@bob.news.rcn.net>g  > In article <buJU7.23922$Sj1.12199270@typhoon.ne.mediaone.net>,8    "Terry C. Shannon" <terryshannon@mediaone.net> wrote: >o6 >"Peter da Silva" <peter@taronga.com> wrote in message- >news:9vvm15$10nb$1@citadel.in.taronga.com... 4 >> In article <CCIU7.320$sK3.4944@news.cpqcorp.net>,7 >> Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:1H >> >If we had been able to push the VAX performance, as Intel has pushed >x86...r >>J >> That would have been difficult. 8086 is a deeply ugly instruction set,  buto, >> it's still easier to optimise than VAX... >>K >To be fair to Digital, VAX performance underwent a significant increase incF >the late 80s/early 90s. The first CVAX implementation delivered aboutL >2.7VUPS IIRC. 39 months later the NVAX derivative achieved ~36VUPs. That's  a K >thirteenfold performance improvement in 39 months, which wasn't bad at alls
 >for the day.e  1 It is when the effort was made 10 years too late.s   /BAH  ' Subtract a hundred and four for e-mail.h   ------------------------------  % Date: Sat, 22 Dec 2001 14:46:48 +0100 3 From: Terje Mathisen <terje.mathisen@hda.hydro.com>e: Subject: Re: historical evidence of what went wrong at DEC- Message-ID: <3C248EC8.A04EC982@hda.hydro.com>a   glen herrmannsfeldt wrote: > , > peter@taronga.com (Peter da Silva) writes: > 4 > >In article <CCIU7.320$sK3.4944@news.cpqcorp.net>,7 > >Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:eO > >>If we had been able to push the VAX performance, as Intel has pushed x86...- > M > >That would have been difficult. 8086 is a deeply ugly instruction set, butD, > >it's still easier to optimise than VAX... > : > Looking at it from today's technology, I am not so sure. > " > Maybe 5 or 10 years ago, though. > ? > With the number of transistors in a P4, you should be able to C > do something similar to what many CISC machines do now.  That is,y< > to internally take the CISC instruction apart and generate= > a RISC instruction stream.  The limited number of registerst5 > in x86, compared to VAX, might help balance it out.i  D A key difference between x86 and VAX is the fact that no x86 opcodesE (with the exception of the block move) can generate a large number of  memory operations.  H The worst of the regular ops would be the 'op mem,reg' read-modify-write3 instructions, which can require a bus lock as well.u   TerjeI   -- t  - <Terje.Mathisen@hda.hydro.com>@ "almost all programming can be viewed as an exercise in caching"   ------------------------------  % Date: Sat, 22 Dec 2001 09:30:43 -0800 # From: "Tom Linden" <tom@kednos.com>-: Subject: RE: historical evidence of what went wrong at DEC9 Message-ID: <CIEJLCMNHNNDLLOOGNJIKELLDMAA.tom@kednos.com>t   > -----Original Message-----< > From: Terje Mathisen [mailto:terje.mathisen@hda.hydro.com]+ > Sent: Saturday, December 22, 2001 5:47 AMa > To: Info-VAX@Mvb.Saic.Com < > Subject: Re: historical evidence of what went wrong at DEC >r >r > glen herrmannsfeldt wrote: > >i. > > peter@taronga.com (Peter da Silva) writes: > >r6 > > >In article <CCIU7.320$sK3.4944@news.cpqcorp.net>,9 > > >Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:rC > > >>If we had been able to push the VAX performance, as Intel has0 > pushed x86...n > >X: > > >That would have been difficult. 8086 is a deeply ugly > instruction set, but. > > >it's still easier to optimise than VAX...  @ Well if you consider the inability to color registers, optimize.F I have no doubt that the VAX could have been pushed to the same limits     > > < > > Looking at it from today's technology, I am not so sure. > >x$ > > Maybe 5 or 10 years ago, though. > >RA > > With the number of transistors in a P4, you should be able to E > > do something similar to what many CISC machines do now.  That is,_> > > to internally take the CISC instruction apart and generate? > > a RISC instruction stream.  The limited number of registersa7 > > in x86, compared to VAX, might help balance it out.s > F > A key difference between x86 and VAX is the fact that no x86 opcodesG > (with the exception of the block move) can generate a large number of/ > memory operations.  ? Of course, the key difference is that the X86 is an accumulatorr
 architecture.    >nJ > The worst of the regular ops would be the 'op mem,reg' read-modify-write5 > instructions, which can require a bus lock as well.j >: > Terje  >/ > --" > - <Terje.Mathisen@hda.hydro.com>B > "almost all programming can be viewed as an exercise in caching" >  >    ------------------------------  # Date: Sat, 22 Dec 2001 12:28:07 GMTh= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) 9 Subject: Re: HP admits it will kill VMS if merger suceedsa0 Message-ID: <00A06E42.AA5412CF@SendSpamHere.ORG>  f In article <dGGU7.317$sK3.5175@news.cpqcorp.net>, "Sue Skonetski" <susan.skonetski@compaq.com> writes:C >The only thing that is killing the OpenVMS Customer base is peopleeL >complaining and saying that Digital/Compaq/HP are going to kill VMS. Do youK >realize every time someone posts a sky is falling message we get calls andrE >emails from our customers which we then have to work with to keep asnM >customers, stopping us from doing other work (like porting work)? Every timetI >a negative stream starts our competition is glad and they can say "see IIK >told you so." No, I do not have my head in the sand, but I would prefer to M >defend VMS against a foe instead of a friend. Lets not loose the war becausei >of friendly fire.  L One of the reasons I try to avoid such threads.  However, it really wouldn'tL hurt -- in fact it would help -- if Compaq would have just a little backboneL to stand up and tout some of the superior to Micro$chlock products that they# have acquired from d|i|g|i|t|a|l.     L The sad fact is that the lack of anything positive about VMS often gets par-L leyed into debates that there must be something very negative happening with VMS.  K You wanna know HOW bad Compaq/digital information is about VMS?  I was at awK bank in NYC for about 10 days in the beginning of Dec.  One of the folks inAM the IS dept. there asked me if VMS was ever successfully ported to Alpha and,sK if so, how does it work?  They're still on VAX doing their funds transfers.t  K I also sent you a private email about another misguided company preaching atK sunset for VMS.  What's said in comp.os.vms is not so damaging as the spiel K coming from salesmen and representatives of other software vendors that are4K preaching the demise to present and would/could be future VMS clients.  HasoJ anything been said by Compaq upper mgt. to the misguided naysayers at that4 company?  I'd wager not or I'd have heard something.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM:            oJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes    ------------------------------  ! Date: Sat, 22 Dec 01 12:09:17 GMT> From: jmfbahciv@aol.com 9 Subject: Re: HP admits it will kill VMS if merger suceedst+ Message-ID: <a024g2$ib1$1@bob.news.rcn.net>a  H In article <y4bsgsa4px.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>,K    Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote: ( >"John Vottero" <John@mvpsi.com> writes: > J >> The top keeps repeating that OpenVMS will be supported but some people  don't  >> want to hear that.  >pJ >The top - the CEOs of HP and Compaq - actually know that VMS exists, and  thatH >one of the companies owns it? Colour me surprised - I could never have  told >from their public utterances.  ; There is that.  There is also the fact that VPs residing int< Texas consider the few (their words, not mine) New HampshireD employees they have to be a PITA.  That is a corporate headquarters'> attitude.  Everything that doesn't come out of the CEO's mouth= does not surprise me.  (Now reread the last sentence; I meantn5 it the way I said it :-)).  Go read their interviews.    /BAH  ' Subtract a hundred and four for e-mail.e   ------------------------------  % Date: Sat, 22 Dec 2001 13:35:57 -0500B, From: "Brian Luther" <brian.luther@hwcn.org>) Subject: Logging in on a Graphics console ; Message-ID: <Do4V7.32807$Yq5.4644499@news20.bellglobal.com>u  H I've got an Alphaserver 1000 4/233 for home use, and the dealer I got itK from put OpenVMS 7.0 on it. I can get into SRM and boot OpenVMS, but then IrL can't login from that graphics console. Is that the way it's supposed to be?J I haven't been able to get my Terminal Emulator (Smarterm) on a W2K box toL talk to the Alphaserver over one of the serial ports. Since it's for home, IK managed to get a base OpenVMS license from them, but no support. And, beingh1 the holidays, they're not around to call anyways.s   Am I missing something simple?   thanks,  briani   ------------------------------  % Date: Sat, 22 Dec 2001 05:03:04 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> : Subject: Re: MPE-Tru64 compromise?  VMS-HPux new platform?, Message-ID: <3C245A51.463EC37D@videotron.ca>   Bob Ceculski wrote:t > G > I think the two weak OS links for the new Q-HP have been announced asnI > history ... MPE no match for VMS - gone!  Tru64 market less than HPux -t@ > merged!  That's it!  I think the new Q-HP cleanup is complete   N The way I saw it was more of a "if you want me to drop Tru64, you'll also haveK to make a compromise". Carly responds: Ok, I'll drop MPE and we'll be even:i- each will have dropped an equal amount of OS.s   ------------------------------  % Date: Sat, 22 Dec 2001 17:29:57 +0100s; From: moeller@cdc.informatik.tu-darmstadt.de (Bodo Moeller)n( Subject: OpenSSL version 0.9.6c released0 Message-ID: <20011222172957.A16597b@openssl.org>   OpenSSL version 0.9.6c releaseda ===============================x  - OpenSSL - The Open Source toolkit for SSL/TLSe http://www.openssl.org/   F The OpenSSL project team is pleased to announce the release of versionH 0.9.6c of our open source toolkit for SSL/TLS.  This new OpenSSL versionF is mostly a bugfix release and incorporates at least 40 changes to theL toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES).  ! The most significant changes are:a  '     o Various SSL/TLS library bugfixes.i     o BIGNUM library fixes.-2     o RSA OAEP and random number generation fixes.-     o Object identifiers corrected and added.-)     o Add assembler BN routines for IA64.0A     o Add support for OS/390 Unix, UnixWare with gcc, OpenUNIX 8,:9       MIPS Linux; shared library support for Irix, HP-UX.tA     o Add crypto accelerator support for AEP, Baltimore SureWare,l6       Broadcom and Cryptographic Appliance's keyserver!       [in 0.9.6c-engine release].l  F We consider OpenSSL 0.9.6c to be the best version of OpenSSL availableA and we strongly recommend that users of older versions upgrade aseD soon as possible.  OpenSSL 0.9.6c is available for download via HTTPE and FTP from the following master locations (you can find the variouso= FTP mirrors under http://www.openssl.org/source/mirror.html):a  "   o http://www.openssl.org/source/!   o ftp://ftp.openssl.org/source/s  = [1] OpenSSL comes in the form of two distributions this time. I The reasons for this is that we want to deploy the external crypto devicecH support but don't want to have it part of the "normal" distribution justG yet.  The distribution containing the external crypto device support isnE popularly called "engine", and is considered experimental.  It's been,H fairly well tested on Unix and flavors thereof.  If run on a system withL no external crypto device, it will work just like the "normal" distribution.    The distribution file names are:  $     o openssl-0.9.6c.tar.gz [normal]+     o openssl-engine-0.9.6c.tar.gz [engine]A   Yours, The OpenSSL Project Team...  r  :   Mark J. Cox             Richard Levitte    Andy Polyakov8   Ralf S. Engelschall     Bodo Mller        Holger Reif9   Dr. Stephen Henson      Ulf Mller         Geoff Thorpes-   Ben Laurie              Lutz Jnicke       s   ------------------------------    Date: 22 Dec 2001 07:08:59 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) G Subject: Re: OT: FBI & Pentagon Quiz Microsoft Over Windows XP Problemsm3 Message-ID: <i6IBp5TOqOp2@eisner.encompasserve.org>i  S In article <a018ta$3vg$1@joe.rice.edu>, leslie@clio.rice.edu (Jerry Leslie) writes:h? >     http://www.siliconvalley.com/docs/news/svfront/001901.htmEK >     FBI and Pentagon quiz Microsoft over Windows XP problems (12/21/2001)I > J >    "WASHINGTON (AP) -- FBI and Defense Department officials and some topL >     industry experts sought reassurance Friday from Microsoft Corp. that aK >     free software fix it offered effectively stops hackers from attackinge> >     major flaws discovered in the latest version of Windows.  ? I would hope the DoD delegation included someone from the Navy.r   ------------------------------   Date: 22 Dec 2001 15:28:55 GMT) From: leslie@clio.rice.edu (Jerry Leslie)hG Subject: Re: OT: FBI & Pentagon Quiz Microsoft Over Windows XP Problemss' Message-ID: <a028rn$1k9$1@joe.rice.edu>h  . Larry Kilgallen (Kilgallen@SpamCop.net) wrote:? : In article <a018ta$3vg$1@joe.rice.edu>, leslie@clio.rice.edu d : (Jerry Leslie) writes:A : >     http://www.siliconvalley.com/docs/news/svfront/001901.htmeM : >     FBI and Pentagon quiz Microsoft over Windows XP problems (12/21/2001)  : > L : >    "WASHINGTON (AP) -- FBI and Defense Department officials and some topN : >     industry experts sought reassurance Friday from Microsoft Corp. that aM : >     free software fix it offered effectively stops hackers from attacking-@ : >     major flaws discovered in the latest version of Windows. :nA : I would hope the DoD delegation included someone from the Navy.d :s  I Why would they be interested ?  "Smart Ship" program ?  What's that ? :-)S  B The Navy has pulled these pages on their Smart Ship program since I December 10.  They didn't didn't mention "Microsoft" or "Windows" at all:i  0    http://www.dt.navy.mil/smartship/charter.html    Charter: Smart Ship  $    http://www.dt.navy.mil/smartship/     Smart Ship Program: Home Page  1    http://www.dt.navy.mil/smartship/currstat.html0&    Smart Ship Program - Current Status  C Perhaps they're just reorganizing their web sites.  Or perhaps theynF don't want opponents of deploying Microsoft in highly mission-critical% applications to know what's going on.a    4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------    Date: 22 Dec 2001 10:28:04 -0800( From: bob@instantwhip.com (Bob Ceculski)G Subject: Re: OT: FBI & Pentagon Quiz Microsoft Over Windows XP Problemsi= Message-ID: <d7791aa1.0112221028.270577cf@posting.google.com>i  X leslie@clio.rice.edu (Jerry Leslie) wrote in message news:<a028rn$1k9$1@joe.rice.edu>...0 > Larry Kilgallen (Kilgallen@SpamCop.net) wrote:A > : In article <a018ta$3vg$1@joe.rice.edu>, leslie@clio.rice.edu a > : (Jerry Leslie) writes:C > : >     http://www.siliconvalley.com/docs/news/svfront/001901.htmtO > : >     FBI and Pentagon quiz Microsoft over Windows XP problems (12/21/2001)l > : > N > : >    "WASHINGTON (AP) -- FBI and Defense Department officials and some topP > : >     industry experts sought reassurance Friday from Microsoft Corp. that aO > : >     free software fix it offered effectively stops hackers from attackinghB > : >     major flaws discovered in the latest version of Windows. > :sC > : I would hope the DoD delegation included someone from the Navy.f > :e > K > Why would they be interested ?  "Smart Ship" program ?  What's that ? :-)r > D > The Navy has pulled these pages on their Smart Ship program since K > December 10.  They didn't didn't mention "Microsoft" or "Windows" at all:d > 2 >    http://www.dt.navy.mil/smartship/charter.html >    Charter: Smart Ship > & >    http://www.dt.navy.mil/smartship/" >    Smart Ship Program: Home Page > 3 >    http://www.dt.navy.mil/smartship/currstat.htmlo( >    Smart Ship Program - Current Status > E > Perhaps they're just reorganizing their web sites.  Or perhaps they-H > don't want opponents of deploying Microsoft in highly mission-critical' > applications to know what's going on.a >  > 6 > --Jerry Leslie     (my opinions are strictly my own)  L This shows exactly why I hope most of defense and government stay on VMS ...J if they standardize on windoze intel then I guarantee that someone somedayM will shut them all down with some type of major hostile attack at a time whentB we need to be up!  VMS will keep them up! (except for the Navy) ;)   ------------------------------  ! Date: Sat, 22 Dec 01 10:34:04 GMTa From: jmfbahciv@aol.comAD Subject: Re: PDP-10 architectural flaws? (was: VMS missing features)+ Message-ID: <a01uti$sbe$5@bob.news.rcn.net>i  * In article <3C237513.B0746365@virgin.net>,)    Alan Greig <a.greig@virgin.net> wrote:  >  >f >Bob Koehler wrote:i >f >> I >>I >>   The accumulators were the first 4 bits of addresss space.  You couldaI >>   put code in them and jump to it, it would execute.  You could use anT= >>   accumulator address anywhere a memory address was valid.  >> >aL >And very handy that could be as well. A program could copy a small section  of itself into theL >accumulators and then jump into them. That code could load another program  (say) into the same1H >address space. Fast tight loops could also execute in the accumulators  although this was more ofn+ >a benefit on the earlier pre KL-10 PDP-10s2 >CH >>    I don't have the reference anymore, but I think it was the JSYS or >>    some of the JRST.w >> > I >Ah sounds like you are thinking of pre-defined MACROs such as ERMSG and e ERHLT which I think. >expanded to something like: >e >ERMSG < Unexpected error -> >c3 >       PUSHJ 17, [hrroi 1,[asciz/Unexpected Error/e# >                            psout%yE >                        setom 1                ;  -1 last error code E >                        esout%                ; output error strinngbA >                        popj 17]            ; continue executioni > H >Probably have the argument to esout% slightly wrong as I'm not sure it  went to .priou (primary I >output - sys$output) by default. psout% - primary output string out did.c >nK >Yes these predefined expansions assumed a stack pointer in 17 (octal) but h nothing forced you to 
 >use them. >e >t> I always wondered if those MACROes would be misinterpreted for? machine instructions.  (It was one of the reasons I didn't likeo+ them.)  Now I know.  I was right yet again.u  : One of the features of generating a MACRO listing was that: those macroes were expanded so that you could tell if the ; fucking thing was a macro (look at the machine instructionse= that occurred on the left hand side of the page).  Didn't any   CS classes study a CREF listing?   /BAH  ' Subtract a hundred and four for e-mail.c   ------------------------------  ! Date: Sat, 22 Dec 01 10:29:02 GMTL From: jmfbahciv@aol.comoD Subject: Re: PDP-10 architectural flaws? (was: VMS missing features)+ Message-ID: <a01uk4$sbe$3@bob.news.rcn.net>t  * In article <3C23D858.5FD4AA45@virgin.net>,)    Alan Greig <a.greig@virgin.net> wrote:o >a >v >Christopher Stacy wrote:t >CH >> >>>>> On Fri, 21 Dec 2001 20:03:55 +0000, Alan Greig ("Alan") writes: >>  Alan> Alan Greig wrote: I >>  >> Ah wait I think Bob might also be thinking of the NOOP JUMPA that l wasn't a >>G >> That stuff was not a feature of the PDP-10, but rather a feature of c TOPS-20. >aG >I know. Next you'll be telling me that jsys% was a feature of TOPS-20 a rather than  >the PDP-10 :-), >tB >Little known fact (well maybe not to some people here!). TOPS-20  implemented partJ >of one TOPS-10 UUO entirely natively. A GETTAB UUO for the OPSYS type wasG >understood directly by TOPS-20 monitor. Control was not passed to the n PA-1050aH >TOPS-10 emulator. Even the TOPS-10 Monitor calls manual gave the value  returned
 >for TOPS-20.s > G >In theory an executable could figure out whether it was running under m
 TOPS-10 orK >TOPS-20 and use native calls accordingly. Not that I recall any that ever e did.  C Yup.  There was a standard.  Each OS was assigned a value.  I can't6B remember the symbols in UUOSYM but they're there...IIRC, even ITS.@ If an entity outside of DEC wished to write a new OS and have it< assigned a value for UUO interrogation purposes, there was a? procedure in place to assign a value for that non-DEC entity.  h   /BAH  ' Subtract a hundred and four for e-mail.h   ------------------------------  ! Date: Sat, 22 Dec 01 10:31:04 GMT  From: jmfbahciv@aol.com D Subject: Re: PDP-10 architectural flaws? (was: VMS missing features)+ Message-ID: <a01unt$sbe$4@bob.news.rcn.net>   H In article <y48zbwa4jf.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>,K    Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:  >jmfbahciv@aol.com writes: >  >> > ...  You couldiJ >> >  put code in them and jump to it, it would execute.  You could use an> >> >  accumulator address anywhere a memory address was valid. >> <ahem>  That was a feature. >c: >....that would severely limit a modern implementation of  >the architecture. And+ >void any advantage an I-cache might bring.m  < If you had a machine so broken that you needed to run in the7 accumulators, I'm pretty sure that the caches would be l: turned off.  Zeroing memory on a cold boot was a very nice feature.   /BAH  ' Subtract a hundred and four for e-mail.t   ------------------------------  ! Date: Sat, 22 Dec 01 10:35:41 GMTa From: jmfbahciv@aol.comID Subject: Re: PDP-10 architectural flaws? (was: VMS missing features)+ Message-ID: <a01v0j$sbe$6@bob.news.rcn.net>f  2 In article <a002va$17iq$1@citadel.in.taronga.com>,,    peter@taronga.com (Peter da Silva) wrote:+ >In article <3C237513.B0746365@virgin.net>,u( >Alan Greig  <a.greig@virgin.net> wrote:D >>And very handy that could be as well. A program could copy a small >>section of itself into theD >>accumulators and then jump into them. That code could load another >>program (say) into the sameeH >>address space. Fast tight loops could also execute in the accumulators >>although this was more ofh, >>a benefit on the earlier pre KL-10 PDP-10s >nK ><------------- please adjust your window to this width ------ :) -------->g >iH >Once you have cache, though, this doesn't save you anything and has theE >disadvantage of making it very difficult to pipeline accesses to therG >accumulators, and someone else has already mentioned what this does to  >separate I&D caching. >eI >Not that the vax is particularly easy to pipeline. You need just-in-timesH >translation techniques to make the VAX run really fast. And they becameH >really practical far too late for the VAX, though I understand DEC cameA >up with a nice software JIT engine for the VAX-Alpha transition.r >t< no, no, no.  You don't get the point.  If you have to run in: the accumulators, you aren't running the system in all its> glory.  It's either very broken or every little bit of address% space has to be free for the program.    /BAH  ' Subtract a hundred and four for e-mail.l   ------------------------------   Date: 22 Dec 2001 18:28:11 GMT0 From: gah@ugcs.caltech.edu (glen herrmannsfeldt)D Subject: Re: PDP-10 architectural flaws? (was: VMS missing features), Message-ID: <a02jbr$25k@gap.cco.caltech.edu>   jmfbahciv@aol.com writes:n (snip)= >no, no, no.  You don't get the point.  If you have to run inb; >the accumulators, you aren't running the system in all itsr? >glory.  It's either very broken or every little bit of addresse& >space has to be free for the program.  > I understood that the search function in TECO did it.  I don't< know that I ever heard of anything else.  I believe it makes; a significant difference on the KA-10, maybe not on others.i   -- glene   ------------------------------  % Date: Sat, 22 Dec 2001 16:51:22 +0100h( From: Paul Sture <paul.sture@bluewin.ch>Y Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Congratulations for the festh- Message-ID: <VA.000004f8.00bf054a@bluewin.ch>q   In article uI <Pine.LNX.4.21.0112212011590.5800-100000@sakura.lunar-tokyo.net>, Daniel   Seagraves wrote:- > On Fri, 21 Dec 2001, Fred Kleinsorge wrote:t > ( > > > Properly implemented, UNIX has the, > > > potential for being a lot more secure, > >  > > Why do you believe this? > J > I did some testing... I can get my UNIX machines into a 100% secure modeK > of operation MUCH faster than OpenVMS!  I am using Linux for the UNIX OS,4E > and OpenVMS v7.2.  The OpenVMS machine is a MicroVAX 3100, the UNIXhJ > machine is an Intel P3-700.  Both machines were rebooted and left at theF > system login prompt.  One of my friends (who types faster than I do,G > BTW) was at the VMS console, I was at the UNIX machine.  An impartiale> > third party (My sister) was the starter.  She shouted "GO!". > H > On cue, Nate (my friend) logged in as SYSTEM on the VMS node, and I as; > root on the UNIX.  I typed "shutdown -h now" and he typed  > "@SYS$SYSTEM:SHUTDOWN".d > I > UNIX entered the 100% secure mode (I.E. the machine was powered off) in-K > about 2 minutes.  VMS, however, took around 5 minutes to get to the pointF" > where we could turn the VAX off. > D > See?  Proof, I can secure UNIX more then twice as fast as OpenVMS! >3 A simply wonderful test :-)   J Small nitpick though. A faster way on both my Linux (AMD 400) and my uVAX K 3100 system is to hit the reset button. I learnt this some time ago when a a) brief power cut took my home systems out.t  K The difference was on the subsequent restart. I _knew_ that the uVAX would "J come up with no damage, albeit slowly. The Linux box immediately went off E to do a lengthy FSCK, and at the end of that needed some repair work.d  I (Update: for several months I've been running ReiserFS on the Linux box, e= and testing has have shown a marked improvement in that area)d  H > And, I might add that my PDP-10, a KS-10, is even more secure than theK > UNIX machine.  It has no operating system, therefore, it's ALREADY turned= > off! > , > (Hey, I'm allowed to have fun, right? ^_^) >lG True! Another bit of fun: my NT box came back from that power cut with  1 "Keyboard error - press any key to continue". :-)o  , I had to reinstall the network driver too... ___S
 Paul Sture Switzerlandu   ------------------------------  % Date: Sat, 22 Dec 2001 07:33:45 -0400m+ From: Tim Shoppa <shoppa@trailing-edge.com>eP Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations1 Message-ID: <3C243759.41482417@trailing-edge.com>S   Larry Kilgallen wrote: >  > In article <Pine.LNX.4.21.0112212011590.5800-100000@sakura.lunar-tokyo.net>, Daniel Seagraves <dseagrav@sakura.lunar-tokyo.net> writes:, > L > > I did some testing... I can get my UNIX machines into a 100% secure modeM > > of operation MUCH faster than OpenVMS!  I am using Linux for the UNIX OS, G > > and OpenVMS v7.2.  The OpenVMS machine is a MicroVAX 3100, the UNIXeL > > machine is an Intel P3-700.  Both machines were rebooted and left at theH > > system login prompt.  One of my friends (who types faster than I do,I > > BTW) was at the VMS console, I was at the UNIX machine.  An impartialP@ > > third party (My sister) was the starter.  She shouted "GO!". > >oJ > > On cue, Nate (my friend) logged in as SYSTEM on the VMS node, and I as= > > root on the UNIX.  I typed "shutdown -h now" and he typed  > > "@SYS$SYSTEM:SHUTDOWN".r > > > Your friend can save time as SYSTEM by just typing SHUTDOWN.H > It has been a default abbreviation in SYS$MANAGER:LOGIN.COM for years.  ! Even faster results: MCR OPCCRASH    Tim.   ------------------------------    Date: 22 Dec 2001 07:47:33 -0800( From: bob@instantwhip.com (Bob Ceculski)P Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations= Message-ID: <d7791aa1.0112220747.34db69ed@posting.google.com>   h Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<J9HqeBo4oc22@eisner.encompasserve.org>... > In article <Pine.LNX.4.21.0112212011590.5800-100000@sakura.lunar-tokyo.net>, Daniel Seagraves <dseagrav@sakura.lunar-tokyo.net> writes:  > L > > I did some testing... I can get my UNIX machines into a 100% secure modeM > > of operation MUCH faster than OpenVMS!  I am using Linux for the UNIX OS,uG > > and OpenVMS v7.2.  The OpenVMS machine is a MicroVAX 3100, the UNIX L > > machine is an Intel P3-700.  Both machines were rebooted and left at theH > > system login prompt.  One of my friends (who types faster than I do,I > > BTW) was at the VMS console, I was at the UNIX machine.  An impartial.@ > > third party (My sister) was the starter.  She shouted "GO!". > > J > > On cue, Nate (my friend) logged in as SYSTEM on the VMS node, and I as= > > root on the UNIX.  I typed "shutdown -h now" and he typedN > > "@SYS$SYSTEM:SHUTDOWN".D > > > Your friend can save time as SYSTEM by just typing SHUTDOWN.H > It has been a default abbreviation in SYS$MANAGER:LOGIN.COM for years. > K > > UNIX entered the 100% secure mode (I.E. the machine was powered off) inhM > > about 2 minutes.  VMS, however, took around 5 minutes to get to the pointe$ > > where we could turn the VAX off. > > F > > See?  Proof, I can secure UNIX more then twice as fast as OpenVMS! > E > If you cut the power to your VMS machine it will be equally secure.PA > The careful-write approach taken by RMS ensures disk integrity.lA > Any fixup you choose to perform as part of reboot just recoversrE > unused disk blocks to the pool -- the file system is intact withoutp > it.s  M lets see you try that on an alpha box running minimum jobs ... My alphaserverr@ 800 with multi processes to close shuts down in under 2 minutes!   ------------------------------  # Date: Sat, 22 Dec 2001 12:46:15 GMTn= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)hY Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the  0 Message-ID: <00A06E45.32BBC3CD@SendSpamHere.ORG>   In article <Pine.LNX.4.21.0112212011590.5800-100000@sakura.lunar-tokyo.net>, Daniel Seagraves <dseagrav@sakura.lunar-tokyo.net> writes:m, >On Fri, 21 Dec 2001, Fred Kleinsorge wrote: >s' >> > Properly implemented, UNIX has the + >> > potential for being a lot more secure,i >> f >> Why do you believe this?  >tI >I did some testing... I can get my UNIX machines into a 100% secure modetJ >of operation MUCH faster than OpenVMS!  I am using Linux for the UNIX OS,D >and OpenVMS v7.2.  The OpenVMS machine is a MicroVAX 3100, the UNIXI >machine is an Intel P3-700.  Both machines were rebooted and left at theaE >system login prompt.  One of my friends (who types faster than I do,-F >BTW) was at the VMS console, I was at the UNIX machine.  An impartial= >third party (My sister) was the starter.  She shouted "GO!".- >-G >On cue, Nate (my friend) logged in as SYSTEM on the VMS node, and I asl: >root on the UNIX.  I typed "shutdown -h now" and he typed >"@SYS$SYSTEM:SHUTDOWN". >DH >UNIX entered the 100% secure mode (I.E. the machine was powered off) inJ >about 2 minutes.  VMS, however, took around 5 minutes to get to the point! >where we could turn the VAX off.t >rC >See?  Proof, I can secure UNIX more then twice as fast as OpenVMS!u > G >And, I might add that my PDP-10, a KS-10, is even more secure than theeJ >UNIX machine.  It has no operating system, therefore, it's ALREADY turned >off!r >e >(+ >(Hey, I'm allowed to have fun, right? ^_^)P   <CRTL-P> >>> He   About 2 seconds.  VMS wins!t   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM             sJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes    ------------------------------    Date: 22 Dec 2001 07:51:28 -0800( From: bob@instantwhip.com (Bob Ceculski)Y Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the  = Message-ID: <d7791aa1.0112220751.493be942@posting.google.com>r   Daniel Seagraves <dseagrav@sakura.lunar-tokyo.net> wrote in message news:<Pine.LNX.4.21.0112212011590.5800-100000@sakura.lunar-tokyo.net>...- > On Fri, 21 Dec 2001, Fred Kleinsorge wrote:  > ( > > > Properly implemented, UNIX has the, > > > potential for being a lot more secure, > >  > > Why do you believe this? > J > I did some testing... I can get my UNIX machines into a 100% secure modeK > of operation MUCH faster than OpenVMS!  I am using Linux for the UNIX OS, E > and OpenVMS v7.2.  The OpenVMS machine is a MicroVAX 3100, the UNIX J > machine is an Intel P3-700.  Both machines were rebooted and left at theF > system login prompt.  One of my friends (who types faster than I do,G > BTW) was at the VMS console, I was at the UNIX machine.  An impartial > > third party (My sister) was the starter.  She shouted "GO!". > H > On cue, Nate (my friend) logged in as SYSTEM on the VMS node, and I as; > root on the UNIX.  I typed "shutdown -h now" and he typedt > "@SYS$SYSTEM:SHUTDOWN".s > I > UNIX entered the 100% secure mode (I.E. the machine was powered off) in3K > about 2 minutes.  VMS, however, took around 5 minutes to get to the pointf" > where we could turn the VAX off. > D > See?  Proof, I can secure UNIX more then twice as fast as OpenVMS! > H > And, I might add that my PDP-10, a KS-10, is even more secure than theK > UNIX machine.  It has no operating system, therefore, it's ALREADY turnedd > off! >  > , > (Hey, I'm allowed to have fun, right? ^_^)  N Lets see you try that on an alpha box running minimum procs ... my alphaserverI 800 running alot of procs shuts down in uner a minute ... if you properlytN close your apps in shutdown.com, it goes a lot quicker than a unix (gag!) box.   ------------------------------  % Date: Sat, 22 Dec 2001 00:53:06 -0700n+ From: "Barry Treahy, Jr." <Treahy@mmaz.com>>Y Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the  ' Message-ID: <3C243BE2.7040303@mmaz.com>p  & --------------0307020003030304030807019 Content-Type: text/plain; charset=us-ascii; format=flowedx Content-Transfer-Encoding: 7bit   G Though you may be correct technically, Daniel, hitting the halt button aI on the console would have stopped VMS rather quickly with minimal damage oF and then the system could have been booted  with the console commands D either entered from OPA0: or just as a minimum startup, much like a & single user root mode boot for *nix.    E Granted today's *nix file systems are much better, but it wasn't too d6 long ago that you would trash UFS if you tried that...  C Just try doing a halt or power off on NT with a large file system, t6 you'll have scandisk running for the next two days :-)   Have a Merry Christmas   Barryt   Daniel Seagraves wrote:i  , >On Fri, 21 Dec 2001, Fred Kleinsorge wrote: >a% >>>Properly implemented, UNIX has then) >>>potential for being a lot more secure,e >>>p >>Why do you believe this? >> > I >I did some testing... I can get my UNIX machines into a 100% secure modeeJ >of operation MUCH faster than OpenVMS!  I am using Linux for the UNIX OS,D >and OpenVMS v7.2.  The OpenVMS machine is a MicroVAX 3100, the UNIXI >machine is an Intel P3-700.  Both machines were rebooted and left at thehE >system login prompt.  One of my friends (who types faster than I do,gF >BTW) was at the VMS console, I was at the UNIX machine.  An impartial= >third party (My sister) was the starter.  She shouted "GO!".e >wG >On cue, Nate (my friend) logged in as SYSTEM on the VMS node, and I as0: >root on the UNIX.  I typed "shutdown -h now" and he typed >"@SYS$SYSTEM:SHUTDOWN". >aH >UNIX entered the 100% secure mode (I.E. the machine was powered off) inJ >about 2 minutes.  VMS, however, took around 5 minutes to get to the point! >where we could turn the VAX off.l > C >See?  Proof, I can secure UNIX more then twice as fast as OpenVMS!P >1G >And, I might add that my PDP-10, a KS-10, is even more secure than theSJ >UNIX machine.  It has no operating system, therefore, it's ALREADY turned >off!  >Y >y+ >(Hey, I'm allowed to have fun, right? ^_^)o >C >r >w >n   -- e  @ Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028a      & --------------030702000303030403080701) Content-Type: text/html; charset=us-asciie Content-Transfer-Encoding: 7bita   <html> <head> </head>  <body>I Though you may be correct technically, Daniel, hitting the halt button onbI the console would have stopped VMS rather quickly with minimal damage andoM then the system could have been booted &nbsp;with the console commands eithertH entered from OPA0: or just as a minimum startup, much like a single user# root mode boot for *nix. &nbsp;<br>u <br>I Granted today's *nix file systems are much better, but it wasn't too long 5 ago that you would trash UFS if you tried that...<br>  <br>I Just try doing a halt or power off on NT with a large file system, you'll 3 have scandisk running for the next two days :-)<br>w <br> Have a Merry Christmas<br> <br>	 Barry<br>e <br> Daniel Seagraves wrote:<br>tb <blockquote type="cite" cite="mid:Pine.LNX.4.21.0112212011590.5800-100000@sakura.lunar-tokyo.net">H   <pre wrap="">On Fri, 21 Dec 2001, Fred Kleinsorge wrote:<br><br></pre>   <blockquote type="cite">     <blockquote type="cite">i       <pre wrap="">Properly implemented, UNIX has the<br>potential for being a lot more secure,<br></pre>e       </blockquote>v5       <pre wrap="">Why do you believe this?<br></pre>d       </blockquote>t       <pre wrap=""><!----><br>I did some testing... I can get my UNIX machines into a 100% secure mode<br>of operation MUCH faster than OpenVMS!  I am using Linux for the UNIX OS,<br>and OpenVMS v7.2.  The OpenVMS machine is a MicroVAX 3100, the UNIX<br>machine is an Intel P3-700.  Both machines were rebooted and left at the<br>system login prompt.  One of my friends (who types faster than I do,<br>BTW) was at the VMS console, I was at the UNIX machine.  An impartial<br>third party (My sister) was the starter.  She shouted "GO!".<br><br>On cue, Nate (my friend) logged in as SYSTEM on the VMS node, and I as<br>root on the UNIX.  I typed "shutdown -h now" and he typed<br>"@SYS$SYSTEM:SHUTDOWN".<br><br>UNIX entered the 100% secure mode (I.E. the machine was powered off) in<br>about 2 minutes.  VMS, however, took around 5 minutes to get to the point<br>where we could turn the VAX off.<br><br>See?  Proof, I can secure UNIX more then twice as fast as OpenVMS!<br><br>And, I might aj dd that my PDP-10, a KS-10, is even more secure than the<br>UNIX machine.  It has no operating system, therefore, it's ALREADY turned<br>off!<br><br><br>(Hey, I'm allowed to have fun, right? ^_^)<br><br><br><br><br></pre>m       </blockquote> 
       <br>8       <pre class="moz-signature" cols="$mailwrapcol">--   D Barry Treahy, Jr  *  Midwest Microwave  *  Vice President &amp; CIO    E-mail: <a class="moz-txt-link-abbreviated" href="mailto:Treahy@mmaz.com">Treahy@mmaz.com</a> * Phone: 480/314-1320 * FAX: 480/661-7028</pre>i
       <br>
       </body>n
       </html>l  ( --------------030702000303030403080701--   ------------------------------  # Date: Sat, 22 Dec 2001 12:05:06 GMTi" From: "Hans Vlems" <hvlems@iae.nl>Y Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the  1 Message-ID: <SF_U7.1257$E82.4032@typhoon.bart.nl>l  , This is a multi-part message in MIME format.  + ------=_NextPart_000_0012_01C18AE9.B4C4E460u Content-Type: text/plain;j 	charset="iso-8859-1"c+ Content-Transfer-Encoding: quoted-printables   Barry,  H don't treat that post as if it were serious. The guy used elapsed time = to compare two=20eE operating systems. That may be useful on roughly equivalent hardware.n) But a P-III/700 versus a microVAX3100????i   Hans8   Barry Treahy, Jr. <Treahy@mmaz.com> wrote in message =! news:3C243BE2.7040303@mmaz.com...oJ   Though you may be correct technically, Daniel, hitting the halt button =J on the console would have stopped VMS rather quickly with minimal damage =G and then the system could have been booted  with the console commands = E either entered from OPA0: or just as a minimum startup, much like a =u( single user root mode boot for *nix. =20  H   Granted today's *nix file systems are much better, but it wasn't too =6 long ago that you would trash UFS if you tried that...  F   Just try doing a halt or power off on NT with a large file system, =6 you'll have scandisk running for the next two days :-)     Have a Merry Christmas     BarryX     Daniel Seagraves wrote:   + On Fri, 21 Dec 2001, Fred Kleinsorge wrote:bH Properly implemented, UNIX has thepotential for being a lot more secure, Why do you believe this?E I did some testing... I can get my UNIX machines into a 100% secure = F modeof operation MUCH faster than OpenVMS!  I am using Linux for the =H UNIX OS,and OpenVMS v7.2.  The OpenVMS machine is a MicroVAX 3100, the =J UNIXmachine is an Intel P3-700.  Both machines were rebooted and left at =E thesystem login prompt.  One of my friends (who types faster than I = @ do,BTW) was at the VMS console, I was at the UNIX machine.  An =. impartialthird party (My sister) was the startH er.  She shouted "GO!".On cue, Nate (my friend) logged in as SYSTEM on =H the VMS node, and I asroot on the UNIX.  I typed "shutdown -h now" and =H he typed"@SYS$SYSTEM:SHUTDOWN".UNIX entered the 100% secure mode (I.E. =E the machine was powered off) inabout 2 minutes.  VMS, however, took =tJ around 5 minutes to get to the pointwhere we could turn the VAX off.See? =E  Proof, I can secure UNIX more then twice as fast as OpenVMS!And, I =h might arH dd that my PDP-10, a KS-10, is even more secure than theUNIX machine.  =I It has no operating system, therefore, it's ALREADY turnedoff!(Hey, I'm =o  allowed to have fun, right? ^_^)     --=20   B Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO=20  A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028g      + ------=_NextPart_000_0012_01C18AE9.B4C4E460  Content-Type: text/html; 	charset="iso-8859-1"u+ Content-Transfer-Encoding: quoted-printablen  > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>3 <META content=3D"text/html; charset=3Diso-8859-1" =N http-equiv=3DContent-Type>9 <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>  <STYLE></STYLE>  </HEAD>u <BODY bgColor=3D#ffffff> <DIV>Barry,</DIV>  <DIV>&nbsp;</DIV> H <DIV>don't treat that post as if it were serious. The guy used elapsed =
 time to=20 compare two </DIV>B <DIV>operating systems. That may be useful on roughly equivalent = hardware.</DIV>-4 <DIV>But a P-III/700 versus a microVAX3100????</DIV> <DIV>&nbsp;</DIV>l <DIV>Hans</DIV>u <BLOCKQUOTE=20J style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =, 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">"   <DIV>Barry Treahy, Jr. &lt;<A=20D   href=3D"mailto:Treahy@mmaz.com">Treahy@mmaz.com</A>&gt; wrote in =
 message <A=20d   =aJ href=3D"news:3C243BE2.7040303@mmaz.com">news:3C243BE2.7040303@mmaz.com</A= >...</DIV>Though=20 J   you may be correct technically, Daniel, hitting the halt button on the =
 console=20J   would have stopped VMS rather quickly with minimal damage and then the =	 system=20 I   could have been booted &nbsp;with the console commands either entered =  from=20mI   OPA0: or just as a minimum startup, much like a single user root mode =s boot for=20oJ   *nix. &nbsp;<BR><BR>Granted today's *nix file systems are much better, =	 but it=20t=   wasn't too long ago that you would trash UFS if you tried =l that...<BR><BR>Just=20H   try doing a halt or power off on NT with a large file system, you'll = have=20 C   scandisk running for the next two days :-)<BR><BR>Have a Merry=20S;   Christmas<BR><BR>Barry<BR><BR>Daniel Seagraves wrote:<BR>a   <BLOCKQUOTE=20   =IJ cite=3D"mid:Pine.LNX.4.21.0112212011590.5800-100000@sakura.lunar-tokyo.ne= t"=20-E   type=3D"cite"><PRE wrap=3D"">On Fri, 21 Dec 2001, Fred Kleinsorge =. wrote:<BR><BR></PRE>     <BLOCKQUOTE type=3D"cite">F       <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Properly implemented, =0 UNIX has the<BR>potential for being a lot more =A secure,<BR></PRE></BLOCKQUOTE><PRE wrap=3D"">Why do you believe =@B this?<BR></PRE></BLOCKQUOTE><PRE wrap=3D""><!----><BR>I did some =E testing... I can get my UNIX machines into a 100% secure mode<BR>of =uD operation MUCH faster than OpenVMS!  I am using Linux for the UNIX =G OS,<BR>and OpenVMS v7.2.  The OpenVMS machine is a MicroVAX 3100, the =aF UNIX<BR>machine is an Intel P3-700.  Both machines were rebooted and =J left at the<BR>system login prompt.  One of my friends (who types faster =H than I do,<BR>BTW) was at the VMS console, I was at the UNIX machine.  =5 An impartial<BR>third party (My sister) was the start F er.  She shouted "GO!".<BR><BR>On cue, Nate (my friend) logged in as =J SYSTEM on the VMS node, and I as<BR>root on the UNIX.  I typed "shutdown =I -h now" and he typed<BR>"@SYS$SYSTEM:SHUTDOWN".<BR><BR>UNIX entered the = C 100% secure mode (I.E. the machine was powered off) in<BR>about 2 =$= minutes.  VMS, however, took around 5 minutes to get to the =yE point<BR>where we could turn the VAX off.<BR><BR>See?  Proof, I can =AE secure UNIX more then twice as fast as OpenVMS!<BR><BR>And, I might aEB dd that my PDP-10, a KS-10, is even more secure than the<BR>UNIX =? machine.  It has no operating system, therefore, it's ALREADY =dA turned<BR>off!<BR><BR><BR>(Hey, I'm allowed to have fun, right? =h5 ^_^)<BR><BR><BR><BR><BR></PRE></BLOCKQUOTE><BR><PRE =r1 class=3Dmoz-signature cols=3D"$mailwrapcol">--=20   F Barry Treahy, Jr  *  Midwest Microwave  *  Vice President &amp; CIO=20  - E-mail: <A class=3Dmoz-txt-link-abbreviated =r> href=3D"mailto:Treahy@mmaz.com">Treahy@mmaz.com</A> * Phone: =E 480/314-1320 * FAX: 480/661-7028</PRE><BR></BLOCKQUOTE></BODY></HTML>n  - ------=_NextPart_000_0012_01C18AE9.B4C4E460--i   ------------------------------  % Date: Sat, 22 Dec 2001 10:02:10 -0500-- From: Michael Austin <miaustin@bellsouth.net>nY Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the n- Message-ID: <3C24A072.BFA17FC1@bellsouth.net>l   >s  F It was interesting to note that this individual says that the only way7 to "secure" a Unix system is by shutdown and power off.k  C I agree with the other response... a MV3100 (circa 1987-1990) vs. aOG PIIII/700 (circa 1999)?  I'll borrow a quote from John Stossel -- "Give, me a break".   Michael Austin DBA Consultant     >u >i. >> On Fri, 21 Dec 2001, Fred Kleinsorge wrote: >> >>) >> >>  Properly implemented, UNIX has the1- >> >>  potential for being a lot more secure,n >> >>S >> > Why do you believe this?X >> >F >> I did some testing... I can get my UNIX machines into a 100% secure >> mode C >> of operation MUCH faster than OpenVMS!  I am using Linux for thee >> UNIX OS,tF >> and OpenVMS v7.2.  The OpenVMS machine is a MicroVAX 3100, the UNIXG >> machine is an Intel P3-700.  Both machines were rebooted and left ate >> theG >> system login prompt.  One of my friends (who types faster than I do, > >> BTW) was at the VMS console, I was at the UNIX machine.  An >> impartial( >> third party (My sister) was the start >> er.  She shouted "GO!". >>F >> On cue, Nate (my friend) logged in as SYSTEM on the VMS node, and I >> ase< >> root on the UNIX.  I typed "shutdown -h now" and he typed >> "@SYS$SYSTEM:SHUTDOWN". >>G >> UNIX entered the 100% secure mode (I.E. the machine was powered off)  >> indF >> about 2 minutes.  VMS, however, took around 5 minutes to get to the >> point# >> where we could turn the VAX off.L >>E >> See?  Proof, I can secure UNIX more then twice as fast as OpenVMS!  >> >> And, I might ab; >> dd that my PDP-10, a KS-10, is even more secure than thecE >> UNIX machine.  It has no operating system, therefore, it's ALREADYA	 >> turnede >> off!e >> >>- >> (Hey, I'm allowed to have fun, right? ^_^)e >> >> >> >> >> > -- >wA > Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO- >-C > E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028C >l >)   ------------------------------  % Date: Sat, 22 Dec 2001 10:02:38 -0700l+ From: "Barry Treahy, Jr." <Treahy@mmaz.com>2Y Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the o% Message-ID: <3C24BCAE.60105@mmaz.com>1  & --------------0803000403080502010404019 Content-Type: text/plain; charset=us-ascii; format=flowed  Content-Transfer-Encoding: 7bits   Hans Vlems wrote:    > Barry, >  >  s >rI > don't treat that post as if it were serious. The guy used elapsed time e > to compare two >tG > operating systems. That may be useful on roughly equivalent hardware.g >n+ > But a P-III/700 versus a microVAX3100????e >eG Yes, he sent me a message off-line which had more of his dry humor and  B once it was pointed out to me, I was in fact amused but missed it - because of all of the rhetoric of the list.  ,  I Perhaps others, besides myself, can take a lesson from this missed humor  G and consider that the 'heat and volume' of the lists discussions since eB the demise of Alpha and the C&C Show this summer might indicate a H perfect time kill off these threads and as an earlier posted mentioned, # returning to a technical content.  1  I We are all passionate about what has transpired, but regrettably we must MF also accept that Compaq probably does not care or take serious any of B our banterings, rants, or raves on this list.  If they did, their I actions prior to this summer and perhaps even those of this summer would s* have been different or not occured at all.  ? I, for one, will make a best effort to cease and desist on the !F non-technical postings and deal with Compaq & HP the only way that is H probably heard and matters most, how I spend our corporate IT dollars...  2 I trust that all you folks have a Merry Christmas.  
 Best regards,s   Barryp     >  d >. > Hans >sC >     Barry Treahy, Jr. <Treahy@mmaz.com <mailto:Treahy@mmaz.com> >-9 >     wrote in message news:3C243BE2.7040303@mmaz.com ...T >hE >     Though you may be correct technically, Daniel, hitting the halteF >     button on the console would have stopped VMS rather quickly withE >     minimal damage and then the system could have been booted  witheA >     the console commands either entered from OPA0: or just as acI >     minimum startup, much like a single user root mode boot for *nix.  h > F >     Granted today's *nix file systems are much better, but it wasn't@ >     too long ago that you would trash UFS if you tried that... >nH >     Just try doing a halt or power off on NT with a large file system,< >     you'll have scandisk running for the next two days :-) >a >     Have a Merry Christmas >t >     Barrya >t >     Daniel Seagraves wrote:  >s- >>On Fri, 21 Dec 2001, Fred Kleinsorge wrote:h >>& >>>>Properly implemented, UNIX has the* >>>>potential for being a lot more secure, >>>> >>>Why do you believe this?C >>>m >>J >>I did some testing... I can get my UNIX machines into a 100% secure modeK >>of operation MUCH faster than OpenVMS!  I am using Linux for the UNIX OS,aE >>and OpenVMS v7.2.  The OpenVMS machine is a MicroVAX 3100, the UNIXmJ >>machine is an Intel P3-700.  Both machines were rebooted and left at theF >>system login prompt.  One of my friends (who types faster than I do,G >>BTW) was at the VMS console, I was at the UNIX machine.  An impartiali' >>third party (My sister) was the startb >>er.  She shouted "GO!".s >>H >>On cue, Nate (my friend) logged in as SYSTEM on the VMS node, and I as; >>root on the UNIX.  I typed "shutdown -h now" and he typed  >>"@SYS$SYSTEM:SHUTDOWN".s >>I >>UNIX entered the 100% secure mode (I.E. the machine was powered off) inSK >>about 2 minutes.  VMS, however, took around 5 minutes to get to the pointw" >>where we could turn the VAX off. >>D >>See?  Proof, I can secure UNIX more then twice as fast as OpenVMS! >> >>And, I might a: >>dd that my PDP-10, a KS-10, is even more secure than theK >>UNIX machine.  It has no operating system, therefore, it's ALREADY turnedo >>off! >> >>, >>(Hey, I'm allowed to have fun, right? ^_^) >> >> >> >> >, >--  >mA >Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO h >fB >E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028 >n >i   -- ^  @ Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-70284      & --------------080300040308050201040401) Content-Type: text/html; charset=us-asciie Content-Transfer-Encoding: 7bitn   <html> <head> </head>  <body> Hans Vlems wrote:<br>dG <blockquote type="cite" cite="mid:SF_U7.1257$E82.4032@typhoon.bart.nl">n9   <meta content="MSHTML 5.00.2314.1000" name="GENERATOR">h   <style></style>o   <div>Barry,</div>l   <div>&nbsp;</div>bH   <div>don't treat that post as if it were serious. The guy used elapsed time to  compare two </div>lR   <div>operating systems. That may be useful on roughly equivalent hardware.</div>6   <div>But a P-III/700 versus a microVAX3100????</div>   </blockquote>iK Yes, he sent me a message off-line which had more of his dry humor and once K it was pointed out to me, I was in fact amused but missed it because of all<' of the rhetoric of the list. &nbsp;<br>b   <br>H Perhaps others, besides myself, can take a lesson from this missed humorJ and consider that the 'heat and volume' of the lists discussions since theI demise of Alpha and the C&amp;C Show this summer might indicate a perfectkI time kill off these threads and as an earlier posted mentioned, returningl" to a technical content. &nbsp;<br>   <br>H We are all passionate about what has transpired, but regrettably we mustI also accept that Compaq probably does not care or take serious any of ourwP banterings, rants, or raves on this list. &nbsp;If they did, their actions priorN to this summer and perhaps even those of this summer would have been different or not occured at all.<br>   <br>L I, for one, will make a best effort to cease and desist on the non-technicalJ postings and deal with Compaq &amp; HP the only way that is probably heard= and matters most, how I spend our corporate IT dollars...<br>l   <br>6 I trust that all you folks have a Merry Christmas.<br>   <br> Best regards,<br>S   <br>	 Barry<br>r   <br>   <br>I   <blockquote type="cite" cite="mid:SF_U7.1257$E82.4032@typhoon.bart.nl">U     <div>&nbsp;</div>      <div>Hans</div>b     <blockquote style="border-left-width: 2px; border-left-style: solid; border-left-color: rgb(0,0,0); margin-left: 5px; margin-right: 0px; padding-left: 5px; padding-right: 0px; ">U       <div>Barry Treahy, Jr. &lt;<a href="mailto:Treahy@mmaz.com">Treahy@mmaz.com</a> a &gt; wrote in message <a href="news:3C243BE2.7040303@mmaz.com">news:3C243BE2.7040303@mmaz.com</a>e ..</div>I Though    you may be correct technically, Daniel, hitting the halt button<K on the console    would have stopped VMS rather quickly with minimal damageeM and then the system    could have been booted &nbsp;with the console commandsaM either entered from    OPA0: or just as a minimum startup, much like a singlep+ user root mode boot for    *nix. &nbsp;<br>e
       <br>L Granted today's *nix file systems are much better, but it    wasn't too long5 ago that you would trash UFS if you tried that...<br>t
       <br>L Just    try doing a halt or power off on NT with a large file system, you'll6 have    scandisk running for the next two days :-)<br>
       <br> Have a Merry    Christmas<br>c
       <br>	 Barry<br>S
       <br> Daniel Seagraves wrote:<br>sh       <blockquote cite="mid:Pine.LNX.4.21.0112212011590.5800-100000@sakura.lunar-tokyo.net" type="cite">N         <pre wrap="">On Fri, 21 Dec 2001, Fred Kleinsorge wrote:<br><br></pre>          <blockquote type="cite">"           <blockquote type="cite">o             <pre wrap="">Properly implemented, UNIX has the<br>potential for being a lot more secure,<br></pre>a             </blockquote>e;             <pre wrap="">Why do you believe this?<br></pre>?             </blockquote>              <pre wrap=""><!----><br>I did some testing... I can get my UNIX machines into a 100% secure mode<br>of operation MUCH faster than OpenVMS!  I am using Linux for the UNIX OS,<br>and OpenVMS v7.2.  The OpenVMS machine is a MicroVAX 3100, the UNIX<br>machine is an Intel P3-700.  Both machines were rebooted and left at the<br>system login prompt.  One of my friends (who types faster than I do,<br>BTW) was at the VMS console, I was at the UNIX machine.  An impartial<br>third party (My sister) was the start<br>er.  She shouted "GO!".<br><br>On cue, Nate (my friend) logged in as SYSTEM on the VMS node, and I as<br>root on the UNIX.  I typed "shutdown -h now" and he typed<br>"@SYS$SYSTEM:SHUTDOWN".<br><br>UNIX entered the 100% secure mode (I.E. the machine was powered off) in<br>about 2 minutes.  VMS, however, took around 5 minutes to get to the point<br>where we could turn the VAX off.<br><br>See?  Proof, I can secure UNIX more then twice as fast as OpenVMS!<br><br>And,a  I might a<br>dd that my PDP-10, a KS-10, is even more secure than the<br>UNIX machine.  It has no operating system, therefore, it's ALREADY turned<br>off!<br><br><br>(Hey, I'm allowed to have fun, right? ^_^)<br><br><br><br><br></pre>n             </blockquote>              <br>            <pre class="moz-signature" cols="$mailwrapcol">-- <br><br>Barry Treahy, Jr  *  Midwest Microwave  *  Vice President &amp; CIO <br><br>E-mail: <a class="moz-txt-link-abbreviated" href="mailto:Treahy@mmaz.com">Treahy@mmaz.com</a> * Phone: 480/314-1320 * FAX: 480/661-7028</pre>e             <br>             </blockquote>a             </blockquote>n             <br>>             <pre class="moz-signature" cols="$mailwrapcol">--   D Barry Treahy, Jr  *  Midwest Microwave  *  Vice President &amp; CIO    E-mail: <a class="moz-txt-link-abbreviated" href="mailto:Treahy@mmaz.com">Treahy@mmaz.com</a> * Phone: 480/314-1320 * FAX: 480/661-7028</pre>,             <br>             </body>l             </html>g  ( --------------080300040308050201040401--   ------------------------------  % Date: Sat, 22 Dec 2001 04:43:06 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> ( Subject: Re: QIOs, ASTs, and Event Flags, Message-ID: <3C2455A4.D9D0130E@videotron.ca>   Paul Repacholi wrote:EE > Remember the AST gives you back some info, and for an IO completion.A > AST, the 'AST Parameter' is the address of the associated IOSB.r  E My experience is that the single parameter supplied to the AST is the O parameter supplied in the QIO request following the address of the AST routine.f  N Perhaps you specify your IOSB twice in your QIOs ? (once early in the argumentL list as the IS status block, and a second time as the parameter to be passed to the AST ?   ------------------------------  % Date: Sat, 22 Dec 2001 12:45:44 +0100a1 From: John McLean <mcleanj@swissonline.delete.ch>b( Subject: Re: QIOs, ASTs, and Event Flags5 Message-ID: <3C247268.9052A036@swissonline.delete.ch>T   Paul Repacholi wrote:p > 1 > JF Mezei <jfmezei.spamnot@videotron.ca> writes:y >  > > Paul Repacholi wrote:3 > D > > > Yep, and remember, the AST hands you back the IOSB address forG > > > free :) So hang all the stuff you need after the IOSB and you arem
 > > > set. > B > > Care to explain this ? I don't quite understand how an AST can+ > > automatically have access to the IOSB ?  > E > Remember the AST gives you back some info, and for an IO completion2A > AST, the 'AST Parameter' is the address of the associated IOSB.  > F > So, if we lay out a structure with the directive stuff, IOSB, bufferG > pointer, scratch monkey, and the rest all in a standard order then we H > can do all the processing from that structure.  When we enter the AST,; > we have a pointer to this structure via the IOSB address.0    4 Sorry but I'm backtracking a to pick up this thread.  4 What we used to do back in the good ol' days was ...  C 1.  Create a bunch of buffers and put them in a linked list (calledB Empty List)r  H 2.  Remove an empty from this list and set a $QIO which passed a pointer to this "allocated buffer".r  G 3.  The incoming QIO would send the pointer back to us unchanged, alongd$ with some data to go into te buffer.  G 4.  The AST routine would copy the data into the buffer, put the bufferDD on another linked list (called Active List), then grab another entryC from the Empty List and set a QIO which passed a pointer to the newv allocated buffer.E  D 5.  The mainline code would simply cycle through the Active List andE process every entry that it found and when processing was complete its) would put the buffer onto the Empty List.      A few details....V  G The AST routine would set an Event flag AFTER transferring the new datasF into the buffer.  The mainline would clear the event flag, process allH entries in the queue and then Wait for the Event flag to be set ($WAITEFH I think it was).  This way even if the mainline found the event flag wasG set, when it tried to access the linked list header it would find there E were no entries and the processing would drop back to its normal WaitB	 position.h  H The attaching and removal of entries in the linked list was easy becauseE we had LIB$ calls which would do the same as the Macro routines.  ThewE important thing was that you were changing four pointers (forward andeE back, current item and next in each direction) all in uninterruptiblee	 VAX code.   E This was all documented in an example a DECNET manual, probably abouthE 1989.  (I know because I developed some software based on this idea.)=     I hope this helps.     John McLeanh   ------------------------------  % Date: Sat, 22 Dec 2001 09:23:08 -0500v. From: Lyndon Bartels <lbartels@pressenter.com>( Subject: Re: QIOs, ASTs, and Event Flags. Message-ID: <3C2450FC.61D8FDB0@pressenter.com>  , This is a multi-part message in MIME format.  % --------------2CCFD42967D803AEEACC54Ft* Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bith  D Thanks everyone for the help... I'm reading, and re-reading all your posts.  5 I think I'm starting to get this all figured out.... -  H I tore the guts out of my program and started over. But here's the logic I'm thinking of following.  F I create a doubly linked list. Each element in the list is a structure8 that contains all the info of that connection I'll need.  E I create the listener. Then submit a QIO to accept a connection. FromaC then on, I'm in a loop waiting for any event flag in the event flagdG cluster to be set. (sys$wtflor) When that happens, I need to figure out9A which conversation has cause the event flag to be set. (I haven'tS written that yet.)  C If the event is a new connection, I go off and make that connection E ready for conversation. And I get ready to accept another connection,UF either by reusing a "empty" element in the linked list, or by adding a new one.  5 If the event is a read or a write, I handle them too.g  H I attached my program as it is right now. Not everything is written, but9 it's getting there. There's enough for y'all to look at. >  H I'm having difficulty with the event flag cluster calls. (sys$ascefc andH sys$wtflor) I'm not sure I'm issuing them correctly, have the parameters8 set correctly, etc. Any help there would be appreciated.   Thanks in advance,   Lyndon   -- SG My opinions are mine and mine alone. They seldom align with those of myy	 employer.s    H The only good thing about putting the cart before the horse is you don't have to look at the horse's butt.  % --------------2CCFD42967D803AEEACC54FsE Content-Type: text/plain; charset=us-ascii; name="tcpip-server-g.c.2"n Content-Transfer-Encoding: 7bitt: Content-Disposition: inline; filename="tcpip-server-g.c.2"   /* tcpip-server-g.cd  J This program is a tcpip server process. It starts. Creates a output file.    */   /*  *  INCLUDE FILESI  */e    8 #include <descrip.h>		/* define OpenVMS descriptors	 	*/  8 #include <efndef.h>		/* define 'EFN$C_ENF' event flag	*/  : #include <in.h>			/* define internet related constants,	*/$ 				/* functions, and structures		*/6 #include <inet.h>		/* define network address info	 	*/4 #include <iodef.h>		/* define i/o function codes		*/  < #include <lib$routines.h>	/* define RTL library routines		*/  > #include <netdb.h>		/* define network database library info	*/  < #include <ssdef.h>		/* define system service status codes	*/9 #include <starlet.h>		/* define system service calls	 	*/P8 #include <stdio.h>		/* define standard i/o functions 	*/< #include <stdlib.h>		/* define standard library functions	*/: #include <string.h>		/* define string handling routines	*/; #include <stsdef.h>		/* define condition (status) values	*/d  B #include <tcpip$inetdef.h>	/* define tcpip internet definitions	*/ /*  *  NAMED CONSTANTSr  */i  - #define SERV_BACKLOG	1	/* server backlog			*/o5 #define SERV_PORTNUM	12345	/* server port number			*/y   /*  *  Structure definitions   */I   struct connect_record0.     {				/* information for this connection	*/1     unsigned short channel;	/* i/o channel 				*/o:     char host_ip[20];		/* string, ip address of client		*/8     int portnum;		/* port number of client connection	*/     };  
 struct buffere     {				/* string buffer			*/1     char buffer[512];		/* string information			*/l*     int length;			/* length of string			*/     };   struct iosb !     {				/* i/o status block			*/i7     unsigned short status;	/* i/o completion status		*/n?     unsigned short bytcnt;	/* bytes transfered if read/write	*/t8     void *details;		/* address of buffer or parameter	*/     };   struct itemlst_2-     {				/* item-list 2 descriptor/element	*/a*     unsigned short length;	/* length				*//     unsigned short type;	/* parameter type			*/d0     void *address;		/* address of item list			*/     };   struct itemlst_3-     {				/* item-list 3 descriptor/element	*/ *     unsigned short length;	/* length				*//     unsigned short type;	/* parameter type			*/h0     void *address;		/* address of item list			*/;     unsigned int *retlen;	/* address of returned length		*/h     };   struct sockchare,     {				/* socket characteristics buffer	*/*     unsigned short prot;	/* protocol				*/'     unsigned char type;		/* type					*/ -     unsigned char af;		/* address format			*/      };   struct linger_time     {e     int l_onoff;     int l_linger;      };   struct connection_info3     {					/* information for a given connection		*/aB     unsigned short channel;		/* i/o channel for the connection		*/B     unsigned int event_flag;		/* event flag for qio operations		*/D     unsigned int next_event;		/* event flag signafying the next 		*/ 					/* expected event				*/A     struct iosb iosb;			/* i/o status block returned from qio		*/ <     char host_ip[20];			/* string, ip address of client			*/:     int portnum;			/* port number of client connection		*/H     unsigned int client_retlen;		/* returned length of client socket		*/ 					/* address structure				*/ I     struct itemlst_3 client_itemlst;	/* client item-list 3 descriptor		*/rJ     struct sockaddr_in client_addr;	/* client socket address structure		*/  ?     struct connection_info *next;	/* pointer to next link				*/>B     struct connection_info *prev;	/* pointer to previous link			*/     };   /*!  *  Typedef structure definitions!  */m   typedef struct e3     {					/* information for a given connection		*/iB     unsigned short channel;		/* i/o channel for the connection		*/B     unsigned int event_flag;		/* event flag for qio operations		*/D     unsigned int next_event;		/* event flag signafying the next 		*/ 					/* expected event				*/A     struct iosb iosb;			/* i/o status block returned from qio		*/e<     char host_ip[20];			/* string, ip address of client			*/:     int portnum;			/* port number of client connection		*/H     unsigned int client_retlen;		/* returned length of client socket		*/ 					/* address structure				*/EI     struct itemlst_3 client_itemlst;	/* client item-list 3 descriptor		*/aJ     struct sockaddr_in client_addr;	/* client socket address structure		*/  ?     struct connection_info *next;	/* pointer to next link				*/MB     struct connection_info *prev;	/* pointer to previous link			*/     } connect_info_t;X   /*  *  Global variables  */s  5 FILE *message_file;		/* pinter to output log file		*/H  E struct itemlst_2 connect_sockopts;	/* socket options, connection	  */BF struct itemlst_2 tcp_option_itemlst;	/* tcpip options conn socket	  */   int done = FALSE;m  D struct sockchar listener_sockchar;	/* listener socket char buffer	*/; unsigned short listener_channel;	/* listen inet device 		*/a 					/* i/o channel			*/  ? $DESCRIPTOR(	inet_device,		/* string descriptor with logical */38 		"TCPIP$DEVICE:");	/* name of internet psuedodevice  */   /*  *  Procedures  */:   int lesserof(int a, int b) {  
 if (a < b)     return(a); else     return(b); }i     /* i */7 int create_channel_ast(connect_info_t *local_conn_info)H {  unsigned int local_status;   /*'  *  Init client's item-list descriptor.l  */d  + memset( &(local_conn_info->client_itemlst),a 	0,i* 	sizeof(local_conn_info->client_itemlst));P local_conn_info->client_itemlst.length  = sizeof( local_conn_info->client_addr);J local_conn_info->client_itemlst.address = &(local_conn_info->client_addr);L local_conn_info->client_itemlst.retlen  = &(local_conn_info->client_retlen);   /**  *  Init client's socket address structure  */   Q memset(&(local_conn_info->client_addr), 0, sizeof(local_conn_info->client_addr));b   /*  *  Assign connection socket  */    local_status = sys$assign(# 		&inet_device,			/* device name	*/a0 		&(local_conn_info->channel),	/* i/o channel	*/ 		0,				/* access mode	*/m 		0);				/* not used	*/t  & if ( !(local_status & STS$M_SUCCESS) )     { J     printf("Failed to assign i/o channel to TCP/IP connection device.\n");     exit( local_status );p     }t  8 printf("I/O Channel for connection device assigned.\n");G fprintf(message_file, "I/O Channel for connection device assigned.\n");t    local_conn_info->event_flag = 1;  local_conn_info->next_event = 2;   /*%  *  Accept a connection from a client   */i local_status = sys$qio(d2 		&local_conn_info->event_flag,		/* event flag		*/( 		listener_channel,			/* i/o channel		*/4 		IO$_ACCESS|IO$M_ACCEPT,			/* i/o function codes	*/3 		&(local_conn_info->iosb),		/* i/o status block	*/n 		0,					/* ast routine		*/u 		0,					/* ast parameter	*/ 		0,0,					/* p1,p2		*/l? 		&(local_conn_info->client_itemlst),	/* p3 - client ip info	*/S@ 		&(local_conn_info->channel),		/* p4 - channel for new socket*/ 		0,0);					/* p5,p6		*/  $ if (!(local_status & STS$M_SUCCESS))     { 6     printf("QIO for connection acceptance failed.\n");     exit( local_status );e     };   return (SS$_NORMAL); },       /* f */ int main (void) {p /* main procedure */  - int one  = 1;			/* reuseaddr option value		*/J  7 struct iosb listener_iosb;		/* i/o status block for 	*/ % 					/* listener related QIO calls	*/C  A unsigned int main_sys_status;		/* system service return status	*/>  < unsigned short connect_channel;		/* connect inet device 		*/ 					/* i/o channel			*/     unsigned int listener_flag = 1;u  D struct sockaddr_in serv_addr;		/* server socket address structure */E struct itemlst_2 serv_itemlst;		/* server item-list 2 descriptor   */t  G struct itemlst_2 sockopt_itemlst;	/* sockopt item-list 2 descriptor  */.H struct itemlst_2 reuseaddr_itemlst;	/* reuseaddr item-list 2 desc.	   */  E connect_info_t *client_list;		/* linked list of client connections */hA connect_info_t *first_client;		/* pointer to the first client 	*/   : int connect_info_size;			/* number of 512 byte pagelets	*/( 					/* the connection_info structure */  					/* consumes. Rounded up.	*/  1 char EF_name[15];			/* Event Flag Cluster name	*/eY int  EF_counter;			/* counter to loop though Event Flags, in a given Even Flag Cluster	*/k /*  *  Init pointers   */    client_list = NULL;  first_client = NULL;  7 connect_info_size = ((sizeof(connect_info_t)+511)/512);    /*!  *  Initialize event flag cluster   */    strcpy(EF_name,"IP_Flags");e) main_sys_status = sys$ascefc(0,&EF_name);t. for (EF_counter=1;EF_counter<=31;EF_counter++)     { ,     main_sys_status = sys$clref(EF_counter);+     if (!(main_sys_status & STS$M_SUCCESS))  	{) 	printf("Failed to clear event flag.'n");i 	exit( main_sys_status );h 	}     }    /*/  *  Init listener socket characteristics bufferM  */   % listener_sockchar.prot = TCPIP$C_TCP;e( listener_sockchar.type = TCPIP$C_STREAM;) listener_sockchar.af   = TCPIP$C_AF_INET;3   /*'  *  init reuseaddr's item-list elementst  */>  ( reuseaddr_itemlst.length  = sizeof(one);. reuseaddr_itemlst.type    = TCPIP$C_REUSEADDR;! reuseaddr_itemlst.address = &one;      /*'  *  init sockopt's item-list descriptor  */t4 sockopt_itemlst.length  = sizeof(reuseaddr_itemlst);* sockopt_itemlst.type    = TCPIP$C_SOCKOPT;- sockopt_itemlst.address = &reuseaddr_itemlst;    /*&  *  init server's item-list descriptor  */<+ serv_itemlst.length  = sizeof( serv_addr );e) serv_itemlst.type    = TCPIP$C_SOCK_NAME;u" serv_itemlst.address = &serv_addr;   /**  *  Init server's socket address structure  */X  * memset( &serv_addr, 0, sizeof(serv_addr));) serv_addr.sin_family	  = TCPIP$C_AF_INET;d- serv_addr.sin_port	  = htons( SERV_PORTNUM );s/ serv_addr.sin_addr.s_addr = TCPIP$C_INADDR_ANY;a   /*(  *  Init tcpip connection socket options  */<  ) tcp_option_itemlst.length  = sizeof(one);f7 tcp_option_itemlst.type    = TCPIP$C_FULL_DUPLEX_CLOSE;/" tcp_option_itemlst.address = &one;6 connect_sockopts.length  = sizeof(tcp_option_itemlst);+ connect_sockopts.type    = TCPIP$C_SOCKOPT;a/ connect_sockopts.address = &tcp_option_itemlst;a      < if ((message_file = fopen("socket-output.txt","w")) == NULL)     {.?     printf("Failed to open output file: socket-output.txt.\n");      exit (EXIT_FAILURE);     }e  < fprintf(message_file, "Program started. Awaiting input.\n");   /*  *  Assign listener socket  */p   main_sys_status = sys$assign(M" 		&inet_device,		/* device name	*/& 		&listener_channel,	/* i/o channel	*/ 		0,			/* access mode	*/ 		0);			/* not used	*/  ) if ( !(main_sys_status & STS$M_SUCCESS) ):     {1H     printf("Failed to assign i/o channel to TCP/IP listener device.\n");     exit( main_sys_status );     }4  / printf("I/O Channel for listener assigned.\n");a= fprintf(message_file,"I/O Channel for listener assigned.\n");@   /*#  *  Create and bind listener socketd  */t   main_sys_status = sys$qiow(9$ 		listener_flag,		/* event flag			*/' 		listener_channel,	/* i/o channel			*/c( 		IO$_SETMODE,		/* i/o function code		*/* 		&listener_iosb,		/* i/o status block		*/! 		0,			/* ast service routine		*/c 		0,			/* ast parameter		*/r3 		&listener_sockchar,	/* p1 - socket char buffer	*/h 		0,			/* p2				*/. 		&serv_itemlst,		/* p3 - local socket name	*/. 		SERV_BACKLOG,		/* p4 - connection backlog	*/. 		&sockopt_itemlst,	/* p5 - socket options		*/ 		0);			/* p6				*/e  $ if (main_sys_status & STS$M_SUCCESS)+     main_sys_status = listener_iosb.status;e     else     {18     printf("QIO creation of listener socket failed.\n");     exit( main_sys_status );     }a  ) if ( !(main_sys_status & STS$M_SUCCESS) )6     {n;     printf("Failed to create and bind listener socket.\n");f     exit( main_sys_status );     }   / printf("Listener socket created and bound.\n");r= fprintf(message_file,"Listener socket created and bound.\n");e     /*$  *  Make ready the first connection.  */n /*0  *  Initialize the first connection info record.  */n) first_client = malloc(connect_info_size);o client_list = first_client;I first_client->next = NULL; first_client->prev = NULL; /*%  *  Start the first connection socket   */e  A main_sys_status = sys$dclast(create_channel_ast,&first_client,0); ' if (!(main_sys_status & STS$M_SUCCESS))B     {r:     printf("Call to initiate first connection failed.\n");     exit( main_sys_status );     }e   /* do stuff */   while (!(done))n     { 0     printf("Waiting for an AST to complete.\n");       /*0      *  Wait for any of the eventflags to be set      */r      main_sys_status = sys$wflor(/ 			1,		/* any event flag in the flag cluster	*/o? 			31);		/* mask, what event flags in the cluster to look at	*/ +     if (!(main_sys_status & STS$M_SUCCESS))$ 	{6 	printf("sys$wflor called in main routine failed.\n"); 	exit( main_sys_status );s 	},     printf("An Event Flag has been set.\n");     } /* while (!(done)) */e     /*  * shutdown listener sockett  */t   main_sys_status = sys$qiow(e( 		listener_flag,		/* event flag		    	*/' 		listener_channel,	/* i/o channel			*/E 		IO$_DEACCESS|IO$M_SHUTDOWN,a 					/* i/o function code		*/o* 		&listener_iosb,		/* i/o status block		*/! 		0,			/* ast service routine		*/i 		0,			/* ast parameter		*/h 		0,0,0,			/* p1 - p3			*/1 		TCPIP$C_DSC_ALL,	/* p4 - discard all packets	*/  		0,0);			/* p5 - p6			*/a  & if ( main_sys_status & STS$M_SUCCESS )+     main_sys_status = listener_iosb.status;n     else     {hI     printf("QIO DEACCESS|SHUTDOWN of listener channel device failed.\n");d     exit( main_sys_status );     }e) if ( !(main_sys_status & STS$M_SUCCESS) )      {m9     printf( "Failed to shutdown listener connection\n" );e     exit( main_sys_status );     }n& printf("Listener socket Shutdown.\n");4 fprintf(message_file,"Listener socket Shutdown.\n");     /*#  * close and delete listener socket   */d   main_sys_status = sys$qiow(L$ 		listener_flag,		/* event flag			*/' 		listener_channel,	/* i/o channel			*/ ) 		IO$_DEACCESS,		/* i/o function code		*/o* 		&listener_iosb,		/* i/o status block		*/! 		0,			/* ast service routine		*/l 		0,			/* ast parameter		*/l  		0,0,0,0,0,0);		/* p1 - p6			*/  & if ( main_sys_status & STS$M_SUCCESS )+     main_sys_status = listener_iosb.status;s     else     {o@     printf("QIO DEACCESS of listener channel device failed.\n");     exit( main_sys_status );     }0) if ( !(main_sys_status & STS$M_SUCCESS) )n     {>=     printf( "Failed to close and delete listener socket\n" );F     exit( main_sys_status );     } 0 printf("Listener socket Closed and Deleted.\n");> fprintf(message_file,"Listener socket Closed and Deleted.\n");   /*  *  Deassign Listener Channel7  */    main_sys_status = sys$dassgn( ' 		listener_channel);	/* i/o channel		*/t  ( if ( !(main_sys_status & STS$M_SUCCESS))     {o5     printf("Failed to Deassign Listener Channel.\n");e     exit( main_sys_status );     }n  ) printf("Listener Channel Deassigned.\n");d7 fprintf(message_file,"Listener Channel Deassigned.\n");a  2 fprintf(message_file, "Program Shutting Down.\n"); fclose(message_file);    }t    ' --------------2CCFD42967D803AEEACC54F--,   ------------------------------  % Date: Sat, 22 Dec 2001 09:32:05 -0500 . From: Lyndon Bartels <lbartels@pressenter.com>( Subject: Re: QIOs, ASTs, and Event Flags- Message-ID: <3C245315.DC844DC@pressenter.com>h    I have another quick question...  E I'm a bit confused by all the references to variables especially when  they're passed to routines...o  " Could somebody explain that to me?  1 int a; 	/* it's an interger variable called "a"*/.G int *b;		/* this is a pointer to an interger. the pointer is called "b"m */    C a = 4;		/* that's giving the integer variable "a" the value of 4 */e  D Stuff like this.... It's gets more confusing beyond this. Especially@ when you start passing pointers into functions. And how are they! referenced inside the function...h    E I *think* I've got it mostly figured out... but without a teacher for.# this student to ask.... it's hard. -  
 Thanks again,r   Lyndon   -- lG My opinions are mine and mine alone. They seldom align with those of myh	 employer.u    H The only good thing about putting the cart before the horse is you don't have to look at the horse's butt.   ------------------------------  % Date: Sat, 22 Dec 2001 16:28:33 +0100c1 From: John McLean <mcleanj@swissonline.delete.ch>p( Subject: Re: QIOs, ASTs, and Event Flags5 Message-ID: <3C24A6A1.C78B25E8@swissonline.delete.ch>    Lyndon Bartels wrote:. > " > I have another quick question... > G > I'm a bit confused by all the references to variables especially whenr > they're passed to routines...  > $ > Could somebody explain that to me? > 3 > int a;  /* it's an interger variable called "a"*/	K > int *b; /* this is a pointer to an interger. the pointer is called "b" */s > M > a = 4;          /* that's giving the integer variable "a" the value of 4 */o > F > Stuff like this.... It's gets more confusing beyond this. EspeciallyB > when you start passing pointers into functions. And how are they# > referenced inside the function...u > G > I *think* I've got it mostly figured out... but without a teacher ford$ > this student to ask.... it's hard.    D I'm a bit rusty with this but let me try explaining it this way ....  E FORTRAN is a pass-by-reference language.  You call a subroutine usingeC some parameters and underneath you have passed the address of thoseeD variables.  You change a value in the subroutine and it gets changedG back in the calling routine because we are dealing with the same memory 	 location.   > C is a pass-by-value language.  You call a function using someH parameters and all you have passed is the current value of each of those? parameters.   The mechanism of getting them into the routine as ? variables simply looks at the pseudo-parameters in the functionrD definition and assigns to each of them, the values of the parametersE used to call the routine.  Working this way, a change of value in then@ function will NOT mean a change of value in the calling routine.  - Each method has advantages and disadvantages.t  F Now if you want to change the way things are done, in Fortran you needH to use %VAL(X) to get the value passed.  (It's rarely done but sometimesH very useful.)  In C you need to pass pointers if you want the address to! be available in the new function.t  C In both languages (in fact all languages) a function has a starting*G location in memory.  Because it has a location you can obtain the valueeG of the location and pass it around just like any other variable.  (I'vetF done this when the function to be executed was different for different2 types of data items.  The coding was very simple.)     Has that helped ??   John McLeano   ------------------------------    Date: 22 Dec 2001 05:53:09 -0800) From: P.Young@unsw.EDU.AU (Patrick Young)o( Subject: Re: Strange quorum disk problem; Message-ID: <55f85d77.0112220553.cf865e@posting.google.com>   W Alan Greig <a.greig@virgin.net> wrote in message news:<3C23C87D.D5551501@virgin.net>... D > Did you tune the account BACKUP runs under after two weeks? BACKUP  D Not as far as I know - I did not change anything. No autogen either.  D > DEFAULT's quotas is far less likely to cause quorum glitches IIRC.  E I won't bet anything on this one. Making BACKUP somehow not cause the	B problem is not a solution for me. Just makes some fodder for those> "PC" folks when the system is under full load next session :=)  C As always with OpenVMS, It works _every time_, and properly, or I'mi not interested./   It is indeed a tough one.l   ------------------------------  ! Date: Sat, 22 Dec 01 10:42:21 GMT	 From: jmfbahciv@aol.comt@ Subject: Re: VMS missing features (was how to do deamons on VMS)+ Message-ID: <a01vd3$sbe$7@bob.news.rcn.net>a  ? In article <3C23ED0A.C3CFD23A@gce.com>, gce <ge@gce.com> wrote:r >  >t >Paul Repacholi wrote: >> e >> gce <ge@gce.com> writes:t >> vI >> > I believe that some VERY late RSX11M or maybe just M+ releases wouldyH >> > accept decimal version numbers. For most of their history they did  not. >> oH >> Micro RSX and POX started that cruft. It was an option though, so it  could	
 >> be canned.o >>  K >> > The very earliest pdp10 systems had no highseg hardware and I believe x just6 >> > handed out memory as a user process asked for it. >> o= >> The 10s all had 2 seg or better, it was the 6 that didn't.* >> n3 >Nope. I USED a pdp10 back in 1970 that did not at o  >first have it. Highseg hardware6 >was added late that year but the machine had been in  >use for some time without it. s  9 Can you describe this highseg hardware?  Not at the bitsyl= level but at a level where some of the words used would twang_ my memory cells?     /BAH  ' Subtract a hundred and four for e-mail.n   ------------------------------  % Date: Sat, 22 Dec 2001 10:37:41 +0100	* From: dwparsons@t-online.de (Dave Parsons)O Subject: Re: [anounce] Sanity Kit for Compaq C++ V6.5 for OpenVMS Alpha systemstP Message-ID: <Ej0w7lFo08Zw-pn2-WKc0txeOFcWG@jupiter.dwparsons.dialin.t-online.de>  K On Fri, 21 Dec 2001 22:10:27, "Kenneth Block" <krblock@computer.org> wrote:e  L > The sanity kit for Compaq C++ V6.5 for OpenVMS Alpha field test kit is now > available. > J > The kit can be downloaded by pointing your browser to the URL below. YouF > will be asked to accept the license agreement and then will be givenJ > instructions to download the kit. If you would like to help us test thisK > product and do not have a valid product authorization key (PAK) to invokenE > the product please contact us immediately at field.test@compaq.com.c > J > The information contained in this kit is confidential and proprietary toN > Compaq, subject to the terms and conditions of your Agreement. This softwareL > has been made available to you for your internal use only. Please rememberL > that Compaq makes no warranties regarding the capability or performance of) > this software. Further, Compaq warrants- > L > and represents that this software is field-test quality software and makesJ > it available to you "AS IS". This software may impact the functioning of6 > your system(s) and thus, should be used accordingly. > 
 > KIT URL: > H > <ftp://ftp.compaq.com/pub/products/C-CXX/OpenVMS/cxx/beta/ftindex.htm> >  > FIELD TEST SCHEDULE: > L > Compaq C++ V6.5 for OpenVMS Alpha is currently scheduled for an eight-weekI > field test. The following dates are accurate but are subject to change:  > ' > Start of field test November 09, 2001l >   > Field Test 2 December 10, 2001 >  > Sanity December 21, 2001 > $ > End of field test January 04, 2002 >   E That's doesn't give much time for testing. Does it expire on Jan 4th?a" Also, can it coexist with Cxx 6.2?   -- a Dave   ------------------------------   End of INFO-VAX 2001.709 ************************