1 INFO-VAX	Sat, 22 Dec 2001	Volume 2001 : Issue 708       Contents:  Re: "You must think in Russian."  Re: "You must think in Russian."5 Any Ohio State football fans?  Remember Joe Germiane? > 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 seaJ Re: Buffer Overflows - again Was: (Re: Congratulations for the festive seaP Re: Buffer Overflows - again Was: (Re: Congratulations for the festive sea festiP Re: Buffer Overflows - again Was: (Re: Congratulations for the festive sea seaseE Re: Buffer Overflows - again Was: (Re: Congratulations for thefestive P Re: Buffer Overflows - again Was: (Re: Congratulations for thefestive  sea  seasI Re: Buffer Overflows - again Was: (Re: Congratulations for thefestive sea P Re: Buffer Overflows - again Was: (Re: Congratulations for thefestive sea seaseaH Re: Buffer Overflows - again Was: (Re: Congratulations for thefestiveseaH Re: Buffer Overflows - again Was: (Re: Congratulations for thefestiveseaH Re: Buffer Overflows - again Was: (Re: Congratulations for thefestiveseaH Re: Buffer Overflows - again Was: (Re: Congratulations for thefestiveseaH Re: Buffer Overflows - again Was: (Re: Congratulations for thefestivesea2 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 season5 Re: Current timetable for HP/CPQ shareholder voting ?   Re: CXX and the Hobbyist license$ Re: Excitement -- and disappointment$ Re: Excitement -- and disappointment$ Re: Excitement -- and disappointment1 Re: historical evidence of what went wrong at DEC 1 Re: historical evidence of what went wrong at DEC 0 Re: HP admits it will kill VMS if merger suceeds0 Re: HP admits it will kill VMS if merger suceeds0 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 suceeds0 Re: HP admits it will kill VMS if merger suceedsE Re: Maintaining date file created attribute when creating an archives ) Microsoft addresses security issues in XP P More CLIUTL Wish List items (was Re: SUBMIT/AFTER/HOLD (was: RE: DCL day of the  Re: More than Ctrl-Alt-Del- MPE-Tru64 compromise?  VMS-HPux new platform? " OPC$ENABLE_LOGFILE? and 7.3 - bug?* Open Source CORBA now available on OpenVMS Re: OpenVMS Handed a Lifeline : OT: FBI & Pentagon Quiz Microsoft Over Windows XP Problems. Re: OT: Windows XP, biggest security hole yet.; 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) G Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations P Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the fest 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: Strange quorum disk problem 7 Re: VMS missing features (was how to do deamons on VMS) 7 Re: VMS missing features (was how to do deamons on VMS) 7 Re: VMS missing features (was how to do deamons on VMS) 7 Re: VMS missing features (was how to do deamons on VMS) $ Re: VMSclusters and network switches$ Re: VMSclusters and network switches* Re: Windows XP, biggest security hole yet.* Re: Windows XP, biggest security hole yet.B [anounce] Sanity Kit for Compaq C++ V6.5 for OpenVMS Alpha systems  F ----------------------------------------------------------------------  % Date: Fri, 21 Dec 2001 19:20:45 -0500 ( From: Bill Gunshannon <bill@cs.uofs.edu>) Subject: Re: "You must think in Russian." B Message-ID: <20011221191738.R90403-100000@server2.cs.scranton.edu>  & On 20 Dec 2001, Larry Kilgallen wrote:  a > In article <3C22AB3A.BEFA79CB@cablespeed.com>, Chuck McCrobie <mccrobie@cablespeed.com> writes: C > > Wow!  I must be the only one who doesn't have a symbol for "set 
 > > default".  >  > You are not. >   B This may come as a complete surprise to many people here, but evenA though I have more experience and feel much more comfortable with B Unix style commands, I also do not have a symbol for "set default"> or any other VMS command and agree that it is a very bad idea.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |> Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------    Date: 21 Dec 2001 18:53:47 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) ) Subject: Re: "You must think in Russian." 3 Message-ID: <o5NRTLQRo7MJ@eisner.encompasserve.org>   m In article <20011221191738.R90403-100000@server2.cs.scranton.edu>, Bill Gunshannon <bill@cs.uofs.edu> writes: ( > On 20 Dec 2001, Larry Kilgallen wrote: > b >> In article <3C22AB3A.BEFA79CB@cablespeed.com>, Chuck McCrobie <mccrobie@cablespeed.com> writes:D >> > Wow!  I must be the only one who doesn't have a symbol for "set >> > default". >> >> You are not.  >> > D > This may come as a complete surprise to many people here, but evenC > though I have more experience and feel much more comfortable with D > Unix style commands, I also do not have a symbol for "set default"@ > or any other VMS command and agree that it is a very bad idea.  C Please don't presume that we make assumptions about your habits :-)   @ My own reasoning, now that you bring it up, is that I want to be? fully functional on someone else's machine.  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 the5 EDIT/TECO command.  (Yes, DEFINE TEC$INIT 128 works.)    ------------------------------    Date: 21 Dec 2001 19:01:45 -0800( From: bob@instantwhip.com (Bob Ceculski)> Subject: Any Ohio State football fans?  Remember Joe Germiane?= Message-ID: <d7791aa1.0112211901.7c640413@posting.google.com>    Merry Christmas everyone!   ! click on this ... it is hilarious    http://www.joegermaine.net/    ------------------------------    Date: 21 Dec 2001 17:52:56 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) G Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the 3 Message-ID: <R838r6rk6EzU@eisner.encompasserve.org>    In article <Pine.NXT.4.50.0112211312160.6883-100000@Tomobiki-Cho.CAC.Washington.EDU>, Mark Crispin <mrc@CAC.Washington.EDU> writes: * > On Fri, 21 Dec 2001, Hoff Hoffman wrote:  K >>   If you believe you have encountered a security problem, please contact M >>   a Compaq representative directly.  In deference to the security of other E >>   OpenVMS users, please do not post security problem reports here.  > K > This should be a call to arms to post those problems.  After all, that is L > what UNIX and Windows users have been suffering for years.  Why should VMS > users be treated specially?   I Because with the VMS customer base and vendor speed at releasing patches, H this system has worked well for years.  I would side with you if VMS hadH the track record of Microsoft.  We just received VMS Mandatory Update #3G this fall.  That numbering sequence started about 10 years ago, roughly ? when Windows NT was released.  What number is Microsoft up to ?   ? If your only tool is a hammer, every problem looks like a nail.   D Other generalizations that should not be made about VMS just because- they are true on other operating systems are:    	1. You need a virus scanner  ; 	2. Reinstalling the operating system often solves problems   : 	3. You always need to tighten security from the defaults.   ------------------------------    Date: 21 Dec 2001 18:27:05 -0500- From: viro@weyl.math.psu.edu (Alexander Viro) S Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the festive sea * Message-ID: <a00gg9$iqo@weyl.math.psu.edu>  3 In article <gIw7WGLS6HWI@eisner.encompasserve.org>, , Rob Young <young_r@encompasserve.org> wrote: > E >	It sounds like you are trying to insert your own code somewhere and H >	run it.  That is how I am interpreting this:  "instead of putting yourC >	code into buffer".  This code you would attempt to run or exploit D >	has to be written somewhere.  If you write it in a data PSECT, youA >	can't run it.  If you attempt to write it in a code section, it H >	won't let you.  Hence "buffer overflow" exploits are nearly impossible >	on Alpha VMS.  > E >	Are you attempting to exploit (buffer overflow) an existing program ' >	on VMS?  Go from theory to example...   9 Sigh...  What is it with illiterate weenies of all sorts?   H Let me repeat it in slowly.  Making data segment non-executable does notJ make buffer overruns less harmful.  What it _does_ provide is a protectionH against one class of attacks, namely ones that place code to be executed directly into the buffer.   J However, program that is vulnerable to attacks of that class is vulnerableF to slightly different sort of attacks.  One that is _not_ prevented by# having data segment non-executable.   I Search the bugtraq archives.  Find any instance of the (recurring) thread E with "non-executable stack" in subject.  Read it.  Think for a while. F Notice that while details depend on calling conventions, vulnerability5 itself is pretty much the same, regardless of the OS.   J There are systems (including several Unices, BTW) that have non-executableG stack and data segments.  There are patches that provide that for other J systems.  And there are half-literate advocates that happily claim that itJ makes $OS more secure.  Bullshit.  Stack-smashing is stack-smashing and ifJ your program allows it - it can be tricked into doing what attacker wants. With priveleges it's run with.   --  % Fairy Tails start "Once upon a time." ) Army/Sea stories start "This is no shit."  Software proposals start "1.0."  				Joe Zeff in the Monastery    ------------------------------    Date: 21 Dec 2001 17:33:25 -0800( From: bob@instantwhip.com (Bob Ceculski)S Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the festive sea = Message-ID: <d7791aa1.0112211733.20889850@posting.google.com>   _ viro@weyl.math.psu.edu (Alexander Viro) wrote in message news:<a00gg9$iqo@weyl.math.psu.edu>... 5 > In article <gIw7WGLS6HWI@eisner.encompasserve.org>, . > Rob Young <young_r@encompasserve.org> wrote: > > G > >	It sounds like you are trying to insert your own code somewhere and J > >	run it.  That is how I am interpreting this:  "instead of putting yourE > >	code into buffer".  This code you would attempt to run or exploit F > >	has to be written somewhere.  If you write it in a data PSECT, youC > >	can't run it.  If you attempt to write it in a code section, it J > >	won't let you.  Hence "buffer overflow" exploits are nearly impossible > >	on Alpha VMS.  > > G > >	Are you attempting to exploit (buffer overflow) an existing program ) > >	on VMS?  Go from theory to example...  > ; > Sigh...  What is it with illiterate weenies of all sorts?  > J > Let me repeat it in slowly.  Making data segment non-executable does notL > make buffer overruns less harmful.  What it _does_ provide is a protectionJ > against one class of attacks, namely ones that place code to be executed > directly into the buffer.  > L > However, program that is vulnerable to attacks of that class is vulnerableH > to slightly different sort of attacks.  One that is _not_ prevented by% > having data segment non-executable.  > K > Search the bugtraq archives.  Find any instance of the (recurring) thread G > with "non-executable stack" in subject.  Read it.  Think for a while. H > Notice that while details depend on calling conventions, vulnerability7 > itself is pretty much the same, regardless of the OS.  > L > There are systems (including several Unices, BTW) that have non-executableI > stack and data segments.  There are patches that provide that for other L > systems.  And there are half-literate advocates that happily claim that itL > makes $OS more secure.  Bullshit.  Stack-smashing is stack-smashing and ifL > your program allows it - it can be tricked into doing what attacker wants.  > With priveleges it's run with.  N You said the magic word ... privs ... this isn't windoze ... without VMS privsI you can't run a pot of beans ... are you saying you can create privs for  7 your app on vms without having them in the first place?    ------------------------------    Date: 21 Dec 2001 17:37:16 -0800( From: bob@instantwhip.com (Bob Ceculski)S Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the festive sea = Message-ID: <d7791aa1.0112211737.35b11ad5@posting.google.com>    Mark Crispin <mrc@CAC.Washington.EDU> wrote in message news:<Pine.NXT.4.50.0112211312160.6883-100000@Tomobiki-Cho.CAC.Washington.EDU>...* > On Fri, 21 Dec 2001, Hoff Hoffman wrote:K > >   No myth.  No legend.  OpenVMS can potentially be and has occasionally I > >   actually been found to be vulnerable to security problems resulting 0 > >   from buffer overrun errors.  This is fact. >  > So far, so good. > L > >   If you believe you have encountered a security problem, please contactN > >   a Compaq representative directly.  In deference to the security of otherF > >   OpenVMS users, please do not post security problem reports here. > K > This should be a call to arms to post those problems.  After all, that is L > what UNIX and Windows users have been suffering for years.  Why should VMS > users be treated specially?  >  > -- Mark -- > ! > http://staff.washington.edu/mrc H > Science does not emerge from voting, party politics, or public debate.  M are you saying you can overflow buffers on vms and create privs you never had J to begin with?  this isn't windoze you know, you need privs to do anything
 on vms ...   ------------------------------    Date: 21 Dec 2001 21:34:10 -0500- From: viro@weyl.math.psu.edu (Alexander Viro) S Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the festive sea * Message-ID: <a00rf2$j85@weyl.math.psu.edu>  = In article <d7791aa1.0112211733.20889850@posting.google.com>, ) Bob Ceculski <bob@instantwhip.com> wrote:   O >You said the magic word ... privs ... this isn't windoze ... without VMS privs J >you can't run a pot of beans ... are you saying you can create privs for 8 >your app on vms without having them in the first place?  ? 	If your MUA got a buffer overrun in parsing headers (hi, Mark) C it almost definitely will have enough privs to send the contents of F your mailbox to attacker.  Or to leave it in a world-readable file, so& that (local) attacker could get to it.  K The point being: OS can't save you from consequences of sloppy programming. C If you believe otherwise - thanks for letting everyone know, now we  know to avoid your programs.  F No comments on Windows - so far I've successfully avoided interactions with that animal...    --  8 "You're one of those condescending Unix computer users!"B "Here's a nickel, kid.  Get yourself a better computer" - Dilbert.   ------------------------------  % Date: Fri, 21 Dec 2001 18:35:43 -0800 + From: Mark Crispin <mrc@CAC.Washington.EDU> Y Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the festive sea festitU Message-ID: <Pine.NXT.4.50.0112211759180.7301-100000@Tomobiki-Cho.CAC.Washington.EDU>f  # On 21 Dec 2001, Bob Ceculski wrote: O > are you saying you can overflow buffers on vms and create privs you never hadoL > to begin with?  this isn't windoze you know, you need privs to do anything > on vms ...  J It may surprise you, but NT has privileges just like VMS.  Perhaps you are< too young to know about the relationship between VMS and NT.  G I won't clue you in on that point (you'll have to find that out on your-I own), but I will clue you in on how security gets broken.  It has nothingfC to do with a user task getting corrupted by something like a buffer 	 overflow.f  H It has everything to do with a privileged task being subverted to do theI bad guy's bidding.  One of many ways is to cause a buffer overflow in theeI privileged task.  Another way is to identify a flaw in the means by whicheF a privileged task determines the authorization of a user request.  YetH another is to hide an unauthorized payload inside an authorized request.  G I'm only scratching the surface here, but you should be able to get theu gist.e  
 -- Mark --   http://staff.washington.edu/mrceF Science does not emerge from voting, party politics, or public debate.   ------------------------------  # Date: Fri, 21 Dec 2001 23:58:03 GMTe2 From: Arthur Krewat <krewat@bartek.dontspamme.net>Y Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for the festive sea sease 5 Message-ID: <3C23CB7E.B77E043C@bartek.dontspamme.net>    Alexander Viro wrote:e > J > Let me repeat it in slowly.  Making data segment non-executable does notL > make buffer overruns less harmful.  What it _does_ provide is a protectionJ > against one class of attacks, namely ones that place code to be executed > directly into the buffer.e  I I think the problem is he doesn't realize there is another sort of buffer B exploit that doesn't involve running your own code on the machine.  N For example, a very simple piece of C code that shows a buffer exploit without) having to actually run code on the stack:e   void hole(char *url) { 	char tempurl[512];n, 	char flags;	/* 1=admin, 2=guest, 4=wheel */
 	char *p,*p2;i	 	int i=0;    	p=tempurl; p2=url;g 	while (*p2) *p++=*p2++;  ; 	{lots of other code that uses the flags to do things with}a }a  E Then, call hole with 513 char URL with the last character being ASCII E code for "1". This will fill flags with (octal) 61 and the admin flag  will be set.   aak    ------------------------------    Date: 21 Dec 2001 20:32:25 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)tN Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for thefestive3 Message-ID: <SjBxss1VO98d@eisner.encompasserve.org>g   In article <Pine.NXT.4.50.0112211635190.7051-100000@Tomobiki-Cho.CAC.Washington.EDU>, Mark Crispin <mrc@CAC.Washington.EDU> writes:i* > On Fri, 21 Dec 2001, Hoff Hoffman wrote:J >>   Yes, security through obscurity is clearly not reliable.  Regardless,G >>   it can be a very definite (temporary) advantage to you and to youre+ >>   systems, and to the systems of others.  >  > You missed the point.  > F > Yes, if you can get away with quietly fixing a security problem thatD > you discovered, and nobody else knows about, it certainly is quite0 > tempting to sit on it for as long as possible.  2 Have you any examples of that being done for VMS ?  K > Having done so, you can't claim that the system is "more secure" than the H > one which has had its security bugs exposed.  After all, you were just! > lucky enough not to get caught.a  D If you claim the volume of unproclaimed security defects in VMS even: begins to approach that for Windows, please provide proof.  ? Certainly that is theoretically possible, but given the serioust@ approach they have taken to known security defects, I do not see it as being true.    ------------------------------  % Date: Fri, 21 Dec 2001 14:25:25 -0800s+ From: Mark Crispin <mrc@CAC.Washington.EDU> Y Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for thefestive  sea  seasiU Message-ID: <Pine.NXT.4.50.0112211422100.6928-100000@Tomobiki-Cho.CAC.Washington.EDU>   & On Fri, 21 Dec 2001, Alan Greig wrote:	 > I don'toQ > believe anyone should publicise full details of exploits, if not already in the * > public domain, for any operating system.  E Regardless of whether or not you or I believe that exploits should beeH publicized, the fact is that they are.  That's the world that we live inH today.  If VMS security bugs are shielded from publication, that rendersI into nonsense all claims of VMS being secure.  It's just security through 
 obscurity.  Q > Don't you recall TOPS-20 SPRs responses came in two flavours. The normal publicDO > ones and the confidential ones? Don't recall you demanding that security hole 8 > SPRs should have been posted to the TOPS-20 mailgroup.  A Here you are wrong.  Security hole bugs and their fixes were most!F certainly posted to the TOPS-20 group.  That was its original purpose.  
 -- Mark --   http://staff.washington.edu/mrcaF Science does not emerge from voting, party politics, or public debate.   ------------------------------  # Date: Fri, 21 Dec 2001 23:52:51 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)R Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for thefestive sea1 Message-ID: <nXPU7.335$sK3.5410@news.cpqcorp.net>      Followups to: comp.os.vms    In article <Pine.NXT.4.50.0112211422100.6928-100000@Tomobiki-Cho.CAC.Washington.EDU>, Mark Crispin <mrc@CAC.Washington.EDU> writes:>' :On Fri, 21 Dec 2001, Alan Greig wrote:eE :> I don't believe anyone should publicise full details of exploits, lA :> if not already in the public domain, for any operating system.T :oF :Regardless of whether or not you or I believe that exploits should beI :publicized, the fact is that they are.  That's the world that we live in I :today.  If VMS security bugs are shielded from publication, that rendersBJ :into nonsense all claims of VMS being secure.  It's just security through :obscurity.t  H   There have been various previous discussions on this exact topic, and F   your opinion has been quite regularly represented.  Your points are G   quite valid.  You are entirely correct that some number of so-called tE   black hats will know about security bug(s) at the speed of email.   G   (Some will quietly sit on the "best" holes, but I digress.)  And you .F   are further correct that security through obscurity is not reliable.F   I should add that I have no delusions that everyone receiving email C   from the various security mailing lists is a so-called white hat.d  G   Yes, security through obscurity is clearly not reliable.  Regardless, D   it can be a very definite (temporary) advantage to you and to yourF   systems, and to the systems of others.  Please consider the effects G   of a room full of your most untrustworthy users, and users that have AG   just told that the STOP command will bugcheck an OpenVMS system.  Do aH   you want someone to email all of your users with details of this bug, E   before somebody (else) can get you a fix for the problem?  Probably H   not.  Like other forms of what I would refer to as security courtesy, H   most folks would prefer that others not be impolite, and particularly I   that general notifications of security problems not occur before a fix eH   can be obtained and loaded.  (Can we rely on courtesy?  Clearly, no.  0   Do we prefer it?  Most folks would, I expect.)  C   Some might initially find it surprising that some folks actually tC   strive for security through obscurity -- where this obscurity is eA   deliberately sought.  There are computer systems configured to tB   misrepresent themselves to various network requests, responding E   with the identity or the fingerprint of another platform.  Is this sF   a reliable protection?  Clearly not.  Does this defense stymie some H   attacks?  Clearly yes.  Does the incompleteness of the defense defeat    its value?  Nope.e  J   Widespread publication of a security hole simply means that the "script H   kiddies" learn about the bugs, and before it is possible to identify, I   create, test, and then distribute a fix or a workaround.  Meaning that m   you are exposed.  G   Most any military organization has obvious security concerns and has rE   at least a few direct corollaries to this discussion -- corollarieslB   to security through obscurity -- not the least of which involvesF   shielding details of radio frequencies and of transmitter locations.J   Hiding frequencies and transmitter locations is obviously not reliable, H   because once the AN/SPS-49A(V) radar lights up, everybody in the area K   with a working radar threat receiver knows about it.  But that knowledge  K   might be just a little too late for somebody.  And thus obscurity can be  K   a very definite -- albiet clearly temporary -- advantage.  (Consider thatqL   you had the best search radar currently available.  Would you rather show I   off its existence and its availability to your opponents, or would you tM   prefer to display an older pre-NTU AN/SPS-40 series radar until you really p8   needed to use the good stuff?  Tactics...  Tactics...)  H   Would I prefer to send every OpenVMS System Manager full details of a H   security bug or vulnerability, and as soon as it is identified?  Sure.F   (Folks here at Compaq work with CERT for just this reason.)  Would IJ   rely on obscurity for my security?  No.  But could I justify my posting J   details of an OpenVMS security problem into comp.os.vms for all to see, I   and particularly posting details prior to the availability of a fix or aI   a workaround?  Um, no.  That would be, um, discourteous in the extreme.l    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Fri, 21 Dec 2001 17:01:41 -0800q+ From: Mark Crispin <mrc@CAC.Washington.EDU>nY Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for thefestive sea seaseatU Message-ID: <Pine.NXT.4.50.0112211635190.7051-100000@Tomobiki-Cho.CAC.Washington.EDU>h  ( On Fri, 21 Dec 2001, Hoff Hoffman wrote:I >   Yes, security through obscurity is clearly not reliable.  Regardless, F >   it can be a very definite (temporary) advantage to you and to your* >   systems, and to the systems of others.   You missed the point.a  D Yes, if you can get away with quietly fixing a security problem thatB you discovered, and nobody else knows about, it certainly is quiteI tempting to sit on it for as long as possible.  Sometimes, the temptationpI even extends to fixing it in a way that someone looking at the differencesF between the old and the new code won't realize that the change fixes a security problem.1   BUT!!!  I Having done so, you can't claim that the system is "more secure" than the F one which has had its security bugs exposed.  After all, you were just lucky enough not to get caught.5  
 -- Mark --   http://staff.washington.edu/mrc(F Science does not emerge from voting, party politics, or public debate.   ------------------------------  # Date: Fri, 21 Dec 2001 23:13:03 GMTu2 From: Arthur Krewat <krewat@bartek.dontspamme.net>Q Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for thefestiveseaw5 Message-ID: <3C23C13F.45794354@bartek.dontspamme.net>	   Mark Crispin wrote:s > ( > On Fri, 21 Dec 2001, Alan Greig wrote: > > I don'trS > > believe anyone should publicise full details of exploits, if not already in thee, > > public domain, for any operating system. > G > Regardless of whether or not you or I believe that exploits should beAJ > publicized, the fact is that they are.  That's the world that we live inJ > today.  If VMS security bugs are shielded from publication, that rendersK > into nonsense all claims of VMS being secure.  It's just security throughl > obscurity.  J Mark, forget it - this is another fine example of the thinking that ruined DEC. d   aako   ------------------------------  % Date: Fri, 21 Dec 2001 23:20:57 +0000e% From: Alan Greig <a.greig@virgin.net>hQ Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for thefestiveseau* Message-ID: <3C23C3D9.D8B7828F@virgin.net>   Mark Crispin wrote:t  S > > Don't you recall TOPS-20 SPRs responses came in two flavours. The normal publiceQ > > ones and the confidential ones? Don't recall you demanding that security holes: > > SPRs should have been posted to the TOPS-20 mailgroup. >aC > Here you are wrong.  Security hole bugs and their fixes were mostmH > certainly posted to the TOPS-20 group.  That was its original purpose. >r  R Hmm, as you ran the mailing list I'll accept what you say even if I don't off-handS remember any being posted. Not that there were that many security problems - mostlytO system crashers as I recall and I don't want to suggest there were lots of themaT either! Actually come to think of it, I think I posted details of a fairly nasty bugS with crjob%, splfk% and ipcf which could be used to start up a not logged in job on Q another terminal with EXEC below your own process. Then you could trap the login%sC call from the parent and read the password. Or something like that.   O My point still stands though. It would have been one thing posting details to a6P controlled circulation mailing list and another posting them to "human-nets" for example. Or so I would argue.   O Is the TOPS-20 mail list still active btw. Last message I recall posting was an S obituary for the Dundee Tech DEC-20 which I'd like to get hold of again. That would1% have been 1992 I sent it out I guess.h  T For the record I still would have preferred to be using a 2001 TOPS-20 rather than aP 2001 VMS. I hated VMS for years in the beginning but after years of managing VMSQ alongside Unix and latterly some NT. I would still put VMS in second place behind S TOPS-20.  But that's current VMS. Not what it once was.  If VMS today was really asuR deficient as you remember it once was there really wouldn't be so many of us still	 using it.r     > -- Mark -- >p! > http://staff.washington.edu/mrcuH > Science does not emerge from voting, party politics, or public debate.   --
 Alan Greig   ------------------------------  % Date: Fri, 21 Dec 2001 16:14:15 -0800r+ From: Mark Crispin <mrc@CAC.Washington.EDU>lQ Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for thefestiveseaeU Message-ID: <Pine.NXT.4.50.0112211551030.7051-100000@Tomobiki-Cho.CAC.Washington.EDU>   & On Fri, 21 Dec 2001, Alan Greig wrote:E > > Here you are wrong.  Security hole bugs and their fixes were most J > > certainly posted to the TOPS-20 group.  That was its original purpose.E > Hmm, as you ran the mailing list I'll accept what you say even if I:I > don't off-hand remember any being posted. Not that there were that many I > security problems - mostly system crashers as I recall and I don't want1, > to suggest there were lots of them either!  A There weren't many security bugs in TOPS-20, but there were some.s  J The one that I remember best was a truly nasty security bug which I postedG to the list on May 28, 1980.  I think that I discovered it, but perhapsvE someone else called it to my attention; I no longer remember after 21rH years.  The bug was that the privileged MSFRK system call -- perhaps theH most dangerous system call in all of TOPS-20 -- made the wrong check andI thus anyone could execute it. DEC put in the fix into development sourcesnJ on June 2, 1980, but who knows how long it took before word got out to the full customer base?   D > My point still stands though. It would have been one thing postingF > details to a controlled circulation mailing list and another posting8 > them to "human-nets" for example. Or so I would argue.  H That war is long lost.  If the VMS world hasn't had to face that realityE yet, it should; maybe then we'd hear fewer claims about VMS security.   G There are several open mailing lists to discuss security bugs *and post:G exploits of the bug*.  You're supposed to give the developer a heads-upeG and a few days to make a fix and get it out before posting, but lots ofhE the kiddies are more concerned with counting coup than such niceties.oI You can be sure that once a bug is posted, the script kiddie attacks will  start in a matter of hours.n  J Your VMS system may have a known gaping hole a mile wide, and you had justJ better hope that everyone who is privy to that information guards it well.  , > Is the TOPS-20 mail list still active btw.   Yes.  
 -- Mark --   http://staff.washington.edu/mrcaF Science does not emerge from voting, party politics, or public debate.   ------------------------------    Date: 21 Dec 2001 17:52:41 -0800( From: bob@instantwhip.com (Bob Ceculski)Q Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for thefestivesea.= Message-ID: <d7791aa1.0112211752.4a39c93c@posting.google.com>l  W Alan Greig <a.greig@virgin.net> wrote in message news:<3C23C3D9.D8B7828F@virgin.net>...e > Mark Crispin wrote:n > U > > > Don't you recall TOPS-20 SPRs responses came in two flavours. The normal publiceS > > > ones and the confidential ones? Don't recall you demanding that security holei< > > > SPRs should have been posted to the TOPS-20 mailgroup. > >sE > > Here you are wrong.  Security hole bugs and their fixes were most-J > > certainly posted to the TOPS-20 group.  That was its original purpose. > >  > T > Hmm, as you ran the mailing list I'll accept what you say even if I don't off-handU > remember any being posted. Not that there were that many security problems - mostly Q > system crashers as I recall and I don't want to suggest there were lots of themnV > either! Actually come to think of it, I think I posted details of a fairly nasty bugU > with crjob%, splfk% and ipcf which could be used to start up a not logged in job ondS > another terminal with EXEC below your own process. Then you could trap the login%aE > call from the parent and read the password. Or something like that.o > Q > My point still stands though. It would have been one thing posting details to apR > controlled circulation mailing list and another posting them to "human-nets" for > example. Or so I would argue.; > Q > Is the TOPS-20 mail list still active btw. Last message I recall posting was anwU > obituary for the Dundee Tech DEC-20 which I'd like to get hold of again. That would ' > have been 1992 I sent it out I guess.i > V > For the record I still would have preferred to be using a 2001 TOPS-20 rather than aR > 2001 VMS. I hated VMS for years in the beginning but after years of managing VMSS > alongside Unix and latterly some NT. I would still put VMS in second place behindBU > TOPS-20.  But that's current VMS. Not what it once was.  If VMS today was really asOT > deficient as you remember it once was there really wouldn't be so many of us still > using it.C >  >  > > -- Mark -- > >p# > > http://staff.washington.edu/mrc J > > Science does not emerge from voting, party politics, or public debate.  O but isn't this guy saying he can overflow a buffer on vms and create privilegesrL that he may of never of had to begin with?  Like you stated above w/the execH priv ... this isn't windoze ... you need privs on vms to do anything ...   ------------------------------  % Date: Fri, 21 Dec 2001 22:15:48 -0500b From: gce <ge@gce.com>Q Subject: Re: Buffer Overflows - again Was: (Re: Congratulations for thefestiveseaa' Message-ID: <3C23FAE4.5F4073EF@gce.com>o  M Ahh, but in fact the number of such problems is also very small for reasons I  have elaborated.  N Go check out the recent Schneier editorials on full disclosure: it got startedM because people DID sit on bugs and not fix them. That does not happen in VMS.h
 I've seen it.w  J I tend to favor disclosure in any case, but realize your arguments are not based on fact.   Mark Crispin wrote:n > * > On Fri, 21 Dec 2001, Hoff Hoffman wrote:K > >   Yes, security through obscurity is clearly not reliable.  Regardless,5H > >   it can be a very definite (temporary) advantage to you and to your, > >   systems, and to the systems of others. >  > You missed the point.  > F > Yes, if you can get away with quietly fixing a security problem thatD > you discovered, and nobody else knows about, it certainly is quiteK > tempting to sit on it for as long as possible.  Sometimes, the temptation K > even extends to fixing it in a way that someone looking at the differenceyH > between the old and the new code won't realize that the change fixes a > security problem.r >  > BUT!!! > K > Having done so, you can't claim that the system is "more secure" than thenH > one which has had its security bugs exposed.  After all, you were just! > lucky enough not to get caught.P >  > -- Mark -- > ! > http://staff.washington.edu/mrciH > Science does not emerge from voting, party politics, or public debate.   ------------------------------  # Date: Fri, 21 Dec 2001 21:54:51 GMTe4 From: "Terry C. Shannon" <terryshannon@mediaone.net>; Subject: Re: Compaq still tries to spin Alphacide both waysi> Message-ID: <LcOU7.24471$Sj1.12315470@typhoon.ne.mediaone.net>  6 "Wilko Bulte" <wkb@freebie.xs4all.nl> wrote in message: news:3c23ae8a$0$11266$e4fe514c@tyrannewsaurus.xs4all.nl...8 > In <yga1yhofxbz.fsf@severn.office.aol.com> Joel Gallun$ <root@localhost.localdomain> writes: >:- > >nmm1@cus.cam.ac.uk (Nick Maclaren) writes:i > F > >> Note that by "the EVx" I am also referring to chipsets and so on,F > >> without which the chip is useless and cannot support faster clockD > >> speeds even on the same chip - witness the 1 GHz Alpha and ES45 > >> shambles. >t@ > >Do tell! I lived (still living it, actually) through the ES40D > >disaster, but don't have any experience with the ES45. The site I >n2 > Which ES40 disaster? What is so bad about those? >g  G The ES40 motherboard and crossbar chipset would not support a 1GHz EV68iL upgrade. Not exactly a disaster, but I am sure it PO'd some customers. WhichH has not prevented the ES45 from being the most-popular platform in Alpha history.   ------------------------------  # Date: Fri, 21 Dec 2001 22:18:03 GMT 2 From: Arthur Krewat <krewat@bartek.dontspamme.net>3 Subject: Re: Congratulations for the festive seasone5 Message-ID: <3C23B4A2.54C610CA@bartek.dontspamme.net>    Eric Smith wrote:e > 6 > Arthur Krewat <krewat@bartek.dontspamme.net> writes:M > > C is not the cause of the bugs - the cause is the weenies that think they 2 > > know how to write software after they learn C. > E > That's like saying that the old table saw that's missing the fingerdG > guard isn't responsible for cutting off the owner's fingers, it's theoG > owner's fault.  Yes, it *is* the owners fault, but mainly for keepingh8 > and using a broken tool that is prone to such problems  H Either way, they are weenies. If the moron didn't have his finger under F or near the blade, he wouldn't cut off his fingers, would he? The onlyH reason for the finger guard is to protect stupid people. While it's niceE to be able to use the saw and not worry about where my fingers are, I A still keep my fingers away... (ok, so the finger guard also keeps I pieces of wood from flying in your face, but you should be wearing safetyoI goggles - and if the blade splits, that little rinky-dink finger guard ist< going to shatter and let the blade fragment hit you anyway)   H > Sure, the programmer has responsibility for bugs and security holes inG > his code.  But when you use a stupid language that don't provide evennI > the most trivial of protection from stupid buffer overrun problems, I'diA > have to conclude that the language is at fault as well.  So thecI > programmer should be blamed not just for writing bad code, but also for. > choosing poor tools.  C The only thing I can say is who the hell writes code without boundseG checking built in? Yeah, read a GET command from a socket where the URLoH is 10K long. My buffer is only 512 chars. Do I just blindly write a loopC that just goes until it hits NULL or do I stop at 511? Stop at 511.eJ Anyone writing a loop that doesn't check for itself, well, they're puttingF their fingers too close to the blade and deserve to have their fingers	 cut off. r  I > Some people think that it's a good thing to use compilers that generateaF > no run-time error checking (for array bounds and such), because it'sE > more efficient.  When given a language or compiler that can supportdH > run-time error checking, they may use it for debug then disable it forI > production.  That's like practicing the use of life preservers on solidoK > ground, then leaving them behind when you set out to sea, because they'ret > too heavy.  L Ok, so it's the programmer's fault he left behind the life preserver, right?@ Learn to swim (meaning, write code that checks it's own bounds).  H > So maybe the C language isn't to blame for software security problems,F > just as the broken table saw isn't to blame for cutting off fingers.H > But just as any sensible workman would fix or replace the broken tableB > saw rather than continuing to use it and risking losing fingers,H > programmers should fix or replace the C language, or we'll keep having# > these software security problems.a  F In some cases I have purposely removed the finger guard and still haveG all 10 fingers. I'm not stupid enough to put my fingers near the blade.s  E Again, any decent programmer should realize the compiler is not going 4 to check for them and they have to do it themselves.  C > It's possible to write bad code in any programming language.  ButtD > there's no excuse for using tools that don't try to catch the mostG > obvious bugs, or for using languages that are so poorly designed thati/ > such problems can't be detected by the tools.u  D There's no excuse for people that would write a loop against a fixed6 size array and never check if they are out of bounds.   A This is like the teenager that can't accept they are at fault for-D their problems. Everyone else is at fault. It should have been builtB into the compiler. The runtime-library should check it for me ... = uh, the processor should just allow me to write to location 0-, because I got a NULL pointer... ad infinitum  B Instead, recognize that most buffer overrun exploits are from justB plain stupidity and give it up already. The stuff is written in C.B The programmers should realize this and program accordingly. There is no excuse for this crap.E   aak    ------------------------------  % Date: Fri, 21 Dec 2001 22:46:51 +0000t% From: "a.carlini" <arcarlini@iee.org> 3 Subject: Re: Congratulations for the festive season & Message-ID: <3C23BBDB.77558EF@iee.org>   Arthur Krewat wrote:  > Either way, they are weenies.   ' Sadly, whether you like it or not, the c& weenies seem to be writing mucho code.  & > The only thing I can say is who the ! > hell writes code without boundsl > checking built in? i  * Well obviously someone does - and he seems to do it quite a bit :-)  ' > This is like the teenager that can't n > accept they are at fault for > their problems.   % No. These bug-writers may well acceptd' their faults and learn from them quite s' quickly. They just get replaced by new a' bug-writers. Or maybe they really don'ty$ learn. Either way, there are enough ! bug-writers around that the bladea guards are clearly necessary.   ! OTOH if we had blade guards, somel other style of bug (that is not-% caught by the safety net) would come 2  to the fore and bite us. That, I$ guess, is what evolution teaches us.   Antonioc   -- B   ---------------g- Antonio Carlini             arcarlini@iee.orgw   ------------------------------    Date: 21 Dec 2001 18:04:01 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)i3 Subject: Re: Congratulations for the festive seasonl3 Message-ID: <IwhmnQbvl04g@eisner.encompasserve.org>e  f In article <qhk7vgmfdc.fsf@ruckus.brouhaha.com>, Eric Smith <eric-no-spam-for-me@brouhaha.com> writes:6 > Arthur Krewat <krewat@bartek.dontspamme.net> writes:L >> C is not the cause of the bugs - the cause is the weenies that think they1 >> know how to write software after they learn C.s > E > That's like saying that the old table saw that's missing the finger.G > guard isn't responsible for cutting off the owner's fingers, it's theuG > owner's fault.  Yes, it *is* the owners fault, but mainly for keepinge8 > and using a broken tool that is prone to such problems > H > Sure, the programmer has responsibility for bugs and security holes inG > his code.  But when you use a stupid language that don't provide evenoI > the most trivial of protection from stupid buffer overrun problems, I'dhA > have to conclude that the language is at fault as well.  So theyI > programmer should be blamed not just for writing bad code, but also forO > choosing poor tools.  ? Sometimes, of course, it is the PHB that chooses the languages, @ based on "popularity".  Have you noticed how many more Yugos are on the road than Rolls Royces ?   C > It's possible to write bad code in any programming language.  ButrD > there's no excuse for using tools that don't try to catch the mostG > obvious bugs, or for using languages that are so poorly designed thate/ > such problems can't be detected by the tools.  > E > There are plenty of programming languages out there that don't have B > these problems.  Some of them are just as efficient as C for all! > practical intents and purposes.   > In particular, some compilers which use the same back end have@ produced the same object code when the same algorithm is written in C and another language.   ------------------------------    Date: 21 Dec 2001 18:05:28 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) 3 Subject: Re: Congratulations for the festive season 3 Message-ID: <Fuaie0VLdzyI@eisner.encompasserve.org>w  j In article <3C23B4A2.54C610CA@bartek.dontspamme.net>, Arthur Krewat <krewat@bartek.dontspamme.net> writes: > Eric Smith wrote:h >> o7 >> Arthur Krewat <krewat@bartek.dontspamme.net> writes:0N >> > C is not the cause of the bugs - the cause is the weenies that think they3 >> > know how to write software after they learn C.l >> eF >> That's like saying that the old table saw that's missing the fingerH >> guard isn't responsible for cutting off the owner's fingers, it's theH >> owner's fault.  Yes, it *is* the owners fault, but mainly for keeping9 >> and using a broken tool that is prone to such problemso > J > Either way, they are weenies. If the moron didn't have his finger under ? > or near the blade, he wouldn't cut off his fingers, would he?   3 But with C you can go for _other_people's_ fingers.r   ------------------------------  % Date: Fri, 21 Dec 2001 19:35:05 -0500g  From: John Santos <JOHN@egh.com>3 Subject: Re: Congratulations for the festive seasonm6 Message-ID: <1011221190540.59837B-100000@Ives.egh.com>  ( On Fri, 21 Dec 2001, Mark Crispin wrote:  - > On Fri, 21 Dec 2001, John J Francini wrote: J > > Hence, buffer overflows and other nastiness.  This philosophy is by NOO > > MEANS restricted to Unix; it is very much evident in Microsoft-written OSesaM > > and applications (like Exchange, IIS, and many others), as well as plentym > > of other products. > J > Including VMS.  The reason why there aren't many buffer overflow attacksJ > on VMS is that the target is uncommon and uninteresting to the bad guys., > It's a form of security through obscurity. > H > If VMS had achieved the level of success that UNIX did, and UNIX fadedJ > into obscurity the way VMS did, then CERT bulletins would be filled withL > the latest VMS buffer overflow attacks, and UNIX users would be snickering > about VMS insecurity.o  B This turns out not to be the case.  Most VMS languages use countedA strings and the OTS routines that do string copies that check the @ counts when copying to fixed-length buffers, and truncate and/orA warn you (but never, ever write past the end of the destination.)tE This philosophy has been present since day one - ever notice the veryo7 non-RISCy MOVC5 instruction in the VAX instruction set?"  C Sure this hurts performance sometimes: you have to store, maintain,SB check and pass around all those pesky counts, and you can't do the@ cheap trick of copy bytes until you hit a <nul> in a tight loop.B Instead you have to compare source and destination sizes, set your? loop counter to the minimum, and copy.  Sometimes you don't get B to stop early if the source string is short, since you may need to@ fill the destination.  On the other hand, <nul> is not a special? character in strings.  (In-band flow control is generally a bade idea.)  6 But what's a few nano-seconds if it saves you hours ofB crash/reboot/recovery time and debugging?  Especially when the fixA is to manually insert code that does the same bounds checking, in  a less efficient manner?  > Most (all?) exceptions to the above are in C programs that use> <nul>-terminated strings, and most of those were imported fromA Unix, so I don't understand why the Unix users would be laughing.c= I think they would be too busy fixing their own systems to be  worrying about others.  B Or maybe if the implementors of most of the public-domain software> (TCP/IP, etc., etc.) had grown up on VMS instead of Unix, theyC would have been dismayed on discovering the lack of buffer overflowi> protection in the usual C libraries and would have insisted on< (or implemented themselves) a standard set of counted string? functions that everyone would use, and would have soon acquiredgD direct support in ANSI C (for counted string literals and constants)A and buffer overflow attacks on Unix would be a thing of the past.    > -- Mark -- > ! > http://staff.washington.edu/mrcSH > Science does not emerge from voting, party politics, or public debate.   -- n John Santosc Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------    Date: 21 Dec 2001 17:24:36 -08003 From: Eric Smith <eric-no-spam-for-me@brouhaha.com>a3 Subject: Re: Congratulations for the festive seasonu0 Message-ID: <qhpu58rqqz.fsf@ruckus.brouhaha.com>  4 Arthur Krewat <krewat@bartek.dontspamme.net> writes:H > In some cases I have purposely removed the finger guard and still haveI > all 10 fingers. I'm not stupid enough to put my fingers near the blade.f  F That's exactly my point.  If you sell table saws with no finger guardsG to experts, they *usually* won't cut their fingers off.  It will happen G occasionally.  If you sell them to the vast unwashed masses, it's goingmD to happen frequently.  So a vendor selling table saws with no fingerG guards is considered to be somewhat irresponsible, even though it's thea! end user that is really at fault.   F Similarly, you can expect that expert C programmers will usually writeG appropriate bounds checking, while the unwashed masses of C programmers F will not.  Guess which group writes the majority of code?  Given that,8 are you really willing to claim that C is not a problem?  H It's been known since the 1960s that there are certain classes of common? errors that programmers make, and that it is possible to design C languages such that many of them are caught at compile time.  It iswE really a crock that brain-damaged languages like C and C++ became the ! standards in the 1980s and 1990s./  H Computers are supposed to be labor-saving devices.  Since it is entirelyH possible and even easy to design a programming language that can supportF bounds checking, how can anyone maintain that it is a good idea to useF a language that can't, and thus shift that burden onto the programmer?  E Note that I'm not criticizing C when used as was originally intended, G for systems programming hosted on and targeted to small computers.  ButrG it's completely inappropriate for modern systems.  Even when developing3A for small embedded systems, the development is normally hosted onr? machines with plenty of memory and CPU cycles, on which using ac> cross-compiler for a reasonable language is entirely feasible.   ------------------------------  # Date: Sat, 22 Dec 2001 01:28:40 GMTt4 From: enders@bolshoi.cc.misu.nodak.edu (Todd Enders)3 Subject: Re: Congratulations for the festive seasonn> Message-ID: <clRU7.183955$kf1.56549047@news1.rdc1.ne.home.com>  A In <3C23B4A2.54C610CA@bartek.dontspamme.net> Arthur Krewat wrote:c  D > Instead, recognize that most buffer overrun exploits are from justD > plain stupidity and give it up already. The stuff is written in C.D > The programmers should realize this and program accordingly. There > is no excuse for this crap.r > J 	This is the most profoundly cogent comment on programming I've seen in a  *long* time.H The textbooks and programming instructors *NEVER* drive this point home 
 enough.  Kids M take programming classes, and basically learn to write crap code.  Been that n
 way for quitewH some years now, from what I've seen.  They graduate with their shiny CS  degree, and goM to work writing the same crap code.  And it comes back to bite us all in the a end.   Todd   ------------------------------  % Date: Fri, 21 Dec 2001 17:32:40 -0800g+ From: Mark Crispin <mrc@CAC.Washington.EDU>s3 Subject: Re: Congratulations for the festive seasonnU Message-ID: <Pine.NXT.4.50.0112211717560.7143-100000@Tomobiki-Cho.CAC.Washington.EDU>   ' On Fri, 21 Dec 2001, John Santos wrote:nD > This turns out not to be the case.  Most VMS languages use countedC > strings and the OTS routines that do string copies that check theoB > counts when copying to fixed-length buffers, and truncate and/orC > warn you (but never, ever write past the end of the destination.)    Truncate???b  I Oh dear, oh my.  There's a whole class of attacks relating to truncation.:  
 -- Mark --   http://staff.washington.edu/mrcsF Science does not emerge from voting, party politics, or public debate.   ------------------------------  % Date: Fri, 21 Dec 2001 21:05:38 -0500o From: gce <ge@gce.com>3 Subject: Re: Congratulations for the festive season>' Message-ID: <3C23EA72.48874137@gce.com>l   Not so. J The reason for the lack of buffer overflows is due to a number of factors.J One: VMS habitually has used descriptors to pass strings, which have sizesK passed. (Contrast windows NT and successors. Take a look at the ntifs.h and6I you will find numerous input arguments which are null terminated strings,WI some even which are arrays of such, terminated by a second null.These arepF sitting like time bombs waiting to cause trouble, and will not readilyI be removed by automated tools pulled from the public domain or internally:J written that find gets() and friends. As a rule input string size is NEVERG available, and many of the APIs are security critical. VMS OTOH must beaG searched long and hard to find any such cases, thanks to the insistenceeF on descriptors. It may have been a pain but it was pain with a payoff.  L Two: The process that creates VMS asks about security and customer data, notK just by code review, but asks at investigation time, at design review time,,H at function spec time, and at code review time. This makes it relatively6 hard to slip things by. The culture insists on polish.  M Three: Much of VMS has been to the wars, gotten badly hurt, and been replaced . so that much has changed since V1, V2, or V3.   M THAT is why VMS gets so few problems. If it were hit harder, a few more mightpL surface, but the "today's Nth critical security flaw" you see in Windows, orL the "this week's Nth flaw" that happens in Linux at times would still IMO beL rare, as it is with OpenBSD, for the same reasons: the people writing the OSK care deeply about getting security right and are damn good at what they do.i    P If you take code written by careful people watching out for one another, you getH a better result than you get with code written by careless folks workingJ separately. Less code, generally, but FAR less problems down the road. NorJ am I sure that over the very long haul you get less code, since ultimately$ crappy code needs to be redone more.  J The claim below amounts to "all coders are equal" in security results. ButI some companies foster care, others foster carelessness. This makes coderswG unequal, and we should be able to figure out which way works better forr	 security.  Glenn Everhart     Mark Crispin wrote:  > - > On Fri, 21 Dec 2001, John J Francini wrote:tJ > > Hence, buffer overflows and other nastiness.  This philosophy is by NOO > > MEANS restricted to Unix; it is very much evident in Microsoft-written OSesoM > > and applications (like Exchange, IIS, and many others), as well as plentyo > > of other products. > J > Including VMS.  The reason why there aren't many buffer overflow attacksJ > on VMS is that the target is uncommon and uninteresting to the bad guys., > It's a form of security through obscurity. > H > If VMS had achieved the level of success that UNIX did, and UNIX fadedJ > into obscurity the way VMS did, then CERT bulletins would be filled withL > the latest VMS buffer overflow attacks, and UNIX users would be snickering > about VMS insecurity.f >  > -- Mark -- > ! > http://staff.washington.edu/mrcsH > Science does not emerge from voting, party politics, or public debate.   ------------------------------    Date: 21 Dec 2001 18:20:00 -0800( From: bob@instantwhip.com (Bob Ceculski)3 Subject: Re: Congratulations for the festive seasonw= Message-ID: <d7791aa1.0112211820.692b5095@posting.google.com>i   Mark Crispin <mrc@CAC.Washington.EDU> wrote in message news:<Pine.NXT.4.50.0112210740180.6674-100000@Tomobiki-Cho.CAC.Washington.EDU>...- > On Fri, 21 Dec 2001, John J Francini wrote:rJ > > Hence, buffer overflows and other nastiness.  This philosophy is by NOO > > MEANS restricted to Unix; it is very much evident in Microsoft-written OSeszM > > and applications (like Exchange, IIS, and many others), as well as plentye > > of other products. > J > Including VMS.  The reason why there aren't many buffer overflow attacksJ > on VMS is that the target is uncommon and uninteresting to the bad guys., > It's a form of security through obscurity. > H > If VMS had achieved the level of success that UNIX did, and UNIX fadedJ > into obscurity the way VMS did, then CERT bulletins would be filled withL > the latest VMS buffer overflow attacks, and UNIX users would be snickering > about VMS insecurity.  >  > -- Mark -- > ! > http://staff.washington.edu/mrcoH > Science does not emerge from voting, party politics, or public debate.  J VMS has been around for over 20 years now ... "3" cert advs in the last 10M years ... it is everywhere in government ... it is now gaining on the web ...eI are you saying the Defcon9 group is a bunch of idiots, and one of the top I hackers in the world lied to congress when testifying about the vms basednO mail system in the white house saying that vms was hardest os to hack, and that2L he had no success doing it?  Are you saying you can create vms privileges byH overflowing a buffer that you never had in the first place?  This is not4 windoze ... you need privs on vms to do anything ...   ------------------------------  % Date: Fri, 21 Dec 2001 21:24:02 -0500e  From: John Santos <JOHN@egh.com>3 Subject: Re: Congratulations for the festive seasono6 Message-ID: <1011221211958.59837A-100000@Ives.egh.com>  ( On Fri, 21 Dec 2001, Mark Crispin wrote:  ) > On Fri, 21 Dec 2001, John Santos wrote:nF > > This turns out not to be the case.  Most VMS languages use countedE > > strings and the OTS routines that do string copies that check theuD > > counts when copying to fixed-length buffers, and truncate and/orE > > warn you (but never, ever write past the end of the destination.)a > 
 > Truncate???s > K > Oh dear, oh my.  There's a whole class of attacks relating to truncation.g >   A I guess you don't understand the difference between attempting toi? copy a long string of your own (the programmer's) choosing into B too small a buffer (program bug) and copying a long string of someB external user's choosing into too small a buffer (attempted bufferD overflow expoit defeated.)  Or are you just pretending to be stupid?   > -- Mark -- > ! > http://staff.washington.edu/mrcIH > Science does not emerge from voting, party politics, or public debate. >  >  >    -- i John Santos- Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------    Date: 21 Dec 2001 20:36:38 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)y3 Subject: Re: Congratulations for the festive season 3 Message-ID: <NPMySeOuDGlH@eisner.encompasserve.org>s  u In article <clRU7.183955$kf1.56549047@news1.rdc1.ne.home.com>, enders@bolshoi.cc.misu.nodak.edu (Todd Enders) writes: C > In <3C23B4A2.54C610CA@bartek.dontspamme.net> Arthur Krewat wrote:t > E >> Instead, recognize that most buffer overrun exploits are from justbE >> plain stupidity and give it up already. The stuff is written in C.tE >> The programmers should realize this and program accordingly. Theren >> is no excuse for this crap. >>  L > 	This is the most profoundly cogent comment on programming I've seen in a  > *long* time.J > The textbooks and programming instructors *NEVER* drive this point home 	 > enough.i  B Perhaps not for C, but take a look at textbooks for languages that: _do_ support bounds checking, true enumeration types, etc.   ------------------------------    Date: 21 Dec 2001 20:37:51 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)c3 Subject: Re: Congratulations for the festive season 3 Message-ID: <JQoCx4OSJp4G@eisner.encompasserve.org>o   In article <Pine.NXT.4.50.0112211717560.7143-100000@Tomobiki-Cho.CAC.Washington.EDU>, Mark Crispin <mrc@CAC.Washington.EDU> writes:n) > On Fri, 21 Dec 2001, John Santos wrote:rE >> This turns out not to be the case.  Most VMS languages use counted D >> strings and the OTS routines that do string copies that check theC >> counts when copying to fixed-length buffers, and truncate and/oraD >> warn you (but never, ever write past the end of the destination.) > 
 > Truncate???r > K > Oh dear, oh my.  There's a whole class of attacks relating to truncation.e  @ And those who don't check the status returned by system routines are condemned to relive them.1   ------------------------------    Date: 21 Dec 2001 18:48:48 -0800( From: bob@instantwhip.com (Bob Ceculski)3 Subject: Re: Congratulations for the festive season0= Message-ID: <d7791aa1.0112211848.35143404@posting.google.com>s  b peter@taronga.com (Peter da Silva) wrote in message news:<a002id$1781$1@citadel.in.taronga.com>...) > In article <9vvu6g$rnk$1@joe.rice.edu>,g, > Jerry Leslie <leslie@clio.rice.edu> wrote:J > >Why wouldn't the bad guys be interested in VMS systems that run a largeF > >precentage of the lotteries, some stock exchanges, and some banks ? > L > 1. The guys who do most of the buffer overflow attacks are more interestedL > in getting a UNIX or Windows box they can use to attack other bad guys IRC > channels.h > K > 2. I would *hope* critical systems like that aren't exposed to the public  > Internet.  > H > 3. Exploits like this are more likely to be covered up, and since theyK > don't produce publicly visible hacked web pages they may never be noticedI > outside the victim's staff.2 > H > I have been told of a couple of cases where a critical system was leftK > exposed, and bad guys managed to rootkit/backorifice it... and completely L > ignored the system's potential (and almost certainly had no idea what theyB > had access to) in favor of using it for pingflood amplification. > M > I'm not at liberty to name names, for obvious reasons, but the systems were'A > a good deal more worrisome than mere banks and stock exchanges.m > N > Now this isn't to say that I agree with Marc that VMS is equally susceptibleI > to buffer overflow attacks. Non-executable stacks do help somewhat (butdH > as he noted, they don't stop them), and the code is written in a widerL > variety of languages, many with stronger type structures than C. One issueL > I have with VMS and security is the complexity of the security model makesL > privilege boosting attacks more likely. Properly implemented, UNIX has theL > potential for being a lot more secure, though a lot of UNIX code runs withN > far greater privileges than it really needs to. Oh, and the Berkeley sockets. > interface is an amazingly poor fit for UNIX.  K What are you talking about?  I am currently teaching my 10 year old son howtP to implement VMS security!  The VMS security model is not that hard to grasp ...O I have seen the unix and OS400 security model and it is no where near the level O of VMS, let alone SVMS (Secure VMS) ... I have been on VMS for 16 years now andiJ have never had an OS crash! Can you say that about your unix (gag!) boxes?O Want to have a clustering contest?  For disaster recovery, unix would be toast!lP VMS withstood the 9/11 disaster!  What happened to unix?  The last I heard, onlyK VMS clusters withstood the test ... are the defcon9 people idiots?  Did the-L worlds top hacker lie to congress a few years ago when he testified that theP White House mail system ran on VMS (All-in-1) and that was one OS he could neverJ hack into?  Unix is hack city!  It is a VMS wanna be written by a bunch ofM people who want something for nothing!  Windows NT is in the same boat!  DaverN Cutler failed to turn VMS into NT with the Dec West Mica project code!  VMS is1 the best!  Use it or lose it (your hair that is)!m   ------------------------------    Date: 21 Dec 2001 18:55:11 -0800( From: bob@instantwhip.com (Bob Ceculski)3 Subject: Re: Congratulations for the festive seasony< Message-ID: <d7791aa1.0112211855.10062ba@posting.google.com>  b peter@taronga.com (Peter da Silva) wrote in message news:<9vvs1t$13r9$1@citadel.in.taronga.com>...P > >But then, it takes ten seconds to start a shell with everything on my current/ > >Solaris box also, so where's the difference?o > L > If it takes 10 seconds to start a shell on your Solaris box, you're eitherI > trying to run Solaris 8 on a Sparcstation I with 16M RAM and a 3600 RPMrI > drive to swap into, or you have a boatload of crap in your rc file that.K > should only be run on login (if that). I have an AT&T 3b1 with 2M of RAM, J > a 12 MHz 68010 CPU, and a 40M MFM hard disk (ie, something somewhat lessL > powerful than a typical 11/750: it doesn't even support demand paging) andF > it starts a new shell fast enough that it's basically instantaneous.  G no, she is probably running a 512 cpu sparcserver that still can't beata" a single processor Alphaserver ...   ------------------------------    Date: 21 Dec 2001 21:56:25 -0500- From: viro@weyl.math.psu.edu (Alexander Viro)n3 Subject: Re: Congratulations for the festive seasone* Message-ID: <a00sop$ja0@weyl.math.psu.edu>  = In article <d7791aa1.0112211848.35143404@posting.google.com>,v) Bob Ceculski <bob@instantwhip.com> wrote:   L >What are you talking about?  I am currently teaching my 10 year old son howQ >to implement VMS security!  The VMS security model is not that hard to grasp ...uP >I have seen the unix and OS400 security model and it is no where near the levelP >of VMS, let alone SVMS (Secure VMS) ... I have been on VMS for 16 years now andK >have never had an OS crash! Can you say that about your unix (gag!) boxes?wP >Want to have a clustering contest?  For disaster recovery, unix would be toast!Q >VMS withstood the 9/11 disaster!  What happened to unix?  The last I heard, onlysL >VMS clusters withstood the test ... are the defcon9 people idiots?  Did theM >worlds top hacker lie to congress a few years ago when he testified that the Q >White House mail system ran on VMS (All-in-1) and that was one OS he could nevereK >hack into?  Unix is hack city!  It is a VMS wanna be written by a bunch oflN >people who want something for nothing!  Windows NT is in the same boat!  DaveO >Cutler failed to turn VMS into NT with the Dec West Mica project code!  VMS isr2 >the best!  Use it or lose it (your hair that is)!  I $DEITY...  I stand... amazed.  Typical Linux (if not Amiga) advocate, buttG (a) old enough to have 10 years old son and (b) having somewhat unusuals8 object of, erm, affection.  Will the wonders ever cease?   -- mF All that blue light from Orthanc at night? That was Saruman, trying to- moderate news.admin.palantir-abuse.sightings.o" 					Mike Andrews in the Monastery   ------------------------------  % Date: Fri, 21 Dec 2001 18:43:12 -0800 + From: Mark Crispin <mrc@CAC.Washington.EDU>E3 Subject: Re: Congratulations for the festive seasonsU Message-ID: <Pine.NXT.4.50.0112211838060.7301-100000@Tomobiki-Cho.CAC.Washington.EDU>5  ' On Fri, 21 Dec 2001, John Santos wrote:tM > > Oh dear, oh my.  There's a whole class of attacks relating to truncation.tC > I guess you don't understand the difference between attempting to.A > copy a long string of your own (the programmer's) choosing intoeD > too small a buffer (program bug) and copying a long string of someD > external user's choosing into too small a buffer (attempted bufferF > overflow expoit defeated.)  Or are you just pretending to be stupid?  H No.  You're too stupid to understand how the truncation of a long stringH of some external user's choosing to fit into too small a buffer can be a9 completely different security bug from a buffer overflow.   H I'll give you a hint.  Truncation and proceeding is not the right thing.8 Generating an error and rejecting the entire request is.   I'll give you a hint: payload.  
 -- Mark --   http://staff.washington.edu/mrcrF Science does not emerge from voting, party politics, or public debate.   ------------------------------    Date: 21 Dec 2001 22:04:50 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)t3 Subject: Re: Congratulations for the festive seasoni3 Message-ID: <wmyPx+aOTAr0@eisner.encompasserve.org>h   In article <Pine.NXT.4.50.0112211838060.7301-100000@Tomobiki-Cho.CAC.Washington.EDU>, Mark Crispin <mrc@CAC.Washington.EDU> writes:t) > On Fri, 21 Dec 2001, John Santos wrote:yN >> > Oh dear, oh my.  There's a whole class of attacks relating to truncation.D >> I guess you don't understand the difference between attempting toB >> copy a long string of your own (the programmer's) choosing intoE >> too small a buffer (program bug) and copying a long string of somecE >> external user's choosing into too small a buffer (attempted buffer8G >> overflow expoit defeated.)  Or are you just pretending to be stupid?  > J > No.  You're too stupid to understand how the truncation of a long stringJ > of some external user's choosing to fit into too small a buffer can be a; > completely different security bug from a buffer overflow.g > J > I'll give you a hint.  Truncation and proceeding is not the right thing.: > Generating an error and rejecting the entire request is.  C That is a rather bold statement for you to make without knowing thea
 application !d  A The proper behaviour depends on the application, which is why thef) truncation is indicated in a status code.R   ------------------------------  % Date: Fri, 21 Dec 2001 23:08:40 -0500   From: John Santos <JOHN@egh.com>3 Subject: Re: Congratulations for the festive seasons6 Message-ID: <1011221225646.59837A-100000@Ives.egh.com>  ( On Fri, 21 Dec 2001, Mark Crispin wrote:  ) > On Fri, 21 Dec 2001, John Santos wrote: O > > > Oh dear, oh my.  There's a whole class of attacks relating to truncation. E > > I guess you don't understand the difference between attempting tolC > > copy a long string of your own (the programmer's) choosing intosF > > too small a buffer (program bug) and copying a long string of someF > > external user's choosing into too small a buffer (attempted bufferH > > overflow expoit defeated.)  Or are you just pretending to be stupid? > J > No.  You're too stupid to understand how the truncation of a long stringJ > of some external user's choosing to fit into too small a buffer can be a; > completely different security bug from a buffer overflow.b > J > I'll give you a hint.  Truncation and proceeding is not the right thing.: > Generating an error and rejecting the entire request is. >   > I'll give you a hint: payload. >  > -- Mark --  @ Since you snipped the part of my original post where I mentioned> that the programmer has a choice between truncating the source? string to fit or handling it as an error when the source is too > long, you are clearly here only to troll and not to help other people write better programs.t  = But if the user-provided string is too long, and your programk? ignores part of it and processes the rest, I don't see how thisy> can result in a security problem[*].  The result clearly won't> be what the user wanted, but that's a good thing, since he was' trying to exploit or crash your system.n  B [*] Unless something farther down the chain remembers the original> length of the source string, but looks at the contents of your> fixed length (and too small) buffer.  If that happens, you are> not using counted strings correctly (taking length of string B< and assuming that's the length of string B), which means you> aren't using counted strings, just paying lip service to them.   -- r John Santosb Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Sat, 22 Dec 2001 04:10:37 GMTn3 From: Christopher Stacy <cstacy@spacy.Boston.MA.US>S3 Subject: Re: Congratulations for the festive seasonc. Message-ID: <uzo4bevya.fsf@spacy.Boston.MA.US>  A >>>>> On 21 Dec 2001 18:48:48 -0800, Bob Ceculski ("Bob") writes: D  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?  7 I wouldn't put too much stock in that particular point.o   ------------------------------  % Date: Fri, 21 Dec 2001 23:21:06 -0500e  From: John Santos <JOHN@egh.com>3 Subject: Re: Congratulations for the festive seasonn6 Message-ID: <1011221231848.59837C-100000@Ives.egh.com>  ( On Fri, 21 Dec 2001, Mark Crispin wrote:  ) > On Fri, 21 Dec 2001, John Santos wrote:nO > > > Oh dear, oh my.  There's a whole class of attacks relating to truncation.eE > > I guess you don't understand the difference between attempting touC > > copy a long string of your own (the programmer's) choosing intovF > > too small a buffer (program bug) and copying a long string of someF > > external user's choosing into too small a buffer (attempted bufferH > > overflow expoit defeated.)  Or are you just pretending to be stupid? > J > No.  You're too stupid to understand how the truncation of a long stringJ > of some external user's choosing to fit into too small a buffer can be a; > completely different security bug from a buffer overflow.s > J > I'll give you a hint.  Truncation and proceeding is not the right thing.: > Generating an error and rejecting the entire request is. >   > I'll give you a hint: payload.  G This is so apples and oranges, I didn't even know what you were getting A at the 1st time.  Everyone else was talking about blade guards onoB table saws and all of a sudden, you claim blade guards are uselessB because they won't protect your thumb if you hit it with a hammer.   Go back under your bridge.   >  > -- Mark -- > ! > http://staff.washington.edu/mrcpH > Science does not emerge from voting, party politics, or public debate. >  >  >    -- z John Santosd Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Fri, 21 Dec 2001 23:25:11 -0500   From: John Santos <JOHN@egh.com>3 Subject: Re: Congratulations for the festive season26 Message-ID: <1011221232430.59837A-100000@Ives.egh.com>  ' On Fri, 21 Dec 2001, John Santos wrote:c  * > On Fri, 21 Dec 2001, Mark Crispin wrote: > + > > On Fri, 21 Dec 2001, John Santos wrote:tQ > > > > Oh dear, oh my.  There's a whole class of attacks relating to truncation.nG > > > I guess you don't understand the difference between attempting touE > > > copy a long string of your own (the programmer's) choosing intoaH > > > too small a buffer (program bug) and copying a long string of someH > > > external user's choosing into too small a buffer (attempted bufferJ > > > overflow expoit defeated.)  Or are you just pretending to be stupid? > > L > > No.  You're too stupid to understand how the truncation of a long stringL > > of some external user's choosing to fit into too small a buffer can be a= > > completely different security bug from a buffer overflow.- > > L > > I'll give you a hint.  Truncation and proceeding is not the right thing.< > > Generating an error and rejecting the entire request is. > > " > > I'll give you a hint: payload. > >  > > -- Mark -- > B > Since you snipped the part of my original post where I mentioned@ > that the programmer has a choice between truncating the sourceA > string to fit or handling it as an error when the source is toos@ > long, you are clearly here only to troll and not to help other > people write better programs.. > ? > But if the user-provided string is too long, and your programsA > ignores part of it and processes the rest, I don't see how thiss@ > can result in a security problem[*].  The result clearly won't@ > be what the user wanted, but that's a good thing, since he was) > trying to exploit or crash your system.y > D > [*] Unless something farther down the chain remembers the original@ > length of the source string, but looks at the contents of your@ > fixed length (and too small) buffer.  If that happens, you are@ > not using counted strings correctly (taking length of string B@ ------------------------------------------------------->string A> > and assuming that's the length of string B), which means you@ > aren't using counted strings, just paying lip service to them.   -- c John Santos: Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Sat, 22 Dec 2001 04:29:23 GMT11 From: "David J. Dachtera" <djesys.nospam@fsi.net>.3 Subject: Re: Congratulations for the festive season ' Message-ID: <3C240C95.64D439AE@fsi.net>r   Christopher Stacy wrote: > C > >>>>> On 21 Dec 2001 18:48:48 -0800, Bob Ceculski ("Bob") writes:iF >  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.t  , So, you're saying he was less than truthful?   -- r David J. Dachterao dba DJE Systemsm http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/@   ------------------------------  # Date: Fri, 21 Dec 2001 19:17:27 GMTi4 From: "Terry C. Shannon" <terryshannon@mediaone.net>> Subject: Re: Current timetable for HP/CPQ shareholder voting ?> Message-ID: <bVLU7.24435$Sj1.12250167@typhoon.ne.mediaone.net>  : "Warren Spencer" <wspencer@ap.nospam.org> wrote in message1 news:917E8B7E2warrenspencer1977@207.126.101.97...s7 > terryshannon@mediaone.net (Terry C. Shannon) wrote int! > <pY2R7.2358$7y.9233@rwcrnsc54>:c >gH > >I don't know when the voting was to have taken place, but the CPQ andJ > >HWP timelines called for a consummation by early April and an immediateH > >integration and consolidation. They planned to hit the ground running > >with the new company. > ! > Is that a "splat" sound I hear?  >    ;-}E   ------------------------------  % Date: Fri, 21 Dec 2001 17:07:00 -0500 , From: "Kenneth Block" <krblock@computer.org>) Subject: Re: CXX and the Hobbyist licensem1 Message-ID: <doOU7.332$sK3.5219@news.cpqcorp.net>a  J > If you have a C++ license and just need the binary kit,  you may be able to@ > use the beta kit. The beta kit is available for download from: >nF > ftp://ftp.compaq.com/pub/products/c-cxx/openvms/cxx/beta/ftindex.htm >gJ > The sanity kit (final beta kit) for V6.5 should be available shortly. WeJ > will annouce this kit in comp.os.vms as soon as it is available. I would= > wait until the sanity kit was available before downloading.h    The sanity kit is now available.   ------------------------------  % Date: Fri, 21 Dec 2001 18:06:46 -0500l- From: Michael Austin <miaustin@bellsouth.net>p- Subject: Re: Excitement -- and disappointmenta- Message-ID: <3C23C086.53B6CB5C@bellsouth.net>u  J I don't have the certificate, but I got the pen a few weeks ago at the NYCK Encompass LUG talk on the future of OpenVMS.  I would still like to get theiJ neat Denim shirt they gave away... and as usual didn't win the give-aways.   Michael Austin DBA Consultant     "Stanley F. Quayle" wrote:  : > I am now a Compaq Accredited Professional OpenVMS SystemC > Administrator.  My welcome packet came today.  It had a very nicen* > certificate, and an official Compaq pen. >e: > The pen says "Tru64 Unix Systems Administrator".  *sigh* >a > --Stan Quaylee# > President, Quayle Consulting Inc.n >t > ----------I > Stanley F. Quayle, P.E.   N8SQ   +1 614-868-1363   Fax: +1 614 868-1671f3 > 8572 North Spring Ct. NW, Pickerington, OH  43147 ? > Preferred address:  stan@stanq.com       http://www.stanq.comr   ------------------------------  % Date: Sat, 22 Dec 2001 00:49:16 +0100h1 From: John McLean <mcleanj@swissonline.delete.ch>I- Subject: Re: Excitement -- and disappointment.5 Message-ID: <3C23CA7C.F51D6214@swissonline.delete.ch>h  F So the future of VMS is Tru64 ?   Maybe if Tru64 doesn't have a future& they have plenty of pens to give away.  6 More likely it is a typical Compaq marketing screw-up.  G On the other hand, you would think that the person would see "Tru64" onnD the pen and "OpenVMS" and at least realise they weren't the same ...     John McLeanN     Michael Austin wrote:o > L > I don't have the certificate, but I got the pen a few weeks ago at the NYCM > Encompass LUG talk on the future of OpenVMS.  I would still like to get theiL > neat Denim shirt they gave away... and as usual didn't win the give-aways. >  > Michael Austin > DBA Consultant >  > "Stanley F. Quayle" wrote: > < > > I am now a Compaq Accredited Professional OpenVMS SystemE > > Administrator.  My welcome packet came today.  It had a very nicel, > > certificate, and an official Compaq pen. > >,< > > The pen says "Tru64 Unix Systems Administrator".  *sigh* > >  > > --Stan Quaylea% > > President, Quayle Consulting Inc.  > >i > > ----------K > > Stanley F. Quayle, P.E.   N8SQ   +1 614-868-1363   Fax: +1 614 868-1671t5 > > 8572 North Spring Ct. NW, Pickerington, OH  43147nA > > Preferred address:  stan@stanq.com       http://www.stanq.comz   ------------------------------  # Date: Sat, 22 Dec 2001 00:07:18 GMTf4 From: "Terry C. Shannon" <terryshannon@mediaone.net>- Subject: Re: Excitement -- and disappointmento> Message-ID: <W8QU7.25129$Sj1.12396333@typhoon.ne.mediaone.net>  > "John McLean" <mcleanj@swissonline.delete.ch> wrote in message/ news:3C23CA7C.F51D6214@swissonline.delete.ch...- >-! > So the future of VMS is Tru64 ?0  J Lord, I hope not. Surely you know what Hewlett Parkard's HP-UX Group calls Tru64 UNIX....                               an ORGAN DONOR..  K with apologies all the incumbent Microsoft Business Partners who sadly bearu the same appellation   ------------------------------  # Date: Fri, 21 Dec 2001 22:42:14 GMT1' From: bad bob <sfmc68@bellatlantic.net>u: Subject: Re: historical evidence of what went wrong at DEC0 Message-ID: <3C23BC33.567390B2@bellatlantic.net>   Ben Franchuk wrote:t >  > bad bob wrote: > F > > I can only provide my analysis at the time, and the impetus for me > > leavingOG > > dec.  On the hardware side, I percieved that there were two paths - 	 > > priorcG > > to PC intro, and after Apple intro - Large systems and chip design.9L > > We had national semi buidling a couple of variants of the 11, and trying > > toL > > take on that market space as a vendor, that failed by the way, and intelL > > pushingtheir new chips, moto pushing  theirs, rumors of an INTEL version > > ofL > > the pdp11, MOS Technology - not MOSTEK - doing their micro..that sure asH > > heck in the 6500 model was an 8bit pdp11 - producing stuff at prices > > lessF > > than we could.  The culture was changing, and the path to a single$ > > product was written on the wall. > >cH > > The culture change, the impact of the Business side of what had beenJ > > an engineering enterprise, the impact of more competition - IBM comingD > > out with their series1, finally acknowledging minis were real...K > > and all that contributed to a path that led to the actions that flushedb > > dec. > B > But could have DEC made a comeback with a low cost CPU on a chipE > or was the writing on the wall? The other idea was you did not need-I > a license to run a OS on the 8 bit computers. Why some people even gavea > out source for the bios.:)  H Exactly right, we had gone to the mass bus licensing, the patents on theB busses, and limited rights....worse on xmi, sbi, and so on. yep, I forgot$ about those nails in the dec coffin.  2 I don't know if they could have made comeback..... >  > --( > Ben Franchuk --- Pre-historic Cpu's --- > www.jetnet.ab.ca/users/bfranchuk/index.html    ------------------------------  % Date: Fri, 21 Dec 2001 20:12:42 -0500m# From: Paul DeMone <pdemone@igs.net>g: Subject: Re: historical evidence of what went wrong at DEC' Message-ID: <3C23DE0A.BF37CFC6@igs.net>l   "Terry C. Shannon" wrote:y > 7 > "Peter da Silva" <peter@taronga.com> wrote in message . > news:9vvm15$10nb$1@citadel.in.taronga.com...5 > > In article <CCIU7.320$sK3.4944@news.cpqcorp.net>,a8 > > Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:I > > >If we had been able to push the VAX performance, as Intel has pushedo > x86... > >nN > > That would have been difficult. 8086 is a deeply ugly instruction set, but- > > it's still easier to optimise than VAX...s > L > To be fair to Digital, VAX performance underwent a significant increase inG > the late 80s/early 90s. The first CVAX implementation delivered about6N > 2.7VUPS IIRC. 39 months later the NVAX derivative achieved ~36VUPs. That's aL > thirteenfold performance improvement in 39 months, which wasn't bad at all > for the day.  C You still have to look at it in absolute terms. The NVAX co-existed>B with 68040's and 486DX2's. These offered comparable performance atD much lower implementation cost (1/2 the die area, 1/2 the power, andB about 1/3 the pins) and far, far lower manufacturing cost and ASPs6 due to their orders of magnitude higher sales volumes.   --D Paul W. DeMone       The 801 experiment SPARCed an ARMs race of EPICE Kanata, Ontario      proportions to put more PRECISION and POWER intonG demone@mosaid.com    architectures with MIPSed results but ALPHA's well.$ pdemone@igs.net      that ends well.    > -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----A http://www.newsfeeds.com - The #1 Newsgroup Service in the World!t> -----==  Over 80,000 Newsgroups - 16 Different Servers! =-----   ------------------------------  % Date: Fri, 21 Dec 2001 23:23:37 +0100e1 From: John McLean <mcleanj@swissonline.delete.ch> 9 Subject: Re: HP admits it will kill VMS if merger suceedsl5 Message-ID: <3C23B669.8C8F7150@swissonline.delete.ch>c   JF Mezei wrote:p >  > "Terry C. Shannon" wrote:cO > > That is an oversimplification. Differentiation is important, it all depends- > > on where you differentiate., > O > For Compaq, it means the colour of the box the unit ships in, and the way youl > sell/deliver the goods.o > I > > Why on God's green earth would Microsoft want to buy VMS when they've0L > > already been granted executive clemency for stealing the Son-of-VMS Mica > > code back in 1989? > E > Why on God's green earth would Intel want to buy Alpha when they'veeM > already been granted executive clemency for stealing the Alpha technologiesn! > for its Pentium back in 1990s ?  > J > Imagine what would happen if the kindergarden known as Microsoft full ofN > little weenies were suddlently equipped with experienced parents coming fromP > Digital who could teach the kids how to program, how to spot security flaws inN > features and would have enough credibility to tell the marketers to get lostO > because the feature they want is a liability to microsoft due to the securityt > risk ? > L > Imagine if the Digital engineers could bring order to the place and put inM > place the quality control philosophy and methodologies that had been put in A > place at Digital to ensure that VMS was a top quality product ?  > O > On the other hand, it is possible that Microsoft has to put in those securityiO > flaws in its systems to force some customers to buy from Sun and IBM. ImaginehL > how much of a monopoly Microsoft would have if it actually shipped quality > products at a low price ?a    : Thanks JF, I was more or less going to say the same thing.  = Getting VMS would let Microsoft cater from the desktop to thew% data-centre, soup-to-nuts as it were.m  E ...Sorry, I just remembered where these comments come from.  It was ad0 Compaq press release when it bought Digital. :-(     John McLean*   ------------------------------  # Date: Fri, 21 Dec 2001 21:06:55 GMTo4 From: "Terry C. Shannon" <terryshannon@mediaone.net>9 Subject: Re: HP admits it will kill VMS if merger suceedsu> Message-ID: <PvNU7.24463$Sj1.12292085@typhoon.ne.mediaone.net>  . "John Smith" <a@nonymous.com> wrote in message7 news:tpNU7.73158$pa1.24443496@news3.rdc1.on.home.com...n > Terry, > K > Perhaps it's time that a formal question was put to both the Boards of HPtJ > and Compaq for a statement that is in legal terms, jointly and severally
 > binding. >tJ > Perhaps a noted and often quoted newsletter author might be able to poseL > just such a question, while at the same time suggesting that the answer be > made public. >4I > It can't be that they can't comment about it due to SEC rules - they've - > commented about just about everything else.i >d  F Oh, I could certainly pose the question within the pages of SKC, but IH honestly don't know if it would do any good. I don't know how interested+ Compaq is in outside advice these days. ;-}-  J Looking in from the outside, it seems intuitively obvious to me that a VMSI statement (if appropriate, e.g. if the firms intended to keep VMS around)1/ would be a good way to quell customer concerns.i  G But perhaps CPQ feels that issuing such a letter would be tantamount tooB responding to one of those "when did you stop beating your spouse"
 questions.   ------------------------------    Date: 21 Dec 2001 14:29:51 -0800( From: bob@instantwhip.com (Bob Ceculski)9 Subject: Re: HP admits it will kill VMS if merger suceedsr= Message-ID: <d7791aa1.0112211429.5c4f1be8@posting.google.com>u  n John McLean <mcleanj@swissonline.delete.ch> wrote in message news:<3C23949C.D08AA60A@swissonline.delete.ch>... > Sue Skonetski wrote: > > F > > The only thing that is killing the OpenVMS Customer base is peopleO > > complaining and saying that Digital/Compaq/HP are going to kill VMS. Do youeN > > realize every time someone posts a sky is falling message we get calls andH > > emails from our customers which we then have to work with to keep asP > > customers, stopping us from doing other work (like porting work)? Every timeL > > a negative stream starts our competition is glad and they can say "see IN > > told you so." No, I do not have my head in the sand, but I would prefer toP > > defend VMS against a foe instead of a friend. Lets not loose the war because > > of friendly fire.a > >  > > Sueb >  > H > I'm pleased that you get calls and emails from customers that you thenE > have to work with to keep as customers.  You can tell those varioustJ > echelons above you that there is a lot of concern about VMS and that theG > customers are hearing little (or nothing) from Compaq that gives them2 > much reassurance.  > I > As Alan Greig pointed out, VMS is noticably absent from HP's message to2: > Shareholders; all the other OSes rate frequent mentions. > F > You would have seen from this newsgroup that VMS is noticably absentJ > from Compaq's financial statements; and usually all the rest rate plenty3 > of mention (especially the loss making products).t > ? > There are copious amounts of advertising for PCs, rather lessw8 > advertising for Tru64, almost no advertising for VMS.  > H > What do these three statements tell you ?  That Compaq thinks VMS is aG > great operating system and is doing its best to keep it visible ?  OrlF > that Compaq really doesn't like it much at all and would prefer thatF > customers used another platform ?  (One could understand if a personJ > thought that the only reason that Compaq was only keeping VMS is because' > it is a reasonable source of income.)  >  > I > Now if Compaq did more for VMS and was actively trying to promote it, IlJ > don't think you would get a more loyal bunch that the people who post toI > this newsgroup.  Any suggestion that Compaq was thinking of killing VMS J > would be given a hard time because the answer would be simple - Don't be5 > ridiculous, look at the support it has from Compaq.r >  > H > As many of us have said time and time again, Compaq's marketing is theG > number one problem.  Compaq fails to publicly endorse and promote it.tE > Compaq only wants to sell it into a niche market (and will actively I > pressure the customer into buying something else if the customer is notoI > in that niche.)  My goodness, Compaq's approach is almost that they areiA > ashamed of VMS, that it's like some nasty little skin disease. , > G > Don't blame us if customers lose confidence.  If Compaq marketing didt- > their job properly this would never happen.h >  > 
 > John McLeanr  N Perfectly stated ... no, they are not ashamed, but rather guys like Palmer andL Capellas are being paid off to try and kill VMS, that is the problem ... theJ shareholders need to boot these guys out the minute they start singing theJ windoze, itanic song ... they had the number one chip (alpha) and have theK number one OS (VMS), and they are selling out to the windoze, itanic crowd!c   ------------------------------  % Date: Fri, 21 Dec 2001 23:24:09 +00000% From: Alan Greig <a.greig@virgin.net>-9 Subject: Re: HP admits it will kill VMS if merger suceeds * Message-ID: <3C23C499.EF7B9F0C@virgin.net>   Jerry Leslie wrote:r   > Js >eD > Perhaps plans for NSK and VMS were made back in September, such as6 > selling them to someone like CA, IBM, Unisys, or GE. >c  O Not for NSK. The HP letter to shareholders I referenced *specifically* mentionsrM NSK/Himalaya by name as something HP sees of value they will get from Compaq.    > 6 > --Jerry Leslie     (my opinions are strictly my own)   --
 Alan Greig   ------------------------------  % Date: Fri, 21 Dec 2001 20:40:12 -0500l From: gce <ge@gce.com>9 Subject: Re: HP admits it will kill VMS if merger suceeds.' Message-ID: <3C23E47C.C42650F8@gce.com>e  E Might I observe too that info-vax is getting to be a VERY high volume-G group, mainly due to these speculations and replies to them. Can't somesE of the speculations go into some other group and leave the tech stuffl in this one?  J The pdp10 reminiscences are fun - for a while - but the technical fractionF of the content here has never been lower IMO during the 15 or so years I've followed the discussions.  C alt.vms.corporate.politics and alt.vms.conspiracy.theories might be9E good names for groups in which to put most of the recent discussions.   O If I have complaints about things VMS that are political I have Rich Marcello'snJ email address, and can find others for Mr. Capellas or various folks at HP if I need to.   H Historically the mission of info-vax/c.o.v. has been much more technical* which made it much more rewarding to read.  O Some of the topics of discussion could well become so again. What, for example,cI are the major differences we might expect in IA64 versions of VMS? SurelycI the data structures will get at least little tweaks in kernel mode, and IyM have hoped for a few things in support of I/O layering which are difficult onfM Alpha because certain data structures are already defined and in use by thirdmF party packages and VMS engineering is justifiably loath to alter them.  O Is third party boot going to get easier? Will anything simplify driver writing?d  M Some of these bits might be getting clearer in good old ZK3 about now, and ittL would be nice to have hints. I figure that some re-layout of IRP, UCB, maybeG DDT, FCB, and so on might be needed just to get things clean on the new:M architecture..not so much as was needed in the vax->alpha move, but a little,hM and so the little bits I mention might be natural mods. Anyone who is an IA64e expert care to comment?o  U Anyone care to comment how updated caching maybe should look, work, be designed etc.?.O (given, that is, that it is desired that most old code be usable with recompile  or translation)?   Glenn Everhart     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 youeL > 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.d >  > Suen > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:T3Fa2DzEOm$v@eisner.encompasserve.org...e9 > > In article <3C229E2D.C7ABFB23@videotron.ca>, JF Mezei ( > <jfmezei.spamnot@videotron.ca> writes: > > > "Terry C. Shannon" wrote:nH > > >> Is there any concrete evidence that IBM has a serious interest in
 > OpenVMS?L > > >> By and large Big Blue and its proxies seem to prefer to migrate folks > from > > >> VMS to an IBM platform. > > >uJ > > > If the current remaining VMS customers were to make it very clear to > CompaqL > > > that they will drop VMS and leave Compaq instead of move to IA64, then > CompaqL > > > might see value in selling VMS ASAP while it is still alive. (actually > sell* > > > the VMS customers more than the OS). > > >dF > > > But as long as Compaq has hopes of eventually converting the VMS > customersaF > > > into NT customers then it will keep VMS in basic life support to > postpone the > > > inevitable defections. > > >gL > > > And the longer Compaq postpones the inevitable, the more forgotten andH > > > irrelevant VMS will be, at at one point it will make more sense to > donate theL > > > VMS IP and engineers to Microsoft than to sell VMS as an whole entity. > > >tN > > > When the wedding is called off and Curly comes back to reality and finds > his,N > > > Compaq sick and stranded all alone in a desert, he may have to take someM > > > drastic actions like selling stuff such as VMS to  downsize Compaq back1 > toH > > > what Compaq's management are capable of managing : a single wintel > business.s > > D > > You go back and forth , back and forth... and it is the same old/ > > nonesense.  Nary a quote, nary a datapoint.u > > J > > > If the current remaining VMS customers were to make it very clear to > Compaq > >OA > > Why not just say the dozen or so customers that remain and be B > > done with it?  How many customers are we talking about anyhow? > > Two dozen?  Three maybe? > >0F > > > But as long as Compaq has hopes of eventually converting the VMS > customersvF > > > into NT customers then it will keep VMS in basic life support to > postpone the > > > inevitable defections. > >rH > > Where can we find more information on this migration plan?  I assume > > one exists somewhere.e > >n > > Robw > >i   ------------------------------  # Date: Sat, 22 Dec 2001 01:46:37 GMT,4 From: "Terry C. Shannon" <terryshannon@mediaone.net>9 Subject: Re: HP admits it will kill VMS if merger suceedso> Message-ID: <1CRU7.25182$Sj1.12458439@typhoon.ne.mediaone.net>  E "gce" <ge@gce.com> wrote in message news:3C23E47C.C42650F8@gce.com...oG > Might I observe too that info-vax is getting to be a VERY high volumeSI > group, mainly due to these speculations and replies to them. Can't some G > of the speculations go into some other group and leave the tech stuffh > in this one? >uL > The pdp10 reminiscences are fun - for a while - but the technical fractionH > of the content here has never been lower IMO during the 15 or so years  > I've followed the discussions. >rE > alt.vms.corporate.politics and alt.vms.conspiracy.theories might berG > good names for groups in which to put most of the recent discussions.t >tF > If I have complaints about things VMS that are political I have Rich
 Marcello'sL > email address, and can find others for Mr. Capellas or various folks at HP > if I need to.w >yJ > Historically the mission of info-vax/c.o.v. has been much more technical, > which made it much more rewarding to read. > H > Some of the topics of discussion could well become so again. What, for example,K > are the major differences we might expect in IA64 versions of VMS? Surely K > the data structures will get at least little tweaks in kernel mode, and I.L > have hoped for a few things in support of I/O layering which are difficult onI > Alpha because certain data structures are already defined and in use by0 third2H > party packages and VMS engineering is justifiably loath to alter them. >dH > Is third party boot going to get easier? Will anything simplify driver writing? >hL > Some of these bits might be getting clearer in good old ZK3 about now, and itH > would be nice to have hints. I figure that some re-layout of IRP, UCB, maybewI > DDT, FCB, and so on might be needed just to get things clean on the new G > architecture..not so much as was needed in the vax->alpha move, but ao little,.J > and so the little bits I mention might be natural mods. Anyone who is an IA64 > expert care to comment?  >oH > Anyone care to comment how updated caching maybe should look, work, be designed etc.?G > (given, that is, that it is desired that most old code be usable withi	 recompile6 > or translation)? >n > Glenn Everhart   Well stated, Glenn!6  G Of course, one can always wander over to www.openvms.org and post theirw technical comments therein....   ------------------------------  # Date: Sat, 22 Dec 2001 04:23:57 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> N Subject: Re: Maintaining date file created attribute when creating an archives' Message-ID: <3C240B4E.1A5DBC68@fsi.net>w   Nick Paszty wrote: >  > hello. > F > i'm migrating some files from OpenVMS 7.1-2 to Solaris 2.8.  i wouldH > like to create an archive on VMS, FTP it to my Solaris box and extractC > the directories and files while maintaining the VMS file creation  > date.t >  > Can this be done?b > G > what software do i need on the VMS side to create the archive so that E > i can use gunzip and tar on the Solaris box to extract the archive?-  G I believe Solaris 8 ships with zip and unzip from InfoZip. These should F preserve file dates, given the proper command line options. Check "manG unzip" on Solaris and HELP ZIP on VMS (if ZIP was installed with HELP).d  H Other posters' caveats about file types and contents still hold true, ofG course. Anything other than sequential (variable or fixed) or Stream_LF E may not survive the transfer process intact unless close attention ise, paid to command line options for ZIP on VMS.   -- e David J. Dachtera, dba DJE Systemsq http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------    Date: 21 Dec 2001 18:18:21 -0600+ From: kuhrt@encompasserve.org (Marty Kuhrt)e2 Subject: Microsoft addresses security issues in XP3 Message-ID: <evzXO5RGmoQ2@eisner.encompasserve.org>w  , Microsoft addresses security issues in XP...  - http://204.95.248.100/News/2001/12/death.htmlt   ------------------------------  # Date: Sat, 22 Dec 2001 04:08:33 GMTd1 From: "David J. Dachtera" <djesys.nospam@fsi.net> Y Subject: More CLIUTL Wish List items (was Re: SUBMIT/AFTER/HOLD (was: RE: DCL day of the a' Message-ID: <3C2407B1.9CBCE710@fsi.net>,   "Alan E. Feldman" wrote: > ~ > Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> wrote in message news:<01KC3IXAS4LI9138XQ@sysdev.deutsche-boerse.com>...J > > > I'm not sure what you mean by /AFTER and /HOLD not working together.* > > > What version of VMS are you running? > > > G > > > Anyway, see the example below on how to use F$GETQUI to check theiG > > > "after time" without running SET ENTRY/NOHOLD and thereby risking = > > > starting the job prematurely. (Example run on VMS V6.1)  > >o > > Mea culpa! > > D > > OK, with /AFTER one should use /NOHOLD instead of /RELEASE.  OK. > > L > > What annoys me is that /HOLD turns of the display of the time.  It wouldL > > be nice to have something like "holding" to indicate the action of /HOLDB > > and "queued for" or whatever to indicate the action of /AFTER. > D > Agreed, but it would be difficult to come up with something that's@ > both clear and concise. I mean, you have to say something like? > "21-DEC-2001 12:00:00.00 but holding" which would be unclear,-@ > ambiguous, or confusing; or "Holding, but if you run SET ENTRYC > /NOHOLD, it would start at 21-DEC-2001 12:00:00.00", which is tooiA > verbose. Maybe someone can come up with something better. Maybe1E > "Holding overriding scheduled time of 21-DEC-2001 12:00:00.00"? No,t > still too verbose.  B Well, whaddaya think 'bout this: (please excuse the line wrapping)   Given:2 $ subm/noprint user$root:[000000]login/after=16:00   Current behavior:q $ sh ent/fu &$entry 4   Entry  Jobname         Username     Blocks  Status4   -----  -------         --------     ------  ------G     656  LOGIN           DDACHTERA            Holding until 21-DEC-2001s 16:00:00+          On available batch queue SYS$BATCHc1          Submitted 21-DEC-2001 14:33:17.79 /KEEP  @          /LOG=DSA1:[USER.DDACHTERA.][WORK].LOG; /NOTIFY /NOPRINT /PRIORITY=3o0          File: _DSA1:[USER.DDACHTERA]LOGIN.COM;6   Proposed behavior: $ sh ent/fu &$entryl4   Entry  Jobname         Username     Blocks  Status4   -----  -------         --------     ------  ------E     656  LOGIN           DDACHTERA            Pending (timed release)i+          On available batch queue SYS$BATCHk1          Submitted 21-DEC-2001 14:33:17.79 /KEEP o$          /AFTER=21-DEC-2001 16:00:00@          /LOG=DSA1:[USER.DDACHTERA.][WORK].LOG; /NOTIFY /NOPRINT /PRIORITY=3e0          File: _DSA1:[USER.DDACHTERA]LOGIN.COM;6 $ set entry/hold &$entry $ sh ent/fu &$entry14   Entry  Jobname         Username     Blocks  Status4   -----  -------         --------     ------  ------5     656  LOGIN           DDACHTERA            Holding4+          On available batch queue SYS$BATCHl1          Submitted 21-DEC-2001 14:33:17.79 /KEEP 3$          /AFTER=21-DEC-2001 16:00:00@          /LOG=DSA1:[USER.DDACHTERA.][WORK].LOG; /NOTIFY /NOPRINT /PRIORITY=3V0          File: _DSA1:[USER.DDACHTERA]LOGIN.COM;6 $ set entry/nohold &$entry $ sh ent/fu &$entry.4   Entry  Jobname         Username     Blocks  Status4   -----  -------         --------     ------  ------E     656  LOGIN           DDACHTERA            Pending (timed release)s+          On available batch queue SYS$BATCHg1          Submitted 21-DEC-2001 14:33:17.79 /KEEP r$          /AFTER=21-DEC-2001 16:00:00@          /LOG=DSA1:[USER.DDACHTERA.][WORK].LOG; /NOTIFY /NOPRINT /PRIORITY=3e0          File: _DSA1:[USER.DDACHTERA]LOGIN.COM;6  A Would that suit everyone, if we could convince the right folks to + implement it and ECO it to mature versions?c   -- d David J. Dachterae dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/r   ------------------------------    Date: 21 Dec 2001 22:57:06 -0800) From: P.Young@unsw.EDU.AU (Patrick Young)t# Subject: Re: More than Ctrl-Alt-DelA= Message-ID: <55f85d77.0112212257.454d47dd@posting.google.com>e  d Lyndon Bartels <lbartels@pressenter.com> wrote in message news:<3C211DCF.787C5C24@pressenter.com>...B > I think one of the hard parts about being a VMS administrator is- > battling the Ctrl-Alt-Del thought process.   >   G "Ctrl-Alt-Del" rox on my OpenVMS workstation - it allows me to login touH whatever crapulent M$ box is under control of my VNC viewer. M$ users of4 VNC have to do some strange key sequence to do this.  B Which reminds me... recent thread on cut and paste. M$ solution isE not what I would ever be able to use - too much work - double/tripplelC click from anything under OpenVMS including Mozilla does it for me.d   ------------------------------    Date: 21 Dec 2001 16:57:47 -0800( From: bob@instantwhip.com (Bob Ceculski)6 Subject: MPE-Tru64 compromise?  VMS-HPux new platform?= Message-ID: <d7791aa1.0112211657.42eb6b25@posting.google.com>   E I think the two weak OS links for the new Q-HP have been announced astG history ... MPE no match for VMS - gone!  Tru64 market less than HPux - E merged!  That's it!  I think the new Q-HP cleanup is complete ... TheaM new platforms will be OpenVMS Alpha-Itanium, HPux Itanium with Tru64 on Alpha G supported, and for the frond end or those managers that like running 80 J million windoze machines to patch, windoze!  Linux also ... sounds like a L pretty good line up eventually all on the Itanium (w/Alpha tech, compilers)! Sounds like a winner to me!o   ------------------------------    Date: 21 Dec 2001 20:34:36 -0800) From: P.Young@unsw.EDU.AU (Patrick Young)s+ Subject: OPC$ENABLE_LOGFILE? and 7.3 - bug? = Message-ID: <55f85d77.0112212034.79d2060e@posting.google.com>   > With OpenVMS 7.3 Alpha there is a _strange_ message at startup= just after the system does it's device configuration and goese$ into the OpenVMS Operator Console...  6 "The operator console and logfile will not be enabled.@ Change OPC$ENABLE_OPA0 & OPC$ENABLE_LOGFILE in SYLOGICALS.COM to
 enable them."b  C I've noticed the message on my home system in the past, however didoB not pay much attention to it. Yesterday after upgrading systems atA work to 7.3 I noticed it since my mission at work is to eliminate G any start up messages that even _smell funny_ - let alone are an error.0  : I have the correct logical, in my case, OPC$LOGFILE_ENABLE; defined as per the instructions in SYLOGICALS.COM. Tried an.@ OPC$ENABLE_LOGFILE just for fun now on my home machine - did not kill the message.   > The author had OPC$ENABLE_LOGFILE_CLASSES on the brain? - justE the sort of "misktake" I make every day :-) "takes one to notice one"r  E I have not purchased OpenVMS 7.3 source listings (yet) so can't tracko	 this one.s   ------------------------------    Date: 21 Dec 2001 14:26:11 -0800* From: spence_m@ociweb.com (Malcolm Spence)3 Subject: Open Source CORBA now available on OpenVMS,= Message-ID: <285db71c.0112211426.3989c766@posting.google.com>R  A Hi everybody, I just want to let you know we think there is still7E plenty of life left in OpenVMS. As a result we recently did a limited < port of the open source CORBA Product that we support to it.  D The ORB is TAO (The ACE ORB), a high performance CORBA 2.3 compliant@ C++ ORB developed by Washington University in St. Louis, and nowE commercially supported by OCI. It was alimeted port in as much as TAOnC has a dozen CORBA services and we did not port all. We had a clientlE who just wanted a naming service and the real time event channnel. IfrB you need A/V, logging, notification, trader, load balancing or anyD other of the many services TAO has, then we will need to do a littleE more work.  We alos ported our existing shipping version of TAO 1,1a.tA the new version 1.2a is due out shortly and will need validating.t  A This was tricky port, and was made possible by our using the next D version of OpenVMS with its more "Unix like" features. I cannot tellF you when that will ship but please contact me and I will help you work> with Compaq to get a sense of when you could plan on using it.  E TAO runs on an abstraction layer called ACE, which is a C++ framework D and hides OS and communication issues. If you have apps designed forF Unix they will easily port to ACE which now of course runs on OpenVMS.C So now you have an easier time of getting existing C++ apps over too0 OpenVMS, if you choose. ACE is also open source.  / More information on ACE and TAO is available atdC http://www.theaceorb.com. We run on just about everything including B Tru64, the WinCE O/S, many RTOSs, and of course most Unix strains.  F TAO has a zero cost license model for both development and runtime. NoD worries about this vendor dropping platform support, the TAO code is@ always right where you want it, if you wish, in your repository.C We provide training, product supprt, consulting and migration help.t: Our goal is help you achieve an open, inclusive middleware infrastructure.d  " Let me know if you are interested.! thanks and regards Malcolm Spence   Director of Business Development. OCI St Louis MO  tel 1-(314)-579-0066 ext 206. FAX 1-314-579-0065   ------------------------------    Date: 21 Dec 2001 14:40:05 -0800( From: bob@instantwhip.com (Bob Ceculski)& Subject: Re: OpenVMS Handed a Lifeline= Message-ID: <d7791aa1.0112211440.2257dcf4@posting.google.com>   a JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3C2387BE.B31F5980@videotron.ca>...  > Bob Ceculski wrote:p4 > > you call 450,000+ customers a few customers ...  >  > O > Are these 450,000 customers, systems, or users ?  Since I haven't spent money N > at Compaq in a while, are my 2 active systems at home and a cold microvax-II/ > spare counted as 3 in there or as 0 or as 1 ?   O I'll bet thats known licensed systems only ... if you count all boxes worldwide 9 I'll bet you it is a lot more than that ... maybe double!t   ------------------------------   Date: 22 Dec 2001 06:23:38 GMT) From: leslie@clio.rice.edu (Jerry Leslie)nC Subject: OT: FBI & Pentagon Quiz Microsoft Over Windows XP Problemsr' Message-ID: <a018ta$3vg$1@joe.rice.edu>n* Keywords: fbi,dod,quiz,msft,windowsxp,bugs  =     http://www.siliconvalley.com/docs/news/svfront/001901.htm I     FBI and Pentagon quiz Microsoft over Windows XP problems (12/21/2001)   H    "WASHINGTON (AP) -- FBI and Defense Department officials and some topJ     industry experts sought reassurance Friday from Microsoft Corp. that aI     free software fix it offered effectively stops hackers from attackingS<     major flaws discovered in the latest version of Windows.  B     The government's rare interest in the problems with Windows XPB     software, which is expected to be widely adopted by consumers,C     illustrates U.S. concerns about risks to the Internet. Friday'svF     discussions came during a private conference call organized by the<     FBI's National Infrastructure Protection Center, its top     cyber-security unit.  E     Microsoft's experts bluntly acknowledged the threats posed by theaH     Windows XP problems, but they assured federal officials and industryE     experts that its fix -- if installed by consumers -- resolves the      issues.n  J     The company acknowledged Thursday that Windows XP suffers from seriousI     problems that allow hackers to steal or destroy a victim's data files H     across the Internet or implant rogue computer software. The glitchesI     were unusually serious because they allow hackers to seize control ofeI     all Windows XP operating system software without requiring a computer 7     user to do anything except connect to the Internet.a  G     Microsoft declined to tell U.S. officials Friday how many consumers E     downloaded and installed its fix during the first 24 hours it waseE     available. Experts from Internet providers, including AT&T Corp.,rK     argued that information was vital to determine the scope of the threat.t  J     Microsoft also indicated it would not send e-mail reminders to WindowsJ     XP customers to remind them of the importance of installing the patch.  E     One participant in the call, who spoke on condition of anonymity, H     otherwise described Microsoft officials as ``extremely forthright.''J     Microsoft explained that a new feature of Windows XP can automaticallyB     download the free fix, which takes several minutes, and prompt     consumers to install it.  J     ``The patch is effective,'' said Steve Lipner, Microsoft's director ofH     security assurance, who participated in Friday's call. ``There was aG     discussion of the importance of the Windows auto-update capability.nL     People were encouraged by the fact that we'll get the patch to people.''  H     Officials also expressed fears to Microsoft about electronic attacksF     launched against Web sites and federal agencies during next week'sJ     Christmas holidays from computers running still-vulnerable versions of     Windows, participants said.t  E     Several experts said they had already managed to duplicate withintD     their research labs so-called ``denial of service'' attacks madeJ     possible by the Windows XP flaws. Such attacks can overwhelm Web sites1     and prevent their use by legitimate visitors.c  I     ``That was the one you'll more likely see over Christmas break,'' ones     participant said.l  G     Another risk, that hackers can implant rogue software on vulnerabletB     computers, was considered more remote because of the technical     sophistication needed.  F     The FBI's cyber-security unit has been particularly worried latelyE     about the threats from denial of service attacks. It warned again C     Thursday that it ``has reason to believe that the potential fore*     (denial of service) attacks is high.''  F     The FBI said people have indicated they plan to target the DefenseG     Department's Web sites, as well as other organizations that supporto)     the nation's most important networks.c  G     Participants in Friday's call included the FBI; Defense Department;FH     the U.S. Federal Computer Incident Response Center; federally fundedJ     CERT Coordination Center; eEye Digital Security Inc., which discovered@     the Windows XP problems; Network Associates Inc.; the SystemC     Administration, Networking and Security Institute; and others."m      4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------  # Date: Sat, 22 Dec 2001 04:26:49 GMTb1 From: "David J. Dachtera" <djesys.nospam@fsi.net>n7 Subject: Re: OT: Windows XP, biggest security hole yet.a' Message-ID: <3C240BFB.12860F63@fsi.net>p   Shane Smith wrote: > " > Think I'm joking? Take a look at > D > http://www.washingtonpost.com/wp-dyn/articles/A7050-2001Dec20.html > J >         A Microsoft official acknowledged that the risk to consumers wasK >         unprecedented because the glitches allow hackers to seize control I >         of all Windows XP operating system software without requiring aMF >         computer user to do anything except connect to the Internet. > F > You know it's bad if a Microsoft spokesman calls an MS security holeE > "unprecedented", they usually play them down as much as possible. I I > don't think that can be described as "glitches", personally. And it was H > 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. Apparentlyo9 > it's OK because it's so much harder to break into XP...L  A Micro$hit should just voluntarily dissolve itself and let all itslB employees go. Bill Gates has enough bux to last him ten lifetimes, anyway.e   --   David J. Dachtera  dba DJE Systemsi http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t   ------------------------------  # Date: Sat, 22 Dec 2001 00:34:13 GMTp3 From: Christopher Stacy <cstacy@spacy.Boston.MA.US> D Subject: Re: PDP-10 architectural flaws? (was: VMS missing features). Message-ID: <uvgf0f5yy.fsf@spacy.Boston.MA.US>  E >>>>> On Fri, 21 Dec 2001 20:03:55 +0000, Alan Greig ("Alan") writes:@  Alan> Alan Greig wrote:N  >> Ah wait I think Bob might also be thinking of the NOOP JUMPA that wasn't a  L That stuff was not a feature of the PDP-10, but rather a feature of TOPS-20.   ------------------------------  % Date: Sat, 22 Dec 2001 00:48:25 +0000M% From: Alan Greig <a.greig@virgin.net>MD Subject: Re: PDP-10 architectural flaws? (was: VMS missing features)* Message-ID: <3C23D858.5FD4AA45@virgin.net>   Christopher Stacy wrote:  G > >>>>> On Fri, 21 Dec 2001 20:03:55 +0000, Alan Greig ("Alan") writes:v >  Alan> Alan Greig wrote:P >  >> Ah wait I think Bob might also be thinking of the NOOP JUMPA that wasn't a >vN > That stuff was not a feature of the PDP-10, but rather a feature of TOPS-20.  Q I know. Next you'll be telling me that jsys% was a feature of TOPS-20 rather than  the PDP-10 :-)  Q Little known fact (well maybe not to some people here!). TOPS-20 implemented partuI of one TOPS-10 UUO entirely natively. A GETTAB UUO for the OPSYS type was M understood directly by TOPS-20 monitor. Control was not passed to the PA-1050 O TOPS-10 emulator. Even the TOPS-10 Monitor calls manual gave the value returned/ for TOPS-20.  P In theory an executable could figure out whether it was running under TOPS-10 orN TOPS-20 and use native calls accordingly. Not that I recall any that ever did. --
 Alan Greig   ------------------------------  # Date: Sat, 22 Dec 2001 04:07:28 GMTe3 From: Christopher Stacy <cstacy@spacy.Boston.MA.US>uD Subject: Re: PDP-10 architectural flaws? (was: VMS missing features). Message-ID: <u3d23ganz.fsf@spacy.Boston.MA.US>  E >>>>> On Sat, 22 Dec 2001 00:48:25 +0000, Alan Greig ("Alan") writes:e    Alan> Christopher Stacy wrote:   I  >> >>>>> On Fri, 21 Dec 2001 20:03:55 +0000, Alan Greig ("Alan") writes:   Alan> Alan Greig wrote:Q  >> >> Ah wait I think Bob might also be thinking of the NOOP JUMPA that wasn't ae  >> P  >> That stuff was not a feature of the PDP-10, but rather a feature of TOPS-20.    Alan> I know.  I Yeah, but some other people (the original poster, for example) might not.    ------------------------------    Date: 21 Dec 2001 22:10:50 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)PP Subject: Re: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations3 Message-ID: <J9HqeBo4oc22@eisner.encompasserve.org>    In article <Pine.LNX.4.21.0112212011590.5800-100000@sakura.lunar-tokyo.net>, Daniel Seagraves <dseagrav@sakura.lunar-tokyo.net> writes:-  J > I did some testing... I can get my UNIX machines into a 100% secure modeK > of operation MUCH faster than OpenVMS!  I am using Linux for the UNIX OS,0E > and OpenVMS v7.2.  The OpenVMS machine is a MicroVAX 3100, the UNIX/J > machine is an Intel P3-700.  Both machines were rebooted and left at theF > system login prompt.  One of my friends (who types faster than I do,G > BTW) was at the VMS console, I was at the UNIX machine.  An impartial > > third party (My sister) was the starter.  She shouted "GO!". > H > On cue, Nate (my friend) logged in as SYSTEM on the VMS node, and I as; > root on the UNIX.  I typed "shutdown -h now" and he typedP > "@SYS$SYSTEM:SHUTDOWN".2  < Your friend can save time as SYSTEM by just typing SHUTDOWN.F It has been a default abbreviation in SYS$MANAGER:LOGIN.COM for years.  I > UNIX entered the 100% secure mode (I.E. the machine was powered off) in K > about 2 minutes.  VMS, however, took around 5 minutes to get to the point-" > where we could turn the VAX off. > D > See?  Proof, I can secure UNIX more then twice as fast as OpenVMS!  C If you cut the power to your VMS machine it will be equally secure. ? The careful-write approach taken by RMS ensures disk integrity.H? Any fixup you choose to perform as part of reboot just recovers_C unused disk blocks to the pool -- the file system is intact withouto it.o   ------------------------------  % Date: Fri, 21 Dec 2001 20:18:41 -0600 8 From: Daniel Seagraves <dseagrav@sakura.lunar-tokyo.net>Y Subject: Proof!  I can secure UNIX faster than VMS! Was: Re: Congratulations for the fest-L Message-ID: <Pine.LNX.4.21.0112212011590.5800-100000@sakura.lunar-tokyo.net>  + On Fri, 21 Dec 2001, Fred Kleinsorge wrote:r  & > > Properly implemented, UNIX has the* > > potential for being a lot more secure, >  > Why do you believe this?  H I did some testing... I can get my UNIX machines into a 100% secure modeI of operation MUCH faster than OpenVMS!  I am using Linux for the UNIX OS,tC and OpenVMS v7.2.  The OpenVMS machine is a MicroVAX 3100, the UNIXeH machine is an Intel P3-700.  Both machines were rebooted and left at theD system login prompt.  One of my friends (who types faster than I do,E BTW) was at the VMS console, I was at the UNIX machine.  An impartialt< third party (My sister) was the starter.  She shouted "GO!".  F On cue, Nate (my friend) logged in as SYSTEM on the VMS node, and I as9 root on the UNIX.  I typed "shutdown -h now" and he typed- "@SYS$SYSTEM:SHUTDOWN".0  G UNIX entered the 100% secure mode (I.E. the machine was powered off) inuI about 2 minutes.  VMS, however, took around 5 minutes to get to the pointe  where we could turn the VAX off.  B See?  Proof, I can secure UNIX more then twice as fast as OpenVMS!  F And, I might add that my PDP-10, a KS-10, is even more secure than theI UNIX machine.  It has no operating system, therefore, it's ALREADY turnedl off!    * (Hey, I'm allowed to have fun, right? ^_^)   ------------------------------  # Date: Sat, 22 Dec 2001 00:19:31 GMTa From: danco@pebble.org( Subject: Re: QIOs, ASTs, and Event Flags- Message-ID: <slrna27kci.k0o.danco@pebble.org>u  C In article <87vgf04c1y.fsf@prep.synonet.com>, Paul Repacholi wrote:   E > Remember the AST gives you back some info, and for an IO completion0A > AST, the 'AST Parameter' is the address of the associated IOSB.O  @ I didn't see the start of this thread, but so far as I know, theA ASTPRM parameter is not the address of the associated IOSB unless ? you _explicitly_ make it so when you call a system service thati; has an ASTPRM parameter (such as QIO and friends).  You can.; obviously pass (usually the address of) just about anything ; you like for the ASTPRM parameter.  If you want to pass the  IOSB address, that's fine too.   - Dans   ------------------------------  % Date: Fri, 21 Dec 2001 20:13:43 -0500   From: John Santos <JOHN@egh.com>( Subject: Re: QIOs, ASTs, and Event Flags6 Message-ID: <1011221200230.59837C-100000@Ives.egh.com>  % On 22 Dec 2001, Paul Repacholi wrote:n  1 > JF Mezei <jfmezei.spamnot@videotron.ca> writes:P >  > > Paul Repacholi wrote:r > D > > > Yep, and remember, the AST hands you back the IOSB address forG > > > free :) So hang all the stuff you need after the IOSB and you areh
 > > > set. > B > > Care to explain this ? I don't quite understand how an AST can+ > > automatically have access to the IOSB ?a > E > Remember the AST gives you back some info, and for an IO completioneA > AST, the 'AST Parameter' is the address of the associated IOSB.-  ? No, the 'AST Parameter' received by the AST routine is the 'ASTr@ Parameter' arg you specified in the $QIO (the sixth arg, astprm,@ immediately after the fifth arg, astadr.)  It's an optional arg.A The online help doesn't specify what the AST routine would see ifSA you don't specify it in the $QIO; I always assumed it would see aO7 zero, but maybe it defaults to the address of the IOSB?   F > So, if we lay out a structure with the directive stuff, IOSB, bufferG > pointer, scratch monkey, and the rest all in a standard order then weIH > can do all the processing from that structure.  When we enter the AST,; > we have a pointer to this structure via the IOSB address.s  C The IOSB is a good candidate to put first because it is a quadword,tB and alignment is important both if you care about performance (whyH are you using AST's and asynch I/O if you *don't* care about performanceA and if you are writing multi-threaded code, since aligment avoidsuA the "multiple writers to bytes in the same quadword" interlockingn@ problems and potential cache flushes.  (Your structure should of3 course be aligned on at least a quadword boundary.)h   >  > -- s> > Paul Repacholi                               1 Crescent Rd.,9 > +61 (08) 9257-1001                           Kalamunda.uB >                                              West Australia 60760 > Raw, Cooked or Well-done, it's all half baked.H > EPIC, The Architecture of the future, always has been, always will be. >  >    --   John Santosv Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------    Date: 21 Dec 2001 20:34:09 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)t( Subject: Re: QIOs, ASTs, and Event Flags3 Message-ID: <nd6W0o6s0SRe@eisner.encompasserve.org>   Y In article <1011221200230.59837C-100000@Ives.egh.com>, John Santos <JOHN@egh.com> writes:n' > On 22 Dec 2001, Paul Repacholi wrote:i > 2 >> JF Mezei <jfmezei.spamnot@videotron.ca> writes: >> w >> > Paul Repacholi wrote: >> sE >> > > Yep, and remember, the AST hands you back the IOSB address foreH >> > > free :) So hang all the stuff you need after the IOSB and you are >> > > set.e >> kC >> > Care to explain this ? I don't quite understand how an AST cant, >> > automatically have access to the IOSB ? >> (F >> Remember the AST gives you back some info, and for an IO completionB >> AST, the 'AST Parameter' is the address of the associated IOSB. > A > No, the 'AST Parameter' received by the AST routine is the 'AST7B > Parameter' arg you specified in the $QIO (the sixth arg, astprm,B > immediately after the fifth arg, astadr.)  It's an optional arg.C > The online help doesn't specify what the AST routine would see if C > you don't specify it in the $QIO; I always assumed it would see a 9 > zero, but maybe it defaults to the address of the IOSB?w  C Even if it did default to the IOSB address for some system service,oA nobody should depend on that behavior unless VMS has committed ton! maintaining it by documenting it.l   ------------------------------  % Date: Fri, 21 Dec 2001 23:12:13 -0500e  From: John Santos <JOHN@egh.com>( Subject: Re: QIOs, ASTs, and Event Flags6 Message-ID: <1011221231015.59837B-100000@Ives.egh.com>  & On 21 Dec 2001, Larry Kilgallen wrote:  [ > In article <1011221200230.59837C-100000@Ives.egh.com>, John Santos <JOHN@egh.com> writes:s) > > On 22 Dec 2001, Paul Repacholi wrote:e > > 4 > >> JF Mezei <jfmezei.spamnot@videotron.ca> writes: > >> n > >> > Paul Repacholi wrote: > >> "G > >> > > Yep, and remember, the AST hands you back the IOSB address for J > >> > > free :) So hang all the stuff you need after the IOSB and you are
 > >> > > set.i > >> fE > >> > Care to explain this ? I don't quite understand how an AST canr. > >> > automatically have access to the IOSB ? > >> eH > >> Remember the AST gives you back some info, and for an IO completionD > >> AST, the 'AST Parameter' is the address of the associated IOSB. > > C > > No, the 'AST Parameter' received by the AST routine is the 'AST D > > Parameter' arg you specified in the $QIO (the sixth arg, astprm,D > > immediately after the fifth arg, astadr.)  It's an optional arg.E > > The online help doesn't specify what the AST routine would see ifdE > > you don't specify it in the $QIO; I always assumed it would see ax; > > zero, but maybe it defaults to the address of the IOSB?h > E > Even if it did default to the IOSB address for some system service,uC > nobody should depend on that behavior unless VMS has committed too# > maintaining it by documenting it.t  C Maybe it is documented, but I'm too lazy to look it up (I did checkuC HELP system_services $QIO), and since Paul made the claim, I'll let  him check the docs.  ;-P     -- t John Santosr Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Fri, 21 Dec 2001 23:08:12 -0500 ' From: Howard S Shubs <howard@shubs.net>d( Subject: Re: QIOs, ASTs, and Event Flags< Message-ID: <howard-0E8D92.23081221122001@enews.newsguy.com>  6 In article <1011221200230.59837C-100000@Ives.egh.com>,"  John Santos <JOHN@egh.com> wrote:  A > No, the 'AST Parameter' received by the AST routine is the 'ASTiB > Parameter' arg you specified in the $QIO (the sixth arg, astprm,B > immediately after the fifth arg, astadr.)  It's an optional arg.C > The online help doesn't specify what the AST routine would see ifiC > you don't specify it in the $QIO; I always assumed it would see aw9 > zero, but maybe it defaults to the address of the IOSB?f  L It would see no parameters, as it's not an exit handler or some such.  What O you stick in the ASTPRM address should look like a parameter block, as follows:   K first byte: number of following longwords (followed by three bytes of fill)s% second  lw:     first parameter valueu& third   lw:     second parameter value  etc.g    & If I had an AST which looked like this  -    integer*4 function foo (bar, bletch, feep)    ...the ASTPRM should look like      structure foo_paramss      byte arg_count /3/       byte %fill(3)      integer*4 ptr_to_bar       integer*4 ptr_to_bletch      integer*4 ptr_to_feep    end structure  !foo_paramse  D ...and would need to be filled in with %loc(bar), %loc(bletch), and J %loc(feep), whatever they were defined as. ...using VMS FORTRAN 77 syntax. -- h Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"- Xerox is the anti-Microsoft.  And visa-versa.e   ------------------------------    Date: 21 Dec 2001 15:33:24 -0800) From: P.Young@unsw.EDU.AU (Patrick Young)n( Subject: Re: Strange quorum disk problem< Message-ID: <55f85d77.0112211533.dc8f4ef@posting.google.com>  a Paul Repacholi <prep@prep.synonet.com> wrote in message news:<87pu596f8n.fsf@prep.synonet.com>...e  E > If it is only when you are testing stuff with backup, ignore it. Or ? > re-config the mess so the drive is a higher LUN than the host D > controllers. EG, make the drive LUN7, and the controllers 6 and 5.  B Many thanks for the suggestion - being intent on swapping hardwareC around (being under the assumption it worked for two weeks prior toiB the problem - which I am now wondering about - paranoia sets in) I did not think about this.e  > It is a new configuration, I just set it up about a month ago.  D The problem I have in ignoring it is that when the other node in the@ SCSI cluster is down I can't do backups without causing constant one minute duration hangups.  B At this point in the year "the other node" is not doing much, so IA removed it soon after to do another task for a couple of days and- therefore noticed the problem.  E Next year that will change and it will be just as important, thus thenH quorum disk requirement and requirement that during an emergency/problemD with one node the other can continue with no problems (although each! have different tasks to perform)./  ? > re-config the mess so the drive is a higher LUN than the host   E Tried this yesterday, however did not make a lot of difference. I did B however manage to provide myself with a good 5 minutes of joy that@ the problem went away until I remembered I forgot to also adjust0 DISK_QUORUM :-( to point to the new device name.  0 Another try just now (SSH session from home) ...  8 %%%%%%%%%%%  OPCOM  22-DEC-2001 09:57:37.42  %%%%%%%%%%%A 09:57:37.42 Node TEACH (csid 00010001) failed to read quorum disks  > The OpenVMS quorum code uses an alternate entry point into theB SCSI DKDRIVER specifically so that quorum I/Os are not queued withE ordinary I/Os. This sort of thing, ie: priority access, seems to havet been thought about.s  F      DKDRIVER (the only driver supporting valid quorum disks) has beenJ      modified to provide an alternate entry point for quorum file read and      write I/Os.  F I guess I just have to study it a bit harder. I updated to OpenVMS 7.3E (Also Advanced Server, most compilers and a couple of other products)rI from 7.2-1 yesterday and installed all available 7.3 patches. Very smoothMC upgrade BTW - took just under an hour longer in downtime last night-G than I would have liked - my fault. I do the upgrade offline and BACKUPcH in the new VMS$COMMON to save downtime. It would appear that OpenVMS 7.33 with all patches does not solve the problem either.f   Many thanks anyway.    ------------------------------  % Date: Fri, 21 Dec 2001 23:40:46 +0000a% From: Alan Greig <a.greig@virgin.net>n( Subject: Re: Strange quorum disk problem* Message-ID: <3C23C87D.D5551501@virgin.net>   Patrick Young wrote:  c > Paul Repacholi <prep@prep.synonet.com> wrote in message news:<87pu596f8n.fsf@prep.synonet.com>...0 > G > > If it is only when you are testing stuff with backup, ignore it. Or A > > re-config the mess so the drive is a higher LUN than the hostvF > > controllers. EG, make the drive LUN7, and the controllers 6 and 5. >:D > Many thanks for the suggestion - being intent on swapping hardwareE > around (being under the assumption it worked for two weeks prior toaD > the problem - which I am now wondering about - paranoia sets in) I > did not think about this.w >e  _ Did you tune the account BACKUP runs under after two weeks? BACKUP running from an account withkB DEFAULT's quotas is far less likely to cause quorum glitches IIRC. --
 Alan Greig   ------------------------------  % Date: Fri, 21 Dec 2001 21:16:42 -0500o From: gce <ge@gce.com>@ Subject: Re: VMS missing features (was how to do deamons on VMS)' Message-ID: <3C23ED0A.C3CFD23A@gce.com>e   Paul Repacholi wrote:  >  > gce <ge@gce.com> writes: > H > > I believe that some VERY late RSX11M or maybe just M+ releases wouldK > > accept decimal version numbers. For most of their history they did not.g > L > Micro RSX and POX started that cruft. It was an option though, so it could > be canned. > N > > The very earliest pdp10 systems had no highseg hardware and I believe just5 > > handed out memory as a user process asked for it.s > < > The 10s all had 2 seg or better, it was the 6 that didn't. > Q Nope. I USED a pdp10 back in 1970 that did not at first have it. Highseg hardware N was added late that year but the machine had been in use for some time without it.  Glenn Everhart   ------------------------------  % Date: Fri, 21 Dec 2001 18:04:44 -0800w! From: Jack Hamilton <jfh@acm.org> @ Subject: Re: VMS missing features (was how to do deamons on VMS)8 Message-ID: <n5q72us1dij0819tj3eqa54idi88ajhvnt@4ax.com>  , Mark Crispin <mrc@CAC.Washington.EDU> wrote:  * >On Fri, 21 Dec 2001, Jack Hamilton wrote:  E >> By the way, a fair amount of student computing (heavy-duty FORTRANhG >> number-crunching, not learning to program) took place on the big MVSaI >> system.  It used Stanford WYLBUR as its text editor and job submissionlH >> system.  WYLBUR was later enhanced to use PDP-11's (I think) as front >> ends. > D >The MVS system had fallen by the wayside by the time the DEC-20 was >retired in favor of UNIX.  B I worked in the MVS accounting office in the late 1970's and earlyD 1980's, worked with students, saw the bills, and can assure you thatF there was considerable use of MVS.  It was declining, yes, but "fallen% by the wayside" is an overstatement. s  J >And the whole reason why LOTS was created in 1976 was because of a desireK >to get away from SCIP and MVS/WYLBUR.  Remember the protest march in 1975?   H No.  I might have been overseas at the time.  I do remember LOTS, in theG lobby of that education building over by UGLY, and I have fond memoriesT of SAIL and TOPS-20.   ------------------------------  # Date: Sat, 22 Dec 2001 04:18:37 GMTe3 From: Christopher Stacy <cstacy@spacy.Boston.MA.US>.@ Subject: Re: VMS missing features (was how to do deamons on VMS). Message-ID: <uwuzfevky.fsf@spacy.Boston.MA.US>  > >>>>> On Fri, 21 Dec 2001 21:16:42 -0500, gce  ("gce") writes:    gce> Paul Repacholi wrote:,  >>   >> gce <ge@gce.com> writes:  >> J  >> > I believe that some VERY late RSX11M or maybe just M+ releases wouldM  >> > accept decimal version numbers. For most of their history they did not.   >> N  >> Micro RSX and POX started that cruft. It was an option though, so it could  >> be canned.  >> P  >> > The very earliest pdp10 systems had no highseg hardware and I believe just7  >> > handed out memory as a user process asked for it.s  >> >  >> The 10s all had 2 seg or better, it was the 6 that didn't.  F  gce> Nope. I USED a pdp10 back in 1970 that did not at first have it.?  gce> Highseg hardware was added late that year but the machinec/  gce> had been in use for some time without it.p  D Some sites had advanced memory features earlier, but they made theirF own hardware modifications.  For example, the Lawrence Livermore folksF had both segmentation and paging on their PDP-6 in the summer of 1966.I At MIT, the AI Lab KA-10 had very fancy paging hardware at least by 1970.iJ But we ran our own operating system (much fancier then the ones from DEC).   ------------------------------  % Date: Fri, 21 Dec 2001 20:59:13 -0800p+ From: Mark Crispin <mrc@CAC.Washington.EDU>s@ Subject: Re: VMS missing features (was how to do deamons on VMS)U Message-ID: <Pine.NXT.4.50.0112212058250.7435-100000@Tomobiki-Cho.CAC.Washington.EDU>T  ) On Fri, 21 Dec 2001, Jack Hamilton wrote:XF > >The MVS system had fallen by the wayside by the time the DEC-20 was > >retired in favor of UNIX.D > I worked in the MVS accounting office in the late 1970's and earlyF > 1980's, worked with students, saw the bills, and can assure you thatH > there was considerable use of MVS.  It was declining, yes, but "fallen& > by the wayside" is an overstatement.  G The DEC-20 was not retired in favor of UNIX until many years later thang the early 1980s.  
 -- Mark --   http://staff.washington.edu/mrceF Science does not emerge from voting, party politics, or public debate.   ------------------------------  % Date: Fri, 21 Dec 2001 18:57:35 -0500T  From: John Santos <JOHN@egh.com>- Subject: Re: VMSclusters and network switches<6 Message-ID: <1011221180947.59837A-100000@Ives.egh.com>  , On Fri, 21 Dec 2001, John E. Malmberg wrote:   > Rich Jordan wrote: > E > > The reason I'm asking is I have a clear recollection of _someone_ J > > posting here or in another related newsgroup about known problems withJ > > many network switch codebases that could negatively impact a cluster. C > > I haven't been able to locate the posts (haven't had time for a  > > complete search either). >  > G > Basically from what I have been told by people who seem to know more r > about networks than I do:u > F > Watch out for auto-negotiate!  If you have a thin-net or thick wire * > ethernet on a switch, it is half-duplex.  H Yes!  I'm not sure I've ever had a DEC/Compaq Ethernet card successfullyG autonegotiate with a switch.  (Most or all the switches are 3rd party.) F There have been several ECO's. mostly LAN ECO's, that mention problemsC with autonegotiation, including one very recently. VMS721_LAN-V0300,A and VMS73_LAN-V0200 (also for 7.2-1h1 and 7.2-2, I think), that Ir* haven't tried yet, so it may now be fixed.  D The problems seem to be 1) failure to negotiate the speed, which canE often be fixed by unplugging the ethernet cable for about 30 seconds,I@ which sometimes makes the switch reset the speed, and appears toB often work.  This only has to be done once, after you boot for theH 1st time after changing EWx0_MODE in the console.  However, it sometimesC leads to problem 2) failure to autonegotiate FULL/HALF duplex.  TheaC only fix for this seems to be explicitly setting the switch and therD EWx0_MODE to the same setting.  I think you need a managed switch toC be able to do this, unless the switch had dip switches or something G to control the mode.  The symptom of this is lots of Ethernet framing &aF alignment errors reported to OPCOM, and drastically reduced throughputF when the ethernet load is heavy.  Under light load, it appears to workD fine.  Problem 3) is that sometimes VMS forgets that console settingC for the ethernet mode and sometime after initializing it (and maybe @ convincing the switch to run in one mode), it resets the mode toB something else.  I haven't seen this problem (AFAIK), and maybe itC only applied to earlier versions of VMS (I'm running only V7.2-1 orf) later, or maybe only to one type of NIC.)    > F > You basically can not have 1/2 duplex links communicating with full ? > duplex links on the same switch network (one colision domain)o > H > You need a router isolate the full duplex and half duplex sections of 8 > the network, and of course that has it's own problems. > A > I have seen this happen where only a few hosts with full duplex E > connections in a half duplex network can effectively jam the entiree	 > networko  M My cluster has 2 half-dup, 10Mb nodes (VAX and old Alpha DEC 3000 model 300),,A and one 100Mb FD node (AlphaServer 1200).  Once we got the switcha? and the nodes explicitly set to same modes, it has worked fine. C Served disk speed is what we expect (limited by the 10Mb ethernet.)y  B There are many other 100Mb hosts on the switch (most new PC's comeC with 10/100 cards and successfully autonegotiate, so VMS'es failure9@ to do this is a little embarrassing.)  There is occasional heavy? net traffic (PC backups, and a pair of Suns one of which does asB network backup of the other to DLT.)  The two Suns are on a secondI switch hanging of the 1st one, so that switch should isolate the traffic.>D However, at least one of the PC's that gets backed up is on the sameA secondary switch and the PC with the tape drive is on the primarye@ switch.  And the Alpha regularly backs up an RZ26 and an RZ28 onA other VAX and two DSSI disks and HSD05-served RZ29 to a local 8mmI tape drive.   @ Given that there are no obvious problems, would we be better off= changing the 1200 back to 10Mb half-duplex to match the othere  nodes (or to 100Mb half-duplex?)   > K > Note that the problems induced are intermittant and hard to find, and it .J > is possible that some sites are mixing half duplex and full duplex with  > out any visible problems.'  D Maybe that's us!  (Or maybe I should have read this paragraph before3 writing my response to the previous paragraph?  :-)n   > But just be forewarned.B >  > -Johns > wb8tyw@qsl.network > Personal Opinion Onlyh   -- v John SantosS Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Sat, 22 Dec 2001 06:02:50 GMT0- From: "John E. Malmberg" <wb8tyw@qsl.network>:- Subject: Re: VMSclusters and network switches1* Message-ID: <3C2427C5.5000904@qsl.network>   John Santos wrote:  . > On Fri, 21 Dec 2001, John E. Malmberg wrote:  C >>Rich Jordan wrote: >> >>D >>>The reason I'm asking is I have a clear recollection of _someone_I >>>posting here or in another related newsgroup about known problems with>I >>>many network switch codebases that could negatively impact a cluster.  B >>>I haven't been able to locate the posts (haven't had time for a >>>complete search either).d >>>a  G >>Basically from what I have been told by people who seem to know more e >>about networks than I do:> >>F >>Watch out for auto-negotiate!  If you have a thin-net or thick wire * >>ethernet on a switch, it is half-duplex. >>  J > Yes!  I'm not sure I've ever had a DEC/Compaq Ethernet card successfullyI > autonegotiate with a switch.  (Most or all the switches are 3rd party.)a    F At a networking class that I attended that had nothing to do with any F specific vendors product, the Instructor stressed that auto-negotiate ! was not reliable between vendors.u  G He said that the process had not yet been standardized and only worked iF somewhat reliably if all the equipment came from the same vendor, and  was all at the same revision.u    H > There have been several ECO's. mostly LAN ECO's, that mention problemsE > with autonegotiation, including one very recently. VMS721_LAN-V0300nC > and VMS73_LAN-V0200 (also for 7.2-1h1 and 7.2-2, I think), that Ii, > haven't tried yet, so it may now be fixed.    I If you are current on the LAN eco's and are having problems with OpenVMS oH recognizing the console settings or the LANCP settings for the speed andC duplex, I would advise you to contact the CSC to get this resolved.d  H But from what I have heard about auto-negotiation, I avoid it where ever I can.    rB > Given that there are no obvious problems, would we be better off? > changing the 1200 back to 10Mb half-duplex to match the othert" > nodes (or to 100Mb half-duplex?)    I I am far from being a networking expert, but this is how I understand it.O  E With the ALPHA set to full duplex, it can send a response to the half'D duplex segment while it is still receiving data from the half duplexE segment. This will cause a collision on the half duplex side, and thedA full duplex system will resend the packet once the acknowlegementh
 times out.    G If you only have this happening once in a while you will not notice it.   G But it could just as easily get into a condition where the full duplex oE node can keep pumping data into the half duplex segment to the point t! that almost nothing can get done.   E Two half duplex segments of different speeds do not suffer from this IG problem.  The half duplex means that the slow links and the fast links tH will usually not be sending at the same time, hence most collisions are  avoided.  F In order to handle the connection between a full duplex segment and a F half duplex segment reliably, some sort of store and forward scheme isI needed that can buffer several messages.  That is more the function of a n router than a switch.r    K >>Note that the problems induced are intermittant and hard to find, and it nJ >>is possible that some sites are mixing half duplex and full duplex with  >>out any visible problems.v > F > Maybe that's us!  (Or maybe I should have read this paragraph before5 > writing my response to the previous paragraph?  :-)R    >  D A collision detect protocol like ethernet can ignore quite a bit of D network mis-configuration and cabling errors and still appear to be  quite functional.n  C Some of these problems can be detected with a network monitor, but fG others require actually monitoring the signal to see if there is noise e or distortion.   >  -Johno wb8tyw@qsl.network   Personal Opinion Onlyo   ------------------------------    Date: 21 Dec 2001 14:45:21 -0800( From: bob@instantwhip.com (Bob Ceculski)3 Subject: Re: Windows XP, biggest security hole yet.e= Message-ID: <d7791aa1.0112211445.3ebbf5f6@posting.google.com>o  z "Terry C. Shannon" <terryshannon@mediaone.net> wrote in message news:<UhKU7.24205$Sj1.12219564@typhoon.ne.mediaone.net>...3 > "Shane Smith" <ssmith@icius.com> wrote in messagen, > news:01C18A01.16CBF430@sulfer.icius.com...$ > > Think I'm joking? Take a look at > >nF > > http://www.washingtonpost.com/wp-dyn/articles/A7050-2001Dec20.html > >  > $ > Nope, I don't think you're joking. >  > Nor am I surprised.r  I that's why VMS will be around for a long time ... it has over 20 years ofhJ service that has proved it was written well for security while new massiveH amounts of windows code appears every other year ... which means it will be unstable and unsecure ...   ------------------------------  # Date: Fri, 21 Dec 2001 23:02:01 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>3 Subject: Re: Windows XP, biggest security hole yet.t> Message-ID: <JbPU7.24838$Sj1.12348800@typhoon.ne.mediaone.net>  5 "Bob Ceculski" <bob@instantwhip.com> wrote in messaget7 news:d7791aa1.0112211445.3ebbf5f6@posting.google.com...sA > "Terry C. Shannon" <terryshannon@mediaone.net> wrote in message%: news:<UhKU7.24205$Sj1.12219564@typhoon.ne.mediaone.net>...5 > > "Shane Smith" <ssmith@icius.com> wrote in messagel. > > news:01C18A01.16CBF430@sulfer.icius.com...& > > > Think I'm joking? Take a look at > > >hH > > > http://www.washingtonpost.com/wp-dyn/articles/A7050-2001Dec20.html > > >o > >a& > > Nope, I don't think you're joking. > >o > > Nor am I surprised.  > K > that's why VMS will be around for a long time ... it has over 20 years ofaL > service that has proved it was written well for security while new massiveJ > amounts of windows code appears every other year ... which means it will > be unstable and unsecure ...  B Preaching to the choir, my friend. Now, if only Compaq's MARKETING$ DEPARTMENT would pick up the chorus!   ------------------------------  % Date: Fri, 21 Dec 2001 17:10:27 -0500f, From: "Kenneth Block" <krblock@computer.org>K Subject: [anounce] Sanity Kit for Compaq C++ V6.5 for OpenVMS Alpha systems 1 Message-ID: <orOU7.333$sK3.5143@news.cpqcorp.net>-  J The sanity kit for Compaq C++ V6.5 for OpenVMS Alpha field test kit is now
 available.  H The kit can be downloaded by pointing your browser to the URL below. YouD will be asked to accept the license agreement and then will be givenH instructions to download the kit. If you would like to help us test thisI product and do not have a valid product authorization key (PAK) to invoke C the product please contact us immediately at field.test@compaq.com.h  H The information contained in this kit is confidential and proprietary toL Compaq, subject to the terms and conditions of your Agreement. This softwareJ has been made available to you for your internal use only. Please rememberJ that Compaq makes no warranties regarding the capability or performance of' this software. Further, Compaq warrantsu  J and represents that this software is field-test quality software and makesH it available to you "AS IS". This software may impact the functioning of4 your system(s) and thus, should be used accordingly.   KIT URL:  F <ftp://ftp.compaq.com/pub/products/C-CXX/OpenVMS/cxx/beta/ftindex.htm>   FIELD TEST SCHEDULE:  J Compaq C++ V6.5 for OpenVMS Alpha is currently scheduled for an eight-weekG field test. The following dates are accurate but are subject to change:E  % Start of field test November 09, 2001w   Field Test 2 December 10, 2001   Sanity December 21, 2001  " End of field test January 04, 2002   FIELD TEST SUPPORT:u  J A problem report should not be limited to reporting problems, but also mayK be used to supply information, ask questions, make suggestions, and keep usmC informed on how your field test is progressing. We encourage you torJ communicate with us as often as you would like. Please note that your siteH is one of a few selected to assist in this field test and we are relying: heavily on your reports to help us in the testing process.  L To report a problem, contact us at compaq_cxx.bugs@compaq.com. Thank you forL in advance for being a field test site. We look forward to hearing from you.       The Compaq C/C++ Team    ------------------------------   End of INFO-VAX 2001.708 ************************