1 INFO-VAX	Tue, 10 Jul 2001	Volume 2001 : Issue 379       Contents: Re: Alpha 2100A blue screen :-( 5 Re: Alpha fiasco looses $30M deal to IBM in Singapore 5 Re: Alpha fiasco looses $30M deal to IBM in Singapore 5 Re: Alpha fiasco looses $30M deal to IBM in Singapore * Re: Capellas admits move anti-competitive?* Re: Capellas admits move anti-competitive? Re: Changing platforms.  Compaq loses Alpha deal to IBMD Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window?D Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window?D Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window?B Re: Computer Rooms and big UPSes: I need some electrical advice... Darwin Awards for Compaq! Re: DEC Notes available, someone?  Re: DECWORLD 2001 Byte article Re: DECWORLD 2001 Byte article Re: DECWORLD 2001 Byte article Re: DECWORLD 2001 Byte article DVI to ADC Conversion Box  6722  Re: Experience with EMC storage  Re: Experience with EMC storage  Re: Experience with EMC storage 1 Re: exploitable buffer overflows in VMS possible? 1 Re: exploitable buffer overflows in VMS possible? 1 Re: exploitable buffer overflows in VMS possible? 1 Re: exploitable buffer overflows in VMS possible?  Re: FreeVMS  Re: FUD  Re: FUD  Re: FUD  Re: FUD  Re: FUD $ Re: Helper applications with Mozilla RE: IA64 Rocks My World  Re: IA64 Rocks My World % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance , Re: network clustering - multiple interfaces" Re: New Mailbox 0.7 (anyone using)	 Perl 5.6? 3 Re: PointSecure's Website Affected by Thunderstorms - Re: Porting VMS (was Itanium, non-issue, ...) 
 Re: Rdb troll " Removing a Vax cluster environment! Running OpenVMS on ALPHA PWS 500a % Re: Running OpenVMS on ALPHA PWS 500a 1 Re: Some thoughts on the recent turn of events... 1 Re: Some thoughts on the recent turn of events... 1 Re: Some thoughts on the recent turn of events... 1 Re: Some thoughts on the recent turn of events...  Re: The Alpha/IA64 Hybrid 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated  The Inquirer Strikes Again Re: The Inquirer Strikes Again Re: The Inquirer Strikes Again< Re: VBN 397: Invalid bucket address sample in bucket header.< Re: VBN 397: Invalid bucket address sample in bucket header.< Re: VBN 397: Invalid bucket address sample in bucket header.? Re: VMS software/documentation product library (aka con dist) ? F Re: Wailing and moaning.... (was: Some thoughts on the recent turn...)F Re: Wailing and moaning.... (was: Some thoughts on the recent turn...)# Re: What about performance issues?? % What happened to Charon-VAX Hobbyist? ) Re: What happened to Charon-VAX Hobbyist? ) Re: Writing to OPA0: from a device driver  [ANNOUNCE] OpenSSL 0.9.6b  [ANNOUNCE] OpenSSL 0.9.6b  [ANNOUNCE] OpenSSL 0.9.6b   F ----------------------------------------------------------------------  $ Date: Mon, 9 Jul 2001 18:39:13 -0400) From: "Neil Rieck" <n.rieck@sympatico.ca> ( Subject: Re: Alpha 2100A blue screen :-(: Message-ID: <Nkq27.12515$as2.511054@news20.bellglobal.com>  I Forget about my previous post. When the console of an Alpha-2100 has been K set to serial, almost nothing goes to the VGA monitor. Doing a system power L up with the halt button in should drop you into console mode. If it doesn't,G then something is hanging the bus and you may have to resort to pulling I boards to try and improve the situation (make sure the memory hasn't been C removed; if you've got more than one memory board, then swap them).   H BTW, when an Alpha-2100 boots you should see firmware writing diagnosticJ messages to the OCP (a 16 character glass alpha-numeric display mounted onK the front of the chassis).  If this doesn't happen then you could also have  a power supply problem.   I Compaq does publish a firmware CD-ROM. But in order to update firware you I need to have a working system and then need to boot the disk ("b dka500:" L and then follow the instructions). BTW, if you ever get this far, be sure toJ always update the SRM module first. A problem can occur when SRM module is older than version 5.3  # More information can be found here: ; ftp://ftp.digital.com/pub/Digital/Alpha/firmware/index.html     
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/    ------------------------------  # Date: Mon, 09 Jul 2001 17:58:40 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>> Subject: Re: Alpha fiasco looses $30M deal to IBM in Singapore8 Message-ID: <khm27.15$NF2.26808@typhoon.ne.mediaone.net>  F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:AEsVzGcA8pIY@eisner.encompasserve.org... I > In article <I0g27.5585$gb6.1031322@news20.bellglobal.com>, "Neil Rieck"  <n.rieck@sympatico.ca> writes:L > > Compaq looses $30M deal to IBM (in Singapore) because of Alpha's demise? > > + > > http://www.theinquirer.net/09070107.htm  > > L > > If this fact is true and more deals fall through, then Capellas could goG > > down in flames at the next shareholder's meeting (but with a golden D > > parachute the size of the Alpha Microprocessor Division's annual
 budget). IK > > still don't understand why Compaq didn't decide to support/develop both G > > Alpha and IA-64 (eg. HP: PA-RISC and IA-xx, IBM: PowerPC and IA-xx,  etc.). > 0 > Perhaps Intel required it as part of the deal.  I Indeed. Compaq's announcement that it will consolidate on IPF, not merely I incorporate the architecture into future enterprise servers, makes a much   more compelling story for Intel.  G On the surface it seems to be a strategic blunder of the first order to J publish Alpha's obituary three years ahead of time, but Compaq had reasonsJ for committing to a high-risk strategy. And I suspect they knew they would( experience some sales attrition as well.  L The ramifications of the June 25 announcement have yet to be fully revealed.L There are significant ramifications for INTC, ORCL, and MSFT. Not to mention Compaq's ISSG.   ------------------------------  $ Date: Mon, 9 Jul 2001 21:21:27 -0400) From: "Neil Rieck" <n.rieck@sympatico.ca> > Subject: Re: Alpha fiasco looses $30M deal to IBM in Singapore; Message-ID: <6Js27.13003$gb6.1646036@news20.bellglobal.com>   7 "Main, Kerry" <Kerry.Main@compaq.com> wrote in message>  [snip]  L > To clarify - while they had to release a few additional speed bumps on theD > PA line,  HP has announced their future platform for HPUX is IA64.  K If memory serves, HP announced the end of the PA-RISC architecture and then H had to revive it a year later (in 1998) because of the delays associated with Merced (a.k.a. Itanium)0 http://www.hoise.com/articles/UH-PR-11-98-2.html( The new chips were JUST not speed bumps.  H Compaq has announced the end of Alpha and is already scaring away futureJ business by implying that employees from the Alpha Microprocessor DivisionH are almost Intel employees. Intel is on record stating that they are notG taking Alpha from Compaq so Alpha has all the charm of an orphan. IMHO, G Compaq should not have burned its bridges so quickly. Itanium is a very L expensive (US$4k/chip) unproven architecture that currently only boots LinuxE and has no native apps. Also, it is being released at a time when the D computer market place is very depressed. (6 vendors released ItaniumI machines last month but I don't see the world racing to buy them). Compaq F could have its cake and eat it too by building a bridge to IA-64 (portI complier tools and OSes: "Tru64, OpenVMS, NSK and Linux") and continue to L promote Alpha until such time that IA-64 is more successful. Then a graceful$ transfer should have been announced.  F > Also, IBM has announced their future AIX5L (former Monterey program) > platform is IA64 or Power4.   3 I don't see IBM announcing the end of POWER family.   J > Both of which, while some emulation/translation capabilities will likelyI > exist, will require application porting / recompile for important 64bit  apps
 > as well. >  > Reference:J > http://www.hp.com/products1/itanium/vision/roi/parisc_roadmap_print.htmlJ > http://www-1.ibm.com/servers/aix/overview/industry.html (IA64 and Power)( > http://www-1.ibm.com/servers/monterey/ > 
 > Regards, >  > Kerry Main > Senior Consultant  > Compaq Canada Inc. > Professional Services  > Voice: 613-592-4660  > Fax  :  819-772-7036 > Email: Kerry.Main@Compaq.com >  >  > -----Original Message-----0 > From: Neil Rieck [mailto:n.rieck@sympatico.ca] > Sent: July 9, 2001 6:56 AM > To: Info-VAX@Mvb.Saic.Com < > Subject: Alpha fiasco looses $30M deal to IBM in Singapore >  > J > Compaq looses $30M deal to IBM (in Singapore) because of Alpha's demise? > ) > http://www.theinquirer.net/09070107.htm  > J > If this fact is true and more deals fall through, then Capellas could goE > down in flames at the next shareholder's meeting (but with a golden K > parachute the size of the Alpha Microprocessor Division's annual budget).  I I > still don't understand why Compaq didn't decide to support/develop both L > Alpha and IA-64 (eg. HP: PA-RISC and IA-xx, IBM: PowerPC and IA-xx, etc.). > K > Mikey: It's not too late to change your mind about killing Alpha! You can H > save face by saying that this is the recommendation of the newly hired > marketing consultants. >  >  > Neil Rieck > Kitchener/Waterloo/Cambridge,  > Ontario, Canada.# > http://www3.sympatico.ca/n.rieck/ B > http://www3.sympatico.ca/n.rieck/links/compaq_memorial_site.html >  >    ------------------------------  $ Date: Mon, 9 Jul 2001 22:13:00 -0500% From: "Rich Jordan" <rjordan@mcs.net> > Subject: Re: Alpha fiasco looses $30M deal to IBM in Singapore5 Message-ID: <Dlu27.15237$j02.226880@news.goodnet.com>   % Terry C. Shannon wrote in message ...  > ... H >On the surface it seems to be a strategic blunder of the first order toK >publish Alpha's obituary three years ahead of time, but Compaq had reasons K >for committing to a high-risk strategy. And I suspect they knew they would ) >experience some sales attrition as well.  >     K Its just too bad about those smaller VARs and resellers who have stuck with L VMS through it all who are also getting a dose of "sales attrition" courtesyL of the 'q'.  That $30M deal might have been a direct Compaq one (don't know,L not taking time to look at the article) but those nice little $15-200K salesF that made life fun... those are coming out of our (and others like us) bottom line.   Rich Jordan 4 rjordan@mcs.com   <--- soon to be rjordan@duodec.com   ------------------------------  % Date: Mon, 09 Jul 2001 17:35:36 -0600  From: yyyc186@mindspring.com3 Subject: Re: Capellas admits move anti-competitive? ; Message-ID: <3b4a3ff4$1$lllp186$mr2ice@nntp.mindspring.com>   C In <ada27.8466$Pf6.3253689@typhoon.ne.mediaone.net>, on 07/09/2001  D    at 04:15 AM, "Terry C. Shannon" <terryshannon@mediaone.net> said:    * ><yyyc186@mindspring.com> wrote in message6 >news:3b492f41$2$lllp186$mr2ice@nntp.mindspring.com...4 >> In <3B3FB586.A45D654D@bigfoot.com>, on 07/01/2001; >>    at 07:43 PM, Hamlyn Mootoo <univms@bigfoot.com> said:  >>M >> Basically, GQ Bob has been on Mickey's payroll ever since he took the helm L >> of steering DEC straight into the ground.  This was a deliberate criminalG >> action taken with mallice of forethought.  Even as he was committing I >> mail/wire fraud hosting interviews and spouting how he was turning DEC F >> around he was in negotiations to sell the entire company to Compaq.J >> Shareholders were given absolutely NO knowledge of this when he startedG >> doing it week one of his tenure.  This was a blatant criminal action & >> directed by the Billy Goat himself. >>M >> The current criminal master plan is to whore off enough of Compaq that the J >> Billy Goat can now consume it.  Why does he want it?  So he can put theK >> same resource working on generating new and unique Blue Screens of Death L >> into "improving" VMS.  He wants to remove the two platforms which are theE >> epitamy of being correctly done and reliable.  But he can't....You J >> see....VMS is a protected computer species....ceasing development of itM >> while it is still under contract with DOD and other government agencies is G >> an act of treason.  Doing it gets you a trip to prison, and possibly I >> hanging.  (Been so long since someone was killed for an act of treason M >> that the "acceptable methods" haven't been updated.)  Add to this the fact I >> __none__ of the evil billy gates's OS's (if you commit enough fraud to - >> call them that) enjoy the same protection.  >>L >> So, the evil billy gates has two options.  Option 1) put in place a patsyJ >> which will take the fall  ala GQ Oswald or 2)  Consume the company, putJ >> your "crack" Windows 2k development team (you know, the ones that stillL >> haven't figured out how to do clustering) and let them "improve" each newG >> release of VMS such that it is more wretched and grotesque than your L >> average .Even MS release.  This will force the DOD into either taking theG >> OS in house, or porting to your new "prefferred" platform.  He has a K >> little problem here though...none of his "prefferred" platforms can pass K >> any of the reliability tests.  And the 40Billion dollar Yorktown !@#$ up L >> (which I don't think has left drydock since being found dead in the waterF >> some number of years ago) isn't lending any creedence to his cause. >>7 >> That's my analysis given MS's prior battle tacticts.  >>	 >> Roland   G >Microsoft's influence at Compaq is fading. Oracle is ascendent. Recall F >that Microsoft never got access to the VMS goodies it wanted (clusterG >file system for NT, etc) yet Oracle got the TruCluster IP for Oracle9i H >RAC. Note that Compaq's new best friend Oracle participated in the June9 >25 announcement. Nary a reference was made to Microsoft.   I >Compaq's IPF-Inside strategy is bad juju for Gates and Win2K Datacenter. F >With the demise of Alpha and MIPS, Intel gets three proven enterpriseH >OSes to run on IPF. The not-ready-for-prime-time Win2K Datacenter facesF >new competition in the IPF space, and market share dominance is by noB >means a sure thing. And Microsoft's ability to influence Intel is' >directly proportional to market share.     H MS's influence at DEC will always be heavy handed as long as G.Q. Oswald2 is on the board and/or holding an advisory office.   Roland     --  ; -----------------------------------------------------------  yyyc186@mindspring.com; -----------------------------------------------------------    ------------------------------  # Date: Mon, 09 Jul 2001 22:52:06 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>3 Subject: Re: Capellas admits move anti-competitive? : Message-ID: <qAq27.234$LH4.193997@typhoon.ne.mediaone.net>  ) <yyyc186@mindspring.com> wrote in message 5 news:3b4a3ff4$1$lllp186$mr2ice@nntp.mindspring.com... D > In <ada27.8466$Pf6.3253689@typhoon.ne.mediaone.net>, on 07/09/2001F >    at 04:15 AM, "Terry C. Shannon" <terryshannon@mediaone.net> said:  I > >Microsoft's influence at Compaq is fading. Oracle is ascendent. Recall H > >that Microsoft never got access to the VMS goodies it wanted (clusterI > >file system for NT, etc) yet Oracle got the TruCluster IP for Oracle9i J > >RAC. Note that Compaq's new best friend Oracle participated in the June; > >25 announcement. Nary a reference was made to Microsoft.  > K > >Compaq's IPF-Inside strategy is bad juju for Gates and Win2K Datacenter. H > >With the demise of Alpha and MIPS, Intel gets three proven enterpriseJ > >OSes to run on IPF. The not-ready-for-prime-time Win2K Datacenter facesH > >new competition in the IPF space, and market share dominance is by noD > >means a sure thing. And Microsoft's ability to influence Intel is) > >directly proportional to market share.  >  > J > MS's influence at DEC will always be heavy handed as long as G.Q. Oswald4 > is on the board and/or holding an advisory office. >i > Roland  - We'll see. I'm sticking by my assessment. ;-}o   ------------------------------  % Date: Tue, 10 Jul 2001 00:33:22 +0200o) From: Christof Brass <brass@infopuls.com>e  Subject: Re: Changing platforms., Message-ID: <3B4A3132.73F4C27E@infopuls.com>   Keith Parris wrote:A > x > "Duane Sand" <duane.sand@mindspring.com> wrote in message news:<LBU_6.139045$%i7.93197619@news1.rdc1.sfba.home.com>...M > > I don't challenge that VMS makes nice earnings from offering good systems B > > with good software features to a very desirable customer base.I > > But somehow the net total of everything associated with Alpha, ie themK > > entire division formerly known as Digital, is consistently losing moneyEJ > > every quarter, and those losses are only barely covered by the profitsM > > from the division formerly known as Tandem.  I believe it's been that waygK > > since before both were acquired, and maybe long before, given Digital's $ > > long decline before acquisition. > H > I think this is a myth.  And it concerns me that it is believed withinC > the Tandem division, because that means it is probably widespread  > within Compaq. > D > Let's examine this assertion in more depth -- that the portions ofH > Compaq which were formerly Digital are chronically losing money.  WhatG > was left of Digital after the takeover by Compaq?  VMS, Tru64, Alpha,-F > StorageWorks, and Services (arguably the majority of Services, sinceH > Compaq reportedly bought Digital primarily for that capability).  (TheC > Networks Division had been sold to Cabletron.  The PC Division of @ > Digital was immediately axed; even the exemplary HiNote series > succumbed swiftly to NIH.) > H > We've been told VMS has $4B in revenues per year, with profits of $800F > million.  Tru64 can't be doing much worse than VMS, considering thatH > we're told more than half of all high-end Alphaservers go out the doorE > running Tru64.  Alpha costs $150 million per year, according to theH? > recent press info (other sources reported here estimated $300hG > million); even if take the larger number and we assume that number iseC > a total loss, it's more than covered by the profits of VMS alone.aH > StorageWorks is going great gangbusters, with #1 market share in SANs,F > so I really doubt they're losing money.  The 2000 Annual Report saysD > Services made a profit.  So what portions of Digital are left that! > could possibly be losing money?  > D > Tandem's revenues are $1.3 billion per year, and it is profitable.H > But its contribution to Compaq's profits is dwarfed in comparison withE > that of VMS, even after subtracting all the Alpha development costst > first. > " > > The fixation on home-grown cpuD > > chips named Alpha seems to be a big part of the expense problem. > H > What big expense problem?  The press info said Alpha development costsE > $150 million per year.  Big deal!  They could double or even triplenD > the development expenditures to keep Alpha competitve and still be) > profitable based on VMS' profits alone.a > G > Face it -- VMS, Tru64, StorageWorks, and Tandem have been keeping theeF > PC Division afloat for years.  If VMS goes down, Tandem could end upF > in the dumpster with the rest of Compaq.  And the recent decision to? > can Alpha puts VMS and Tru64 revenues at risk, in my opinion.c  @ Brilliant, but not to the point Compaq had in mind (do they have@ one?) with giving away Alpha: this was basically Untel's idea to< get rid of the bad press repeating Untel's processors beeing slower than Alpha.< Compaq has decided to transform itself to a services company: within 180 days. They simply don't care much about VMS and= Tru64. They care about supplying service to Wuntel customers.a   ------------------------------   Date: 9 Jul 2001 18:44:51 -0700k3 From: antony.wardle@optusnet.com.au (Antony Wardle)t' Subject: Compaq loses Alpha deal to IBMe< Message-ID: <fe52053.0107091744.620f200c@posting.google.com>  ' http://www.theinquirer.net/09070107.htm1   Reports from the field e$ By Mike Magee, 09/07/01 10:15:48 BST    D THE INQUIRER is receiving so far unconfirmed reports that Compaq has= lost a deal worth $30 million to IBM in the wake of its Alpha 
 announcement. E The reports say that the Singapore government was set to put its handiD in its pocket for an Alpha clustering contract. But when it heard ofC Compaq's unwavering commitment to the microprocessor, it decided toe switch the business.  C Now IBM appears to have swung the deal. If the reports are correct, F and we are trying to obtain confirmation at press time, this will be a, bitter pill for Q shareholders to swallow.    ------------------------------  % Date: Mon, 09 Jul 2001 17:06:46 -0400-, From: Steve Lionel <Steve.Lionel@compaq.com>M Subject: Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window? 8 Message-ID: <rd6kktsroturt7uj8u49b5vv68keu7heaq@4ax.com>  F On Mon, 09 Jul 2001 10:46:45 -0700, Tom Linden <tom@kednos.com> wrote:  K >Is Compaq actually transferring title or simply licensing the compilers tog >Intel?nJ >When you say that the compilers will continue to be Compaq products, does >that implyoK >that compaq will continue with engineering support, or will that be turnedp >over to Intel? G >Has the list yet been identified, as to what is going where?  GEM, SDL  >various front-endsaK >where are they.  Based on the press releases, which identify an agreement,r >Somebody must know.H >I would be truly amazed if the agreement said "to be defined at a later= >date", Intel doesn't do business that way.  Why the mystery?d  F Please note that I have not read the actual contract, so I can only goA by what I have been told.  Also, it's clear to those of us on thedE ground that there's a lot of "and then a miracle happens" in here - Ic) expect this to get fleshed out over time.   B Intel is acquiring the engineering groups and access to the sourceA code for the compilers.  Intel is committed to providing "Level 3eA support", which means bug fixes, etc., and then makes the changesy@ available to Compaq which packages it and sells it.  The primaryA support contact continues to be Compaq Services, as it is today. m  ? Compaq will continue to own and sell the VMS and Tru64 compileru> products and, supposedly, will have some engineering resources! available to do platform porting.T  D As for "somebody must know" - hah!  My initial understanding is that@ the list includes Fortran, C/C++, GEM, Math Library, Ladebug andE performance tools.  (I may have left something out.)  SDL is not partaE of this - VMS owns that.  At the moment, the only project which knowsMF that it is moving to Intel and when is Fortran, but I'm sure that more* will be settled out over the coming weeks.  A My take on this is that the high-level folks who came up with the F agreement had little understanding as to how the compiler products areB developed and supported, and the initial agreement reflected that.F Have patience - those of us who feel responsible for the products will@ work to make sure that the "right things" happen.   Also, pleaseD understand that we're all VERY BUSY right now trying to work out theD mechanics of the transition so don't have a lot of time available to  try to interpret/explain things.    - Steve Lionel (mailto:Steve.Lionel@compaq.com)s Fortran Engineeringn* High-Performance Technical Computing Group& Compaq Computer Corporation, Nashua NH  6 Compaq Fortran web site: http://www.compaq.com/fortran   ------------------------------  % Date: Mon, 09 Jul 2001 23:12:10 -0400b2 From: rdeininger@mindspring.com (Robert Deininger)M Subject: Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window?dL Message-ID: <rdeininger-0907012312110001@user-2ivea5o.dialup.mindspring.com>  E In article <7gpjktso8o011lokpmmujh65g4821ibd0k@4ax.com>, Steve Lionelg  <Steve.Lionel@compaq.com> wrote:    F > As it has been explained to me - note that this is NOT in any way anD > official statement - all existing Compaq compilers for OpenVMS andH > Tru64 will continue to be Compaq products, thus the transition of someH > compiler groups to Intel (Fortran is the first) will have no effect onD > programs such as CSLG.  Intel will provide development and supportG > resources, but these compilers will still be sold as Compaq products.  > H > When there are IA64 compilers for OpenVMS and Tru64, these too will be@ > Compaq products, so Compaq gets to decide how to license them. > G > The only current Compaq compiler which will actually change to becomemH > an Intel-branded product is Visual Fortran for Windows, but that won't > happen for at least a year.C > G > After Fortran, the specifics as to which "compiler" groups (including4D > GEM, math library and some others) transition to Intel and when isF > currently unknown.  Fortran will make the move in mid-August (last I	 > heard.)e  D Will there still be anyone around to enhance Fortran on VMS (Vax and Alpha) and Tru64?   H Will there still be folks working on GEM for alpha, to put in the neededJ enhancements for EV7x?  Is the optimization work for EV7 already finished?   --   Robert Deininger rdeininger@mindspring.comt   ------------------------------  % Date: Mon, 09 Jul 2001 23:14:10 -0400m2 From: rdeininger@mindspring.com (Robert Deininger)M Subject: Re: Compilers go to Intel, hobbyist, CSLG, etc. goes out the window?aL Message-ID: <rdeininger-0907012314110001@user-2ivea5o.dialup.mindspring.com>  D In article <CIEJLCMNHNNDLLOOGNJIEEBDCPAA.tom@kednos.com>, Tom Linden <tom@kednos.com> wrote:u  L > Is Compaq actually transferring title or simply licensing the compilers to > Intel?K > When you say that the compilers will continue to be Compaq products, doese > that implyL > that compaq will continue with engineering support, or will that be turned > over to Intel?H > Has the list yet been identified, as to what is going where?  GEM, SDL > various front-endsL > where are they.  Based on the press releases, which identify an agreement, > Somebody must know.$I > I would be truly amazed if the agreement said "to be defined at a latern> > date", Intel doesn't do business that way.  Why the mystery?     Hi Tom,t  , What's the release schedule for PL/1 on IPF?   :-)   J Just kidding, mostly.  I wouldn't expect a timetable, but does Kednos have any plans in the works?-   -- r Robert Deininger rdeininger@mindspring.come   ------------------------------  % Date: Mon, 09 Jul 2001 13:42:21 -0500o1 From: "David J. Dachtera" <djesys.nospam@fsi.net> K Subject: Re: Computer Rooms and big UPSes: I need some electrical advice... ' Message-ID: <3B49FB0D.D8D7D955@fsi.net>e   "Richard D. Piccard" wrote:o > [snip]E >         ***the current and potential need not be in phase with each 
 > other***  D Not being an EE, I've often wondered: can current remain positive if; potential goes negative? If so, for how long and under whatu circumstances?   -- - David J. Dachtera  dba DJE Systemsu http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/   F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.l   ------------------------------  % Date: Mon, 09 Jul 2001 15:40:46 -0300o) From: fabio_compaq@ep-bc.petrobras.com.brt! Subject: Darwin Awards for Compaq L Message-ID: <OFA74FEE18.2F3A10ED-ON03256A84.00668438@ep-bc.petrobras.com.br>  
 Just click   http://www.darwinawards.com./   > And tell a strange  story about Compaq ... in these days .....   Regards    FC   ------------------------------  % Date: Mon, 09 Jul 2001 23:16:12 -0400w2 From: rdeininger@mindspring.com (Robert Deininger)* Subject: Re: DEC Notes available, someone?L Message-ID: <rdeininger-0907012316130001@user-2ivea5o.dialup.mindspring.com>  J In article <Pine.LNX.4.21.0107091848070.8093-100000@firewall.freddym.org>,. Freddy Meerwaldt <frederik@freddym.org> wrote:   > Hi Steve,t > H > > >Anyway, we would like to install DEC Notes on it, but I only have a% > > >slightly outdated version handy.n > > E > > The last DEC Notes kit is 2.5A from 1993.  Is that what you have?o >  > Yupp!iF > A real pity that DEC stopped developing DEC Notes - it's a very nice
 > product.  K Yes, it is nice.  Out of curiosity, what would you like to see added to it?a  G There's a Notes-to-Web converter around somewhere, likely on one of theiF freeware CDs.  I don't know if it's read-only, or if you can use it to post and reply to notes.   -- t Robert Deininger rdeininger@mindspring.come   ------------------------------  + Date: Mon, 09 Jul 2001 10:59:00 -0700 (PDT)l  From: l_ricker@lto.locktrack.com' Subject: Re: DECWORLD 2001 Byte articlee. Message-ID: <01070910590045@lto.locktrack.com>  : > On the other hand, maybe I can find it on the 'net?  ;-?  ; Yup, as an exercise:  www.sciam.com ... hit "Archive" link,p: use search-engine looking for "digital information", found (among others) --p  5 Title:   Ensuring the Longevity of Digital Documents u Author:   Rothenberg i Date:   January 1995 o No. of Pages:   6  Starting Page #:   42 6 Abstract:   The digital medium is replacing paper in a6 dramatic record-keeping revolution. But such documents may be lost unless we act nown  e Price for this article:   $5.00   $ Ain't capitalism a grand thing?  ;-)   -- Lorin   ------------------------------   Date: 9 Jul 2001 18:11:55 GMTf0 From: fdc@watsun.cc.columbia.edu (Frank da Cruz)' Subject: Re: DECWORLD 2001 Byte article 5 Message-ID: <9ics5b$jfo$1@newsmaster.cc.columbia.edu>f  . In article <01070910470171@lto.locktrack.com>,$  <l_ricker@lto.locktrack.com> wrote:- : >Will this article exist 25 years from now?i : >Will the URL work next year?n : A : >I can still read a paper copy of an article in Byte from 1976.R : K : >http://abcnews.go.com/sections/scitech/DailyNews/preservation010708.htmlf :  : >food for thought. : C : `Scientific American' covered this same topic of data/informationwA : preservation in an excellent article in, I think, an issue fromyD : the early 1990's... I'd post a reference if I could only find that@ : issue in my banker's boxes containing all my back issues!  ;-) : G I don't have the reference handy either, but it was indeed an excellentnH article, except until the conclusions, which were basically now that allJ publication is electronic, and inevitably tied to some particular hardwareE and software (e.g. Word 97 on Intel), all we need to do is keep everysH application and OS around forever, and keep writing simulators for every: kind of hardware, which doesn't sound like much fun to me.  H Also the article pretty much predates the Web, which renders all of thatF moot now.  The problem has shifted from strictly proprietary platform-I specific formats for files that we *have*, to de facto proprietary "open"u: formats for data that changes or disappears by the second.   - Franke   ------------------------------   Date: 9 Jul 2001 18:43:34 GMTD1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) ' Subject: Re: DECWORLD 2001 Byte article , Message-ID: <9icu0m$17e1$1@info.cs.uofs.edu>  ; In article <aek-0907011014590001@il0502a-dhcp38.apple.com>,t"  aek@spies.com (Al Kossow) writes:F |> In article <uiu5ktg8e6r5a0e1hvotsj71tbmeg4lqjm@4ax.com>, Alan Greig |> <a.greig@virgin.net> wrote: |> i1 |> > DEC no longer exists, Byte no longer exists?c |> >  I |> > But you can still read the Byte review of DECworld 2001 by Lou Greerg |> e
 |> today.. |> r |> > at D |> > http://www.byte.com/documents/s=716/byt20010622s0005/greer.html |> >   |>  - |> Will this article exist 25 years from now?o  ? Will the earth be here 25 years from now??  If it is, I have non> reason to believe all the stuff ont he web will go away.  Even that with little or no value.    |> Will the URL work next year?y  = Will the URL work tomorrow??  Even if it doesn't, there is no @ reason to believe the article won't be archived in several dozen different places.s   |> yA |> I can still read a paper copy of an article in Byte from 1976.  |>  K |> http://abcnews.go.com/sections/scitech/DailyNews/preservation010708.html  |> o |> food for thought.  C I can still read stuff online that I posted/emailed in 1987.  There E wasn't even a Web then and yet this stuff has lasted until there was. C I see no reason to believe that stuff on the web today is likely toj- disappear any time in the foreseeable future.3  F I think it much more likely that the paper copies will go away.  WhileE I still have my collection of Byte, Creative Computing, Kilobaud, Dr.1E Dobbs, etc.  someday I will have to decide between them and somethingcE of more value and they will go to the recyclers.  Assuming they don't  deteriorate physically first.s     bill   -- oJ 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>   m   ------------------------------   Date: 9 Jul 2001 12:17:23 -0700e+ From: Tim Shoppa <shoppa@trailing-edge.com>i' Subject: Re: DECWORLD 2001 Byte articlec) Message-ID: <9id00301uht@drn.newsguy.com>A  N In article <9icu0m$17e1$1@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu says... >n< >In article <aek-0907011014590001@il0502a-dhcp38.apple.com>,# > aek@spies.com (Al Kossow) writes: G >|> In article <uiu5ktg8e6r5a0e1hvotsj71tbmeg4lqjm@4ax.com>, Alan Greigy >|> <a.greig@virgin.net> wrote:o >|> 2 >|> > DEC no longer exists, Byte no longer exists? >|> > J >|> > But you can still read the Byte review of DECworld 2001 by Lou Greer >|>  >|> today..D >|>  >|> > atE >|> > http://www.byte.com/documents/s=716/byt20010622s0005/greer.htmle >|> >  >|> . >|> Will this article exist 25 years from now? >t@ >Will the earth be here 25 years from now??  If it is, I have no? >reason to believe all the stuff ont he web will go away.  Even8 >that with little or no value.  C I'm less certain.  For example, show me where on the web I can find C a 15-year old version of EMACS.  Or on what FTP site I can find all K the PDP-10 software that was on SIMTEL-20 for public FTP in the early 90's.uH These were major tools that were being electronically distributed at theJ time via the most major distribution hubs of their time, yet today I don't know where to find them.   Tim.   ------------------------------  # Date: Mon, 09 Jul 2001 22:12:00 GMTo From: gsinfo@gefen.com( Subject: DVI to ADC Conversion Box  67227 Message-ID: <Q_p27.168113$qv3.43798528@nnrp5-w.sbc.net>a   Dear User Group;   Gefen makes an interface that allows any computer with a DVI output, including the older G4 with DVI graphics to connect to any new Apple flat panel display 15" and 17" Studio Display and 22" Cinema Display monitors with ADC connection.     The DVI to ADC Conversion Box as it is called also allows Macintosh users to add a second DVI PCI card and to drive a second Apple flat panel display (15" and 17" Studio Display and 22" Cinema Display )   The package includes:   1- The DVI to ADC Conversion Box 2- 6 feet DVI cable (M-M)n 3- 6 feet USB cable (A-B)a   The package  list price is $299.00 and we wanted to offer it to your user group at a special discount ($100.00) off or $199.00. Any purchases during  the month of July 2001 will be honored at the reduced price.  < You can find more information online at http://www.gefen.com  9 Call us and mention this ad to get your $100.00 discount.,  > evgyselfslhuprdsoxeolhjkycbjikjzvqijfowsjphhmbukjzoupepfwdnekw   ------------------------------  # Date: Tue, 10 Jul 2001 03:09:28 GMTl" From: Ed Wilts <ewilts@ewilts.org>( Subject: Re: Experience with EMC storage; Message-ID: <Ilu27.6102$GI4.275814@typhoon.mn.mediaone.net>e   Rob Young wrote:  ; > In article <3B45AA0B.7BFDE069@bigfoot.com>, Hamlyn MootooT > <univms@bigfoot.com> writes:G >> Do you plan to use two, using SRDF to synchronize data with a backup0H >> data center? To me, disaster tolerance is one of the best features ofG >> the EMC boxes; that and BCV's which allow you great flexibility, and. >> save backup time. > = > You wouldn't want SRDF as it makes absolutely no sense witht> > VMS.  SRDF is for broken/brain-dead OSes.  I think there mayB > be only one of those left, but I haven't done a complete survey.  ? Before you spout off like this, perhaps you need a little more t) understanding of how SRDF actually works.r  > > What you would do of course is use VMS volume shadowing with > your Symmetrixes.n  G So, with nodes in your cluster a thousand miles away, you'd use volume dJ shadowing?  Yeah, right.  There *are* people using SRDF across very large I distances, and those distances are not supported, nor are practical, for  K volume shadowing.  I talked to one EMC customer who was using SRDF between -J Puerto Rico, California, and Minnesota.  Try that with volume shadowing...  J This isn't to say that SRDF is better in all cases than volume shadowing, K because it isn't.  There are latencies involved, but those latencies allow kL you to do things that simply aren't possible with volume shadowing.  If you 2 can use volume shadowing, it's normally preferred.  B         .../Ed (who has a disaster tolerant cluster based on HBVS) -- c Ed Wilts, Mounds View, MN, USA mailto:ewilts@ewilts.org   ------------------------------  # Date: Tue, 10 Jul 2001 03:14:27 GMT " From: Ed Wilts <ewilts@ewilts.org>( Subject: Re: Experience with EMC storage; Message-ID: <nqu27.6103$GI4.275814@typhoon.mn.mediaone.net>e  
 Koloth wrote:p    F > 3) Does having the cached mirrored and the external batteries on theE > Compaq's HSG80 make it reliable enough to just use controller based"/ > mirroring versus host based volume shadowing?s  H Controller-based mirroring is not good enough.  Simple as that.  I have F personally been the proud recipient of an HSJ-50 controller pair that K disagreed on the membership of its raidsets.  Kiss 40GB of storage goodbye e% and restore the raidset from tape :-(   J My storage uses HSJ-50 pairs which is then mirrored using HBVS to another L controller pair in another data center.  I have yet to lose data, even when K one data center lost power, lost its UPS, and a source member drive failed a while copying the data back.   --   Ed Wilts, Mounds View, MN, USA mailto:ewilts@ewilts.org   ------------------------------    Date: 10 Jul 2001 00:42:34 -0500+ From: young_r@encompasserve.org (Rob Young)o( Subject: Re: Experience with EMC storage3 Message-ID: <Tm0dwbEdhKqo@eisner.encompasserve.org>a  ` In article <Ilu27.6102$GI4.275814@typhoon.mn.mediaone.net>, Ed Wilts <ewilts@ewilts.org> writes: > Rob Young wrote: > < >> In article <3B45AA0B.7BFDE069@bigfoot.com>, Hamlyn Mootoo >> <univms@bigfoot.com> writes:eH >>> Do you plan to use two, using SRDF to synchronize data with a backupI >>> data center? To me, disaster tolerance is one of the best features oftH >>> the EMC boxes; that and BCV's which allow you great flexibility, and >>> save backup time.g >> o> >> You wouldn't want SRDF as it makes absolutely no sense with? >> VMS.  SRDF is for broken/brain-dead OSes.  I think there mayhC >> be only one of those left, but I haven't done a complete survey." > A > Before you spout off like this, perhaps you need a little more S+ > understanding of how SRDF actually works.  >   = 	I know how it works.  Perhaps we want to look at the manualst  	and compare notes and what not?  ? >> What you would do of course is use VMS volume shadowing withh >> your Symmetrixes. > I > So, with nodes in your cluster a thousand miles away, you'd use volume s > shadowing?  Yeah, right.    = 	Ahhh... now you are arguing from extremes.  You are correct.2< 	You certainly wouldn't want to use Volume Shadowing in thatE 	case.  But you wouldn't have a cluster that far apart either, right? > 	So just what is that far away?  Another cluster waiting to go3 	live when/if the primary datacenter goes sky high?1  2 > There *are* people using SRDF across very large K > distances, and those distances are not supported, nor are practical, for tM > volume shadowing.  I talked to one EMC customer who was using SRDF between fL > Puerto Rico, California, and Minnesota.  Try that with volume shadowing... >   > 	And from a recent discussion in comp.arch Greg Pfister points+ 	out that you can spool journals worldwide:e  ' From: Greg Pfister (pfister@us.ibm.com)e= Subject: Re: Where do the filesystem and RAID system belong? c Newsgroups: comp.archa Date: 2001-01-11 12:23:41 PST   r  = On the other hand, I know of many current products (from IBM,d< Sybase, Informix, Oracle) that do the log spooling trick, so; presumably this provides something most customers are quiteo; satisfied with. Also, some non-DB products (like IBM HACMP;f? others probably have them too) allow the customer to select theiA degree of synchronization. For Sybase in particular, the spoolingrA version was developed for brokerage houses who wanted to maintaini< centers around the world, local to various markets, with the= "primary" that sources the spooling rotating around the worldlA over 24 hours - London to NY to Hong Kong to Munich to London ...p? Things are actually "out of sync" in such situations by as mucht< as several seconds, but the customers are happy with it like that.g     	Try that with SRDF.  L > This isn't to say that SRDF is better in all cases than volume shadowing, M > because it isn't.  There are latencies involved, but those latencies allow oN > you to do things that simply aren't possible with volume shadowing.  If you 4 > can use volume shadowing, it's normally preferred. >   G 	And now.... to put this back in perspective... using a more reasonablee@ 	scenario that would cover most customers.  At the distances youI 	mention, you are in "semi synchronous" mode and there is the whole nasty C 	of lost writes or a high *possibility* of lost writes.  It is bestuA 	to keep the distance resonable so you can stay *synchronous* and?@ 	if you can stay *synchronous* , SRDF makes absolutely no sense @ 	whatsover in a VMS environment.  But yes, there is a subset of @ 	customers out there that wish to keep disparate datacenters in ; 	lock-step, or so they think.   Or they are keeping them innD 	lockstep with EMC + SRDF + Multihop + TimeFinder to get around that8 	small problem of writes that never hit remote platters.     http://www.hds.com/pdf/ssg.pdf  M Semi synchronous remote copy is not recommended for disaster recovery becausewH the application may assume a given write is successful when, in fact, itL ultimately may have failed at the secondary location. This inconsistency canN very easily cause the second copy of the data to become corrupted. SignificantO improvements to this technology have reduced this risk but caution should stillRN prevail, especially in larger, complex environments. Essentially, an update toO a specific logical volume causes a busy condition for that volume, and although N that update is immediately allowed to complete, the busy condition will not beL released until the update is secured at the secondary location. This has twoL effects. First, no subsequent updates may occur on that logical volume untilO the previous one does complete. Second, a subsequent failure in transmission to I the secondary logical volume (as might happen in a rolling disaster!) can H result in out-of-sequence data at the secondary because the application,D assuming its updates were successful, continued its update activity.  *                                   MultiHop  N MultiHop is an EMC product. Primary site updates are copied to a local (withinN ESCON ) bunker site using SRDF synchronous. At that bunker site, an additionalM system copy is maintained using TimeFinder (also an EMC product). This bunkereF site needs to be far enough away to be outside the scope of a regionalK disaster. Any issues that are normally associated with synchronous productswO (i.e. consistency and performance) still apply. The TimeFinder copy is shadowedlL again to a remote (third) site using the Adaptive Copy feature of SRDF. ThatK third-site copy also needs to be protected with a TimeFinder copy. MultiHoplK requires three separate sites, and six to eight separate copies of the sametI data that includes the copies required for RAID-1 protection. As a resulteO MultiHop is a very expensive solution and very complex from an operations point.I of view. However, in spite of the multiplicity of data copies, expense toCN deploy and operational complexity, MultiHop and TimeFinder do provide EMC with+ a long-distance disaster recovery solution.e   ---t  < 	So I suppose with Multihop + TimeFinder and a few Symmetrix; 	here and there you have a case.  Looks a little expensive,o< 	and a much better solution would to be:  keep your distance6 	reasonable (if you can) and use VMS Volume Shadowing.  @ 	Oh, one other thing... those folks going MN<->CA<->Puerto Rico,= 	they aren't using Multihop + TimeFinder and a bunker site as0= 	they are reasonable folks.  So they really don't care about >< 	remote data integrity in a disaster do they?  Or maybe they2 	don't really understand the issues?  Which is it?   	Just curious ;-)r   				Robo    D >         .../Ed (who has a disaster tolerant cluster based on HBVS) > -- h  > Ed Wilts, Mounds View, MN, USA > mailto:ewilts@ewilts.org   ------------------------------   Date: 9 Jul 2001 14:47:33 -0500t9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)c: Subject: Re: exploitable buffer overflows in VMS possible?3 Message-ID: <CyPTAEK7GSrG@eisner.encompasserve.org>0  { In article <D6m27.450$rc5.28335@news.cpqcorp.net>, lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman) writes:mq > In article <hJmIkrqsI+pw@eisner.encompasserve.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:e >>G >>Both C and Bliss support sloppy programming in this regard with their B >>pointer arithmetic, making it easy to run off the end of arrays. >>H >>C promotes sloppy programming in this regard with it's null-terminated
 >>strings. > B > Even so, the default action of the compilers is to separate code4 > and data, and protect the various memory segments. > 9 > In order for someone to exploit this hole, at least twoo > things have to happen. > : > First, there has to be a program which people can access9 > from the 'outside' in some way: this would usually meann= > a web browser, web server, or some similar network program.c  ; Or a Trojan Horse, to operate without a network connection.t   ------------------------------   Date: 9 Jul 2001 14:49:13 -0500w9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen),: Subject: Re: exploitable buffer overflows in VMS possible?3 Message-ID: <p2c3WD13zuu0@eisner.encompasserve.org>   ` In article <9icoo8$14l1$1@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:5 > In article <hJmIkrqsI+pw@eisner.encompasserve.org>,t> >  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes: > |>  K > |> C promotes sloppy programming in this regard with it's null-terminateds
 > |> strings.  > B > We've been through this before, but Macro-11 had null terminated@ > strings (.ASCIZ) and very likely predated the common use of C.  @ Certainly it had the ability to generate such, but they were notA that useful :-).  What was missing were the routines to copy froml> one .ASCIZ string to another without regard to the size of the$ target area.  C fixes that omission.   ------------------------------   Date: 9 Jul 2001 19:05:32 GMTk1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) : Subject: Re: exploitable buffer overflows in VMS possible?, Message-ID: <9icv9s$17e1$3@info.cs.uofs.edu>  3 In article <p2c3WD13zuu0@eisner.encompasserve.org>, <  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:c |> In article <9icoo8$14l1$1@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:r8 |> > In article <hJmIkrqsI+pw@eisner.encompasserve.org>,A |> >  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:w |> > |> N |> > |> C promotes sloppy programming in this regard with it's null-terminated |> > |> strings. |> > wE |> > We've been through this before, but Macro-11 had null terminated'C |> > strings (.ASCIZ) and very likely predated the common use of C.s |> rC |> Certainly it had the ability to generate such, but they were notbD |> that useful :-).  What was missing were the routines to copy fromA |> one .ASCIZ string to another without regard to the size of thee' |> target area.  C fixes that omission.   @ Actually, they were used primarily for output strings and .PRINT@ expected them.  Seems pretty useful to me.  Saved the programmer> the trouble of counting all his output strings and passing theA length as a parameter.  Use .ASCIZ to define static strings, make @ sure all dynamic strings end with a null, call .PRINT for any of them.d   bill   -- tJ 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>   c   ------------------------------  % Date: Mon, 09 Jul 2001 21:48:51 +0200o= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>d: Subject: Re: exploitable buffer overflows in VMS possible?) Message-ID: <3B4A0AA2.FE9B4823@gtech.com>p   Bill Gunshannon wrote:+ > In article <3B45C33C.2727C9CE@gtech.com>,cB >  Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> writes: > |> > |>( > |> There are a few good things on VMS:F > |>   * the VMS core are not using C/C++ zero-terminated strings, butI > |>     uses descriptors => that makes the VMS core much less vulnerablej/ > |>     than its Unix and Windows counterpartsv > F > C & C++ are not the only languages subject to data overruns writting > into other data areas.   No.   > But it is significantly easier to avoid in languages that uses descriptors|C than languages that uses zero-terminate strings. Because max-lengthe is mandatory with descriptors.  G There are probably other languages than C/C++ that uses zero-terminateds7 strings, but they are probably the mot well-known such.t   Arne   ------------------------------  # Date: Tue, 10 Jul 2001 05:51:46 GMTe0 From: Monty Brandenberg <mcbinc@ne.mediaone.net> Subject: Re: FreeVMS/ Message-ID: <3B4A97F3.9DA7BDE9@ne.mediaone.net>n   "antonio.carlini" wrote: >  > 6 > Reverse engineering is (I think) permitted in Europe2 > under some circumstances. I thought that was the > case in the US too?e >  > Just mildly curious.  5 Legal reverse engineering is how Compaq was started..    -- eM Monty Brandenberg, Software Consultant                              MCB, Inc. M mcbinc@world.std.com                                          P.O. Box 426188-M mcbinc@ne.mediaone.net                              Cambridge, MA  02142-0021a 617.864.6907   ------------------------------   Date: 9 Jul 2001 18:21:11 GMTG1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)t Subject: Re: FUD, Message-ID: <9icsmn$16sm$1@info.cs.uofs.edu>  D In article <kEl27.1475$HV1.153718@newsread1.prod.itd.earthlink.net>,1  "mulp" <michaelpettengill@earthlink.net> writes:n |> |>  O |> Sun forced a rapid switch to SPARC by stopping production of 68K systems andn0 |> you couldn't run Solaris on just any 68K box. |> e  A Just one small nit.  You could never run Solaris on a 68K system.    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>   o   ------------------------------  % Date: Mon, 09 Jul 2001 14:36:32 -0400 + From: John Eisenschmidt <jeisensc@aaas.org>k Subject: Re: FUD# Message-ID: <sb49c191.091@aaas.org>-  J Though, scary as it may seem, there was a Solaris port to Power PC in 2.51  & LONG LIVE SUN OS. LONG LIVE SLOWLARIS.  I >>> Bill Gunshannon <bill@triangle.cs.uofs.edu> 07/09/2001 2:21:11 PM >>> D In article <kEl27.1475$HV1.153718@newsread1.prod.itd.earthlink.net>,1  "mulp" <michaelpettengill@earthlink.net> writes:  |> |>=20 E |> Sun forced a rapid switch to SPARC by stopping production of 68K =  systems ande0 |> you couldn't run Solaris on just any 68K box. |>=20x  A Just one small nit.  You could never run Solaris on a 68K system.a   bill   --=20 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   |C Scranton, Pennsylvania   |         #include <std.disclaimer.h>  =20d   ------------------------------   Date: 9 Jul 2001 14:39:42 -0400t/ From: jordan@lisa.gemair.com (Jordan Henderson)n Subject: Re: FUD* Message-ID: <9ictpe$sl8$1@lisa.gemair.com>  , In article <9icsmn$16sm$1@info.cs.uofs.edu>,- Bill Gunshannon <bill@cs.scranton.edu> wrote:SE >In article <kEl27.1475$HV1.153718@newsread1.prod.itd.earthlink.net>,d2 > "mulp" <michaelpettengill@earthlink.net> writes: >|>o >|> P >|> Sun forced a rapid switch to SPARC by stopping production of 68K systems and1 >|> you couldn't run Solaris on just any 68K box.  >|>  >SB >Just one small nit.  You could never run Solaris on a 68K system. >T  E It may depends on who you ask.  Sun did rebadge SunOS 4 as Solaris 1.s  @ Now, I can't recall, did 68K systems run SunOS 4, or was that 3?   >bills >o >-- K >Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolveseE >bill@cs.scranton.edu     |  and a sheep voting on what's for dinner.w >University of Scranton   |-B >Scranton, Pennsylvania   |         #include <std.disclaimer.h>      -Jordan Henderson  jordan@greenapple.com    ------------------------------  % Date: Mon, 09 Jul 2001 15:38:33 -0300t) From: fabio_compaq@ep-bc.petrobras.com.brt Subject: Re: FUDL Message-ID: <OF5CB16C05.B03CDED9-ON03256A84.00665E22@ep-bc.petrobras.com.br>   Bill  & It is a US$ 68K system ! It runs . . .     Regardsu   FC        B bill@triangle.cs.uofs.edu (Bill Gunshannon) em 09/07/2001 15:21:11  = Favor responder a bill@triangle.cs.uofs.edu (Bill Gunshannon)l             Info-VAX@Mvb.Saic.Comm       Assunto: Re: FUD    D In article <kEl27.1475$HV1.153718@newsread1.prod.itd.earthlink.net>,1  "mulp" <michaelpettengill@earthlink.net> writes:e |> |>K |> Sun forced a rapid switch to SPARC by stopping production of 68K systems  and 0 |> you couldn't run Solaris on just any 68K box. |>  A Just one small nit.  You could never run Solaris on a 68K system.-   bill   --J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |> Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------   Date: 9 Jul 2001 18:59:33 GMTn1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon): Subject: Re: FUD, Message-ID: <9icuul$17e1$2@info.cs.uofs.edu>  * In article <9ictpe$sl8$1@lisa.gemair.com>,2  jordan@lisa.gemair.com (Jordan Henderson) writes:/ |> In article <9icsmn$16sm$1@info.cs.uofs.edu>,?0 |> Bill Gunshannon <bill@cs.scranton.edu> wrote:H |> >In article <kEl27.1475$HV1.153718@newsread1.prod.itd.earthlink.net>,5 |> > "mulp" <michaelpettengill@earthlink.net> writes:  |> >|> |> >|> aS |> >|> Sun forced a rapid switch to SPARC by stopping production of 68K systems andh4 |> >|> you couldn't run Solaris on just any 68K box. |> >|> m |> >E |> >Just one small nit.  You could never run Solaris on a 68K system.l |> > |>  H |> It may depends on who you ask.  Sun did rebadge SunOS 4 as Solaris 1. |> sC |> Now, I can't recall, did 68K systems run SunOS 4, or was that 3?   I The last 68K version of SunOS was quite sometime before the first releasemH of Solaris with a number of Sparc only releases in the interim.  I don'tJ believe any 68K version  ever shipped on a CD and I have a number of SunOS( coasters loating around the office here.  F Where's andrew when we really need him??  He must know the chronology.   bill   -- lJ 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>   s   ------------------------------  + Date: Mon, 09 Jul 2001 22:11:46 +0200 (MET)e' From: ZINSER@sysdev.deutsche-boerse.comf- Subject: Re: Helper applications with Mozillay; Message-ID: <01K5QR0BFKU28ZEP28@sysdev.deutsche-boerse.com>u   Hello,  F 	since neither changing the path to xpdf to look Unix like (why shouldD 	this really be neccessary, xpdf is defined as a global symbol in myC 	environment), nor using %s (which is certainly correct for Mosaic, F 	but would be horribly counterintuitive to the way helper applicationsB 	are setup in Mozilla) does make any difference, I guess Patricks C 	answer is the ticket: It simply is broken. Any indications to the r 	contrary (Colin maybe? ;-)o   				Greetings, Martini  o > From:	IN%"pmoreau@dev.ath.cena.fr"  "Patrick MOREAU, CENA Athis, Tel: 01.69.57.64.40"  8-JUL-2001 15:09:55.98b, > Subj:	RE: Helper applications with Mozilla  , > In article <3b478deb$1@news.kapsch.co.at>,. > eplan@kapsch.net (Peter LANGSTOEGER) writes: > i > > In article <01K5KV993DV68ZEP28@sysdev.deutsche-boerse.com>, ZINSER@sysdev.deutsche-boerse.com writes: K > >>      I've tried to setup helper applications with Mozilla, but withoutn> > >>      success. Specifically I used the following settings: > >> > >>      Name: Adobe PDF files  > >>      Extension: PDF$ > >>      MIME Type: application/pdf% > >>      Handled By Application xpdf  > >s > > Wasn't it "xpdf %s" ?n > K > The helpers support seems to be broken with Mozilla 0.91 and 0.92 .May be  > specific to the VMS port ? > Q > There is another regression with 0.92: background images are not displayed (not  > specific to the VMS port). > B > I stay with 0.91 , performances are good (far better than 0.90). > 	 > Patricks > --Q > ===============================================================================tQ > pmoreau@cena.dgac.fr  (CENA)     ______      ___   _           (Patrick MOREAU) 6 > moreau_p@decus.fr (DECUS)       / /   /     / /|  /|J > CENA/Athis-Mons FRANCE         / /___/     / / | / |   __   __   __   __P > BP 205                        / /         / /  |/  |  |  | |__| |__  |__| |  |P > 94542 ORLY AEROGARE CEDEX    / /   ::    / /       |  |__| | \  |__  |  | |__|P > http://www.ath.cena.fr/~pmoreau/            http://www.multimania.com/pmoreau/Q > ===============================================================================sP Dr. Martin P.J. Zinser                                 zinser@sysdev.exchange.de2 Deutsche Boerse Systems AG                        O Neue Boersenstr. 1                                     Tel: +49 69 2101 5634   nL 60487 Frankfurt                                        FAX: +49 69 2101 3411P Germany                                                Private:  zinser@decus.de   ------------------------------  % Date: Mon, 09 Jul 2001 14:38:57 -0400e+ From: "Main, Kerry" <Kerry.Main@compaq.com>g  Subject: RE: IA64 Rocks My WorldR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4AD7EE2@kaoexc01.americas.cpqcorp.net>  L >>> Because you can "scale out" AFTER you "scale up" but it doesn't work the other direction.<<<s  G Not sure I understand what you are getting at. Why can you not scale upe after a scale out direction?  L As an example, if one starts with two hard partitions with 3 cpu's each, oneI can certainly add cpu's to each partition (to limit that system supports)q% for additional scaling up capacity...   L If that limit is reached, then the ability to do further scaling out becomesB important (whereby two node primary-backup clusters are a distinct limitation).   Regards,  
 Kerry Main Senior Consultanth Compaq Canada Inc. Professional Serviceso Voice: 613-592-4660t Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----1 From: cjt & trefoil [mailto:cheljuba@prodigy.net]e Sent: July 9, 2001 1:33 PM To: Info-VAX@Mvb.Saic.Comt  Subject: Re: IA64 Rocks My World    H Because you can "scale out" AFTER you "scale up" but it doesn't work the othercG direction.  Taking a maximally scaled up system and replicating it willf yield K yet higher performance, but once you've exhausted your ability to scale outp aME system built of pieces that won't scale up any farther, you're spent.e   "Main, Kerry" wrote: > J > >>> Valid perhaps, but should a benchmark run on a partitioned system be
 > compared2 > directly to one on a non-partitioned system? >>> > 
 > Why not? > F > A customer buys a single server and wants to know that he can get an overalln2 > level of performance and availability out of it. > I > Does the Cust business group that approved that purchase care about howi thelJ > techies configure it to get that level of performance and availability ? >  > :-)e > 
 > Regards, >  > Kerry Main > Senior Consultant  > Compaq Canada Inc. > Professional Servicesd > Voice: 613-592-4660n > Fax  :  819-772-7036 > Email: Kerry.Main@Compaq.com >  > -----Original Message-----3 > From: cjt & trefoil [mailto:cheljuba@prodigy.net]r > Sent: July 6, 2001 7:06 PM > To: Info-VAX@Mvb.Saic.Comm" > Subject: Re: IA64 Rocks My World >  > "Main, Kerry" wrote: > >l	 > > Greg,d > >iK > > re: OPS in a box .. I think Andrew is trying to state somehow that a HW(K > > partitioned system using separate OS's within the same system (and OPS)s is" > > somehow not a valid benchmark. > <snip> > F > Valid perhaps, but should a benchmark run on a partitioned system be
 > compared. > directly to one on a non-partitioned system?   ------------------------------  $ Date: Mon, 9 Jul 2001 20:04:38 +0100, From: Peter Boyle <pboyle@holyrood.ed.ac.uk>  Subject: Re: IA64 Rocks My WorldH Message-ID: <Pine.SOL.4.33.0107091945470.23518-100000@holyrood.ed.ac.uk>   Hi,a  K > The amount of traffic between nodes for some of the applications is huge.aK > Wildfire can outperform quadrics between qbbs by a large enough factor tonJ > offset the reduced bandwidth due to memory latency.  The problem is that  H This is exactly why GS320's aren't a good basis for BIG machines. If youF really are going to use all the cpu's on a single application, Ahmdahl; doesn't care that you have "pools" of good performance. ThehA comms between 32 processor "super-nodes" is what will limit you..h So why pay more?  M > wildfire's I/O isn't good enough to meet the bisection bandwidth - wildfirel  D Consider a cubic 3d decomposed application, e.g. Solid state physics simulations.- If you half a 1024 processor machine composedmF of e.g. 4x4x2 GS320's into 2 4x4 halves (I'm being generous giving theU maximal area, rather than a 2x4) you end up with 16 times the interconnect speed of arB single GS320 (typically this would be some aggregate over multipleD links per GS). Note that bisection BW in the larger machine does NOTD depend on the intra-GS320 bandwidth but on the external interconnectI because you can always choose surfaces which do not cut an individual GS.e   Peters  M > only support 33MHz PCI while ES45 supports multiple 66MHz PCIs and quadrics> > can consume a 66MHz PCI bus. >iH > Wildfire needed PCI-X today - the investment for this was all Compaq'sL > responsibility and Compaq didn't make the investment.  But this is the wayN > that Compaq operates: define a technology standard and require it, but don'tM > do anything that requires investing in making it work or taking the risk of 
 > failing. >y >o >   $ Peter Boyle	pboyle@physics.gla.ac.uk   ------------------------------   Date: 9 Jul 2001 18:36:45 GMT-& From: peter@abbnm.com (Peter da Silva). Subject: Re: IA64 volume and low-end dominance% Message-ID: <9ictjt$661@web.nmti.com>e  O In article <9iaevf$39o$1@pyrite.mv.net>, Bill Todd <billtodd@foo.mv.com> wrote:fN > Contrast the above situation with the move from IA16 to IA32.  That move wasK > hardware-technology-driven, not demand-driven:  for many years there werefL > virtually *no* 32-bit desktop applications, despite that fact that typicalL > 16-bit applications had been standing on their heads for years to make useK > of the megabytes of available physical memory (exactly the reverse of therK > situation today).  Users bought 32-bit hardware mostly because it offered K > better performance (at little or no additional cost) running their 16-bits > OSs and 16-bit applications.  J Actually, there were quite a lot of 32-bit desktop applications. They just" werent running on wintel hardware.  O For example, graphics work was largely being done on Macs, and video on Amigas,gH because the 68000 could handle large bitmaps efficiently and the 80[2]86	 couldn't.n  I Once Win32 got moving (and the first Win32 apps could run under Win32s ontJ Windows 3.1), Win32 ports from the 68000 world started showing up. You gotK decent perfomance on Photoshop from the Mac, and the Video Toaster softwareA from the Amiga.a  K But there aren't really any 64-bit desktop apps. The 64-bit apps are thingsn- like huge databases, and they run on servers.   K The only desktop app that I can think of off the top of my head that really L could use that kind of storage is really hefty data mining, stuff that's tooM compute intensive to delegate to servers, and how big a market are investment- bankers?  M > In sum, while I can imagine that Intel would *like* IA64 to replace IA32 inhL > the mass market ASAP, if only to shut out AMD and simplify its own productJ > lines, it's hard to imagine that the market will let them.  Am I missing > something critical here?  L In the final analysis, no, I don't think so... in fact I think the situationJ is worse than for the 16-32 bit transition because there's no "64-bit Mac"0 market for wintel desktops to try and take over.   -- g+  `-_-'   In hoc signo hack, Peter da Silva.eE   'U`    "A well-rounded geek should be able to geek about anything."sL                                                        -- nicolai@esperi.org          Disclaimer: WWFD?   ------------------------------   Date: 9 Jul 2001 20:04:53 GMTn3 From: mooney@dogbert.cc.ndsu.NoDak.edu (Tim Mooney)s. Subject: Re: IA64 volume and low-end dominance. Message-ID: <9id2p5$mgg$1@news.ndsu.nodak.edu>  K In article <9icgor$12e$1@sunnews.cern.ch>, Dan Pop <Dan.Pop@cern.ch> wrote:r3 > In <3B497431.DAF93DDA@peoplepc.com> Jack Patteeuw-# > <jjpatteeuw@peoplepc.com> writes:, > P > >One of Alpha/OSF1 least desirable feature was that it only had a 64 bit mode.- > >No sloppy K&R code could easily be ported.. > L > This is not true.  The Alpha/OSF1 C compiler and the linker could generateI > executable code that lived in a 32-bit address space.  This feature wase: > explicitly intended for easy porting sloppy 32-bit code.  E You mean the -taso/-xtaso/-xtaso_short stuff?  You're right that it'sb= ostensibly been there for a long long time.  However, it's my E understanding (I looked at the problem long ago when trying to port axG crufty "All the world's a sparc running SunOS 4.x" program -- my memoryML might not be 100% accurate at this point) that it was almost unuseable untilF just recently (maybe late 4.x, but probably not until 5.x) because the headers weren't protected.  H Now that the headers are (or can be, see protect_headers_setup(8)), it'sI much easier to port a 32bit app.  Of course, it's *way* too late to be ofr- much use, but don't get me started on that...t   Tim  -- oH Tim Mooney                              mooney@dogbert.cc.ndsu.NoDak.edu> Information Technology Services         (701) 231-1076 (Voice)< Room 242-J6, IACC Building              (701) 231-8541 (Fax)3 North Dakota State University, Fargo, ND 58105-5164s   ------------------------------   Date: 10 Jul 2001 03:04:08 GMT From: Dan.Pop@cern.ch (Dan Pop)c. Subject: Re: IA64 volume and low-end dominance* Message-ID: <9idrb8$koe$1@sunnews.cern.ch>  [ In <9id2p5$mgg$1@news.ndsu.nodak.edu> mooney@dogbert.cc.ndsu.NoDak.edu (Tim Mooney) writes:   L >In article <9icgor$12e$1@sunnews.cern.ch>, Dan Pop <Dan.Pop@cern.ch> wrote:4 >> In <3B497431.DAF93DDA@peoplepc.com> Jack Patteeuw$ >> <jjpatteeuw@peoplepc.com> writes: >>  Q >> >One of Alpha/OSF1 least desirable feature was that it only had a 64 bit mode.c. >> >No sloppy K&R code could easily be ported. >> kM >> This is not true.  The Alpha/OSF1 C compiler and the linker could generatefJ >> executable code that lived in a 32-bit address space.  This feature was; >> explicitly intended for easy porting sloppy 32-bit code.  >tF >You mean the -taso/-xtaso/-xtaso_short stuff?  You're right that it's> >ostensibly been there for a long long time.  However, it's myF >understanding (I looked at the problem long ago when trying to port aH >crufty "All the world's a sparc running SunOS 4.x" program -- my memoryM >might not be 100% accurate at this point) that it was almost unuseable until G >just recently (maybe late 4.x, but probably not until 5.x) because then >headers weren't protected.e  E Even back then (in the days of 3.2), there were some pragmas (I don'toD remember the details, it's been quite some time since I've looked at8 the problem) that allowed the protection of the headers.   Dan  -- Dan Poph CERN, IT Divisionl Email: Dan.Pop@cern.ch |? Mail:  CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland    ------------------------------   Date: 10 Jul 2001 03:32:07 GMT3 From: mooney@dogbert.cc.ndsu.NoDak.edu (Tim Mooney)u. Subject: Re: IA64 volume and low-end dominance. Message-ID: <9idsvn$uov$1@news.ndsu.nodak.edu>  K In article <9idrb8$koe$1@sunnews.cern.ch>, Dan Pop <Dan.Pop@cern.ch> wrote: H > In <9id2p5$mgg$1@news.ndsu.nodak.edu> mooney@dogbert.cc.ndsu.NoDak.edu > (Tim Mooney) writes: > H > >You mean the -taso/-xtaso/-xtaso_short stuff?  You're right that it's@ > >ostensibly been there for a long long time.  However, it's myH > >understanding (I looked at the problem long ago when trying to port aJ > >crufty "All the world's a sparc running SunOS 4.x" program -- my memoryO > >might not be 100% accurate at this point) that it was almost unuseable until.I > >just recently (maybe late 4.x, but probably not until 5.x) because the  > >headers weren't protected.  > G > Even back then (in the days of 3.2), there were some pragmas (I don't2F > remember the details, it's been quite some time since I've looked at: > the problem) that allowed the protection of the headers.  G I did some looking, and I think you're right.  The -protect_headers andnG protect_headers_setup were new in DU 4.0d (1998-1999 timeframe), and anfF email conversation I had with a (then-DEC) guy lead me to believe thatE short of editing the headers themselves, that was the first "elegant"aD way to protect the headers & libraries while compiling for ILP32.  IF misunderstood him by omission.  He never mentioned any other, previousK way of doing it, short of editing system headers, and the pragmas certainlyvJ weren't mentioned where they should have been -- in the compiler man page,J right under the -taso & related options. That notwithstanding, the feature has been there a long time.f   Thanks for the clarification.:   TimD -- sH Tim Mooney                              mooney@dogbert.cc.ndsu.NoDak.edu> Information Technology Services         (701) 231-1076 (Voice)< Room 242-J6, IACC Building              (701) 231-8541 (Fax)3 North Dakota State University, Fargo, ND 58105-5164e   ------------------------------  % Date: Mon, 09 Jul 2001 22:41:50 -0400c2 From: rdeininger@mindspring.com (Robert Deininger)5 Subject: Re: network clustering - multiple interfacespL Message-ID: <rdeininger-0907012241510001@user-2ivea5o.dialup.mindspring.com>  = In article <cb85fed2.0107081831.3766767b@posting.google.com>,v) kparris@my-deja.com (Keith Parris) wrote:     B > PEDRIVER can do a pretty good job of determining by itself whichF > interconnect has the lowest actual latency in practice, so after youH > use LAVC$STOP_BUS to eliminate SCS traffic on your 100BaseT network asF > you wish, you could just let PEDRIVER pick which of the other two itG > uses.  That allows the cluster to survive a failure of either FDDI orn( > Gigabit Ethernet and continue working. >  > > PS. We are running 7.2.1.H > G > 7.2-1H1, I assume.  In the same directory as Verell's CI presentationnE > is one on SCACP, the new control tool in 7.3.  SCACP gives one morel@ > flexibility in controlling PEDRIVER's path-selection behavior.    H I see in the 7.3 New Features and Documentation Overview manual, sectionF 4.9.5, some stuff about improvements in cluster communication over LANJ interconnects.  It looks like they did a lot of work to make PEDRIVER takeE advantage of switched, full-duplex interconnects.  (It was originally2* written for old-style broadcast ethernet.)  . As you said, the SCACP program is new as well.  I There are also new operator messages about excessive packet loss.  Before H this, you only got messages when the network got so bad that the virtual circuit closed.u  9 I haven't used any of this stuff yet, but it sounds good.s   -- s Robert Deininger rdeininger@mindspring.comg   ------------------------------  # Date: Tue, 10 Jul 2001 01:39:55 GMTn2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>+ Subject: Re: New Mailbox 0.7 (anyone using).A Message-ID: <L1t27.86694$2u2.2062873@e420r-sjo2.usenetserver.com>2  = Jean-Francois Marchal <jean-francois.marchal@x9000.fr> wrote: 4 > I've been told the problem should have been fixed.+ > You might download the corrected version.   . Thanks!  I just did and it seems to work fine.   		Zane   ------------------------------  # Date: Tue, 10 Jul 2001 03:16:49 GMTu" From: Ed Wilts <ewilts@ewilts.org> Subject: Perl 5.6?; Message-ID: <Bsu27.6104$GI4.275814@typhoon.mn.mediaone.net>>  H Now that Compaq nicely bundles perl and mod_perl, what are the plans to A keep it current?  As of this week, Compaq still has 5.5.3 online.s   Thanks,t         .../Ed --   Ed Wilts, Mounds View, MN, USA mailto:ewilts@ewilts.org   ------------------------------   Date: 9 Jul 2001 14:48:45 -0700h3 From: antonio.marin@pointsecure.com (Antonio Marin)s< Subject: Re: PointSecure's Website Affected by Thunderstorms; Message-ID: <2edc61b.0107091348.a47ad55@posting.google.com>a   To Whom It May Concern:=    C During the recent electric storms in Houston some of our electronicmB equipment was damaged and we were forced to implement our disaster recovery plans.e  @ In order to provide continuing web and e-mail visibility, our DRA provider InetLabs, rerouted our DNS address.  Unfortunately, some F visitors were caught in the middle of our efforts to recover from such a damaging natural disaster.  E We regret the inconvenience that our technical difficulties caused to.B our web visitors and customers.  On a positive note, our company'sB data center is back in operation and ready to support you with the: highest quality standards that have been characteristic of PointSecure.  
 Sincerely,  
 Antonio Marin  Chief Technical Officer  PointSecure, Inc.s   ======================   "P. Thompson" <thompson-nospam@new.rr.com> wrote in message news:<Pine.LNX.4.33.0107051036240.31583-100000@malacandra.localnet>...G > There was a hack several weeks ago where NT based domain servers were H > sending false addresses for various domains.  Perhaps this is similar. > , > On Wed, 4 Jul 2001, Paul Blenderman wrote: > P > > Unless the DNS servers are VMS-based, this is OT. www.pointsecure.com is OK. > >aO > > The problem is that you have a 50% chance of getting the wrong address fromi > > DNS.- > > (IE, Netscape, etc., etc. is irrelevant.)d > >nF > > Two of the four DNS servers responsible for pointsecure.com are in > > inetlabs.com. 4 > > They supply the correct address: 65.104.226.166. > >sC > > The other two are at gobase2.com. They supply the wrong addresss > > 63.149.157.92.L > > This address is in the same subnet as www.gobase2.com. The SOA record is > > also- > > completely different and doesn't point toy > >nH > > gobase2.com, phatchip.com and pointsecure.com all belong to the same
 > > companiesrN > > at the same address that is also listed at the "real" www.pointsecure.com.J > > Unless this was a very thorough hacker, I'd say an admin probably just > > deliberately orr > > undeliberately screwed up. > > 6 > > "Alan Greig" <a.greig@virgin.net> wrote in message6 > > news:0ac6ktofnqcecofnndrf8nqpch186ai2cq@4ax.com...) > > > On Wed, 04 Jul 2001 10:29:51 -0300,'0 > > > fabio_compaq@ep-bc.petrobras.com.br wrote: > > > < > > > >I am connecting to the homepage and it is appearing : > > > > E > > > > Name                    Last modified       Size  Descriptioni > > >aP > > >--------------------------------------------------------------------------- >  -----8 > > > > Parent Directory        15-Jun-2000 01:46      -8 > > > > Get out of here/        20-Jun-2001 17:01      - > > > >  > > > >? > > > P > > >--------------------------------------------------------------------------- >  ----- > > > >e< > > > >Apache/1.3.14 Server at phatchat.phatchip.com Port 80 > > > 	 > > > FC,a > > >aG > > > I see the same as you but I suspect config problems rather than afE > > > hacker. If you click on get out of here it does bring up a pagen > > >i > > >u > > > --
 > > > Alan > >. > >r > >i   ------------------------------  % Date: Mon, 09 Jul 2001 20:46:04 -0000r- From: wspencer@ap.nospam.org (Warren Spencer)-6 Subject: Re: Porting VMS (was Itanium, non-issue, ...)/ Message-ID: <tkk60c292ji924@news.supernews.com>M  K duane.sand@mindspring.com (Duane Sand) wrote in <ML827.166155$%i7.109214887  @news1.rdc1.sfba.home.com>:    >n2 >"Duane Sand" <duane.sand@mindspring.com> claimed:A >> > I don't know VMS at all, but have been involved in 3 (now 4)aB >> > porting efforts for NSK.  Seems likely that VMS can be portedE >> > onto any stock version of any little-endian processor capable ofs? >> > also running Unixes, at some performance-compromise level.? >  >- >"Bob Koehler" replied:-K >> Not quite.  While many processors support the 4 modes VMS requires, UNIXe: >> requires only 2, and some processors still have only 2. >O= >IA-64 supports 4 levels; hopefully they will fit VMS's needs 
 >well enough.  >f  H IIRC, so does IA-32.  But Windoze uses only rings 0 and 2 - 1 and 3 are  left unused.   ws   -- b   Warren Spencer Senior Software Engineer The Associated Press  L ** My employer does not necessarily agree with my statements - neither do I  **   ------------------------------  % Date: Mon, 09 Jul 2001 17:37:54 -0600a From: yyyc186@mindspring.com Subject: Re: Rdb troll; Message-ID: <3b4a40b8$2$lllp186$mr2ice@nntp.mindspring.com>s  : In <EahJ64AUXHqg@eisner.encompasserve.org>, on 07/09/2001 I    at 05:49 AM, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) said:f  < >In article <3b492690$1$lllp186$mr2ice@nntp.mindspring.com>, >yyyc186@mindspring.com writes:u  L >> What we all need is to dump every Oracle product on every platform in ourK >> shops.  Oracle has been cosistently de-improving RDB until they now have D >> it just about down to the level of Oracle...a database that fails- >> miserably in every aspect of business use.   D >It does not fail in "profitability to the vendor", a characteristic% >Oracle may value higher than you do.e  E Neither does crack, heroin, and a host of other things which are both 8 highly profitable and illegal.  Nothing makes them good.  I Oracle fails in those "little" areas.  Reliability, real time capability,HE tools that work, distributed accross nodes, those insignificant areas . Oracle has never bothered to pay attention to.   Roland -- n; -----------------------------------------------------------e yyyc186@mindspring.com; -----------------------------------------------------------n   ------------------------------  # Date: Tue, 10 Jul 2001 01:22:10 GMTe0 From: "Ambrose, Joseph" <jambrose@optonline.net>+ Subject: Removing a Vax cluster environment < Message-ID: <6Ns27.104130$2W4.17578389@news02.optonline.net>  K In a cost cutting measure, my boss has asked me to dissolve the VAX ClustertH from our dual VAX 4000-500a cluster to enable me to split the system and& physically shut down one of the CPU's.  K I told him we could shutdown and halt one of the processors and the clustera3 would continue, he wants to physically shut it off.n  H This is not possible now because some of the drives are also in the same5 enclosure. Therefore dropping the system on its head.   = I need to break the cluster to do what he has asked. How to ?y   VMS 6.2e     -- Joseph Ambrose System and Network Manager
 Windows NT MSExchange/MSSql Open VMS/VAX The Conference Board Phone : 001-212-339-0443 Fax : 001-212-836-3802( Email : Joe.Ambrose@conference-board.orgB Visit our Award Winning Web Site:  http://www.conference-board.org   ------------------------------  # Date: Mon, 09 Jul 2001 20:55:55 GMTy% From: "Zal Vesuna" <zvesuna@home.com>s* Subject: Running OpenVMS on ALPHA PWS 500a= Message-ID: <vTo27.139385$W02.2486170@news1.rdc2.on.home.com>m  L I recently ordered a hobbyist OpenVMS (V7.2 I think) kit which I plan to run6 on my Alpha PWS 500a with the following configuration:  
 21164A cpu 512MB main memoryo
 2MB bcache Intel SIO 82378 ISA bridge5 Matrox Millenium II PCI graphics card with 2MB memoryb 1 Qlogic PCI SCSI controller% 2 4.3 GB DEC RZ1CC-BA (C) hard drivesd 1 TLZ09 tape drive! 1 IDE TOSHIBA XM6102B cdrom drivea 1 DEC 21143 NICe  K I have updated the SRM Console to V7.2-1 and have OpenVMS PALcode V1.20-16.tK However after reading some docs on the Compaq OpenVMS FAQ website, it would L seem that Alpha OpenVMS V7.2 does not support IDE cdrom drives (booting fromI or otherwise?) nor does it support the Matrox Millenium II graphics card. K I'm not sure if these are the only problems with my system running OpenVMS?hJ If the aforementioned is correct, can anyone please tell me what I need to6 modify/purchase in order for my system to run OpenVMS.  H I am currently running WNT 4.0 on this system, so you can understand the urgency of my plea for help.   Thanks,k   Zal    ------------------------------  % Date: Mon, 09 Jul 2001 23:34:15 -0400 2 From: rdeininger@mindspring.com (Robert Deininger). Subject: Re: Running OpenVMS on ALPHA PWS 500aL Message-ID: <rdeininger-0907012334160001@user-2ivea5o.dialup.mindspring.com>  J In article <vTo27.139385$W02.2486170@news1.rdc2.on.home.com>, "Zal Vesuna" <zvesuna@home.com> wrote:(  M > I have updated the SRM Console to V7.2-1 and have OpenVMS PALcode V1.20-16.$M > However after reading some docs on the Compaq OpenVMS FAQ website, it wouldpN > seem that Alpha OpenVMS V7.2 does not support IDE cdrom drives (booting fromK > or otherwise?) nor does it support the Matrox Millenium II graphics card.b  . I think you are right about the graphics card.  H Some flavors of VMS 7.2 do support (some) IDE CD-ROMs, including bootingJ from them.  There are/were firmware concerns, and you might need VMS 7.2-1& or a lot of patches on top of VMS 7.2.  D Our PWS 600au systems can't do DMA on the CD-ROM drives, so they areJ slow.  For more than occasional use, you'll probably want to obtain a SCSII CD-ROM from a vendor who knows about VMS.  Island Computers has done some # business in this area, for example.n  M > I'm not sure if these are the only problems with my system running OpenVMS? L > If the aforementioned is correct, can anyone please tell me what I need to8 > modify/purchase in order for my system to run OpenVMS.  I I don't know the details.  It's been discussed here before, and I thoughta& the FAQ had more detailed information.   -- t Robert Deininger rdeininger@mindspring.coms   ------------------------------  # Date: Mon, 09 Jul 2001 18:04:21 GMTh4 From: "Terry C. Shannon" <terryshannon@mediaone.net>: Subject: Re: Some thoughts on the recent turn of events...8 Message-ID: <Fmm27.16$NF2.27308@typhoon.ne.mediaone.net>  3 "Bob Marcan" <bob.marcan@aster.si> wrote in message " news:3B4971BD.9AB78723@aster.si... > Robert Deininger wrote:- > >-; > > In article <3B474299.AFCFEDB2@ui.urban.org>, Jim Beckere! > > <jbecker@ui.urban.org> wrote:  > >eJ > > > Not exactly a reply to Ken's message -- I'm just swiping his subject
 > > > line.... > > >dK > > > Our organization was, before the recent turn of events, just about to F > > > buy another Alpha running OpenVMS. We're not a big shop, so thisL > > > wasn't a trivial decision. We like VMS and we like the Alpha, but whenC > > > a vendor announces plans to discontinue one platform and portiH > > > "everything" to another platform to be made by some other company,E > > > it's just good business sense for us to re-assess our decision.c > >g
 > > <snip> > >uJ > > You raised many good points.  Some of them are directly under compaq'sJ > > control.  I suggest you put the questions for Compaq in a nice letter, andaG > > send it to Rich Marcello.  Make it plain that your next alphaserverrD > > purchase is ON HOLD until you see concrete movement in the right > > directions.w > >rL > > Keep in mind that it is less than 2 weeks since the public announcement.7 > > You shouldn't expect concrete timetables yet, IMHO.a >t > Wrong, wrong, wrong!@ > The timetables should be available alongside the announcement. >a  J In a perfect world, yes. Given that this announcement was cobbled togetherK in less than a month, detailed timetables are an unrealistic expectation. IeJ suspect it'll be a couple of months before a reasonably complete agenda is
 assembled.   ------------------------------  % Date: Mon, 09 Jul 2001 22:36:00 +0200R& From: John McLean <mcleanj@dplanet.ch>: Subject: Re: Some thoughts on the recent turn of events...* Message-ID: <3B4A15B0.EE64908F@dplanet.ch>  F There is one big thing that bothers me with the Capellas spiel and theE subsequent writings in the press and here, namely the assumption thatiD the move to IA64 will some how make VMS more popular to users and to ISV's.  F Users don't care too much what kind of "engine" their operating systemH is fitted with so long as it is fast and reliable.  The fact that VMS isG on IA64 might be of interest to what ? maybe 5% of the market, and that'8 is because they are techos who like to know such things.  H For ISV's I cannot see that the move to IA64 will make any difference toG either their plans for a VMS version of their software or to the efforttB that would be involved in doing so.  The work to take advantage ofD clustering would all be unique to VMS as would be the use of certainA System Service routines and run-time libraries.  Neither would be(G trivial task regardless of whether the underlying processor is Alpha oroG IA64.  As to any idea of increased demand from the market, see previousi
 paragraph.  G I am afraid that any idea of increased applications on VMS continues toe look like a pious hope.1  F The _only_ way that anything might happen is if we saw Compaq use someH of their pot full of "Alpha" money (what Intel paid them and the savingsF of disposing of Alpha+compiler teams) and used a decent amount of thatD to market VMS in a big way.  Given their track-record I can't see itG happening.  I hope I will be proved wrong, but I don't think I will be.s     John McLean    ------------------------------   Date: 9 Jul 2001 16:58:49 -0500o+ From: young_r@encompasserve.org (Rob Young)a: Subject: Re: Some thoughts on the recent turn of events...3 Message-ID: <SKmrnRJ4ZPcj@eisner.encompasserve.org>   S In article <3B4A15B0.EE64908F@dplanet.ch>, John McLean <mcleanj@dplanet.ch> writes:n > H > There is one big thing that bothers me with the Capellas spiel and theG > subsequent writings in the press and here, namely the assumption thattF > the move to IA64 will some how make VMS more popular to users and to > ISV's. > H > Users don't care too much what kind of "engine" their operating systemJ > is fitted with so long as it is fast and reliable.  The fact that VMS isI > on IA64 might be of interest to what ? maybe 5% of the market, and that0: > is because they are techos who like to know such things. >   ? 	Some of this too is intertia.  If you are so fortunate to havetB 	many specific VMS system calls in your code base, coming off that, 	may be very problematic.  This is goodness.  J > For ISV's I cannot see that the move to IA64 will make any difference toI > either their plans for a VMS version of their software or to the efforteD > that would be involved in doing so.  The work to take advantage ofF > clustering would all be unique to VMS as would be the use of certainC > System Service routines and run-time libraries.  Neither would beoI > trivial task regardless of whether the underlying processor is Alpha orlI > IA64.  As to any idea of increased demand from the market, see previous3 > paragraph. > I > I am afraid that any idea of increased applications on VMS continues tos > look like a pious hope.v > H > The _only_ way that anything might happen is if we saw Compaq use someJ > of their pot full of "Alpha" money (what Intel paid them and the savingsH > of disposing of Alpha+compiler teams) and used a decent amount of thatF > to market VMS in a big way.  Given their track-record I can't see itI > happening.  I hope I will be proved wrong, but I don't think I will be.t >   > 	I'm not sure how exactly it will work but since compilers are= 	going over to Intel and as Steve Lionel pointed out first tod@ 	go is Visual Fortran (and no they don't all "go" there, but you@ 	get the idea) with continued support for Tru64 and VMS... theseA 	compilers become the de facto compilers, free to Linux and maybee@ 	mostly free (war alert:  no not free but CSA and other programsB 	and hobbyists open up holes for most serious Tru64/VMS developersA 	and yes, you may have to spend a few hundred a year) to others..n  @ 	So maybe compilers and coding to Linux API makes cross platformG 	very real possiblity.  Seems IBM is doing quite a bit with Linux, etc.u? 	so Itanium + Linux API + Compaq/Intel compilers are the key to:E 	future application availability for many back-ends.  Long range goal>B 	would be a "simple" compile with bugs common across all platforms8 	and squashed accordingly.  Maybe that is 3-5 years out?   				Robn   ------------------------------  % Date: Mon, 09 Jul 2001 22:31:10 -0400a2 From: rdeininger@mindspring.com (Robert Deininger): Subject: Re: Some thoughts on the recent turn of events...L Message-ID: <rdeininger-0907012231100001@user-2ivea5o.dialup.mindspring.com>  P In article <3B4971BD.9AB78723@aster.si>, Bob Marcan <bob.marcan@aster.si> wrote:   > Robert Deininger wrote:  > >   L > > Keep in mind that it is less than 2 weeks since the public announcement.7 > > You shouldn't expect concrete timetables yet, IMHO.e >  > Wrong, wrong, wrong!@ > The timetables should be available alongside the announcement.  I Timetable offered by bean-counters, without any input from the engineers, G would be worthless.  I suspect if such were offered, many in this groupe3 would simply complain in a slightly different tone.d   -- t Robert Deininger rdeininger@mindspring.coms   ------------------------------  % Date: Mon, 09 Jul 2001 13:24:20 -0700r3 From: Kevin Strietzel <kevin_strietzel@stratus.com>d" Subject: Re: The Alpha/IA64 Hybrid+ Message-ID: <3B4A12F4.AF5E7266@stratus.com>     LBohan@dbc.spam_less..com wrote: ...c  G Everybody else seems to have assumed a particular DBM.  But in the morew general case....  2 > how do the DBM-type api's fit into this picture?  F I used the "imbedded SQL" preprocessors with Oracle and Informix.  TheF preprocessors C or Fortran (or COBOL or whatever) source with imbeddedH SQL-ish statements into calls to the DBM's runtime library.  It's a cute idea.s  H Back in the mid 1980s, I used Unify on Venix (Unix System III for IBM PCD hardware), and I don't remember the API being all that complex.  ButB then, I was temporary, and wrote my database-using applications by copy-and-paste....  e- > are they typically part of the C run-time ?o   Not the ones I used.  , > are the DBM api's portable bwtween Unices?  H The embedded SQL interfaces are pretty portable.  In fact, both InformixE and Oracle had (nearly?) identical state-reporting or error-reportingaF structures, with the same unused fields; I've always assumed they were= borrowed from some IBM SQL interface, maybe the one from DB2.   " > Could one move a DBM mapped file- > (backing store file, *.dir?) btween unices?i  E I would expect them to be significantly portable in many cases, but IeF never tried.  As somebody else said, it was unsupported, and there are endian-ness (and other) issues.    --Kevin Strietzel"   Not speaking for Stratus.n   ------------------------------  % Date: Mon, 09 Jul 2001 21:46:08 +0200W= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>o: Subject: Re: The death of VMS has been greatly exaggerated) Message-ID: <3B4A09FF.6B79EE71@gtech.com>    Dave Weatherall wrote:G > I have always taken the view that the term 'nn-bit computer' referred-H > to its 'basic' register size. Z80/8080/6800 = 8 bit, pdp11/8086/6800 =8 > 16 bit, vax/80386/68020/ = 32 bit, Alpha,IA64 = 64bit.    That is also a valid definition.  B And in most cases an equivalent definition, because unless offsetsF are used, then addressing X bits require a register capable of holding X bits.   E I still prefer the "size of virtual address" definition, because thata. is what really has an effect for applications.  E > Alphas aren't quick because of an  ability to address 2*63 bytes of G > memory (although that can bring an advantage to many applications). I G > had the impression it was down to how it uses the 64bit registers and1H > the 64bit data bus to load/store 1 quad or 2 long or 4 word or 8 bytesE > on one cycle. Hence, one of the needs for smart compilers. i.e. thei( > optimal arrangement of data in memory.  ? I do not think that 64 bit computers in general are faster thanw 32 bit computers at all.  " They can just address more memory.  A The Alpha was much faster than VAX, but I consider that primarilyv due to the CISC->RISC switch.e   Arne   ------------------------------  % Date: Mon, 09 Jul 2001 23:15:02 +0200f) From: Christof Brass <brass@infopuls.com>>: Subject: Re: The death of VMS has been greatly exaggerated, Message-ID: <3B4A1ED6.A9CCC235@infopuls.com>   Bill Todd wrote: > 9 > "Arne Vajhj" <arne.vajhoej@gtech.com> wrote in messagen% > news:3B44C4E5.E2D11E39@gtech.com...l, > > Andrew Harrison SUNUK Consultancy wrote: > > > > - HP PA --> IA64 > > > 8 > > > Doesn't require new binaries its is able to decode% > > > and run HP-PA binaries on IA-64u > > N > > > > - Alpha --> IA64-2 (or whatever the enhanced IA64 + Alpha architecture > is > > > > called)o > > >s2 > > > Requires a completely new os and ported apps > >-G > > I guess one has to be a SUN sales guy to understand why HP-UX/HP-PAmE > > binaries can run on HP-UX/IA-64 but VMS/Alpha binaries cannot run$ > > on VMS/IA-64 ! > L > You can, of course, run anything on anything, given sufficient motivation.N > But IA64 was specifically designed to support running PA-RISC binaries (justL > how much emulation will be required I don't know, but one should assume itG > will be as minimal as was possible) whereas IA64 was almost certainlyeC > designed with no thought whatsoever about running Alpha binaries.v >  > There is a difference. >  > - bill >  > >o > > Arne  # Another reason *not* to drop Alpha.m   ------------------------------  % Date: Mon, 09 Jul 2001 23:25:30 +0200b) From: Christof Brass <brass@infopuls.com>a: Subject: Re: The death of VMS has been greatly exaggerated+ Message-ID: <3B4A214A.D54AC44@infopuls.com>t   Hunter Goatley wrote:  > R > On Fri, 06 Jul 2001 21:39:41 GMT, "Terry C. Shannon" <terryshannon@mediaone.net> > wrote: > >aL > >Gotta agree with you on that one. I understand that when the VAX to AlphaK > >port was done, all the VMS device drivers and much of the OS itself were- > >recoded in C, > L > That's not true.  A few drivers, maybe, and some pieces of the OS, but the$ > majority is still BLISS and MACRO. > = > >which should render this port less difficult than the last  > >one.m > H > This should still be true, as the BLISS and MACRO-32 compilers now useI > the GEM backend, same as any other compiler, so once a new GEM is done, 6 > a lot of the port should be pretty straight-forward. >  > Hunter > ------; > Hunter Goatley, Process Software, http://www.process.com/ ; > goathunter@goatley.com     http://www.goatley.com/hunter/h  ? I don't think so. In every OS are major parts that deal with HWa? specific issues like mapping registers to I/O ports, setting up = interrupt service routines, enabling and disabling interruptse? a.s.o.. All these parts are very architecture specific and needd> re-coding although they might be compilable at the first place" but the resulting code would fail.   ------------------------------  % Date: Mon, 09 Jul 2001 23:32:11 +0200r) From: Christof Brass <brass@infopuls.com> : Subject: Re: The death of VMS has been greatly exaggerated+ Message-ID: <3B4A22DB.931ACE2@infopuls.com>.   Robert Deininger wrote:- > Q > In article <009FE9D4.D7BB65F8@SendSpamHere.ORG>, system@SendSpamHere.ORG wrote:< > J > > In article <3b463834.9185828@news.process.com>, goathunter@goatley.com > (Hunter Goatley) writes:9 > > >On Fri, 06 Jul 2001 21:39:41 GMT, "Terry C. Shannon"  > <terryshannon@mediaone.net>  > > >wrote:  > > >>O > > >>Gotta agree with you on that one. I understand that when the VAX to AlphacN > > >>port was done, all the VMS device drivers and much of the OS itself were > > >>recoded in C,I > > >oO > > >That's not true.  A few drivers, maybe, and some pieces of the OS, but theB# > >                         ^-- newI' > > >majority is still BLISS and MACRO.7 > >aL > > Recently, I was looking through the source listings to see if/where someL > > mod_STD$routine was used.  Much to my chagrin, DEC created them but theyM > > seldom use them.  Why?  Because so much of OpenVMS was ported with littleoK > > more than a compile.  In the Macro-32 case, the addition of .directivesiK > > to assist the compiler with knowledge it might no be able to gleen fromp$ > > scanning and parsing the source. > D > I guess that's good and bad news.  If they could port once by justJ > compiling, they can almost certainly port the module the same way again.0 > That's good, since it leads to a quicker port.  6 The conclusion might not be correct. It depends on the; architecture similarities. You can't burden all that to thei= compiler. I doubt that most HW specific parts can be migrated4# that way from Alpha or VAX to IA63..  : > The bad part is that they missed a chance to upgrade theL > quality/maintainability of these modules, and will probably miss many such > chances again this time.  > Good point. They should re-write whatever must be touched in a; sound modern PL (not C/C++), e.g. Pascal or Ada or Modula-3n which was developed by DEC.   J > On the other hand, if it ain't broke, don't fix it still applies.  Every= > time someone tweeks a module, there's a chance to break it.r  : Every time you migrate the new environment will unevitably@ reveal hidden bugs. This means that you normally don't know what= isn't broken until you run it within the new environment. Butp: testing can never prove the absence of bugs so it might be> better to assess each module and if the quality is too lowe or= if it is very HW specific you might better re-write it in thek9 first place because the probability of failure after merei re-compilation is too high.    > -- > Robert Deininger > rdeininger@mindspring.comt   ------------------------------  % Date: Mon, 09 Jul 2001 23:37:57 +0200 ) From: Christof Brass <brass@infopuls.com>n: Subject: Re: The death of VMS has been greatly exaggerated, Message-ID: <3B4A2435.97BF5126@infopuls.com>   Eric Taylor wrote: >  > "Mark E. Levy" wrote:  > 7 > > "Eric Taylor" <et@rocketship1.com> wrote in message-- > > news:3B3D264E.C83BC5D6@rocketship1.com...14 > > > My intent is to pursuade all vms users to moveO > > > to linux if at all possible. My project at JPL has just spent less than ag
 > > couple > >F > > ...y > >.N > > You want to "pursuade all vms users to move to linux." Is this just at JPL9 > > or in general? If it's just at JPL, have a nice life. B > > If it's in general, well, then all I have to say is, get bent. > >e
 > > Mark Levyr > < > I said, "if possible". Obviously, you can't or more likely< > won't. I must admit, it was difficult to leave 15 years of9 > vax expertise behind. But, like the buggy whip, vms ando= > eventually all proprietary systems like it, will fade away.g > 6 > You simply cannot afford to be stuck on one piece of: > iron anymore. VMS does that. Soon it will be zero pieces > of hardware. > < > Otherwise, I must commend you for a most eloquently spoken > rebuttal.y >  > ee  : On what HW does the Micro$hit family of so called OSs run?   ------------------------------  % Date: Mon, 09 Jul 2001 23:49:24 +0200t) From: Christof Brass <brass@infopuls.com>s: Subject: Re: The death of VMS has been greatly exaggerated, Message-ID: <3B4A26E4.4CC5BC56@infopuls.com>   JF Mezei wrote:a >  > Christopher Smith wrote:P > > Linux is clearly an inferior product in terms of design to VMS.  It makes noO > > sense to me that one would migrate to something which is "worse" (to choosec$ > > a term) than what they have now. > L > The OS is useless to a company. It is something seen by low level techies.$ > APPLICATIONS ARE WHAT ARE THE KEY. > M > And if you can't get the apps you need on VMS but they exist on Linux, then . > you move to Linux even if Linux is inferior.  % What does this mean "move to Linux"??l> If there is one app I urgently need and what is only available> on Linux (I doubt that anyway) I might inclined to use a Linux: box just for that purpose. But I would never think a femto= second about dropping VMS in favour of Linux as long as there ! are apps I need available on VMS.n   ------------------------------  # Date: Mon, 09 Jul 2001 21:56:23 GMTa- From: goathunter@goatley.com (Hunter Goatley)r: Subject: Re: The death of VMS has been greatly exaggerated0 Message-ID: <3b4a2814.16996239@news.process.com>  N On Mon, 09 Jul 2001 23:25:30 +0200, Christof Brass <brass@infopuls.com> wrote:   >Hunter Goatley wrote:I >> This should still be true, as the BLISS and MACRO-32 compilers now usetJ >> the GEM backend, same as any other compiler, so once a new GEM is done,7 >> a lot of the port should be pretty straight-forward.e >> A >w@ >I don't think so. In every OS are major parts that deal with HW@ >specific issues like mapping registers to I/O ports, setting up> >interrupt service routines, enabling and disabling interrupts@ >a.s.o.. All these parts are very architecture specific and need? >re-coding although they might be compilable at the first placel# >but the resulting code would fail.o  ? Yes.  That's why I said "a lot of the port" and not "the port."m   Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/p9 goathunter@goatley.com     http://www.goatley.com/hunter/    ------------------------------  % Date: Mon, 09 Jul 2001 23:54:16 +0200t) From: Christof Brass <brass@infopuls.com>p: Subject: Re: The death of VMS has been greatly exaggerated, Message-ID: <3B4A2808.FE03955D@infopuls.com>   "D.Webb" wrote:  > w > In article <fmx17.7103$G_1.714731@newsread2.prod.itd.earthlink.net>, "mulp" <michaelpettengill@earthlink.net> writes:M > > 9 > >"Main, Kerry" <Kerry.Main@compaq.com> wrote in message8O > >news:BE56C50EA024184DAF48F0B9A47F5CF4AD7EDA@kaoexc01.americas.cpqcorp.net...h > > K > >For example, I don't think that any of the people involved with vest areoH > >still around.  A lot of the product management folk who worked issuesH > >related to figuring out which products actually exist and are used byI > >customers to figuring out the 2-5-2 number that needs to go on the SSB  > >submit form are long gone.e > >A > >l > Q > Talking of VEST. Will there be a "VEST" for vested images. ie a utility to takemH > images which were vested onto Alpha and reconvert them to run on IA64.  = This isn't necessary. You can VEST the VAX images. While thish> requires two VEST programs it might much cleaner and easier to> re-write the existing VEST to be able to translate from VAX to
 IA63 also.  @ > Many users are still running Vested applications on Alpha VMS.R > I maybe wrong but I seem to recall that parts of Alpha VMS are still just vested	 > images.s >  > David Webb > VMS and Unix team leader > CCSS > Middlesex University   ------------------------------  % Date: Mon, 09 Jul 2001 23:29:57 -0400r2 From: rdeininger@mindspring.com (Robert Deininger): Subject: Re: The death of VMS has been greatly exaggeratedL Message-ID: <rdeininger-0907012329570001@user-2ivea5o.dialup.mindspring.com>  : In article <3B4A22DB.931ACE2@infopuls.com>, Christof Brass <brass@infopuls.com> wrote:A  F > > I guess that's good and bad news.  If they could port once by justL > > compiling, they can almost certainly port the module the same way again.2 > > That's good, since it leads to a quicker port. > 8 > The conclusion might not be correct. It depends on the= > architecture similarities. You can't burden all that to theI? > compiler. I doubt that most HW specific parts can be migratedt% > that way from Alpha or VAX to IA63.   J I was thinking of modules that have already been ported from VAX to alpha,J with only a recompile or maybe a bit more.  Such a module will likely portG again with no more effort.  Of course, there are other modules that aree0 completely hardware and architechture dependent.  = Note that VMS is already designed to isolate the worst of theyG hardware-dependent code.  On alpha, the console firmware covers up manymH differences.  Above that are the CPU routines, which try to provide evenE more uniformity for higher layers.  The port/class separation in manyoD device drivers is another advantage.  VMS was _designed_, not thrownG together over pizza and pepsi.  I'm sure one of the design goals was ton% limit the impact of hardware changes.o    v< > > The bad part is that they missed a chance to upgrade theN > > quality/maintainability of these modules, and will probably miss many such > > chances again this time. > @ > Good point. They should re-write whatever must be touched in a= > sound modern PL (not C/C++), e.g. Pascal or Ada or Modula-3  > which was developed by DEC.   H I belive the recent trend has been toward C, and away from Pascal, PL/1,I and Ada.  Mainly because C programmers are considerably easier to find, ISF guess.  It is possible to write quality code in C, but it is easier in some more modern languages.i  L > > On the other hand, if it ain't broke, don't fix it still applies.  Every? > > time someone tweeks a module, there's a chance to break it.  > < > Every time you migrate the new environment will unevitablyB > reveal hidden bugs. This means that you normally don't know what< > isn't broken until you run it within the new environment.   H I expect more manpower will go into testing VMS on IPF than writing it. I Huge chunks of the test machinery will be useable with little effort, butr' some of the rest will be a LOT of work.p   -- l Robert Deininger rdeininger@mindspring.como   ------------------------------  % Date: Mon, 09 Jul 2001 13:54:37 -0400-- From: "Richard D. Piccard" <piccard@ohio.edu>m# Subject: The Inquirer Strikes Againr( Message-ID: <3B49EFD4.F481C132@ohio.edu>  A See   http://www.theinquirer.net/08070106.htm  under the headline_  ! "Massive array of Capellas found"l   My favorite parts are:  H "Each cell of the seven by eight array is able to independently convince customers thatF moving to the Itanium platform beats the existing Alpha platform hands down.m  B One senior analyst said that, as it stood, the Capellas Array, the latest example of B Inspiration Technology, was only eight cells short of being a full Marvel."  #                                 RDPn --B ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  % Date: Mon, 09 Jul 2001 14:13:24 -0400t+ From: John Eisenschmidt <jeisensc@aaas.org>c' Subject: Re: The Inquirer Strikes Againg# Message-ID: <sb49bc15.075@aaas.org>h   That is really sick...<G>   I It's like he went to the Bill Gates school of business, except he's not =  Bill Gates.   I "By this time next year, everything will be running on iPaq. And I mean =cD everything - SQL Server 2000, Oracle, OpenVMS, Solaris, AIX, Pong, =D FreeCell, Lotus Notes, Exchange. So buy an iPaq and avoid the rush."  E >>> "Richard D. Piccard" <piccard@ohio.edu> 07/09/2001 1:54:37 PM >>>   A See   http://www.theinquirer.net/08070106.htm  under the headline,  ! "Massive array of Capellas found"r   My favorite parts are:  H "Each cell of the seven by eight array is able to independently convince customers thatF moving to the Itanium platform beats the existing Alpha platform hands down.w  B One senior analyst said that, as it stood, the Capellas Array, the latest example ofiB Inspiration Technology, was only eight cells short of being a full Marvel."  #                                 RDPo --L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DB Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  # Date: Mon, 09 Jul 2001 18:32:35 GMTu4 From: "Terry C. Shannon" <terryshannon@mediaone.net>' Subject: Re: The Inquirer Strikes Again88 Message-ID: <7Nm27.21$NF2.32172@typhoon.ne.mediaone.net>  8 "Richard D. Piccard" <piccard@ohio.edu> wrote in message" news:3B49EFD4.F481C132@ohio.edu... >eC > See   http://www.theinquirer.net/08070106.htm  under the headlinej > # > "Massive array of Capellas found"  >h > My favorite parts are: >dJ > "Each cell of the seven by eight array is able to independently convince > customers thatH > moving to the Itanium platform beats the existing Alpha platform hands > down.> >uD > One senior analyst said that, as it stood, the Capellas Array, the > latest example offD > Inspiration Technology, was only eight cells short of being a full
 > Marvel."  K Well, what it is that I said was a bit more tasteful than eight cards short  of a full DEC!   ------------------------------  $ Date: Mon, 9 Jul 2001 20:57:45 +0200, From: "Dave McDonald" <browser@acenet.co.za>E Subject: Re: VBN 397: Invalid bucket address sample in bucket header.c- Message-ID: <9icul7$m6d$1@ctb-nnrp2.saix.net>l  7 I've recovered RMS files with individual bucket errors. 1 You need to write a program, I did it in Fortran.uJ The basic principle is to open and read the file as a sequential file, and save the records in a new file. D Then use RMS utilities to build a new file with correct indexes etc.I You should be able to recover all the records except those in the corrupt  bucket.AI In the corrupt bucket you don't know if the records you think you can seeuH are current, or outdated records which have been deleted. So you have to% discard everything in the bad bucket.    YMMV, good luck.   Kind regards
 Dave McDonaldv
 Johannesburg.s    8 "Peter Weaver" <peter.weaver@stelco.ca> wrote in message. news:BLj27.261118$Z2.3120513@nnrp1.uunet.ca...D > We had a hard disk fail last week and recovered our latest backup.K > Unfortunately we had one file that had been updated since the last backupeL > and the user asked if we could grab it off of the failed drive. Since thenJ > we have had an invalid bucket in the file. The programmers have tried toL > recover the data, but are now asking me if I can help. Can anyone give any8 > thoughts on what we can do to recover this? (VAX V7.1) >M > $ANA/RMS PETER.BAD > .f > .O > .e > Key Segments: 1d > Key Size: 10 > Minimum Record Size: 10r5 > Index Fill Quantity: 4096, Data Fill Quantity: 4096y > Segment Positions: 0 > Segment Sizes: 10l > Data Type: strings
 > Name: "" > First Data Bucket VBN: 10 > > *** VBN 397: Invalid bucket address sample in bucket header.? > *** VBN 397: Invalid first free byte offset in bucket header.a8 > *** VBN 397: Next-bucket pointer out of range of file.7 > Unrecoverable error encountered in structure of file.y >r >s > -- > Peter WeaverL > Using a WIN NT/WIN 2000 box to manage your VMS systems is like towing your8 > mechanic in a 5th wheel motor home behind your Porche. >h >a   ------------------------------  $ Date: Mon, 9 Jul 2001 15:19:43 -0400- From: "Peter Weaver" <peter.weaver@stelco.ca>tE Subject: Re: VBN 397: Invalid bucket address sample in bucket header.e4 Message-ID: <ktn27.261179$Z2.3122718@nnrp1.uunet.ca>  7 "Dave McDonald" <browser@acenet.co.za> wrote in message-' news:9icul7$m6d$1@ctb-nnrp2.saix.net...u9 > I've recovered RMS files with individual bucket errors.s3 > You need to write a program, I did it in Fortran.yL > The basic principle is to open and read the file as a sequential file, and! > save the records in a new file.4F > Then use RMS utilities to build a new file with correct indexes etc.K > You should be able to recover all the records except those in the corrupte	 > bucket.wK > In the corrupt bucket you don't know if the records you think you can seehJ > are current, or outdated records which have been deleted. So you have to' > discard everything in the bad bucket.   C One of the people here is attacking it from that angle. I tried the I INDEXED_FILE_PATCH from Freeware V4. Once he is done with his try then wed9 will compare the results and see who has more valid data.   J Luckily the file only contains a history of what the mill is working on, aF record is entered for each item going through the mill then updated atH various times, so we don't have to worry about deleted records. The millJ that uses this file will be down tomorrow so we will combine the recoveredH file with the file the mill created today and hopefully have most of the
 data back.    $ run INDEXED_FILE_PATCH.EXE_VAX File name? peter.dat
 Start VBN?' Number of buckets between status lines?e3 *** VBN: 397  Address sample 0 ! Last valid VBN 379 %     Valid bucket 415  after 18 tries.n+ *** There were 84 Data buckets in the file.t1     12 Reads done. Last bucket VBNs are: 640  658o4 *** Template patch command file PATCH.COM generated. $ ty patch.com $ @patch    #   PATCH  Version 7.1    26-JUL-1995l  9 %PATCH-I-NOGBL, some or all global symbols not accessible 4 %PATCH-I-NOLCL, image does not contain local symbols old:    0002F408:  0000018De new:    0002F408:  0000019FtC %PATCH-I-OVERLAY, SYS$USERS3:[PWEAVER]PETER.DAT;1 being overwrittens   ------------------------------  $ Date: Mon, 9 Jul 2001 21:55:32 +0200, From: "Dave McDonald" <browser@acenet.co.za>E Subject: Re: VBN 397: Invalid bucket address sample in bucket header.D- Message-ID: <9id21i$6il$1@ctb-nnrp1.saix.net>   K If you're going to try my technique, you need to manually patch the corrupthB bucket out of the bucket chain, before the sequential read thingy. Forgot to mention that.eF If the bucket chain itself is corrupt, then you're buggered, I reckon.  
 Dave McDonaldn Johannesburg    8 "Peter Weaver" <peter.weaver@stelco.ca> wrote in message. news:ktn27.261179$Z2.3122718@nnrp1.uunet.ca...9 > "Dave McDonald" <browser@acenet.co.za> wrote in messagei) > news:9icul7$m6d$1@ctb-nnrp2.saix.net... ; > > I've recovered RMS files with individual bucket errors.n5 > > You need to write a program, I did it in Fortran.rJ > > The basic principle is to open and read the file as a sequential file, and7# > > save the records in a new file.sH > > Then use RMS utilities to build a new file with correct indexes etc.E > > You should be able to recover all the records except those in the  corruptr > > bucket.oI > > In the corrupt bucket you don't know if the records you think you cans see2L > > are current, or outdated records which have been deleted. So you have to) > > discard everything in the bad bucket.. > E > One of the people here is attacking it from that angle. I tried the K > INDEXED_FILE_PATCH from Freeware V4. Once he is done with his try then we ; > will compare the results and see who has more valid data.i > L > Luckily the file only contains a history of what the mill is working on, aH > record is entered for each item going through the mill then updated atJ > various times, so we don't have to worry about deleted records. The millL > that uses this file will be down tomorrow so we will combine the recoveredJ > file with the file the mill created today and hopefully have most of the > data back. > " > $ run INDEXED_FILE_PATCH.EXE_VAX > File name? peter.dat > Start VBN?) > Number of buckets between status lines?o5 > *** VBN: 397  Address sample 0 ! Last valid VBN 379n' >     Valid bucket 415  after 18 tries.c- > *** There were 84 Data buckets in the file.-3 >     12 Reads done. Last bucket VBNs are: 640  658i6 > *** Template patch command file PATCH.COM generated. > $ ty patch.com
 > $ @patch >t > % >   PATCH  Version 7.1    26-JUL-1995. >>; > %PATCH-I-NOGBL, some or all global symbols not accessibleu6 > %PATCH-I-NOLCL, image does not contain local symbols > old:    0002F408:  0000018Dm > new:    0002F408:  0000019FeE > %PATCH-I-OVERLAY, SYS$USERS3:[PWEAVER]PETER.DAT;1 being overwritten. >  >  >  >i   ------------------------------  $ Date: Mon, 9 Jul 2001 16:55:32 -05001 From: "Dave Gudewicz" <david.gudewicz@abbott.com>nH Subject: Re: VMS software/documentation product library (aka con dist) ?8 Message-ID: <9id99o$675$1@fizban.fizban.pprd.abbott.com>  G Discovered that our CDs landed in another building.  Luckily I know theaH person who claimed them.  This is a big place and things are easily gone with the wind.   Dave...B  1 "Scott Vieth" <svieth@wi.rr.com> wrote in message # news:3B466D29.9AE47C54@wi.rr.com...r > Dave:p >I > I'm pretty sure I got mine.- >-? > Maybe your copy got misplaced in the Abbott mail system?  ;^)r >  > -Scott in Milwaukee :^)t >G > Dave Gudewicz wrote: >dI > > Anyone here receive the June 2001 VMS software and documentation CDs?w > >cG > > My last was March 2001.  Did the distribution frequency change fromo > > quarterly? > >H > > Dave...  >t   ------------------------------  $ Date: Mon, 9 Jul 2001 14:16:41 -0400' From: "Bill Todd" <billtodd@foo.mv.com>eO Subject: Re: Wailing and moaning.... (was: Some thoughts on the recent turn...)a( Message-ID: <9ics6s$bia$1@pyrite.mv.net>  F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:bV4jlg$eNGl5@eisner.encompasserve.org...r   ...r  C > If there had been more people involve, there would have been morerC > leaks over a longer period of time, and this newsgroup would havem$ > had even more wailing and moaning.  J If there had been more people involved, there would have been a chance for some of them to say:  J 1.  This move is really stupid from a business viewpoint (it will kill ourJ enterprise business before there's any hope of substituting something else for it).  J 2.  This move unilaterally abrogates repeated commitments to customers (itK will severely damage our credibility as a vendor, regardless of how good itr may look to an accountant).E  F 3.  This move is based on dubious assumptions about relative technicalJ advance, and ignores the non-technical disadvantages of changing horses in mid-stream.s  J 4.  If even after all of the above you decide to make this move, talk withH customers beforehand and find out exactly what it will take to keep them happy.  L There was no need for secrecy here, save to maintain Alpha sales right up toI the day of the announcement.  It's not as if publicity would have queeredl( the deal:  it's not that kind of a deal.   - bill   ------------------------------  % Date: Mon, 09 Jul 2001 22:56:46 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)O Subject: Re: Wailing and moaning.... (was: Some thoughts on the recent turn...)lL Message-ID: <rdeininger-0907012256480001@user-2ivea5o.dialup.mindspring.com>  G In article <P7g27.5667$gb6.1033729@news20.bellglobal.com>, "Neil Rieck"  <n.rieck@sympatico.ca> wrote:i    J > Nope. I suspect that execs at GM have more technical understanding aboutL > their own products than these guys have about any computer products. (Hey,M > both architectures have registers and use electricity; what's the problem?)a  J I suspect you are correct.  It's probably a fundamental difference between+ the computer business and the car business.-   -- - Robert Deininger rdeininger@mindspring.com5   ------------------------------  % Date: Mon, 09 Jul 2001 22:55:11 -0400T2 From: rdeininger@mindspring.com (Robert Deininger), Subject: Re: What about performance issues??L Message-ID: <rdeininger-0907012255110001@user-2ivea5o.dialup.mindspring.com>  = In article <cb85fed2.0107090052.2fcf4676@posting.google.com>, ) kparris@my-deja.com (Keith Parris) wrote:u    D > Over the last 2-4 years, it appears we were having more difficulty@ > with locking being a bottleneck than the actual I/O operationsH > themselves.  Elinor Woods has done some excellent work lately (7.2-1H1F > and later) in RMS in reducing lock rates required for RMS files with7 > global buffers, and reducing lock contention as well.l  D Do check out the new features in VMS 7.3.  One new possibility is toF dedicate a single CPU to do all the lock management in an SMP system. F (New Features Manual, section 4.4)  The rule of thumb in the manual isG that you may do better dedicating a CPU in a system with 5 or more CPUse" and MP_SYNCH cpu usage above 200%.   -- e Robert Deininger rdeininger@mindspring.comn   ------------------------------  % Date: Tue, 10 Jul 2001 03:08:47 -0000b0 From: Timothy Stark <sword7@grace.speakeasy.net>. Subject: What happened to Charon-VAX Hobbyist?/ Message-ID: <tkksdvleehu16f@corp.supernews.com>    Hello folks:  G What happened to Charon-VAX Hobbyist Edition?  Today I checked its web eG site but it said that it should be back before the summer.  The summer   already is here.  
 Thank you.   -- Tim Stark   -- u, Timothy Stark	<><	Inet: sword7@speakeasy.orgJ --------------------------------------------------------------------------F "For God so loved the world, that he gave his only begotten Son, that H whosoever believeth in him should not perish, but have everlasting life.. Amen." -- John 3:16 (King James Version Bible)   ------------------------------  # Date: Tue, 10 Jul 2001 03:31:14 GMTC4 From: "Terry C. Shannon" <terryshannon@mediaone.net>2 Subject: Re: What happened to Charon-VAX Hobbyist?: Message-ID: <6Gu27.624$LH4.428546@typhoon.ne.mediaone.net>  = "Timothy Stark" <sword7@grace.speakeasy.net> wrote in message ) news:tkksdvleehu16f@corp.supernews.com...  > Hello folks: > H > What happened to Charon-VAX Hobbyist Edition?  Today I checked its webH > site but it said that it should be back before the summer.  The summer > already is here.  K I talked to the SRI folks over in Zurich last May... they did say they were E gonna pull the hobbyist version for a while as they are working on anaK upgrade. The owner of company told me "sometime this summer" but didn't setl a date certain.r   ------------------------------  # Date: Mon, 09 Jul 2001 19:21:26 GMTo- From: goathunter@goatley.com (Hunter Goatley)D2 Subject: Re: Writing to OPA0: from a device driver/ Message-ID: <3b4a03e5.7733620@news.process.com>o  4 On Mon, 9 Jul 2001 12:32:43 -0400, "Fred Kleinsorge"$ <kleinsorge@star.zko.dec.com> wrote:  M >Use the broadcast call if you are at a low enough IPL.  Reserve the high-IPLg= >CON$ stuff for truly CRITICAL system messages, or debugging.i  I Definitely.  I would never use the CON$ stuff for anything but debugging.    >ALSO note thats9 >you should be on the PRIMARY CPU to make the CON$ calls.p >o Good point.  Thanks.   Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/ 9 goathunter@goatley.com     http://www.goatley.com/hunter/=   ------------------------------  % Date: Mon, 09 Jul 2001 20:10:19 +0200a+ From: Richard Levitte <levitte@openssl.org> " Subject: [ANNOUNCE] OpenSSL 0.9.6b/ Message-ID: <20010709201018.A29837@openssl.org>   !   OpenSSL version 0.9.6a released-B   =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  /   OpenSSL - The Open Source toolkit for SSL/TLSi   http://www.openssl.org/7  F   The OpenSSL project team is pleased to announce the release of vers= ioneF   0.9.6a of our open source toolkit for SSL/TLS.  This new OpenSSL ve= rsionaF   is mostly a bugfix release and incorporates at least 55 changes to = the F   toolkit (for a complete list see http://www.openssl.org/source/exp/=	 CHANGES).u  #   The most significant changes are:R  (       o Security fix: PRNG improvements.%       o Security fix: RSA OAEP check.wF       o Security fix: Reinsert and fix countermeasure to Bleichbacher= 's         attack.y       o MIPS bug fix in BIGNUM.l!       o Bug fix in "openssl enc".e*       o Bug fix in X.509 printing routine.F       o Bug fix in DSA verification routine and DSA S/MIME verificati= on.w)       o Bug fix to make PRNG thread-safe.o$       o Bug fix in RAND_file_name().5       o Bug fix in compatibility mode trust settings.s        o Bug fix in blowfish EVP.7       o Increase default size for BIO buffering filter.=,       o Compatibility fixes in some scripts.  F   We consider OpenSSL 0.9.6a to be the best version of OpenSSL availa=
 ble and weF   strongly recommend that users of older versions, especially of old = SSLeayF   versions, upgrade as soon as possible.  OpenSSL 0.9.6a is available=  forF   download via HTTP and FTP from the following master locations (you = can findF   the various FTP mirrors under http://www.openssl.org/source/mirror.= html):  $     o http://www.openssl.org/source/#     o ftp://ftp.openssl.org/source/:  ?   [1] OpenSSL comes in the form of two distributions this time.yF   The reasons for this is that we want to deploy the external crypto = deviceF   support but don't want to have it part of the "normal" distribution=  just0F   yet.  The distribution containing the external crypto device suppor= t isF   popularly called "engine", and is considered experimental.  It's be= enF   fairly well tested on Unix and flavors thereof.  If run on a system=  withoF   no external crypto device, it will work just like the "normal" dist=	 ribution.   "   The distribution file names are:  &       o openssl-0.9.6a.tar.gz [normal]-       o openssl-engine-0.9.6a.tar.gz [engine]      Yours,!   The OpenSSL Project Team... =20a  <     Mark J. Cox             Richard Levitte    Andy Polyakov<     Ralf S. Engelschall     Bodo M=F6ller        Holger Reif=     Dr. Stephen Henson      Ulf M=F6ller         Geoff Thorpeu3     Ben Laurie              Lutz J=E4nicke      =20b   ------------------------------  % Date: Mon, 09 Jul 2001 20:42:20 +0200v+ From: Richard Levitte <levitte@openssl.org> " Subject: [ANNOUNCE] OpenSSL 0.9.6b. Message-ID: <20010709204216.A2010@openssl.org>  L As a few people noticed, not only was the announcement of OpenSSL 0.9.6b se= ntK more than once (due to, eh, technical error...), but the version number wasb& 0.9.6a everywhere in the message body!  9 So, with my deepest appologies, here is the correct text:o  L =00=06=D8Z=00=0C=00=01.=00=00=00=00=08-=05=00=0C=00=02..=00=00=00=06=D8b=00=K =10=00=06README=00=00=00=06=D8i=00=0C=00=03arc=00=00=06=D8s=00=0C=00=03bin=tL =00=00=06=D8t=00=0C=00=03tmp=00=00=06=AB_=00=0C=00=03web=00=00=06=D8x=00=14=L =00=0B.bash_login=00=00=06=D8y=00=10=00=07.bashrc=00=00=06=D8z=00=10=00=07.=L muttrc=00=00=06=D8{=00=18=00=0F.muttrc.aliases=00=00=06=D8|=00=18=00=0D.pro=I cmail.log=00=00=00=00=06=D8}=00=14=00=0B.procmailrc=00=00=06=D8~=00=14=00c =2Esignature=00=00=00=06=DA L =00=14=00=08.viminfo=00=00=00=00=00=06=D8=80=00=10=00=06.vimrc=00=00=00=00s=K =08=00=10=00=04work=00=00=00=00=00=06=D8=82=00=18=00=0D.bash_history=00=00=hL =00=00=06=D8=83=00=10=00=04.ssh=00=00=00=00=00=06=D9=E0=00=1C=00=11.muttrc.=K postponed=00=00=00=00=06=D9=C3=00=14=00=0Bpublic_html=00=00=06=D9=D3=00=10= L =00=07pod2man=00=00=04D1=00=10=00=07perlpod=00=00=06=DA=1A=00=10=00=07bnbug=K c=00=00=06=DA@=00 =00=16OpenSSL.beta2.announce=00=00=00=02#=0F=00=10=00=07=  CVSRoot=00=00=06=DA=E7=00=14=00:K Octbio.tgz=00=00=00=05=83=89=00=1C=00=05work2=00=00=00.tmp=00=00=00=00f=00=cL =00=00=00=06=D87=00=0C=00=03foo=00=00=06=D8T=00=1C=00=10openssl-web.diff=00=L =00=00=00=00=06=D8=8E=00=18=00=0Fopenssl-web.tar=00=00=06=D9?=00$=00=1Bopen=L ssl-0.9.6a-beta1.tar.gz=00=00=06=D9=A6=00(=00=1Fopenssl-0.9.6a-beta1.tar.gz=I md5=00=00=06=D9=A8=00,=00"openssl-engine-0.9.6a-beta1.tar.gz=00=00=00=06= J =D9=A9=000=00&openssl-engine-0.9.6a-beta1.tar.gz.md5=00=00=00=06=D9=DD=00=K =10=00=04NEWS=00=00=00=00=00=06=DA=06=00=1C=00=10OpenSSL-arch.zip=00=00=00=4 =00=00=06=DA=07=00=14=00L root.saved=00=00=00=06=D9N=00=D8=00=0DNEWS-diff.txt=00=00=00=00=00=00=00=00=K =C0=00=0C.viminfo.tmp=00=00=00=00=00=00=00=00=00=A8=00=0E.procmail.lock=00=DL =00.muttrc.postponed.lock=00=00ck=00=00=00=00=00=00=00=00=00=00=00=00=00=00=L =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=L =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=L =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=L =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00!   OpenSSL version 0.9.6b releasedeK   =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=o =3D=3D=3D=3D=3D=3D=3D   /   OpenSSL - The Open Source toolkit for SSL/TLSr   http://www.openssl.org/t  H   The OpenSSL project team is pleased to announce the release of versionJ   0.9.6b of our open source toolkit for SSL/TLS.  This new OpenSSL versionH   is mostly a bugfix release and incorporates at least 55 changes to theL   toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGE= S).o  #   The most significant changes are:e  (       o Security fix: PRNG improvements.%       o Security fix: RSA OAEP check.,G       o Security fix: Reinsert and fix countermeasure to Bleichbacher'ss         attack.n       o MIPS bug fix in BIGNUM.r!       o Bug fix in "openssl enc".l*       o Bug fix in X.509 printing routine.H       o Bug fix in DSA verification routine and DSA S/MIME verification.)       o Bug fix to make PRNG thread-safe.s$       o Bug fix in RAND_file_name().5       o Bug fix in compatibility mode trust settings.8        o Bug fix in blowfish EVP.7       o Increase default size for BIO buffering filter. ,       o Compatibility fixes in some scripts.  L   We consider OpenSSL 0.9.6b to be the best version of OpenSSL available an= d weK   strongly recommend that users of older versions, especially of old SSLeayNI   versions, upgrade as soon as possible.  OpenSSL 0.9.6b is available foreL   download via HTTP and FTP from the following master locations (you can fi= ndK   the various FTP mirrors under http://www.openssl.org/source/mirror.html):5  $     o http://www.openssl.org/source/#     o ftp://ftp.openssl.org/source/7  ?   [1] OpenSSL comes in the form of two distributions this time.dK   The reasons for this is that we want to deploy the external crypto deviceeJ   support but don't want to have it part of the "normal" distribution justI   yet.  The distribution containing the external crypto device support iseG   popularly called "engine", and is considered experimental.  It's beensJ   fairly well tested on Unix and flavors thereof.  If run on a system withL   no external crypto device, it will work just like the "normal" distributi= on.o  "   The distribution file names are:  &       o openssl-0.9.6b.tar.gz [normal]-       o openssl-engine-0.9.6b.tar.gz [engine]o     Yours,!   The OpenSSL Project Team... =20r  <     Mark J. Cox             Richard Levitte    Andy Polyakov<     Ralf S. Engelschall     Bodo M=F6ller        Holger Reif=     Dr. Stephen Henson      Ulf M=F6ller         Geoff Thorpe 3     Ben Laurie              Lutz J=E4nicke      =20d   ------------------------------  % Date: Mon, 09 Jul 2001 21:10:48 +0200o+ From: Richard Levitte <levitte@openssl.org>s" Subject: [ANNOUNCE] OpenSSL 0.9.6b. Message-ID: <20010709211046.A3889@openssl.org>  F As a few people noticed, not only was the announcement of OpenSSL 0.9= 6b sentkF more than once (due to, eh, technical error...), but the version numb= er was& 0.9.6a everywhere in the message body!  9 So, with my deepest appologies, here is the correct text:     !   OpenSSL version 0.9.6b releasedoB   =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  /   OpenSSL - The Open Source toolkit for SSL/TLSr   http://www.openssl.org/h  F   The OpenSSL project team is pleased to announce the release of vers= ionvF   0.9.6b of our open source toolkit for SSL/TLS.  This new OpenSSL ve= rsioneF   is mostly a bugfix release and incorporates at least 55 changes to = thetF   toolkit (for a complete list see http://www.openssl.org/source/exp/=	 CHANGES).   #   The most significant changes are:a  (       o Security fix: PRNG improvements.%       o Security fix: RSA OAEP check. F       o Security fix: Reinsert and fix countermeasure to Bleichbacher= 's         attack.O       o MIPS bug fix in BIGNUM. !       o Bug fix in "openssl enc".n*       o Bug fix in X.509 printing routine.F       o Bug fix in DSA verification routine and DSA S/MIME verificati= on.c)       o Bug fix to make PRNG thread-safe.0$       o Bug fix in RAND_file_name().5       o Bug fix in compatibility mode trust settings.         o Bug fix in blowfish EVP.7       o Increase default size for BIO buffering filter.0,       o Compatibility fixes in some scripts.  F   We consider OpenSSL 0.9.6b to be the best version of OpenSSL availa=
 ble and weF   strongly recommend that users of older versions, especially of old = SSLeayF   versions, upgrade as soon as possible.  OpenSSL 0.9.6b is available=  forF   download via HTTP and FTP from the following master locations (you = can findF   the various FTP mirrors under http://www.openssl.org/source/mirror.= html):  $     o http://www.openssl.org/source/#     o ftp://ftp.openssl.org/source/   ?   [1] OpenSSL comes in the form of two distributions this time.oF   The reasons for this is that we want to deploy the external crypto = deviceF   support but don't want to have it part of the "normal" distribution=  just0F   yet.  The distribution containing the external crypto device suppor= t isF   popularly called "engine", and is considered experimental.  It's be= enF   fairly well tested on Unix and flavors thereof.  If run on a system=  withaF   no external crypto device, it will work just like the "normal" dist=	 ribution.i  "   The distribution file names are:  &       o openssl-0.9.6b.tar.gz [normal]-       o openssl-engine-0.9.6b.tar.gz [engine]g     Yours,!   The OpenSSL Project Team... =20   <     Mark J. Cox             Richard Levitte    Andy Polyakov<     Ralf S. Engelschall     Bodo M=F6ller        Holger Reif=     Dr. Stephen Henson      Ulf M=F6ller         Geoff Thorpeh3     Ben Laurie              Lutz J=E4nicke      =20:   ------------------------------   End of INFO-VAX 2001.379 ************************