1 INFO-VAX	Sun, 23 Dec 2001	Volume 2001 : Issue 710       Contents:  Re: "You must think in Russian." Re: 100% FREE SPAM  2891 Re: 100% FREE SPAM  2891 Re: 100% FREE SPAM  2891 Re: 100% FREE SPAM 2891 > Re: Buffer Overflows - again Was: (Re: Congratulations for the> Re: Buffer Overflows - again Was: (Re: Congratulations for the> Re: Buffer Overflows - again Was: (Re: Congratulations for the> Re: Buffer Overflows - again Was: (Re: Congratulations for the> Re: Buffer Overflows - again Was: (Re: Congratulations for the> Re: Buffer Overflows - again Was: (Re: Congratulations for the> Re: Buffer Overflows - again Was: (Re: Congratulations for the> Re: Buffer Overflows - again Was: (Re: Congratulations for theJ 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 sea2 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 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: 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 season4 Re: DDS4 (20/40 GB) tape drives in a Alphaserver 8001 Re: historical evidence of what went wrong at DEC 3 How can I receive OPCOM messages in another nodes ? 7 Re: How can I receive OPCOM messages in another nodes ? 0 Re: HP admits it will kill VMS if merger suceeds0 Re: HP admits it will kill VMS if merger suceeds0 Re: HP admits it will kill VMS if merger suceeds& Job security for HP-Compaq merger team* Re: Job security for HP-Compaq merger team$ Re: Logging in on a Graphics console$ Re: Logging in on a Graphics console) More on marketing (was Re: HP admits ...) - Re: More on marketing (was Re: HP admits ...)  Need a Sydney PC doctor ? & Re: OPC$ENABLE_LOGFILE? and 7.3 - bug?( OpenVMS  vs. Unix  -  put up or shut up!, Re: OpenVMS  vs. Unix  -  put up or shut up!; 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 festP RE: Proof!  I can secure UNIX faster than VMS! Was: Congratulations for the festP Re: Proof!  I can secure UNIX faster than VMS! Was: Congratulations for the festP Re: Proof!  I can secure UNIX faster than VMS! Was: Congratulations for the festP 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: Congratulationsfor the f 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: 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 $ Re: VMSclusters and network switchesP Re: Why would one want a colon in a logical name? (Re: TOPS residuals (was: RE: * Re: Windows XP, biggest security hole yet.  F ----------------------------------------------------------------------  % Date: Sat, 22 Dec 2001 20:58:43 +0100 ( From: Paul Sture <paul.sture@bluewin.ch>) Subject: Re: "You must think in Russian." - Message-ID: <VA.000004fb.01a177fe@bluewin.ch>   J In article <o5NRTLQRo7MJ@eisner.encompasserve.org>, Larry Kilgallen wrote:o > In article <20011221191738.R90403-100000@server2.cs.scranton.edu>, Bill Gunshannon <bill@cs.uofs.edu> writes: * > > On 20 Dec 2001, Larry Kilgallen wrote: > > d > >> In article <3C22AB3A.BEFA79CB@cablespeed.com>, Chuck McCrobie <mccrobie@cablespeed.com> writes:F > >> > Wow!  I must be the only one who doesn't have a symbol for "set > >> > default". > >> > >> You are not.  > >> > > F > > This may come as a complete surprise to many people here, but evenE > > though I have more experience and feel much more comfortable with F > > Unix style commands, I also do not have a symbol for "set default"B > > or any other VMS command and agree that it is a very bad idea. > E > Please don't presume that we make assumptions about your habits :-)  > B > My own reasoning, now that you bring it up, is that I want to be- > fully functional on someone else's machine.   G My reasoning too, dating back to times when I was frequently working at  customer sites.   ' > The only exception I tend to make is:  > ! >  TECO == "$TECO TECO32 /SCROLL"  > > > since I don't know of a way to achieve /SCROLL with just the7 > EDIT/TECO command.  (Yes, DEFINE TEC$INIT 128 works.)  >    Similarly I might have:   A  $ DELETE /SYMBOL /GLOBAL /ALL ! Avoid SYLOGIN DCL customizations   $ DEFINE EVE$KEYPAD EDT   J and in days past, to avoid heavily customized EDT startup files (I've seen some really weird ones):  A  $ EDT == EDIT /EDT /NOCOMMAND ! Avoid customer EDT startup files   I When dealing with clustered systems, I add a combination of node name and J username to the prompt, with the node name for DECTerm icon and title bar, if applicable. ___ 
 Paul Sture Switzerland    ------------------------------  % Date: Sat, 22 Dec 2001 20:36:08 +0100 1 From: John McLean <mcleanj@swissonline.delete.ch> ! Subject: Re: 100% FREE SPAM  2891 5 Message-ID: <3C24E0A8.C4B1F300@swissonline.delete.ch>    "Terry C. Shannon" wrote:  > @ > "John McLean" <mcleanj@swissonline.delete.ch> wrote in message1 > news:3C24C001.5FBB70DC@swissonline.delete.ch...  > >  > >  > > "Terry C. Shannon" wrote:  > > > 6 > > > As per SpamCop, abuse@casema.nl for followups... > > > + > > > <evxsqn@hotmail.com> wrote in message 4 > > > news:dF2V7.14961$TJ5.1410@castor.casema.net...# > > > > http://home.wanadoo.nl/cap/  > > > > 100% FREE SEX MOVIES! E > > > > luibmgpqsmfiliudfrezdpljosxnrdwqoztomhkripyroknhyqloefqvzbhti  > > > >  > >  > > Note theJ > > "luibmgpqsmfiliudfrezdpljosxnrdwqoztomhkripyroknhyqloefqvzbhti".  ThatF > > has just has to be Welsh - the country that gave us the village of? > > Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.  > >  > J > 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?    @ Yea, verily.  'Tis now know by the much less interesting name ofC Llanfair P G and is located on the Isle of Anglesey, near the Menai  Bridge in north Wales.  H I believe that repainting the name at the local train station was ratherA a chore.  Probably a bit like repainting the Brooklyn Bridge  ;-)      John   ------------------------------  % Date: Sat, 22 Dec 2001 21:32:05 +0100 ( From: Paul Sture <paul.sture@bluewin.ch>! Subject: Re: 100% FREE SPAM  2891 - Message-ID: <VA.000004fd.01c00551@bluewin.ch>   H In article <_n3V7.26181$Sj1.12873411@typhoon.ne.mediaone.net>, Terry C.  Shannon wrote:@ > "John McLean" <mcleanj@swissonline.delete.ch> wrote in message1 > news:3C24C001.5FBB70DC@swissonline.delete.ch...  > >  > >  > > "Terry C. Shannon" wrote:  > > > 6 > > > As per SpamCop, abuse@casema.nl for followups... > > > + > > > <evxsqn@hotmail.com> wrote in message 4 > > > news:dF2V7.14961$TJ5.1410@castor.casema.net...# > > > > http://home.wanadoo.nl/cap/  > > > > 100% FREE SEX MOVIES! E > > > > luibmgpqsmfiliudfrezdpljosxnrdwqoztomhkripyroknhyqloefqvzbhti  > > > >  > >  > > Note theJ > > "luibmgpqsmfiliudfrezdpljosxnrdwqoztomhkripyroknhyqloefqvzbhti".  ThatF > > has just has to be Welsh - the country that gave us the village of? > > Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch.  > >  > J > 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? >  Llanfair PG  ___ 
 Paul Sture Switzerland    ------------------------------  # Date: Sat, 22 Dec 2001 20:06:40 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>! Subject: Re: 100% FREE SPAM  2891 > Message-ID: <kJ5V7.26706$Sj1.12961711@typhoon.ne.mediaone.net>  > "John McLean" <mcleanj@swissonline.delete.ch> wrote in message/ news:3C24E0A8.C4B1F300@swissonline.delete.ch...  > J > I believe that repainting the name at the local train station was ratherC > a chore.  Probably a bit like repainting the Brooklyn Bridge  ;-)  >   # Wait a minute... REPAINTED? When???   K I just bought that bridge from Scott McNealy. The condition of the paint is 
 terrible! ;-}    ------------------------------  % Date: Sat, 22 Dec 2001 20:10:28 -0500   From: John Santos <JOHN@egh.com>  Subject: Re: 100% FREE SPAM 28916 Message-ID: <1011222200802.59837E-100000@Ives.egh.com>  , On Sat, 22 Dec 2001, Terry C. Shannon wrote:   > @ > "John McLean" <mcleanj@swissonline.delete.ch> wrote in message1 > news:3C24E0A8.C4B1F300@swissonline.delete.ch...  > > L > > I believe that repainting the name at the local train station was ratherE > > a chore.  Probably a bit like repainting the Brooklyn Bridge  ;-)  > >  > % > Wait a minute... REPAINTED? When???  > M > I just bought that bridge from Scott McNealy. The condition of the paint is  > terrible! ;-}   C Get your money back.  You have a right to fresh paint.  Now, I have D a bridge in the S.F. area with a fine fresh coat of paint.  In fact,D I have a team that does nothing but paint the bridge.  When they getC to the end, they start over from the beginning.  Proper maintenance @ is key.  Contact me offline - I can quote you a very nice price.   --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------   Date: 22 Dec 2001 22:01:37 GMT) From: leslie@clio.rice.edu (Jerry Leslie) G Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the ' Message-ID: <a02vs1$l64$1@joe.rice.edu>   , Mark Crispin (mrc@CAC.Washington.EDU) wrote:. : My consulting rates start at $10,000/week...  / Damn, why are you wasting time in this forum ?    : We'd forgive you if you had to go make a buck, really. ;-)  4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------  % Date: Sat, 22 Dec 2001 14:56:58 -0800 + From: Mark Crispin <MRC@CAC.Washington.EDU> G Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the N Message-ID: <Pine.WNT.4.50.0112221446340.1372-100000@Shimo-Tomobiki.Panda.COM>  # On 22 Dec 2001, Jerry Leslie wrote: 0 > : My consulting rates start at $10,000/week...0 > Damn, why are you wasting time in this forum ?  E This is entertainment.  There's a lot of lurkers rolling on the floor G laughing at the notion that anyone could consider VMS superior to UNIX.   < > We'd forgive you if you had to go make a buck, really. ;-)   Fortunately, I don't.   
 -- Mark --   http://staff.washington.edu/mrc F Science does not emerge from voting, party politics, or public debate.   ------------------------------    Date: 22 Dec 2001 17:36:09 -0800( From: bob@instantwhip.com (Bob Ceculski)G Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the = Message-ID: <d7791aa1.0112221736.17bf2a92@posting.google.com>    Mark Crispin <MRC@CAC.Washington.EDU> wrote in message news:<Pine.WNT.4.50.0112221446340.1372-100000@Shimo-Tomobiki.Panda.COM>... % > On 22 Dec 2001, Jerry Leslie wrote: 2 > > : My consulting rates start at $10,000/week...2 > > Damn, why are you wasting time in this forum ? > G > This is entertainment.  There's a lot of lurkers rolling on the floor I > laughing at the notion that anyone could consider VMS superior to UNIX.  > > > > We'd forgive you if you had to go make a buck, really. ;-) >  > Fortunately, I don't.  >  > -- Mark -- > ! > http://staff.washington.edu/mrc H > Science does not emerge from voting, party politics, or public debate.  C You don't really believe that, do you?  From what is on this board, 
 you have aC grudge w/dec, but don't let that make you look foolish ... the only 	 unix that B can even run in the same room as vms is dec unix (tru64), and even	 w/all the C vms clustering logic they could put into it, it still ain't vms ...  vms was C designed for clustering, and nothing else can come close ... as for  reliability @ lets just look who wins uptime sponsored tests year to year, VMS (99.9%) ... @ security, the defense dept. can answer that one (VMS), and thank
 goodness they F aren't as stupid as other IT mgrs (except the Navy ;) ) ... the jstars program F picked VMS because of galaxy ... do you know what a vms galaxy can do, and yourE pitiful little unix has nothing that can compare ... even networking,  I willE put up a Decnet Phase IV over IP network that can be run all over the  world C thru dsl, cable, frame, sattelite, you name it, and offer a class b  network D that spans the globe but looks and feels like everyone is on a local lan ... E copies and EDT right from my local account onto any box in the world,  wihoutE even a set host (login), and add DQS (Digital Que Services) and I can  offer D ques to a box in Shanghai on an Alpha/Vax in Pittsburgh ... complete w/firewalls A in an instant ... and this is touching the tip of the iceburg ... > decnet copies are a lot more reliable than stupid ftp and file corruption ... w/vms nothingE is impossible, and it is alot easier than unix(gag!) ... and lets not 
 even startE w/security!  You may have a tip on a vms cert bug #4, but I will take  that anyE day compared to cert #9999999 on unix and windoze!  The last cert vms  adv. wasF for decwindows, and that you had to have access already to exploit it, and weC don't even run decwindows, let alone over the internet!  I think it  has beenF covered enough on the overflow postings how vms is written compared to unixA and NT, and I think VMS will always be the clear winner on buffer 
 overflows ... D there are a million enemy hackers just waiting for a war so they can begin toE exploit all the unknown unix and nt bugs they have yet to unleash ... 	 and I for F one will be glad I am on VMS when it happens!  VMS has been around 20+ years,D and by the way things are going w/nt unix, it will be around another	 20 years! @ VMS withstood the 9/11 disaster ... only God can stop a properly
 configuredF VMS cluster!  And I can out do any unix solution on a cost basis also!  I thinkE you know the power of VMS, so don't let a little grudge make you look  foolish!   ------------------------------    Date: 22 Dec 2001 18:01:38 -0800( From: bob@instantwhip.com (Bob Ceculski)G Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the = Message-ID: <d7791aa1.0112221801.100da3e5@posting.google.com>    Mark Crispin <MRC@CAC.Washington.EDU> wrote in message news:<Pine.WNT.4.50.0112221446340.1372-100000@Shimo-Tomobiki.Panda.COM>... % > On 22 Dec 2001, Jerry Leslie wrote:M2 > > : My consulting rates start at $10,000/week...2 > > Damn, why are you wasting time in this forum ? > G > This is entertainment.  There's a lot of lurkers rolling on the floorsI > laughing at the notion that anyone could consider VMS superior to UNIX.s > > > > We'd forgive you if you had to go make a buck, really. ;-) >  > Fortunately, I don't.e >  > -- Mark -- > ! > http://staff.washington.edu/mrctH > Science does not emerge from voting, party politics, or public debate.  G and there's more ... you want the fastest java virtual machine ... VMS!oK you want unix apps (Apache) ... VMS!  any unix app can be ported to vms ...s9 and you don't need a 512 cpu ultradudsparc box to run it! I Alpha OpenVMS is tops, and if Intel and the Alpha team do their job right : redesigning Itanium, it will continue to be number one ...I Why does Intel for the past ten years use OpenVMS is their chip fab linesa to make pentiums and itaniums?   ------------------------------    Date: 22 Dec 2001 18:09:26 -0800( From: bob@instantwhip.com (Bob Ceculski)G Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the = Message-ID: <d7791aa1.0112221809.280a3269@posting.google.com>o   Mark Crispin <MRC@CAC.Washington.EDU> wrote in message news:<Pine.WNT.4.50.0112221446340.1372-100000@Shimo-Tomobiki.Panda.COM>...g% > On 22 Dec 2001, Jerry Leslie wrote: 2 > > : My consulting rates start at $10,000/week...2 > > Damn, why are you wasting time in this forum ? > G > This is entertainment.  There's a lot of lurkers rolling on the flooraI > laughing at the notion that anyone could consider VMS superior to UNIX.n > > > > We'd forgive you if you had to go make a buck, really. ;-) >  > Fortunately, I don't.g >  > -- Mark -- > ! > http://staff.washington.edu/mrcoH > Science does not emerge from voting, party politics, or public debate.  N Why don't you tell us why unix is better than VMS?  All you unix people alwaysM say it is better, but never tell anyone why?  It sure hasn't beat VMS in headeN to head overall competitions (VMS 99.9%) ... its file system sure doesn't beatO RMS ... if you pull the plug on the box, your in trouble ... clustering, forget N about it ... I had a nt/unix guy come in once for some nt troubleshooting, andL after a little tour he fell in love w/vms ... his only complaint, only 8 dirO levels, but I showed him work arounds, and he found that acceptable ... so whateH makes unix better than vms?  Can someone enlighten us spoiled vms users?   ------------------------------  # Date: Sun, 23 Dec 2001 02:08:19 GMTw' From: bad bob <sfmc68@bellatlantic.net>mG Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the 0 Message-ID: <3C253E0F.AC7809C5@bellatlantic.net>   Bob Ceculski wrote:f >  > Mark Crispin <MRC@CAC.Washington.EDU> wrote in message news:<Pine.WNT.4.50.0112221446340.1372-100000@Shimo-Tomobiki.Panda.COM>...s' > > On 22 Dec 2001, Jerry Leslie wrote: 4 > > > : My consulting rates start at $10,000/week...4 > > > Damn, why are you wasting time in this forum ? > > I > > This is entertainment.  There's a lot of lurkers rolling on the floortK > > laughing at the notion that anyone could consider VMS superior to UNIX.s > > @ > > > We'd forgive you if you had to go make a buck, really. ;-) > >e > > Fortunately, I don't.e > >l > > -- Mark -- > >s# > > http://staff.washington.edu/mrcrJ > > Science does not emerge from voting, party politics, or public debate. > E > You don't really believe that, do you?  From what is on this board,  > you have aE > grudge w/dec, but don't let that make you look foolish ... the onlyt > unix thatWD > can even run in the same room as vms is dec unix (tru64), and even > w/all thesE > vms clustering logic they could put into it, it still ain't vms ...a	 > vms was E > designed for clustering, and nothing else can come close ... as for 
 > reliabilityoB > lets just look who wins uptime sponsored tests year to year, VMS
 > (99.9%) ...gB > security, the defense dept. can answer that one (VMS), and thank > goodness theyuH > aren't as stupid as other IT mgrs (except the Navy ;) ) ... the jstars	 > programiH > picked VMS because of galaxy ... do you know what a vms galaxy can do,
 > and yourG > pitiful little unix has nothing that can compare ... even networking,  > I willG > put up a Decnet Phase IV over IP network that can be run all over the  > worldeE > thru dsl, cable, frame, sattelite, you name it, and offer a class bI	 > networknF > that spans the globe but looks and feels like everyone is on a local	 > lan ...hG > copies and EDT right from my local account onto any box in the world,  > wihoutG > even a set host (login), and add DQS (Digital Que Services) and I can- > offer-F > ques to a box in Shanghai on an Alpha/Vax in Pittsburgh ... complete
 > w/firewallslC > in an instant ... and this is touching the tip of the iceburg ...a@ > decnet copies are a lot more reliable than stupid ftp and file > corruption ... w/vms nothingG > is impossible, and it is alot easier than unix(gag!) ... and lets not0 > even startG > w/security!  You may have a tip on a vms cert bug #4, but I will take 
 > that anyG > day compared to cert #9999999 on unix and windoze!  The last cert vms>
 > adv. wasH > for decwindows, and that you had to have access already to exploit it, > and weE > don't even run decwindows, let alone over the internet!  I think it 
 > has beenH > covered enough on the overflow postings how vms is written compared to > unixC > and NT, and I think VMS will always be the clear winner on bufferx > overflows ...IF > there are a million enemy hackers just waiting for a war so they can
 > begin toG > exploit all the unknown unix and nt bugs they have yet to unleash ...u > and I for H > one will be glad I am on VMS when it happens!  VMS has been around 20+ > years,F > and by the way things are going w/nt unix, it will be around another > 20 years! B > VMS withstood the 9/11 disaster ... only God can stop a properly > configuredH > VMS cluster!  And I can out do any unix solution on a cost basis also!
 >  I thinkG > you know the power of VMS, so don't let a little grudge make you look 
 > foolish! Bob,> you do not know what you are talking about in general, and in E particular with VMS and security.  Being uninformed, you are spoutingED the same drivel that MSdenizens spout.  It is a manifestation of theC old iranian proverb: a lie told twice becomes truth.  I am not sureAF which factoid you are trying to sell as truth: that VMS will be aroundG for another 20 years. that vms is secure.  that vms is more secure thanhF unix.  that vms is more secure than NT.  In your fantasy world all of A these statements might seem to be true. However, in the world of aG reality, none of your statements are true at this time. They range froml) speculative to absurd. but you know that. D One question: Do you live under a bridge?  So that you get the clue," you do seem to act like a troll... bobl   ------------------------------  # Date: Sun, 23 Dec 2001 02:36:41 GMTi4 From: "Terry C. Shannon" <terryshannon@mediaone.net>G Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the.> Message-ID: <ZqbV7.27162$Sj1.13138766@typhoon.ne.mediaone.net>  5 "Bob Ceculski" <bob@instantwhip.com> wrote in messaget7 news:d7791aa1.0112221809.280a3269@posting.google.com... 8 > Mark Crispin <MRC@CAC.Washington.EDU> wrote in messageJ news:<Pine.WNT.4.50.0112221446340.1372-100000@Shimo-Tomobiki.Panda.COM>...' > > On 22 Dec 2001, Jerry Leslie wrote:h4 > > > : My consulting rates start at $10,000/week...4 > > > Damn, why are you wasting time in this forum ? > >rI > > This is entertainment.  There's a lot of lurkers rolling on the floor K > > laughing at the notion that anyone could consider VMS superior to UNIX.  > > @ > > > We'd forgive you if you had to go make a buck, really. ;-) > >l > > Fortunately, I don't.c > >s > > -- Mark -- > > # > > http://staff.washington.edu/mrclJ > > Science does not emerge from voting, party politics, or public debate. >tI > Why don't you tell us why unix is better than VMS?  All you unix peoplet alwaysJ > say it is better, but never tell anyone why?  It sure hasn't beat VMS in headK > to head overall competitions (VMS 99.9%) ... its file system sure doesn'tc beatJ > RMS ... if you pull the plug on the box, your in trouble ... clustering, forgetL > about it ... I had a nt/unix guy come in once for some nt troubleshooting, andrJ > after a little tour he fell in love w/vms ... his only complaint, only 8 dir2L > levels, but I showed him work arounds, and he found that acceptable ... so whatJ > makes unix better than vms?  Can someone enlighten us spoiled vms users?  K I guess it pretty much depends on one's individual preferences. Some prefert2 Unix, some prefer VMS. And others prefer TOPS. ;-}   ------------------------------  # Date: Sun, 23 Dec 2001 03:32:54 GMTd* From: "Bill Todd" <billtodd@metrocast.net>G Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for theyB Message-ID: <GfcV7.363388$8q.31551087@bin2.nnrp.aus1.giganews.com>  5 "Bob Ceculski" <bob@instantwhip.com> wrote in messageh7 news:d7791aa1.0112221809.280a3269@posting.google.com...r   ...i  I > Why don't you tell us why unix is better than VMS?  All you unix peoplen alwaysJ > say it is better, but never tell anyone why?  It sure hasn't beat VMS in headK > to head overall competitions (VMS 99.9%) ... its file system sure doesn'ta beatJ > RMS ... if you pull the plug on the box, your in trouble ... clustering, forgetL > about it ... I had a nt/unix guy come in once for some nt troubleshooting, andeJ > after a little tour he fell in love w/vms ... his only complaint, only 8 dir L > levels, but I showed him work arounds, and he found that acceptable ... so whatJ > makes unix better than vms?  Can someone enlighten us spoiled vms users?  L Actually, I've already enlightened c.o.v. more than once that VMS's supposedB advantages in most of the above areas are either illusory (in fileI management, for example, it now lags Unix in some ways) or at least underaL heavy attack (Unix is catching up, and has at least functional equivalence).L But since you clearly didn't listen before (I've often suspected that you'reC really a write-only 'bot) I'm not going to bother repeating myself.    - bill   ------------------------------    Date: 22 Dec 2001 13:22:52 -0800( From: bob@instantwhip.com (Bob Ceculski)S Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the festive seay= Message-ID: <d7791aa1.0112221322.7c4f00c1@posting.google.com>a   Mark Crispin <mrc@CAC.Washington.EDU> wrote in message news:<Pine.NXT.4.50.0112221004440.7962-100000@Tomobiki-Cho.CAC.Washington.EDU>...% > On 22 Dec 2001, Bob Ceculski wrote:t> > > by the way, when are you going to give us a decent version > > of pine for vms? > D > Never.  There is no funding for development work on dead operatingL > 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. > H > We didn't do the VMS port of Pine.  I know that a school in Israel didL > one, but they are probably no longer using VMS since we haven't heard fromK > them in ages.  There was also a company did one, but it no longer exists.e > J > Now, if you'd like to pay me to do it, we can talk.  My consulting ratesL > start at $10,000/week.  Prices higher for clients in California, New York, > Massachusetts, and DC. >  > -- Mark -- > ! > http://staff.washington.edu/mrcoH > Science does not emerge from voting, party politics, or public debate.  L the only dead OS right now is windoze XP ... goto to the inquirer or read myM post here about the FBI warning ... VMS is hardly dead, esp. in the military,eM just lookup at the next jstars plane overhead, and with windoze unix security.P bugs out every other day, VMS will be around another 20 years ... VMS on ItaniumL or VMS on EV8 alpha, it will be around ... any one who deviates will be shutN down one day by enemy hackers just waiting w/million other attacks for windoze and unix and linux!    ------------------------------   Date: 22 Dec 2001 21:59:38 GMT( From: peter@taronga.com (Peter da Silva)S Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the festive seas2 Message-ID: <a02voa$2qbf$1@citadel.in.taronga.com>  = In article <d7791aa1.0112211737.35b11ad5@posting.google.com>,-) Bob Ceculski <bob@instantwhip.com> wrote:-N >are you saying you can overflow buffers on vms and create privs you never hadK >to begin with?  this isn't windoze you know, you need privs to do anythingb >on vms ....  I Sure. Here we go, let's say there's a buffer overflow in the mail server.PK I send you mail exploiting the buffer overflow bug, and have it spawn a DCL J session listening to TCP port 666. Then I connect with your server on portG 666. Now I've got all the privileges that mail server runs under, where + before I didn't even have a valid username!i   -- h@ Rev. Peter da Silva, ULC.	      "Cave cuniculos lagana ferentes"  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)l   ------------------------------   Date: 22 Dec 2001 21:55:03 GMT( From: peter@taronga.com (Peter da Silva)S Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the festive seaa2 Message-ID: <a02vfn$2q9a$1@citadel.in.taronga.com>  1 In article <3C235485.6DAE0096@trailing-edge.com>,n- Tim Shoppa  <shoppa@trailing-edge.com> wrote:iA >But write it over the stack (where a C program is likely to keep ? >all its local variables), and when you hit a return you can gorB >to any syscall you want with whatever parameters you want.  True,C >it's not easy to run code, but all you have to do is rename a file @ >or change a protection or set the setuid bit (Unix) or redefine6 >a logical (VMS) and the system can be made wide open.  J Pushing the address of "exec" with the arguments "/bin/sh" "sh" "-i" NULL, for example.   -- w@ Rev. Peter da Silva, ULC.	      "Cave cuniculos lagana ferentes"  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)e   ------------------------------  # Date: Sat, 22 Dec 2001 19:06:37 GMTt* From: "Bill Todd" <billtodd@metrocast.net>; Subject: Re: Compaq still tries to spin Alphacide both waysa> Message-ID: <1R4V7.254775$YD.19916242@news2.aus1.giganews.com>  ? "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messagea8 news:JG4V7.26540$Sj1.12923662@typhoon.ne.mediaone.net... > B > "Robert R Kircher, Jr." <rrkircher@hotmail.com> wrote in message' > news:a02ko4$hfp$1@bob.news.rcn.net...hC > > "Terry C. Shannon" <terryshannon@mediaone.net> wrote in message < > > news:Ym4V7.26477$Sj1.12912646@typhoon.ne.mediaone.net... > > > F > > > "Robert R Kircher, Jr." <rrkircher@hotmail.com> wrote in message+ > > > news:a02jku$dr3$1@bob.news.rcn.net...lH > > > > The Alpha chips fate was sealed the moment Digital was bought by	 > Compaq.m > > > >w > > > > Robn > > >n > > > In hindsight, absolutely.e > > >e > >tL > > I used to work with a company that was a dgital partner up until the buyH > > out.  We where told by our rep that the alpha didn't stand a chance. MayaJ > > have been his opinion at the time but I still think the writing was on the 	 > > wall.. > G > Well, it was definitely WRIT LARGE by the time August 19, 1999 rollediI > around. A shame that the Sculptor project was killed. That IMHO was the  > final nail in the coffin.d  L Funny, I don't recall such an observation from you at the time:  rather, youE were vigorously defending dropping NT on Alpha as a sensible businessiF decision that had absolutely nothing to do with the viability of Alpha itself.e  + Guess you didn't have good reading glasses.t   - bill   ------------------------------  # Date: Sat, 22 Dec 2001 19:09:24 GMTe* From: "Bill Todd" <billtodd@metrocast.net>; Subject: Re: Compaq still tries to spin Alphacide both wayst@ Message-ID: <ET4V7.83557$Zd.7918220@bin1.nnrp.aus1.giganews.com>  ? "Terry C. Shannon" <terryshannon@mediaone.net> wrote in message18 news:Ym4V7.26477$Sj1.12912646@typhoon.ne.mediaone.net... >nB > "Robert R Kircher, Jr." <rrkircher@hotmail.com> wrote in message' > news:a02jku$dr3$1@bob.news.rcn.net...2L > > The Alpha chips fate was sealed the moment Digital was bought by Compaq. > >. > > Robn >h > In hindsight, absolutely.s  J That's kind of difficult to assert given the CEO change Compaq underwent aF year after the acquisition.  Pfeiffer at least showed some significantL interest in Alpha, and seemed to be allowing moves to increase its exposure.  L Unless you take the view that the past couldn't have been any different than8 it was, in which case the observation loses all meaning.   - bill   ------------------------------  # Date: Sat, 22 Dec 2001 19:11:17 GMTl* From: "Bill Todd" <billtodd@metrocast.net>; Subject: Re: Compaq still tries to spin Alphacide both ways @ Message-ID: <pV4V7.83582$Zd.7919952@bin1.nnrp.aus1.giganews.com>  ? "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messagei8 news:Pj4V7.26464$Sj1.12910678@typhoon.ne.mediaone.net... >s? > "Dave Cherkus" <cherkus777@777unimaster.com> wrote in messagea. > news:Xns917F88CA63AFEidtoken@199.125.85.9...   ...-  E > > I thought that strategy was solid right up till the CPQ/HP merger  fiasco.l >)L > Looked to me like it might fly as well. Better than staying the course andL > spending more and more selling less and less until everything was spent on > selling nothing.  L But not better than getting off your duff and marketing your most profitableB product line so that the continuing expenditure would be more than
 justified.   - bill   ------------------------------  % Date: Sat, 22 Dec 2001 14:35:47 -0500 + From: "Main, Kerry" <Kerry.Main@compaq.com>r; Subject: RE: Compaq still tries to spin Alphacide both waysoT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4010D724C@kaoexc01.americas.cpqcorp.net>   Bill,,  E [following is a resend and update to something I sent earlier as must/G have happened on my email side as I had some home net probs and it doesp# not appear to have been sent .. km]'  E >>> Kerry Main floated this rationale the day of the announcement <<<a  ? >>> I'd like to think in some small part because I spread it to E comp.arch and comp.sys.intel and Intel was not amused - perhaps HP ass well)<<<  ? Perhaps I should be asking about what tea leaves you are using?.   :-)r  D Please try to refain from the master conspiracy theories you seem to like attributing to me.=20  G While I obviously can not talk publicly about everything (same goes foreF all other readers of this group who have to respect certain about someF topics of their own employers) - No one tells me what to say or not toE say in any of these newsgroups. I am sure the same goes for all other8* Compaq participants in this newsgroup. =20  H With respect to the quotes above. the real reality is that what I statedD in this newsgroup at that time is that future versions of IPF in the= post Madison timeframes would likely have an Alpha influence.m  B I have not changed my tune btw, so your strategy of trying to turnB different parties against one another to further your own personal: agenda and subsequent self-perceived influence is/was nil.  F For lack of a better name, I called it IPF-2 (or something like that).F The current roadmaps call it "Next Generation IPF" and shows the appox timeframe of 2005. Reference:uH http://www.compaq.com/hps/ipf-enterprise/openvms.html (Cust presentation	 slide 12);  F I have no idea how much or in what form it will take, but using IntelsD own press releases, it does not take a rocket scientist to determineH there will likely be a fair amount of Alpha design influence in the post 2005 timeframe.=20  F Since it is part of their core business, why is it that you find it soD hard to beleive that Intel may actually value a great deal the Alpha9 technology and world class design teams they acquired?=20   . Check out Intels recent public press releases:  E http://www.intel.com/pressroom/archive/releases/20010830corp_a.htm=20sD "Intel Appoints Four New Fellows, Names New Vice President" (All areE Compaq Alpha folks - check out the resumes of each of these folks and   look at what they are doing..km)  D http://www.intel.com/pressroom/kits/bios/dcasaletto.htm (new Head of Intel Arch Group)yG quote> "Daniel J. Casaletto is Vice President of the Intel ArchitectureoD Group and General Manager of the Massachusetts Microprocessor Design Center in Shrewsbruy, Mass..  B Most recently, Daniel J. Casaletto was Vice President of the Alpha= Development Group at Compaq Computer Corporation." <end quotef  D Does that future "influence" mean throwing away current IPF designs?4 Course not. The IPF architecture will simply evolve.  G Does that influence mean throwing away all previous knowledge of Alpha? H Course not. Just as Alpha evolved from EV4 to EV5 to EV56 to EV6 to EV67= to EV7.+ etc etc, so IPF will evolve over the next few years.g  F Timing ? Who knows what issues will arise between then and now, so anyH timeframes are estimates and your mileage may vary. That is no differentF than any other chip vendors prediction of future release timeframes as well.=20  D Sigh .. btw - Bill, Can you let us know how many other newgroups you plan to post this reply to ?   Regards,  
 Kerry Main Senior Consultantu Compaq Canada Corp.t Professional Services  Voice: 613-592-4660  Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----/ From: Bill Todd [mailto:billtodd@metrocast.net]o Sent: December 20, 2001 4:49 PMe To: Info-VAX@Mvb.Saic.Comk7 Subject: Compaq still tries to spin Alphacide both waysg    G Despite Compaq's public declarations of Alpha's inability to maintain ayB significant performance lead over The Good Ship Itanic, some pesky	 customers D still aren't convinced about the desirability of the migration.  But CompaqG has a story for them as well, just not a consistent one:  Itanic may bei abF pig, but the Alpha team will miraculously transform it into a pig with fliesy# (er, sorry, a pig *that* flies...).i  F Kerry Main floated this rationale the day of the announcement and MarkH Gorham tried to feed it to Alphaman a few days later, but it then seemed toF disappear (I'd like to think in some small part because I spread it toE comp.arch and comp.sys.intel and Intel was not amused - perhaps HP aso well).E But it's alive and well out in preferred-customer-persuasion land, asw thisH email I answered yesterday demonstrates.  JF may be right:  Compaq isn'tF much interested in new Alpha system business or in many small existingH customers, but cares enough about a few important current clients to say: whatever it takes to keep them on board the sinking liner.  B Anyway, you can be a fly on the wall listening in on our (slightly= expurgated, to remove identity clues and one private piece ofh information)) conversation, and conclude what you will:l    
 > Hi Bill, >n= > ... I told our Compaq account manager in no uncertain termspD > how I thought about the infamous Itanic move. Of course he replied thatD > everyone else was very happy etc. (specially management guys), and thatG > we were the only ones unhappy. That wasn't true of course, but hey hei is > a sales person.o ><H > But he was very quick to act, and today we had another guy who told usH > what is actually the case, and how it all came to this. He is a former2 > DEC support guy, and he was refreshingly honest.  D He may have believed what he said (a lot of people at Compaq seem to haveG swallowed the party line as gospel), but the information he imparted isWG dramatically inconsistent with the information I have received from EV8 H developers now at Intel - and on the subject at hand, I know whom I find more credible.   >nH > I told him again my vision on the Itanic (didn't differ very much fromG > your vision with regard to the technical side of things) and he couldo > understand it very well. > C > But then he gave us some more information about the whole matter.  >eD > First of all he said that the whole marketing presentation of this moveH > was done in good old Digital fashion, as stupid as it can be. As if we > didn't know. :-))l >cF > What happened was that the EV8 development team went to Capellas andH > said that without a lot more funding it would be impossible to keep up; > with the X86 class of processors (and possibly Itanium ?)l  H I very much doubt that any such mission to Capellas occurred - it soundsD much more like the spin Compaq tried to palm off as part of the June 25thD announcement that the decision had started with the Alpha engineers. They@ later amended this to saying that it originated with some of the *server*H (not processor) designers - and there's an interesting political tensionG between the two groups involving the migration of much of what had beent# server 'turf' onto the chip in EV7.t  D There was *no question whatsoever* in the minds of the EV8 team that theyH would extend, not simply maintain, Alpha's current performance advantage over Itanic.  G Keeping ahead of IA32 processors would have been more difficult but farj fromB impossible, at least for Intel variants (Hammer might be harder to match):GF EV7's on-chip memory control (with its dramatically improved bandwidth andnG latency) will hit the streets next year with nothing similar from Inteln onG any road map (32-bit *or* 64-bit), and while Intel will debut 2-way SMTM soonH in IA32 (again, nothing on any road map for IA64) EV8's 4-way SMT shouldD 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'sl bread-and-butter markets.    We are.B > speaking here in terms of raw processor speed of course, not the qualityoF > of the OS. Of course the intellectual capacity is there, but not the
 > funding.  ? The funding *was* there, until June 25th, to continue the Alpha, performance C road map that has been public for years and showed no sign of beingoG inadequate (or unduly expensive).  Again, I'm reasonably sure that yourc@ informant was feeding you misinformation, though not necessarily
 knowingly.  @  And indeed, the performance of the fastest X86 class processors@ > at the moment is about the same as that of the fastest present Alpha's.H > Only now we have 1 GHz Alpha's, I had expected them at least 1.5 yearsA > earlier. Development is slowing down, and so is the performanceb > advantage of the Alpha.   C If IA32 were truly Alpha's competition, that argument might have at  least2G some merit.  But if a 32-bit architecture were considered sufficient in: thatD market, there would have been absolutely no reason for Intel to haveE developed a 64-bit machine that shows no evidence that it will *ever*i comeH even close to catching up with IA32 on simple speed benchmarks (with theD possible exception of FP-style code, which is not the main source of Alphas income).   > C > It was the EV8 development team who suggested joining forces withn Intelm > to design a new processor.  ? No, it was not.  I don't know how tightly-knit the European DECs	 communityeH is, but if you know <name deleted> I think he may have additional insideC information from a source that I don't (he's another person who was G initially fed a load of crap but then discovered what it was from othery sources he trusted).  *  This processor is now known in the CompaqF > presentations as the Itanium 2, and apparently it has almost nothing in< > common with the present Itanium, but instead is EV8 based.  D More bullshit, I'm afraid.  This is another lie that Compaq tried to float B to make the decision easier to swallow, but it doesn't stand up to@ examination (nor, incidentally, do I believe you will find *any*
 indicationG from *Intel* that this is what's planned - so Compaq is asking for yourqA trust - hah! - while ignoring the signals from the architecture's  owner)..  D First of all, *if* Compaq recognized that Itanic was the disaster it appearszG to be and that Alpha technology would remain far superior, why on earth C wouldn't they have vigorously capitalized on this asset rather thana handedF it over to Intel supposedly so that Intel could rescue Itanic with it?F After all, if Itanic *wasn't* destined to change the 64-bit landscape, thenF Alpha would have remained as competitive (with any marketing) as ever, with8 increased leadership clearly visible in the near future.  G Second, I've received private confirmation from one of the transplanted.C Alpha designers that my guesstimate of 2006 as the earliest such anlE Alphabetized Itanic could appear is a good one, which puts it about 3o yearsvH behind the date when the same technology would have appeared in EV8.  SoE *even after having given the technology away* Compaq will now have to  wait 3E more years to make use of it than would have been the case if EV8 had  gone= ahead, while POWER4 reaps the rewards of lack of any high-end  competition F and Hammer may start grabbing large chunks of the mid-range-to-low-end market.   H Whatever Itanic will come after Madison is far more likely to be an EPICB architecture with Alpha-inspired tweaks than an Alpha architecture runningu the Itanic instruction set.B    TheF > instruction set will be different of course, but as I understand the0 > overall design will be very much like the EV8.  F One of Alpha's strengths was its instruction set, which was explicitlyG designed to allow performance enhancements.  The design behind Itanic's D instruction set was based on completely different (EPIC) assumptions whichtE are less amenable to using Alpha-style performance approaches even ifi theg( entire EPIC implementation is abandoned.    Why they still use thekE > infamous name Itanium for that new processor is unclear, but we allc2 > agreed that this again is very stupid marketing. >rB > The Alpha technology has not been sold to Intel, but it has beenC > licensed. The Itanium 2 / EV8 team hasn't moved, but are still atU their D > own desks at Compaq. The only difference is they have Intel badges now.7 > But what's in a badge as Shakespeare might have said.-  H It's not the badge, its the architecture.  Alpha is an eagle, and Itanic isG a pig.  Compaq has just given Intel the means to streamline the pig and  putyG wings on it, but in the end it's still a pig:  all instruction sets are-F *not* created equal (just look at IA32 for a cautionary example of how much1 more effort it takes to make a poor one perform).h   > F > So in essence your vision on the Itanium (1) is right, it is a piece ofD > shit Compaq agrees. In fact Dell has stopped selling Itanium based- > systems as I read in a newspaper over here.. >.; > Compaq however has so much confidence in the Itanium 2...t > (Don't publish this please,$* > don't know if this is official already).  E It sounds like the so-called 'golden blanket', and given that even if1 the2H mythical Itanium 2 does appear it won't be before 2006 this is just moreD smoke being blown to try to make an indefensible position palatable.  B It is possible that some of the on-chip memory and multi-processor supportuD could be grafted onto the McKinley/Madison core by 2005, and there's someD indication that this may be what you are referring to as 'Itanium 2' (i.e.,E a processor core with absolutely no Alpha technology in it, and henceh justF as much a pig as McKinley/Madison will be).  And while Compaq has beenG promoting the fiction that it might appear in 2004, again this does nott seemE to be consistent with private information from the transplanted Alphae team.o   >jG > It seems that at the Los Angeles presentation there were several very,G > important customers that were very unhappy with the way Capellas etc.eB > answered their questions. Only after these customers talked withH > technical staff they were satisfied that the Itanium move was ok. That6 > again proves how poor the marketing is in this case.  + No, it just proves how gullible people are.    > D > Compaq ... is visiting all important customers now to explain themG > what is happening. And sure enough there were other customers too whogF > were planning to leave Compaq because of the Itanium move. But after5 > this guy paid them a visit they changed their mind.   
 See above.   > ...  It seems to be sure nowE > that HP UX and Tru64 will be merged to one Unix, even if the mergernF > doesn't go ahead. The best of both (in Unix ?? :-)  ) will be in the neww > Unix.   A Except that it will be big-endian, so even if the amalgamation isn	 performedo= perfectly the little-endian Tru64 people will be faced with aa non-trivialdB port.  Not to mention that the HP/UX kernel is a large, antiquated	 monolith,t, which bodes poorly for its long-term future.  7 > So maybe things are not as gloomy as I (we?) thought.w    H Yeah.  Right.  Thus concludes another small chapter in Compaq's on-goingG soap opera.  If you know people who, for some reason, are still willing- toE trust Compaq's "This time for sure!" promises, you might want to giver them aC heads-up about this particular offensive (and 'offensive' certainlys seems G the proper term):  even Bullwinkle eventually realized that he needed a" newr hat.   - bill   ------------------------------   Date: 22 Dec 2001 21:59:29 GMT) From: wkb@freebie.xs4all.nl (Wilko Bulte)u; Subject: Re: Compaq still tries to spin Alphacide both ways3@ Message-ID: <3c250240$0$32595$e4fe514c@tyrannewsaurus.xs4all.nl>  l In <LcOU7.24471$Sj1.12315470@typhoon.ne.mediaone.net> "Terry C. Shannon" <terryshannon@mediaone.net> writes:    7 >"Wilko Bulte" <wkb@freebie.xs4all.nl> wrote in message ; >news:3c23ae8a$0$11266$e4fe514c@tyrannewsaurus.xs4all.nl... 9 >> In <yga1yhofxbz.fsf@severn.office.aol.com> Joel Gallunr% ><root@localhost.localdomain> writes:t >>. >> >nmm1@cus.cam.ac.uk (Nick Maclaren) writes: >>G >> >> Note that by "the EVx" I am also referring to chipsets and so on,:G >> >> without which the chip is useless and cannot support faster clockCE >> >> speeds even on the same chip - witness the 1 GHz Alpha and ES452 >> >> shambles.5 >>A >> >Do tell! I lived (still living it, actually) through the ES40 E >> >disaster, but don't have any experience with the ES45. The site In >>3 >> Which ES40 disaster? What is so bad about those?  >>  H >The ES40 motherboard and crossbar chipset would not support a 1GHz EV68M >upgrade. Not exactly a disaster, but I am sure it PO'd some customers. WhichuI >has not prevented the ES45 from being the most-popular platform in Alpha 	 >history.a  A Right, that is what I hear, they are moved into major accounts ina> substantial numbers. Somebody is destined to be PO'd anyway ;)   W/ --- |   / o / /_  _   		email: 	wilko@FreeBSD.org 1 |/|/ / / /(  (_)  Bulte		Arnhem, The Netherlands	t   ------------------------------  # Date: Sat, 22 Dec 2001 22:10:16 GMT * From: "Bill Todd" <billtodd@metrocast.net>; Subject: Re: Compaq still tries to spin Alphacide both ways A Message-ID: <cx7V7.16248$m05.1334126@bin5.nnrp.aus1.giganews.com>r  ' < Responses formated like this.  - bills  6 "Main, Kerry" <Kerry.Main@compaq.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF4010D724C@kaoexc01.americas.cpqcorp.net. .. Bill,n  E [following is a resend and update to something I sent earlier as mustmG have happened on my email side as I had some home net probs and it does # not appear to have been sent .. km]n  J < Pity you didn't just let that status stand.  But since you chose not to:  E >>> Kerry Main floated this rationale the day of the announcement <<<o  ? >>> I'd like to think in some small part because I spread it to E comp.arch and comp.sys.intel and Intel was not amused - perhaps HP ash well)<<<  ? Perhaps I should be asking about what tea leaves you are using?   H < I don't drink tea much, but fail to see anything in my statement aboveI < beyond a simple expression of preference (not even opinion).  As usual,nA < your inclination to write seems to exceed your ability to read.h   :-)e  D Please try to refain from the master conspiracy theories you seem to like attributing to me.e  J < Could you provide an example?  You present the appearance much more of aK < trained parrot than of a conspirator (master or otherwise), but I supposemI < I could have said something somewhere that left a different impression.    ...e  H With respect to the quotes above. the real reality is that what I statedD in this newsgroup at that time is that future versions of IPF in the= post Madison timeframes would likely have an Alpha influence.e  K < "...would likely have an Alpha influence", eh?  The following quotes seemiB < more suggestive of something with a definite Alpha *appearance*. < 3 < You began on June 25th in our advocacy group with, <nL < "As a fyi, and again pure personal opinion, one needs to keep in mind thatF < it is not IA64 that OpenVMS and Tru64 and NSK will be ported to, butK < rather a follow-on flavor of IA64 ie. IA64-2 (for lack of a better name).p <eI < "So, will IA64-2 more closely resemble IA64 or Alpha EV8? The answer isAJ < likely somewhere in between, but it will almost certainly be a different< < chip architecture than what is available today as "IA64"." <s= < A more carefully-worded statement than many which followed.d <w! < On June 26th you continued witha <yJ < "There is no way anyone in the newsgroup could have predicted that IntelK < would adopt whatever Alpha features are required to make OpenVMS, NSK ando? < Tru64 work with its IA64-2 (or whatever they plan to call it)l < architecture." <  < anda < @ < "As I've stated and as the press release has noted .. the IA64J < architecture will be updated to enable Tru64, OpenVMS and NSK to use it. <-- < "This a major change for the IA64 program."t <i9 < On June 27th we got (once more with a careful preamble)o <nH < "Pure speculation mode on. Based only on watching the many previous IA# < delay announcements in the press.l <tH < "IA64 (in its current form) has been delayed way beyond any reasonableK < expectation of making any headway in the 64bit marketplace. It is in deeptI < trouble and CB knows it. So, do you announce that you are abandoning itlL < (keeping in mind the moral impact this would have on a chip company) or doK < you open up the cheque book and work to ensure the success of the programfI < by integrating (adopting?) another architecture that already has proven  < high OS's running on it?"d < E < I should emphasize that the above occurred in the context of heatedkG < discussion in which I and others pointed out the logical flaws in andsC < lack of evidence for the views you were espousing, so by the timeaB < you floated them in c.o.v. you were well aware that they were at@ < least very questionable - but that didn't slow you down a bit. <nK < You will note that my comment about the thesis you were advancing was notuG < limited to c.o.v. posts, so the above are relevant (and I referred tohC < them without quoting them, in c.o.v. discussion, but since you'reoA < contesting their content now quoting them appears appropriate).dG < And they establish the sense of what you then began to spew in c.o.v.rH < - without even the disclaimers that you at least occasionally provided < above.  We saw <e> < "... a new combined Alpha/IA64 platform..." (c.o.v. 6/26/01) < C < "...todays IA64 technologies will be integrated and upgraded with E < Alpha technologies..." (c.o.v. 6/27/01 - note that you chose not to.6 < say simply 'upgraded' but 'integrated and upgraded') <sC < after which you quieted down for a while (vacation?) and I didn'tyE < bother combing Google for the month of July.  But you were still at 5 < it in our advocacy group on 7/10/01 when you statedg <hJ < "Again pure speculation on my part, but imho, given the short timeframesF < announced to do the VMS/Tru64/NSK ports, one can only assume that MCJ < either does not realize how long it takes to do this stuff or the target! < platform will be very EV8'ish."  < @ < and on 7/13/01 when you cited the following from The Inquirer: < ) < http://www.theinquirer.org/13070103.htmnH < "SOURCES IN THE US suggest that current designs of of IA-64 processorsD < may now be garotted to death inside Intel, to be replaced by Alpha5 < technology masquerading under the Itanic cognomen."  <eL < "The move may make the job of porting all those applications and operatingK < systems Compaq will hang onto much easier, being as future generations ofiD < the Itanic will really be the Alpha in disguise, the sources add."   I have not changed my tune btw,   G < You have indeed:  see quotes above, and contrast them with the *much*6E < milder characterization you gave at the start of your response thattE < "future versions of IPF in the post Madison timeframes would likelys < have an Alpha influence."a  #  so your strategy of trying to turntB different parties against one another to further your own personal: agenda and subsequent self-perceived influence is/was nil.  J < Cut the shit, Kerry:  I just shine a light on places Compaq would ratherE < keep murky, as do several others here.  If people are influenced byd4 < what they then see, you can thank Compaq for that.  F For lack of a better name, I called it IPF-2 (or something like that).F The current roadmaps call it "Next Generation IPF" and shows the appox timeframe of 2005. Reference:IH http://www.compaq.com/hps/ipf-enterprise/openvms.html (Cust presentation	 slide 12)r  I < That's clearly not the processor you were talking about when you statednD < that it would be necessary for VMS to run on, because the VMS port < is scheduled for 2003 - 4.  F I have no idea how much or in what form it will take, but using IntelsD own press releases, it does not take a rocket scientist to determineH there will likely be a fair amount of Alpha design influence in the post 2005 timeframe.a  H < "A fair amount of Alpha design influence" represents significant back-H < pedaling from the June statements I've quoted above.  This is the sameI < tactic you used in our group:  you seem to like re-writing history wheno < you find it inconvenient.y  F Since it is part of their core business, why is it that you find it soD hard to beleive that Intel may actually value a great deal the Alpha6 technology and world class design teams they acquired?  C < Where you got that impression is unclear, but so are many of your G < thought processes.  I've consistenly maintained that Intel wanted thedC < engineers and at least some of the technology - but was not abouteI < to use them to do anything but try to *rescue* EPIC rather than replacen$ < it with something more like Alpha.   < [more back-pedaling snipped]  D Sigh .. btw - Bill, Can you let us know how many other newgroups you plan to post this reply to ?  I < I post to groups where people might be interested and/or have somethingtL < to contribute.  In this case, I'd suggest your original distribution couldK < have been cut down a bit more, but when responding to a post I do includeb) < those groups the original post went to.i <* < - bill   ------------------------------  % Date: Sat, 22 Dec 2001 22:19:31 -0500e+ From: "Main, Kerry" <Kerry.Main@compaq.com>i; Subject: RE: Compaq still tries to spin Alphacide both wayseT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4010D724D@kaoexc01.americas.cpqcorp.net>   Bill,   G <I knew you would resort to this .. leaks were also one of the concernstD of others who participated in that private group. Even after someoneC leaked discussions and some participants dropped out because of theh0 leak, I continued to participate in good faith.>  G First, thank you for letting us all know that you can not be trusted tonB not quote from a private conversation in a group that specificallyB requested privacy from all its participants. It goes a long way to4 showing the amount of respect you should receive.=20  G It also speaks mountains of the character of the individual who will dos7 or quote anything to further their own personal agenda.n  6 < You began on June 25th in our advocacy group with..>  D I'll let others of the private-group members who also participate inH c.o.v. decide if they should comment on how they feel about participantsH in that group extracting previously-private-quotes for posting in public forums.   D Second, as you say, cut the crap - everything you have stated in the previous post boils down to:  H 1. Whether Intel will use the Alpha technology it has acquired or not inB future versions of IPF. Whether it is to rescue it (your words) or@ enhance it (my words) is a moot point for beer hall discussions.  E There is nothing shocking about this - and the Intel press releases IiC quoted illustrate the importance Intel places on its newly acquireddF assets and their new roles in assisting with the development of Intels future processors.  E 2. <<That's clearly not the processor you were talking about when youpD stated that it would be necessary for VMS to run on, because the VMS! port is scheduled for 2003 - 4.>>p  H I never stated "it would be necessary to run on..". Again, cut the crap.H You only read what you wanted to read from my postings because it suited your own personal agenda.=20  @ VMS is being ported to IA64 on IA64 systems available today. TheH expectation is that the IA64 systems available at the time when this newF VMS version is available for Cust's will be much improved over what is= available today. If the IA64 servers for that initial generalnD availability release of VMS are not up to snuff, then they obviouslyH will have lots more work to do as existing and new Cust's will remain or choose Alpha based servers.   D However, nether you or I or anyone else in this group knows for sureG what these performance levels will be so, all of your tea leave readingsD is just that until we have a chance to test whatever is available at
 that time.  = You do have good technical capabilities in some area's. It isnE unfortunate your emotions sometimes tend to cloud your posts content.    Regards,  
 Kerry Main Senior Consultantt Compaq Canada Corp.o Professional Servicesw Voice: 613-592-4660  Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----/ From: Bill Todd [mailto:billtodd@metrocast.net]  Sent: December 22, 2001 5:10 PMe To: Info-VAX@Mvb.Saic.Come; Subject: Re: Compaq still tries to spin Alphacide both ways    [major snip]   ------------------------------  # Date: Sun, 23 Dec 2001 04:54:34 GMT * From: "Bill Todd" <billtodd@metrocast.net>; Subject: Re: Compaq still tries to spin Alphacide both waysrB Message-ID: <esdV7.198273$C8.14018410@bin4.nnrp.aus1.giganews.com>  6 "Main, Kerry" <Kerry.Main@compaq.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF4010D724D@kaoexc01.americas.cpqcorp.net. .. Bill,   G <I knew you would resort to this .. leaks were also one of the concernshD of others who participated in that private group. Even after someoneC leaked discussions and some participants dropped out because of the 0 leak, I continued to participate in good faith.>  E < "Good faith", from someone who performed an instantaneous back-flipfG < on June 25th in this group of supposedly private individuals who justvC < had a common interest in VMS?  That was the point where it becamefC < obvious that your participation was purely professional, and thateA < every word out of your mouth was bought and paid for by Compaq.i  G First, thank you for letting us all know that you can not be trusted toMB not quote from a private conversation in a group that specificallyB requested privacy from all its participants. It goes a long way to1 showing the amount of respect you should receive.h  D < No, it just shows you don't pay attention when, from your commentsC < above, you clearly ought to.  I refer you to my post in c.o.v. ofs < 6/28, 12:07 A.M.:b <o8 < "my impression that this is the kind of beastie you'veF < often been referring to must have been strengthened by content in anD < earlier private communication, which I'd be happy to quote from if < you'd like specifics." <nG < Since you did not reply negatively to that offer, and then (just now)aG < denied that you had been spewing this trash, I felt free to follow uprB < with the evidence that I refrained from presenting then.  If you < don't like it, tough shit.  G It also speaks mountains of the character of the individual who will doh7 or quote anything to further their own personal agenda.r  H < Aside from your injudicious denial of the material I referred to in myI < recent post (you did not post to c.o.v. on June 25th in this vein:  the.> < reference was to the group message) which made this evidenceC < fair game, insofar as your participation in the group was clearlyeA < under the pretense of acting as an interested individual rathere> < than as a Compaq mouthpiece I'm afraid that your indignation < rings just a bit hollow.  6 < You began on June 25th in our advocacy group with..>  D I'll let others of the private-group members who also participate inH c.o.v. decide if they should comment on how they feel about participantsH in that group extracting previously-private-quotes for posting in public forums.e  C < When people lie about their statements, they really shouldn't gethA < too indignant if those statements are exhumed as evidence.  Butm? < I guess it's understandable that someone who would lie in thea( < first place might not share that view.  D Second, as you say, cut the crap - everything you have stated in the previous post boils down to:  H 1. Whether Intel will use the Alpha technology it has acquired or not inB future versions of IPF. Whether it is to rescue it (your words) or@ enhance it (my words) is a moot point for beer hall discussions.  L < It doesn't boil down to that at all:  *clearly* Intel will try to use someD < elements of Alpha technology if possible.  But the dispute was notG < about that:  it was about your suggestion that significant aspects of B < the Alpha *architecture* would *replace* portions of the currentE < Itanic architecture, and I believe the statements I dredged up makelH < it clear that your position shortly after June 25th was what I said it < was (and you denied).h  E There is nothing shocking about this - and the Intel press releases IhC quoted illustrate the importance Intel places on its newly acquired F assets and their new roles in assisting with the development of Intels future processors.  E 2. <<That's clearly not the processor you were talking about when you'D stated that it would be necessary for VMS to run on, because the VMS! port is scheduled for 2003 - 4.>>   H I never stated "it would be necessary to run on..". Again, cut the crap.H You only read what you wanted to read from my postings because it suited your own personal agenda.t  4 < I refer you once again to your quote of June 26th: < @ < "As I've stated and as the press release has noted .. the IA64J < architecture will be updated to enable Tru64, OpenVMS and NSK to use it. < - < "This a major change for the IA64 program."e <.> < Would you care to explain how that quote does *not* say thatB < architectural changes would be necessary for VMS to run on IA64?C < And would you care to list the IA64 member that will be available @ < in 2003 - 4 that could have such changes, given that the IntelA < time-line clearly identifies McKinley/Madison/Deerfield (all ofh9 < which share the same, already-defined core) as the IA64 ) < processors shipping during that period?7  @ VMS is being ported to IA64 on IA64 systems available today. TheH expectation is that the IA64 systems available at the time when this newF VMS version is available for Cust's will be much improved over what is available today.  A < But *in no way* improved by Alpha technology:  McKinley siliconeC < already exists, and Madison/Deerfield will use the McKinley core.fA < And the anticipated performance improvements are not such as tob4 < cause EV7 undue concern about its competitiveness. <I< < I don't like weasels, and find a penny-ante weasel no less< < reprehensible than the mega-weasels in Compaq management -C < just less significant.  But if you stick your head up out of your H < hole again in this manner, I'll try to find time to take a shot at it. <o < - bill   ------------------------------  % Date: Sat, 22 Dec 2001 14:10:54 -0500t  From: John Santos <JOHN@egh.com>3 Subject: Re: Congratulations for the festive season 6 Message-ID: <1011222140045.59837B-100000@Ives.egh.com>  ) On Sat, 22 Dec 2001, Arthur Krewat wrote:c   > Bob Ceculski wrote:e > > + > > I have been on VMS for 16 years now andn  > > have never had an OS crash!  > H > Me too - and I've seen more VMS crashes than I can count. 5.x liked toK > reboot itself when the cluster quorum changed. 6.0 liked to reboot itself J > too. (for the life of me, I can't recall what VMS called a panic) I haveJ > yet to get my 7.2 VS3100 to do it, but I haven't had it turned on in the > last year... > 2 > > Can you say that about your unix (gag!) boxes?S > > Want to have a clustering contest?  For disaster recovery, unix would be toast!p$ > > VMS withstood the 9/11 disaster! > K > In what way? Having a VMS cluster on the 100th floor of one of the towers,) > when it came down? I don't understand. e  D He's talking about a wide-area cluster where one of the sites was inD one of the towers.  People who should know have posted here (c.o.v.)B that such clusters exist and survived (one site in the WTC and oneH somewhere across the Hudson), but no one has posted details.  Of course,( I wouldn't either if I knew such things.  2 > > What happened to unix?  The last I heard, onlyO > > VMS clusters withstood the test ... are the defcon9 people idiots?  Did thehP > > worlds top hacker lie to congress a few years ago when he testified that theT > > White House mail system ran on VMS (All-in-1) and that was one OS he could never > > hack into?   > M > Must have been an amateur - I hacked VMS between '81 and '85 for fun. Can'tTN > remember all the university computers I was into - even places like nationalI > research labs (I won't name the place). Defense computers? even easier.   E How many times was it by a method not involving one of the well known B passwords?  (That barn door was closed over 15 years ago - you areE forced by the installation procedure to set the password to somethingn much tougher.)  . The "top hacker" was Mitnick.  See other post.  A > >Unix is hack city!  It is a VMS wanna be written by a bunch ofiQ > > people who want something for nothing!  Windows NT is in the same boat!  Dave R > > Cutler failed to turn VMS into NT with the Dec West Mica project code!  VMS is5 > > the best!  Use it or lose it (your hair that is)!  > ! > You're delusions are showing :)h >  > aaki >  >    -- v John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Sat, 22 Dec 2001 19:17:38 GMTv4 From: "Terry C. Shannon" <terryshannon@mediaone.net>3 Subject: Re: Congratulations for the festive seasont> Message-ID: <m%4V7.26612$Sj1.12934922@typhoon.ne.mediaone.net>  - "John Santos" <JOHN@egh.com> wrote in message 0 news:1011222140045.59837B-100000@Ives.egh.com...+ > On Sat, 22 Dec 2001, Arthur Krewat wrote:  >e > > Bob Ceculski wrote:q > > >t- > > > I have been on VMS for 16 years now and ! > > > have never had an OS crash!g > > J > > Me too - and I've seen more VMS crashes than I can count. 5.x liked toF > > reboot itself when the cluster quorum changed. 6.0 liked to reboot itselfL > > too. (for the life of me, I can't recall what VMS called a panic) I haveL > > yet to get my 7.2 VS3100 to do it, but I haven't had it turned on in the > > last year... > >l4 > > > Can you say that about your unix (gag!) boxes?K > > > Want to have a clustering contest?  For disaster recovery, unix wouldf	 be toast!o& > > > VMS withstood the 9/11 disaster! > >dF > > In what way? Having a VMS cluster on the 100th floor of one of the towers* > > when it came down? I don't understand. >sF > He's talking about a wide-area cluster where one of the sites was inF > one of the towers.  People who should know have posted here (c.o.v.)D > that such clusters exist and survived (one site in the WTC and oneJ > somewhere across the Hudson), but no one has posted details.  Of course,* > I wouldn't either if I knew such things.  J It is said that a VMS disaster-tolerant cluster kept things up and runningI during the CY93 WTC "incident." The truck bomb detonated by the terroristoK vermin screwed things up but good at the WTC locale of the primary cluster, 9 the shadow site across the river just kept on keeping on.   J CPQ has mentioned this event, dunno if there's any written commentary from the Q, though.   cheers,e   terry ss   ------------------------------  % Date: Sat, 22 Dec 2001 14:42:52 -0500   From: John Santos <JOHN@egh.com>3 Subject: Re: Congratulations for the festive seasont6 Message-ID: <1011222142241.59837C-100000@Ives.egh.com>  & On Sat, 22 Dec 2001, Paul Sture wrote:  K > In article <1011221190540.59837B-100000@Ives.egh.com>, John Santos wrote:  > >  > [snip] > F > > This turns out not to be the case.  Most VMS languages use countedE > > strings and the OTS routines that do string copies that check thedD > > counts when copying to fixed-length buffers, and truncate and/orE > > warn you (but never, ever write past the end of the destination.).I > > This philosophy has been present since day one - ever notice the veryf; > > non-RISCy MOVC5 instruction in the VAX instruction set?s > > G > > Sure this hurts performance sometimes: you have to store, maintain,oF > > check and pass around all those pesky counts, and you can't do theD > > cheap trick of copy bytes until you hit a <nul> in a tight loop.F > > Instead you have to compare source and destination sizes, set yourC > > loop counter to the minimum, and copy.  Sometimes you don't getsF > > to stop early if the source string is short, since you may need toD > > fill the destination.  On the other hand, <nul> is not a specialC > > character in strings.  (In-band flow control is generally a badh
 > > idea.) > > : > > But what's a few nano-seconds if it saves you hours ofF > > crash/reboot/recovery time and debugging?  Especially when the fixE > > is to manually insert code that does the same bounds checking, ino > > a less efficient manner? > >i@ > Here's a point though. Those extra nano seconds mean that yourI > subroutines (APIs, whatever), don't have to scan up a string themselvest > to determine its length.  A That's why I refered to the fix as being "less efficient".  WorstqC case, the broken routine needs to count the characters in the input C string, and then use min(length,dest-buffer-size) in its copy loop.lB Often you can code this more efficiently by checking for the <nul>F in the source string and the end of the output buffer as two differentB loop termination conditions, but you have to be careful to do themD in the right order, this is still slower (more stuff to check in theC loop) because you don't know the source string length up front, and D you have to handle the case where the source string is 1 byte longerA than the buffer, but that extra byte is the terminating <nul> andu thus the input string is okay.  G I guess I'm trying to derail the common argument that "sure programmingaE in C is dangerous, but it is more efficient in the safe cases, and iteF is the programmer's job to explicitly code in the checks in the unsafeF cases."  In this day of optimizing compilers and GHz processors, isn'tE it smarter to always do the checks and let the machine decide when it.B is redundant?  Let the programmer get on with the program, and notF write 3 lines of code when one would do it in a language that actually supports strings.r  K > For any program dealing with fixed length records, determining the record J > length during its initialization phase means it's then available for any7 > routine to use, for the program's execution lifetime.t > M > I'd suggest that the CPU consumed on a Windows machine continually scanningaL > every buffer passed its APIs is probably many times greater than that usedH > by a mechanism of passing the length (which you calculated once at the > beginning anyway). > O > Variable length records are only slightly harder - if you are constructing a iI > variable string you likely know how long it is already, as part of the s > construction process.    Yes.  B > > Most (all?) exceptions to the above are in C programs that useB > > <nul>-terminated strings, and most of those were imported fromE > > Unix, so I don't understand why the Unix users would be laughing.aA > > I think they would be too busy fixing their own systems to bes > > worrying about others. > > F > > Or maybe if the implementors of most of the public-domain softwareB > > (TCP/IP, etc., etc.) had grown up on VMS instead of Unix, theyG > > would have been dismayed on discovering the lack of buffer overflowlB > > protection in the usual C libraries and would have insisted on@ > > (or implemented themselves) a standard set of counted stringC > > functions that everyone would use, and would have soon acquiredrH > > direct support in ANSI C (for counted string literals and constants)E > > and buffer overflow attacks on Unix would be a thing of the past.p > 
 > Good point." > ___d > Paul Sture
 > Switzerlandg   -- t John Santoso Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Sat, 22 Dec 2001 12:06:53 -0800I+ From: Mark Crispin <mrc@CAC.Washington.EDU>e3 Subject: Re: Congratulations for the festive seasoneU Message-ID: <Pine.NXT.4.50.0112221146570.8045-100000@Tomobiki-Cho.CAC.Washington.EDU>   ' On Sat, 22 Dec 2001, John Santos wrote:aU > > > Want to have a clustering contest?  For disaster recovery, unix would be toast!y& > > > VMS withstood the 9/11 disaster!M > > In what way? Having a VMS cluster on the 100th floor of one of the towerst* > > when it came down? I don't understand.F > He's talking about a wide-area cluster where one of the sites was in > one of the towers.  < This is supposed to be something to "ooh" and "aah" about???  B Disaster preparedness may be a new concept for Noo Yawkahs, but inH earthquake country we deal with it all the time.  And yes, we understandI the concept of how to engineer distributed services that do not fail in ar% disaster.  On UNIX!  Who'da thunk it?6  J Yes, some people think that a cluster is a bunch of CPUs lunk via NFS to aH NetApp box with the RAID array from hell and immortal power.  If that isJ the basis for the ignorant claim that UNIX can't have survivable clusters,G you need to get out more.  That isn't how people who know what they are- doing build UNIX clusters.  0 > The "top hacker" was Mitnick.  See other post.  0 A congenital liar is an authoritative reference?  
 -- Mark --   http://staff.washington.edu/mrc$F Science does not emerge from voting, party politics, or public debate.   ------------------------------  % Date: Sat, 22 Dec 2001 12:07:48 -0800a+ From: Mark Crispin <mrc@CAC.Washington.EDU>I3 Subject: Re: Congratulations for the festive season U Message-ID: <Pine.NXT.4.50.0112221207200.8045-100000@Tomobiki-Cho.CAC.Washington.EDU>   , On Sat, 22 Dec 2001, Terry C. Shannon wrote:L > It is said that a VMS disaster-tolerant cluster kept things up and runningK > during the CY93 WTC "incident." The truck bomb detonated by the terrorist M > vermin screwed things up but good at the WTC locale of the primary cluster,i; > the shadow site across the river just kept on keeping on.u  5 This is supposed to be a unique attibute of VMS??????a  
 -- Mark --   http://staff.washington.edu/mrc F Science does not emerge from voting, party politics, or public debate.   ------------------------------  # Date: Sat, 22 Dec 2001 20:33:05 GMTp4 From: "Terry C. Shannon" <terryshannon@mediaone.net>3 Subject: Re: Congratulations for the festive seasono> Message-ID: <566V7.26760$Sj1.12976190@typhoon.ne.mediaone.net>  8 "Mark Crispin" <mrc@CAC.Washington.EDU> wrote in messageL news:Pine.NXT.4.50.0112221207200.8045-100000@Tomobiki-Cho.CAC.Washington.EDU ...m. > On Sat, 22 Dec 2001, Terry C. Shannon wrote:F > > It is said that a VMS disaster-tolerant cluster kept things up and runningeC > > during the CY93 WTC "incident." The truck bomb detonated by the 	 terroristiF > > vermin screwed things up but good at the WTC locale of the primary cluster,= > > the shadow site across the river just kept on keeping on.  >l7 > This is supposed to be a unique attibute of VMS??????i >t  F Nope. But kinda unique to clusters, of which VMS is the best exemplar.   ------------------------------  % Date: Sat, 22 Dec 2001 16:03:02 -0500t  From: John Santos <JOHN@egh.com>3 Subject: Re: Congratulations for the festive seasonf6 Message-ID: <1011222155704.59837A-100000@Ives.egh.com>  ) On Sat, 22 Dec 2001, Arthur Krewat wrote:c   > Bob Ceculski wrote:e > > \ > > leslie@clio.rice.edu (Jerry Leslie) wrote in message news:<a01klu$c3n$3@joe.rice.edu>...9 > > > Arthur Krewat (krewat@bartek.dontspamme.net) wrote:t > > > : Bob Ceculski wrote:h8 > > > : > Can you say that about your unix (gag!) boxes?O > > > : > Want to have a clustering contest?  For disaster recovery, unix wouldh > > > : > be toast!o* > > > : > VMS withstood the 9/11 disaster! > > > :tQ > > > : In what way? Having a VMS cluster on the 100th floor of one of the towerse. > > > : when it came down? I don't understand. > > > : O > > > Bob is referring to multisite VMSClusters, where one node can be lost duenM > > > to a WTC-type disaster, and the remaining nodes still have enough votesn; > > > to keep the cluster going, without loss of data, etc.  > > >rM > > > Several institutions lost VMS systems on September 11, but continued ton& > > > operate.  Here's one such story: > > >rS > > >   http://www.success-stories.digital.com/css/cgi-bin/cssextusr/s=display/i=30F( > > >   Success Stories: Credit Lyonnais# > > >   VMS Clusters' Trial By Fireo > > > : > > > --Jerry Leslie     (my opinions are strictly my own) > > J > > Sorry, I forgot these are unix people ... they don't understand "real" > > clustering ... ;)w > 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...  F It will do that to you.  Look at poor Mark C.  He used to be bright as* a monkey, and now he's dumb as a chimp[*].  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...e >  > aaka  D [*] Abe Simpson describing Homer to Lisa.  He describe Bart as beingD bright as a chimp until he turned 5 when he became dumb as a monkey.B So far as I know, neither Homer nor Bart ever used Unix.  In their@ case it was genetic.  Fortunately for Lisa, Y-chromosome linked.   -- t John Santose Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Sat, 22 Dec 2001 16:11:16 -0400r+ From: Tim Shoppa <shoppa@trailing-edge.com> 3 Subject: Re: Congratulations for the festive seasons1 Message-ID: <3C24B0A4.68C19022@trailing-edge.com>c   Dave Cherkus wrote:  > ; > gce <ge@gce.com> wrote in news:3C23EA72.48874137@gce.com:n > > Not so.6E > > 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. > / > Was this true in the PDP11 operating systems?v  > Most "system services" that deal with strings (i.e. filenames); under RSX-11 and RT-11 are working with fixed-size buffers,e# usually with RAD50 encoded strings.   E > I ask because the first place I saw the practice of zero-terminated D > strings was when using a PDP11 MACRO assembler, which provided the2 > ASCIZ directive (ascii string, zero terminated).  B Yes null-terminated strings certainly are common on -11's, even if the OS didn't use them.w  B > I always thought that's where UNIX picked up the practice, sinceA > UNIX was mainly written on a PDP11, and perhaps used MACRO as ai > bootstrap language.r  A It was very common to do null terminated strings on -11's becausep of the ease of using the idiom   10$:	MOV (R1)+,(R2)+ 	BNE 10$  > to, for example, copy a null-terminated string.  Note how this> looks almost identical to the K&R C example of copying a null-= terminated string!  Despite this similarity I think I've seeni= Mr. Ritchie write that the C (B?  BCPL?) postincrement syntax-0 predated the arrival of their -11 in New Jersey.   Tim.   ------------------------------  % Date: Sat, 22 Dec 2001 16:13:14 -0400a+ From: Tim Shoppa <shoppa@trailing-edge.com>03 Subject: Re: Congratulations for the festive seasonw1 Message-ID: <3C24B11A.30A0EAB3@trailing-edge.com>b   Ben Franchuk wrote:  >  > jmfbahciv@aol.com wrote: > A > > Oh, yea.  A key ingredient of this team is that they are ableuB > > to learn from previous mistakes (not something that Misoft has > > done at all).iF > M$ is great at marketing! Not computer software. Why else could they > sell! > BASIC (yuck),DOS a (CP/M clone)o  > For several years Microsoft sold CP/M (under an agreement with< Digital Research) with the Apple II "Microsoft Softcard" Z80E coprocessor, largely as a vehicle for selling existing Microsoft CP/Mp software to a larger market.   Tim.   ------------------------------  % Date: Sat, 22 Dec 2001 13:14:32 -0800t+ From: Mark Crispin <mrc@CAC.Washington.EDU>n3 Subject: Re: Congratulations for the festive seasonoU Message-ID: <Pine.NXT.4.50.0112221312160.8155-100000@Tomobiki-Cho.CAC.Washington.EDU>o  , On Sat, 22 Dec 2001, Terry C. Shannon wrote:H > > > It is said that a VMS disaster-tolerant cluster kept things up and- > > > running during the CY93 WTC "incident."I9 > > This is supposed to be a unique attibute of VMS??????I% > Nope. But kinda unique to clusters,d  ' More generally, to distributed systems.?  $ > of which VMS is the best exemplar.   That is debatable.  
 -- Mark --   http://staff.washington.edu/mrcaF Science does not emerge from voting, party politics, or public debate.   ------------------------------   Date: 22 Dec 2001 11:32:09 CDT= From: wayne@tachysoft.xxx.524703.killspam.00bd (Wayne Sewell)p3 Subject: Re: Congratulations for the festive seasonr. Message-ID: <aeMoJgvNa5ut@tachxxsoftxxconsult>  d In article <uzo4bevya.fsf@spacy.Boston.MA.US>, Christopher Stacy <cstacy@spacy.Boston.MA.US> writes:B >>>>>> On 21 Dec 2001 18:48:48 -0800, Bob Ceculski ("Bob") writes:F >  Bob> Did the worlds top hacker lie to congress a few years ago when@ >  Bob> he testified that the White House mail system ran on VMS@ >  Bob> (All-in-1) and that was one OS he could never hack into? > 9 > I wouldn't put too much stock in that particular point.   L Not that I would particularly trust someone like that, but what would be hisG motivation for lying in this particular case?  Given the hacker/cracker M mentality, if he was lying, wouldn't he be more likely to claim the opposite, N that he had been able to break into vms when he in fact hadn't?  The fact thatK he admits failure, and therefore reduces his stature in the warped world ofr hackers, makes me believe it.:     -- rO ===============================================================================.M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxx2: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)eO ===============================================================================tN Sparky (from Bring It On): "In cheerleading, we throw people in the air.  Fat  	people don't go as high."   ------------------------------   Date: 22 Dec 2001 21:53:23 GMT( From: peter@taronga.com (Peter da Silva)3 Subject: Re: Congratulations for the festive seasonh2 Message-ID: <a02vcj$2q7l$1@citadel.in.taronga.com>  < In article <d7791aa1.0112211855.10062ba@posting.google.com>,) Bob Ceculski <bob@instantwhip.com> wrote:a4 >peter@taronga.com (Peter da Silva) wrote in message/ >news:<9vvs1t$13r9$1@citadel.in.taronga.com>...HQ >> >But then, it takes ten seconds to start a shell with everything on my current?0 >> >Solaris box also, so where's the difference?  M >> If it takes 10 seconds to start a shell on your Solaris box, you're eithersJ >> trying to run Solaris 8 on a Sparcstation I with 16M RAM and a 3600 RPMJ >> drive to swap into, or you have a boatload of crap in your rc file thatL >> should only be run on login (if that). I have an AT&T 3b1 with 2M of RAM,K >> a 12 MHz 68010 CPU, and a 40M MFM hard disk (ie, something somewhat lessuM >> powerful than a typical 11/750: it doesn't even support demand paging) andnG >> it starts a new shell fast enough that it's basically instantaneous.h  H >no, she is probably running a 512 cpu sparcserver that still can't beat# >a single processor Alphaserver ...i  L I *have* a Sparcstation 1. It's kinda sluggish, even under OpenBSD, but it'sK still able to open a shell faster than I can notice. The last system I usedJI where creating a new shall took significant amounts of time was the 11/70-M in the Engineering department at Berkeley, but that *was* running 35-75 usersr
 in 2M of RAM.n   -- e@ Rev. Peter da Silva, ULC.	      "Cave cuniculos lagana ferentes"  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)    ------------------------------   Date: 22 Dec 2001 22:18:55 GMT( From: peter@taronga.com (Peter da Silva)3 Subject: Re: Congratulations for the festive seasont2 Message-ID: <a030sf$2r12$1@citadel.in.taronga.com>  1 In article <jgOU7.331$sK3.5237@news.cpqcorp.net>,e4 Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:6 >"Peter da Silva" <peter@taronga.com> wrote in message- >news:a002id$1781$1@citadel.in.taronga.com...c >> One issueM >> I have with VMS and security is the complexity of the security model makes * >> privilege boosting attacks more likely.  J >Generally speaking, boosting privs is the way to go.  But not easy to do.  I I imagine it's gotten a lot better, when I was using VMS there are a heck L of a lot of apparently innocuous privileges that let you get pretty much anyO other privilege on the system. I don't recall the details now, but they weren't 4 all as obvious as the right to grant privileges. :->  J >But show me a model that is as flexible, yet so secure?  No doubt that ifM >VMS was as popular as Windows, and 17 year olds could read the source like ao3 >bible, this is where I suspect people would focus.s  % >> Properly implemented, UNIX has thet) >> potential for being a lot more secure,    >Why do you believe this?a  K What do you mean "why do I believe this"? Do you want to know why I believe I that I have the experience to make such a claim, or do you want a quickie C tutorial on the UNIX security model, or what? I can try and oblige.g  H The short answer is, UNIX provides a finely grained security model basedH on assigning resources to groups, restricting membership in these groupsM to people who are authorised to use these resources, and temporarily grantingnM rights to operate as group members to trusted programs that run with modifiedw privileges.f  K There are significant problems in the implementation of this security modeltI in most applicatons and systems. The failures fall into two main classes:r  > 	1. Resources that can not be assigned rights based on groups.  @ 	   This includes system calls that are super-user only (such asC 	   mount) rather than based on access to device files: if you have D 	   r/w access to /dev/fd0c, then you should be able to mount it[1].  C 	   This also includes resources (like TCP/IP sockets) that are not ( 	   in the UNIX namespace and should be.  E 	   This also includes resources (like the frame buffer) that have ani  	   inadequate protection model.   	2. Lazy programmers.a  ? 	   The line printer daemon should not need to run setuid root.e  7 	   The mail server should not need to run setuid root.l  7 	   The name server should not need to run setuid root.e  F Properly implemented, with all resources subject to file system accessI control and programs granted no more privileges than they need to get thehC job done, and with processes running with extra privileges properlyrI designed and audited (which also means making them small enough TO audit:yJ things like the X server are far too complex to run with root privileges),K the only need for root access would be to introduce new resources and grantoH access (adding users, creating devices, etc), and these are rare events.  D [1] This would mean that non-root mounts would have to be limited toD     mounting file systems that don't contain resources or mechanismsD     for granting enhanced access. NOSUID,NOXEC,NODEV, to begin with.   -- u@ Rev. Peter da Silva, ULC.	      "Cave cuniculos lagana ferentes"  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)h   ------------------------------   Date: 22 Dec 2001 22:46:45 GMT( From: peter@taronga.com (Peter da Silva)3 Subject: Re: Congratulations for the festive seasonn2 Message-ID: <a032gl$2s0l$1@citadel.in.taronga.com>  G In article <a0232f$bdi$2@bob.news.rcn.net>,  <jmfbahciv@aol.com> wrote:v3 >In article <9vvmkd$1126$1@citadel.in.taronga.com>,h- >   peter@taronga.com (Peter da Silva) wrote:iI >>It's worse today. At least UNIX has error *detection* code, and code istI >>rewritten now and then to allow recovery from more errors, and there is G >>an actual system call interface where security and overflow checks onn >>system calls can be made.   G >>In Windows, there is no single system call interface. Every call that2L >>crosses a protection boundary has to invent its own protection mechanisms,K >>because it's all based on regular shared library calls rather than traps.0  J >>And, of course, instead of having 30 or 40 system calls (less on earlierK >>systems, more on later) you have tens of thousands of calls that run withtF >>elevated privileges that really need to exhaustively check all their >>arguments.  A >Windows checks?  It was definitely my gut feel that they didn't   >bother.  7 I didn't say they checked. I said they needed to check.d  , I believe your gut is telling you the truth.   -- t@ Rev. Peter da Silva, ULC.	      "Cave cuniculos lagana ferentes"  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)e   ------------------------------   Date: 22 Dec 2001 16:45:00 CDT= From: wayne@tachysoft.xxx.524703.killspam.00bd (Wayne Sewell)t3 Subject: Re: Congratulations for the festive seasont. Message-ID: <0oRpgordhB5b@tachxxsoftxxconsult>  Y In article <1011222135245.59837A-100000@Ives.egh.com>, John Santos <JOHN@egh.com> writes: / > On Sat, 22 Dec 2001, David J. Dachtera wrote:v >  >> Christopher Stacy wrote:u >> >=20TF >> > >>>>> On 21 Dec 2001 18:48:48 -0800, Bob Ceculski ("Bob") writes:I >> >  Bob> Did the worlds top hacker lie to congress a few years ago whensC >> >  Bob> he testified that the White House mail system ran on VMS.C >> >  Bob> (All-in-1) and that was one OS he could never hack into?l >> >=20.< >> > I wouldn't put too much stock in that particular point. >>=20 / >> So, you're saying he was less than truthful?U > F > From=20what I've read, it appears that Kevin Mitnick is an extremelyB > good social engineer and fairly good at exploiting problems that> > other people have found, but he isn't that proficient from aD > purely technical standpoint.  In other words, he probably believedI > what he said, (and, since he was saying something good about VMS, he=20eG > probably is correct :-), but he doesn't really have the competence toi > be making that judgement.e  I He doesn't know whether he broke into a vms system or not?  Now *that* iso clueless.  :-)   --  O ===============================================================================yM Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxx : http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)gO ===============================================================================AN Sparky (from Bring It On): "In cheerleading, we throw people in the air.  Fat  	people don't go as high."   ------------------------------  # Date: Sun, 23 Dec 2001 00:47:05 GMTd4 From: "Terry C. Shannon" <terryshannon@mediaone.net>3 Subject: Re: Congratulations for the festive season > Message-ID: <dQ9V7.27142$Sj1.13096767@typhoon.ne.mediaone.net>  J "Wayne Sewell" <wayne@tachysoft.xxx.524703.killspam.00bd> wrote in message( news:0oRpgordhB5b@tachxxsoftxxconsult...D > In article <1011222135245.59837A-100000@Ives.egh.com>, John Santos <JOHN@egh.com> writes:1 > > On Sat, 22 Dec 2001, David J. Dachtera wrote:  > >- > >> Christopher Stacy wrote:e	 > >> >=20eH > >> > >>>>> On 21 Dec 2001 18:48:48 -0800, Bob Ceculski ("Bob") writes:K > >> >  Bob> Did the worlds top hacker lie to congress a few years ago when0E > >> >  Bob> he testified that the White House mail system ran on VMSeE > >> >  Bob> (All-in-1) and that was one OS he could never hack into?m	 > >> >=20:> > >> > I wouldn't put too much stock in that particular point. > >>=20a1 > >> So, you're saying he was less than truthful?  > > H > > From=20what I've read, it appears that Kevin Mitnick is an extremelyD > > good social engineer and fairly good at exploiting problems that@ > > other people have found, but he isn't that proficient from aF > > purely technical standpoint.  In other words, he probably believedK > > what he said, (and, since he was saying something good about VMS, he=20sI > > probably is correct :-), but he doesn't really have the competence to  > > be making that judgement.  >aK > He doesn't know whether he broke into a vms system or not?  Now *that* ist > clueless.  :-)  I IIRC the little weasel managed, via social engineering vice brainwork, tocI hack into DEC's Easynet network. Mitnicik subsequently managed to abscond/J with the source code for VMS, which of course did not make Ken Olsen & Co.I very happy. Aside from several rather clueless DECUS members who tried to E make him a cause celebre, Mitnick didn't have many friends in the DEC 
 community.   ------------------------------  % Date: Sat, 22 Dec 2001 20:26:30 -0500e  From: John Santos <JOHN@egh.com>3 Subject: Re: Congratulations for the festive season 6 Message-ID: <1011222202249.59837J-100000@Ives.egh.com>  % On Sat, 22 Dec 2001, Bill Todd wrote:u   > ? > "Dave Cherkus" <cherkus777@777unimaster.com> wrote in messages- > news:Xns917F79F8FAADidtoken@199.125.85.9...l= > > gce <ge@gce.com> wrote in news:3C23EA72.48874137@gce.com:a
 > > > Not so.eG > > > The reason for the lack of buffer overflows is due to a number ofsH > > > factors. One: VMS habitually has used descriptors to pass strings, > > > which have sizes passed. > >  > > Interesting. > > 1 > > Was this true in the PDP11 operating systems?  > H > Certainly on RSX, though RSTS may have had greater affection for ASCIZ
 > strings.  D As far as I can remember, RSTS didn't use ASCIZ internally anywhere.  D Certainly not in the monitor interfaces, which were all either fixedB length strings (logical names, device names, send/receive receiver= names, etc.) or were passed by length & address (CCL parsing, A filename parsing, i/o and send/receive buffers, and core common.)w@ Embedded nulls were not special characters and did not cause anyH particular problems.  (They were illegal in file names, but were handledE just like the dozens of other illegal characters -- nothing special.)rC Embedded nulls in I/O buffers and send/receive messages were normal  and posed no problems.  1 BASIC+ didn't use null-terminated strings either."  L > Where they could be used safely (and efficiently, which was not always theJ > case), they did have advantages.  Byte-by-byte processing is at least asM > efficient when dealing with a short string as the set-up involved in tryinguK > to process it word-by-word, and condition codes make the loop-terminationrN > check close to free (and without requiring the use of a counting register, a9 > resource which the 11 did not have in great profusion).t >  > - bill   -- c John Santosa Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Sat, 22 Dec 2001 20:45:28 -0500t  From: John Santos <JOHN@egh.com>3 Subject: Re: Congratulations for the festive seasonM6 Message-ID: <1011222203233.59837K-100000@Ives.egh.com>  % On 22 Dec 2001, Peter da Silva wrote:   3 > In article <jgOU7.331$sK3.5237@news.cpqcorp.net>,-6 > Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:8 > >"Peter da Silva" <peter@taronga.com> wrote in message/ > >news:a002id$1781$1@citadel.in.taronga.com...  > >> One issueO > >> I have with VMS and security is the complexity of the security model makesa, > >> privilege boosting attacks more likely. > L > >Generally speaking, boosting privs is the way to go.  But not easy to do. > K > I imagine it's gotten a lot better, when I was using VMS there are a heck N > of a lot of apparently innocuous privileges that let you get pretty much anyQ > other privilege on the system. I don't recall the details now, but they weren't$6 > all as obvious as the right to grant privileges. :-> > L > >But show me a model that is as flexible, yet so secure?  No doubt that ifO > >VMS was as popular as Windows, and 17 year olds could read the source like ao5 > >bible, this is where I suspect people would focus.o > ' > >> Properly implemented, UNIX has thet+ > >> potential for being a lot more secure,- > >Why do you believe this?2 >   D I think I mis-interpreted this statement and I think Fred and othersB may have also.  I took it to mean "a lot more secure than VMS."  IF think you meant "a lot more secure than it usually is."  Your examples' all pertain to making Unix more secure.r  > Does everyone agree that Unix can be just as secure as VMS (or? that VMS can be just as secure as Unix) if properly managed and < used?  (Including proper coding of privileged applications?)  ? I (and I think most VMS partisans) argue that it is *EASIER* tosC do things right on VMS, not that it is impossible on other systems..  B Just as it is much easier to build a disaster tolerant VMS cluster> that to build the same disaster tolerance based on another O/S3 since most of the tools you need are already there.C  M > What do you mean "why do I believe this"? Do you want to know why I believeCK > that I have the experience to make such a claim, or do you want a quickiexE > tutorial on the UNIX security model, or what? I can try and oblige.S > J > The short answer is, UNIX provides a finely grained security model basedJ > on assigning resources to groups, restricting membership in these groupsO > to people who are authorised to use these resources, and temporarily grantingaO > rights to operate as group members to trusted programs that run with modified 
 > privileges.t > M > There are significant problems in the implementation of this security modeleK > in most applicatons and systems. The failures fall into two main classes:  > @ > 	1. Resources that can not be assigned rights based on groups. > B > 	   This includes system calls that are super-user only (such asE > 	   mount) rather than based on access to device files: if you haveaF > 	   r/w access to /dev/fd0c, then you should be able to mount it[1]. > E > 	   This also includes resources (like TCP/IP sockets) that are not=* > 	   in the UNIX namespace and should be. > G > 	   This also includes resources (like the frame buffer) that have anw" > 	   inadequate protection model. >  > 	2. Lazy programmers.o > A > 	   The line printer daemon should not need to run setuid root.= > 9 > 	   The mail server should not need to run setuid root.= > 9 > 	   The name server should not need to run setuid root.  > H > Properly implemented, with all resources subject to file system accessK > control and programs granted no more privileges than they need to get the E > job done, and with processes running with extra privileges properlyDK > designed and audited (which also means making them small enough TO audit:0L > things like the X server are far too complex to run with root privileges),M > the only need for root access would be to introduce new resources and grant.J > access (adding users, creating devices, etc), and these are rare events. > F > [1] This would mean that non-root mounts would have to be limited toF >     mounting file systems that don't contain resources or mechanismsF >     for granting enhanced access. NOSUID,NOXEC,NODEV, to begin with. >  > -- MB > Rev. Peter da Silva, ULC.	      "Cave cuniculos lagana ferentes" > H > "Be conservative in what you generate, and liberal in what you accept" > 	-- Matthew 10:16 (l.trans), >  >    -- h John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Sat, 22 Dec 2001 21:13:26 -0500e  From: John Santos <JOHN@egh.com>3 Subject: Re: Congratulations for the festive season26 Message-ID: <1011222210157.59837A-100000@Ives.egh.com>  # On 22 Dec 2001, Wayne Sewell wrote:c  [ > In article <1011222135245.59837A-100000@Ives.egh.com>, John Santos <JOHN@egh.com> writes: 1 > > On Sat, 22 Dec 2001, David J. Dachtera wrote:r > >  > >> Christopher Stacy wrote:m	 > >> >=20mH > >> > >>>>> On 21 Dec 2001 18:48:48 -0800, Bob Ceculski ("Bob") writes:K > >> >  Bob> Did the worlds top hacker lie to congress a few years ago when E > >> >  Bob> he testified that the White House mail system ran on VMSrE > >> >  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. > >>=20o1 > >> So, you're saying he was less than truthful?r > > H > > From=20what I've read, it appears that Kevin Mitnick is an extremelyD > > good social engineer and fairly good at exploiting problems that@ > > other people have found, but he isn't that proficient from aF > > purely technical standpoint.  In other words, he probably believedK > > what he said, (and, since he was saying something good about VMS, he=20 I > > probably is correct :-), but he doesn't really have the competence tok > > be making that judgement.t > K > He doesn't know whether he broke into a vms system or not?  Now *that* isg > clueless.  :-)  B Sure he knows he was stymied, but that doesn't in itself mean thatD someone else couldn't break in.  If he *did* break in, that would beB bad news, but his failure could just mean he was unlucky or didn't" find the right person to help him.  E Absence of evidence is not evidence of absence, though after a while, ' it builds a strong circumstantial case.h  C Look at the design.  Look at the tools and components.  Look at the F care used by the builders.   Then look at the efforts of many crackersD over many years, not just at a single one, no matter how well known.   -- e John Santosy Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------    Date: 22 Dec 2001 18:45:05 -08003 From: Eric Smith <eric-no-spam-for-me@brouhaha.com>g3 Subject: Re: Congratulations for the festive seasone0 Message-ID: <qhadwairim.fsf@ruckus.brouhaha.com>  4 Arthur Krewat <krewat@bartek.dontspamme.net> writes:D > I don't accept the fact that programmers can be "unwashed masses".  A Research shows that there is more than a 10:1 range of programmerhH productivity.  The 10x programmers are obviously more experienced and/orA more skilled than the 1x programmers.  But there are many more 1xeF programmers, and so the majority of software is written by them.  They' are the unwashed masses of programmers.h  K > Exactly - again, it's the programmers. They decide to use C. case closed.h  D That decision does not usually rest exclusively with the programmer.F When the market demands C or C++, most programmers will have to use itD whether they like it or not.  We could debate why the market demands, bad languages, but it doesn't really matter.  0 > What is a reasonable language? Very curious :)  H Depends on who you ask.  I personally like (in no particular order) Ada,E Modula-3 [*], Sather, Smalltalk, Scheme, and to a lesser extent Java.h2 None of these have any of the major problems of C.   Eric    / [*] NOT Modula-2.  Modula-3 is quite different.e   ------------------------------  % Date: Sat, 22 Dec 2001 18:51:22 -0800s# From: "Tom Linden" <tom@kednos.com> 3 Subject: RE: Congratulations for the festive seasong9 Message-ID: <CIEJLCMNHNNDLLOOGNJIMEMIDMAA.tom@kednos.com>c   > -----Original Message-----D > From: eric@ruckus.brouhaha.com [mailto:eric@ruckus.brouhaha.com]On > Behalf Of Eric Smith+ > Sent: Saturday, December 22, 2001 6:45 PMr > To: Info-VAX@Mvb.Saic.Como5 > Subject: Re: Congratulations for the festive seasons >  > 6 > Arthur Krewat <krewat@bartek.dontspamme.net> writes:F > > I don't accept the fact that programmers can be "unwashed masses". > C > Research shows that there is more than a 10:1 range of programmerNJ > productivity.  The 10x programmers are obviously more experienced and/orC > more skilled than the 1x programmers.  But there are many more 1xrH > programmers, and so the majority of software is written by them.  They) > are the unwashed masses of programmers.G > A > > Exactly - again, it's the programmers. They decide to use C. o > case closed. > F > That decision does not usually rest exclusively with the programmer.H > When the market demands C or C++, most programmers will have to use itF > whether they like it or not.  We could debate why the market demands. > bad languages, but it doesn't really matter. > 2 > > What is a reasonable language? Very curious :) > J > Depends on who you ask.  I personally like (in no particular order) Ada,G > Modula-3 [*], Sather, Smalltalk, Scheme, and to a lesser extent Java.l4 > None of these have any of the major problems of C. You forgot PL/Ia >  > Eric >  > 1 > [*] NOT Modula-2.  Modula-3 is quite different.  >    ------------------------------   Date: 23 Dec 2001 02:59:02 GMT( From: peter@taronga.com (Peter da Silva)3 Subject: Re: Congratulations for the festive seasonl1 Message-ID: <a03h9m$1r7$1@citadel.in.taronga.com>t  6 In article <1011222203233.59837K-100000@Ives.egh.com>," John Santos  <JOHN@egh.com> wrote:& >On 22 Dec 2001, Peter da Silva wrote:4 >> In article <jgOU7.331$sK3.5237@news.cpqcorp.net>,7 >> Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:h9 >> >"Peter da Silva" <peter@taronga.com> wrote in messageh0 >> >news:a002id$1781$1@citadel.in.taronga.com... >> >> One issueaP >> >> I have with VMS and security is the complexity of the security model makes- >> >> privilege boosting attacks more likely.-  M >> >Generally speaking, boosting privs is the way to go.  But not easy to do.x  L >> I imagine it's gotten a lot better, when I was using VMS there are a heckO >> of a lot of apparently innocuous privileges that let you get pretty much any2J >> other privilege on the system. I don't recall the details now, but theyP >> weren't all as obvious as accidentall granting the right to grant privileges.  M >> >But show me a model that is as flexible, yet so secure?  No doubt that if P >> >VMS was as popular as Windows, and 17 year olds could read the source like a6 >> >bible, this is where I suspect people would focus. >> .( >> >> Properly implemented, UNIX has the, >> >> potential for being a lot more secure, >> >Why do you believe this?  E >I think I mis-interpreted this statement and I think Fred and othersrC >may have also.  I took it to mean "a lot more secure than VMS."  IiG >think you meant "a lot more secure than it usually is."  Your examplesl( >all pertain to making Unix more secure.   No, you didn't.i  I What I said is that "UNIX is potentially a lot more secure than VMS". Thev word "potentially"  E In practice the VMS security design problems (mostly due to the large J array of interconnected privileges that in combination provide rights thatD were never intended) are more than made up for by the quality of theF implementation. VMS benefits from all the strengths of the "cathedral"G design philosophy, and those strengths (despite Raymond's comments) areh not negligable.u  G And yet there have been securitiy problems, simply because the securityc model is so complex.  I In practice the potential of the UNIX security model is frittered away by I people who have no idea how it's supposed to work, and all the weaknesses=L of the bazaar design model... and those weaknesses, particularly in the area% of security, should not be minimized."  K Given the way live UNIX systems are built of components designed like this,mK the fact that it *can* be secured at all is an homage to its strength. It'ssJ a simple and versatile model and properly applied... using subsystems eachN running with minimum privilege and with no trust relationships between them..., it's capable of almost infinite flexibility.  J And yet a system that has all the weaknesses of the "cathedral" model tiedI to all the weaknesses of the "bazaar" model, and none of the strengths of 2 either, is widely touted as the way of the future.  9 I'm talking about Windows here, if anyone's lost track...)   Humbug.    -- o@ Rev. Peter da Silva, ULC.	      "Cave cuniculos lagana ferentes"  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)h   ------------------------------   Date: 22 Dec 2001 21:21:41 CDT= From: wayne@tachysoft.xxx.524703.killspam.00bd (Wayne Sewell)>3 Subject: Re: Congratulations for the festive season . Message-ID: <pOreDfCn0cKb@tachxxsoftxxconsult>  Y In article <1011222210157.59837A-100000@Ives.egh.com>, John Santos <JOHN@egh.com> writes:t% > On 22 Dec 2001, Wayne Sewell wrote:s >> hL >> He doesn't know whether he broke into a vms system or not?  Now *that* is >> clueless.  :-)  > D > Sure he knows he was stymied, but that doesn't in itself mean thatF > someone else couldn't break in.  If he *did* break in, that would beD > bad news, but his failure could just mean he was unlucky or didn't$ > find the right person to help him. > G > Absence of evidence is not evidence of absence, though after a while,n) > it builds a strong circumstantial case.  > E > Look at the design.  Look at the tools and components.  Look at the H > care used by the builders.   Then look at the efforts of many crackersF > over many years, not just at a single one, no matter how well known.      M Hey, I'm not arguing.  I understood what you were saying.  I just found humor- in:-  =      he testified that the White House mail system ran on VMSo<      (All-in-1) and that was one OS he could never hack into&                                     ^^    -      he doesn't really have the competence to2      be making that judgement.    I The wording just struck me as funny, that's all.  He knows perfectly well9H whether *he* can break into vms or not.  What he doesn't know is whether anybody *else* can do it.    -- eO =============================================================================== M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxx : http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-) O =============================================================================== N Sparky (from Bring It On): "In cheerleading, we throw people in the air.  Fat  	people don't go as high."   ------------------------------  # Date: Sun, 23 Dec 2001 04:41:30 GMTr4 From: "Terry C. Shannon" <terryshannon@mediaone.net>3 Subject: Re: Congratulations for the festive seasonf> Message-ID: <_fdV7.27698$Sj1.13200425@typhoon.ne.mediaone.net>  J "Wayne Sewell" <wayne@tachysoft.xxx.524703.killspam.00bd> wrote in message( news:pOreDfCn0cKb@tachxxsoftxxconsult...D > In article <1011222210157.59837A-100000@Ives.egh.com>, John Santos <JOHN@egh.com> writes:' > > On 22 Dec 2001, Wayne Sewell wrote:o > >>K > >> He doesn't know whether he broke into a vms system or not?  Now *that*u is > >> clueless.  :-)f > >tF > > Sure he knows he was stymied, but that doesn't in itself mean thatH > > someone else couldn't break in.  If he *did* break in, that would beF > > bad news, but his failure could just mean he was unlucky or didn't& > > find the right person to help him. > > I > > Absence of evidence is not evidence of absence, though after a while,,+ > > it builds a strong circumstantial case.r > >rG > > Look at the design.  Look at the tools and components.  Look at thenJ > > care used by the builders.   Then look at the efforts of many crackersH > > over many years, not just at a single one, no matter how well known. >r >l >oI > Hey, I'm not arguing.  I understood what you were saying.  I just foundg humor  > in:  > ? >      he testified that the White House mail system ran on VMSn> >      (All-in-1) and that was one OS he could never hack into( >                                     ^^ >a >m/ >      he doesn't really have the competence to.  >      be making that judgement. >  >IK > The wording just struck me as funny, that's all.  He knows perfectly well J > whether *he* can break into vms or not.  What he doesn't know is whether > anybody *else* can do it.B  K As an aside the White House still runs its email (other than the stuff thatVF Algore managed to "lose" on a Zip disk) on ALL-In-1. They have severalG WildFires and still run OpenVMS. Another reference account that OpenVMSc Marketing can't talk about. ;-}e   ------------------------------  # Date: Sun, 23 Dec 2001 04:58:16 GMTs2 From: Arthur Krewat <krewat@bartek.dontspamme.net>3 Subject: Re: Congratulations for the festive seasonn5 Message-ID: <3C256383.2A5C2E8A@bartek.dontspamme.net>    Eric Smith wrote:c > 6 > Arthur Krewat <krewat@bartek.dontspamme.net> writes:F > > I don't accept the fact that programmers can be "unwashed masses". > C > Research shows that there is more than a 10:1 range of programmerFJ > productivity.  The 10x programmers are obviously more experienced and/orC > more skilled than the 1x programmers.  But there are many more 1x H > programmers, and so the majority of software is written by them.  They) > are the unwashed masses of programmers.  >   H Yeah, but come on. Isn't it the programmer's fault that they can't writeJ good C code? The fact that there are plenty of bad mechanics who will tellK me my car needs a new motor when it does not, does that mean that I have tosI allow them to work on my car? Or should I find someone who knows that thes f*&k they are doing? r  M > > Exactly - again, it's the programmers. They decide to use C. case closed.h > F > That decision does not usually rest exclusively with the programmer.H > When the market demands C or C++, most programmers will have to use itF > whether they like it or not.  We could debate why the market demands. > bad languages, but it doesn't really matter.  I Again, I see nothing wrong with the language except that it doesn't checkd on the assholes. s  2 > > What is a reasonable language? Very curious :) > J > Depends on who you ask.  I personally like (in no particular order) Ada,G > Modula-3 [*], Sather, Smalltalk, Scheme, and to a lesser extent Java.i4 > None of these have any of the major problems of C. >  > Eric > 1 > [*] NOT Modula-2.  Modula-3 is quite different.s  G Seen Ada, matter of fact had to tell the weenies how to program Ada in  G an effective way (system admin for a place that did DOD stuff). Modula, H never. Smalltalk, some - didn't like it. Java, well, it's OK, the jury'sG still out. I like machine language, preferably in octal (for PDP-10's).eE I never liked a compile/interpreter that pretended to know more than s I did.   aakr   ------------------------------  % Date: Sat, 22 Dec 2001 22:40:39 -0700n+ From: Ben Franchuk <bfranchuk@jetnet.ab.ca>s3 Subject: Re: Congratulations for the festive seasonn, Message-ID: <3C256E57.4285232A@jetnet.ab.ca>   Arthur Krewat wrote:H > Seen Ada, matter of fact had to tell the weenies how to program Ada inI > an effective way (system admin for a place that did DOD stuff). Modula, J > never. Smalltalk, some - didn't like it. Java, well, it's OK, the jury'sI > still out. I like machine language, preferably in octal (for PDP-10's).oF > I never liked a compile/interpreter that pretended to know more than > I did.  > I never did like the Pascal family of languages because it has? too many noise words. I was going to learn Java until I found IeF could not get a 'official' version that runs on linux. I feel the sameD about compilers too, every so often you need to get 'under the hood' to fix a programing problem.  A With all this talk of DEC and what happened to it, here is a linkt about a bit of its history: http://research.microsoft.com/~gbell/Digital/DECMuseum.htm -- r- Ben Franchuk --- Pre-historic OCTAL Cpu's -- n+ www.jetnet.ab.ca/users/bfranchuk/index.html. -- PS. Semi-washed programer!i   ------------------------------  % Date: Sat, 22 Dec 2001 20:02:46 -0500   From: John Santos <JOHN@egh.com>= Subject: Re: DDS4 (20/40 GB) tape drives in a Alphaserver 800h/ Message-ID: <1011222195521.59837D@Ives.egh.com>-   On Sat, 22 Dec 2001, Jim wrote:-   > Main, Kerry wrote: >  > > Bob, > >  > > E > >>>>... also you may want to get a firmware cd to upgrade the 800'sf > >>>>/ > > firmware, I think they are on 5.9 now ...<<- > > K > > Just a quick clarification - V6.1 is the current Alpha console firmware2 > > release. > >  > > For future reference:s2 > > http://ftp.digital.com/pub/DEC/Alpha/firmware/ > > 	 > >[snip]w >  > 7 > Actually, although the CD says 6.1, its 5.8-16 for an> > AlphaServer 800. >  > -- 8 > krait1@worldnet.att.neti  = Each different CPU has its own numbering scheme which doesn'twB match the CD scheme.  Many times, especially for older processors,9 there is no change from one CD to the next.  Other times,o= intermediate versions of the firmware get skipped.  Something 9 might be V3.2 on the 5.5 CD and go to V3.4 on the 5.6 CD.>  @ I think for some processors that attempted to match the firmware? rev # to the number of the CD it was initially released on, butoC for others no such attempt was made.  For the former, you might seet< firmware rev 5.3 on the 5.3, 5.4, 5.5 and 5.6 CD's, firmware< rev 5.7 on the 5.8-6.0 CD's, and firmware 6.1 on CD 6.1, but you can't count on it.  : I think Kerry and Bob were refering to CD #'s, and Jim to < firmware rev #.  You need to look at the little booklet with4 the CD to determine if the firmware rev has changed.   -- t John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------    Date: 22 Dec 2001 18:59:52 -0800( From: bob@instantwhip.com (Bob Ceculski): Subject: Re: historical evidence of what went wrong at DEC= Message-ID: <d7791aa1.0112221859.26751174@posting.google.com>r   Mark Crispin <mrc@CAC.Washington.EDU> wrote in message news:<Pine.NXT.4.50.0112191138290.1879-100000@Tomobiki-Cho.CAC.Washington.EDU>...L > The problem at DEC started at the top.  As early as 1974, Ken Olsen showedH > that he no longer had a grasp at which was the world was going when heK > said "I don't know why anyone would want a computer in their home."  ThisSI > was at a time when DEC advertised the first PDP-8s sold for home use as-# > being the vanguard of the future.  >  > -- Mark -- > ! > http://staff.washington.edu/mrcuH > Science does not emerge from voting, party politics, or public debate.  M And he was right!  How many people want to go thru learning and dealing w/themN windoze nightmare?  Not very many!  People don't want to be computer competentJ and learn windoze and spend 80% of their time patching it!  They want whatH us in the DP area are always told about our end users, they want serviceL without headaches, and confusion ... the computer should do it all for them,M and that is still true today, and Ken was right!  People are tired of windozemM headaches, they want what is coming, to surf the net, aol mail, banking, etc.tK all from their digital tv box with a simple to use remote control keyboard!hM That why the pc market is slowly fading away ... soon mainframes will providetK these people w/disk space, web hosting, mail services, service!  They don'tsL want to be bothered w/having to mess w/disks or any other hardware software!K And it is our job as programmers to give them what they need and want!  ThetH technology for this is now here ... honme pcs filled a temp void of slowM expensive networks and costly disk space and memory ... that is all changing! % So time will show that Ken was right!d   ------------------------------  , Date: Sat, 22 Dec 2001 18:52:43 -0200 (BRST) From: valdemir-@uol.com.br< Subject: How can I receive OPCOM messages in another nodes ?6 Message-ID: <200112222052.SAA28460@walters.uol.com.br>  F Is there any way to read OPCOM messages from one node in another node?	 Thanks...e   ------------------------------  # Date: Sun, 23 Dec 2001 01:34:59 GMTe- From: "John E. Malmberg" <wb8tyw@qsl.network>.@ Subject: Re: How can I receive OPCOM messages in another nodes ?* Message-ID: <3C253A88.7060700@qsl.network>   valdemir-#uol.com.br wrote:e  H > Is there any way to read OPCOM messages from one node in another node?     Yes.  0 As to how depends on what you read the messages.  I If the two nodes are in a cluster, all OPCOM messages from all nodes are i visible on all nodes.m  E If not, you log into a terminal session to the other host and if you  ' have OPCOM privileges, use the command:    $Reply/temp/enable  D Alternatively you can purchase a third party program to monitor and  distribute console programs.   Or you can write your own.  ? You may be able to find some links on the OpenVMS home page fore* software partners and for the OpenVMS FAQ.     HTTP://www.openvms.compaq.com/   -Johnc   wb8tyw@qsl.network Personal Opinion Onlyg   ------------------------------   Date: 22 Dec 2001 23:16:04 GMT& From: peter@abbnm.com (Peter da Silva)9 Subject: Re: HP admits it will kill VMS if merger suceeds % Message-ID: <a0347k$nnt@web.nmti.com>,  > In article <cSHU7.23417$Sj1.12150550@typhoon.ne.mediaone.net>,3 Terry C. Shannon <terryshannon@mediaone.net> wrote:rG > Why on God's green earth would Microsoft want to buy VMS when they've-J > already been granted executive clemency for stealing the Son-of-VMS MicaN > code back in 1989? Fact of the matter is, Microsoft has had access to the IP > since, what, August 1995?i  H They could use FreePort Express technology to run Win32 apps in multiple; virtual sessions, and rename it "NT Enterprise Datacenter".t  K > How would Microsoft support a real OS like VMS (or OS/400 or MVS, et al)?e  L Support? Microsoft? If Microsoft had to do that they'd be be out of businessA by now. They'd just precertify VMS people with MCSE-ED paperwork.a   -- o+  `-_-'   In hoc signo hack, Peter da Silva. E   'U`    "A well-rounded geek should be able to geek about anything."lL                                                        -- nicolai@esperi.org          Disclaimer: WWFD?   ------------------------------   Date: 22 Dec 2001 23:22:26 GMT& From: peter@abbnm.com (Peter da Silva)9 Subject: Re: HP admits it will kill VMS if merger suceeds % Message-ID: <a034ji$oba@web.nmti.com>   ' In article <3C23A795.7000008@mmaz.com>,>* Barry Treahy, Jr. <Treahy@mmaz.com> wrote:H > One better, if HP and Compaq agreed to place into escrow all VMS, and K > related layered products, that they have present ownership of, then when ,J > or if VMS is killed, all escrowed licenses would be transferred to Open F > Source licenses.  At least then, the stupid Open that DEC marketing F > prefixed onto VMS would mean something and VMS might even thrive as 4 > other systems have in the Open Source community.    F It'll never happen, but that'd definitely be enough to make us look at
 VMS again.   --  +  `-_-'   In hoc signo hack, Peter da Silva.iE   'U`    "A well-rounded geek should be able to geek about anything.".L                                                        -- nicolai@esperi.org          Disclaimer: WWFD?   ------------------------------  # Date: Sat, 22 Dec 2001 23:37:51 GMTt4 From: "Terry C. Shannon" <terryshannon@mediaone.net>9 Subject: Re: HP admits it will kill VMS if merger suceedse> Message-ID: <jP8V7.27022$Sj1.13059719@typhoon.ne.mediaone.net>  3 "Peter da Silva" <peter@abbnm.com> wrote in messagee news:a0347k$nnt@web.nmti.com...t@ > In article <cSHU7.23417$Sj1.12150550@typhoon.ne.mediaone.net>,5 > Terry C. Shannon <terryshannon@mediaone.net> wrote:sI > > Why on God's green earth would Microsoft want to buy VMS when they'veuL > > already been granted executive clemency for stealing the Son-of-VMS MicaI > > code back in 1989? Fact of the matter is, Microsoft has had access tok the IP > > since, what, August 1995?c >tJ > They could use FreePort Express technology to run Win32 apps in multiple= > virtual sessions, and rename it "NT Enterprise Datacenter".u  J Indeed they could... but if FreePort Express/FX!32 et al was so great, whyE didn't more folks run their Intel windoze apps on AlphaNT. Seems thatiG emulation/translation isn't acceptable, especially for mission-criticalo apps.n > H > > How would Microsoft support a real OS like VMS (or OS/400 or MVS, et al)? >eE > Support? Microsoft? If Microsoft had to do that they'd be be out ofr businessC > by now. They'd just precertify VMS people with MCSE-ED paperwork.b  @ Well, maybe there's a place for Compaq (Services) after all! ;-}   cheers,    terry s	   ------------------------------  # Date: Sun, 23 Dec 2001 00:16:08 GMTn  From: grinch <grinch@south.pole>/ Subject: Job security for HP-Compaq merger team-* Message-ID: <3C2522BF.601F2B05@south.pole>   From: 2  http://news.cnet.com/news/0-1003-200-8247736.html  * HP, Compaq detail fate of integration team By Dawn Kawamoto Staff Writer, CNET News.coma December 20, 2001, 4:30 p.m. PT<  N Employees who are developing Hewlett-Packard and Compaq Computer's post-mergerP plans will not lose their jobs if the deal collapses, according to documents the4 companies filed with federal regulators on Thursday.  O "If for any reason the merger does not gain regulatory or shareholder approval,oN each of our (integration) employees will go through a similar process which weO use when we hire a new employee from a competitor," states Compaq's filing with % the Security and Exchange Commission.   L That interview process would determine what type of confidential informationL employees have acquired and whether there would be a conflict of interest if$ they return to their prior position.  N "Depending upon the circumstances, an employee may return to the same job, theH same job with different responsibilities or, in some cases, a completelyK different job where the confidential information is not relevant," Compaq's  filing states.  M HP also filed a document with the SEC Thursday that contains nearly identicalh	 language.   B The multibillion-dollar merger is being opposed by the families ofP Hewlett-Packard's co-founders and their charitable organizations, which togetherM own 18 percent of HP's shares. As a result, the merger is anything but a donemP deal--and that has raised speculation about the fate of employees working on the integration team.=  P There has been widespread speculation that members of the integration team wouldP have to be let go if the deal failed because they would hold insider information about the other company.  K In the SEC filing, Compaq Chief Financial Officer Jeff Clarke clarifies the A issue to "address several questions that are consistently asked."=  P The integration team, which is staffed full-time by employees of both companies,P has access to confidential and sensitive material relating to current and future plans of the two companies.   K Although a number of team members have signed nondisclosure agreements thattJ prohibit them from discussing or using the information at their respectiveP companies, some employees at HP have speculated that the team members would have3 to leave the company should the merger be approved.l  N HP and Compaq created the integration team, or "clean room," as a way to get aK head start once the merger closes. The companies expect to seek shareholdersN approval in late February, at the earliest. And should the merger be approved,M the combined company hopes to release a product road map within 30 days afterm5 the merger's close, according to Compaq's SEC filing.i  M Although the companies are eager to operate smoothly as one entity on the dayuK the merger closes, U.S. antitrust laws prohibit companies engaged in mergerfI discussions from implementing merger-related business plans before a deal  closes.c  D Mark Feldman, author of "Five Frogs on a Log: A CEO's Field Guide toO Accelerating the Transition in Mergers, Acquisitions and Gut-Wrenching Change,"fP noted that in any merger discussion a certain amount of confidential informationM is shared in order to reach a decision about whether to even consider a deal.   P "I sincerely doubt anyone has ever lost their job from serving on a clean room,"
 Feldman said.n  F In absence of a clean room, he noted most companies do not do a lot ofI integration planning until regulators have approved the merger because ofhF concerns they may be perceived by regulators as having jumped the gun.  N Regulators are concerned that proceeding with plans before the deal officially& closes may limit competition, he said.   ------------------------------  % Date: Sun, 23 Dec 2001 01:41:36 -0500h- From: JF Mezei <jfmezei.spamnot@videotron.ca>s3 Subject: Re: Job security for HP-Compaq merger teamn, Message-ID: <3C257C9F.4FFDF80D@videotron.ca>  
 grinch wrote:AP > "Depending upon the circumstances, an employee may return to the same job, theJ > same job with different responsibilities or, in some cases, a completelyM > different job where the confidential information is not relevant," Compaq'sf > filing states.  I Ouch, never considered that. So an employee being sent to the merger task I force would in fact be punished. I wonder if employees will consider sucht& offers to participate in merger teams.  H Will Winkler be forced into a different job , or is he out of the merger integration team ?   ------------------------------  + Date: Sat, 22 Dec 2001 23:43:06 +0100 (CET)d: From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl>- Subject: Re: Logging in on a Graphics consolerJ Message-ID: <Pine.LNX.4.21.0112222328490.13808-100000@irys.stanpol.com.pl>  ( On Sat, 22 Dec 2001, Brian Luther wrote:  J >+I've got an Alphaserver 1000 4/233 for home use, and the dealer I got itM >+from put OpenVMS 7.0 on it. I can get into SRM and boot OpenVMS, but then I ) >+can't login from that graphics console.   H  Means something nearly: "I don't know any username not SYSTEM password" or something else ??  Know you of FAQ existence ?= (b.ex. http://www.openvms.compaq.com/wizard/openvms_faq.html)u  & > Is that the way it's supposed to be?L >+I haven't been able to get my Terminal Emulator (Smarterm) on a W2K box to7 >+talk to the Alphaserver over one of the serial ports.k    Wait a moment.a@  Havn't AS100 on hand to check :) but you probably have 2 serial: ports. Only one is suposed to work as console, and in most< (nearly all ?) Alphas in console mode works *paralelly* with6 the graphics console. Have you ever check the PC port 9 conecting a loop between pins 2 and 3 (regardless if 9 orl9 25 pins !) ? Set the terminal emulator (at start, not fora/ work !) "without flow controll" and re-check...    > Since it's for home, IM >+managed to get a base OpenVMS license from them, but no support. And, beingw3 >+the holidays, they're not around to call anyways.f >+  >+Am I missing something simple?  =  Really - we are not sure what mean "cannot login on graphics = console !" (being precise "console" means a "console device",c1 but you probably say "decwindows login screen" !)p  -:)    Regards - Gotfryd   -- hE ===================================================================== F $ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") - 		THEN EXCUSE/OBJECT=MEo. $!                        GS@stanpol.zabrze.plE =====================================================================    ------------------------------  % Date: Sat, 22 Dec 2001 20:18:38 -0500t  From: John Santos <JOHN@egh.com>- Subject: Re: Logging in on a Graphics consoled6 Message-ID: <1011222201227.59837F-100000@Ives.egh.com>  ( On Sat, 22 Dec 2001, Brian Luther wrote:  J > I've got an Alphaserver 1000 4/233 for home use, and the dealer I got itM > from put OpenVMS 7.0 on it. I can get into SRM and boot OpenVMS, but then IaN > can't login from that graphics console. Is that the way it's supposed to be?L > I haven't been able to get my Terminal Emulator (Smarterm) on a W2K box toN > talk to the Alphaserver over one of the serial ports. Since it's for home, IM > managed to get a base OpenVMS license from them, but no support. And, beingt3 > the holidays, they're not around to call anyways.f >   > Am I missing something simple? > 	 > thanks,k > brianh  G A base license won't let you run DECWindows.  As this is a home system,PJ you probably qualify for a hobbyist license (just about any non-commercialG use is okay - see the fine print.)  When acquiring the hobbyist license:G you need to get both the base O/S license (either VAX or ALPHA) and the9H layered products license (same for VAX and Alpha).  The layered productsF license include DECWindows and a zillion other things.  (If the system; came with a license, then all you need is the LP licenses.)   F See Gotfryd's followup for hints about the serial ports, and a pointerB to the FAQ which will point you to the hobbyist licenses web page.  = (Get the FAQ!  It has lots of other things you need to know!)a   -- r John Santos[ Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Sat, 22 Dec 2001 22:12:11 +0100.1 From: John McLean <mcleanj@swissonline.delete.ch>h2 Subject: More on marketing (was Re: HP admits ...)4 Message-ID: <3C24F72B.E7CC496@swissonline.delete.ch>   Sue Skonetski wrote: > D > The only thing that is killing the OpenVMS Customer base is peopleM > complaining and saying that Digital/Compaq/HP are going to kill VMS. Do youoL > realize every time someone posts a sky is falling message we get calls andF > emails from our customers which we then have to work with to keep asN > customers, stopping us from doing other work (like porting work)? Every timeJ > a negative stream starts our competition is glad and they can say "see IL > told you so." No, I do not have my head in the sand, but I would prefer toN > defend VMS against a foe instead of a friend. Lets not loose the war because > of friendly fire.f >  > Suer     Sue,  G Yesterday I said that probably the main reason why you have to spend soeB much time defending VMS is because marketing isn't doing their jobF properly.  I've been thinking about that today and it seems to me that@ there is really plenty that one can complain about with Compaq's. marketing in general and of VMS in particular.  F I have now started to wonder what it is that Compaq's marketing peopleE actually do to earn their salaries. From what I can gather, Compaq istC spending more than $250 million per year on "marketing" and despitehF this, current and potential customers are not being properly informed.  > A recent case in point is longtime VMS advocate and user BrianF Schenkenberger's Usenet post  - "You wanna know HOW bad Compaq/digitalF information is about VMS?  I was at a bank in NYC for about 10 days inH the beginning of December.  One of the folks in the IS dept. there askedG me if VMS was ever successfully ported to Alpha and, if so, how does itn9 work?  They're still on VAX doing their funds transfers."?   Enough said!  D And these are incumbent VMS customers to boot.  The marketing to theC existing customer base for NSK seems far superior to that for VMS. rC Could this be why NSK has been doing reasonably well in the currente? climate while VMS has been sliding? Sure, high availability has F increased in importance since the events of September 11, but VMS is aH solution that is eminently qualified to capitalize on this new factor inE the plan-to-purchase decision. Based on recent actions, it seems thattD Compaq would rather issue a daily PC-centric press release than makeE some bold statements about the progress in matters related to VMS ands enterprise systems.e  F As you well know, Compaq on a profit margin basis derives eight to tenF times more ROI from Enterprise systems and services than from PCs.  IfB ever there was a time to make all efforts to increase sales at theA high-end, then this year has been such a time.  But instead of anaH increased visibility of high-end offerings, we've been treated to simply; more of the same - huge emphasis on the loss-making PCs and1# near-invisibility of anything else.r  > A key goal of an effective marketing effort is to support, andH contribute to, a firm's business strategy and to give advice on the bestD method for selling the firm's offerings.  In this role I expect thatH marketing were largely responsible for dividing the sales field into PC,G Unix, VMS and NSK markets, a structure that appears to make life easiercD for sales people but does the entire company a great disservice.  IfG there was ever any reasonable justification for this division then thatyE time has past.  In the current economic climate Compaq should be verytH happy to sell any platform to any customer, regardless of their activity sector.   H Compaq's past history in this area has been to try to pressure customersE into buying systems at a lower level than the customer really wants. MF The irony of this situation is that the customer is pressured out of aC high-profit item (like VMS), not even into a medium profit platformoH (like Unix) but into very low margin (or even loss-making) products like= Windows based systems.  Not only does this strategy result in C significantly lower profit margins, it is the antithesis of accounttH control because others have a greater influence over the product and the sales operation.  F The irony in all this is that about two years ago Compaq declared thatG it wanted to be known as more than just a PC company.  What does CompaqiD consistently do ?  It emphasizes its PCs and then complains that theH industry, market and analysts are just not getting the picture.  ActionsB speak louder than words and I'm sure they all got the picture veryH well.  Compaq might as well have completed the picture by putting a hugeD sign right inside their Houston headquarters to say "Intel Inside" -6 visible of course through the massive picture Windows.  G If you want the world to know that PCs are just one part of Compaq theneF you need to increase the exposure of all other products and services. D Some people say that you should not advertise specific platforms butA concentrate more on the apps and solutions; they use IBM with itsyH non-specific advertising as a case in point.  The difference is that IBMH is already synonymous with enterprise systems while Compaq is synonymousD with low-end PCs.  To break this perception Compaq needs to tell theH world in no uncertain terms that it has far more to offer than only PCs.G (Of course customers buy "solutions," but unless customers are aware ofeF the quality ingredients--e.g. VMS, NSK, management software, services,H storage, etc.--that make up these solutions, they are far more likely toG purchase from a perceived solutions provider, which again would be IBM.   H Finally, let's take a look at the impact of the proposed merger.  In theB firm's last financial statement (SEC form 10-Q), under the headingH "Factors That May Affect Financial Condition and Future Results", CompaqD stated "The announcement of the planned merger could have an adverseG effect on Compaq's revenues in the near-term if customers delay, defer,iG or cancel purchases pending resolution of the planned merger with HP." eF Note in particular one admonition because the caveat certainly appliesA to VMS; it reads "While Compaq is attempting to mitigate the risk C through customer assurance programs, prospective customers could be G reluctant to purchase Compaq's products if they are uncertain about the = direction of the combined company's product offerings and its 6 willingness to support and service existing products".  H Compaq has clearly stated that it recognizes this as a potential problemH but what action has it taken in this regard?  VMS was very conspicuouslyB absent from the HP position statement about the merger.  All otherG operating systems were mentioned several times but there was no sign ofnH VMS.  What message do you think this is giving potential purchasers of aD high-end, high-margin product?  For that matter, what message do youG think this might give to existing VMS customers ?  According to various-D media reports customer defection has already started, so I guess the answer is rather obvious.   H My advice, for what it is worth, is to demand accountability and resultsG from senior marketing people before they cause the complete collapse ofe7 Compaq.  Compaq's hard-working employees-and the firm'so" stockholders-deserve nothing less.     John McLean    ------------------------------  % Date: Sat, 22 Dec 2001 19:08:08 -0500l- From: JF Mezei <jfmezei.spamnot@videotron.ca>c6 Subject: Re: More on marketing (was Re: HP admits ...), Message-ID: <3C252063.3270670A@videotron.ca>   John McLean wrote:@ > A recent case in point is longtime VMS advocate and user BrianH > Schenkenberger's Usenet post  - "You wanna know HOW bad Compaq/digitalH > information is about VMS?  I was at a bank in NYC for about 10 days in  G You'll note that Compaq has abandonned VMS in the financial sector. For6N instance, the product manager (a Mr Watson) in charge of SWIFT software on VMSG doesn't mind that SWIFT pullled the plug on ST400, the "official" SWIFT:N software that many banks used for funds transfers, and it ran on VAX. The next+ generation SWIFT software won't run on VMS.N  N Mr Watson was hoping to retain many of ST400 coustomers by offering a NT basedL solution that is supported by SWIFT. He didn't mention that Tandem still has: BESS, one of the prime solutions for SWIFT funds transfer.  K I think that the decision to drop VMS as the prime platform for SWIFT fundsoM transfers was made circa 1997-1998-1999. During the "renaissance" period lastlM year, I suggested that he get in touch with SWIFT and offer VMS as a platformeH again now that Compaq was serious about VMS (or so it seemed for a shortR while). That is where he mentioned that he didn't mind if customer migrated to NT.  M So it seems that Compaq has given up on VMS in the financial sector (at leasttF for SWIFT) and it goes without saying that knowing you will lose thoseJ customers, you don't spend much time with them during the remaining years.   ------------------------------   Date: Sun, 23 Dec 2001 11:56:23 H From: "mail.optushome.com.au" <mail.optushome.com.au@cpmx.mail.saic.com>" Subject: Need a Sydney PC doctor ?" Message-ID: <5001281@MVB.SAIC.COM>  a This is an HTML email message.  If you see this, your mail client does not support HTML messages.l   ------=_NextPart_SNRJZQSBNAh, Content-Type: text/html;charset="iso-8859-1" Content-Transfer-Encoding: 7bit   4 <!-- saved from url=(0022)http://internet.e-mail --> <html> <head> 	<title> 	Dr. PC Repairs and Consulting	 	</title>e </head>t   <body>   <table width="100%"> <tr> <td align="center">e) 	<h1 style="font-family: comic sans ms;">e 	Need a PC doctor ?. 	</h1> </td>e	 </tr><tr>d <td align="center">  	<img src="http://homepage.idx.com.au/jimmac/drpc.jpg" width="400" height="316" alt="Dr. PC Repairs and Consulting (you must be connected to the internet to view the graphics)">  </td>t	 </tr><tr>h <td align="center">i) <div style="font-family: comic sans ms;">e When your computer or network is on the blink call Dr Pc Repairs and Consulting for prompt <nobr><b>On Site</b></nobr> (we come to you) assistance.e <br><br>[ Dr. Pc will repair or provide new computer equipment and software to meet all requirements.c </div> </td>,	 </tr><tr>y <td align="center">a) <div style="font-family: comic sans ms;">a& <hr width="100%" size="1" noshade><br>  Sydney Metropolitan Area 7 days.	 <br><br> o <b>Telephone: 0419 227847</b>a <br>Q James Mckinnon (<a href="mailto:james@accountz.com.au">james@accountz.com.au</a>)  </div> </td>e </tr>r   </table>   </body>  </html>e ------=_NextPart_SNRJZQSBNA--n   ------------------------------  % Date: Sat, 22 Dec 2001 18:28:53 -0500e  From: John Santos <JOHN@egh.com>/ Subject: Re: OPC$ENABLE_LOGFILE? and 7.3 - bug?r6 Message-ID: <1011222181915.59837A-100000@Ives.egh.com>  $ On 21 Dec 2001, Patrick Young wrote:  @ > With OpenVMS 7.3 Alpha there is a _strange_ message at startup? > just after the system does it's device configuration and goesu& > into the OpenVMS Operator Console... > 8 > "The operator console and logfile will not be enabled.B > Change OPC$ENABLE_OPA0 & OPC$ENABLE_LOGFILE in SYLOGICALS.COM to > enable them."t > E > I've noticed the message on my home system in the past, however didwD > not pay much attention to it. Yesterday after upgrading systems atC > work to 7.3 I noticed it since my mission at work is to eliminateaI > any start up messages that even _smell funny_ - let alone are an error.t > < > I have the correct logical, in my case, OPC$LOGFILE_ENABLE= > defined as per the instructions in SYLOGICALS.COM. Tried an B > OPC$ENABLE_LOGFILE just for fun now on my home machine - did not > kill the message.y > @ > The author had OPC$ENABLE_LOGFILE_CLASSES on the brain? - justG > the sort of "misktake" I make every day :-) "takes one to notice one"p > G > I have not purchased OpenVMS 7.3 source listings (yet) so can't tracke > this one.2  < This appears to be a typo, since the only occurance of these= logicals is in the message text insys$message:sysmsg.exe and e$ sys$help:MSGHLP$LIBRARY.MSGHLP$DATA.  > (They could be constructed by appending pieces somewhere else,2 the only thing I searched for was "opc$enable"...)  C OPCOM.EXE (and sylogicals.com/.template) do contain OPC$OPA0_ENABLE  and OPC$LOGFILE_ENABLE.   B Maybe you have to define both of them to make the message go away.  > They should only be relevent on workstations, but I'm not sure? how OPCOM decides it is a workstation (satellite boot, graphicso9 hardware, workstation-class license, hardware model, ???)    -- 1 John Santos0 Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------    Date: 22 Dec 2001 18:15:34 -0800( From: bob@instantwhip.com (Bob Ceculski)1 Subject: OpenVMS  vs. Unix  -  put up or shut up!,= Message-ID: <d7791aa1.0112221815.6ef7abf0@posting.google.com>r   Mark Crispin <MRC@CAC.Washington.EDU> wrote in message news:<Pine.WNT.4.50.0112221446340.1372-100000@Shimo-Tomobiki.Panda.COM>...m% > On 22 Dec 2001, Jerry Leslie wrote:t2 > > : My consulting rates start at $10,000/week...2 > > Damn, why are you wasting time in this forum ? > G > This is entertainment.  There's a lot of lurkers rolling on the floor I > laughing at the notion that anyone could consider VMS superior to UNIX.n > > > > We'd forgive you if you had to go make a buck, really. ;-) >  > Fortunately, I don't.  >  > -- Mark -- > ! > http://staff.washington.edu/mrc H > Science does not emerge from voting, party politics, or public debate.  @ Why don't you tell us why unix is better than VMS?  All you unix
 people alwayspE say it is better, but never tell anyone why?  It sure hasn't beat VMSn in headnA to head overall competitions (VMS 99.9%) ... its file system suret doesn't beat< RMS ... if you pull the plug on the box, your in trouble ... clustering, forget9 about it ... I had a nt/unix guy come in once for some ntu troubleshooting, andF after a little tour he fell in love w/vms ... his only complaint, only 8 dirgC levels, but I showed him work arounds, and he found that acceptableh ... so what = makes unix better than vms?  Security?  don't make me laugh!  F Scalibility?  I don't think so ... Can someone enlighten us stupid vms users?  We have timeD now to settle this once and for all over the holidays ... VMS record
 stands for itself!,   ------------------------------  % Date: Sun, 23 Dec 2001 00:04:02 -0500 - From: Jack Patteeuw <jjpatteeuw@peoplepc.com>=5 Subject: Re: OpenVMS  vs. Unix  -  put up or shut up!=+ Message-ID: <3C2565C2.239C21D@peoplepc.com>   J First, I cut my teeth on VMS many years ago and it is still my first love J (with TOPS20 a close second).  I have been doing Unix (Tru64 and Solaris) ? sys admin for the past 6 years so let me clear a few things up.    Bob Ceculski wrote:  > B > Why don't you tell us why unix is better than VMS?  All you unixF > people always say it is better, but never tell anyone why?  It sure G > hasn't beat VMS in head to head overall competitions (VMS 99.9%) ... e, > its file system sure doesn't beat RMS ...   J Well, RMS is **NOT** a file system.  It's a layer that sits on top of the I file system.  Sometimes it does get in the way but most of the time it's ,J fantastic !  Understand that WinDoz and Unix folk never heard of ISAM and E would rather pay extra $$$ for those fancy things called "relational  I databases" so they can get there friends jobs as dba's and get more free  1 lunch from the Oracle, Ingress, etc, sales folks.b    5 >if you pull the plug on the box, your in trouble ...   I Not a problem any more !!  Tru64 solved it years ago, Solaris finally didsG in V8.  AIX also has had a log based file system for awhile.  HP-UX ???a     > clustering, forget about it   L Some Unix folks will claim they had it for years with NFS.  But we all know J what is truly unique about VMSclusters is the distributed lock manager andH mandatory (file) locking.  Truclusters claims they can do it; I haven't 	 tried it.t  G > ... I had a nt/unix guy come in once for some nt troubleshooting, andsH > after a little tour he fell in love w/vms ... his only complaint, onlyK > 8 dir levels, but I showed him work arounds, and he found that acceptable0J > ... so what makes unix better than vms?  Security?  don't make me laugh!  J I sure wish I had ACLs that worked in a heterogeneous environment !!  JustK try to figure out how to prevent a user from going "outbound" on your Unix k box.    H > Scalibility?  I don't think so ... Can someone enlighten us stupid vmsM > users?  We have time>now to settle this once and for all over the holidays y# > ... VMS record stands for itself!     : Perhaps, but we all know that Beta is better than VHS  !!! -- s  
 Jack Patteeuwo   ------------------------------    Date: 22 Dec 2001 23:38:28 +0100- From: Neil Franklin <neil@franklin.ch.remove>dD Subject: Re: PDP-10 architectural flaws? (was: VMS missing features)/ Message-ID: <6u7kreaniz.fsf@chonsp.franklin.ch>t  I Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:e   > jmfbahciv@aol.com writes:t >a > > > ...  You couldK > > >  put code in them and jump to it, it would execute.  You could use ane? > > >  accumulator address anywhere a memory address was valid.b > > <ahem>  That was a feature.  >tO > ...that would severely limit a modern implementation of the architecture. Andg, > void any advantage an I-cache might bring.  2 Why would that limit it? And why void the I-cache?  E Just regard the PDP-10 as having an main memory with an fixed-addressq$ (from 0) 16 word combined-I/D cache.  F Then treat the instructions as 2-register + 1-memory address, with theC AC and X fields directly reading the accumulators/registers (2 readiE ports) and Y as 18bit in-segment offset into 18/26/30bit memory spacen' (mapping to 18/22 bit physical memory).o  B For the special case of Y=0..15 have an Mux switch memory input to@ from an additional register read port. Place your I-cache eitherD between memory and reg/mem Mux (do not cache from registers, as theyC deliver fast anyway) or after the Mux, treating registers simply asu5 fast cache load (gives more uniform from-cache read).o  7 No reason why this should slow down the machine at all.e  E I have programmed x86 and 86k, read a lot on ARM, MIPS, Sparc and PPCrC implementation, and am presently designing an PDP-10 microprocessoruB just for the fun of it. I see no reason why I can not achieve 1990B ARM/MIPS/Sparc style performance, from an 1990-chip-size-equvalent( FPGA, using an 3-read-port register set.     --? Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/q? Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayero/ - Intellectual Property is Intellectual Robberyr   ------------------------------   Date: 22 Dec 2001 22:52:59 GMT( From: peter@taronga.com (Peter da Silva)D Subject: Re: PDP-10 architectural flaws? (was: VMS missing features)2 Message-ID: <a032sb$2s9r$1@citadel.in.taronga.com>  ) In article <3C239703.B0DF989@virgin.net>,e' Alan Greig  <a.greig@virgin.net> wrote:a >Peter da Silva wrote:M >> <------------- please adjust your window to this width ------ :) -------->m  O >The version of Netscape I post from home with seems to have a mind of its own.oI >Some posts are ok but others aren't. Short of re-installing (the typicalr& >Windows world fix) I'm a bit stumped.  L I may actually be able to help here. Check your message composition settingsL (I don't recall where they are, but the Netscape repferences are fairly easyM to deal with in both GUI and text forms) and tell it to always use plain texta rather than HTML.   C >For the special case of executing code in the ACs I guess a modernlI >architecture could work around the optimization problem without too muchtK >difficulty. After all we are only talking of this applying to the first 16u >words in address space.  I Yeh, but any machine modern enough to do that would be running loops that L short in the decoded instruction buffer anyway, and it'd need to add a bunchI of logic in the instruction-execuition critical path to make sure it only K clobbered the decoded instruction buffer on accumulator writes to code thato& happened to already be in that buffer.   --  @ Rev. Peter da Silva, ULC.	      "Cave cuniculos lagana ferentes"  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)    ------------------------------  % Date: Sat, 22 Dec 2001 01:22:10 -0700r+ From: Ben Franchuk <bfranchuk@jetnet.ab.ca> D Subject: Re: PDP-10 architectural flaws? (was: VMS missing features), Message-ID: <3C2442B2.20D5CE1E@jetnet.ab.ca>   Neil Franklin wrote: > K > Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:t >  > > jmfbahciv@aol.com writes:a > >d > > > > ...  You couldM > > > >  put code in them and jump to it, it would execute.  You could use aneA > > > >  accumulator address anywhere a memory address was valid.r! > > > <ahem>  That was a feature.l > >cQ > > ...that would severely limit a modern implementation of the architecture. Ands. > > void any advantage an I-cache might bring. > 4 > Why would that limit it? And why void the I-cache? > G > Just regard the PDP-10 as having an main memory with an fixed-addressn& > (from 0) 16 word combined-I/D cache. > H > Then treat the instructions as 2-register + 1-memory address, with theE > AC and X fields directly reading the accumulators/registers (2 readoG > ports) and Y as 18bit in-segment offset into 18/26/30bit memory spacee) > (mapping to 18/22 bit physical memory).  > D > For the special case of Y=0..15 have an Mux switch memory input toB > from an additional register read port. Place your I-cache eitherF > between memory and reg/mem Mux (do not cache from registers, as theyE > deliver fast anyway) or after the Mux, treating registers simply asc7 > fast cache load (gives more uniform from-cache read).i > 9 > No reason why this should slow down the machine at all.  > G > I have programmed x86 and 86k, read a lot on ARM, MIPS, Sparc and PPCFE > implementation, and am presently designing an PDP-10 microprocessor D > just for the fun of it. I see no reason why I can not achieve 1990D > ARM/MIPS/Sparc style performance, from an 1990-chip-size-equvalent* > FPGA, using an 3-read-port register set. >  Sounds fast!/ Just how big is that FPGA to be 1990 equvalent?    --  ' Ben Franchuk --- Pre-historic Cpu's -- r+ www.jetnet.ab.ca/users/bfranchuk/index.htmlt   ------------------------------  % Date: Sat, 22 Dec 2001 23:12:32 +0000b% From: Alan Greig <a.greig@virgin.net>uD Subject: Re: PDP-10 architectural flaws? (was: VMS missing features)* Message-ID: <3C251360.3EC78DF4@virgin.net>   Peter da Silva wrote:i  + > In article <3C239703.B0DF989@virgin.net>,h) > Alan Greig  <a.greig@virgin.net> wrote:m > >Peter da Silva wrote:O > >> <------------- please adjust your window to this width ------ :) -------->t >nQ > >The version of Netscape I post from home with seems to have a mind of its own.tK > >Some posts are ok but others aren't. Short of re-installing (the typicall( > >Windows world fix) I'm a bit stumped. >cN > I may actually be able to help here. Check your message composition settingsN > (I don't recall where they are, but the Netscape repferences are fairly easyO > to deal with in both GUI and text forms) and tell it to always use plain text  > rather than HTML.c >n   Already set... --
 Alan Greig   ------------------------------   Date: 23 Dec 2001 02:39:34 GMT( From: peter@taronga.com (Peter da Silva)D Subject: Re: PDP-10 architectural flaws? (was: VMS missing features)1 Message-ID: <a03g56$17p$1@citadel.in.taronga.com>1  * In article <3C251360.3EC78DF4@virgin.net>,' Alan Greig  <a.greig@virgin.net> wrote:mO >> I may actually be able to help here. Check your message composition settings O >> (I don't recall where they are, but the Netscape repferences are fairly easyiP >> to deal with in both GUI and text forms) and tell it to always use plain text >> rather than HTML.   >Already set...i  B Plan B: install a real operating system and use a real newsreader.   -- h@ Rev. Peter da Silva, ULC.	      "Cave cuniculos lagana ferentes"  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)l   ------------------------------  % Date: Sat, 22 Dec 2001 16:05:08 -0500V From: "JD" <dyson@jdyson.com>sY Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Congratulations for the festf1 Message-ID: <du6V7.93$Pe5.30687@news1.iquest.net>F  E "Daniel Seagraves" <dseagrav@sakura.lunar-tokyo.net> wrote in messageoF news:Pine.LNX.4.21.0112221327180.6245-100000@sakura.lunar-tokyo.net... > [Reset button on the PC...]u >oJ > Falls under the same category as the VAX HALT.  This is supposed to be a3 > VMS vs. UNIX flamewar, not a PC vs. VAX flamewar.F >nC Let's have a flamewar over what flamewar that should be prosecuted.M   John   ------------------------------  % Date: Sat, 22 Dec 2001 13:43:10 -0800i# From: "Tom Linden" <tom@kednos.com>iY Subject: RE: Proof!  I can secure UNIX faster than VMS! Was: Congratulations for the festi9 Message-ID: <CIEJLCMNHNNDLLOOGNJIEEMCDMAA.tom@kednos.com>t   > -----Original Message-----$ > From: JD [mailto:dyson@jdyson.com]+ > Sent: Saturday, December 22, 2001 1:05 PMu > To: Info-VAX@Mvb.Saic.Comm= > Subject: Re: Proof! I can secure UNIX faster than VMS! Was:.( > Congratulations for the festive season >s >- > G > "Daniel Seagraves" <dseagrav@sakura.lunar-tokyo.net> wrote in message,H > news:Pine.LNX.4.21.0112221327180.6245-100000@sakura.lunar-tokyo.net... > > [Reset button on the PC...]; > >eL > > Falls under the same category as the VAX HALT.  This is supposed to be a5 > > VMS vs. UNIX flamewar, not a PC vs. VAX flamewar.D > > E > Let's have a flamewar over what flamewar that should be prosecuted."/                              which         xxxxo   How's that for a start.e >N > John >c   ------------------------------  + Date: Sat, 22 Dec 2001 23:49:00 -0500 (EST)a) From: John Dyson <dyson@dyson.jdyson.com>hY Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Congratulations for the feste4 Message-ID: <200112230449.XAA03994@dyson.jdyson.com>   Tom Linden said:7 [Charset iso-8859-1 unsupported, filtering to ASCII...]w >  >  > > -----Original Message-----& > > From: JD [mailto:dyson@jdyson.com]- > > Sent: Saturday, December 22, 2001 1:05 PM> > > To: Info-VAX@Mvb.Saic.Comv? > > Subject: Re: Proof! I can secure UNIX faster than VMS! Was:c* > > Congratulations for the festive season > >a > >v > >eI > > "Daniel Seagraves" <dseagrav@sakura.lunar-tokyo.net> wrote in messageyJ > > news:Pine.LNX.4.21.0112221327180.6245-100000@sakura.lunar-tokyo.net...! > > > [Reset button on the PC...]t > > >@N > > > Falls under the same category as the VAX HALT.  This is supposed to be a7 > > > VMS vs. UNIX flamewar, not a PC vs. VAX flamewar.  > > >-G > > Let's have a flamewar over what flamewar that should be prosecuted.o1 >                              which         xxxxO >  > How's that for a start.- > >1 > > John > >8 >  > @ That is certainly in keeping with the spirit on the newsgroup!!!  ; This goes to show that 'loyalties' to the various tools canu> stick with people for years...   Every time that I have played? with a long lost loved OS, I have been disappointed anyway.  My 5 memories were better than reality.   I have become soP< accustomed to a very well tuned, configured UNIX clone, with@ lots of features, including nice big screens, very sophisticated9 command history, short commands that can be convieniently 9 combined, and other things like this (much of which couldi? be installed on VMS also), that looking back is only historical 	 interest.y  ; The main thing that I miss (until I compile a copy locally) > is TECO.   Once in a while, it is the best tool for an editing< job, even though VI or sed can be coerced into doing the job
 sometimes.  > I'd like to play with BLISS again (until I quickly get sick of: it), just for memories sake also.  I have fond memories of> working on DEC-10's and PDP-11's, but our machines are just so; much faster today, esp when running simple command oriented)
 environments.e  > About 7-9yrs ago, I converted a 1979-1980 PDP-11 based product= that had been eventually upgraded to an 11/93 or somesuch, tom> a 486/66 or Pentium90 type machine.   The compile (proprietary7 language) took about 10-15minutes on the 11/93 but took < about 15seconds on the 486 or Pentium.   I simply recompiled7 the C code for the compiler, and ran the application on 6 FreeBSD.  The system was MUCH MUCH faster, even though0 when I wrote the code in 1979, the PDP11 was the. 'cats meow' and fit the application perfectly.  8 Frankly, instead of the PDP11 (or DEC10 or VAX) being my? 'loss', it is the loss of simple, elegant, OS code like RSX11M.,5 I don't claim that RSX11M was perfect, but was prettyn( darned cool from a structure standpoint.  ; Even though I am a FreeBSD advocate, I still appreciate the@= simple elegance of alot of relatively well designed work donep= by others.  One of my pastimes, when bored with other things,o8 is to look through the old ACM archives for good but old ideas.  @ Stuff seems to get fatter and fatter, with clumsier and clumsier6 code, producing much less than O(fatness) benefit :-).   John   ------------------------------  % Date: Sat, 22 Dec 2001 13:28:52 -0600n8 From: Daniel Seagraves <dseagrav@sakura.lunar-tokyo.net>Y Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Congratulations for the festiL Message-ID: <Pine.LNX.4.21.0112221327180.6245-100000@sakura.lunar-tokyo.net>   [Reset button on the PC...]t  H Falls under the same category as the VAX HALT.  This is supposed to be a1 VMS vs. UNIX flamewar, not a PC vs. VAX flamewar.,   ------------------------------    Date: 22 Dec 2001 17:01:58 -0800( From: bob@instantwhip.com (Bob Ceculski)Y Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the o= Message-ID: <d7791aa1.0112221701.76136ebf@posting.google.com>    Daniel Seagraves <dseagrav@sakura.lunar-tokyo.net> wrote in message news:<Pine.LNX.4.21.0112221318190.6245-100000@sakura.lunar-tokyo.net>...% > [You can just halt the VAX, and...]  > E > Yes, but that is not a feature of VMS, that's a feature of the VAX.hG > I thought this was a VMS vs. UNIX flamewar, not an Intel vs. VAX war?   K that is not a feature of vax, it is the same on alpha ... that is a feature  of VMS!.   ------------------------------  % Date: Sat, 22 Dec 2001 13:20:29 -0600 8 From: Daniel Seagraves <dseagrav@sakura.lunar-tokyo.net>Y Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the 0L Message-ID: <Pine.LNX.4.21.0112221318190.6245-100000@sakura.lunar-tokyo.net>  # [You can just halt the VAX, and...]D  C Yes, but that is not a feature of VMS, that's a feature of the VAX. E I thought this was a VMS vs. UNIX flamewar, not an Intel vs. VAX war?    ------------------------------  % Date: Sat, 22 Dec 2001 13:25:46 -0600s8 From: Daniel Seagraves <dseagrav@sakura.lunar-tokyo.net>Y Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the aL Message-ID: <Pine.LNX.4.21.0112221323540.6245-100000@sakura.lunar-tokyo.net>   > P > Lets see you try that on an alpha box running minimum procs ... my alphaserverK > 800 running alot of procs shuts down in uner a minute ... if you properlyoP > close your apps in shutdown.com, it goes a lot quicker than a unix (gag!) box. >   ? Certainly!  Send me an Alphaserver and I'll give it a shot. ^_^    ------------------------------   Date: 22 Dec 2001 22:20:51 GMT( From: peter@taronga.com (Peter da Silva)Y Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the s2 Message-ID: <a03103$2r2s$1@citadel.in.taronga.com>  L In article <Pine.LNX.4.21.0112212011590.5800-100000@sakura.lunar-tokyo.net>,: Daniel Seagraves  <dseagrav@sakura.lunar-tokyo.net> wrote:I >I did some testing... I can get my UNIX machines into a 100% secure modekJ >of operation MUCH faster than OpenVMS!  I am using Linux for the UNIX OS, >and OpenVMS v7.2. [...]  G >On cue, Nate (my friend) logged in as SYSTEM on the VMS node, and I ass: >root on the UNIX.  I typed "shutdown -h now" and he typed >"@SYS$SYSTEM:SHUTDOWN".  K Heh. That's like Marcus Ranum's "100% secure Internet Firewall kit". A pairm of diagonal cutters.  K (ps, BSD is more secure than Linux because "halt" is quicker than "shutdownp	  -h" :) ).   -- a@ Rev. Peter da Silva, ULC.	      "Cave cuniculos lagana ferentes"  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)e   ------------------------------  % Date: Sat, 22 Dec 2001 00:56:38 -0700 + From: Ben Franchuk <bfranchuk@jetnet.ab.ca> Y Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulationsfor the f , Message-ID: <3C243CB6.5DAF4A94@jetnet.ab.ca>   Daniel Seagraves wrote:e > % > [You can just halt the VAX, and...]t > E > Yes, but that is not a feature of VMS, that's a feature of the VAX.0G > I thought this was a VMS vs. UNIX flamewar, not an Intel vs. VAX war?h  G Well I can do better... Trips over the AC cord and shuts everbody down.h :) -- k' Ben Franchuk --- Pre-historic Cpu's -- .+ www.jetnet.ab.ca/users/bfranchuk/index.html    ------------------------------  % Date: Sat, 22 Dec 2001 20:58:43 +0100n( From: Paul Sture <paul.sture@bluewin.ch>( Subject: Re: QIOs, ASTs, and Event Flags- Message-ID: <VA.000004fc.01a17812@bluewin.ch>a  H In article <3C24A6A1.C78B25E8@swissonline.delete.ch>, John McLean wrote: > Lyndon Bartels wrote:c > > $ > > I have another quick question... > > I > > I'm a bit confused by all the references to variables especially when ! > > they're passed to routines...  > > & > > Could somebody explain that to me? > > 5 > > int a;  /* it's an interger variable called "a"*/ M > > int *b; /* this is a pointer to an interger. the pointer is called "b" */e > > O > > a = 4;          /* that's giving the integer variable "a" the value of 4 */n > > H > > Stuff like this.... It's gets more confusing beyond this. EspeciallyD > > when you start passing pointers into functions. And how are they% > > referenced inside the function...e > > I > > I *think* I've got it mostly figured out... but without a teacher foro& > > this student to ask.... it's hard. > F > I'm a bit rusty with this but let me try explaining it this way .... > G > FORTRAN is a pass-by-reference language.  You call a subroutine using6E > some parameters and underneath you have passed the address of thoseeF > variables.  You change a value in the subroutine and it gets changedI > back in the calling routine because we are dealing with the same memorym > location.- >eF Nitpick. It's been a long time, but IIRC, by default FORTRAN 77 passes  character strings by descriptor.   [snip] ___.
 Paul Sture SwitzerlandE   ------------------------------  % Date: Sat, 22 Dec 2001 21:43:54 +0100t1 From: John McLean <mcleanj@swissonline.delete.ch>-( Subject: Re: QIOs, ASTs, and Event Flags5 Message-ID: <3C24F08A.72E4B009@swissonline.delete.ch>    Paul Sture wrote:( > J > In article <3C24A6A1.C78B25E8@swissonline.delete.ch>, John McLean wrote: > > Lyndon Bartels wrote:9 > > >i& > > > I have another quick question... > > >eK > > > I'm a bit confused by all the references to variables especially wheni# > > > they're passed to routines...v > > >o( > > > Could somebody explain that to me? > > >m7 > > > int a;  /* it's an interger variable called "a"*/hO > > > int *b; /* this is a pointer to an interger. the pointer is called "b" */a > > >lQ > > > a = 4;          /* that's giving the integer variable "a" the value of 4 */h > > >yJ > > > Stuff like this.... It's gets more confusing beyond this. EspeciallyF > > > when you start passing pointers into functions. And how are they' > > > referenced inside the function...c > > >tK > > > I *think* I've got it mostly figured out... but without a teacher foro( > > > this student to ask.... it's hard. > >wH > > I'm a bit rusty with this but let me try explaining it this way .... > > I > > FORTRAN is a pass-by-reference language.  You call a subroutine using G > > some parameters and underneath you have passed the address of thosebH > > variables.  You change a value in the subroutine and it gets changedK > > back in the calling routine because we are dealing with the same memorye
 > > location.d > >lH > Nitpick. It's been a long time, but IIRC, by default FORTRAN 77 passes" > character strings by descriptor.  F Sure it is the descriptor in the call frame and not the ADDRESS of the
 descriptor ??s  G One big advantage of pass-by-reference was that it was possible for the0H compiler to optimise by building the call-frame with relative addressingG and thus being able to grab the entire call-frame in a single operationE- rather than have to work with each parameter.      John   ------------------------------  % Date: Sun, 23 Dec 2001 00:03:51 +0100m1 From: John McLean <mcleanj@swissonline.delete.ch>u( Subject: Re: QIOs, ASTs, and Event Flags5 Message-ID: <3C251157.9BE05F78@swissonline.delete.ch>m   Lyndon Bartels wrote:  > F > Thanks everyone for the help... I'm reading, and re-reading all your > posts. > 6 > I think I'm starting to get this all figured out.... > J > I tore the guts out of my program and started over. But here's the logic > I'm thinking of following. > H > I create a doubly linked list. Each element in the list is a structure: > that contains all the info of that connection I'll need. > G > I create the listener. Then submit a QIO to accept a connection. FromdE > then on, I'm in a loop waiting for any event flag in the event flagaI > cluster to be set. (sys$wtflor) When that happens, I need to figure out2C > which conversation has cause the event flag to be set. (I haven'ta > written that yet.) > E > If the event is a new connection, I go off and make that connection G > ready for conversation. And I get ready to accept another connection, H > either by reusing a "empty" element in the linked list, or by adding a
 > new one. > 7 > If the event is a read or a write, I handle them too.  > J > I attached my program as it is right now. Not everything is written, but: > it's getting there. There's enough for y'all to look at. > J > I'm having difficulty with the event flag cluster calls. (sys$ascefc andJ > sys$wtflor) I'm not sure I'm issuing them correctly, have the parameters: > set correctly, etc. Any help there would be appreciated. >  > Thanks in advance, >  > Lyndon  F I'll take a look at your C when I can remember everything I know about. it.  (It's been a few years, and then some...)   A few points  F 1.  If the QIO read operation is handled by AST then you only need oneE Event Flag; the sending program doesn't need one.  This means you canrD drop $ASCEFC and change WTFLOR to a plain wait for single event flag ($WAITEF ?).  F 2.  What is the situation with the sending and receiving images ?   IfG it is networked, everything I told you works fine because you will movetH the data from the network mailbox into the allocated buffer (the addressE of which should be passed into the AST, probably as the first item int
 the mailbox).f  D 3.  If all this is on one machine, possibly with a number of sendingH processes, then unless you are passing very small amounts of data in oneE of the QIO parameters you should look at putting all the buffers in a H global section.  Your sending program can be told the OFFSET at which toC start writing (because each process will have mapped the GS to someuA address of its own choosing).  This avoids the AST having to copynF anything anywhere; it just attachs the buffer to the Active list, setsE the EF and puts out another $QIO.  (This situation is a bit tricky iftG you run short of empty buffers in the global section and have to createa some more.)   D 4.  Now for a refinement.  I've found it useful to have some kind ofD header information.  For example, you could set a flag in the headerF part of the data buffer to indicate what kind of data it is.  This wayE you can send "real" data or you can send some kind of control messageUB (eg. stop, request for monitoring data and so on). The decision ofE processing type could be made in the main code or in the AST routine.   G 5. Another refinement.  If you wanted to, you could extend the previousuF idea and have two types of "real" data, one at normal priority and oneF at high priority.  The AST checks the priority type and attachs normalE messages to the TAIL of the queue (ie. linked list), but attachs high"G priority messages to the HEAD of the queue.  (See the Sys Serv routinesV" for inserting at head or at tail.)    G Warning !!  All this used to work fine under VMS on VAX.  When we moved<F to Alpha some of the uninterruptible system services disappeared (suchF as the "interlocked" instructions INSQHI and INSQTI).  This meant that> it was not possible to be certain that the instruction was not3 interrupted in the middle of changing the pointers.n  E Please check to see what the corresponding calls are under Alpha/VMS.t     cheers   John McLean    ------------------------------  % Date: Sat, 22 Dec 2001 18:47:34 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>u( Subject: Re: QIOs, ASTs, and Event Flags, Message-ID: <3C251B92.A9B60BCD@videotron.ca>   Lyndon Bartels wrote:NG > I create the listener. Then submit a QIO to accept a connection. FrommE > then on, I'm in a loop waiting for any event flag in the event flag5I > cluster to be set. (sys$wtflor) When that happens, I need to figure out C > which conversation has cause the event flag to be set. (I haven't  > written that yet.g  " There is a simpler way to do this:  H When a "control" QIO gets delivered an AST gets executed. If the IO is aF network connect request,  yu then establish the connection, allocate aH "connection structure", and fire up a QIO to read from that new channel,A giving as AST argument the address of the "connection structure".a  K When the remote client sends a packet, an AST gets executed in your program J with , as argument, the pointer to the "connection structure" . So the ASTJ code simply takes that address and blindly processes the data based on theI channel, buffer and context variables in that structure. It then fires upcL another read QIO, with, as AST argument, the same value that was given to itI as argument (the pointer to the connectiuon structure). before returning.-    G And when you do establish the connection, you also set it up to deliver-H "control" messages to an AST.  So when the client dosconnects, an AST isK delivered to your program and you can deallocate its structures. Be careful H though, I have seen instances where the disconnect request arrived in myM program before the data packet (eg: connect, send a packet, disconnect). This>N was with decnet. I added code to delay the deallocation of the structure if noM transactions had been received when the disconnect was received. (essentiallyhM a delete pending , which would get acted upon when a transaction was receivedf and processed.)     J Having your connection structures in a linked list is useful for your mainI program to manage and report on its health/statistics. But for the actual M work, you're essentially tossing balls in a racketball court. Each ball has anN pointer in it. And whenever a ball comes bacl to you (AST delivered), you lookN at the pointer and process what is needed and then toss the ball back into the court with the same pointer.      1 ASTs allow far more esthetic and simple programs.s   ------------------------------  % Date: Sat, 22 Dec 2001 19:08:59 -0500u  From: John Santos <JOHN@egh.com>( Subject: Re: QIOs, ASTs, and Event Flags6 Message-ID: <1011222183931.59837B-100000@Ives.egh.com>  ' On Sun, 23 Dec 2001, John McLean wrote:t   >  >  > Lyndon Bartels wrote:  > > H > > Thanks everyone for the help... I'm reading, and re-reading all your
 > > posts. > > 8 > > I think I'm starting to get this all figured out.... > > L > > I tore the guts out of my program and started over. But here's the logic > > I'm thinking of following. > > J > > I create a doubly linked list. Each element in the list is a structure< > > that contains all the info of that connection I'll need. > > I > > I create the listener. Then submit a QIO to accept a connection. FromeG > > then on, I'm in a loop waiting for any event flag in the event flagaK > > cluster to be set. (sys$wtflor) When that happens, I need to figure outgE > > which conversation has cause the event flag to be set. (I haven't  > > written that yet.) > > G > > If the event is a new connection, I go off and make that connectionnI > > ready for conversation. And I get ready to accept another connection,dJ > > either by reusing a "empty" element in the linked list, or by adding a > > new one. > > 9 > > If the event is a read or a write, I handle them too.  > > L > > I attached my program as it is right now. Not everything is written, but< > > it's getting there. There's enough for y'all to look at. > > L > > I'm having difficulty with the event flag cluster calls. (sys$ascefc andL > > sys$wtflor) I'm not sure I'm issuing them correctly, have the parameters< > > set correctly, etc. Any help there would be appreciated. > >  > > Thanks in advance, > > 
 > > Lyndon > H > I'll take a look at your C when I can remember everything I know about0 > it.  (It's been a few years, and then some...) >  > A few points > H > 1.  If the QIO read operation is handled by AST then you only need oneG > Event Flag; the sending program doesn't need one.  This means you canmF > drop $ASCEFC and change WTFLOR to a plain wait for single event flag > ($WAITEF ?). > H > 2.  What is the situation with the sending and receiving images ?   IfI > it is networked, everything I told you works fine because you will movenJ > the data from the network mailbox into the allocated buffer (the addressG > of which should be passed into the AST, probably as the first item in- > the mailbox).- > F > 3.  If all this is on one machine, possibly with a number of sendingJ > processes, then unless you are passing very small amounts of data in oneG > of the QIO parameters you should look at putting all the buffers in anJ > global section.  Your sending program can be told the OFFSET at which toE > start writing (because each process will have mapped the GS to somekC > address of its own choosing).  This avoids the AST having to copyaH > anything anywhere; it just attachs the buffer to the Active list, setsG > the EF and puts out another $QIO.  (This situation is a bit tricky if I > you run short of empty buffers in the global section and have to create  > some more.)  > F > 4.  Now for a refinement.  I've found it useful to have some kind ofF > header information.  For example, you could set a flag in the headerH > part of the data buffer to indicate what kind of data it is.  This wayG > you can send "real" data or you can send some kind of control messagenD > (eg. stop, request for monitoring data and so on). The decision ofG > processing type could be made in the main code or in the AST routine.r > I > 5. Another refinement.  If you wanted to, you could extend the previous H > idea and have two types of "real" data, one at normal priority and oneH > at high priority.  The AST checks the priority type and attachs normalG > messages to the TAIL of the queue (ie. linked list), but attachs high-I > priority messages to the HEAD of the queue.  (See the Sys Serv routineso$ > for inserting at head or at tail.) >  > I > Warning !!  All this used to work fine under VMS on VAX.  When we moved H > to Alpha some of the uninterruptible system services disappeared (suchH > as the "interlocked" instructions INSQHI and INSQTI).  This meant that@ > it was not possible to be certain that the instruction was not5 > interrupted in the middle of changing the pointers.c > G > Please check to see what the corresponding calls are under Alpha/VMS.r  B The INSQxI instructions are available on the Alpha.  (I think they@ are emulated in PAL code.)  The library routines LIB$INSQxI (and? LIB$REMQxI) [x is H or T for head or tail]  all exist.  I thinkIB MACRO-32 may actually call the LIB functions, instead of the other way around.)  F The Alpha also has LIB$INSQxIQ instructions, which operate on quadword8 queues.  (64-bit addresses instead of 32-bit addresses.)   So this shouldn't be a problem.s  B (The VAX instructions have always had a situation where they wouldB back out and not do anything.  If CARRY is set on completion, then? the entry wasn't linked to the queue and you need to re-try it. B See the example in the VAX Architecture Handbook, 1981, pp 236-249G or the VAX MACRO and Instruction Set Reference Manual, sections 9.2.7.2fD and 9.2.7.3.  The LIB$ functions accept a retry count (default valueA of 10) and retry that many times.  An interlock failure is a rare-A occurance possible only on a multi-processor system where threadshG in each processor are trying to update the same queue at the same time,eD and unlikely even then.  I think 10 was chosen because the chance ofE failing 10 times in a row is infinitesmal, unless the queue header is B messed up, in which case it would always fail and infinite retries would cause an infinite loop.)   > cheers > 
 > John McLeanU   -- m John SantosI Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Sat, 22 Dec 2001 19:11:38 -0500h- From: JF Mezei <jfmezei.spamnot@videotron.ca>n( Subject: Re: QIOs, ASTs, and Event Flags, Message-ID: <3C252135.EB12AE73@videotron.ca>   John McLean wrote:I > Warning !!  All this used to work fine under VMS on VAX.  When we moved-H > to Alpha some of the uninterruptible system services disappeared (suchH > as the "interlocked" instructions INSQHI and INSQTI).  This meant that@ > it was not possible to be certain that the instruction was not5 > interrupted in the middle of changing the pointers.   K For all operations that modified the lilnked list (adding or removing), the I main program would simply declare an AST that did the work. If an AST was*H already in progress to add a new block in the linked list, my request toK remove another block would wait for that first AST to complete. I have beennK told that in a process only one user mode AST executes at any point in timelJ and that no user mode AST will interrupt another user mode AST. So you can safely "queue" your operations..   ------------------------------  % Date: Sat, 22 Dec 2001 20:14:36 -0500c- From: JF Mezei <jfmezei.spamnot@videotron.ca>.( Subject: Re: QIOs, ASTs, and Event Flags, Message-ID: <3C252FF3.6CE0B73E@videotron.ca>   re: pointers and values.   consider this:  @ short a[50] ;  /* contains 50 short integers, each 2 bytes long.K short *b[50] ; /* contains 50 pointers , each 4 bytes (64 bits on alpha) noa1 matter if declared as short, char or float etc */e% short *c ; contains a single pointer.r    L c = &a[5] ;  c now contains the address of the 6th element in the "a" array.  H *c : is equivalent to a[5] and will generate the value stored in the 6th element of the array.-   Where it gets tricky is math.,  D c ++ ;  this means that the VALUE of C (eg: an address in memory) isM incremented by 1 times the size of its definition. Because *c was declared as0M a short, then adding 1 to c means that the size of short (2 bytes) gets added8 to c.w  - After c++,  *c points to a[6]  (7th element).d   if you define a subroutine as:  = int chocolate( int flag, int *result, int first, int *second)d {    *result = first + *second ;  }e  M when you say "int *result" it means that result contains an address, and thate *result points to an integer.    so in *result = first + *secondb  + 	  int    = int   + int   ---> that is OK ;i  & if you had:  *result = first + second  	        int = int  + address    That would not be ok.t          < Where ANSI C is not very coherent is with character strings.   char buffer[256], *ptr ;  M one would logically expect:  ptr = &buffer to have ptr contain the address of " the first byte in buffer. BUT NO !  K you have to say ptr = buffer. Alternatively , you can say ptr = &buffer[0]..   ------------------------------  # Date: Sun, 23 Dec 2001 01:26:56 GMT - From: "John E. Malmberg" <wb8tyw@qsl.network>y( Subject: Re: QIOs, ASTs, and Event Flags* Message-ID: <3C2538A4.7000700@qsl.network>   JF Mezei wrote:s   > > > Where ANSI C is not very coherent is with character strings. >  > char buffer[256], *ptr ; > O > one would logically expect:  ptr = &buffer to have ptr contain the address ofe > the first byte in buffer.     G Actually you are asking for the assignment of the address of something CF that only exists as an address.  This was something that some older C = compilers ignored, but ANSI ones flag as a programming error.f  0 Does this make it clearer why it is not allowed?    M > you have to say ptr = buffer. Alternatively , you can say ptr = &buffer[0].c    B Yes, both of those are assigning an address to a pointer variable.  F The older behavior was inconsistent with the language syntax, but the ; compiler usually ignored the redundant address of operator.e    , -John    wb8tyw@qsl.network Personal Opinion Onlya   ------------------------------  % Date: Sat, 22 Dec 2001 20:56:23 -0500g. From: Lyndon Bartels <lbartels@pressenter.com>( Subject: Re: QIOs, ASTs, and Event Flags. Message-ID: <3C24F377.50D3A198@pressenter.com>   John McLean wrote:   > A few points > H > 1.  If the QIO read operation is handled by AST then you only need oneG > Event Flag; the sending program doesn't need one.  This means you can.F > drop $ASCEFC and change WTFLOR to a plain wait for single event flag > ($WAITEF ?). >   E I'm using multiple event flags for a couple reasons. 1. There are twoeF local event flag clusters. The first cluster has event flags from 0 toD 31, the second cluster from 32 to 63. And there are two common event@ flag clusters. The wflor looks at all the event flags in a givenD cluster. I want to spread out the event flags for verious reasons soG that the event flags aren't tripping over one another. 2. I'm using thehD event flag to also indicate what action the io conversation has justD done. That way, I can better decide what that conversation should do next.   H > 2.  What is the situation with the sending and receiving images ?   IfI > it is networked, everything I told you works fine because you will movegJ > the data from the network mailbox into the allocated buffer (the addressG > of which should be passed into the AST, probably as the first item ine > the mailbox).l         > F > 3.  If all this is on one machine, possibly with a number of sendingJ > processes, then unless you are passing very small amounts of data in oneG > of the QIO parameters you should look at putting all the buffers in aaJ > global section.  Your sending program can be told the OFFSET at which toE > start writing (because each process will have mapped the GS to somenC > address of its own choosing).  This avoids the AST having to copyrH > anything anywhere; it just attachs the buffer to the Active list, setsG > the EF and puts out another $QIO.  (This situation is a bit tricky if I > you run short of empty buffers in the global section and have to createm
 > some more.)f > F > 4.  Now for a refinement.  I've found it useful to have some kind ofF > header information.  For example, you could set a flag in the headerH > part of the data buffer to indicate what kind of data it is.  This wayG > you can send "real" data or you can send some kind of control messageeD > (eg. stop, request for monitoring data and so on). The decision ofG > processing type could be made in the main code or in the AST routine.  > I > 5. Another refinement.  If you wanted to, you could extend the previoussH > idea and have two types of "real" data, one at normal priority and oneH > at high priority.  The AST checks the priority type and attachs normalG > messages to the TAIL of the queue (ie. linked list), but attachs highfI > priority messages to the HEAD of the queue.  (See the Sys Serv routines.$ > for inserting at head or at tail.)    B Right now, I'm working on getting the concept of the server engineF working properly. Once that is done, then I can start writing both the7 server and client to converse with actual, useful data.o      H I'm still trying to figure out the longword bit vector used in the wflor< call... How is that parameter declared and how is it set....  G I've been looking around the documentation and I haven't found anythingnF yet, but is there somewhere that the various data types are listed andG how they are declared? Especially, the ones needed for system services.    Thanks,y   Lyndon   --  G My opinions are mine and mine alone. They seldom align with those of myh	 employer.i    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: Sun, 23 Dec 2001 01:51:01 -0500a- From: JF Mezei <jfmezei.spamnot@videotron.ca>s( Subject: Re: QIOs, ASTs, and Event Flags, Message-ID: <3C257ED4.3BF754F8@videotron.ca>   "John E. Malmberg" wrote:tH > Actually you are asking for the assignment of the address of something! > that only exists as an address.   ! This is where there is a problem.r  
 int  cake[25]  int  biscuit ; char cookie[25]- void *pointer ;-  ) I can pointer = cake ; pointer = cookie ;   N but when I :  cryptic_function( cake ) ; it isn't so obvious well below in theG program that I am passing a pointer to an array.  and then I could alsowW cryptic_function(&biscuit). This now makes it very obvious that I am passing a pointer.o  J This is why I will often cryptic_function( &cake[0] ) in a program just toL make it obvious that I am passing a pointer to the first element of an array) that may have been defined very far away.    ------------------------------  % Date: Sat, 22 Dec 2001 23:03:01 +0000n% From: Alan Greig <a.greig@virgin.net>g( Subject: Re: Strange quorum disk problem* Message-ID: <3C251125.9C5041B6@virgin.net>   Patrick Young wrote:  G > I won't bet anything on this one. Making BACKUP somehow not cause the D > problem is not a solution for me. Just makes some fodder for those@ > "PC" folks when the system is under full load next session :=) >iE > As always with OpenVMS, It works _every time_, and properly, or I'mT > not interested.   [ In that case the simple answer is do it properly and make the quorum disk a disk all of its  own with no other data.n  M That said I've run systems for years with  quorom/data disks without problemsn   >t > It is indeed a tough one.    --
 Alan Greig   ------------------------------  % Date: Sat, 22 Dec 2001 19:21:10 -0500   From: John Santos <JOHN@egh.com>- Subject: Re: VMSclusters and network switches 6 Message-ID: <1011222191042.59837C-100000@Ives.egh.com>  , On Sat, 22 Dec 2001, John E. Malmberg wrote:   > John Santos wrote: > 0 > > On Fri, 21 Dec 2001, John E. Malmberg wrote: >  o > >>Rich Jordan wrote: > >> > >>F > >>>The reason I'm asking is I have a clear recollection of _someone_K > >>>posting here or in another related newsgroup about known problems withhK > >>>many network switch codebases that could negatively impact a cluster. aD > >>>I haven't been able to locate the posts (haven't had time for a > >>>complete search either).n > >>>e > I > >>Basically from what I have been told by people who seem to know more i > >>about networks than I do:k > >>H > >>Watch out for auto-negotiate!  If you have a thin-net or thick wire , > >>ethernet on a switch, it is half-duplex. > >>  L > > Yes!  I'm not sure I've ever had a DEC/Compaq Ethernet card successfullyK > > autonegotiate with a switch.  (Most or all the switches are 3rd party.)r >  > H > At a networking class that I attended that had nothing to do with any H > specific vendors product, the Instructor stressed that auto-negotiate # > was not reliable between vendors.- > I > He said that the process had not yet been standardized and only worked eH > somewhat reliably if all the equipment came from the same vendor, and  > was all at the same revision.r >  > J > > There have been several ECO's. mostly LAN ECO's, that mention problemsG > > with autonegotiation, including one very recently. VMS721_LAN-V0300 E > > and VMS73_LAN-V0200 (also for 7.2-1h1 and 7.2-2, I think), that Ie. > > haven't tried yet, so it may now be fixed. >  > K > If you are current on the LAN eco's and are having problems with OpenVMS  J > recognizing the console settings or the LANCP settings for the speed andE > duplex, I would advise you to contact the CSC to get this resolved.  > J > But from what I have heard about auto-negotiation, I avoid it where ever > I can.  C I've only had problems where both the Alpha and the switch were set A to auto-negotiate, or when the Alpha had an explicit setting, butdB the switch was set to auto-negotiate.  I haven't had problems whenA both the Alpha and the switch were set to the same explicit mode.mK I haven't messed with it using the current ECO's because it is working now.i  D > > Given that there are no obvious problems, would we be better offA > > changing the 1200 back to 10Mb half-duplex to match the otheri$ > > nodes (or to 100Mb half-duplex?) >  > K > I am far from being a networking expert, but this is how I understand it.e > G > With the ALPHA set to full duplex, it can send a response to the halfaF > duplex segment while it is still receiving data from the half duplexG > segment. This will cause a collision on the half duplex side, and theoC > full duplex system will resend the packet once the acknowlegement  > times out. >  > I > If you only have this happening once in a while you will not notice it.b > I > But it could just as easily get into a condition where the full duplex eG > node can keep pumping data into the half duplex segment to the point f# > that almost nothing can get done.  > G > Two half duplex segments of different speeds do not suffer from this  I > problem.  The half duplex means that the slow links and the fast links  J > will usually not be sending at the same time, hence most collisions are 
 > avoided. > H > In order to handle the connection between a full duplex segment and a H > half duplex segment reliably, some sort of store and forward scheme isK > needed that can buffer several messages.  That is more the function of a e > router than a switch.   B I agree with your reasoning, but I thought switches had to do this@ anyway, because a 100Mb NIC can send 10 packets while a 10Mb NIC@ is receiving the 1st one, even if everything is half-duplex.  So? the switch has to buffer at least a few packets and fake "busy" @ (assert carrier?) to make the 100Mb sender back off when it gets too far behind.   A I think a switch without this function is just a repeater (i.e. a 6 hub) and I didn't think they could do speed-buffering.  M > >>Note that the problems induced are intermittant and hard to find, and it uL > >>is possible that some sites are mixing half duplex and full duplex with  > >>out any visible problems.  > > H > > Maybe that's us!  (Or maybe I should have read this paragraph before7 > > writing my response to the previous paragraph?  :-)e >  >  > > F > A collision detect protocol like ethernet can ignore quite a bit of F > network mis-configuration and cabling errors and still appear to be  > quite functional.n > E > Some of these problems can be detected with a network monitor, but  I > others require actually monitoring the signal to see if there is noise h > or distortion.  0 I'll look into this more when I have a chance...   > >l > -Johnt > wb8tyw@qsl.network >  > Personal Opinion OnlyA   -- e John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Sat, 22 Dec 2001 14:36:02 -0000.1 From: "Chris Townley" <news@townleyc.demon.co.uk>tY Subject: Re: Why would one want a colon in a logical name? (Re: TOPS residuals (was: RE: TA Message-ID: <1009070298.7252.0.nnrp-10.d4e45fa5@news.demon.co.uk>i  E "John Macallister" <J.Macallister1@physics.ox.ac.uk> wrote in messagecH news:35666012DF4CD411BE940090279FA240010BF193@ppnt41.physics.ox.ac.uk...D > >Now, *why* would you *want* to include a colon in a logical name? >yJ > SYS$SYSDEVICE is a logical name with a colon. It's just one way of using <snip>    I missed the original post here.  J Plenty of times when itis relevant. For example in a com file I will use aF logical for the file handle with a trailing colon for readability, for example    $ open/read infile: file.names   $ read infile: data_line   etc.    It is a convention I always use.   -- Chrisr   ------------------------------  % Date: Sat, 22 Dec 2001 11:28:23 -0800n2 From: "Randy Park" <rjpark@mindspring.nospaam.com>3 Subject: Re: Windows XP, biggest security hole yet. 2 Message-ID: <a02mq9$84f$1@slb0.atl.mindspring.net>  < My dad just bought a new PeeCee a couple of weeks ago.  When; he was discussing his proposed purchase with me a month agoo8 I gave him explicit instructions not to buy one that had9 XP already loaded.  Thankfully, he took my advice, but he 0 had to buy a remanufactured machine to avoid XP.  / Shane Smith <ssmith@icius.com> wrote in messages* news:01C18A01.16CBF430@sulfer.icius.com..." > Think I'm joking? Take a look at >eD > http://www.washingtonpost.com/wp-dyn/articles/A7050-2001Dec20.html >u >eB > A Microsoft official acknowledged that the risk to consumers wasC > unprecedented because the glitches allow hackers to seize controlaA > of all Windows XP operating system software without requiring a0> > computer user to do anything except connect to the Internet. >1F > You know it's bad if a Microsoft spokesman calls an MS security holeE > "unprecedented", they usually play them down as much as possible. IoI > don't think that can be described as "glitches", personally. And it wasdH > known about for five weeks before MS released a patch. To matters evenH > worse, go check out www.grc.com's stuff on the WXP raw sockets issues,I > and look at Microsoft's excuses for not fixing that problem. Apparentlye9 > it's OK because it's so much harder to break into XP...n >h > Shanes   ------------------------------   End of INFO-VAX 2001.710 ************************