1 INFO-VAX	Tue, 09 May 2006	Volume 2006 : Issue 256       Contents:' Re: Compatibility Not Without Its Costs J Re: Compatibility Not Without Its Costs (was: Re: Linux kernel defective!) Re: Compressing backup file 8 Re: DCL versus Unix CLIs, was: Re: File output like UnixP Re: H P To Launch Multi Million Dollar Ad Campaign For The PC [WAS Re: OT: IntelP Re: H P To Launch Multi Million Dollar Ad Campaign For The PC [WAS Re: OT: Intel> Re: HP TCPIP SMTP setup for Process PMAS, is it even possible?+ Re: IMCB$V_PARENT_PROT What is it good for?  Re: Linux kernel defective! 9 Re: Looking for power supply/supplies for DS20e in Europe ) Re: Mac OS X no longer immune to viruses! ) Re: Mac OS X no longer immune to viruses! ) Re: Mac OS X no longer immune to viruses! ) Re: Mac OS X no longer immune to viruses! ) Re: Mac OS X no longer immune to viruses! - Re: OT: Intels quickens cadence for new 8086s - Re: OT: Intels quickens cadence for new 8086s  Poster defective!  Re: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11 Re: SGI files for chapter 11 TCPIP 5.4 anti-spam  Re: TCPIP 5.4 anti-spam  Re: TCPIP 5.4 anti-spam P Re: This post will self-destruct in 10secs (Was Re: X windows  vulnerability)  vL Re: This post will self-destruct in 10secs (Was Re: X windows vulnerability)L Re: This post will self-destruct in 10secs (Was Re: X windows vulnerability)L RE: This post will self-destruct in 10secs (Was Re: X windows vulnerability) Updated VMS information May 7th  Re: X windows vulnerability   F ----------------------------------------------------------------------  % Date: Tue, 09 May 2006 01:07:26 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 0 Subject: Re: Compatibility Not Without Its Costs9 Message-ID: <GLqdnZO_jLhEv_3ZnZ2dnUVZ_v2dnZ2d@libcom.com>    Hoff Hoffman wrote:  > bob@instantwhip.com wrote: >> http://www.t....  > H >   The cited article references a discussion from somebody that claims 5 > there are too many defects in recent Linux kernels.  > 8 >   All kernels are defective, to one degree or another. > K >   All kernels that have to deal with older hardware are almost certainly  C > going to have compatibility problems -- and this includes Linux,   > Windows, HP-UX, and OpenVMS. > K >   There are certainly a number of areas within the OpenVMS kernel that I  J > would consider to be problematic, FWIW -- decisions and trade-offs that E > are made in any kernel over the years tend to inevitably have this  J > outcome, particularly whenever a central tenet involves the maintenance M > of source and binary compatibility, or of long-term hardware compatibility.   A Strengths can actually be weaknesses, depending upon perspective.   H >   And if I could banish various parts of the SCSI stack that very few H > folks are still using, for instance, as they're only needed for or by = > older (and arguably buggy) devices, I most certainly would.  > H >   I'm sure anybody that's looked at CDRECORD or its derivatives would E > certainly be willing to comment on the relative effort involved in  G > maintaining compatibility with ancient CD and DVD recording hardware  F > while also working correctly with newer hardware.  (These recording @ > drives used to be seriously expensive, and now they're nearly & > pocket-change replaceable hardware.)  G Many of the devices that are developed mainly for windows systems come  H with drivers written specifically for the device.  I doubt that many of $ those drivers support older devices.  C I wonder how many PC devices from 1990 would still be supported on  F windows today?  How many drivers from 1990?  With large enough disks, 7 what's the odds on today's VMS running on a VAX 11/780.   D >   Eventually, any long-lived and evolving software package has to G > (explicitly or implicitly) drop older hardware; sooner or later, you  I > will be forced to break from compatibility, as you simply can't manage  J > an ever-increasing hardware test matrix without requiring near-infinite  > testing resources. > $ >   TANSTAAFL, to quote Mr Heinlein. >  >      --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  # Date: Mon, 08 May 2006 17:59:08 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>S Subject: Re: Compatibility Not Without Its Costs (was: Re: Linux kernel defective!) 0 Message-ID: <MFL7g.225$d33.219@news.cpqcorp.net>   bob@instantwhip.com wrote: > http://www.t....  G    The cited article references a discussion from somebody that claims  3 there are too many defects in recent Linux kernels.   7    All kernels are defective, to one degree or another.   @    All kernels that have to deal with older hardware are almost D certainly going to have compatibility problems -- and this includes # Linux, Windows, HP-UX, and OpenVMS.   H    There are certainly a number of areas within the OpenVMS kernel that E I would consider to be problematic, FWIW -- decisions and trade-offs  H that are made in any kernel over the years tend to inevitably have this H outcome, particularly whenever a central tenet involves the maintenance K of source and binary compatibility, or of long-term hardware compatibility.   G    And if I could banish various parts of the SCSI stack that very few  F folks are still using, for instance, as they're only needed for or by ; older (and arguably buggy) devices, I most certainly would.   G    I'm sure anybody that's looked at CDRECORD or its derivatives would  C certainly be willing to comment on the relative effort involved in  E maintaining compatibility with ancient CD and DVD recording hardware  D while also working correctly with newer hardware.  (These recording > drives used to be seriously expensive, and now they're nearly $ pocket-change replaceable hardware.)  C    Eventually, any long-lived and evolving software package has to  E (explicitly or implicitly) drop older hardware; sooner or later, you  G will be forced to break from compatibility, as you simply can't manage  H an ever-increasing hardware test matrix without requiring near-infinite  testing resources.  #    TANSTAAFL, to quote Mr Heinlein.    ------------------------------  % Date: Mon, 08 May 2006 18:45:13 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>$ Subject: Re: Compressing backup file6 Message-ID: <445FD809.AA4BC4DD@NeOaSrPtAhMlNiOnWk.net>   Kevin Handy wrote: > $ > VMS 5.5-2, MicroVax 3100, 8Mb RAM.9 > Yes, it's an old machine, but it works fine for what it  > is doing.  > : > I am looking at creating a backup file, then compressing1 > it, copying it to a PC, and burning it to a CD. 7 > The test savesets I'm playing with are in the 200,000 : > to 400,000 block size. Real ones would likely be larger. > < > Yes, I could put a CD burner on the VAX, but at this stage9 > I'm looking at generating the data first, and where the 8 > burner is located isn't my problem yet. Generating the9 > backup sets in a reasonable time is my current problem.  > 0 > This is for making periodic permanent backups.0 > They are currently using tape (various TLZ???)6 > but having serious reliability problems (dust, etc.) > : > The backup images will be too big to fit on a CD without6 > compressing them, and moving them to a PC would lose > file attributes. > ; > I am able to do this on the VAX using 'zip "-V" ...', but : > it is very, very, very slow. I'd guess it's at least 10X= > slower than creating the original backup saveset (I've only = > let it run for 2 hours before giving up on a test saveset). 3 > I'm not  sure the process would finish overnight.  > 6 > Zipping the individual files seems to be faster, but > still very slow. > ; > I could copy the uncompressed saveset to a windows PC and < > do the compression there, but wouldn't be able to automate< > it, and I would lose file attributes. I really want to run7 > this as an overnight process with the resulting files 9 > available to burn in the morning, and the less the user 7 > needs to work the better (the easier it is to do, the ' > more often it is likely to get done).  > ; > Anyone familiar with doing compression on the a VAX, with < > regards to the speed? Would gzip or bzip2 be better/faster) > (which would probably lose attributes)?  >  > Any options/discussions?  ? About all I can add is that the compression process is very CPU F intensive. VAXes always seems to be rather slower than Alpha for this.  D I'd be inclined to take Eberhard's advice and write stuff out to DVD. recordable. That may still take awhile, but...   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------   Date: 8 May 2006 16:36:41 -0700 $ From: "AEF" <spamsink2001@yahoo.com>A Subject: Re: DCL versus Unix CLIs, was: Re: File output like Unix C Message-ID: <1147131401.820055.305990@u72g2000cwu.googlegroups.com>    Bob Koehler wrote:l > In article <1147022551.096797.203100@j73g2000cwa.googlegroups.com>, "AEF" <spamsink2001@yahoo.com> writes: > @ > > And that's part of what makes .EXE special. Try this: renameJ > > SYSBOOT.EXE to have some other file type and reboot. Good luck. (Note:I > > I haven't tried this. Maybe it actually works anyway, but I doubt it. 8 > > If I have time later, I'll try it on a test system!) > H >    That's not a valid test.  If the boot software is coded to look forI >    able.a and you rename it to able.b then the boot software will fail,   >    no matter what a abd b are.  F Your right! Yeah, I knew it was a stretch. Glad to see you and JF were awake and caught it!  I >    A valid test is to find one of at least two places in VMS where .EXE F >    is the required extension only because someone made it so in code' >    that could have accepted anything.   B One of at least two? If you find only one, how do you know there's another?    Anyway, let's go back to .DIR;1.  E The O/S only creates directories ending in .DIR;1. Additionally, said G files are created so that can't rename them without either changing the $ protections or enabling bypass priv.  C Normal directory syntax ([HELLO.THERE.MY.FRIEND], for example) only ( works with directories ending in .DIR;1.  F If that doesn't make .DIR;1 special to the OS, I don't know what does.  G Yes, you can go out of your way to make dangling non-.DIR;1 directories C dangling in ODS-5 state still accessible by the special DID format. F Yes, you can go out of your way to make a file with .DIR;1 that is notF a directory. Yes, you can reset the directory bit. But .DIR;1 is stillA special. In 21 years using VMS I have never encountered a problem G caused by these rather contrived scenarios. You can break the scheme by C these scenarios, but the scheme is that .DIR;1 is for directory and  that makes .DIR;1 special!  F RED with GREEN RIGHT ARROW doesn't mean that RED isn't special (see my  reply to Wilm for more on this.)   AEF    ------------------------------  % Date: Mon, 08 May 2006 09:00:39 -0600  From: Dan Notov <d9nno@hp.com>Y Subject: Re: H P To Launch Multi Million Dollar Ad Campaign For The PC [WAS Re: OT: Intel , Message-ID: <445f5d19$1@usenet01.boi.hp.com>   etmsreec@yahoo.co.uk wrote: D > Isn't that what's being proposed?  Isn't the PC business the least+ > profitable and the one with least margin? F > Perhaps HP are also having trouble shipping units, competing againstF > Dell and their ilk?  Proliants sell themselves since they are one ofB > the market leaders.  HP PCs on the other hand probably aren't asE > desirable.  Think about all the "incompatibilities" that there were . > with industry standard parts and Compaq PCs. > H HP has grabbed market share from Dell in the PC market. In Q1 FY06 HP's F Personal Systems Group doubled their profit over the same period last  year, to nearly $300M.    From the 1Q report:D Personal Systems Group (PSG) revenue grew 8% year-over-year to $7.4 H billion, with unit shipments up 16%. On a year-over-year basis, desktop B revenue increased 1% and notebook revenue grew 26%. Commercial PC I revenue grew 6% year-over-year, while Consumer PC revenue increased 18%.  I PSG reported an operating profit of $293 million, or 3.9% of revenue, up  L from a profit of $147 million, or 2.1% of revenue, in the prior-year period.  E Since PSG is no long merged with the Imaging & Printing Group, their   numbers stand alone.   ------------------------------  % Date: Tue, 09 May 2006 00:08:31 -0400 ' From: Dave Froble <davef@tsoft-inc.com> Y Subject: Re: H P To Launch Multi Million Dollar Ad Campaign For The PC [WAS Re: OT: Intel 9 Message-ID: <RoSdnQzg2InciP3ZnZ2dnUVZ_tmdnZ2d@libcom.com>    Dan Notov wrote: > etmsreec@yahoo.co.uk wrote: E >> Isn't that what's being proposed?  Isn't the PC business the least , >> profitable and the one with least margin?G >> Perhaps HP are also having trouble shipping units, competing against G >> Dell and their ilk?  Proliants sell themselves since they are one of C >> the market leaders.  HP PCs on the other hand probably aren't as F >> desirable.  Think about all the "incompatibilities" that there were/ >> with industry standard parts and Compaq PCs.  >>J > HP has grabbed market share from Dell in the PC market. In Q1 FY06 HP's H > Personal Systems Group doubled their profit over the same period last  > year, to nearly $300M. >  >  From the 1Q report:F > Personal Systems Group (PSG) revenue grew 8% year-over-year to $7.4 J > billion, with unit shipments up 16%. On a year-over-year basis, desktop D > revenue increased 1% and notebook revenue grew 26%. Commercial PC K > revenue grew 6% year-over-year, while Consumer PC revenue increased 18%.  K > PSG reported an operating profit of $293 million, or 3.9% of revenue, up  G > from a profit of $147 million, or 2.1% of revenue, in the prior-year  	 > period.  > G > Since PSG is no long merged with the Imaging & Printing Group, their   > numbers stand alone.  G In the summer of 2000 I sat in a meeting with the VMS people and heard   of some better numbers.   G VMS related revenue, around $4B, and profits, $800M.  That was without  C major advertising.  The advertising budget at that time was rather  ? small, maybe $12M or so, my memory isn't so good that far back.   I $800M and about 20% of revenue, vs $300M and 3.9% of revenue.  Makes you  4 wonder just where the advertising dollars should go.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------   Date: 8 May 2006 16:18:53 -0700 ( From: "Rich Jordan" <jordan@ccs4vms.com>G Subject: Re: HP TCPIP SMTP setup for Process PMAS, is it even possible? B Message-ID: <1147130333.909751.15490@j33g2000cwa.googlegroups.com>   Well, duh...  D Somehow protection on TCPIP$HOSTS.DAT got munged, lost world access.F Apache/SWS quietly declines to start under those conditions.  Found itE in the audit logs, but the failure was not set for alarms so I didn't  see it earlier.   D So the system is back up and happy without a restore.  I still don'tE have TCPIP SMTP working on an alternate port, but at least I know all . the experimentation really didn't kill Apache.  E More experimenting to follow.  If anyone out there has gotten this to / work I'd really like to hear about it.  Thanks!    Rich   ------------------------------  % Date: Mon, 08 May 2006 22:49:55 -0400 0 From: Glenn and Mary Everhart <everhart@gce.com>4 Subject: Re: IMCB$V_PARENT_PROT What is it good for?0 Message-ID: <12600ilj1dk8j13@corp.supernews.com>   Hoff Hoffman wrote:  > K >   It is my considered opinion as an engineer with some slight experience  B > on OpenVMS and with OpenVMS security that I would tend to avoid H > implementing and using UWSS callouts and that I would strive to avoid G > using UWSS constructs where I can avoid it, and that I would seek to  < > avoid mixing trusted and untrusted code in the same image. > A >   I would tend to use, as I have indicated, a combination of a  J > pseudo-driver and an ACP, or communications a dedicated server process, B > and to protect and to secure the trusted code behind the memory  > management protections.  > G >   This is basically the same design model as used by Mach, of course.  > F >   I've not preferred the UWSS image constructs, bluntly, and I have I > certainly encountered my share of problems with my uses (and sometimes  5 > with my deliberate misuses) of these constructions.  > J >   I don't believe that I could manage to mix trusted UWSS code and code K > that was not expecting to be called with privileges entirely securely --  H > without performing a detailed examination of all code involved.  (And D > even then, there are considerations around any security exposures J > potentially introduced as underlying code is changed or upgraded.)  And H > the effort involved in the investigation and the on-going maintenance J > can potentially exceed the effort involved in creating a solution using ; > a Mach-like model.  Some of the attacks are quite subtle.  > G >   If you believe you can manage all this securely, that's your call.  - > "Have at," to quote the classic expression.  > J >   Security mistakes I or others might make in the base operating system J > are of a larger potential cost than those that can be introduced within G > a more isolated case of a specific LP or of a particular third-party  K > package.  All are obviously costly to some folks, of course.  But if I'm  J > working with a trusted caller (whether a user-mode application image or I > otherwise) in a restricted environment, then the whole UWSS design and  J > the whole discussion of trust is moot.  This risk aversion is a central K > reason why I tend to (try to) be conservative with my offical and formal  J > recommendations, of course.  And why I don't mind writing "have at", at H > least once I've indicated that there might be or (if I can reasonably , > provide it) where there might be problems. > D >   I also need to complete some code that I've promised to certain I > customers (and one or two read the newsgroups) this week, and the work  K > done that my management has asked me for.  (And I also wish to set aside  K > a few hours in the evening and on the weekends to conduct what I like to  8 > delude myself into calling "my life".  But I digress.) > Q One simple question would be to ask what $getuai is doing. Without looking (it's  L been awhile since I looked at such), it would seem to need to get a look at M sysuaf.dat since that's where user auth info lives. Running in outer mode but P with privs turned on so it can get away with it, question is whether the $getuaiO code has enough checking in it to make very very sure it can only read the real P sysuaf.dat and not something else, for starters. For that matter, if the $getuaiL service should be firing up authorize.exe, what if something tricks it into # firing up some other image instead?   N    I suspect this is somewhere within a country mile of where Steve is worriedP although it would be unsurprising if these guesses cannot in fact be done in theP case at hand. When you're trying to protect resources though, the less cruft andL layering between the defining code for the resource and your protection, theM easier it is to convince yourself (correctly) that you're protecting what you  think.  P There's been a fair amount of experience with what happens when programs get runN with more privs than they are expecting and get tricked. (In comp.os.vms this P will be understood. I would not expect understanding of such in very many other  groups.)   Glenn Everhart   ------------------------------   Date: 8 May 2006 19:15:02 GMT ( From: bill@cs.uofs.edu (Bill Gunshannon)$ Subject: Re: Linux kernel defective!, Message-ID: <4c9jlmF14logaU1@individual.net>  B In article <1147107512.704454.85670@e56g2000cwe.googlegroups.com>, 	bob@instantwhip.com writes:+ > http://www.theinquirer.net/?article=31543    F Well, I read it.  I didn't see anything of any substance in the entireG article.  Kind of like your usual meaningless ramblings. But I digress. E Linux being junk is nothing new.  Lot's of people have been saying it J since the beginning.  The lesson that needs to be learned by VMS's keepersI is that while you can't make a silk purse out of a sow's ear, with enough D hype you can still sell it as one.  Think what the kind of hype that0 linux gets would do for a real product like VMS.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Mon, 08 May 2006 21:01:14 -0400 # From: DrSlinky <drslinky@gmail.com> B Subject: Re: Looking for power supply/supplies for DS20e in Europe' Message-ID: <kRR7g.388$Lo.374@fe12.lga>    Marc Schlensog wrote: @ > I recently got a DS20e for free, which has one defective powerH > supply/unit/module (whatchamacallit), thus the system shuts down afterG > a couple of minutes. Is there anyone in Europe who is able to help me I > out with one or two supplies? Additionally, if anyone is having a spare F > 667MHz CPU which isn't needed anymore, I'd be very interested in it.A > David: as much as I like what you do to keep up the supply with H > relatively cheap alpha hardware, you're unfortunately still way beyond > what I can afford. Sorry.  >  > TIA & regards, >  > Marc  G I don't have an extra, seeing as I only bought the one.  But there's a  @ seller on eBay selling the 667 21264 for $20 US.  Not sure what   international shipping would be.  ; Seller's name is "dynamic-components" if you're interested.    ------------------------------  * Date: Mon, 8 May 2006 21:52:02 +0000 (UTC)1 From: legalize+jeeves@mail.xmission.com (Richard) 2 Subject: Re: Mac OS X no longer immune to viruses!, Message-ID: <e3oei2$jve$2@news.xmission.com>  / [Please do not mail me a copy of your followup]   N andekl_no@saaf_spam.se (=?ISO-8859-1?Q?Anders_Ekl=F6f?=) spake the secret code7 <1hexbch.q5z0ff1pdguzfN%andekl_no@saaf_spam.se> thusly:   3 >Richard <legalize+jeeves@mail.xmission.com> wrote:  > 2 >> [Please do not mail me a copy of your followup] >>  B >> Paul Sture <paul.sture.nospam@hispeed.ch> spake the secret code9 >> <6a6ac$445b5d77$50db5015$8098@news.hispeed.ch> thusly:  >>  B >> >I'll second Rob Brown's request to Richard for details of the  >> >precautions he took. >>   >> Windows Update  >> Don't read email on a PC ' >> Disable "Windows Messenger" service.  >  >and:  > 0 >Don't leave the administrator password empty..." >Don't visit casino or porn sites.  - The other ones that you can/should adopt are: "     - don't login as administratorE     - disable active content in the "internet" zone if you're browing      less reputable web sites     -or-4     - use some relatively obscure browser like Opera  F >After earlier having questioned your credibility on the matter - yes,E >that's basically it. But the second line raised my eyebrows - do you 0 >read your mail on a Mac ? That's cheating. :-)    No, I don't own a Mac. --  E "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: 3           <http://www.xmission.com/~legalize/book/> ( 	    Pilgrimage: Utah's annual demoparty,                <http://pilgrimage.scene.org>   ------------------------------  * Date: Mon, 8 May 2006 21:54:52 +0000 (UTC)1 From: legalize+jeeves@mail.xmission.com (Richard) 2 Subject: Re: Mac OS X no longer immune to viruses!, Message-ID: <e3oenc$jve$4@news.xmission.com>  / [Please do not mail me a copy of your followup]   2 GreyCloud <mist@cumulus.com> spake the secret code6 <6_-dnR8A1t_WZcbZnZ2dnUVZ_s-dnZ2d@bresnan.com> thusly:  6 >No, your claims are just too absurd to be believable.   Whatever dude.  @ You clearly are not interested in anything that doesn't fit your preconceived ideas.  --  E "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: 3           <http://www.xmission.com/~legalize/book/> ( 	    Pilgrimage: Utah's annual demoparty,                <http://pilgrimage.scene.org>   ------------------------------  * Date: Mon, 8 May 2006 21:49:52 +0000 (UTC)1 From: legalize+jeeves@mail.xmission.com (Richard) 2 Subject: Re: Mac OS X no longer immune to viruses!, Message-ID: <e3oee0$jve$1@news.xmission.com>  / [Please do not mail me a copy of your followup]   2 GreyCloud <mist@cumulus.com> spake the secret code6 <6_-dneIA1t-8asbZnZ2dnUVZ_s-dnZ2d@bresnan.com> thusly:   >Richard wrote: 2 >> [Please do not mail me a copy of your followup] >>  5 >> GreyCloud <mist@cumulus.com> spake the secret code 9 >> <gZudneDer_yQA8bZnZ2dnUVZ_t2dnZ2d@bresnan.com> thusly:  >>   >>  > >>>Let's just say that your claims border on the unbelievable. >>   >>  F >> The set of things that you're willing to believe doesn't change the >> set of things that are true.  > / >Which you haven't provided any real proof yet.   C What "proof" would you accept short of coming out to my machine and  auditing it yourself?   5 Can you prove to me that you're not just a VMS troll?   
 >Just claims.   = I could make a similar pointless retort to all of your posts.   F You're an adherent to some sort of religion, proof appears irrelevant. --  E "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: 3           <http://www.xmission.com/~legalize/book/> ( 	    Pilgrimage: Utah's annual demoparty,                <http://pilgrimage.scene.org>   ------------------------------  * Date: Mon, 8 May 2006 21:53:18 +0000 (UTC)1 From: legalize+jeeves@mail.xmission.com (Richard) 2 Subject: Re: Mac OS X no longer immune to viruses!, Message-ID: <e3oeke$jve$3@news.xmission.com>  / [Please do not mail me a copy of your followup]   2 GreyCloud <mist@cumulus.com> spake the secret code6 <6_-dnRwA1t9WasbZnZ2dnUVZ_s-dnZ2d@bresnan.com> thusly:  - >[...]  But I'm sure that the Geek squad can  6 >tell you some very interesting stories that are true.  >Otherwise, they wouldn't exist.   Ah, now I see your reasoning.   F You'll believe any story that amounts to Windows/MS bashing, but won't believe any story that doesn't.   7 That's not called an open mind, that's called religion.  --  E "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: 3           <http://www.xmission.com/~legalize/book/> ( 	    Pilgrimage: Utah's annual demoparty,                <http://pilgrimage.scene.org>   ------------------------------  % Date: Mon, 08 May 2006 17:05:16 -0600 " From: GreyCloud <mist@cumulus.com>2 Subject: Re: Mac OS X no longer immune to viruses!: Message-ID: <ocudnR9tp5ssU8LZnZ2dnUVZ_sCdnZ2d@bresnan.com>   Richard wrote:  1 > [Please do not mail me a copy of your followup]  > 4 > GreyCloud <mist@cumulus.com> spake the secret code8 > <6_-dneIA1t-8asbZnZ2dnUVZ_s-dnZ2d@bresnan.com> thusly: >  >  >>Richard wrote: >>2 >>>[Please do not mail me a copy of your followup] >>> 5 >>>GreyCloud <mist@cumulus.com> spake the secret code 9 >>><gZudneDer_yQA8bZnZ2dnUVZ_t2dnZ2d@bresnan.com> thusly:  >>>  >>>  >>> ? >>>>Let's just say that your claims border on the unbelievable.  >>>  >>> F >>>The set of things that you're willing to believe doesn't change the >>>set of things that are true.  >>0 >>Which you haven't provided any real proof yet. >  > E > What "proof" would you accept short of coming out to my machine and  > auditing it yourself?  > 7 > Can you prove to me that you're not just a VMS troll?  >  >  >>Just claims. >  > ? > I could make a similar pointless retort to all of your posts.  > H > You're an adherent to some sort of religion, proof appears irrelevant.  H It's a little obvious that the majority of people wouldn't believe your C claims.  Too many *have* caught viruses and other malware on their  I windows PCs.  You do use email don't you?  You haved used IE in the past  @ haven't you?  Even M$ knows that their PCs get viruses and they F themselves have had problems on the inside.  When they tried to allow G people to download SP2 for XP the end user even got an infected during  C the download.  It has been in the news over the last few years, so  J claiming that you don't need a virus scanner for your PC is a bit dubious.     --   Where are we going?   And why am I in this handbasket?   ------------------------------   Date: 8 May 2006 18:35:21 GMT ( From: bill@cs.uofs.edu (Bill Gunshannon)6 Subject: Re: OT: Intels quickens cadence for new 8086s, Message-ID: <4c9hb9F14482iU1@individual.net>  , In article <ZbKeUJdCVNa6@malvm9.mala.bc.ca>,4 	nothome@spammers.are.scum (Malcolm Dunnett) writes:/ > In article <4c16u0F13nb5vU1@individual.net>,  0 >     bill@cs.uofs.edu (Bill Gunshannon) writes: >>  J >> And that is a matter of opinion.  While I like VMS, from the standpointL >> of student use Unix always wins in ease of use available (out of the box)K >> functionality. Argue it if you want, but I run both Unix and VMS systems   >> and get to see it first hand. > E >     Can you elaborate on this point? We taught first/second year CS D > courses on VMS for many years and ease of use was never an issue.   G So did we.  Until Unix showed up and suddenly, no one wanted to use VMS J any more.  And, I am not talking about just CS students here.  CS studentsH automagically got Unix accounts on the department machines.  We got lotsJ of requests from students and even faculty in other departments who wantedH Unix accounts rather than continue using VMS which had been the academic$ machine since before I eve got here.  I >                                                                    What K > Unix features do you believe make it significantly easier for a computing  > neophyte to grasp?  H Couldn't say.  I learned Unix from the online docs and from the originalI tech papers that used to come bundled with Unix systems form the Ritchie- I Kernigan-Thompson days.  My daughter learned how to use Unix when she was I about 6, with no real instruction at all. Just by playing around with it. 8 She has a version if Rogue for her PC to this day!!  :-)   > - >> And, as another data point, back when PC's G >> were still rather rare, the university had a VMS machine for general J >> academic use.  We were the only department on campus with Unix systems.I >> We were constantly flooded with requests for accounts from students an < >> faculty who found the VMS system to not meet their needs. > . >    In what way did it not meet their needs?    I have no way of knowing.   F >                                             I suspect it was becauseF > they wanted to run software someone else had written for Unix and it( > wouldn't run "out of the box" on VMS.   G Cute assumption, but with no basis in fact.  Non-CS Faculty tend to not I play with computers, just use them to get their work done.  I assume that F would mean they found it easier to do email, write papers, keep gradesD ande whatever else.  But, I really have no way of knowing because weL didn't ask.  If they were faculty or staff we usually granted their request.I If they were students, we usually turned them down.  We have had students H who actually took classes in the CS area as electives because it was theH easiest way to get an account.  And somehow I can't see all these non-CS( students sitting around playing NetHack.  G >                                       To me though this is more of an M > effect than a cause - had DEC been better about getting VMS into widespread I > use in universities ( and keeping it there ) back in the early 80s that K > might not have been such an issue - the software they wanted to run would H > have been written for VMS, not Unix, and the situation would have been > reversed.   K Ummmm......   Actually, they did.  When I was at West Point, while the Dean F had a research lab that had Unix (SYSV) and made use of these machinesG available, the CS (actually, G&CS) departmen had a VAX running VMS.  It K did have Eunice, but anyone who has ever used that knows what a dog it was.   H You are, to a certain extent, right about the software thign, though.  IE remember an RFP I once worked on the response to where my company was J bidding Primes and DEC was bidding an, as yet imaginary, VAX.  We withdrewH when it became obvious the RFP was a sham and they were going to buy theI VAX no matter what the results of the Proposals were.  After the fact, we H learned that what they got was a VAX running VMS and the original intentJ driving the desire to have a VAX was to run software from Kitt Peak Obser-I vatory.  The software was for BSD Unix.  :-)  Just another example of how 5 "Be careful what you ask for, you just might get it!"    > H >    I saw this happen myself at the time. In the early 80s many of the G > colleges around here used VMS in their CS courses. However the advent J > of relatively cheap systems from other vendors ( primarily Sun ) quicklyF > eroded this market. DEC refused to compete effectively against theseL > offerings with cheap VAXen (I had DEC reps at the time tell me they didn'tR > care what Sun did, they saw IBM customers as the market they wanted to go after)  F Even after we put in whole labs of Unix Workstations with Unix ServersH backing them up we continued to use VMS, in particular for the first twoG CS Programming Courses.  But it rapidly became a matter of the students I using VMS for those things they had to use VMS for while doing everything L they could on the Unix Workstations.  I still run VMS here in the departmentI and we have at least one course that still requires that the students use L it. (This also helps with our accreditation which requires that the studentsE at least be exposed to more than one OS.)  Even with DECWindows being H available so they can point-and-click to their hearts content they still9 prefer Unix.  Can't tell you why, I am not a sociologist.    > O >    It's not that there wasn't competetive VAX hardware - a $30,000 VAXStation J > could easily handle many multi-user workloads ( and was priced similarlyH > to a Sun workstation at the time ), but DEC wouldn't sell a multi-userG > VMS license for it ( Sun had multi-user licenses on their boxes ) and E > instead wanted you to buy a "VAXServer" offering which had the same 6 > CPU and memory capacity but cost well over $100,000.  I But all you keep saying is that the schools stopped making VMS available. F Not true here.  Other than the VMS system I run in the department, theF University still has a genereal purpose academic VMS machine.  It seesF very little use and at the rate things are going I suspect it will not8 be long before they drop it as not being worth the cost.   > B >    When we stopped teaching on VMS it had nothing to do with theJ > faculty or students disliking it or feeling Unix was inherently a betterL > teaching environment - it was simply an acknowledgement that the world hadI > moved that way and the students would be better served by being exposed ) > to the "industry standard" environment.   G But we still teach in VMS.  And still no one really wants to use it.  I J think there is much more to it than that.  If it was a matter of "industryG standard", the students wouldn't want to use Unix either, but they do!!     bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Tue, 09 May 2006 00:23:35 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 6 Subject: Re: OT: Intels quickens cadence for new 8086s9 Message-ID: <TZqdnVcEq_4Hhf3ZnZ2dnUVZ_uWdnZ2d@libcom.com>    Bill Gunshannon wrote:  H > Even after we put in whole labs of Unix Workstations with Unix ServersJ > backing them up we continued to use VMS, in particular for the first twoI > CS Programming Courses.  But it rapidly became a matter of the students K > using VMS for those things they had to use VMS for while doing everything N > they could on the Unix Workstations.  I still run VMS here in the departmentK > and we have at least one course that still requires that the students use N > it. (This also helps with our accreditation which requires that the studentsG > at least be exposed to more than one OS.)  Even with DECWindows being J > available so they can point-and-click to their hearts content they still; > prefer Unix.  Can't tell you why, I am not a sociologist.   F How about a survey, near the end of a course, trying to find out what  students like in Unix vs VMS?   I I can understand e-mail and browsing, but I'd think most use windows for   that.   B You're in a location and position to attempt to find out what the " students, and even faculty, think.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------   Date: 8 May 2006 14:11:00 -0700 ' From: "toby" <toby@telegraphics.com.au>  Subject: Poster defective!B Message-ID: <1147122660.410640.94270@i40g2000cwc.googlegroups.com>   bob@instantwhip.com wrote:+ > http://www.theinquirer.net/?article=31543    In other news:) COMP.OS.VMS NO LONGER IMMUNE FROM TROLLS!    ------------------------------   Date: 8 May 2006 11:12:02 -0700 1 From: nothome@spammers.are.scum (Malcolm Dunnett) % Subject: Re: SGI files for chapter 11 , Message-ID: <UOfpUzD8BMs5@malvm9.mala.bc.ca>  D In article <1147108136.879764.277650@j73g2000cwa.googlegroups.com>, 1   "Andrew" <andrew_harrison@symantec.com> writes:  > E > Sun/IBM/The tooth Fairy are not going to buy OpenVMS and port it to  > anything.  > + > HP are highly unlikely to port it to x86.  >      How do you know that?   A   Presumably they still believe (rightly or wrongly) that IA64 is J a better choice, but one has to believe that with each port to a different- processor the subsequent port becomes easier.   C   If there are sufficient customers who let HP know that VMS is the E only reason they are HP customers and if IA64 proves to not be viable G then porting VMS to x86 would be a good business decision. I have every A confidence the good folks in VMS engineering would have no great  $ difficulty doing this port if asked.   > G > The only thing that matters is that OpenVMS needs IA-64 to suceed and  > make HP and Intel very happy.  >   D    No, what OpenVMS needs is customers who see value in it that theyI can't get elsewhere. The processor it runs on is just a technical detail.   D   Of course that does suggest that if they're going to pull the plug# on IA64 then the sooner the better.    ------------------------------  % Date: Mon, 08 May 2006 15:03:48 -0400 ( From: Bill Todd <billtodd@metrocast.net>% Subject: Re: SGI files for chapter 11 = Message-ID: <du2dnc-yVpFyCMLZRVn-og@metrocastcablevision.com>    Malcolm Dunnett wrote:F > In article <1147108136.879764.277650@j73g2000cwa.googlegroups.com>, 3 >   "Andrew" <andrew_harrison@symantec.com> writes: F >> Sun/IBM/The tooth Fairy are not going to buy OpenVMS and port it to >> anything. >>, >> HP are highly unlikely to port it to x86. >> >  >   How do you know that?   D A valid question:  it can't be known with any certainty outside the ! higher echelons of HP management.   9 But it certainly can be suspected, based on the evidence:   E 1.  VMS sales took a devastating dive after the Alphacide from which  C they have never recovered (it may in fact still be continuing at a  E slower pace, given the degree to which VMS revenues are dominated by  H service revenues from *existing* installations rather than by new-sales G figures).  VMS may have been seen as worth porting five years ago back  F when some of these defections were viewed as potentially recoverable, > but could easily not be seen as worth porting now (especially G considering that platforms supporting it will continue to be available  = for years yet even if all active development of them ceases).   H 2.  To all appearances the port of VMS to Itanic was funded at least in E significant part by the Intel Alphacide deal - something which Intel  5 does not seem very likely to repeat for another port.   G 3.  HP likely viewed the VMS port as in part worthwhile in its visible  B support for Itanic (it's certainly devoted more visible effort to G publicizing this in its Itanic promotions than it has to promoting VMS  ; per se).  x86 needs no comparable demonstration of support.    > C >   Presumably they still believe (rightly or wrongly) that IA64 is  > a better choice   G A questionable presumption at best.  HP may well view Itanic as a more  G desirable choice from their *own* viewpoint (to the degree that Itanic  H needs all the help it can get to survive), but any objective evaluation F of the desirability of potential VMS port target platforms made today H would hardly place Itanic at the head of the list if it weren't already 
 supported.   - bill   ------------------------------  % Date: Mon, 08 May 2006 17:37:03 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> % Subject: Re: SGI files for chapter 11 , Message-ID: <445FB9EF.BAD3536C@teksavvy.com>   Malcolm Dunnett wrote:C >   Presumably they still believe (rightly or wrongly) that IA64 is  > a better choice,    D I am not convinced of that. Back in February 2004, both Intel and HPH started to make statements that opened the door to the end of IA64 to beH replacved by the 8086. HP head would have read the IDG study that showedE a very significant decrease of customer based due to the migration to E that IA64. And they know that decision to restrict that IA64 thing to D the high end only basically sealed that chip's fate because it wouldG never achieve the volumes necessary to justified continued spending for 
 its upgrades.   E Killing a chip takes time. They shifted resources to the 8086 and now F you have more and more delays in IA64. (not only in actual delays, but/ also shifting features to subsequent releases).     B > confidence the good folks in VMS engineering would have no great& > difficulty doing this port if asked.  A Same here. However, I am not sure that I have confidence that VMS D management has the guts to fight HP management to get the funding to port to the 8086.   D VMS management and engineers have been so excellent at toeing the HPD corporate line and supporting that IA64 thing that I am wondering ifG they haven't begun to actually believe what they say. Hopefully not and  they can still see the reality.   F >    No, what OpenVMS needs is customers who see value in it that theyK > can't get elsewhere. The processor it runs on is just a technical detail.   G It is much more than a technical detail. Customers want to see VMS on a C platform whose future is not constantly being questioned. If you're D going to drop the best of the best (Alpha) to go to a commoditychip,E then you really need to go to a commodity chip and not buy some other F proprietary chip with inferior performance and a future just as dismal as that of alpha.    ------------------------------  % Date: Mon, 08 May 2006 17:42:02 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> % Subject: Re: SGI files for chapter 11 , Message-ID: <445FBB19.C8B3C0A0@teksavvy.com>   Malcolm Dunnett wrote:H >    Will SGI going into Chapter 11 be the death of VMS, as Andrew would > have us believe?    E It depends on how the media treats this. If they blame IA64 for SGI's = problems, then IA64's image might be mortally wounded. And HP G shareholders might demand some explanations from Hurd on why HP insists H on continuing with thie deadweight that studies show it will cause large loss of customers.   ------------------------------  % Date: Mon, 08 May 2006 17:06:48 -0500 % From: Dan Foster <usenet@evilphb.org> % Subject: Re: SGI files for chapter 11 5 Message-ID: <slrne5vg7o.3uh.usenet@zappy.catbert.org>   < In article <4c9mm2F14tvo9U1@individual.net>, Bill Gunshannon <bill@cs.uofs.edu> wrote:  > G >> I have every confidence the good folks in VMS engineering would have 0 >> no great difficulty doing this port if asked. > F > While I have no doubt that the VMS engineers are a rather remarkableD > collection of Computer Scientists, I would not go so far as to sayH > they "would have no great difficulty" doing the port.  For a long timeG > people ran around saying VMS would not run on x86.  If that was true, 6 > not enough has changed to actually make a port easy.  6 Well, x86 has grown up a bit since Project Emerald. :)  G For instance, 64-bit x86 these days has 16 64-bit GPRs (general purpose E registers), at least 16 SIMD registers (a mixture of 64 and 128-bit), B and some additional registers that aren't either GPRs or for SIMD.   In comparison:  E VAX had 12 32-bit GPRs (encompassing both integer and floating point)  and no SIMD.  B Alpha had 32 64-bit integer registers and 32 64-bit floating pointB registers. It also had SIMD starting with PCA56 (and for EV class, starting with EV6).   D IA-64 has 128 82-bit floating point registers and 128 64-bit integer3 registers. I'm not sure about SIMD status, offhand.   = Clearly, even modern x86 falls short of both Alpha and IA-64.   E HP also has experience in doing special magic tricks in the compilers C and back-ends to remap or insert synthetic code to take place of an E actual physical register (at expense of some performance). Mr. Reagan 9 wrote about some of these in a past HP Technical Journal.   E While x86-64 is clearly better than the VAX for the registers, it may ) not be sufficiently significantly better.   H I bet it *could* be made to work on x86 if given sufficient interest and4 money, but would guess it'd still be rather painful.   -Dan   ------------------------------  % Date: Mon, 08 May 2006 17:00:47 -0600 " From: GreyCloud <mist@cumulus.com>% Subject: Re: SGI files for chapter 11 0 Message-ID: <mpWdnSka3eQ-UMLZ4p2dnA@bresnan.com>   JF Mezei wrote:  > Malcolm Dunnett wrote: > H >>   Will SGI going into Chapter 11 be the death of VMS, as Andrew would >>have us believe?   >  > G > It depends on how the media treats this. If they blame IA64 for SGI's ? > problems, then IA64's image might be mortally wounded. And HP I > shareholders might demand some explanations from Hurd on why HP insists J > on continuing with thie deadweight that studies show it will cause large > loss of customers.  I I'd think that one of SGIs major problems has to do with MIPS processors  @ not advancing fast enough.  Their processor only runs at 800Mhz.   --   Where are we going?   And why am I in this handbasket?   ------------------------------  % Date: Mon, 08 May 2006 20:43:45 -0400 ( From: Bill Todd <billtodd@metrocast.net>% Subject: Re: SGI files for chapter 11 G Message-ID: <mNKdnYLOKNYKeMLZnZ2dnUVZ_vadnZ2d@metrocastcablevision.com>    Dan Foster wrote:    ...   G > While x86-64 is clearly better than the VAX for the registers, it may + > not be sufficiently significantly better.   F I'll suggest that it need not be any better at all.  16 registers are B more than sufficient for common register-use patterns, and in the F less-common cases where they are not sufficient to eliminate the need ? for re-use the cost of moving register contents back and forth  G occasionally to a fast L1 D cache is hardly a show-stopper (especially  $ when executing on an OoO processor).   > J > I bet it *could* be made to work on x86 if given sufficient interest and6 > money, but would guess it'd still be rather painful.  I Perhaps for code written in assembler; otherwise, compilers take care of  I the problem (and even Bliss has an x86 compiler already, IIRC - just not  : one that HP was willing to support externally for Oracle).   - bill   ------------------------------  % Date: Mon, 08 May 2006 18:47:32 -0700 # From: "Tom Linden" <tom@kednos.com> % Subject: Re: SGI files for chapter 11 ) Message-ID: <op.s89glitdzgicya@hyrrokkin>   H On Mon, 08 May 2006 17:43:45 -0700, Bill Todd <billtodd@metrocast.net>   wrote:   > Dan Foster wrote:  >  > ...  > H >> While x86-64 is clearly better than the VAX for the registers, it may, >> not be sufficiently significantly better. > I > I'll suggest that it need not be any better at all.  16 registers are   E > more than sufficient for common register-use patterns, and in the   I > less-common cases where they are not sufficient to eliminate the need   B > for re-use the cost of moving register contents back and forth  J > occasionally to a fast L1 D cache is hardly a show-stopper (especially  & > when executing on an OoO processor).  J For coloring algorithms 16 is a good number.  If you have a large number   of registersH a good strategy is to organize them into context sets as the Nord-10 did0 (35 years ago) corresponding to priority levels.   > J >>  I bet it *could* be made to work on x86 if given sufficient interest   >> and7 >> money, but would guess it'd still be rather painful.  > L > Perhaps for code written in assembler; otherwise, compilers take care of  L > the problem (and even Bliss has an x86 compiler already, IIRC - just not  < > one that HP was willing to support externally for Oracle). >  > - bill   ------------------------------  % Date: Mon, 08 May 2006 22:18:59 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> % Subject: Re: SGI files for chapter 11 , Message-ID: <445FFC03.6187B046@teksavvy.com>   Bill Todd wrote:H > I'm sorry to see SGI sink (even given the possibility that it may rise9 > again):  it was a victim of Itanic, not a perpetrator.    E Note that chapter 11 in the USA is more of a change of ownership than E actual bankrupcy. Creditors generally swap debt for equity and become 0 the new majority (or full) owner of the company.  G For this to happen, SGI must prove to their creditors that they do have H a plan to become profitable again. Under the new laws now in effect, SGIH has 18 months to present a reorganisation plan that satisfied creditors,P ortherwise the creditors become 100% owners with 100% control and can liquidate.    G This chapter 11 appears to be more a question of paperwork/process than C a real bankrupcy. They've already begun to reorganise and make deep E cuts. And such a company doesn't really have lots of assets. The real : assets are the employees. And it is hard to monetise this.  G What will be interesting is whether Intel decides to use some of its 10 H billion Itanic survival fund to  help recapitalise SGI.  If HP agrees toG this, it would mean that HP is truly desperate to prevent the immediate  sinking of that IA64 thing.   E If Intel decides not to invest in SGI to help it out of bankrupcy, it . probably means that SGI is moving to the 8086.   ------------------------------  % Date: Mon, 08 May 2006 22:44:23 -0400 ( From: Bill Todd <billtodd@metrocast.net>% Subject: Re: SGI files for chapter 11 G Message-ID: <SqOdnVPN8chAnP3ZnZ2dnUVZ_tGdnZ2d@metrocastcablevision.com>    JF Mezei wrote:  > Bill Todd wrote:I >> I'm sorry to see SGI sink (even given the possibility that it may rise : >> again):  it was a victim of Itanic, not a perpetrator.  > G > Note that chapter 11 in the USA is more of a change of ownership than G > actual bankrupcy. Creditors generally swap debt for equity and become 2 > the new majority (or full) owner of the company.  I *Some* of the creditors are getting to swap (increased) debt for equity,  I but my impression is that others may simply be getting the shaft (unless  H the cash infusion from those who are supporting the reorg is being used C to settle all outstanding debt - which might be a good idea if the  E reconstituted entity wants to enjoy the confidence of its suppliers).    ...   I > This chapter 11 appears to be more a question of paperwork/process than  > a real bankrupcy.   E Chapter 11 (and Chapter 7) *define* bankruptcy in the U.S.:  it's as  H real as it gets.  Debts exceed assets to an extent that complete timely H repayment is considered impossible, so the court attempts to come to as F equitable an arrangement as possible (within the existing contractual E arrangements - e.g., some creditors are contractually preferred over   others).  F Chapter 11 filings significantly discourage investors and customers - A both of which SGI needs desperately.  Paradoxically, while SGI's  F traditional HPC customers might be less discouraged than average, the G commercial customers which it was rumored to be about to seek now need  ? the courage to embrace not only new commercial products but an  " increasingly shaky vendor as well.   ...   I > What will be interesting is whether Intel decides to use some of its 10 9 > billion Itanic survival fund to  help recapitalise SGI.   D Intel has no $10 billion 'Itanic survival fund'.  There *is* no $10 C billion Itanic survival fund:  it's merely the funds that existing  F Itanic vendors *already* planned to spend on their own Itanic-related F product development and marketing over the next 5 years (plus perhaps E the expenditures that Intel planned to make).  HP alone accounts for  I half that $10 billion, SGI likely accounted for a significant portion of  	 the rest.    ...   G > If Intel decides not to invest in SGI to help it out of bankrupcy, it 0 > probably means that SGI is moving to the 8086.  F Others have observed that a major investment by Intel in SGI could be H seen as putting it into competition with its other Itanic OEMs.  In any B event, HP needs Itanic more than Intel does:  if HP didn't try to L purchase SGI, that might be more an indication that *HP* is moving to x86...   - bill   ------------------------------  % Date: Mon, 08 May 2006 23:58:33 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> % Subject: Re: SGI files for chapter 11 , Message-ID: <44601354.B3354A56@teksavvy.com>   Bill Todd wrote:J > *Some* of the creditors are getting to swap (increased) debt for equity,  F Correct. Unsecured creditors generally get only pennies to the dollar,) depending on the extent of the bankrupcy.   > > Chapter 11 (and Chapter 7) *define* bankruptcy in the U.S.:   G Chapter 11 is actually protection from bankrupcy. It prevents creditors H from seizing assets of the company and allows the company to continue toG function more or less normally with a judge overseeing the negotiations H between creditors and management. Judge has the power to void contracts.A In the USA, Chapter 11 also gives current management 18 months of ? control over the company to find a suitable deal to emerge from H bankrupcy. (prior to last october, there was no time limit, which is howH United Airlines managed to stay in bankrupcy protection for many years).  A When/if the judge decides there is no credible plan to rescue the F company, he can suspend the protection from bankrupcty, at which point> the creditors can petition to have the company enter Chapter 7H (liquidation). Chapter 7 means end of operations, assets are seized etc.  F For airlines, the period of protection granted by a judge exceeds mostF reservations, so passengers have good confidence, when they book, thatD the airline will still be operating on the day of their flight.  ForG SGI, this is different because customers buy systems with expections of D support/upgrades for years to come. Lack of visibility on SGI's long* term future will cause some loss of sales.  G > Chapter 11 filings significantly discourage investors and customers -   F Customers, definitely. But it is actually an opportunity for investorsD to make lots of money. An investor that comes in now will be able toD dicate many terms/conditions, and will have a very high propotion ofD onwership because his existing shareholders will see their ownership reduced to near nill.   H When Continental was in chapter 11, Air Canada invested a fair amount ofF money and got enough control of Contijnental to change its management.H (AC's then chaimen was a former CO employee who hated the management whoG had fired him, so he was now in a postion to get them fired, and he got E GFordon Bethune (a friend) to the top job. A few years later, AC sold ) its shares in CO and made a hefty profit.   F Just recently, Air Canada participated in the emergence from bankrupcyH protection of US Air with a relatively small investment. In exchange, ACD got a seat on the US Air board, as well as a very lucrative contractA where US Air will pay AC for maintenance of US Air aircraft. That C contract alone is worth more than the investment AC made. And a few F weeks ago, AC sold its shares , again, at a nice profit, lost its seat7 on the US board, but retains the maintenance contracts.     E > Intel has no $10 billion 'Itanic survival fund'.  There *is* no $10 D > billion Itanic survival fund:  it's merely the funds that existingG > Itanic vendors *already* planned to spend on their own Itanic-related  > product development   H It is still money that could be used to help SGI "develop new software".  F Another possibility, and this one would be really "competitive" is AMDG stepping in and offering to invest in SGI in exchange for SGI switching 
 to AMD 8086s.   F This is quite an opportunity for AMD since getting SGI to convert from4 IA64 to Opterons would be a big high visibility win.    G > Others have observed that a major investment by Intel in SGI could be A > seen as putting it into competition with its other Itanic OEMs.   @ If that IA64 thing is in a terrible condition and HP needs it toF continue to stay afloat, then helping a competitor may in fact help HPE since it would help keep IA64 afloat. Hp could then help dictate some F conditions to ensure SGI stays in its niche amrket and doesn't compete against HP.    ------------------------------  % Date: Tue, 09 May 2006 00:31:55 -0400 ' From: Dave Froble <davef@tsoft-inc.com> % Subject: Re: SGI files for chapter 11 / Message-ID: <3pudnUbq26Uah_3ZRVn-gw@libcom.com>    Malcolm Dunnett wrote:F > In article <1147108136.879764.277650@j73g2000cwa.googlegroups.com>, 3 >   "Andrew" <andrew_harrison@symantec.com> writes: F >> Sun/IBM/The tooth Fairy are not going to buy OpenVMS and port it to >> anything. >>, >> HP are highly unlikely to port it to x86. >> >  >   How do you know that?  > C >   Presumably they still believe (rightly or wrongly) that IA64 is L > a better choice, but one has to believe that with each port to a different/ > processor the subsequent port becomes easier.  > E >   If there are sufficient customers who let HP know that VMS is the G > only reason they are HP customers and if IA64 proves to not be viable I > then porting VMS to x86 would be a good business decision. I have every C > confidence the good folks in VMS engineering would have no great  & > difficulty doing this port if asked.  H A company that makes an unpopular decision, knowing that they will lose H customers, isn't a company that customers can count upon.  I'm not sure ; that customer opinion will be sought, nor given any weight.   L People using VMS aren't the type that have at most a 3-month attention span.  H >> The only thing that matters is that OpenVMS needs IA-64 to suceed and  >> make HP and Intel very happy. >> > F >    No, what OpenVMS needs is customers who see value in it that theyK > can't get elsewhere. The processor it runs on is just a technical detail.  > F >   Of course that does suggest that if they're going to pull the plug% > on IA64 then the sooner the better.  >      --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Tue, 09 May 2006 00:40:28 -0400 ' From: Dave Froble <davef@tsoft-inc.com> % Subject: Re: SGI files for chapter 11 / Message-ID: <3pudnUHq26UYgf3ZRVn-gw@libcom.com>    Malcolm Dunnett wrote:  @ >    The only certainty is that if one chooses to believe FUD it% > becomes a self-fulfilling prophecy.   I How about that?  Something finally gets written in this newsgroup that's  , worth the bandwidth it takes to transmit it.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Tue, 09 May 2006 00:46:44 -0400 ' From: Dave Froble <davef@tsoft-inc.com> % Subject: Re: SGI files for chapter 11 / Message-ID: <bsidnWRUf-afg_3ZRVn-ig@libcom.com>    Bill Todd wrote: > GreyCloud wrote: >  > ...  > A >> I'd think that one of SGIs major problems has to do with MIPS  G >> processors not advancing fast enough.  Their processor only runs at  
 >> 800Mhz. > H > SGI has been shipping Itanic systems since McKinley (i.e., going on 4 J > years now) - and for a long time was the only platform on which Madison K > was able to beat EV7 in large-system SPECfp_rate performance (yet again,  D > Superdomes just couldn't cut the mustard there, despite Madison's I > crushing SPECfp superiority in small configurations).  SGI has usually  G > shipped more Itanics than anyone save HP, and has been show-cased as  B > proof of Itanic's performance potential (though they've avoided G > commercial benchmarks completely - something which was rumored to be  ! > changing, but now, who knows?).  > I > I'm sorry to see SGI sink (even given the possibility that it may rise  D > again):  it was a victim of Itanic, not a perpetrator.  A willing < > victim, to be sure, but it was looking for a way out of a A > processor-development business which (unlike Compaq) it really  F > *couldn't* afford, and committed to Itanic before anything like the J > extent of its disaster was at all visible (just storm clouds on the far J > horizon, with all of Intel's corporate presence offered as reassurance).  C There were worse decisions they could have made.  What if they had  E embraced Alpha, before it was killed?  A good technical decision.  A  3 killer business decision, SGI being the one killed.   A Not really any good possibilities for SGI in the timeframe being  I discussed.  x86 really wasn't a possibility until HAMMER started beating  2 on Intel.  Way after SGI made their CPU decisions.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Tue, 09 May 2006 00:54:35 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> % Subject: Re: SGI files for chapter 11 , Message-ID: <44602073.2805C698@teksavvy.com>   Dave Froble wrote:B > Not really any good possibilities for SGI in the timeframe beingJ > discussed.  x86 really wasn't a possibility until HAMMER started beating4 > on Intel.  Way after SGI made their CPU decisions.   Power was there.  E And if they did look at Alpha, they would have seen all the convicing D slides from Digital about how IA64 was a flawed architecture.It is aC fair bet that SGI's engineers also saw that IA64 was a bloated boat @ anchor. They may have been given a business deal with Intel theyO couldn't refuse, and they chose to embark on an inferior platform. Their fault.   G In the case of HP, HP embarked on the Itanic before  it was apparent it F would be a sinking ship. But it is responsible for staying on it after? it was apparent it just wouldn't work out as had been expected.    ------------------------------  % Date: Tue, 09 May 2006 01:00:56 -0400 ' From: Dave Froble <davef@tsoft-inc.com> % Subject: Re: SGI files for chapter 11 / Message-ID: <ZpWdnTzk74HOvP3ZRVn-rQ@libcom.com>    JF Mezei wrote:  > Malcolm Dunnett wrote:D >>   Presumably they still believe (rightly or wrongly) that IA64 is >> a better choice,  > F > I am not convinced of that. Back in February 2004, both Intel and HPJ > started to make statements that opened the door to the end of IA64 to beJ > replacved by the 8086. HP head would have read the IDG study that showedG > a very significant decrease of customer based due to the migration to G > that IA64. And they know that decision to restrict that IA64 thing to F > the high end only basically sealed that chip's fate because it wouldI > never achieve the volumes necessary to justified continued spending for  > its upgrades.  >  > Killing a chip takes time.  8 Ha!  Just how much of one day did it take to kill Alpha?  , > They shifted resources to the 8086 and nowH > you have more and more delays in IA64. (not only in actual delays, but1 > also shifting features to subsequent releases).  >  > C >> confidence the good folks in VMS engineering would have no great ' >> difficulty doing this port if asked.  > C > Same here. However, I am not sure that I have confidence that VMS F > management has the guts to fight HP management to get the funding to > port to the 8086.  > F > VMS management and engineers have been so excellent at toeing the HPF > corporate line and supporting that IA64 thing that I am wondering ifI > they haven't begun to actually believe what they say. Hopefully not and ! > they can still see the reality.  > G >>    No, what OpenVMS needs is customers who see value in it that they L >> can't get elsewhere. The processor it runs on is just a technical detail. > I > It is much more than a technical detail. Customers want to see VMS on a E > platform whose future is not constantly being questioned. If you're F > going to drop the best of the best (Alpha) to go to a commoditychip,G > then you really need to go to a commodity chip and not buy some other H > proprietary chip with inferior performance and a future just as dismal > as that of alpha.   G I'd say that the itanic has never enjoyed near the future of Alpha, if  G we look at each in the timeframe of when they were introduced.  I fear   that it never will.   G Then again, there was some mention in PC World (I think) about Tekewla  I (spelling), about on chip memory controllers and routers and such.  Four  H cores.  Good stuff from the Alpha people.  Unfortunately, it seems from I past news that the HP people got to impose their cores onto the project.  -   We've seen how well they hit their targets.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  * Date: Mon, 8 May 2006 22:17:51 +0000 (UTC)P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: TCPIP 5.4 anti-spam$ Message-ID: <e3og2f$oss$1@online.de>  F When is TCPIP.CONFIG read?  In particular, if changes are made, is it F enough to stop and restart SMTP, or does one need to stop and restart  TCPIP as well?   ------------------------------   Date: 8 May 2006 15:29:45 -0700 ( From: "Rich Jordan" <jordan@ccs4vms.com>  Subject: Re: TCPIP 5.4 anti-spamC Message-ID: <1147127385.799166.186240@g10g2000cwb.googlegroups.com>   F I've always seen it work by restarting only the SMTP service.  No need$ to restart the entire TCPIP product.   ------------------------------  % Date: Mon, 08 May 2006 19:46:32 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>   Subject: Re: TCPIP 5.4 anti-spam, Message-ID: <445FD851.F4311448@teksavvy.com>  / Phillip Helbig---remove CLOTHES to reply wrote:  > G > When is TCPIP.CONFIG read?  In particular, if changes are made, is it G > enough to stop and restart SMTP, or does one need to stop and restart  > TCPIP as well?   for the receiver:    TCPIP> DISABLE SERVICE SMTP  <sip some chocolate milk>  TCPIP> ENABLE SERVICE SMTP  B (this forces the kernel to load the most recent changes to the SET7 SERVICE commands). For instance, if you use SET SERVICE H SMTP/REJECT=NET=ip.address:ip.mask , that change won't take effect until# you DISABLE and ENABLE the service.    for the symbiont:    TCPIP> STOP MAIL <sip some chocolate milk>  TCPIP> START MAIL   E In terms of receiving messages, the SMTOP.CONFIG is actually read for D each incoming messages, so making changes to it sort of takes effectE when the next message comes in. But you can be sure of that with STOP  MAIL and START MAIL.   ------------------------------  % Date: Mon, 08 May 2006 21:57:47 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> Y Subject: Re: This post will self-destruct in 10secs (Was Re: X windows  vulnerability)  v , Message-ID: <445FF70C.E54E9801@teksavvy.com>   "Main, Kerry" wrote:J > Bottom line is that as I stated in earlier thread, no vendor plans their% > platform to be secure by obscurity.   * The lack of VMS exposure makes it obscure.  G The lack of HP press releases to confirm that VMS version of a software E does not suffer from a vulnerability just published leaves VMS out in E the dark, with customers wondering if there is somebody  left to even ' verify that VMS is or isn't vulnerable.   C In the case of the current BIND for VMS on VAX (Bind 8) there are a H number of vulnerabilities and HP hasn't issued any statements to confirmB or deny that they apply to VMS.  Is there anyone left at the TCPIP Services group ?   ------------------------------   Date: 8 May 2006 18:05:49 GMT ( From: bill@cs.uofs.edu (Bill Gunshannon)U Subject: Re: This post will self-destruct in 10secs (Was Re: X windows vulnerability) , Message-ID: <4c9fjtF133jb1U1@individual.net>  ? In article <DTiotGxQ0bj6-pn2-4TBdt6sdUP33@dave2_os2.home.ours>, 5 	"Dave Weatherall" <djw-nothere@nospam.nohow> writes: 3 > On Sun, 7 May 2006 22:57:29 UTC, "Richard Maher"  & > <maher_rj@hotspamnotmail.com> wrote: >  >> Hi, >>  A >> "Richard B. Gilbert" <rgilbert88@comcast.net> wrote in message - >> news:eKednSQX1NQGYcDZRVn-jA@comcast.com... G >> > Would you prefer that the details of each vulnerability and how to . >> > exploit it were published on comp.os.vms? >>  N >> I would prefer the details of each vulnerability and how to protect againstL >> it. (Obviously I'd prefer it if there were no vulnerabilities at all, but! >> hey it's not a perfect world.)  >>  ? >> > IF you can't find out, the crackers probably can't either.  >>  N >> That's the spirit! Why didn't Homeland Security think of that and just saveO >> 1.25 million? I'll think you'll find that the hackers out there are probably O >> far more dedicated to the cause and certainly have more resources than lowly  >> moi.  >>  I >> > If you could find out, do you have the resources to fix the problem?  >>  O >> If it was in my code yes. I do concede your point about the timing window of M >> opportunity but we are talking about prevention here aren't we? Or are we?  >>  M >> > Not being part of the "in group" may sting but limiting the distribution E >> >   of the details seems to have worked quite well over the years.  >>  J >> You're right! Just look at what maintaining the clique has done for VMSL >> growth over the years. We're kickin' arse! When there are no customers atN >> all then there will be absolutely zero vulnerabilities. Excellent strategy! >>  O >> Anyway, I'm off to the office to burn that Bin Laden bible "The Guide to VMS I >> Security". What the hell were they thinking when they brought out that ' >> little How-to-Hack guide? The fools!  > E > One possible _good_ reason for just keeping it tight and not 'just  E > fixing' it is perhaps that the elapsed time window for unsupported  H > (i.e. out-of support) versions of VMS could actually be quite long... H > Presumably, users of such versions would prefer the details kept quiet# > if there is no defense available.   D And this is what brought up the whole "Security by Obscurity" issue.C That is precisely what you are advocating.  The bad news is the bad C guys have very good/fast/active channels for exchanging information B on the latest exploit.  Keeping it quiet is very likely to ensure D that potential victims are unaware while having little if any effect* on how many of the bad guys know about it.  D It also feeds the idea that there actually are known problems in VMSF but that the powers that be choose to just not tell anyone about them.   bill      --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 8 May 2006 14:59:20 -0700 ' From: "toby" <toby@telegraphics.com.au> U Subject: Re: This post will self-destruct in 10secs (Was Re: X windows vulnerability) C Message-ID: <1147125560.237121.247790@e56g2000cwe.googlegroups.com>    Richard B. Gilbert wrote:  > Richard Maher wrote: >  > > Hi,  > > 7 > > (Listen very carefully! I shall say siss only once)  > > ...  > >  > > Regards Richard Maher  > >  > <snip> > D > Would you prefer that the details of each vulnerability and how to+ > exploit it were published on comp.os.vms?  > < > IF you can't find out, the crackers probably can't either.  B 1) If that were true, there would be no computer security problem.   > F > If you could find out, do you have the resources to fix the problem?  1 2) Only where open source products are concerned.   A 1) and 2) encapsulate what we have learned in the last 20+ years.      > J > Not being part of the "in group" may sting but limiting the distributionB >   of the details seems to have worked quite well over the years.  ) It seems to work wonderfully well for MS.    ------------------------------  $ Date: Mon, 8 May 2006 20:56:44 -0400' From: "Main, Kerry" <Kerry.Main@hp.com> U Subject: RE: This post will self-destruct in 10secs (Was Re: X windows vulnerability) T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B8684013AC8B3@tayexc19.americas.cpqcorp.net>   > -----Original Message-----$ > From: bill@triangle.cs.uofs.edu=20A > [mailto:bill@triangle.cs.uofs.edu] On Behalf Of Bill Gunshannon  > Sent: May 8, 2006 2:06 PM  > To: Info-VAX@Mvb.Saic.Com A > Subject: Re: This post will self-destruct in 10secs (Was Re:=20  > X windows vulnerability) >=20A > In article <DTiotGxQ0bj6-pn2-4TBdt6sdUP33@dave2_os2.home.ours>, 7 > 	"Dave Weatherall" <djw-nothere@nospam.nohow> writes: 7 > > On Sun, 7 May 2006 22:57:29 UTC, "Richard Maher"=20 ( > > <maher_rj@hotspamnotmail.com> wrote: > >=20 > >> Hi, > >>=20 C > >> "Richard B. Gilbert" <rgilbert88@comcast.net> wrote in message / > >> news:eKednSQX1NQGYcDZRVn-jA@comcast.com... A > >> > Would you prefer that the details of each vulnerability=20  > and how to0 > >> > exploit it were published on comp.os.vms? > >>=20 @ > >> I would prefer the details of each vulnerability and how=20 > to protect against5 > >> it. (Obviously I'd prefer it if there were no=20  > vulnerabilities at all, but # > >> hey it's not a perfect world.)  > >>=20 A > >> > IF you can't find out, the crackers probably can't either.  > >>=20 @ > >> That's the spirit! Why didn't Homeland Security think of=20 > that and just saveA > >> 1.25 million? I'll think you'll find that the hackers out=20  > there are probably? > >> far more dedicated to the cause and certainly have more=20  > resources than lowly	 > >> moi.  > >>=20 A > >> > If you could find out, do you have the resources to fix=20  > the problem? > >>=20 ? > >> If it was in my code yes. I do concede your point about=20  > the timing window of< > >> opportunity but we are talking about prevention here=20 > aren't we? Or are we?  > >>=20 A > >> > Not being part of the "in group" may sting but limiting=20  > the distributionG > >> >   of the details seems to have worked quite well over the years.  > >>=20 B > >> You're right! Just look at what maintaining the clique has=20 > done for VMSA > >> growth over the years. We're kickin' arse! When there are=20  > no customers at ? > >> all then there will be absolutely zero vulnerabilities.=20  > Excellent strategy!  > >>=20 B > >> Anyway, I'm off to the office to burn that Bin Laden bible=20 > "The Guide to VMS = > >> Security". What the hell were they thinking when they=20  > brought out that) > >> little How-to-Hack guide? The fools!  > >=20I > > One possible _good_ reason for just keeping it tight and not 'just=20 I > > fixing' it is perhaps that the elapsed time window for unsupported=20 > > > (i.e. out-of support) versions of VMS could actually be=20 > quite long...=20B > > Presumably, users of such versions would prefer the details=20 > kept quiet% > > if there is no defense available.  >=20F > And this is what brought up the whole "Security by Obscurity" issue.E > That is precisely what you are advocating.  The bad news is the bad E > guys have very good/fast/active channels for exchanging information F > on the latest exploit.  Keeping it quiet is very likely to ensure=20F > that potential victims are unaware while having little if any effect, > on how many of the bad guys know about it. >=20F > It also feeds the idea that there actually are known problems in VMSH > but that the powers that be choose to just not tell anyone about them. >=20  H Bottom line is that as I stated in earlier thread, no vendor plans theirD platform to be secure by obscurity. And while there are no platformsD that can state they are 100% secure, similar to the bigger banks andH casino's, there are some platforms which by nature of their basic designI means a much more sophisticated attack is required to break into them.=20   H OpenVMS is like the bigger banks/casino's. Windows/Linux/others are likeF the corner store/liquor store where they get hit more often because itG is simply easier. Hackers thrive on successful hacks and so they attack  the simpler targets.  H Those who state OpenVMS is secure primarily because it does not have theA same volume as Windows/Linux/ others typically do not have a full . understanding of the basic design differences.  F It is like stating the casino's and bigger get broken into less simplyE because there are fewer of them than corner stores and liquor stores.    Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------   Date: 8 May 2006 19:03:45 -0700 ) From: "Sue" <susan_skonetski@hotmail.com> ( Subject: Updated VMS information May 7thC Message-ID: <1147140225.499643.251610@j73g2000cwa.googlegroups.com>    Dear Distribution Lists,  G Please find attached the latest updated VMS information, this is a long < one with much information which I know you will find useful.  
 Warm Regards,  Sue      Contents  , 1.0 Time Sensitive (recommend you read this) 2.0 From HP  	2.1 New OpenVMS Roadmaps 8 	2.2 Upcoming changes to Daylight Saving Time in the U.S 	2.3 New OpenVMS White Papers # 		2.3.1 HP Superdome Hybrid Servers A 		2.3.2 Business practices for HP OpenVMS on HP Integrity servers F  		2.3.3 Integrating HP Integrity servers into the OpenVMS AlphaServer environment A 	2.4 New and updated OpenVMS Transition Modules now available for  download; 	2.5 Information on training resources for Tru64 UNIX Alpha  transitions. 	2.6 OpenVMS Training Page 3. In the Press " 4. Partners/Customers in the Press5    4.1 Migration RPG: Another Option for RPG II Shops G    4.2 Vodafone Recognizes HP as Leading Professional Services Provider  5. From DSPPC    5.1 The latest C++ compiler is now installed on the HP Integrity 4 server running OpenVMS 6. Sue's Fav's 7.0 Partners -G  	7.1 Campus USA Credit Union implements EnterpriseSCHEDULE under Users  Inc. partnership< 	7.2 Appmind will no longer sell it's products on the market7 	7.3 Download PointSecure's FREE OpenVMS Patch Analyzer  8.0 Jobs     ---------------------------    1.0 Time Sensitive  F 1.1. OpenVMS Technical Journal Articles are due May 15, please send to Susan.Skonetski@hp.com  G 1.2. OpenVMS Boot camp is the week of May 21 we have 17 seats remaining , http://h71000.www7.hp.com/news/bootcamp.html  % 1.3. BCS Customer Times now available " http://www.hp.com/go/customertimes  A 1.4. HP Worldwide Advocacy Survey http://www.hpadvocacysurvey.org % please make sure your voice is known.   7 1.5 HP TECHNOLOGY FORUM 2006 - CALL FOR PAPERS NOW OPEN A http://www.hptechnologyforum.com/ then click on "Be a presenter."   1 1.6 HP TECHNOLOGY FORUM REGISTRATION OPENS JUNE 1  http://hptechnologyforum.com   2.0 From HP   D 2.1 New OpenVMS Roadmaps are on the web site as of May 6th I thought you may want to know. > http://h71000.www7.hp.com/openvms/roadmap/openvms_roadmaps.htm  8 2.2 Upcoming changes to Daylight Saving Time in the U.S." http://h71000.www7.hp.com/dst.html   2.3 New OpenVMS White Papers8 http://h71000.www7.hp.com/openvms/whitepapers/index.html  (  2.3.1 HP Superdome Hybrid Servers [PDF]F  2.3.2 Business practices for HP OpenVMS on HP Integrity servers [PDF]C 2.3.3 Integrating HP Integrity servers into the OpenVMS AlphaServer  environment [PDF]   @ 2.4 New and updated OpenVMS Transition Modules now available for downloadF HP has recently released a new set of Transition Modules to assist itsG OpenVMS customers with the transition of their VAX systems to Integrity @ servers. Transition Modules are a collection of information thatG includes white papers, porting guides, advice packages, software tools, F and other valuable documents focused on a specific transition activityG - such as database migration, platform migration, custom code migration ) and packaged application (ISV) migration.   F In addition, an update to the OpenVMS AlphaServer to OpenVMS IntegrityG server Transition Modules is also available. Version 1.1 now includes a # database module for RDB and Oracle.   B Both sets of Transition Modules are available to customers free of< charge at: VAX to Integrity OpenVMS Transition Modules V1.0:G http://h71000.www7.hp.com/openvms/integrity/transition/vax/modules.html 9 AlphaServer to Integrity OpenVMS Transition Modules V1.1: C http://h71000.www7.hp.com/openvms/integrity/transition/modules.html  ----B 2.5 Here is the external HP site where you can find information on4 training resources for Tru64 UNIX Alpha transitions.- http://education.hp.com/curr-hptru64-unix.htm  ----  F 2.6. From Sonia Brocko (OpenVMS Training you will meet her at the Boot& Camp) OpenVMS Training Page (external)1 http://www.hp.com/education/sections/openvms.html   E 3. In the Press http://www.itjungle.com/tlb/tlb050206-story03.html HP 9 Expects to Ship 'Montecito' Arches Servers by Late Summer C AdaCore's GNAT Pro Ada Development Environment Now Available for HP > OpenVMS on HP Integrity Servers; GNAT Pro helps customers meet< stringent requirements for mission-critical software systems http://tinyurl.com/gae99 Oro http://home.businesswire.com/portal/site/google/index.jsp?ndmViewId=news_view&newsId=20060501005204&newsLang=en   D http://www.forbes.com/infoimaging/feeds/ap/2006/04/27/ap2701667.html0 Update 2: Microsoft, EU Debate Access for Rivals  @ http://www.itjungle.com/big/big041106-story01.html The Mainframe Persists for Database Workloads   " 4. Partners/Customers in the Press  E 4.1 http://www.itjungle.com/tfh/tfh050106-story01.html Migration RPG:  Another Option for RPG II Shops   E 4.2 http://biz.yahoo.com/bw/060420/20060420005266.html?.v=1  Vodafone 7 Recognizes HP as Leading Professional Services Provider    5. From DSPPG 5.1 The latest C++ compiler is now installed on the HP Integrity server F running OpenVMS.  HP C++ V7.2 features 64-bit pointers.  DocumentationC may be found in the release notes file, SYS$HELP:CXX.RELEASE_NOTES, G section 2.1 64-bit Pointer Support.  This is the "sanity" kit that will ) be submitted to manufacturing on May 1st.   F TestDrive users may telnet to td183.testdrive.hp.com.  TestDrive login7 is free.  To get an account, go to www.testdrive.hp.com    6. Sue's Fav's   Susan,G I have started 2 articles in Wikipedia about well-known persons related B to Digital Equipment. If you would know anybody who can contributeD content to those articles I would appreciate it a lot... the articleG about John just started, while you can see that the article about Terry " already has substantial content...  ;         http://en.wikipedia.org/wiki/John_Robert_Wisniewski   2         http://en.wikipedia.org/wiki/Terry_Shannon Vriendelijke groeten,  Geert Van Pamel  -----------------------------  7.0Partners   G 7.1 http://www.i-s-e.com/Success/ISE_Success_Story_36/index.html Campus ? USA Credit Union implements EnterpriseSCHEDULE under Users Inc.  partnership   # ___________________________________    7.2 7 Appmind will no longer sell it's products on the market   D Besides developing and selling generic system agent software AppmindF also develops and provides real time application surveillance softwareB (AppMind MX) used in mission-critical applications. The AppMind MXC product has become a vital component in OMX's marketplace solutions C delivered to more than 30 exchanges all over the world. In order to E gain full leverage from the strong customer relationship, Appmind has + decided to fully focus the business on OMX.   @ The continued development and maintenance will be fully based onA requirements from OMX and its customers. There will be no further D development of the AppMind System Agent products and Appmind will no> longer sell the products on the market. The sales and productsC departments will be closed. However, all existing support contracts  will be honored by Appmind.   C Please contact us at appmindinfo@appmind.com if you have questions!   
 Kind Regards,  AppMind Software AB  _______________________  7.3 F Download PointSecure's FREE OpenVMS Patch Analyzer Ensure your systems@ are up to date with the latest patches from OpenVMS engineering.1 http://www.pointsecure.com/products/patch_anl.asp    __________________ 8.0 Jobs    E 8.1 I know when we touched base a month or two ago you mentioned that D you have a network of Engineer colleagues that you run opportunities past when you hear of them.  Here is one.   Brief Job Description   0 Territory - Eastern United States - Boston Based  $ Department: Applications Engineering  G Position Description: The qualified candidate will utilize knowledge of D power supply designs and topologies to evaluate new power management9 integrated circuits and support existing designs. Primary F responsibilities will include: bread boarding, defining and evaluatingE IC designs, creating reference designs, developing evaluation boards, C writing application notes, datasheets, evaluation manuals and other @ design-in tools, providing technical assistance and relationship= building with customers, sales managers and field application 
 engineers.  A Minimum Requirements: BSEE plus 2 years experience in DC/DC power G supply design and circuit topology. Qualifications Desired: MSEE plus 2 C years experience in DC/DC power supply design and circuit topology.      Tim Roth Invision Portland, OR P: 866.391.8877  P: 503.620.5826  f: 503.620.8007  email: tim@4invision.com* ------------------------------------------ 8.2 ? Functional Title: IT- Highly Specialized Database Administrator  Overall Experience: 07-09 Yrs.1 Position Description: Requirements of an RDB DBA:    Location: MN Duration: Long Term  Rate : OPEN   G We are looking for a strong (5-10 years of experience) RDB DBA to plan, ? coordinate, and administer RDB database on OpenVMS systems. The E candidate must be able to develop data models and perform planning of ; architecture, functions, modules, and standards. Additional = qualifications include experience with Oracle on VMS systems.    Mandatory Skills/Experience ? - Recent, in-depth, hands-on, related experience as an RDB DBA. 3 - Hands-on experience on OpenVMS / Alpha platforms. C - Experienced with design and programming the database operational, D backup, journaling restore and archiving procedures in a system thatC requires and relies upon a lot of cross database data integrity and  constraint factors. G - Hands-on experience with analyzing database dumps reverse engineering E to reconstruct the data in severe situations of database corruptions.    Desirable Skills/Experience:- - Very Desirable: DBA experience with Oracle.  - OpenVMS clusters. ! - Digital Command Language (DCL). F - OpenVMS capacity planning, performance management and system utility tools.     Thanks,    Amjad Pathan cyberThink Inc 1125 US Hwy 22 West  Bridgewater, NJ - 08807-9837! Tel    :  (908) 429-8008 ext: 390  Fax    :  (908) 429-8005" mailto:Amjad.Pathan@cyberThink.com mailto:Amjad@cyberThink.com  www.cyberThink.com	 ---------  8.3 D From: elisabeth.laspe@ajilon.com [mailto:elisabeth.laspe@ajilon.com]' Sent: Wednesday, April 26, 2006 7:23 AM  To: & Subject: VAX ALPHA Programmer Analysts    E Ajilon consulting has opportunities for VAX ALPHA Programmer Analysts A for a client  in St.Louis, Missouri.  Right to hire.  Do you know  anyone who mightE be interested?  Please send resume as a word doc attachment.    Clint  willF schedule interview  within the  next week. Description is  below. Hope to hear from you soon.   Required Skills:  > *Minimum of seven years of programming experience on VAX/ALPHAE machines. *Minimum of five years experience with COBOL/OpenVMS. *Must E have hands-on experience in FMS, Datatrieve, CMS, COBOL, DCL, RMS and @ DecForms. *Experience with usage of System Services and Run-timeF Library Functions on OpenVMS. *Knowledge of "C" programming is a plus.E CORBA experience is a plus. *Experience with source management tools,  preferably CMS/ MMS.   Analytical:   C *Ability to partner with a lead analyst. The lead analyst will work D with the business to determine requirements. The analyst may require	 that this  individual: ,  - research and document existing processes,>  - determine gaps between existing processes and requirements,!  - assist in the solution design, 1  - develop, test, implement and support solution.   < *Proven ability to work with minimal supervision and minimalF documentation. *Successful track record of participation in ALL phases@ of the Systems Development Life Cycle. *Must have the ability to@ analyze source code to determine and understand current process.   Communication / Other:  C *Excellent verbal and written communication skills. *Willingness to = participate in production support activities. *Right to hire. ? * Ability to work and succeed in a dynamic environment in which G direction may change periodically.  The individual may also participate  in multiple projects.      Elisabeth Laspe  Technical Recruiting Manager AJILON Consulting 	 Suite 110  425 S. Woods Mill Road St. Louis, MO 63017  314-434-5003 X 225 1-800-434-2342 X 225 Fax # 314-434-7441A Email: elisabeth.laspe@ajilon.com http://www.ajilonconsulting.com    ------------------------------   Date: 8 May 2006 21:16:36 -0700  From: davidc@montagar.com $ Subject: Re: X windows vulnerabilityC Message-ID: <1147148196.445193.215540@j73g2000cwa.googlegroups.com>   F Strong typing is for weak minds! :-)   I do wish compilers would treatE comparing a pointer to scalar 0 as a type mismatch, though...  That's  what NULL is defined for!    ------------------------------   End of INFO-VAX 2006.256 ************************