1 INFO-VAX	Sun, 09 Sep 2001	Volume 2001 : Issue 502       Contents: Re: a summing-up so far  Re: Big black helicopters  Re: Big black helicopters 2 Re: Converting a stream_lf file to a variable file Re: Dear HP... Re: Dear HP... Re: DECRAM in OpenVMS  Re: DECRAM in OpenVMS  Re: DECRAM in OpenVMS  Re: DECRAM in OpenVMS  Re: EV7 will never ship? Re: EV7 will never ship? Re: FTP of ASCII Re: I hate Compaq  Re: I hate Compaq  Re: RIP Bill Gates Re: RIP Bill Gates Re: RIP Bill Gates Re: RIP Bill Gates Re: RIP Bill Gates Re: RIP Bill Gates Re: Setting File Attributes 5 Re: VMS To Be Squeezed Out Of HP's Strategic Vision ?   F ----------------------------------------------------------------------  % Date: Sun, 09 Sep 2001 11:45:03 +0200  From: "B.Eckstein" <be@cli.de>  Subject: Re: a summing-up so far% Message-ID: <3B9B3A1F.8000009@cli.de>    David J. Dachtera wrote:  E > I'm sure we'll be here to keep the newsgroup alive and support each ( > other both technically and personally.  
 I hope so.  - > Raise your glass, VMS'ers - we're the best!    Cheers.    ------------------------------  ! Date: Sun, 09 Sep 01 07:48:02 GMT  From: jmfbahciv@aol.com " Subject: Re: Big black helicopters+ Message-ID: <9nfgn7$nib$2@bob.news.rcn.net>   % In article <9nee3r$51q@web.nmti.com>, *    peter@abbnm.com (Peter da Silva) wrote:; >In article <3b99bf7b.427983836@news.jamison1.pa.home.com>, ; >politics2000@hotmail.com <politics2000@hotmail.com> wrote: D >> What needs to be defined, evidently, is the purpose of anti-trustE >> legislation.  Its intent is to protect CONSUMERS, not competitors, H >> from a monopoly.  The parade of "witnesses" in the Microsoft case had, >> very few (if any) dissatisfied customers. > G >Customers are not in a position to see the strong-arm tactics going on 9 >behind the scenes, yet they can still be harmed by them.   : I saw it as a so-called customer.  I was trying to get JMF; a laptop so he'ld be able to communicate with his coworkers < when he had his last bout of cancer.  He wanted a Unix based9 system but I was told that it takes six months to install ; it on a laptop.  Howvever if I wanted Misoftshit, then they * could ship the fucking thing out that day.  2 The antitrust was about all the wrong things, IMO.     /BAH  ' Subtract a hundred and four for e-mail.    ------------------------------   Date: 9 Sep 2001 09:56:55 -0700 4 From: gherbert@gw.retro.com (George William Herbert)" Subject: Re: Big black helicopters' Message-ID: <9ng70n$4bc$1@gw.retro.com>    <jmfbahciv@aol.com> wrote:+ >   peter@abbnm.com (Peter da Silva) wrote: < >>politics2000@hotmail.com <politics2000@hotmail.com> wrote:E >>> What needs to be defined, evidently, is the purpose of anti-trust F >>> legislation.  Its intent is to protect CONSUMERS, not competitors,I >>> from a monopoly.  The parade of "witnesses" in the Microsoft case had - >>> very few (if any) dissatisfied customers.  >>H >>Customers are not in a position to see the strong-arm tactics going on: >>behind the scenes, yet they can still be harmed by them. > ; >I saw it as a so-called customer.  I was trying to get JMF < >a laptop so he'ld be able to communicate with his coworkers= >when he had his last bout of cancer.  He wanted a Unix based : >system but I was told that it takes six months to install< >it on a laptop.  Howvever if I wanted Misoftshit, then they+ >could ship the fucking thing out that day.  > 3 >The antitrust was about all the wrong things, IMO.   9 So get some friends together and file a private antitrust 7 action on the grounds that MS has denied you commercial 1 access to dual-boot or preinstalled Unix systems.      -george william herbert  gherbert@retro.com   ------------------------------  % Date: Sun, 09 Sep 2001 14:27:35 +0200 < From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@home.com>; Subject: Re: Converting a stream_lf file to a variable file ( Message-ID: <3B9B6037.531D6DE1@home.com>  > Sure, SET FILE/ATTR may work. The very important question here is:   8   "Is the *internal* format (contents) of the file OK ?"  , (One could DUMP a disk block and check that)  < If YES, you could almost always do a SET FILE/ATTRIB to have< the file header match the internal format. And then have RMS? "serve" the file content in an acceptable format to EDT or some A other application. This is the case with FTP'ed BACKUP saveset's. ; FTP (if done in BIN mode) don't touch the *contents* of the @ saveset, it just sets some bits in the header wrong (such as the7 records lenght). Set them right and all should be fine.   = If NO, you have to have the file read and rewritten with some B tool to "fix" the internal format. May it be CONVET/FDL, ZIP/UNZIP3 or writing some 3G tool to "copy" the file content.   > It's importent to stress that SET FILE/ATTRIB don't change the? *contents* of the file in any way, just the *interpretation* of A the file contents and how the file is "seen" by applications. RMS  takes care of that.    Jan-Erik Sderholm.        "David J. Dachtera" wrote: >  > Jan-Erik Sderholm wrote:  > >  > > Hi. ? > > Just FYI, if you need to convert <LF> (aka. UNIX-text file) C > > into <CR><LF> pairs, you could just ZIP it with the "-l" switch 8 > > (see below) and then just unzip your converted file. > ! > Indeed - I've used that myself.  > ! > Though in David Spencer's case,  > $ > $ SET FILE/ATTR=RFM=STMCR filespec >  > ...may suffice. Dunno... >  > -- > David J. Dachtera  > dba DJE Systems  > http://www.djesys.com/ > * > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/    ------------------------------  $ Date: Sun, 9 Sep 2001 13:47:27 +0200" From: "Hans Vlems" <hvlems@iae.nl> Subject: Re: Dear HP... ( Message-ID: <9nfksr$c9p$1@news.IAEhv.nl>  K In short, those that run (ran?) Compaq have no clue what running a business H is about. That is, they watch Wall Street and upon the signals generated there.C Now those signals have nothing to do with products, but rather with  perception, J guesses and at best business economics 101. Wall Street couldn't care lessL whether Compaq (or HP for that matter) builds computers or refrigerators. In factL they cannot even tell the difference since both have a bid door on the front and ! blow hot air out of the backside. H Anyway, as soon as general management fails to recognize the products of their D own company you know that that company is in for big trouble. So the
 illusion that L the company must look well to Wall Str. analysts is more important than what we, G customers, were used to in the past. Which was: your vendor offers fine 	 products, E good service and a solid future. The customers spread the news, stock 	 exchanges 4 pick up on it and react (favourably) upon that news.L Now the stack market reacts negatively, irrespective if a company happens to have satisfied customers or not.   
 Hans Vlems  2 ClaudeVMS <claudevms@freevms.org> wrote in message9 news:rlBm7.67209$c8.34354308@news1.denver1.co.home.com... 6 > Someone always has to confuse the issues with facts! > G > My post was out of fustration in that I hope VMS finds a safe harbor.  > F > Let me check my Digital top seven list of really smart things to do: > I > 1. Sue hardware manufacturers for building HSC knock-offs in 1986. This  > protectionizm 8 >     pissed off many companies and potential customers.H > 2. Building a PC and forcing owners to buy pre-formatted floppies from DEC. > This was so petty J >     and totally stupid I can't imagine how a company can think this way.B > 3. Not lowering the price of VMS and competing with 'nix vendors > head-to-head. I can rememberI >     when SUN OS couldn't last through a thunderstorm without losing its   > filesystem!!! By not competing; >     with this virus its everywhere and spreading today!!! J > 4. Going to the darkside and actually building a 'nix of their own. This was  > really stupid!!! DEC competed  >     against itself!!! L > 5. Allowing their once world class service organization to become a shadow# > of itself. In 1995 I can remember L >     calling DEC for a priority 1 field problem with DMQ. The DEC engineers# > kept suggesting an upgrade to the I >     next revision instead of working the problem. This would never have  > happened in 1988. H > 6. Allowing a bozo company like Compaq buy them out. What can I say... theyI > make toy PCs and for many     years their pricing was astronomical!!! I H > bought many cheaper clones for what Compaq wanted for a single system.A > 7. DEC marketing of VMS. If the marketing department was in the - > assassination business they couldn't handle - >     it in a locked closet with a grinade!!!  >  > I > IMHO VMS has been standing on its own from the beginning!!! Standing on  > technical excellence!!! @ > None of the other cylinders in the company engine were firing. > L > So why is Alpha dead? It's just another marketing con-job. UNOBTAINIUM has > beenG > struggling for years and hopefully will soon die from natural causes.  Build  > VMS to run on all hardwareK > platforms. Go back to the brain trust that built Alpha and do it again!!! $ > It's taken Intel how many years to > catch up?  > L > Wakeup HP/Compaq!!! Do you really want to keep building hardware hosts for > Micorsoft?K > Why not leverage your corporate knowledge in VMS and build a real OS that  > can scale from the desktopI > to the global enterprise. When you control the OS you can be a services  > company - not a builder K > of binary repositories. Windows is barely based on a VMS 1.0 version. The ! > good stuff didn't start showing  > up til version 4.  >  > ClaudeVMS  >  >  >  > 4 > "Bill Todd" <billtodd@foo.mv.com> wrote in message$ > news:9ncbcl$nqr$1@pyrite.mv.net... > > 8 > > "ClaudeVMS" <claudevms@freevms.org> wrote in message= > > news:5_em7.66175$c8.33264460@news1.denver1.co.home.com... 	 > > > Hi!  > > > I > > > How much money would you require to part with VMS - and the Digital  > logo? D > > > Does anyone know of a venture cap newsgroup I can post to? ;-D > > I > > As has been observed before, VMS would have a very hard time standing  > alone.L > > For the next 2 - 3 years, even Compaq (or HP if the merger goes through)H > > will have difficulty selling it on a declared-dying platform:  could someJ > > other owner expect to do any better?  Even had Alpha's future not beenF > > truncated, the combination of VMS and Tru64 had additional synergy (common J > > development for compilers, the TCP stack, and other common components) > thatI > > VMS alone would lack.  And in any event, the VMS service organization  > would L > > be difficult to separate from the rest of Compaq's service organization. > > K > > There's a fair chance that signing Alpha's death-warrant has terminally C > > poisoned VMS and Tru64.  There's a fair chance that it has also 
 terminallyL > > poisoned Compaq, given how much its bottom line relied on these systems.L > > And there's a fair chance that merging with a terminally-poisoned CompaqK > > will do in HP.  But unless top Compaq and HP management understand this  > (andK > > care about it, rather than their personal short-term goals), there's no L > > chance that some course-change (such as backing away from the merger andJ > > resurrecting  and supporting Alpha and its systems - a bitter pill for > their K > > egos, but better for their companies than any obvious alternative) will 
 > > occur. > > 
 > > - bill > >  > > >  > > >  > > > ClaudeVMS  > >  > >  > >  >  >    ------------------------------  % Date: Sun, 09 Sep 2001 15:16:09 +0100 & From: ChrisQ <lightwork@aerosys.co.uk> Subject: Re: Dear HP... - Message-ID: <3B9B79A9.4839FB19@aerosys.co.uk>    Hans Vlems wrote:  > M > In short, those that run (ran?) Compaq have no clue what running a business J > is about. That is, they watch Wall Street and upon the signals generated > there.  T Agreed, a classic example of the tail wagging the dog. Seems to me that the computerW business is going through a period of self destruction and immolation with results more V destructively effective than any "communist plot" could have ever have dreamed about.   W Once upon a time, their were 4 good computer companies each making  good products whose Z business was built upon innovation and sound engineering, with a loyal customer base: Dec,X Tandem, Compaq (ok, but they did make good pc's) and HP. Compaq swallowed Dec and TandemZ and became smaller. Now, HP have swallowed Compaq and will become smaller. Will HP swallow. itself recursively ?. Where will it all end ?.   Chris    ------------------------------  # Date: Sun, 09 Sep 2001 06:33:58 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") Subject: Re: DECRAM in OpenVMS8 Message-ID: <00A01C47.321D4724@SSRL04.SLAC.STANFORD.EDU>  ^ In article <5jDm7.4052$_J1.152740@nntp1.chello.se>, "Michael Sjgren" <mixi@chello.se> writes:   >Dear wizards and magicians,K >A supplier of very specific software told me that DECRAM was necessary for M >good speed. The local IS/IT department says that the CACHE replaces the need  >for DECRAM.   >Which is true?    Are you on VAX or Alpha?  M DECram is a RAM disk; that is, a file-structured "device" that lives entirely K in memory.  If the software supplier tells you you need it for good speed,  L the software does quite a lot of file-type writes to disk and it'll be slow.  O I don't think cache will solve this problem because the cacheing software won't K report the write as complete until it completes to disk.  (I haven't looked L into what the XFC on 7.3 will do for you, and maybe you could turn this off, but I doubt it.)   >IS DECRAM still out there?   L I'm sure it still exists on VAX because - I think - it's used as the "systemN disk" when you run standalone backup, but I don't know if it's still a product you can buy.  N However, there are freeware RAM disk drivers which can likely do the job; I've1 never implemented one, so have no recommendation.   F >How do i get it? (Compaq Sweden assure me they have no clue what i am >talking about)  >Costs?   - DECram would cost money; the others wouldn't.    -- Alan     O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056 M  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210 O ===============================================================================    ------------------------------  % Date: Sun, 09 Sep 2001 10:43:16 +0200  From: Dirk Munk <munk@home.nl> Subject: Re: DECRAM in OpenVMS' Message-ID: <3B9B2BA4.6D4ECAFB@home.nl>    "Michael Sjgren" wrote:   > Dear wizards and magicians, L > A supplier of very specific software told me that DECRAM was necessary forN > good speed. The local IS/IT department says that the CACHE replaces the need
 > for DECRAM.  > Which is true? > IS DECRAM still out there?G > How do i get it? (Compaq Sweden assure me they have no clue what i am  > talking about)  P Perhaps Compaq Sweden is looking in the M$ software catalogue ? Or should we say M$ bugware catalogue ?  N Decram is on the normal VMS distrubution kit (page 1-6 OpenVMS Alpha June 2001O Online Documentation Library Master Index), or page 1-8 of the Software Product  LIbrary Master Index.     The UPI (=product) code is MV3AA   Regards,   Dirk     >  > Costs? > $ > Med vnlig hlsning / Best regards >  > Michael Sjgren    ------------------------------  $ Date: Sun, 9 Sep 2001 13:32:51 +0200" From: "Hans Vlems" <hvlems@iae.nl> Subject: Re: DECRAM in OpenVMS( Message-ID: <9nfk94$b26$1@news.IAEhv.nl>  H IIRC then DECRAM is a more refined product than the PD driver that comes with STABACKIT.   : Michael: the PD driver is part of SYS$UPDATE:STABACKIT.COM> Just copy that file to, say PD.MAR and open it with an editor.K Find the string PDA0 and you'll notice a little program written in MACRO32. G Strip all the DCL around it, but take note on how to assemble, link and  install H the driver. AFAIK PDA0 is not as efficient as DECRAM, but you'll find it faster than  an RZ23 ...   
 Hans Vlems  L "Alan Winston - SSRL Admin Cmptg Mgr" <winston@SSRL.SLAC.STANFORD.EDU> wrote= in message news:00A01C47.321D4724@SSRL04.SLAC.STANFORD.EDU...tG > In article <5jDm7.4052$_J1.152740@nntp1.chello.se>, "Michael Sjgren"e <mixi@chello.se> writes: >s > >Dear wizards and magicians,I > >A supplier of very specific software told me that DECRAM was necessaryn for J > >good speed. The local IS/IT department says that the CACHE replaces the need > >for DECRAM. >e > >Which is true?  >a > Are you on VAX or Alpha? > F > DECram is a RAM disk; that is, a file-structured "device" that lives entirelyL > in memory.  If the software supplier tells you you need it for good speed,H > the software does quite a lot of file-type writes to disk and it'll be slow.- >-K > I don't think cache will solve this problem because the cacheing softwarer won'tEF > report the write as complete until it completes to disk.  (I haven't lookedI > into what the XFC on 7.3 will do for you, and maybe you could turn thise off, > but I doubt it.) >p > >IS DECRAM still out there?c >yF > I'm sure it still exists on VAX because - I think - it's used as the "system H > disk" when you run standalone backup, but I don't know if it's still a product  > you can buy. >.K > However, there are freeware RAM disk drivers which can likely do the job;r I've3 > never implemented one, so have no recommendation.r >bH > >How do i get it? (Compaq Sweden assure me they have no clue what i am > >talking about) 	 > >Costs?0 >o/ > DECram would cost money; the others wouldn't.W > 	 > -- Alan  >i >, >iL ============================================================================ ===S2 >  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUA >  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:) 650/926-3056C >  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CAm
 94309-0210 >oL ============================================================================ ===c >e   ------------------------------  % Date: Sun, 09 Sep 2001 13:13:34 -0400a2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: DECRAM in OpenVMSL Message-ID: <rdeininger-0909011313340001@user-2iveck1.dialup.mindspring.com>  E In article <5jDm7.4052$_J1.152740@nntp1.chello.se>, "Michael Sjgren"g <mixi@chello.se> wrote:i   > Dear wizards and magicians,nL > A supplier of very specific software told me that DECRAM was necessary forN > good speed. The local IS/IT department says that the CACHE replaces the need
 > for DECRAM.l > Which is true?  H For some problems, file cache may make RAM disk less useful than in daysD past.  For other problems, RAM disk is likely very useful.  Ask your? software vendor and your local department each to explain their G reasoning.  The vendor, at least, should be able to supply data showing> the advantage of RAM disk.   > IS DECRAM still out there?  F Yes.  Still on the layered product CDs.  Still orderable from Compaq. = Still under active, or at least recent, development on alpha.   C DECRAM supports large RAM disks on alpha; on VAX the limit is aboutnF 500,000 blocks IIRC.  You can shadow a RAM disk with a real disk; in aF read-mostly situation, that would give you very fast data access, with good data security.   H I expect DECram is an attractive replacement for the "solid-state disks"H that have gone out of fashion, especially if you shadow to a real disk. J The solid-state disks had battery backup, while most systems these days do not have battery-backed RAM.  J RMS adds some overhead to any I/O it processes; that limits the throughput- of a DECram device.  (Unless you bypass RMS.)n  G > How do i get it? (Compaq Sweden assure me they have no clue what i amp > talking about)  G They have no clue what they are talking about.  I suggest you get their-G names, and email Mark Gorham (Compaq VP in charge of openVMS) about thekI situation. Ask him to cause some knowledgeable VMS folks to contact you. t7 Maybe you should give your local folks one more chance.3     > Costs?  F I don't know.  It's on the hobbyist license, and both the CSLG and theJ educational program in the U.S.  Like most VMS software products, I assume/ you can arrange a free 60-day loan from Compaq.o   -- o Robert Deininger rdeininger@mindspring.comi   ------------------------------  $ Date: Sat, 8 Sep 2001 00:34:15 +0100. From: Roger Barnett <roger@natron.demon.co.uk>! Subject: Re: EV7 will never ship? 1 Message-ID: <79TVpVA3lVm7EwQL@natron.demon.co.uk>   9 In article <3B96C025.2267D829@fsi.net>, David J. Dachterat <djesys.nospam@fsi.net> writes >c= >How do you "poison" a system so it can't run Linux? ...*BSD?e > F >Same line of thinking. By M$'s line of thought, Linux and *BSD shouldF >get a cut of every machine sold that might possibly run one of those.    C My point was that its all very well salesbods talking about runningaC multiple operating systems on a single system, but the word is that,B Microsoft's licensing explicitly forbids an OEM from offering suchD a beast. If this is the case then such systems will not run Windows.  C [ Of course this could be seen as a requirement for an "enterprise-eC   ready" system, but I'm not sure it fits with the HcomPaq vision ]N    
 Roger Barnett    ------------------------------  ! Date: Sun, 09 Sep 01 07:48:54 GMTs From: jmfbahciv@aol.comn! Subject: Re: EV7 will never ship?e+ Message-ID: <9nfgor$nib$3@bob.news.rcn.net>   * In article <3B9AD4F5.501F4E92@chopin.com>,.    Diane Dufresne <chopin99@chopin.com> wrote:G >I was sad to see those wonderful Digital Sales and Marketing VPs left y Compaq because. >they were not willing to relocate to Houston. <snip>  ! Please excuse me while I <gag>.  -   /BAH  ' Subtract a hundred and four for e-mail.2   ------------------------------  # Date: Sun, 09 Sep 2001 10:00:32 GMT-5 From: "John Gemignani, Jr." <john@REMOVETHISossc.net>t Subject: Re: FTP of ASCIIcC Message-ID: <45Hm7.253335$NK1.23507646@bin3.nnrp.aus1.giganews.com>e  / This problem is with PUT from NT to VMS, right?   L I have had the same problem, and it's from the NT side.  You may have to GETG the file from the VMS side instead to be able to complete the transfer.t   -Johnq  3 "Michael Sjgren" <mixi@chello.se> wrote in messageo- news:ZmDm7.4053$_J1.152602@nntp1.chello.se...n > Dear all, L > I use the FTP modules of Hummingbird Exceed (6.0?) and Reflection (4.0) toF > transfer files back and forth between NT network and OpenVMS server.% > When i transfer binary all is well.aG > BUT, when i transfer ASCII files, the transfer stops at exactly 57344e bytesa> > every time. There is some obscure warning about user buffer.' > What is wrong and how do I cure it???v >o > TIA 4 ur timer >c > --$ > Med vnlig hlsning / Best regards >o > Michael Sjgrens >t >  >x   ------------------------------  $ Date: Sat, 8 Sep 2001 23:53:23 -0700+ From: "Dennis O'Connor" <dmoc@primenet.com>  Subject: Re: I hate Compaq, Message-ID: <9nf3m0$9k$1@nnrp2.phx.gblx.net>  2 "aaron spink" <aaronspink@earthlink.net> wrote ...1 >  But then again, I believe that Intel is eithermN > the #1 or #2 total semiconductor vendor in the world as far as wafer volume.  K Pre-bust, I'm pretty sure Intel was #1 in wafer starts. Probably still are.mB And #1 in chip-industry capital spending, by a large margin. IIRC.   Fabs-R-Us, as it were. --3 Dennis O'Connor                   dmoc@primenet.com . Vanity Web Page http://www.primenet.com/~dmoc/ Not speaking for Intel.    ------------------------------   Date: 9 Sep 2001 09:50:58 GMT ( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: I hate Compaq0 Message-ID: <9nfe22$nu2$1@pegasus.csx.cam.ac.uk>  C In article <7vzm7.6566$5r.553083@newsread2.prod.itd.earthlink.net>,b- aaron spink <aaronspink@earthlink.net> wrote:h >e3 >"Bill Todd" <billtodd@foo.mv.com> wrote in messagem# >news:9ncakd$n76$1@pyrite.mv.net...rJ >> While I agree with the other sentiments you expressed, this one puzzles >me.K >> My impression was that processes like copper and SOI were generally usedsC >> only for a few high-end products, not one's entire product line.o >oF >Intel is famous for the Copy Exactly method of process technology andM >fabrication facilities.  Some people believe that copy exactly is one of the M >things that got Intel to where it is today and got Craig Barrett his currentuI >job.  Basically, Intel has one process technology at each generation andpM >ideally only has 1 generation at a time.  This is in contrast to most of the K >other companies out there.  But then again, I believe that Intel is eitheroM >the #1 or #2 total semiconductor vendor in the world as far as wafer volume.e >tL >ie, you don't have a different process for each product, you have 1 processM >and the products better work on it.  The advantage is you just have to tweak I >that one process so it gets all the R&D resources vs tuned a process pero	 >product.   B Yes.  Any competent student of commercial economics should be able? to put together an essay explaining why either IBM's or Intel's B approach was either better or worse.  And why.  What is very clear? is that they are competing using different approaches, and thatt3 there neither approach is obviously better overall.      Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679a   ------------------------------  % Date: Sun, 09 Sep 2001 09:35:07 +0200h  From: Paul Sture <paul@sture.ch> Subject: Re: RIP Bill Gates + Message-ID: <VA.00000434.50602778@sture.ch>s  < In article <3B9AC8F5.50E57870@videotron.ca>, JF Mezei wrote: > Peter da Silva wrote:r >  4 > > ISTR IA64 is little-endian.  >  > OK, reality check time:. > M > Does it really matter if an OS is big or little endian ? I realise that youSL > need to know in order to convert data you receive from other machines, but# > other than that, does it matter ?i > K > And at the OS level, would it be a huge task to recompile Tru64 to run oni > Alpha in big endian mode ?K > (eg: are there a LOT of assumptions in the OS about the endianness of the 8 > platform ? or are they handled by the compiler/cpu  ?) >   M Dunno much about C and Unix, but from the VAX calling standard point of view:g  L When passing integers to subroutines by reference (the default in VMS), the K endianness is all important. If you want to pass an Integer:4 to a routine nE expecting an Integer:2 or Integer:1, it works fine because the least y@ significant byte is in position 0 (which is the address passed).  K Indeed, COBOL doesn't understand Integer:1, so the only sensible way is to VL use an Integer:2 (PIC S9(4) COMP in COBOLese) when an Integer:1 is expected  in the called routine.  M Changing endianness (is that a real word?) would create an awful lot of work sJ in converting such programs. Of course, this is speaking from a VMS angle. ___ 
 Paul Sture Switzerlandd   ------------------------------  $ Date: Sun, 9 Sep 2001 08:47:08 +01005 From: "Adam Price" <adam+usenet@pappnase.demon.co.uk>i Subject: Re: RIP Bill GatesHB Message-ID: <1000022766.17992.0.nnrp-13.c2deb51d@news.demon.co.uk>  U "Bill Todd" <billtodd@foo.mv.com> wrote in message news:9nel2f$m1j$1@pyrite.mv.net...e >a< > "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message( > news:3B9AC8F5.50E57870@videotron.ca... > > Peter da Silva wrote:i > >r! > > > ISTR IA64 is little-endian.r > >r > > OK, reality check time:l > >t< > > Does it really matter if an OS is big or little endian ? > B > In the context of this discussion, beyond any shadow of a doubt. >-E > The context is the 'convergence' of Tru64 and HP-UX.  The former ise4 > little-endian, the latter big-endian.  That means: >7L > 1)  Forget about transparently mingling Tru64 nodes and HP-UX nodes in the > same cluster:qL Who ever said you would get mixed HP-UX and Tru64 nodes in the same cluster?L Convergence of the OS means that at some point the two OS's will be replaced5 by one OS with at least some of the features of both.rL One example of this would be to take the Tru64 Kernel and clustering and add: the HP-UX toolset (This would probably keep Oracle happy).S Another is to just add Tru64 Cluster technology to HP-UX giving single system imaget) clustering to HP-UX (not mixed clusters).s  > I'm sure others can think of their own choice of combinations.  P Another would be to go as far as the system you have described and support mixedK OS clusters. However given that at the moment Compaq don't support mixed OSdR clusters with only a 'minor' OS revision difference let alone a major OS rev, thenS what on earth makes you think that mixed clusters with HP-UX was ever on the cards?:  J Any of these could be described as 'convergence'. In fact so long as thereG exists some kind of upgrade path from Tru64 and HP-UX then I suppose it4 counts as convergence.     >nE > a)  At the lowest level, the same application binaries won't run onxL > different-endian nodes - *even if both nodes are Alphas, or both nodes areG > Itanics* - since Tru64 binaries were complied to run on little-endiancJ > hardware and HP-UX binaries were compiled to run on big-endian hardware.  L Who ever said you would get mixed HP-UX and Tru64 nodes in the same cluster?V Why does endianness for executables matter any more than a different processor, surelyX whatever happens the binaries for one hardware architecture need to be processed in someU way before they can run on the other. If they can make mixed mode IA64/Alpha clustershV work in the same way that Tru64 clusters run at the moment then I don't see endiannessT making it any worse. (I just don't think they can make mixed processor clusters work right).   N > b)  Text-only files could be shared by both platforms (assuming they adoptedG > common cluster protocols - itself a mammoth undertaking), but no fileaF > containing integer data wider than a single byte could, because dataG > structures in files are not self-describing hence even if you knew ineH > which-endian mode the file had been created you wouldn't know - exceptL > within the application, using application code explicitly written for thisF > purpose - the structure of the data and which data elements requiredK > conversion.  If the cluster supports truly-shared devices (or even singleAH > ownership with fail-over), only same-endian nodes can handle any givenN > device unless the file structure (meta-data) on that device is changed to beG > endian-independent (or at least the file system code is changed to be= > endian-sensitive).O This is utter nonsense, all that needs to happen is that the applications agree  on what the data means. K For example take filesystems... The AdVFS filesystem will need to be portedgQ to HP-UX if HP-UX is to use it. The definition of the metadata is already agreed,dR therefore when HP-UX reads that data it will have to interpret it correctly or oneN can't call the port a success. Now we know that the HP-UX kernel and the Tru64X kernels are different or we wouldn't be having this conversation, so having a difference. in the filesystem code doesn't seem important.R As for application data, the problem is only that you have to chose one endiannessS over another and that many applications implicitly rather than explicitly make thisu choice.tQ BUT this is only a problem if you assume that mixed OS clusters are on the cards.p   >-G > 2)  Forget about moving application source code transparently betweencJ > platforms of different endianness (even if they're both running the sameJ > OS), unless you've verified that the code is in no way endian-sensitive.M > Since all DEC platforms have been little-endian since before DEC had a UnixjJ > at all (unless Ultrix ran big-endian on MIPS, 'way back when?), expect aJ > fair amount of endian-sensitive code to be out there.  (Code ported from@ > Windows environments, all of which are little-endian, is often > endian-sensitive as well.)L This is more of a problem, however the problem exists today. I suspect thereR are very few pieces of useful code which run only on Tru64, most unix applicationsT run on HP-UX too, those that don't either won't make it, or will need to be reworkedW to take endianness into account, this will be good for all as it will make the software  more portable.V Problems of software portability have always existed in the unix world and will alwaysV exist. This convergence changes nothing in that respect, it simply introduces a new OSW platform for people to write to. This platform will be easier for some to adapt to thanr others.c >fK > 3)  Forget about moving data transparently between platforms of differentTF > endianness (even if they're both running the same OS), unless you've* > verified that it's not endian-sensitive. >hL How is that different from today? If you want to move data between platformsA you find some platform independent interchange format an move it.e   SNIP.... >pN > So IMO the idea that Tru64 and HP-UX will 'converge' is poppycock.  At best,5 > HP-UX will inherit some useful features from Tru64.e$ This is a form of 'convergence' IMO.   > But Tru64 itself is K > toast, for the reasons I gave previously (plus the fact that HP-UX has 9% H > penetration in the enterprise space compared with 2% for Tru64, last I	 > heard): P Of course Tru64 as it stands is toast, so is HP-UX in it's present form, this isI fact because OS's evolve. Some of the parts will survive into the new OS,  some won't, no-one knows which.   M > "Tru64 suffers in this acquisition from being the technology of the acquireh > rather than the acquirerM This I agree with although I would suggest that the outcome would be the sametD had Compaq bought HP because HP-UX is by far the more dominant unix.  > >, from competing with an existing Unix owned by the acquirer,
 Of course.  C >from being a little-endian system that won't easily be melded with=" > the acquirer's big-endian systemD Why should it be 'melded', all that needs to happen is 'convergence'  + >, from being currently available only on a  > lame-duck hardware platform,I OK Alpha is now a lame duck platform because of the IPF announcement, but=J in what way does that make Tru64 suffer? Don't they both need to be ported to IA64?  , > and from already having given a lot of its$ > differentiating goodies to Linux."M I don't think so, the clustering given to the Linux people is not TruCluster.  AdvFS isn't running on Linux.eJ Oh and the usual enormous differentiators which come with a Unix supportedE by a large company rather than a user community, can't be given away.r
 Adam Price   ------------------------------  $ Date: Sun, 9 Sep 2001 07:02:51 -0400' From: "Bill Todd" <billtodd@foo.mv.com>  Subject: Re: RIP Bill GatesE( Message-ID: <9nfi6r$9iv$1@pyrite.mv.net>  @ "Adam Price" <adam+usenet@pappnase.demon.co.uk> wrote in message< news:1000022766.17992.0.nnrp-13.c2deb51d@news.demon.co.uk... > 4 > "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9nel2f$m1j$1@pyrite.mv.net... > >n> > > "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message* > > news:3B9AC8F5.50E57870@videotron.ca... > > > Peter da Silva wrote:t > > >t# > > > > ISTR IA64 is little-endian.b > > >  > > > OK, reality check time:r > > >s> > > > Does it really matter if an OS is big or little endian ? > >nD > > In the context of this discussion, beyond any shadow of a doubt. > >RG > > The context is the 'convergence' of Tru64 and HP-UX.  The former isu6 > > little-endian, the latter big-endian.  That means: > >tJ > > 1)  Forget about transparently mingling Tru64 nodes and HP-UX nodes in theo > > same cluster:cE > Who ever said you would get mixed HP-UX and Tru64 nodes in the same  cluster?  I Without going back and examining dozens of posts in detail, I recall that L Rob Young is one person who suggested this.  Terry Shannon may have as well:J there's been a good deal of loose talk about 'convergence' suggesting thatL it could take place relatively painlessly and transparently - that's what my post was responding to.u  E > Convergence of the OS means that at some point the two OS's will bef replaced7 > by one OS with at least some of the features of both.e  L Perhaps you should become acquainted with the discussion before presuming to dictate definitions to it.  J > One example of this would be to take the Tru64 Kernel and clustering and addg< > the HP-UX toolset (This would probably keep Oracle happy).   But likely not HP-UX users.n  H > Another is to just add Tru64 Cluster technology to HP-UX giving single system image+ > clustering to HP-UX (not mixed clusters).5  B Which probably wouldn't keep Tru64 users all that happy, from most" indications here and at tru64.org.   >A@ > I'm sure others can think of their own choice of combinations. >eL > Another would be to go as far as the system you have described and support mixeds > OS clusters.  H No, it would not, for reasons I've given elsewhere.  Nothing like a realH transparent mixing is possible - and if the the cluster isn't reasonablyL homogeneous, then it really isn't a cluster any more in the current sense of	 the term.n  ?  However given that at the moment Compaq don't support mixed OStJ > clusters with only a 'minor' OS revision difference let alone a major OS	 rev, thenhJ > what on earth makes you think that mixed clusters with HP-UX was ever on
 the cards?  J See above.  Again, perhaps you should spend some time acquainting yourself3 with the discussion before shooting off your mouth.    ...-  G > > a)  At the lowest level, the same application binaries won't run oniJ > > different-endian nodes - *even if both nodes are Alphas, or both nodes aresI > > Itanics* - since Tru64 binaries were complied to run on little-endian L > > hardware and HP-UX binaries were compiled to run on big-endian hardware. > E > Who ever said you would get mixed HP-UX and Tru64 nodes in the samee cluster?  ! Your repetition is getting silly.I  F > Why does endianness for executables matter any more than a different
 processor,  I It doesn't matter *more* for executables, but it is slightly *different*..D The statement was meant to forestall additional confusion (e.g., theJ suggestion that mixed-endianness would have fewer problems if the hardwareH were homogeneous - since the suggestion that things might work better ifH Tru64 were made big-endian had already surfaced and it wasn't clear what else might).    surelyhH > whatever happens the binaries for one hardware architecture need to be processed in some5C > way before they can run on the other. If they can make mixed modee IA64/Alpha clusterseI > work in the same way that Tru64 clusters run at the moment then I don'tT see endiannessH > making it any worse. (I just don't think they can make mixed processor
 clusters work 	 > right).r  L It's a hell of a lot easier to make a heterogeneous hardware cluster work ifB all nodes share the same endiannness (in which case a *relatively*G straight-forward port of the existing system and application software -eJ without the need to add previously-unnecessary endian-sensitivity code allJ over the map - will do the trick).  If you don't understand why, I suggestJ that you study the next paragraph more carefully than you seem to have theK first time (and add in the fact that existing cluster messages often do not E use XDR-style protocols, because they assume homogeneous endianness).d   >aH > > b)  Text-only files could be shared by both platforms (assuming they adoptedbI > > common cluster protocols - itself a mammoth undertaking), but no file.H > > containing integer data wider than a single byte could, because dataI > > structures in files are not self-describing hence even if you knew iniJ > > which-endian mode the file had been created you wouldn't know - exceptI > > within the application, using application code explicitly written forq thisH > > purpose - the structure of the data and which data elements requiredF > > conversion.  If the cluster supports truly-shared devices (or even singleJ > > ownership with fail-over), only same-endian nodes can handle any givenJ > > device unless the file structure (meta-data) on that device is changed to beeI > > endian-independent (or at least the file system code is changed to bee > > endian-sensitive).K > This is utter nonsense, all that needs to happen is that the applications  agreet > on what the data means.x  J It is not rare for applications to store integer or floating-point data inH files in a manner that will break if the application is recompiled for aI different-endian environment and run there on the same data.  Saying that K such applications must agree on what the data means is equivalent to sayingnL that they must include endian-sensitive code that would not be required in aC homogeneous-endian environment - which is precisely the condition I 2 specified above, and is decidedly non-transparent.  F > For example take filesystems... The AdVFS filesystem will need to be portedK > to HP-UX if HP-UX is to use it. The definition of the metadata is alreadyt agreed, C > therefore when HP-UX reads that data it will have to interpret it  correctly or one  > can't call the port a success.  > Which, again, is precisely what I said above:  can't you read?  0  Now we know that the HP-UX kernel and the Tru64F > kernels are different or we wouldn't be having this conversation, so having a differencet0 > in the filesystem code doesn't seem important.  J No, it just makes the port of the file system a great deal messier than itH would have been to a same-endian system if the file system (as is prettyL typical) tacitly assumes homogeneous endianness in the nodes that handle itsH meta-data instead of having been pre-built to handle mixed-endian hosts.  I > As for application data, the problem is only that you have to chose onee
 endiannessK > over another and that many applications implicitly rather than explicitly,	 make thisr	 > choice.e  / Well, yuh:  that's the point (and the problem).n  L > BUT this is only a problem if you assume that mixed OS clusters are on the cards.  , Take that up with people like Rob and Terry.   >  > > I > > 2)  Forget about moving application source code transparently betweeneL > > platforms of different endianness (even if they're both running the sameL > > OS), unless you've verified that the code is in no way endian-sensitive.J > > Since all DEC platforms have been little-endian since before DEC had a UnixL > > at all (unless Ultrix ran big-endian on MIPS, 'way back when?), expect aL > > fair amount of endian-sensitive code to be out there.  (Code ported fromB > > Windows environments, all of which are little-endian, is often > > endian-sensitive as well.)> > This is more of a problem, however the problem exists today.  H Only in mixed-Unix environments - and people have learned to expect such' problems if they run such environments.s  L That's a good deal different from the kind of transparent 'convergence' someH people appeared to be blithely anticipating:  if the 'convergence' isn'tK transparent, exactly how is it all that different from the situation today,sK where the Unixes are just acknowledged to be different and people live with  that?a  I The suggestion has been that the current two systems will 'converge' into2I one.  The reality is that if this happens, at least one of them will lose ? big-time in remaining compatible with its previous incarnation.p    I suspect thereG > are very few pieces of useful code which run only on Tru64, most unixl applicationsJ > run on HP-UX too, those that don't either won't make it, or will need to be reworked9L > to take endianness into account, this will be good for all as it will make the software > more portable.  K Nice of you to decide what's good for users:  takes out all the guess-work.lF I, on the other hand, tend to assume that if a piece of software isn'tB portable, it's because the effort to make it so was not consideredL worthwhile - which means that forcing it to be done after the fact is hardly an act of kindness.t  L > Problems of software portability have always existed in the unix world and will alwayso > exist.  < Not for people running homogeneous environments (or isolatedK sub-environments).  Which is why introducing HP-UX into a Tru64 environmentiI (or replacing Tru64 with an HP-UX variant) is not going to happen without  some serious ripples.n  I  This convergence changes nothing in that respect, it simply introduces ay new OSK > platform for people to write to. This platform will be easier for some tog
 adapt to thant	 > others.t > >dC > > 3)  Forget about moving data transparently between platforms ofi	 different H > > endianness (even if they're both running the same OS), unless you've, > > verified that it's not endian-sensitive. > >nD > How is that different from today? If you want to move data between	 platformseC > you find some platform independent interchange format an move it.t  F It's different because today a lot of people *don't have to* move dataK between platforms.  If Tru64 is replaced by an HP-UX variant, such movementp will be necessary.   > 
 > SNIP.... > >oJ > > So IMO the idea that Tru64 and HP-UX will 'converge' is poppycock.  At best,t7 > > HP-UX will inherit some useful features from Tru64.v& > This is a form of 'convergence' IMO.  H So what?  It's not the kind of 'convergence' people seemed to be talking about before you came along.   >  > > But Tru64 itself isiJ > > toast, for the reasons I gave previously (plus the fact that HP-UX has 9%J > > penetration in the enterprise space compared with 2% for Tru64, last I > > heard):pJ > Of course Tru64 as it stands is toast, so is HP-UX in it's present form, this is K > fact because OS's evolve. Some of the parts will survive into the new OS,m! > some won't, no-one knows which.k  = OSs normally (if developed by competent organizations) evolve'K *upward-compatibly*.  The only way that can happen for both Tru64 and HP-UXdK is if they remain separate systems:  this wouldn't prohibit movement towardy< greater similarity in areas where this could be accomplishedJ upward-compatibly, but would preclude the 'convergence to a single system'I path that has been under discussion (and seems likely to be what HP wouldo want to do).   >eG > > "Tru64 suffers in this acquisition from being the technology of theo acquiret > > rather than the acquirerJ > This I agree with although I would suggest that the outcome would be the sameF > had Compaq bought HP because HP-UX is by far the more dominant unix. > @ > >, from competing with an existing Unix owned by the acquirer, > Of course. >,E > >from being a little-endian system that won't easily be melded withs$ > > the acquirer's big-endian systemF > Why should it be 'melded', all that needs to happen is 'convergence'  C Easy for you to say if migrating from Tru64 to something noticeablyt@ different isn't a problem for you.  Not so easy for some others.   >s- > >, from being currently available only on ai  > > lame-duck hardware platform,K > OK Alpha is now a lame duck platform because of the IPF announcement, buteL > in what way does that make Tru64 suffer? Don't they both need to be ported
 > to IA64?  C It means that for the next two years or so (until the port has beeneF completed) customers must want Tru64 enough to be willing to invest inG hardware they know has a limited life-span - i.e., that will have to be J replaced by other non-upward-compatible hardware (and replaced fairly soonK if they want to upgrade to follow industry performance advances, though EV7iI may perform enough better than Itanic to stave that off a bit longer thaneE might be expected).  That's a bit off-putting to enterprise customerscF accustomed to still being able to run OS/360 programs natively on 21stK century IBM hardware; for that matter, it might even turn off PC types usedh5 to being able to run DOS programs on modern hardware.   G Most people weren't that upset when migrating from VAX to Alpha becauselL Alpha offered improved performance to compensate for the effort.  But movingA from EV7 to McKinley or Madison may well be an actual performance H down-grade:  for some people, this will make a high-performance platformL with long-term promise of upward compatibility (such as Power) seem a better! choice during the porting period.e   >f. > > and from already having given a lot of its& > > differentiating goodies to Linux."C > I don't think so, the clustering given to the Linux people is notn TruCluster.   J No, but it is a comparable and comprehensive clustering package which willJ make Linux clustering effective competition to Tru64's and thus dilute theK differentiating value of Tru64's clustering.  There is some common ancestryi3 as well (e.g., all the way back to Berkeley Locus).e  I And Mission Critical Linux, having been formed by former Tru64 engineers, G has brought some TruCluster flavor to other Linux products (though thatT+ doesn't fall under my quoted remark above).t   > AdvFS isn't running on Linux.i  H No, but file systems that are at least as good are (XFS and JFS, to name two).n  L > Oh and the usual enormous differentiators which come with a Unix supportedG > by a large company rather than a user community, can't be given away.-  E Those differentiators, however, require that in the case of Tru64 thefK company (HP) be willing to continue to support it as a distinct product, as I well as HP-UX.  If the other differentiators are perceived to be diluted,HE the impetus to maintain a separate product is as well.  And of courserG open-source software has its own differentiator, in that a vendor can'tHI leave you completely in the lurch by collapsing or just deciding that thea6 product you depend upon is no longer worth supporting.   - bill   ------------------------------   Date: 9 Sep 2001 12:46:56 GMTy& From: peter@abbnm.com (Peter da Silva) Subject: Re: RIP Bill Gatesu% Message-ID: <9nfoc0$m5o@web.nmti.com>l  , In article <3B9AC8F5.50E57870@videotron.ca>,/ JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:oK > (eg: are there a LOT of assumptions in the OS about the endianness of then8 > platform ? or are they handled by the compiler/cpu  ?)  K The big problem is file systems. Directory and inode structures on the disk  contain data in native format.   -- e+  `-_-'   In hoc signo hack, Peter da Silva.cE   'U`    "A well-rounded geek should be able to geek about anything."hL                                                        -- nicolai@esperi.org          Disclaimer: WWFD?   ------------------------------   Date: 9 Sep 2001 12:49:25 GMTt& From: peter@abbnm.com (Peter da Silva) Subject: Re: RIP Bill Gates % Message-ID: <9nfogl$m5q@web.nmti.com>   O In article <9nel2f$m1j$1@pyrite.mv.net>, Bill Todd <billtodd@foo.mv.com> wrote: L > 1)  Forget about transparently mingling Tru64 nodes and HP-UX nodes in the > same cluster:P  G Forget about transparently mingling HP-UX and Windows nodes in the same4I cluster, too. Microsoft may well be the ten ton gorilla that forces HP-UX  to make an endian flip.@   -- m+  `-_-'   In hoc signo hack, Peter da Silva.dE   'U`    "A well-rounded geek should be able to geek about anything."nL                                                        -- nicolai@esperi.org          Disclaimer: WWFD?   ------------------------------  % Date: Sun, 09 Sep 2001 12:05:38 -0500e' From: QjoeW.EpetersonR@Tmindspring.Ycom. Subject: Re: RIP Bill Gatese8 Message-ID: <b08npt0jng3fb2sckgmalvpojgom9860ik@4ax.com>  ; PMFJI, but this same discussion regarding big-endian versustE little-endian w.r.t. the IA64 took place in the comp.sys.tandem groupsE back when Compaq announced it would use that chip for future Himalayae
 platforms.  D It turns out that, while the IA64 instruction processing, per se, isD little-endian, an OS can set the chip's "data mode" to big-endian ifD desired.  Meaning that, for all intents and purposes for application> programming, a transition to the IA64 is no more severe than a= transition from a CISC chip to a endian-compatible RISC chip.  ```l Joee( (remove "q.w.e.r.t.y" to reply by email)  , On Sat, 08 Sep 2001 21:42:14 -0400, JF Mezei, <jfmezei.spamnot@videotron.ca> spewed forth:   >Peter da Silva wrote: >  >> ISTR IA64 is little-endian. >l >OK, reality check time: >tL >Does it really matter if an OS is big or little endian ? I realise that youK >need to know in order to convert data you receive from other machines, but " >other than that, does it matter ? >hJ >And at the OS level, would it be a huge task to recompile Tru64 to run on >Alpha in big endian mode ?lJ >(eg: are there a LOT of assumptions in the OS about the endianness of the7 >platform ? or are they handled by the compiler/cpu  ?)    ------------------------------  # Date: Sun, 09 Sep 2001 13:19:15 GMTc* From: "David Cressey" <david@dcressey.com>$ Subject: Re: Setting File Attributes6 Message-ID: <n%Jm7.657$Iw2.28606@petpeeve.ziplink.net>   Paul,p  J > There's a command file on the Freeware disk which specifically addressesK > backup saveset file attributes. IIRC it tries more than one method to geta thet# > desired results. Here's the link:o  L Thanks!  That takes care of one of my two cases.  I don't mind the fact that I solved the problem onrL my own,  but I'd be willing to bet that the solution on the freeware disk is more thorough than mine was.  : That's the right place to point people with this question.     -- Regards,     David Cresseyn     www.dcressey.com   ------------------------------  % Date: Sun, 09 Sep 2001 09:35:08 +0200   From: Paul Sture <paul@sture.ch>> Subject: Re: VMS To Be Squeezed Out Of HP's Strategic Vision ?+ Message-ID: <VA.00000435.50602908@sture.ch>n  F In article <9neivk$qs3@gap.cco.caltech.edu>, Vance R. Haemmerle wrote:5 > In article <pv3$DBezFJ$V@eisner.encompasserve.org>,e0 > Larry Kilgallen <Kilgallen@SpamCop.net> wrote: > >-C > >might be a re-badging of Tru64, or it might be running the Alpha B > >in big-endian mode.  Trying to force little-endian customers to! > >big-endian would be a mistake.e > M >   Really?  When I bought up the problems with VMS moving to a processor notiQ > able to do VAX-floats (F, D, G, H) people seemed to not have a problem with it.yP > I heard that people wouldn't mind converting all their data files.  (Of courseM > then they couldn't be shared in a cluster with VAX and Alpha machines to benL > used with programs there... unless all Alpha programs were compiled to use/ > IEEE).  Isn't this pretty much the same deal?r > R I'd suggest that it is a _much_ larger deal. Not just application data files, but R system files. Accounting, UAF and audit files spring immediately to mind, but why O stop there? Backup savesets, RMS internal structures, the file system itself...e  4 Then all the system services and RTL stuff. Shudder! ___u
 Paul Sture Switzerlanda   ------------------------------   End of INFO-VAX 2001.502 ************************