1 INFO-VAX	Thu, 04 Jul 2002	Volume 2002 : Issue 365       Contents:8 Accessing the DCL recall buffer in a command procedure ?< Re: Accessing the DCL recall buffer in a command procedure ?' Re: Andrew wan'ts the numbers, here ... ' Re: Andrew wan'ts the numbers, here ... 8 Apache worm: only a UNIX security whole or also OpenVMS?< Re: Apache worm: only a UNIX security whole or also OpenVMS?@ Re: Deutsche Bank would like to outsource there IT to IBM or CSC@ Re: Deutsche Bank would like to outsource there IT to IBM or CSC@ Re: Deutsche Bank would like to outsource there IT to IBM or CSC@ Re: Deutsche Bank would like to outsource there IT to IBM or CSC@ Re: Deutsche Bank would like to outsource there IT to IBM or CSC$ Re: Fearless IPF Prognostications...$ Re: Fearless IPF Prognostications...$ Re: Fearless IPF Prognostications...$ Re: Fearless IPF Prognostications...$ Re: Fearless IPF Prognostications...$ Re: Fearless IPF Prognostications...$ Re: Fearless IPF Prognostications...$ Re: Fearless IPF Prognostications...$ Re: Fearless IPF Prognostications... Re: Last 3 weeks on c.o.v. new emacs 21! Re: postscript print from vms 5.4 + Re: Three HP Press releases (via Bloomberg)  Re: VMS 64bitness  Re: VMS 64bitness & Re: Windows 2000 -> Linux Samba -> VMS& Re: Windows 2000 -> Linux Samba -> VMS& Re: Windows 2000 -> Linux Samba -> VMS& Re: Windows 2000 -> Linux Samba -> VMS& Re: Windows 2000 -> Linux Samba -> VMS Re: wow  Re: wow  Re: [OT] AS/400 Success Story   F ----------------------------------------------------------------------   Date: 4 Jul 2002 06:14:30 -0600 B From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley)A Subject: Accessing the DCL recall buffer in a command procedure ? 3 Message-ID: <sU+rjv5suLsW@eisner.encompasserve.org>   G How do I get access to the DCL recall buffer from a command procedure ?   J I want to be able to read the commands in the buffer, manipulate them, and0 add any modified ones back to the recall buffer.  I The obvious answer, RECALL/OUT and RECALL/IN, doesn't appear to work in a M command procedure (which raises the question of how _do_ people automatically D save and restore command history when logging out and logging in ?).   Thanks for any information,    Simon.   --  B Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP       + Microsoft: The Lada of the computing world.    ------------------------------  % Date: Thu, 04 Jul 2002 13:23:09 +0200 9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> E Subject: Re: Accessing the DCL recall buffer in a command procedure ? ' Message-ID: <3D24301D.3B9E8CD5@aaa.com>   $ Check Hunter's freeware archive on :, "http://www.process.com/openvms/index.html".  7 There is a tool called GETCMD that can fetch the recall 7 buffer from any interative process on the local system.   " $ GETCMD <pid>  [/OUTPUT=filename]  = Havn't tried it myself, just remebered I had seen it there...    Jan-Erik Sderholm.      Simon Clubley wrote: > I > How do I get access to the DCL recall buffer from a command procedure ?  >    ------------------------------  . Date: Thu, 4 Jul 2002 10:03:36 +0200 (MET DST)& From: Rudolf Wingert <win@fom.fgan.de>0 Subject: Re: Andrew wan'ts the numbers, here ...6 Message-ID: <200207040803.KAA00688@sinet1.fom.fgan.de>   Hello,   Andrew wrotes:   >>> 8 As you yourself have pointed out the ES40 server is more6 expensive, the list price for a ES40 model 1 server is; 40,000 dollars more in a similar config to the workstation.  <<<   A I don't know from which site you get your prices. But in our case H we did ask also for the server price. It did cost only about 10.000,00DMD (~5000,00US$) more. Should we sold 5000$ for nothing? The differenceA between the server and the station, is that the station have less = licenses (e.g. no PathWorks) and that the station will have a ? graphic adapter. The rest is the same. If Sun also sold an four B processor workstation, sorry we did not know it and the seller did not say it. @ I did verify the clockrate of CPU and did see, that I did mix up? it with the our DS20. The ES40 will have four CPUs with 667MHz.    >>> 8 In addition the V880 is more expandible it can currently6 support 8 CPU's and 32 GB or RAM, you should expext to9 pay a bit more for this, your model 1 has fewer PCI slots  and supports less memory.  <<<   C That's right. But I did compare the price of two host with the same E configuration. With eight CPUs and 32GB memory, the SunFire V880 will @ be more expensicve as you reported. We did pay 110.000,00US$ forE our configuration. For your configuration we have to pay 220.000,00$.    >>> 5 And finally the fact that you created a 10 GB file on 5 a machine with 16 GB of memory and copied it, and did 5 the same on a machine with 8 GB of memory should have 2 rung alarm bells with you in terms of the validity of the benchmark.  <<<   J Andrew you missunderstood once more, what I did write! I did create a 10GBG file (not within memory) and did copy them as normal user with a WS_MAX G of 500MB. If I would add LVD host adpater and 180 GB disk to the Sun, I I think that I will not see any performance difference. The I/O bandwith of 7 both system are big enaugh. The bottleneck is the disk.    Regards Rudolf Wingert   ------------------------------    Date: 04 Jul 2002 17:30:20 +0800, From: Paul Repacholi <prep@prep.synonet.com>0 Subject: Re: Andrew wan'ts the numbers, here ...- Message-ID: <87bs9nzvpv.fsf@prep.synonet.com>   3 bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:   E > But if you don't put `GenUine COmpaq' simms into it will it in fact > > be certified??  Wouldn't non-`GenUine COmpaq' anything causeD > problems getting maintenance if you have a problem later??  If so,( > then those prices are even more legit.  F Ask the if they want the business or not. If not, then they know where the door is.  D It is a wonder how their attitude changes if they have walk from allC that lovley income. (and explain up the food-chain why the comtract  was not reneued.)    --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  . Date: Thu, 4 Jul 2002 09:25:19 +0200 (MET DST)& From: Rudolf Wingert <win@fom.fgan.de>A Subject: Apache worm: only a UNIX security whole or also OpenVMS? 6 Message-ID: <200207040725.JAA00607@sinet1.fom.fgan.de>   Hello,  D today I did red, that there is an Apache Worm around the Unix world.E Will this be a problem also for the OpenVMS OS. Or is the Apache CSWS  protected against this worm?   TIA and regards Rudolf Wingert   ------------------------------  % Date: Thu, 04 Jul 2002 10:20:45 -0400 1 From: Michael Austin <maustin@firstdbasource.com> E Subject: Re: Apache worm: only a UNIX security whole or also OpenVMS? 2 Message-ID: <3D2459BD.E7E9094B@firstdbasource.com>   Rudolf Wingert wrote:  >  > Hello, > F > today I did red, that there is an Apache Worm around the Unix world.G > Will this be a problem also for the OpenVMS OS. Or is the Apache CSWS  > protected against this worm? >   > TIA and regards Rudolf Wingert   asked and answered:   L >http://www.openvms.compaq.com/openvms/products/ips/apache/csws_patches.html --   Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163 7 Sr. Consultant            http://www.firstdbasource.com                            + http://www.firstdbasource.com/donation.html / 704-947-1089 (Office)     704-236-4377 (Mobile)    ------------------------------   Date: 4 Jul 2002 02:10:45 -0600 + From: young_r@encompasserve.org (Rob Young) I Subject: Re: Deutsche Bank would like to outsource there IT to IBM or CSC 3 Message-ID: <hhgiiFjbEiUo@eisner.encompasserve.org>   p In article <CdMU8.261480$_j6.13024545@bin3.nnrp.aus1.giganews.com>, "Bill Todd" <billtodd@metrocast.net> writes: > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:51S1zADmHG$N@eisner.encompasserve.org...  >  > ...  > 5 >> Last I checked Power4 and UltraSparc had far fewer - >> OSes to offer and far fewer manufacturers.  > L > Looks as if it may be time for another in the increasingly-frequent series< > of reality checks w.r.t. comments made by Itanic boosters.  ? 	By the way, how do you like those SpecInt numbers?  Seems time 1 	to back pedal... Oh, let's pick a random thread:   Z http://groups.google.com/groups?selm=6ivYvkH5dCqr%40eisner.encompasserve.org&output=gplain  O In article <tv3na9bl0vcab3@corp.supernews.com>, Keith Brown <kbrown780@isd.net>  writes:  > Bill Todd wrote: >>  L >> Still, 1.6 x Merced's 314 SPECint2K Dell number (the only one at the SPECL >> site running 64-bit code, since the HP 358 number was reportedly obtainedL >> using an ILP32 compiler) is only about 502, which isn't competitive today >> let alone next year.  >>  E >>> (And still some fifty percent slower than an Alpha from 2001....) I >>> Will McKinley and Madison come after their successors? (I thought McK G >>> was scheduled for ~mid 2002, how can systems of their successors be 
 >>> available  >>> at that date?? >>    < 	That number is too low.  Paul DeMone talks about 2.5 Merced  	(according to Intel I suppose):  M http://www.realworldtech.com/page.cfm?section=columns&AID=RWT071901001629&p=4   O "Unofficial sources even suggest the McKinley will demonstrate 2.5x the integer K performance and 2.0x the FP performance of Itanium as measured by SPEC2k."	   @ 	Which would make it fairly respectable for SpecInt and the partF 	to beat for FP.  Maybe we can talk about cost for a while and compare? 	that to others.  Total system cost and respectable performance < 	are the keys to Itanium taking off.  Yes... Merced is Dead,< 	McKinley isn't and Itanium finally gets something next year
 	sometime.  i http://groups.google.com/groups?selm=2uBI7.21964%24jp.1553835%40bin2.nnrp.aus1.giganews.com&output=gplain      ...    > That number is too low.   - No, it's not:  you're just a bit out of date.   G 	Actually, that 502 calculation of yours wasn't even close.  More than   	760 SpecInt2000.   C > your comment [about OS numbers] was phrased in the present tense.    	Okay.   				Rob    ------------------------------  % Date: Thu, 04 Jul 2002 03:43:16 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> I Subject: Re: Deutsche Bank would like to outsource there IT to IBM or CSC , Message-ID: <3D23FC90.4442DDCA@videotron.ca>   Rob Young wrote:E >         are the keys to Itanium taking off.  Yes... Merced is Dead, E >         McKinley isn't and Itanium finally gets something next year  >         sometime.   I What do you mean by "Itanium finally gets something next year sometime" ?   N I thought that the next IA64 was to be McKinley, released sometime in 2002 andJ which would be an improvement over Merced and after that it would be untilN 2004-2005 when Intel expects the successor to McKinley which would essentially be a process shrink ?   < What is this weeks's expected/speculated release timetable ?  N Do you agree that once HP allows EV7 out, that the released McKinley will loseN whatever claims it would have been to make during the time between its release and the release of EV7 ?  N Unless HP purposefully slows down EV7, it will make Ia64 look pretty pathetic.L Once can understand Merced being a flop, but there is no real excuse for theK second iteration not being industry leading. And even if you take out Alpha K because it has been murdered, IA64 has yet to beat the 8086. (Especially if  Hammer does materialize).    ------------------------------  # Date: Thu, 04 Jul 2002 10:09:23 GMT * From: "Bill Todd" <billtodd@metrocast.net>I Subject: Re: Deutsche Bank would like to outsource there IT to IBM or CSC B Message-ID: <n9VU8.547324$%y.36188471@bin4.nnrp.aus1.giganews.com>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:hhgiiFjbEiUo@eisner.encompasserve.org... K > In article <CdMU8.261480$_j6.13024545@bin3.nnrp.aus1.giganews.com>, "Bill & Todd" <billtodd@metrocast.net> writes: > > < > > "Rob Young" <young_r@encompasserve.org> wrote in message1 > > news:51S1zADmHG$N@eisner.encompasserve.org...  > >  > > ...  > > 7 > >> Last I checked Power4 and UltraSparc had far fewer / > >> OSes to offer and far fewer manufacturers.  > > G > > Looks as if it may be time for another in the increasingly-frequent  series> > > of reality checks w.r.t. comments made by Itanic boosters. > 4 > By the way, how do you like those SpecInt numbers?  J And you accuse *Andrew* of changing the subject whenever things get tight?     Seems time > to back pedal...  K Not really.  If and when an actual spec.org-legal measurement comes up with H the 760+ SPECint2K number for Itanic2 that I assume you're referring to,I then I'll cheerfully admit that my estimate of 600 - 700 was (even on the K high side) about 10% too low (as was Paul DeMone's of 700).  However, since L that same slide quotes Itanic1 at 400 (a number not yet seen at spec.org forG that processor, despite Intel's claims for the past year-plus), I'm not H placing any bets yet that Itanic2 will meet that claim any more closely:J e.g., should Itanic2 miss, say, hitting 765 by the same amount Itanic1 hasK so far missed the claimed 400 mark, then it'll come in at about 725 - still ? slightly above my high-end estimate, but not embarrassingly so.   J Unfortunately, since Intel is still reluctant to take the public wraps offJ its NDAs regarding McKinley, we're still stuck in 'if and when' hypothesesL as to what its SPECint (or any other relevant benchmark) performance may be.     Oh, let's pick a random thread: >  > L http://groups.google.com/groups?selm=6ivYvkH5dCqr%40eisner.encompasserve.org &output=gplain > = > In article <tv3na9bl0vcab3@corp.supernews.com>, Keith Brown  <kbrown780@isd.net> 	 > writes:  > > Bill Todd wrote: > >>I > >> Still, 1.6 x Merced's 314 SPECint2K Dell number (the only one at the  SPECE > >> site running 64-bit code, since the HP 358 number was reportedly  obtainedH > >> using an ILP32 compiler) is only about 502, which isn't competitive today  > >> let alone next year.   I Now, *this* was back when all we had to work with were Intel's statements H that McKinley's performance would be 1.5 - 1.7x that of Merced, which isI exactly what I reported above.  If and when Dell decides that McKinley is L worth shipping we'll see whether that ratio pans out for a Dell box - thoughC if it doesn't, I suggest you blame Intel rather than the messenger.    > >>G > >>> (And still some fifty percent slower than an Alpha from 2001....) K > >>> Will McKinley and Madison come after their successors? (I thought McK I > >>> was scheduled for ~mid 2002, how can systems of their successors be  > >>> available  > >>> at that date?? > >> > = > That number is too low.  Paul DeMone talks about 2.5 Merced ! > (according to Intel I suppose):  >  > L http://www.realworldtech.com/page.cfm?section=columns&AID=RWT071901001629&p= 4  > I > "Unofficial sources even suggest the McKinley will demonstrate 2.5x the  integer L > performance and 2.0x the FP performance of Itanium as measured by SPEC2k."  K Why not quote the preceding sentence as well?  "Intel has said that it will L run in excess of 1 GHz and offer at least twice the performance of Itanium."I And why not refer to the chart just below that indicating a clock rate of F 1.2 GHz?  Since neither of those seems to be panning out (according toK consistent recent Intel statements that the chip will ship in 1 GHz and 900 K MHz variations), one might suspect the leaked performance information to be  similarly overinflated.    > A > Which would make it fairly respectable for SpecInt and the part G > to beat for FP.  Maybe we can talk about cost for a while and compare  > that to others.   G Although it's changing the subject once again, perhaps we should:  IIRC H Intel has recently stated that the 900 MHz part with half the cache willL list at about $1200, while the 1 GHz part with full cache will list at aboutI $4200.  IIRC Dell marked up similar prices for the high-end Merced around J 50% for add-on processors in its boxes, which left the boxes with no price@ advantage over the RISC competition (and far lower performance).  /   Total system cost and respectable performancet% > are the keys to Itanium taking off.i  L Total McKinley system cost appears headed in the same direction Merced's wasF if processor pricing is any indication:  no advantage there.  McKinleyG performance will certainly be far better than Merced's but so far stilleJ shows no likelihood of blowing away the RISC server competition and has noJ subsequent kicker except for shrinks until the Magickal Elixir that peopleI like you are counting on the Alpha team to infuse in the 2005 - 2007 timetK frame, unlike said RISC competition which - except for Alpha, but includingtC both PA-RISC and MIPS as well as POWER and US - has significant and L *specific* core-design improvments (as well as process-shrinks comparable to9 Itanic's) and/or multi-core dice planned for 2003 - 2004.f     Yes... Merced is Dead,= > McKinley isn't and Itanium finally gets something next year  > sometime.u  E Most of what Itanic gets it gets this month (unless Itanic2 slips yet J again):  Intel has stated consistently (well, at least for the past coupleG of years - far earlier a third core design was reportedly planned) thateJ Madison/Deerfield are based on the McKinley core, just shrunk and with (atL least for the former) more cache, and more recently has said Montecito is asK well.  Deerfield was planned to cost less IIRC - we'll see when it arrives.u   >k >tL http://groups.google.com/groups?selm=2uBI7.21964%24jp.1553835%40bin2.nnrp.au s1.giganews.com&output=gplainc >a >  > ...o >h > > That number is too low.e >c/ > No, it's not:  you're just a bit out of date.n >fG > Actually, that 502 calculation of yours wasn't even close.  More thant > 760 SpecInt2000.  H If/when Itanic2 actually ships, then well see which of Intel's leaks wasF wrong; I suspect both will turn out to be, and that the truth will lieD somewhere in the middle.  If said truth should exceed 700, then I'llF cheerfully admit to guessing a bit low - though will remind you if theI actual figure is still considerably lower than POWER4's (839) and the newtF Alpha 1.24 GHz (a core more than half a decade older than McKinley andI recently estimated to come in at 850), let alone EV7 (more like 1000 withoI the same aging core), and only comparable to the new 875 MHz PA-RISC 8700oI (which should come in at around 700 if it's anything like linear in clock L speed) and the new USIII flavor (IIRC they're scheduled to release somethingL soon, but I've forgotten details that might suggest what performance bump it
 might yield).d   > E > > your comment [about OS numbers] was phrased in the present tense.u >  > Okay.n  D If that's the extent of your comment on the post you were supposedlyG responding to, starting a new thread on the other topics you introduced ' above would have been more appropriate.l   - bill   ------------------------------   Date: 4 Jul 2002 10:49:11 GMTp( From: nmm1@cus.cam.ac.uk (Nick Maclaren)I Subject: Re: Deutsche Bank would like to outsource there IT to IBM or CSCe0 Message-ID: <ag1977$onj$1@pegasus.csx.cam.ac.uk>  B In article <n9VU8.547324$%y.36188471@bin4.nnrp.aus1.giganews.com>,, "Bill Todd" <billtodd@metrocast.net> writes: |>  N |> Not really.  If and when an actual spec.org-legal measurement comes up withK |> the 760+ SPECint2K number for Itanic2 that I assume you're referring to,tL |> then I'll cheerfully admit that my estimate of 600 - 700 was (even on theN |> high side) about 10% too low (as was Paul DeMone's of 700).  However, sinceO |> that same slide quotes Itanic1 at 400 (a number not yet seen at spec.org for J |> that processor, despite Intel's claims for the past year-plus), I'm notK |> placing any bets yet that Itanic2 will meet that claim any more closely:uM |> e.g., should Itanic2 miss, say, hitting 765 by the same amount Itanic1 hasmN |> so far missed the claimed 400 mark, then it'll come in at about 725 - stillB |> slightly above my high-end estimate, but not embarrassingly so.  @ Or 600 with Intel's compiler :-)  Actually, I have heard that it? has improved considerably since Dell's figure was published, so> I am being a little unfair.t  @ |> > That number is too low.  Paul DeMone talks about 2.5 Merced$ |> > (according to Intel I suppose): |> >P |> http://www.realworldtech.com/page.cfm?section=columns&AID=RWT071901001629&p=4 |> >L |> > "Unofficial sources even suggest the McKinley will demonstrate 2.5x the
 |> integerO |> > performance and 2.0x the FP performance of Itanium as measured by SPEC2k."  |>  N |> Why not quote the preceding sentence as well?  "Intel has said that it willO |> run in excess of 1 GHz and offer at least twice the performance of Itanium."fL |> And why not refer to the chart just below that indicating a clock rate ofI |> 1.2 GHz?  Since neither of those seems to be panning out (according tovN |> consistent recent Intel statements that the chip will ship in 1 GHz and 900N |> MHz variations), one might suspect the leaked performance information to be |> similarly overinflated.  C I thought that everybody now knew those particular 'briefings' weremC a few rather unIntelligent marketdroids flipping their lids.  ThosehD figures are (a) MUCH more optimistic than any previous or subsequentC ones, (b) withdrawn from ISSCC 2001 (as Paul DeMone points out) andtB (c) officially denied by Intel in another briefing according to at least one report I saw.,  D Paul DeMone was right to say that it was the most interesting paper,A but his write-up made it clear that he was taking it with a pinchp of salt.  K |> If/when Itanic2 actually ships, then well see which of Intel's leaks waseI |> wrong; I suspect both will turn out to be, and that the truth will lieeG |> somewhere in the middle.  If said truth should exceed 700, then I'll I |> cheerfully admit to guessing a bit low - though will remind you if theyL |> actual figure is still considerably lower than POWER4's (839) and the newI |> Alpha 1.24 GHz (a core more than half a decade older than McKinley andiL |> recently estimated to come in at 850), let alone EV7 (more like 1000 with |> the same aging core), ...  < Agreed.  My guess is that it may be 760 with HP's latest andA greatest compiler, but will not exceed 700 (perhaps not 650) with. Intel's.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679m   ------------------------------   Date: 4 Jul 2002 10:53:08 -0600n+ From: young_r@encompasserve.org (Rob Young)(I Subject: Re: Deutsche Bank would like to outsource there IT to IBM or CSC 3 Message-ID: <S5Mtc1xfic9y@eisner.encompasserve.org>?  \ In article <3D23FC90.4442DDCA@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Rob Young wrote:F >>         are the keys to Itanium taking off.  Yes... Merced is Dead,F >>         McKinley isn't and Itanium finally gets something next year >>         sometime. > K > What do you mean by "Itanium finally gets something next year sometime" ?C >   > 	That quote you referenced is from last year.  I was referring
 	to McKinley.    				Robs   ------------------------------   Date: 4 Jul 2002 08:34:50 GMTn( From: nmm1@cus.cam.ac.uk (Nick Maclaren)- Subject: Re: Fearless IPF Prognostications... 0 Message-ID: <ag11ba$h9g$1@pegasus.csx.cam.ac.uk>  J In article <rdeininger-0307021919220001@1cust96.tnt1.nashua.nh.da.uu.net>,4 rdeininger@mindspring.com (Robert Deininger) writes: |> aL |> >|> VAX MACRO, Bliss, and C are just compiled languages.  None of them is |> >|> inherently unportable.a |> >C |> >Not so.  All are mid-level languages and, as a matter of designnF |> >policy, support inherently unportable programming paradigms.  ThisF |> >shouldn't be overstressed, as experience is that it is fairly easy@ |> >to translate even plain assembler (e.g. IBM System/370) intoD |> >assembler for other architectures with only a moderate amount of. |> >manual editing, provided that it is clean. |>  J |> Compiler folks continue to impress me.  I'm told there is a good chanceI |> that alpha load-locked/store-conditional code sequences written in VAXhL |> macro may be automatically compiled into appropriate synchronization codeE |> for IPF.  Obviously this will require some extra effort in the IPF  |> MACRO-32 compiler.a  B Not a lot - such code generation is pretty easy - the problems, as@ always, are twofold.  The first is analysing the program to work@ out PRECISELY what it is assuming, because emulating down to the@ last bit is too slow (due to the second problem).  The second isC when the models don't match, and there is no reliable and efficientC& mapping from the source to the target.  < This is why converting simple assembler is easy - and lockedA sequences are still simple - but handling exceptions may be quitea? impossible.  You can have delights such as code that assumes anPA operation such as increment is atomic - now consider what happense< with external interrupts if it no longer is.  Yes, any KNOWN< problem variable can be locked, but you can't afford to lock@ EVERY increment, and you may not be able to tell which variables are externally visible.B  ? All right, THAT example refers to the VAX->Alpha transition and0> not the Alpha->IA-64 one, but there will be constructions with! similar properties in the latter.V  F |> >If the code is very clean, then that could be so, but I doubt thatF |> >it is that simple.  Cleaning up the code that assumes a particularE |> >machine without encapsulating it is precisely the IA-64 work that 8 |> >could be reused on POWER4, SPARC, MIPS or whatever.  |> sJ |> Pretty much what I was trying to say.  But a surprising amount of ugly,I |> alpha-specific stuff can be compiled on IPF with no changes or trivial  |> changes to the source code.  ? Subject to the two problems I mentioned above being soluble foroA the code in question.  Remember that what looks ugly and platformiA specific to most humans may actually be fairly simple and genericO to a compiler, and vice versa.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679-   ------------------------------   Date: 4 Jul 2002 06:52:18 -0600 - From: Kilgallen@SpamCop.net (Larry Kilgallen) - Subject: Re: Fearless IPF Prognostications...03 Message-ID: <iujyGfm8K8Qt@eisner.encompasserve.org>-  c In article <3d23759a.2988987@news.easynews.com>, prune@ZAnkh-Morpork.mv.com (Paul Winalski) writes:   D > Then there's the issue of run-time speed.  Compiler technology canA > only go so far in figuring out the "inner program" that's beingsE > expressed by a hunk of VAX MACRO code.  On Alpha one can very oftenaC > get a 2X, 3X, or even better speedup using the C equivalent vs. amE > MACRO-32 equivalent.  And ironically, the compiled object code gets A > worse the more clever the original programmer was in coding thea > VAX MACRO original.  > B > This can have major effects on OS performance.  I saw this firstB > hand with a small benchmark that did nothing but ten million RMSA > $GETs on a vanilla sequential file.  I was shocked to find thateA > twice as many seconds of CPU time were consumed on Alpha VMS aslA > opposed to VAX/VMS running on a CPU several factors slower.  MyE@ > estimate is that the main, default sequential I/O path in RMS,E > which was written in VAX MACRO way back when to make it run faster, F > is about an order of magnitude slower on Alpha than on VAX.  Rewrite6 > it in C or BLISS and you'd get the performance back.  B But the priority of doing that must be based on what proportion of@ worthwhile applications have RMS GET bounding their performance.  H By "worthwhile" I mean applications written by people who, for instance, have ever heard of Locate mode.r   ------------------------------  # Date: Thu, 04 Jul 2002 14:46:50 GMTw# From: "John Smith" <a@nonymous.com> - Subject: Re: Fearless IPF Prognostications... F Message-ID: <udZU8.15355$zGH.582@news01.bloor.is.net.cable.rogers.com>  = "Paul Winalski" <prune@ZAnkh-Morpork.mv.com> wrote in messagep* news:3d23759a.2988987@news.easynews.com... >2D > That sort of thing is only going to be worse on Itanium, where youC > really need profile-directed feedback to get any speed out of theg > hardware.   J At the risk of sounding glib, sometime an o/s and a cpu that were designed! for each other isn't a bad thing.l  L If Alpha had not had its throat slit by Capellas, it seems unlikely that VMSK would have had the amount of intensive reworking it is going through now. IaK know that most of the work is directed at the port to IA-64, but while theyyI are at it I'm quite sure that many other things are getting attention nowhG that may have otherwise been deferred. I guess that's what happens whenk8 somebody else is paying the bills (Intel porting money).   </flog a dead horse on>BL On the other hand, it still seems to me that given the relative high cost ofH IA-64 chips vs. Alpha cpu's, that the number of IA-64 effort (man-hours)L devoted to the porting aspects are a waste. What Compaq should have done wasH taken the $185MM or so that they annually spent advertising money-losingL PC's and used it to subsidized the Alpha CPU cost for low-end Alpha's to theK point where for most businesses a low-cost Alpha system would have been themK no-brain decision vs. Sun and everything else. Eventually Compaq would havelL made up the subsidy with the attendant lower per-unit costs achieved through increased sales volume.i  G Compaq's decision making was fatally flawed for many years. As a really J rough analogy, it was sort of like the homeowners who wanted to freshen upK their home before resale. They got a quote of $1000 from a painter to applytJ the paint to the exterior of their house, then they went out and chose theI most garish color imaginable for $30/gallon. Their house value dropped byuK $5000 because of the perception of potential buyers that the house needed aiH lot of work to make it presentable. If the homeowners had spent the sameJ $1000 with the painter and the same $30/gallon on 'tasteful' paint colors,B their resale value would have climbed by $5000 because prospectiveD purchasers would have deemed the house to be in 'move-in' condition.   <flog a dead horse off>-  K It remains to be seen whether HP are as stupid as Compaq was in relation tot OpenVMS-based systems.   ------------------------------  # Date: Thu, 04 Jul 2002 14:52:00 GMTD1 From: "Terry C. Shannon" <terryshannon@attbi.com>l- Subject: Re: Fearless IPF Prognostications...W. Message-ID: <kiZU8.409726$cQ3.28107@sccrnsc01>  . "John Smith" <a@nonymous.com> wrote in message@ news:udZU8.15355$zGH.582@news01.bloor.is.net.cable.rogers.com... >-? > "Paul Winalski" <prune@ZAnkh-Morpork.mv.com> wrote in message0, > news:3d23759a.2988987@news.easynews.com... > >cF > > That sort of thing is only going to be worse on Itanium, where youE > > really need profile-directed feedback to get any speed out of thee
 > > hardware.  >eL > At the risk of sounding glib, sometime an o/s and a cpu that were designed# > for each other isn't a bad thing.  > J > If Alpha had not had its throat slit by Capellas, it seems unlikely that VMS K > would have had the amount of intensive reworking it is going through now.c IoH > know that most of the work is directed at the port to IA-64, but while theyK > are at it I'm quite sure that many other things are getting attention nowLI > that may have otherwise been deferred. I guess that's what happens when : > somebody else is paying the bills (Intel porting money). >a > </flog a dead horse on>fK > On the other hand, it still seems to me that given the relative high cost  ofJ > IA-64 chips vs. Alpha cpu's, that the number of IA-64 effort (man-hours)- > devoted to the porting aspects are a waste.e  G Ummm, I had speculated that the overhead associated with each Alpha CPU G (total R&D and platform integration cost, etc / number of CPUs sold per E annum) was about $500USD. Turns out that the real number is closer tom $800USD per CPU.  K I strongly suspect that McKinley-based workstations will start at under $5KoK USD when they are announced next week, but more will be known on or about 8  July.y    " > What Compaq should have done wasJ > taken the $185MM or so that they annually spent advertising money-losingJ > PC's and used it to subsidized the Alpha CPU cost for low-end Alpha's to thenI > point where for most businesses a low-cost Alpha system would have beent theeH > no-brain decision vs. Sun and everything else. Eventually Compaq would haveF > made up the subsidy with the attendant lower per-unit costs achieved throughx > increased sales volume.e  E Yep. Assuming that $185M is all it would take to achieve APPLICATIONSl critical mass.   ------------------------------  # Date: Thu, 04 Jul 2002 15:24:03 GMT 0 From: prune@ZAnkh-Morpork.mv.com (Paul Winalski)- Subject: Re: Fearless IPF Prognostications...o/ Message-ID: <3d246942.664795@news.easynews.com>i  E On 4 Jul 2002 06:52:18 -0600, Kilgallen@SpamCop.net (Larry Kilgallen)l wrote:  d >In article <3d23759a.2988987@news.easynews.com>, prune@ZAnkh-Morpork.mv.com (Paul Winalski) writes: > C >> This can have major effects on OS performance.  I saw this firsteC >> hand with a small benchmark that did nothing but ten million RMS B >> $GETs on a vanilla sequential file.  I was shocked to find thatB >> twice as many seconds of CPU time were consumed on Alpha VMS asB >> opposed to VAX/VMS running on a CPU several factors slower.  MyA >> estimate is that the main, default sequential I/O path in RMS, F >> which was written in VAX MACRO way back when to make it run faster,G >> is about an order of magnitude slower on Alpha than on VAX.  Rewritet7 >> it in C or BLISS and you'd get the performance back.b >oC >But the priority of doing that must be based on what proportion ofeA >worthwhile applications have RMS GET bounding their performance.y >iI >By "worthwhile" I mean applications written by people who, for instance,r  >have ever heard of Locate mode.  ? Not a useful attitude if you're trying to grow the business (ort@ even keep it alive) by attracting new cusomers and applications.D If the only worthwhile applications are those specifically hacked upB to use VMS's peculiar system call interfaces, in the long term the
 OS is doomed.i  C It's vitally important that the default path be fast, becaue that'skE the one that the vast majority of customers are going to use, whetherM we OS weenies like it or not.    -----------n Remove 'Z' to send me email. -----------    ------------------------------  # Date: Thu, 04 Jul 2002 15:41:03 GMTt# From: "John Smith" <a@nonymous.com>s- Subject: Re: Fearless IPF Prognostications...iE Message-ID: <j0_U8.3199$si2.266@news01.bloor.is.net.cable.rogers.com>t  < "Terry C. Shannon" <terryshannon@attbi.com> wrote in message( news:kiZU8.409726$cQ3.28107@sccrnsc01... >p0 > "John Smith" <a@nonymous.com> wrote in messageB > news:udZU8.15355$zGH.582@news01.bloor.is.net.cable.rogers.com... > > A > > "Paul Winalski" <prune@ZAnkh-Morpork.mv.com> wrote in messager. > > news:3d23759a.2988987@news.easynews.com... > > >uH > > > That sort of thing is only going to be worse on Itanium, where youG > > > really need profile-directed feedback to get any speed out of the1 > > > hardware.i > >sE > > At the risk of sounding glib, sometime an o/s and a cpu that werel designed% > > for each other isn't a bad thing.e > >mL > > If Alpha had not had its throat slit by Capellas, it seems unlikely that > VMSoH > > would have had the amount of intensive reworking it is going through now. > IhJ > > know that most of the work is directed at the port to IA-64, but while > theyI > > are at it I'm quite sure that many other things are getting attention> now K > > that may have otherwise been deferred. I guess that's what happens wheng< > > somebody else is paying the bills (Intel porting money). > >  > > </flog a dead horse on> H > > On the other hand, it still seems to me that given the relative high cost > ofL > > IA-64 chips vs. Alpha cpu's, that the number of IA-64 effort (man-hours)/ > > devoted to the porting aspects are a waste.n >'I > Ummm, I had speculated that the overhead associated with each Alpha CPUiI > (total R&D and platform integration cost, etc / number of CPUs sold perTG > annum) was about $500USD. Turns out that the real number is closer ton > $800USD per CPU.    I Say they spent $50MM annually on Alpha (VMS and Tru64) advertising (in my1J wildest dreams). And say that they had to 'subsidize' each cpu to the tuneG of $500, we are left with  ($185MM - 50MM)/500 = 270,000 cpu/annum thatnH would have been subsidized. But in fact  it would, on average, have costJ much less than $500 per cpu. Those cpu's fab'ed later in the year would beI benefitting from the lower fab costs associated with the higher run rate,fG and the same would have held true for the support chips, R&D, and otherSK costs. True costs probably would have been closer to $200-250, perhaps evene less.t  G Compaq bet the farm in an advertising sense on PC's - a product line on H which they lose money. Their business/production model for PC's was/is aJ losing proposition and NO amount of advertising money was going to correctF that. That's what they're supposed to teach in MBA school, or what anyI accountant who has half a brain would have known. Better they should havetL rolled the dice with the ad/marketing money to expand the market penetration= on a product line on which they made money - Alpha/VMS/Tru64.e    I > I strongly suspect that McKinley-based workstations will start at undere $5KnK > USD when they are announced next week, but more will be known on or about  8s > July.>  L VAXstations used to cost that too at entry-level. And that was when 1Gb diskK drives and CD-ROM drives were $1k each. Lots of things have gotten cheaper,m, except the starting price of a new cpu line.   ------------------------------  % Date: Thu, 04 Jul 2002 12:49:47 -0400l- From: JF Mezei <jfmezei.spamnot@videotron.ca> - Subject: Re: Fearless IPF Prognostications...n, Message-ID: <3D247CAB.ACCA5384@videotron.ca>   John Smith wrote:KM > It remains to be seen whether HP are as stupid as Compaq was in relation to1 > OpenVMS-based systems.  J If Scott Stallard's memo is any indication, HP may in fact beat Compaq and Palmer in the stupidity game.   L While it can easily be argued that Compaq had long ago decided to eventuallyK phase out Alpha, my feeling is that had Carly and Curly not gotten into bedmJ together, Compaq would have given Alpha a stay of execution until IA64 was more palatable.4  N By murdering Alpha and putting all its eggs in the IA64 basket, it made CompaqK look more "compatible" with Carly's HP and thus made the merger seem like a  better idea.   ------------------------------  % Date: Thu, 04 Jul 2002 12:58:43 -0400?- From: JF Mezei <jfmezei.spamnot@videotron.ca>,- Subject: Re: Fearless IPF Prognostications...:, Message-ID: <3D247EC2.B3263CE5@videotron.ca>   John Smith wrote:.I > Compaq bet the farm in an advertising sense on PC's - a product line onsJ > which they lose money. Their business/production model for PC's was/is aL > losing proposition and NO amount of advertising money was going to correct= > that. That's what they're supposed to teach in MBA school, 	  N The logic was that in raising production volumes, they would finally make it aK profitable business since the fixed costs would be spread amongst a greater. number of units sold.$  I It still wouldn't have made Compaq more efficient/profitable than Dell or9H Gateway since Compaq is still restrictted in how it sells PCs due to itsN continued relationship with the legacy "channel". Neither Dell nor Gateway areE weighted down by the "channel" and have far better efficiency models.e  L Compaq's TV ad showing a wharehouse full of PCs waiting to be shipped should: have sent a clear message to investors to dump that stock.   ------------------------------  # Date: Thu, 04 Jul 2002 16:57:02 GMTe1 From: "Terry C. Shannon" <terryshannon@attbi.com>s- Subject: Re: Fearless IPF Prognostications...e> Message-ID: <y7%U8.237862$R61.87822@rwcrnsc52.ops.asp.att.net>  . "John Smith" <a@nonymous.com> wrote in message? news:j0_U8.3199$si2.266@news01.bloor.is.net.cable.rogers.com...o >t> > "Terry C. Shannon" <terryshannon@attbi.com> wrote in message* > news:kiZU8.409726$cQ3.28107@sccrnsc01... > >e2 > > "John Smith" <a@nonymous.com> wrote in messageD > > news:udZU8.15355$zGH.582@news01.bloor.is.net.cable.rogers.com... > > >iC > > > "Paul Winalski" <prune@ZAnkh-Morpork.mv.com> wrote in message 0 > > > news:3d23759a.2988987@news.easynews.com... > > > >aJ > > > > That sort of thing is only going to be worse on Itanium, where youI > > > > really need profile-directed feedback to get any speed out of ther > > > > hardware.n > > >pG > > > At the risk of sounding glib, sometime an o/s and a cpu that wereb
 > designed' > > > for each other isn't a bad thing.- > > >nI > > > If Alpha had not had its throat slit by Capellas, it seems unlikelyc that > > VMSsJ > > > would have had the amount of intensive reworking it is going through > now. > > IeL > > > know that most of the work is directed at the port to IA-64, but while > > theyK > > > are at it I'm quite sure that many other things are getting attentiona > nowrH > > > that may have otherwise been deferred. I guess that's what happens when> > > > somebody else is paying the bills (Intel porting money). > > >i > > > </flog a dead horse on>aJ > > > On the other hand, it still seems to me that given the relative high > cost > > ofB > > > IA-64 chips vs. Alpha cpu's, that the number of IA-64 effort (man-hours) 1 > > > devoted to the porting aspects are a waste.  > >oK > > Ummm, I had speculated that the overhead associated with each Alpha CPU K > > (total R&D and platform integration cost, etc / number of CPUs sold perfI > > annum) was about $500USD. Turns out that the real number is closer tor > > $800USD per CPU. >e >oK > Say they spent $50MM annually on Alpha (VMS and Tru64) advertising (in myeL > wildest dreams). And say that they had to 'subsidize' each cpu to the tuneI > of $500, we are left with  ($185MM - 50MM)/500 = 270,000 cpu/annum thatiJ > would have been subsidized. But in fact  it would, on average, have costL > much less than $500 per cpu. Those cpu's fab'ed later in the year would beK > benefitting from the lower fab costs associated with the higher run rate, I > and the same would have held true for the support chips, R&D, and otherlH > costs. True costs probably would have been closer to $200-250, perhaps even > less.c  H You might want to make the beancounters and the managers at HPQ aware ofC this, as they have been laboring under the clearly specious $800USDs assumption.e  K Since DEC got out of the fab bizness before it got Compaq-ted, the speciousr7 $800USD assumption does not include fab plant overhead.c   > I > Compaq bet the farm in an advertising sense on PC's - a product line ontJ > which they lose money. Their business/production model for PC's was/is aL > losing proposition and NO amount of advertising money was going to correctH > that. That's what they're supposed to teach in MBA school, or what anyK > accountant who has half a brain would have known. Better they should havegB > rolled the dice with the ad/marketing money to expand the market penetrationd? > on a product line on which they made money - Alpha/VMS/Tru64.a >S >lK > > I strongly suspect that McKinley-based workstations will start at undera > $5KhG > > USD when they are announced next week, but more will be known on orV aboutO > 8b	 > > July.  >eI > VAXstations used to cost that too at entry-level. And that was when 1GbV diskD > drives and CD-ROM drives were $1k each. Lots of things have gotten cheaper,. > except the starting price of a new cpu line. >f  K In 1988 the VAXstar did in fact undergo a price reduction from $10K to $5K.wK VAXstations didn't start out that cheap, though... cheapest pre-VAXstar wasrJ the VAXstation II/RC (with the epoxied backplane) which IIRC was somewhere between $15K and $20K.   ------------------------------  # Date: Thu, 04 Jul 2002 11:00:50 GMTs. From: ">>> ^P" <plj@NOSPAM.byron.ext.telia.se># Subject: Re: Last 3 weeks on c.o.v. 9 Message-ID: <3D242AED.30D1C86B@NOSPAM.byron.ext.telia.se>e  E I'm also a techie-reader, but, yes, more positive now, but we're onlyy  humans after all, not computers.% Well, at least some of us aren't. ;-)f   I'm also going to France!o  	 >>> ^P.Ljd   Jan-Erik Sderholm skrev:d   > Hi. B > Yesterday I came back after 3 weeks of vacation with the family.: > (Paris, Val-de-Loire, Bretagne, if you're interested...) >s? > Now, having followed c.o.v for a day, is it just me, or isn'ti< > there a slightly more positive tone on c.o.v now regarding= > VMS, HP and related matters ? What have happend during thist > 3 week period ?t >  > Best Regards > Jan-Erik Sderholm.    ------------------------------  * Date: Thu, 4 Jul 2002 09:58:33 +0000 (UTC)9 From: Roar =?iso-8859-1?Q?Thron=E6s?= <roart@nvg.ntnu.no>  Subject: new emacs 21B- Message-ID: <ag1689$9o6$1@tyfon.itea.ntnu.no>g   Hi  ) A new Emacs 21 (21.2) is now available ath0 ftp.nvg.ntnu.no:/pub/vms/emacs/emacs212_2.bck.gz  / News since last Emacs 21 announced here (21.5):t Patching it up to 21.2.wK Another developer joined in very recently, and have done some code-patches, E some cleanups of the mms-files, multinet support, some docs, termcap,o@ testing with both VMS 7.2-1/7.3, CC 6.0/6.5 and MMK 3.9/MMS 3.3.   Regards, Roar Throns   ------------------------------  # Date: Thu, 04 Jul 2002 16:48:14 GMTe- From: "John E. Malmberg" <wb8tyw@qsl.network>i* Subject: Re: postscript print from vms 5.4* Message-ID: <3D24782B.2030401@qsl.network>  
 pam wrote:H > I need to print postscript files to a postscript printer on one of the( > serial ports on a vax running vms 5.4.   5.4 is quite out of date.o  H The Current version of OpenVMS for VAX is 7.3.  The lowest version that 6 Prior Version Support is generally available is 5.5-2.  E > I don't really need to print anything else except postscript files.e > = > Does anybody know where I can find the commands to do this.r  D The standard PRINT command should do this just fine, as long as the  printer understands PostScript.a  L > I have so far been able to send postscript commands to the printer and getJ > a pretty picture out but I haven't been able to get a postscript file to- > print on the printer through a print queue.t  I That would indicate that something in the print queue has been set up to pB modify the output in a way that is not compatable with PostScript.  D The default form used with a print queue truncates the width of the C input document to 132 characters.  If your PostScript document has k/ longer lines than that, they will be truncated.<  I You can use the DEFINE/FORM to create a new form, or modify the existing t form.r  E Other possibilities is that the print queue has one or more setup or  < reset modules that are changing the behavior of the printer.  F Reset modules on print queues prevent printer commands from one print A job from affecting later print jobs and insure that a printer is e properly set up.  F It you can upgrade to a supported verion of OpenVMS, the DCPS product ? that is included with the OpenVMS license, can be used to make n( Postscript printing more easy to manage.   -Johnl wb8tyw@qsl.network Personal Opinion Onlyf   ------------------------------   Date: 4 Jul 2002 08:55:53 GMTt( From: nmm1@cus.cam.ac.uk (Nick Maclaren)4 Subject: Re: Three HP Press releases (via Bloomberg)0 Message-ID: <ag12ip$iib$1@pegasus.csx.cam.ac.uk>  . In article <TlHU8.400752$cQ3.26911@sccrnsc01>,3 "Terry C. Shannon" <terryshannon@attbi.com> writes:i1 |> "John Smith" <a@nonymous.com> wrote in messagesD |> news:M5HU8.6707$eZo1.1621@news01.bloor.is.net.cable.rogers.com... |> >M |> > > As to the bet that new AlphaServers (EV7?) will not be benchmarked.. Ia* |> > > would be willing to take that bet.. |> > > |> > > So would I. ;-}  A I wouldn't.  But I would agree that HP/Compaq probably won't, anda# SPEC won't publish private figures.u  I |> > So if EV7 comes in at nearly an order of magnitude better than otherbO |> > existing systems, does HP pull the plug on IA-64 in favor of a resurrecteds- |> > Alpha? Ooops..forgot..this isn't Easter.  |> nI |> Probably won't be an order of magnitude, but I suspect that McKinley'stK |> bragging rights as fastest FP performer on the planet will be relativelyn |> short-lived. ;-}o  ; Yes.  And considering that the POWER4 is close behind, on ao; 0.18 micron process, and has been out for a while, it isn'to> only the EV7 that might knock it off its pedestal.  Of course,> Intel have already brought the Madison forward (on paper), and= could probably produce a 0.13 micron McKinley if they wanted.v  > But, despite all the shouting, I doubt that SpecFP performance? is going to be the reason that the McKinley sinks or fails.  It > will be whether it works in the field, perhaps I/O performance' and certainly Microsoft's machinations.m     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679    ------------------------------  $ Date: Thu, 4 Jul 2002 09:59:51 +0200$ From: "Peter Flunger" <p-i-b@gmx.at> Subject: Re: VMS 64bitness0 Message-ID: <ag0v9o$ubh$1@newsreader1.netway.at>  2 "Paul Winalski" <prune@ZAnkh-Morpork.mv.com> wrote* news:3d237237.2122121@news.easynews.com...G > Doesn't amount to a hill of beans, given that nearly all the EXTERNAL 8 > interfaces available to applications are still 32-bit. >s  F Do some of you folks even try to find out how things really are before	 posting ?w   Peterw   ------------------------------  # Date: Thu, 04 Jul 2002 15:27:57 GMTo0 From: prune@ZAnkh-Morpork.mv.com (Paul Winalski) Subject: Re: VMS 64bitness0 Message-ID: <3d246bb2.1289183@news.easynews.com>  B On Wed, 3 Jul 2002 21:20:05 -0400, "John Vottero" <John@mvpsi.com> wrote:  > >"Paul Winalski" <prune@ZAnkh-Morpork.mv.com> wrote in message+ >news:3d237237.2122121@news.easynews.com...wH >> Doesn't amount to a hill of beans, given that nearly all the EXTERNAL9 >> interfaces available to applications are still 32-bit.t >> > 3 >The OpenVMS documentation has a different opinion:o   [snip]   OK, I stand corrected. -----------y Remove 'Z' to send me email. -----------l   ------------------------------   Date: 4 Jul 2002 02:27:51 -0700p From: br@b-con.dk (Bendix Riis)a/ Subject: Re: Windows 2000 -> Linux Samba -> VMSy= Message-ID: <9946d62e.0207040127.12d74c23@posting.google.com>   j peter@langstoeger.at (Peter LANGSTOEGER) wrote in message news:<tPKU8.131082$IR.1949793@news.chello.at>...a > In article <9946d62e.0207030317.1ca67333@posting.google.com>, br@b-con.dk (Bendix Riis) writes:rH > >I have set up a linux box running samba that via nfs-mount has access. > >to a directory on a VAX running VMS v5.5-2.I > >Windows PC's can connect to the samba share and copy files to and from  > >VMS.hE > >Everything works fine except that when VMS print or text files aren< > >read in windows they have a wrong format - cr lf missing.G > >Is it possible to set up the system to convert/filter the files when8+ > >reading/copying them from VMS to the PC?s > G > Why not run SAMBA on VMS and eliminate LINUX (and more important NFS)e > from the picture ?  E This was more or less the answer I had expected, but for many reasonss" we don't want to run samba on VMS.A Do you think there is a way out of the problem if we stick to ourg
 resent setup?f   Bendix Riish B-cont e-mail: br@b-con.dks   ------------------------------   Date: 4 Jul 2002 02:29:44 -0700t From: br@b-con.dk (Bendix Riis)u/ Subject: Re: Windows 2000 -> Linux Samba -> VMS = Message-ID: <9946d62e.0207040129.5c4b2a6c@posting.google.com>   j peter@langstoeger.at (Peter LANGSTOEGER) wrote in message news:<tPKU8.131082$IR.1949793@news.chello.at>...a > In article <9946d62e.0207030317.1ca67333@posting.google.com>, br@b-con.dk (Bendix Riis) writes: H > >I have set up a linux box running samba that via nfs-mount has access. > >to a directory on a VAX running VMS v5.5-2.I > >Windows PC's can connect to the samba share and copy files to and from  > >VMS.eE > >Everything works fine except that when VMS print or text files area< > >read in windows they have a wrong format - cr lf missing.G > >Is it possible to set up the system to convert/filter the files whens+ > >reading/copying them from VMS to the PC?r > G > Why not run SAMBA on VMS and eliminate LINUX (and more important NFS)a > from the picture ?  E This was more or less the answer I had expected, but for many reasonsh" we don't want to run samba on VMS.A Do you think there is a way out of the problem if we stick to ourb
 resent setup?    Bendix Riis  B-cono e-mail: br@b-con.dk    ------------------------------   Date: 4 Jul 2002 10:10:25 GMTo From: phn@icke-reklam.ipsec.nu/ Subject: Re: Windows 2000 -> Linux Samba -> VMSf) Message-ID: <ag16uh$qhf$5@nyheter.crt.se>     Bendix Riis <br@b-con.dk> wrote:l > peter@langstoeger.at (Peter LANGSTOEGER) wrote in message news:<tPKU8.131082$IR.1949793@news.chello.at>...b >> In article <9946d62e.0207030317.1ca67333@posting.google.com>, br@b-con.dk (Bendix Riis) writes:I >> >I have set up a linux box running samba that via nfs-mount has access / >> >to a directory on a VAX running VMS v5.5-2.uJ >> >Windows PC's can connect to the samba share and copy files to and from >> >VMS.F >> >Everything works fine except that when VMS print or text files are= >> >read in windows they have a wrong format - cr lf missing.iH >> >Is it possible to set up the system to convert/filter the files when, >> >reading/copying them from VMS to the PC? >>  H >> Why not run SAMBA on VMS and eliminate LINUX (and more important NFS) >> from the picture ?s  G > This was more or less the answer I had expected, but for many reasonsr$ > we don't want to run samba on VMS.C > Do you think there is a way out of the problem if we stick to ourn > resent setup?-  F Maybe using lpr/lpd printing would be better ? There is free software ) available for all mentioned environments.   
 > Bendix Riisa > B-con  > e-mail: br@b-con.dke   -- D Peter Hkanson         o7         IPSec  Sverige      ( At Gothenburg Riverside )hJ            Sorry about my e-mail address, but i'm trying to keep spam out,; 	   remove "icke-reklam" if you feel for mailing me. Thanx.a   ------------------------------  % Date: Thu, 04 Jul 2002 13:45:54 +0100e( From: Nic Clews <sendspamhere@127.0.0.1>/ Subject: Re: Windows 2000 -> Linux Samba -> VMS ) Message-ID: <3D244382.4D95DCAA@127.0.0.1>o   Bendix Riis wrote: > l > peter@langstoeger.at (Peter LANGSTOEGER) wrote in message news:<tPKU8.131082$IR.1949793@news.chello.at>...c > > In article <9946d62e.0207030317.1ca67333@posting.google.com>, br@b-con.dk (Bendix Riis) writes: J > > >I have set up a linux box running samba that via nfs-mount has access0 > > >to a directory on a VAX running VMS v5.5-2.K > > >Windows PC's can connect to the samba share and copy files to and froms	 > > >VMS.2G > > >Everything works fine except that when VMS print or text files are > > > >read in windows they have a wrong format - cr lf missing.I > > >Is it possible to set up the system to convert/filter the files whenp- > > >reading/copying them from VMS to the PC?a > >nI > > Why not run SAMBA on VMS and eliminate LINUX (and more important NFS)	 > > from the picture ? > G > This was more or less the answer I had expected, but for many reasonss$ > we don't want to run samba on VMS.C > Do you think there is a way out of the problem if we stick to oure > resent setup?    VMS 5.5-2 came out in 1992.o PCs were running Windows 3.11l  H If you can't consider bringing your VMS system into the real world (thisA is 2002 last I looked at the calendar) then surely this weighs int against your "many reasons".  F Sorry, but if you were talking Windows 2000 and VMS 7.2, perhaps you'd gain more sympathy.   E http://www.openvms.compaq.com/openvms/os/openvms-release-history.html-   -- -? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences  nclews at csc dot comr   ------------------------------  * Date: Thu, 4 Jul 2002 13:35:13 +0000 (UTC) From: david20@alpha1.mdx.ac.uk/ Subject: Re: Windows 2000 -> Linux Samba -> VMSc+ Message-ID: <ag1iuh$s7g$1@aquila.mdx.ac.uk>@  T In article <3D244382.4D95DCAA@127.0.0.1>, Nic Clews <sendspamhere@127.0.0.1> writes: >Bendix Riis wrote:  >> sm >> peter@langstoeger.at (Peter LANGSTOEGER) wrote in message news:<tPKU8.131082$IR.1949793@news.chello.at>...1d >> > In article <9946d62e.0207030317.1ca67333@posting.google.com>, br@b-con.dk (Bendix Riis) writes: >m >VMS 5.5-2 came out in 1992. >PCs were running Windows 3.11 >wI >If you can't consider bringing your VMS system into the real world (this B >is 2002 last I looked at the calendar) then surely this weighs in >against your "many reasons".  > G >Sorry, but if you were talking Windows 2000 and VMS 7.2, perhaps you'dn >gain more sympathy. >iF >http://www.openvms.compaq.com/openvms/os/openvms-release-history.html >n >--    Nic,  O Give the guy a break. You don't know his situation. There may be valid reasons aG - software not supported on later versions of VMS etc which prevent himn
 upgrading.  
 David Webb VMS and Unix team leader CCSS Middlesex University  @ >Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences >nclews at csc dot com   ------------------------------  # Date: Thu, 04 Jul 2002 15:20:33 GMT # From: "John Smith" <a@nonymous.com>l Subject: Re: wowG Message-ID: <5JZU8.15645$zGH.9115@news01.bloor.is.net.cable.rogers.com>i  < "Terry C. Shannon" <terryshannon@attbi.com> wrote in message8 news:AQMU8.229539$R61.84039@rwcrnsc52.ops.asp.att.net... > 0 > "John Smith" <a@nonymous.com> wrote in messageA > news:38MU8.4781$zGH.532@news01.bloor.is.net.cable.rogers.com...v > >d> > > "Gerald Marsh" <gerald@cyfer.demon.co.uk> wrote in message6 > > news:iep6iu4v6kqosmidu38bq3fla85hqjeqgn@4ax.com... > > >a > > >0) > > > Perhaps it's in good hands at last!s > >r > > H > > It's far too early to tell. HP has to do a lot beyond filling in the holeK > > that Compaq and Digital dug OpenVMS into. Perhaps when VMS market sharee > hascI > > returned to where it was 10-15 years ago can we collectively breath ac sigh > > of relief. >aJ > Not looking all that good in blue (and not wanting to emulate a Smurf) II > don't think I'll be holding my breath awaiting the day that VMS regainsi the H > market share it had 15 years ago. There's a lot more UNIX, and way too muchJ > more Windoze out there gobbling up a significant chunk of the market. Oh > yeah, Linux too. >   J I tend to be a 'glass is half-empty' person when it comes to human nature.I People will allow themselves to think that sh*t is pretty tasty to eat ifoC it's advertised enough - also known as 'the big lie' premise. FirstoI practiced to great effect by Nazi Germany's propaganda machine. Fast foods5 chains, unix, linux, *dows, are all shining examples.   D But Terry, you mustn't forget that the absolute number of businessesI existent is larger now than it was 15 years ago. The market is larger. SoaD perhaps what I should have said is that VMS should at least have theL installed # of systems it did then, rather than market percentage. Even that: should translate into a healthy increase in units shipped.   ------------------------------  # Date: Thu, 04 Jul 2002 17:49:15 GMTe1 From: "Terry C. Shannon" <terryshannon@attbi.com>  Subject: Re: wow. Message-ID: <vU%U8.410891$cQ3.28282@sccrnsc01>  . "John Smith" <a@nonymous.com> wrote in messageA news:5JZU8.15645$zGH.9115@news01.bloor.is.net.cable.rogers.com...b >m> > "Terry C. Shannon" <terryshannon@attbi.com> wrote in message: > news:AQMU8.229539$R61.84039@rwcrnsc52.ops.asp.att.net... > >V2 > > "John Smith" <a@nonymous.com> wrote in messageC > > news:38MU8.4781$zGH.532@news01.bloor.is.net.cable.rogers.com...n > > >l@ > > > "Gerald Marsh" <gerald@cyfer.demon.co.uk> wrote in message8 > > > news:iep6iu4v6kqosmidu38bq3fla85hqjeqgn@4ax.com... > > > >o > > > >e+ > > > > Perhaps it's in good hands at last!( > > >e > > >dJ > > > It's far too early to tell. HP has to do a lot beyond filling in the > holeG > > > that Compaq and Digital dug OpenVMS into. Perhaps when VMS marketO sharer > > haslK > > > returned to where it was 10-15 years ago can we collectively breath aN > sigh > > > of relief. > >'L > > Not looking all that good in blue (and not wanting to emulate a Smurf) IK > > don't think I'll be holding my breath awaiting the day that VMS regainsg > the J > > market share it had 15 years ago. There's a lot more UNIX, and way too > muchL > > more Windoze out there gobbling up a significant chunk of the market. Oh > > yeah, Linux too. > >) >sL > I tend to be a 'glass is half-empty' person when it comes to human nature.K > People will allow themselves to think that sh*t is pretty tasty to eat iftE > it's advertised enough - also known as 'the big lie' premise. FirstgK > practiced to great effect by Nazi Germany's propaganda machine. Fast food47 > chains, unix, linux, *dows, are all shining examples.? >oF > But Terry, you mustn't forget that the absolute number of businessesK > existent is larger now than it was 15 years ago. The market is larger. SoaF > perhaps what I should have said is that VMS should at least have theI > installed # of systems it did then, rather than market percentage. Evene that< > should translate into a healthy increase in units shipped. >n  J I don't have internal numbers (but if HPQ would like to provide them, theyK can feel free to do so) but I suspect that the VMS installed base peaked at 0 500K systems or so. HPQ now claims 400K systems.  E I too would like to see shipments increase, but at this juncture appsj' availability is IMHO the gating factor.e   ------------------------------  % Date: Thu, 04 Jul 2002 10:09:52 +0100o( From: Nic Clews <sendspamhere@127.0.0.1>& Subject: Re: [OT] AS/400 Success Story) Message-ID: <3D2410E0.BDFF6254@127.0.0.1>    Nick Maclaren wrote: > 6 > In article <20020703152603.E10069@eisenschmidt.org>,6 > John Eisenschmidt <jweisen@eisenschmidt.org> writes: > |> IBM never sleeps. > |>F > |> I've been out of the blue loop for a couple years now, and I knowE > |> they both use the Power 4 chip, but from what I've read it lookstF > |> like the AS/400 and the RS/6000 are the same hardware.  How scary
 > |> is that?n > A > For whom?  As a manager of an RS/6000-based system (POWER3, notcA > POWER4), the basic hardware is pretty good.  All my informationnA > is that the POWER4 will be similar.  As with most other serioust> > large-system vendors, software issues account for 90% of the	 > effort.w > ? > Standardising on hardware is very reasonable - after all, DECiB > did it twice, being flamed internally and externally both times,; > and both projects succeeded.   This is independent of thetA > question of whether HP/Compaq have chosen the right hardware too > standardise on.   F The issue for big blue has been releasing the hardware for OSes at theG same time. They've done it now, but their AIX used to be running on theaD latest chips up to 6 months before their OS400 systems got to run on them.s  9 (But as I said, they are releasing them concurrently now)u  D If you recall, VMSaxp for Alpha was based on 5.4, when 5.5-2 and 6.0D were out, contrast this with 7.3-1, which will have some vestiges of Itanium.  H This also appears to be the way HP-UX is going, succeeding releases with8 more and more Tru64 (with a Trucluster switch-on point).   -- -? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciencess nclews at csc dot come   ------------------------------   End of INFO-VAX 2002.365 ************************s.csx.cam.ac.uk>  . In article <TlHU8.400752$cQ3.26911@sccrnsc01>,3 "Terry C. Shannon" <terryshannon@attbi.com> writes:i1 |> "Johni    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    i    