1 INFO-VAX	Tue, 28 Aug 2001	Volume 2001 : Issue 477       Contents:# Re: a bit of historical perspective # Re: a bit of historical perspective  RE: Basic VMS Question Re: Comp.os.VMS session at CETS ( compaq engineering - they're at it again$ Re: Compaq staff walk out of meeting$ Re: Compaq staff walk out of meeting$ Re: Compaq staff walk out of meeting$ Re: Compaq staff walk out of meeting$ Re: Compaq staff walk out of meeting. Re: completely off the VMS topics: Bear&Dragon) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update # Re: equivalent to _kbhit and _getch   Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium  Re: Feeling Better about Itanium Re: GNU screen for AXP/VMS Re: GNU screen for AXP/VMS Re: GNU screen for AXP/VMS Re: GNU screen for AXP/VMS; Re: Looking for Digital Serial Number Identication Resource  Mark Twain Promo Re: Mark Twain Promo1 Re: MicroVAX II - local register I/O programming? 1 Re: MicroVAX II - local register I/O programming?  Monitor - System Statistics  Re: Monitor - System Statistics  Speeding Tape Access Re: Speeding Tape Access Re: Speeding Tape Access, Re: Standalone Backup Boot Question - Solved& still can't get my UCX licensed???????* Re: still can't get my UCX licensed??????? Travan drives on OVMS  Re: V5.5-2 Password Recovery Re: V5.5-2 Password Recovery Re: V5.5-2 Password Recovery Re: VMS Hobbyist Program Re: VMS Hobbyist Program Re: VMS Hobbyist Program# Why continue with OpenVMS / Compaq? ' Re: Why continue with OpenVMS / Compaq? : Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?: Re: [Q]: How to get BACKUP to relabel tapes automatically?  F ----------------------------------------------------------------------    Date: 27 Aug 2001 18:30:03 -0500+ From: kuhrt@encompasserve.org (Marty Kuhrt) , Subject: Re: a bit of historical perspective3 Message-ID: <+6LbDOB6H$Ar@eisner.encompasserve.org>   \ In article <3B7D5458.3FC19B2A@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Alan Greig wrote: B >> The Federal Trading Commission (FTC) is making an extraordinaryI >> condition on Digital's sale of its semiconductor operations to Intel -  >  >> So much for regulation. > M > Compaq is based in Texas. The person currently living in the White House is  > based in Texas.    Using your logic...   I You're from Canada, and so is Terry Jacks, the guy who performed "Seasons F in the Sun".  Finally, I have someone to blame for that horrible song!   ------------------------------  % Date: Mon, 27 Aug 2001 20:39:01 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> , Subject: Re: a bit of historical perspective' Message-ID: <3B8AF635.BE102008@fsi.net>    Marty Kuhrt wrote: > ^ > In article <3B7D5458.3FC19B2A@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > > Alan Greig wrote: D > >> The Federal Trading Commission (FTC) is making an extraordinaryK > >> condition on Digital's sale of its semiconductor operations to Intel -  > >  > >> So much for regulation. > > O > > Compaq is based in Texas. The person currently living in the White House is  > > based in Texas.  >  > Using your logic...  > K > You're from Canada, and so is Terry Jacks, the guy who performed "Seasons H > in the Sun".  Finally, I have someone to blame for that horrible song!  2 WOW! Now *THAT* is a *LONG* time to hold a grudge!   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Mon, 27 Aug 2001 18:13:33 -0600  From: yyyc186@mindspring.com Subject: RE: Basic VMS Question ; Message-ID: <3b8ae250$1$lllp186$mr2ice@nntp.mindspring.com>   H In <CDA4BAD1E10ED41181AC00508B6051D3C3E2E8@grumpy.internal.hspg.com>, on 07/23/2001  :    at 01:59 PM, Andrew Robinson <arobinson@hspg.com> said:  I If you are in a critical speed, guarranteed delivery situation you should / be looking into MQ Series and ACMS combination.    Roland     >> -----Original Message----- , >> From: fabio_compaq@ep-bc.petrobras.com.br/ >> [mailto:fabio_compaq@ep-bc.petrobras.com.br]  >> Sent: 23 July 2001 12:26  >> To: Info-VAX@Mvb.Saic.Com" >> Subject: Re: Basic VMS Question >>   >>   >> Hello >>  = >> Why dont you use the "WAIT" command  to run the procedure   >> from time to time >> ????   I >I have a little wait, but the speed that the file requires processing is I >critical. Its there to allow an old legacy system to process an internet  >ordering system.  >    >>  
 >> Regards >>   >> FC  >>  H >> I have a procedure running on one of my VMS boxes which is constantly? >> checking a directory for a file which can be FTPed into it.    G >Because the file doesn't exist already, I can't monitor locks etc on a H >specific file, but I'm just checking for a file of a certain extension.   >Regards   >Andrew Robinson --  ; -----------------------------------------------------------  yyyc186@mindspring.com; -----------------------------------------------------------    ------------------------------    Date: 27 Aug 2001 18:08:12 -0500+ From: kuhrt@encompasserve.org (Marty Kuhrt) ( Subject: Re: Comp.os.VMS session at CETS3 Message-ID: <JXwhDr4TtO6Y@eisner.encompasserve.org>   p In article <00A01054.917CE6BD@SendSpamHere.ORG>, system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes:i > In article <9Jzh7.772$bB1.32697@news.cpqcorp.net>, "Sue Skonetski" <susan.skonetski@compaq.com> writes:  >>Folks, >>J >> Hoff will be having a Denizens of comp.os.vms session at CETS.  Session
 >>number 1133  >>9 >>Wednesday 4:15 in the La Jolla conference room (Hilton)  >>& >>looking forward to seeing you there. >> >>Sue  >> > L > Oh goodie... and this trip I'm bringing the camera so I can snap a shot of2 > all the ugly mugs of this forum that attend.  :) >  > See you all there. > --Q > VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM 
 >             L >   "And of course, I'm a genius, so people are naturally drawn to my fiery K >   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes  >   A I'll have to get the belt sander out to 'purdy' up my block head.    ------------------------------  % Date: Mon, 27 Aug 2001 14:27:54 -0400 " From: "Hal Kuff" <kuff@tessco.com>1 Subject: compaq engineering - they're at it again O Message-ID: <C785D8775945A5ED.E7D4868D12976029.051FE1B2DE2CC5D3@lp.airnews.net>   ' http://www.theinquirer.net/27080104.htm    ------------------------------  % Date: Mon, 27 Aug 2001 20:23:43 -0000 - From: wspencer@ap.nospam.org (Warren Spencer) - Subject: Re: Compaq staff walk out of meeting 7 Message-ID: <910AA64ACwarrenspencer1977@207.126.101.97>   0 jfmezei.spamnot@videotron.ca (JF Mezei) wrote in" <3B8A803A.3141976D@videotron.ca>:   G >Since Compaq no longer needs any fancy R&D, I wouldn't be surprised if C >this type of presentation wasn't intentionally setup to give these 3 >useless scientists a hint of where they should go.  > I >It costs a lot less to have a useless employee decide to quit on his own 6 >than to have to let him go and pay severance package. > G >Perhaps Compaq had tried to "sell" them to Intel but Intel didn't need D >them, so now Compaq will make their life not so happy and they will >leave on their own.   > I >Interesting 180 day transformation. Compaq is really getting back to its  >former pre-digital self.  >   + The part that really hurt, in my eyes, was:   L "... director of the Systems Research Center (who incidentally has resigned D and will now head up the new Microsoft Research division in Silicon 	 Valley)."   L Brain-drain to Microsoft does not help level the competitive playing field, 4 and I hope this guy is ready for a quality lobotomy.   ws   --     Warren Spencer' Senior Software Engineer (not a writer)  The Associated Press  L ** My employer does not necessarily agree with my statements - neither do I  **   ------------------------------  % Date: Mon, 27 Aug 2001 16:59:14 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> - Subject: Re: Compaq staff walk out of meeting ( Message-ID: <9mec9t$5hi$1@pyrite.mv.net>  : "Warren Spencer" <wspencer@ap.nospam.org> wrote in message1 news:910AA64ACwarrenspencer1977@207.126.101.97...    ...   - > The part that really hurt, in my eyes, was:  > D > "... director of the Systems Research Center (who incidentally has resignedE > and will now head up the new Microsoft Research division in Silicon  > Valley)."  > F > Brain-drain to Microsoft does not help level the competitive playing field,6 > and I hope this guy is ready for a quality lobotomy.  H Don't confuse research with development:  Microsoft has a truly enviableK complement of top-notch research people (IBM may have more, but I'm sure no F one else comes close), and they by and large get to work on the thingsJ they're interested in rather than stuff expected to bring in revenue a few
 quarters out.   H It's a great environment, from the little I've heard about it.  And it'sG good insurance, because it keeps MS aware of the external and potential J developments that it needs to be aware of.  Would that more U.S. companies) had that kind of longer-term perspective.   L But, of course, it only underscores the inadequacy of *Compaq's* perspective+ (if that needed any additional evidence)...    - bill   >  > ws >  > -- >  > Warren Spencer) > Senior Software Engineer (not a writer)  > The Associated Press > K > ** My employer does not necessarily agree with my statements - neither do  I  > **   ------------------------------  % Date: Mon, 27 Aug 2001 17:23:17 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> - Subject: Re: Compaq staff walk out of meeting , Message-ID: <3B8ABA33.ED88088A@videotron.ca>   Bill Todd wrote:J > It's a great environment, from the little I've heard about it.  And it'sI > good insurance, because it keeps MS aware of the external and potential L > developments that it needs to be aware of.  Would that more U.S. companies+ > had that kind of longer-term perspective.  > N > But, of course, it only underscores the inadequacy of *Compaq's* perspective  N If you view Compaq as a distribution arm of Microsoft, then it is quite normalM for Compaq not to need R&D. They exist to package distribute and sell producs  developped by Microsoft.  G So sending Compaq's brains to Intel and Microsoft will result in better @ products since product development happens there, not at Compaq.  N Compaq will most probably retain the industrial engineers that design cabinets and production lines.    ------------------------------  # Date: Mon, 27 Aug 2001 22:36:03 GMT ' From: ben_myers@charter.net (Ben Myers) - Subject: Re: Compaq staff walk out of meeting . Message-ID: <3b8acb0d.370303@news.charter.net>  B Well, as far as production lines go, I would imagine that the only> ones needed are to produce servers.  The rest is farmed out to? contract equipment manufacturers, and has been for a long time.   5 Cabinet design?  Probably farmed out too... Ben Myers   , On Mon, 27 Aug 2001 17:23:17 -0400, JF Mezei% <jfmezei.spamnot@videotron.ca> wrote:    >Bill Todd wrote: K >> It's a great environment, from the little I've heard about it.  And it's J >> good insurance, because it keeps MS aware of the external and potentialM >> developments that it needs to be aware of.  Would that more U.S. companies , >> had that kind of longer-term perspective. >>  O >> But, of course, it only underscores the inadequacy of *Compaq's* perspective  > O >If you view Compaq as a distribution arm of Microsoft, then it is quite normal N >for Compaq not to need R&D. They exist to package distribute and sell producs >developped by Microsoft.  > H >So sending Compaq's brains to Intel and Microsoft will result in betterA >products since product development happens there, not at Compaq.  > O >Compaq will most probably retain the industrial engineers that design cabinets  >and production lines.  	 Ben Myers  Spirit of Performance, Inc.  73 Westcott Road Harvard, MA 01451  tel: 978-456-3889  eFax: 810-963-0412    PayPal, MC, VISA, AMEX accepted.   ------------------------------  # Date: Mon, 27 Aug 2001 22:37:30 GMT ' From: ben_myers@charter.net (Ben Myers) - Subject: Re: Compaq staff walk out of meeting . Message-ID: <3b8acb5c.448795@news.charter.net>  D Compaq already sold a lot of engineers to Intel with the property inB Hudson, MA originally used for Alpha R&D and chip production.  NotD sure how many real engineers they have left, except to deal with the> companies to whom the manufacturing is farmed out... Ben Myers  , On Mon, 27 Aug 2001 13:15:39 -0400, JF Mezei% <jfmezei.spamnot@videotron.ca> wrote:   L >Since Compaq no longer needs any fancy R&D, I wouldn't be surprised if thisF >type of presentation wasn't intentionally setup to give these useless+ >scientists a hint of where they should go.  > N >It costs a lot less to have a useless employee decide to quit on his own than1 >to have to let him go and pay severance package.  > M >Perhaps Compaq had tried to "sell" them to Intel but Intel didn't need them, R >so now Compaq will make their life not so happy and they will leave on their own. > I >Interesting 180 day transformation. Compaq is really getting back to its  >former pre-digital self.   	 Ben Myers  Spirit of Performance, Inc.  73 Westcott Road Harvard, MA 01451  tel: 978-456-3889  eFax: 810-963-0412    PayPal, MC, VISA, AMEX accepted.   ------------------------------  % Date: Mon, 27 Aug 2001 22:16:00 +0200 , From: Didier Morandi <Didier.Morandi@gmx.ch>7 Subject: Re: completely off the VMS topics: Bear&Dragon & Message-ID: <3B8AAA80.C9DE8B09@gmx.ch>   jlsue wrote: > 	 > Didier,  > @ > I believe that diplomats are not allowed to be arrested in anyH > country.  It is particularly a problem here in the U.S. where the U.N.F > diplomats (and their families) have been involved in several serious, > crimes.  The most we can do is expel them. > E > The reasoning for this is to protect the only formal communications H > path between governments, without which there would presumably be more > wars.   D As someone replied here (thank you jlsue) I take this opportunity toC thank (again???) all of you who sent me a thousand of copies of the A eDiplomat WEB site URL http://www.ediplomat.com/main/immunity.htm E together with other good pointers and also the one on this marvellous < book I ordered at once "The History of Diplomatic Immunity":  s http://www.amazon.com/exec/obidos/tg/stores/detail/-/books/0814207405/contents/ref=pm_dp_ln_b_2/104-5621019-3986343   F I also use this (noisy) post to thank those who added their 2 euros to< the Clancy question. The answer is http://www.clancyfaq.com.  F At least, if VMS disappears, we could always keep this forum for chat,G in smoking a good lite coke and drinking a looong San Domingo cigar :-)    D. --   ------------------------------   Date: 27 Aug 2001 22:44:43 GMT3 From: mooney@dogbert.cc.ndsu.NoDak.edu (Tim Mooney) 2 Subject: Re: Conference: CETS-2001 Detailed Update. Message-ID: <9meigr$jn8$1@news.ndsu.nodak.edu>  6 In article <KiTh7.295$Ia1.66096@typhoon1.gnilink.net>,% Jeff Killeen <Jeff@IDM-IO.com> wrote:  > K > I am firm believer that Compaq's (Digital's) most painful wounds are self  > inflicted.  6 :-)  That might be common ground for you and Mr. Todd.  @ >  I do not claim to be expert on other platforms an but haven'tJ > both IBM and SUN put their customers through major hardware and software. > changes that forced source level recompiles?  F Sun's move from Motorola 68xxx to sparc in the 80s caused the need forK customer recompiles, but that's the only case I'm aware of from IBM or Sun. N I've seen some scary old code from AIX 3.2.x that will still run on AIX 4.3.x,I and (like Sun) ILP32 binaries will run on a version of the OS that's beenvN booted with an LP64 kernel.  I don't follow IBM's mainframes or AS/400 systemsK (or whatever they're calling them these days), so I'm not up on history forf them.u  ! >  If so technically how are theyuM > any less reliable as a business partner?  I think the answer is technicallyfJ > they aren't any less reliable but the did it with a lot more finesse and > didn't self-inflict wounds...f  H You're right that it's the manner in which it was done that's caused theH most concern.  I think when Sun moved from 68xxx to sparc, everyone knewD in advance the move was coming, the performance benefits at the timeG were obvious, and Sun made sure that customers knew that 68xxx binariestH would be available during the transition period.  Of these three things,- only the last has really been done by Compaq.e  M Also, especially in Sun's case, they were (and still are) a "one trick pony".tK There was no real concern in anyone's mind that Sun was going to quit doingIO UNIX and leave customers with a "dead end" after they spent years transitioningeK to a new architecture.  Of course, it turns out that Sun *did* do somethingoI like that a few years later (the move from BSD SunOS 4.x to Solaris 2.x),eJ but even then it wasn't the same kind of "dead end" that VMS or Tru64 UNIXL customers are thinking may be coming in a couple years.  You could still buy? SunOS 4.x for *years* after Solaris was Sun's bread-and-butter.i  G Architecture switches have to happen once in a great while, but they'reoN usually only done by a company that you know has a committment to the productsM making the switch, and they're done when the need for the arch switch becomes2J overwhelmingly obvious to all.  The concerns many Compaq customers have is? whether that committment truly is there, on the part of Compaq.w  H As we've seen for the past two months, people are also willing to debateI whether the need for an arch switch is certain.  Only the brightest AlphaPH engineers probably really know for certain, and we'll probably never get0 to hear their candid answer to that question is.  I The question itself is moot, at this point.  The move is going to happen.-H The real question is "What enterprise products will still be alive threeJ or five years after the architecture transition happens?".  I think that's7 what has a lot of potential Compaq customers concerned.    Timt -- <H Tim Mooney                              mooney@dogbert.cc.ndsu.NoDak.edu> Information Technology Services         (701) 231-1076 (Voice)< Room 242-J6, IACC Building              (701) 231-8541 (Fax)3 North Dakota State University, Fargo, ND 58105-5164>   ------------------------------  % Date: Mon, 27 Aug 2001 21:53:26 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>x2 Subject: Re: Conference: CETS-2001 Detailed Update, Message-ID: <3B8AF993.2C8A9B6E@videotron.ca>   Tim Mooney wrote:.L > overwhelmingly obvious to all.  The concerns many Compaq customers have isA > whether that committment truly is there, on the part of Compaq.v  K Consider the scenario where Compaq has decided that small VMS customers canpK migrate to NT today because applications already exist on NT to match their C needs. So there is no need to work hard to get them to stay on VMS.t  M And since it appears that Compaq has taken the trouble of visiting its "real"oK customers, I would surmise that the the most profitable customers have beeneN taken care of by Compaq and their fears of VMS' demise might be under control.  N However, the message is strong for the remaining customer base. Compaq doesn't care about small VMS customers.o   ------------------------------  % Date: Mon, 27 Aug 2001 22:32:47 +0200p, From: Didier Morandi <Didier.Morandi@gmx.ch>, Subject: Re: equivalent to _kbhit and _getch& Message-ID: <3B8AAE6F.E7F35F0E@gmx.ch>   Larry Kilgallen wrote: > f > In article <3B8A6229.39930386@vai.at>, "Ing. Hans-Joerg Wahmkow" <hans-joerg.wahmkow@vai.at> writes:H > > I'm doing some porting of C/C++ programs from Windows NT to OpenVMS.L > > What I need now are functions equivalent to _kbhit and _getch. Are there: > > any system services or RTL functions that I could use? > : > More people would be able to answer your question if you$ > indicated what those functions do. > B > Although you may use both Windows NT and VMS, it is not the case, > that everyone reading this newsgroup does.  B _kbhit gives you the number of times you hit the WNT box before it stopped (not) working and   C _getch tells you where has this f* key jumped out onto the floor...    (couldn't resist)a   D.   ------------------------------  % Date: Mon, 27 Aug 2001 14:44:02 -0400c' From: "Bill Todd" <billtodd@foo.mv.com> ) Subject: Re: Feeling Better about Itanium ( Message-ID: <9me4ch$puf$1@pyrite.mv.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:0yqQNkaa7p0P@eisner.encompasserve.org...i   ...    > AMD?  Ha.  That's a good one.d  K Intel doesn't appear to find them as funny as you do.  In fact, it just cutrB high-end P4 prices by another 10% or so, invalidating the previous: pre-release information it had only very recently put out.  I But P4 prices are still quite a bit higher than the newest Athlon prices,,J and P4s, despite higher clock speeds, still don't exceed (or in many cases even match) Athlon performance.   !   No one today is shipping an AMD-; > based server (neither Dell, nor Compaq, nor IBM, nor HP).y  J SMP Athlon boards are relatively recent, of course.  But they're more thanJ competitive with the best dual-processor configuations Intel has to offer:J see, for example, a recent Ace's Hardware comparison of the dual-processorB 1.4 GHz Athlon's superiority over the dual-processor 1.7 GHz Xeon.     So= > the idea here would be to go from ZERO market share in 2001G? > to a contender in 2004 because of a slight *performance* edge$  7 Plus a considerably greater *price*-performance edge...k    and1 > the capabilities to run 32bit binaries quicker?g  J Well, if you consider that the advantage that a 1.4 GHz Athlon enjoys overL the Pentium 100 MHz performance apparently offered by Merced only merits theG adjective 'quicker'.  I suspect others might use somewhat more dramaticmH descriptions for such an order-of-magnitude difference:  not many peopleE would likely be satisfied with P100 performance on today's bloatware.M  C Of course, McKinley should boost that to P200 performance.  But one D shouldn't expect AMD to stand still on the performance front either.     So in 2-3 years F > when the migration away from IA32 is begun (certainly not next year)& > everyone jumps on the AMD bandwagon?  J If, as you suggest, Intel has been so stupid as to cease producing its ownJ IA32 processors, that's exactly what they do.  But of course even then theE time-frame you're suggesting is at least several years premature:  no4K significant migration away from IA32 (except in the mid-range-and-up serveruF markets where it's *already* inadequate) will occur before 2006 at theJ earliest, if for no other reason than that AMD will be supplying an optionK that allows people to *keep* IA32 (with competitive performance) while alsopJ enjoying any benefit they find in having a 64-bit environment available at the same time.   >D > Does AMD have a server part?  C I'd suggest that a dual-processor board that beats the best similare. configuration Xeon has to offer might quality.   >h > A laugher at best.  G I'm afraid that your laughter is sounding a bit like the cackling of ane idiot.   > > > And AMD is very much losing the price performance war on the
 > desktop: >g > " > Pentium 4  August 26  October 28 >    2 GHz   $562       $401 >    1.9 GHz $375       $273 >    1.8 GHz $256       $225 >    1.7 GHz $193       -e >    1.6 GHz $163       -r  H It seems a bit disingenuous that you failed to include the (lower, for aK given performance level) Athlon prices in the above list.  But I guess that.A would have interfered with the absurd statement that preceded it.s   - bill   ------------------------------  % Date: Mon, 27 Aug 2001 14:56:59 -0400.- From: JF Mezei <jfmezei.spamnot@videotron.ca>v) Subject: Re: Feeling Better about Itaniumo, Message-ID: <3B8A97F3.C3634313@videotron.ca>   Bill Todd wrote:J > Not if AMD is still around kicking the price-performance sh1t (gee, thatM > felt awkward...) out of low-end IA64 uses with an architecture that handles ! > both 32- and 64-bit code well. -  K NT on Alpha failed partly because the big popular software wasn't availablec for it even though the OS was.  K The success of the various 64 bit platforms will depend on what software iseK available for it.  Compaq which is still a major player in the PC field has@L clearly sided with Intel on this one. And if one were to beleive Compaq (ha!N ), the main goal for the Alpha murder was to streamline their product line andK focus on a single architecture (which would lead one to beleive that Compaq ? intends to eventually drop the 8086 from its products - ha !). e  K Having said this, if Compaq focuses on IA64, it is doubtful that they wouldtL want to bother with AMD's attempt. And if Compaq doesn't sell machines basedN on AMD's architecture, then it is doubtful that Mircosoft and all others wouldL bother porting their software to that platform, unless it becomes compatible7 with IA64 at the instruction level (eg: no recompiles).r  F If, after all is said and done, Compaq supports both Intel's and AMD'sJ versions of 64 bit architectures, it will say a lot about the real reasonsD Compaq murdered Alpha since streamlining the product lines to reduce1 architectures will have been a deceiptful reason.f   ------------------------------  % Date: Mon, 27 Aug 2001 15:11:50 -0400q- From: JF Mezei <jfmezei.spamnot@videotron.ca> ) Subject: Re: Feeling Better about Itanium , Message-ID: <3B8A9B6E.529333B1@videotron.ca>   Bill Todd wrote:L > Well, if you consider that the advantage that a 1.4 GHz Athlon enjoys overN > the Pentium 100 MHz performance apparently offered by Merced only merits theI > adjective 'quicker'.  I suspect others might use somewhat more dramatic.J > descriptions for such an order-of-magnitude difference:  not many peopleG > would likely be satisfied with P100 performance on today's bloatware.e  	 Question:t  M Would the pentium emulation in Merced be an all-or-nothing thing, or could iteJ boot native 64 bit NT and only invoke the emulator bit to run 32 bit 80x86" applications inside of 64 bit NT ?  L If 32 bit 8086 applications on Merced are able to call upon native NT systemM services, the performance may not be all that bad since most of the executionqM of GUI programs tends to happen inside of the GUI system services provided by H the OS. (as per Apple's experience when they had mixed 68000 and powerpc operating system bits).g   ------------------------------  % Date: Mon, 27 Aug 2001 15:29:21 -0400n' From: "Bill Todd" <billtodd@foo.mv.com> ) Subject: Re: Feeling Better about Itaniuma( Message-ID: <9me71k$t26$1@pyrite.mv.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B8A97F3.C3634313@videotron.ca... > Bill Todd wrote:L > > Not if AMD is still around kicking the price-performance sh1t (gee, thatG > > felt awkward...) out of low-end IA64 uses with an architecture thatl handlesI" > > both 32- and 64-bit code well. >eC > NT on Alpha failed partly because the big popular software wasn'te	 availableu  > for it even though the OS was.  I Whether NT on Alpha 'failed' for such reasons depends on what one thoughtgK the goals of NT on Alpha were.  But in any case, Alpha emphatically did notlL fail along with it, and could have wildly succeeded without it, and the same$ applies to other hardware platforms.   >iJ > The success of the various 64 bit platforms will depend on what software is > available for it.t  K True.  But Microsoft is hardly the source of all (or at the moment all that>F much) software in the server market segments under discussion here, soL plenty of hardware platforms have ample opportunity to succeed in the serverK market (all of it now, and at least the higher-end portion for considerably H longer - assuming that Windows eventually monopolizes the low-end serverJ market, which itself is far from assured, especially given the current and6 increasing levels of success Linux is enjoying there).   ...   G > Having said this, if Compaq focuses on IA64, it is doubtful that theyt wouldeH > want to bother with AMD's attempt. And if Compaq doesn't sell machines based5J > on AMD's architecture, then it is doubtful that Mircosoft and all others would-C > bother porting their software to that platform, unless it becomes 
 compatible9 > with IA64 at the instruction level (eg: no recompiles).k  G I'd suggest that DELL's actions might dominate this situation.  If DELLaK finds that a sufficient x86-64 market exists to be worth selling boxes intoiF (and AMD has made such boxes very easy to sell, given that they'll useI commodity ancillary components and run IA32 applications just fine), thenuH Compaq will ignore that market at its peril.  And if Linux leverages theH flexibility of such boxes (and IIRC Linux has already been running for aK while on an x86-64 simulator), Microsoft will also ignore them at its periloJ as low-end server competition (and Microsoft has become quite sensitive to! open-source competition of late).   J Yeah, I like to root for the underdog.  But in this case the underdogs areK also the better platforms, which makes them all the more worthy of support."   - bill   ------------------------------  % Date: Mon, 27 Aug 2001 15:38:42 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> ) Subject: Re: Feeling Better about Itaniumo( Message-ID: <9me7j2$t31$1@pyrite.mv.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B8A9B6E.529333B1@videotron.ca...   ...   L > Would the pentium emulation in Merced be an all-or-nothing thing, or could itL > boot native 64 bit NT and only invoke the emulator bit to run 32 bit 80x86$ > applications inside of 64 bit NT ? >cG > If 32 bit 8086 applications on Merced are able to call upon native NT. systemE > services, the performance may not be all that bad since most of thes	 executionlL > of GUI programs tends to happen inside of the GUI system services provided byJ > the OS. (as per Apple's experience when they had mixed 68000 and powerpc > operating system bits).T  J A good point, but it still doesn't address the times when the programs areJ actually *doing* something for the user rather than simply soliciting more6 input (presumably so that they can then do something).  J In other words, performance may often be adequate, but there'll also oftenJ be visible P100 performance:  not as bad as it might be, but also not very	 pleasant.o  K And of course for server-style applications (where GUI activity is minimal)oK and often high-end-workstation-style applications (where a lot of crunchingyI takes place between screen updates), the application performance tends to/H dominate.  And these are precisely the areas which might be attracted toL 64-bit capabilities but still run a lot of 32-bit software along with them -B so x86-64 seems a far better match for their needs than does IA64.   - bill   ------------------------------    Date: 27 Aug 2001 14:41:41 -0500+ From: young_r@encompasserve.org (Rob Young)-) Subject: Re: Feeling Better about Itaniumg3 Message-ID: <MDmMw8xog$s+@eisner.encompasserve.org>k  R In article <9me4ch$puf$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes: > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:0yqQNkaa7p0P@eisner.encompasserve.org...M > # >   No one today is shipping an AMDr< >> based server (neither Dell, nor Compaq, nor IBM, nor HP). > L > SMP Athlon boards are relatively recent, of course.  But they're more thanL > competitive with the best dual-processor configuations Intel has to offer:L > see, for example, a recent Ace's Hardware comparison of the dual-processorD > 1.4 GHz Athlon's superiority over the dual-processor 1.7 GHz Xeon. >   = 	Relatively recent.  That's correct.  And no one intending tos< 	use them.  IBM did an AMD desktop for a while and has since= 	gone the way of Dell.  One can imagine Intel lifted the tentu> 	flap and gave IBM a peak at Dell prices and got a deal in the: 	process.  Why else ditch the AMD part?  So maybe IBM doesD 	an AMD server part for a while to get a deal on Intel server parts?   >   So> >> the idea here would be to go from ZERO market share in 2001@ >> to a contender in 2004 because of a slight *performance* edge > 9 > Plus a considerably greater *price*-performance edge...t >    	Marginal at best.     >   So in 2-3 yearsnG >> when the migration away from IA32 is begun (certainly not next year)a' >> everyone jumps on the AMD bandwagon?  > L > If, as you suggest, Intel has been so stupid as to cease producing its ownL > IA32 processors, that's exactly what they do.  But of course even then theG > time-frame you're suggesting is at least several years premature:  no.M > significant migration away from IA32 (except in the mid-range-and-up serveroH > markets where it's *already* inadequate) will occur before 2006 at theL > earliest, if for no other reason than that AMD will be supplying an optionM > that allows people to *keep* IA32 (with competitive performance) while alsonL > enjoying any benefit they find in having a 64-bit environment available at > the same time. >  >> >> Does AMD have a server part?x > E > I'd suggest that a dual-processor board that beats the best similart0 > configuration Xeon has to offer might quality. >   = 	qualify?  Maybe.  Maybe someone uses it someday.  Maybe IBM.    >> >> A laugher at best.- > I > I'm afraid that your laughter is sounding a bit like the cackling of an  > idiot. >    	Thanks for the encouragement.   >>? >> And AMD is very much losing the price performance war on thee >> desktop:e >> >># >> Pentium 4  August 26  October 28i >>    2 GHz   $562       $401r >>    1.9 GHz $375       $273s >>    1.8 GHz $256       $225y >>    1.7 GHz $193       - >>    1.6 GHz $163       - > J > It seems a bit disingenuous that you failed to include the (lower, for aM > given performance level) Athlon prices in the above list.  But I guess thatnC > would have interfered with the absurd statement that preceded it.s >   B 	Actually , no.  This all changes in real-time anyhow.  And if AMDB 	expects to keep their declining desktop share, they need to slice
 	accordingly.t  F 	But back to the point... 64 bit becomes commidity someday.  Something> 	that you seem to suggest won't happen when earlier you state:  L > Higher-end servers won't be 'commodities' in anything like the same sense:I > they're far lower volume, often require the 64-bit processor and/or SMP0L > and/or robust I/O support that lower-end servers (and desktops) don't, andF > hence can't profit to anything like the same degree from many of the    B 	That isn't true because someday (4-5 years) that is all that will@ 	be shipping (64-bit) as Intel puts financial and manufacturing C 	pressure to make it so.  Intel can do whatever they want and priceoE 	accordingly.  Just enough to keep AMD barely alive so they can pointq' 	out they do indeed have "competition."t   				Robi   ------------------------------  % Date: Mon, 27 Aug 2001 16:02:30 -0400d- From: JF Mezei <jfmezei.spamnot@videotron.ca>o) Subject: Re: Feeling Better about Itaniumt, Message-ID: <3B8AA74A.37F6930C@videotron.ca>   Bill Todd wrote:M > And of course for server-style applications (where GUI activity is minimal)oM > and often high-end-workstation-style applications (where a lot of crunchingiK > takes place between screen updates), the application performance tends toeJ > dominate.  And these are precisely the areas which might be attracted toN > 64-bit capabilities but still run a lot of 32-bit software along with them -D > so x86-64 seems a far better match for their needs than does IA64.  I It really depends. If your server spends 99% of its time running a nativenK application such as the database engine, and only 1% on anciliary apps that I are not "core" but need to be on the same machine, then the slow emulatorjH allows you to move right away to Merced, get better performance for yourK majority stuff that runs native, and then just suffer a but for those small 2 utilities whose performance doesn't really matter.  E In the MAC point of view, you'd migrate to PowerPC right away becauseaJ Photoshop was available native and that was your main application, and youK didn't really care if the card game was slower because it ran in emulation.    ------------------------------  % Date: Mon, 27 Aug 2001 15:53:10 -0400t' From: "Bill Todd" <billtodd@foo.mv.com>k) Subject: Re: Feeling Better about Itanium ( Message-ID: <9me8e5$20a$1@pyrite.mv.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:MDmMw8xog$s+@eisner.encompasserve.org...BL > In article <9me4ch$puf$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes:D   ...c  G > > Higher-end servers won't be 'commodities' in anything like the samem sense:K > > they're far lower volume, often require the 64-bit processor and/or SMP J > > and/or robust I/O support that lower-end servers (and desktops) don't, andtH > > hence can't profit to anything like the same degree from many of the >s >rC > That isn't true because someday (4-5 years) that is all that willi > be shipping (64-bit)  H Double that and it *might* become believable.  Unless, of course, you'reE talking about the x86-64 approach, which I'll readily concede has thee= upward-compatibility features that would allow it to supplanteE vanilla-flavored IA32 in that time-frame (and possibly IA64 as well).e  + > as Intel puts financial and manufacturingoD > pressure to make it so.  Intel can do whatever they want and price > accordingly.  G Right:  after all, that's the kind of thinking that got DEC where it isl today.   - bill   ------------------------------  % Date: Mon, 27 Aug 2001 17:15:05 -0400o' From: "Bill Todd" <billtodd@foo.mv.com>c) Subject: Re: Feeling Better about Itaniumr( Message-ID: <9med7j$6ii$1@pyrite.mv.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B8AA74A.37F6930C@videotron.ca...   ...n  K > It really depends. If your server spends 99% of its time running a native H > application such as the database engine, and only 1% on anciliary apps thatK > are not "core" but need to be on the same machine, then the slow emulatoroJ > allows you to move right away to Merced, get better performance for yourG > majority stuff that runs native, and then just suffer a but for thoseb smalla4 > utilities whose performance doesn't really matter.  L I think you confused Merced with later versions of the architecture:  MercedD doesn't run much of *anything* (and certainly not server-style apps)B natively as fast as its better competition does, and even McKinleyJ apparently will be at best comparable to (some of) its competition (though probably not to EV7).o  I And I also think you missed the context of the material to which you wereeG responding:  desktops and lowish-end servers that don't *need* (or evengJ benefit much at all from) a 64-bit address space for their applications to2 run in - in which case, again, the far-lower-cost,E equivalent-native-performance IA32 processors will continue to be the D solutions of choice, and Rob's inane prediction that the desktop andE lower-end server world will soon become IA64's oyster will join other 6 similar prognostications on the trash-heap of history.  G So your observations about a server that is 99% dedicated to a databasefH application don't apply:  if the database is happy executing in a 32-bitJ address space (which remains and will continue to remain a pretty adequateK size for a great many uses), then a lowish-end IA32 server will be the mosttC cost-effective solution; if it requires a 64-bit address space, theGJ installation likely exceeds the capacity of what one would properly term a 'low-end' server.    - bill   ------------------------------  % Date: Mon, 27 Aug 2001 17:32:34 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>b) Subject: Re: Feeling Better about Itaniumt+ Message-ID: <3B8ABC5F.7B01BF1@videotron.ca>e   Bill Todd wrote:K > And I also think you missed the context of the material to which you weremI > responding:  desktops and lowish-end servers that don't *need* (or evenuL > benefit much at all from) a 64-bit address space for their applications to4 > run in - in which case, again, the far-lower-cost,    J Consider how many really *needed* to move from Windows 3.1 to Windows 95. L Microsoft and Intel managed to brainwash everyone into upgrading, even if itM meant that their old PCs weren't good enough and they had to buy new hardwaret as well.  E Granted, this may have been helped by the Y2K scare. But still, don'taN underestimate Microsoft's ability to  steer the sheep to yet another precipiceR and get them to blindly jump because they beleive everything Microsoft tells them.  L Microsost needs only to release one piece of software that has features onlyJ available on IA64 which generates documents not fully readable on IA32 andM you'll see the heard of sheep jumping over to IA64 just to make sure they arei compatible with everyone.\  K Granted, perhaps Microsoft's powers aren't as great now as they used to be,i  but they can still work wonders.   ------------------------------  % Date: Mon, 27 Aug 2001 22:07:47 -0000s- From: wspencer@ap.nospam.org (Warren Spencer)l) Subject: Re: Feeling Better about ItaniumI7 Message-ID: <910AB8F91warrenspencer1977@207.126.101.97>   0 jfmezei.spamnot@videotron.ca (JF Mezei) wrote in! <3B8ABC5F.7B01BF1@videotron.ca>: a     >tF >Consider how many really *needed* to move from Windows 3.1 to WindowsF >95. Microsoft and Intel managed to brainwash everyone into upgrading,H >even if it meant that their old PCs weren't good enough and they had to >buy new hardware as well. >mF >Granted, this may have been helped by the Y2K scare. But still, don'tE >underestimate Microsoft's ability to  steer the sheep to yet anotherdG >precipice and get them to blindly jump because they beleive everythingn >Microsoft tells them. u >0H >Microsost needs only to release one piece of software that has featuresG >only available on IA64 which generates documents not fully readable oniI >IA32 and you'll see the heard of sheep jumping over to IA64 just to make ) >sure they are compatible with everyone.\n >dH >Granted, perhaps Microsoft's powers aren't as great now as they used to% >be, but they can still work wonders.  >t  H I wasn't brain-washed into Win95.  Under Windows 3.1, "System Resource" D exhaustion led to daily crashes with just a few applications open.  J Microsoft ain't magic, but they are seasoned experts at forcing you off a K platform or API with a carrot & stick.  I suspect it's the "stick" portion  E of the equation that has lead to a growing disatisfaction with their  
 methods.    I Compaq appears to be trying the same approach with Alpha / IA-64, except -F they couldn't find a carrot, so they spun one up (IA-64 outperforming H Alpha).  When I bite into this hologram of a carrot, it lacks a certain L amount of substance, and getting whacked on the ass does precious little to L improve its flavor.  It's *supposed* to be:  BIG CARROT, little stick - not  the other way 'round!D   ws   -- u   Warren Spencer' Senior Software Engineer (not a writer)a The Associated Press  L ** My employer does not necessarily agree with my statements - neither do I  **   ------------------------------  % Date: Mon, 27 Aug 2001 19:28:41 -0400e' From: "Bill Todd" <billtodd@foo.mv.com> ) Subject: Re: Feeling Better about Itaniumc( Message-ID: <9mel24$ehi$1@pyrite.mv.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message% news:3B8ABC5F.7B01BF1@videotron.ca...o > Bill Todd wrote:H > > And I also think you missed the context of the material to which you wereK > > responding:  desktops and lowish-end servers that don't *need* (or even K > > benefit much at all from) a 64-bit address space for their applications  to6 > > run in - in which case, again, the far-lower-cost, >n >uK > Consider how many really *needed* to move from Windows 3.1 to Windows 95. K > Microsoft and Intel managed to brainwash everyone into upgrading, even ifp itF > meant that their old PCs weren't good enough and they had to buy new hardware
 > as well.   Completely irrelevant example.  K When Win95 *finally* appeared, 32-bit hardware had been being actively usediJ in the field for almost a decade, and 32-bit applications had been runningL in increasing numbers on that hardware for half that time.  Win3.1 toleratedG their existence via Win32s, but Win32s supported only a small subset ofiD Win32 functionality, the rest being place-holder NOPs.  ApplicationsJ (Microsoft's included) were desperate for a much more full-feature OS, andH users were waiting impatiently for things like preemptive multi-tasking:K the demand for Win95 was very real - and none of the forces that drove this4H demand apply at all to desktop and low-end server Win64 (especially on a= platform that provides lousy 32-bit application performance).r   - bill   ------------------------------  % Date: Mon, 27 Aug 2001 19:39:37 -0400k' From: "Bill Todd" <billtodd@foo.mv.com>t) Subject: Re: Feeling Better about Itaniumu( Message-ID: <9melmj$eqa$1@pyrite.mv.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:0yqQNkaa7p0P@eisner.encompasserve.org...c   ...h  > > And AMD is very much losing the price performance war on the
 > desktop:  A Aside from your misrepresentation of the actual price/performanceoL Intel-vs.-AMD situation, your statement above also seems to suggest that AMDJ is losing ground in the battle, so here's a recent (August 7th) reference:  D http://www.computerworld.com/cwi/story/0,1199,NAV47_STO62873,00.html  F "Intel controlled about 79% of the microprocessor market in the secondK quarter of this year, and Sunnyvale, Calif.-based AMD had 21%, according tooL Lehman Brothers. AMD has continually grabbed market share from Intel for theE past year, which has caused Intel to react, Niles said. In the secondmK quarter, AMD increased its processor shipments by 23% from the same quarterfI a year earlier, while Intel shipped 12% fewer processors in the same timem frame."c   - bill   ------------------------------    Date: 27 Aug 2001 18:44:41 -0500+ From: young_r@encompasserve.org (Rob Young)U) Subject: Re: Feeling Better about Itaniuma3 Message-ID: <euCW7tL$YN$U@eisner.encompasserve.org>d  R In article <9med7j$6ii$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes: > K > And I also think you missed the context of the material to which you were I > responding:  desktops and lowish-end servers that don't *need* (or evengL > benefit much at all from) a 64-bit address space for their applications to4 > run in - in which case, again, the far-lower-cost,G > equivalent-native-performance IA32 processors will continue to be thepF > solutions of choice, and Rob's inane prediction that the desktop andG > lower-end server world will soon become IA64's oyster will join othere8 > similar prognostications on the trash-heap of history. >   ! 	The inane logic flows like this:i  6 		1)  Intel will phase out IA32 according to their own	 			words.3  < 		2)  With only 64-bit offerings from Intel, this guarantees 			IA64 in the low-end space.I  @ 	I don't recall mentioning "soon" regarding the commodization ofA 	64-bit IA64 product.  It will take at least 3-5 years.  But evenj@ 	with the heavy baggage it is carrying, Merced has fairly decentB 	pricing.  It will get much better with McKinley, Intel will priceB 	it to ensure adoption.  At that point, all that is left is "priceC 	performance" arguments as McKinley will be edged in that category.eA 	But maybe not as much as you would think.  Certainly, a McKinleyb? 	4 processor server (for example) will be much cheaper than a 4M/ 	processor Power4, but trailing in performance.    				Robe   ------------------------------  % Date: Mon, 27 Aug 2001 20:18:12 -0400h' From: "Bill Todd" <billtodd@foo.mv.com>t) Subject: Re: Feeling Better about Itaniume( Message-ID: <9menuv$gsq$1@pyrite.mv.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:euCW7tL$YN$U@eisner.encompasserve.org...e   ...   6 > 1)  Intel will phase out IA32 according to their own > words. >.< > 2)  With only 64-bit offerings from Intel, this guarantees > IA64 in the low-end space.  H Not unless people will buy it.  And if Intel reduces prices to the pointJ that people will buy it rather than IA32 solutions that do the job just asG well (and run 32-bit applications a lot better), it will be paying each L customer a sizable chunk of cash rather than raking it in - a situation thatK it can't really tolerate since, unlike Microsoft, which ISTR has around $40 K billion in cash floating around at the moment, Intel has been bleeding cashtJ in record amounts recently and has very little left with which to buy such
 market share.    >sA > I don't recall mentioning "soon" regarding the commodization ofx8 > 64-bit IA64 product.  It will take at least 3-5 years.  L What you said was that the migration from the IA32 platform would begin in 2K years, which is ridiculous:  there's no demand on the horizon to drive suchhL a change and no IA64 platform on the horizon that would facilitate it in the0 absence of such demand (though x86-64 could...).  
   But evenA > with the heavy baggage it is carrying, Merced has fairly decenti
 > pricing.  F You can purchase a pretty respectable IA32 computer, complete with 19"J monitor, for the $1000+ it costs to buy the cheapest Merced *chip* (unlessG the initial prices have now dropped):  your opinion of what constitutestE 'fairly decent pricing' in the market segments we're discussing seemsm seriously flawed.y  9   It will get much better with McKinley, Intel will priced > it to ensure adoption.  B Since a Duron that will blow the doors off McKinley running 32-bitJ applications costs well under $100 these days, once again Intel would haveE to *pay* customers in this segment to use McKinley.  But since that's E exactly the low-margin market Intel said it wanted to break out of by.I creating IA64, I'm not sure why you think it would want to even if it did  have the cash to do so.d  G And since AMD's 'Hammer' is a significantly smaller chip than Merced orcJ McKinley (and based on the Athlon's high-performance core), expect it alsoH to be far more cost-effective than IA64 for those customers who actuallyE need a 64-bit platform (and, of course, much better at running 32-bitp applications).   - bill   ------------------------------    Date: 27 Aug 2001 23:34:29 -0500+ From: young_r@encompasserve.org (Rob Young) ) Subject: Re: Feeling Better about Itanium 3 Message-ID: <FkZ5tau3z1Kf@eisner.encompasserve.org>c  R In article <9menuv$gsq$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes: > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:euCW7tL$YN$U@eisner.encompasserve.org...  >  > ...' > 7 >> 1)  Intel will phase out IA32 according to their own 	 >> words.' >>= >> 2)  With only 64-bit offerings from Intel, this guaranteesi >> IA64 in the low-end space.c > J > Not unless people will buy it.  And if Intel reduces prices to the pointL > that people will buy it rather than IA32 solutions that do the job just asI > well (and run 32-bit applications a lot better), it will be paying each-N > customer a sizable chunk of cash rather than raking it in - a situation thatM > it can't really tolerate since, unlike Microsoft, which ISTR has around $40gM > billion in cash floating around at the moment, Intel has been bleeding cash L > in record amounts recently and has very little left with which to buy such > market share.y >  >>B >> I don't recall mentioning "soon" regarding the commodization of9 >> 64-bit IA64 product.  It will take at least 3-5 years.A > N > What you said was that the migration from the IA32 platform would begin in 2M > years, which is ridiculous:  there's no demand on the horizon to drive suchaN > a change and no IA64 platform on the horizon that would facilitate it in the2 > absence of such demand (though x86-64 could...). >  >   But evenB >> with the heavy baggage it is carrying, Merced has fairly decent >> pricing.b > H > You can purchase a pretty respectable IA32 computer, complete with 19"L > monitor, for the $1000+ it costs to buy the cheapest Merced *chip* (unlessI > the initial prices have now dropped):  your opinion of what constitutessG > 'fairly decent pricing' in the market segments we're discussing seemsr > seriously flawed.h > ; >   It will get much better with McKinley, Intel will pricea >> it to ensure adoption.i > D > Since a Duron that will blow the doors off McKinley running 32-bitL > applications costs well under $100 these days, once again Intel would have7 > to *pay* customers in this segment to use McKinley.     C 	You are mixing target segments and not making a very good argumentg< 	for some reason.  I mentioned McKinley and Power4.  I think> 	in the context I am highlighting servers.  After all, that isA 	where Intel thinks McKinley's target market is.  They positionedh 	Merced against UltraSparc III.i   > But since that'sG > exactly the low-margin market Intel said it wanted to break out of bypK > creating IA64, I'm not sure why you think it would want to even if it didn > have the cash to do so.  >   5 	They have $9 billion in cash.  Cash isn't a problem.n  I > And since AMD's 'Hammer' is a significantly smaller chip than Merced orhL > McKinley (and based on the Athlon's high-performance core), expect it alsoJ > to be far more cost-effective than IA64 for those customers who actuallyG > need a 64-bit platform (and, of course, much better at running 32-bitw > applications).    = 	Always these rumors, and rumors of Microsoft creating a port)@ 	of Windows 2000 to support Hammer.  I don't think that happens.  @ 	It's not a matter of needing 64 bit.  Initially, Intel's 64 bit= 	offering gets a slow start.  But it does have the support ofE< 	Linux and W2K both of which will continue to erode/supplant? 	entrenched Enterprise players.  Linux takes advantage of cheap D 	hardware and will follow that curve in the Enterprise space.  CheapB 	Enterprise hardware will be Intel based.  The hope (mine too) was@ 	to stay above that in performance to add some attractiveness or? 	incentive.  Dashed hopes.  Only IBM now seems to have anythingo@ 	to offer a few years out that will be competitive.  But pricing 	will be a big issue.n  @ 	I heard about a bargain.  A 4 processor IBM AIX box with 2 Gigs@ 	of RAM - for $100K U.S., that same configuration lists for $28KB 	today at Dell (4 processor Intel server, 4 Gigs of RAM instead of< 	2).  So maybe in a year or two, that IBM solution gets down! 	to 65K and IA64 comes in at 30K.y  - 	Apparently, the future will leave us 3 OSes:r  ; http://news.cnet.com/news/0-1003-200-6986291.html?tag=mn_hdy  O "Updating the love it has for Linux, IBM will argue Tuesday that the relativelyiO new operating system has begun fulfilling its potential as mainstream customersi  build serious servers with it. "   ...V  K "Others agree. In the next seven to eight years, Linux will largely replacerN Unix, Aberdeen analyst Bill Claybrook said in a July report. Linux will be oneK of three primary operating systems in commercial use, along with IBM's z/OS B mainframe operating system and Microsoft's Windows, he predicted."    8 	Apparently, you will still need an IBM mainframe to addB 	"management value" to Linux.  After all, if Linux is at the heart= 	of apps, why a mainframe?  Linux never gets robust enough to   	actually replace the mainframe?  C 	So I guess in the next 7-8 years IA64 will be running most of the  9 	commercial apps and a handful running on IBM mainframes.d   				Robh   ------------------------------  % Date: Mon, 27 Aug 2001 21:41:58 +0200t& From: Michael Joosten <joost@c-lab.de># Subject: Re: GNU screen for AXP/VMS3$ Message-ID: <3B8AA286.69D8@c-lab.de>   Robert Deininger wrote:e > J > In article <Pine.GSO.4.32.0108252059400.18980-100000@mars.its.yale.edu>,/ > James Metcalf <sdn6@pantheon.yale.edu> wrote:  > J > > Does anyone if it's possible to port GNU screen to VMS? Has it already+ > > been done? If so where I can I find it?. > J > Never heard of it.  What does it do?  Is it something along the lines of > the SMG library on VMS?  >   * Nono. SMG-alike would be 'Curses', right ?  E screen is a nice, 'must have' for those not having the luxury of beendF able to use multiple terminal session via X11. It's actually a sort ofG 'terminal server/multiplxer' for 'pseudo terminals', where you can manyiB terminal session sessions  under one physical session/serial line. Quite nifty.    K > Bill Gunshannon has been posting here, requesting suggestions for portingaI > projects appropriate for students.  Maybe this is a possibility, though D > you'd likely not see the result for the better part of a semester.  ? If adapter source code for VMS DECterm (or whatever the 'xterm'tH aequivalent is called) is available, this should be not too complicated,; but still a little challenging. Much system specific stuff.i  E Saying this, does anybody still have pointers to the sources of UCB'syF KIC or perhaps MAGIC? These were ECAD chip layout editors, usually forB serial graphic terminals like AEDs and the later Tektronics (41XX)@ models. They had a few porting modules for VMS, which dealt with terminal IO and such.t  E I might still have a 1/2" tape with KIC somewhere, but no tape device- 8-(-   -- -* Michael Joosten, SBS C-LAB, joost@c-lab.de* Fuerstenallee 11, 33094 Paderborn, Germany, Phone: +49 5251 606127, Fax: +49 5251 6060658 C-LAB is a cooperation of University Paderborn & SIEMENS   ------------------------------  # Date: Mon, 27 Aug 2001 21:08:06 GMTB- From: goathunter@goatley.com (Hunter Goatley) # Subject: Re: GNU screen for AXP/VMS 0 Message-ID: <3b8aadf3.31920999@news.process.com>  K On Mon, 27 Aug 2001 21:41:58 +0200, Michael Joosten <joost@c-lab.de> wrote:P  F >screen is a nice, 'must have' for those not having the luxury of beenG >able to use multiple terminal session via X11. It's actually a sort ofdH >'terminal server/multiplxer' for 'pseudo terminals', where you can manyC >terminal session sessions  under one physical session/serial line.M
 >Quite nifty.t >.E This sounds a lot like BOSS, a terminal session manager that lets you C create multiple terminal sessions from one physical session.  Check  it out here:   http://www.process.com/openvms/h  4 ftp://ftp.process.com/vms-freeware/fileserv/boss.zip  ? It doesn't keep track of the full screen layout between sessionsE changes; for that, you might check Networking Dynamics's MultiSessione or used-to-be-Raxco's WINDOW.e   Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/ 9 goathunter@goatley.com     http://www.goatley.com/hunter/'   ------------------------------  % Date: Mon, 27 Aug 2001 17:20:25 -0400P4 From: John Malmberg <Malmberg@dskwld.zko.dec.compaq># Subject: Re: GNU screen for AXP/VMSa4 Message-ID: <3B8AB999.1060906@dskwld.zko.dec.compaq>   Michael Joosten wrote:J >>In article <Pine.GSO.4.32.0108252059400.18980-100000@mars.its.yale.edu>,/ >>James Metcalf <sdn6@pantheon.yale.edu> wrote:  >> >>: >>>Does anyone if it's possible to port GNU screen to VMS?9 >>>Has it already been done? If so where I can I find it?o >>>e >   ? > screen is a nice, 'must have' for those not having the luxuryO= > of been able to use multiple terminal session via X11. It's = > actually a sort of 'terminal server/multiplxer' for 'pseudos@ > terminals', where you can many terminal session sessions under# > one physical session/serial line.- > Quite nifty.  : Now that we sort of know what screen is like.  Some of the< functionality is already in the SET TERM/DISCONNECT command,, provided that the VTA0 device is configured.  D There is also the SSU utility, which is part of the Hobbyist license layered product listing.  > This allows you to switch terminal sessions based on an escape  sequence sent from the terminal.  ; The TCPIP telnet client also has a multisession capability.e     -John' Personal Opinion Only  malmberg@dskwld.zko.dec.compaq   ------------------------------  # Date: Mon, 27 Aug 2001 21:28:51 GMT + From: jcring@switch.com (John C. Ring, Jr.)r# Subject: Re: GNU screen for AXP/VMSm, Message-ID: <9medcq$s9b$1@usenet.switch.com>  j In article <3B8AB999.1060906@dskwld.zko.dec.compaq>, John Malmberg <Malmberg@dskwld.zko.dec.compaq> wrote: >a; >Now that we sort of know what screen is like.  Some of ther= >functionality is already in the SET TERM/DISCONNECT command,a- >provided that the VTA0 device is configured.f  M Don't forget SPAWN and ATTACH!  Personally, I always got alone quite fine by rK defining keys to attach and spawn in and out of the various applications I  ' generally used in college on a VT100 :)   1 I think the GUI in front of my makes me dumber :(-   ------------------------------  # Date: Tue, 28 Aug 2001 00:38:59 GMTu2 From: "John Fredrickson" <jafred@bellatlantic.net>D Subject: Re: Looking for Digital Serial Number Identication Resource6 Message-ID: <DKBi7.123$p81.87382@typhoon1.gnilink.net>   Hoff,d  L I have yet to get it to display anything. The graphics card is a Maxtor VGA,J but when I attached the system to a monitor, keyboard, and mouse, the unitF powers up but displays no video. I also tried disconnecting the mouse,K keyboard, and monitor and connected a VT420 to the serial COM ports insteade+ (9600,N,8,1), but again obtained no output.b  J I'm still in the early phase or examining the machine. I have not given upK hope for it. I'm in the process of dismantling the machine and reconnectingfL the boards, cables, and SIMMs. I just today bought a new lithium ion battery for the CPU board.  5 When I get a console prompt, I'll learn for about it.e  < Thanks to you all for your continued help with this project.   Regards,   John Fredrickson  ? "Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in message0, news:Ffti7.830$bB1.38350@news.cpqcorp.net...L > In article <JCVh7.477$Ia1.113227@typhoon1.gnilink.net>, "John Fredrickson"! <jafred@bellatlantic.net> writes:  >mF > :Does anyone know of a resource on the web where you supply a serial numberG > :for a Digital product and get the model number, date of manufacture,, etc.?c >s3 >   AFAIK, no such resource is generally available.e > I > :I've found an old Digital Alphastation and I'd like to know more about  it..I > :It seems to be in the Alphastation 600 series box, but the front label1 has0B > :been removed. It has two numbers on the back: the serial number
 NI63800016J > :and another number 041-56514. It also has a label on it that identifies it: > :as a prototype that is not for sale outside of Digital. >wJ >   What I can tell you won't help -- the system was manufactured in Salem NH,uE >   which was one of the main manufacturing sites for the early Alpha* series.gJ >   As it is a prototype (and probably should not even be found in generalI >   circulation), you will have some problems with your particular quest.v >eH >   When the system powers up (and assuming that it does power up), whatF >   system processor identification ("KA" followed by some characters) >   number is displayed? >s > ( >  ---------------------------- #include' <rtfaq.h> -----------------------------TL >       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com, >  --------------------------- pure personal# opinion ---------------------------n1 >    Hoff (Stephen) Hoffman   OpenVMS Engineeringc hoffman#xdelta.zko.dec.com >    ------------------------------  % Date: Mon, 27 Aug 2001 15:01:34 -0400s- From: "Richard D. Piccard" <piccard@ohio.edu>r Subject: Mark Twain Promoe( Message-ID: <3B8A990C.9EC44181@ohio.edu>  G I have just received a package from Compaq, with the outside featuring:h  G "The reports of my death are greatly exaggerated." -- Mark Twain, cablet# from London to the Associate Presssh  A and inside several bookmarks with customer quotes favoring VMS, arC booklet of Mark Twain quotes., and a cover letter that includes thel? statement, "Remidns us of Compaq's OpenVMS. If Twain were to be-D reincarnated as an IT operating system, that's most likely what he'd come back as."   I thought it was kind of cute.  #                                 RDPi   --B ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  % Date: Mon, 27 Aug 2001 19:24:04 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>A Subject: Re: Mark Twain Promos' Message-ID: <3B8AE4A3.17B51E29@fsi.net>    "Richard D. Piccard" wrote:e > I > I have just received a package from Compaq, with the outside featuring:h > I > "The reports of my death are greatly exaggerated." -- Mark Twain, cable % > from London to the Associate Pressse > C > and inside several bookmarks with customer quotes favoring VMS, asE > booklet of Mark Twain quotes., and a cover letter that includes the'A > statement, "Remidns us of Compaq's OpenVMS. If Twain were to betF > reincarnated as an IT operating system, that's most likely what he'd > come back as." >   > I thought it was kind of cute.  & Oh, bloody hell! It's started already!  1 They promo'd Alpha/NT, then Alpha/NT got the axe.   < They promo'd Alpha + Tru64 and OVMS, then Alpha got the axe.  @ Anyone care to guess what gets blasted this time? (besides me in reaction to this post)   -- n David J. Dachteray dba DJE Systemsn http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Mon, 27 Aug 2001 19:38:50 GMTv+ From: Jeff Campbell <jcampbell@ins-msi.com>u: Subject: Re: MicroVAX II - local register I/O programming?+ Message-ID: <3B8A9A67.CBAF1B52@ins-msi.com>w   Timothy Stark wrote:? > Well, I need complete specs about TOY, scratch pad RAM, etc..   F Ok. The TOY clock chip contains 64 8-bit registers. The first ten holdC the time of year. The next 4 are the control/status registers named*F CSR A, CSR B, CSR C, and CSR D. The remaining 50 bytes are the scratch pad.  H The TOY and CSR registers are addressed in IO space as words, not bytes.9 The base address is 200B8000, which is the seconds value.a  3 REG  Function    Address Offset from Base  Comments 4  0   Seconds               00              read only3  1   Sec Alarm             02              not usede:  2   Minutes               04              loaded and read3  3   Min Alarm             06              not used,:  4   Hours                 08              loaded and read3  5   Hour Alarm            0A              not used73  6   Day of Week           0C              not used.:  7   Day of Month          0E              loaded and read:  8   Month                 10              loaded and read:  9   Year                  12              loaded and read: 10   CSRA                  14              loaded and read: 11   CSRB                  16              loaded and read: 12   CSRC                  18              loaded and read: 13   CSRD                  1A              loaded and read: 14   RAM byte 1            1C              scratch pad RAM: ...  ..........            ...             ...............4 63   RAM byte 50           7E              last byte  2 Register 14 is the CPMBX, console program mailbox.    CSRA defines the following bits:7  0  RS0  Set RS0-RS3 to zeros to inhibit unused outputst  1  RS1z  2  RS2k  3  RS3r5  4  DV0  Set DV0-DV2 to 2 to use 32,768 HZ oscillatorr  5  DV1e  6  DV2e/  7  UIP  read only bit, update in progress flag   F After power-up CSRA is undefined. Software must load a hex 20 into it.    CSRB defines the following bits:>  0  DSE    Daylight Saving Enable    - 1 = enable, 0 = disable5  1  24/12  24/12 hour mode bit       - 1 = 24, 0 = 12h:  2  DM     Data mode (binary or BCD) - 1 = binary, 0 = BCD  3  SQWE   not used   4  UIE    not used   5  AIE    not usedo  6  PIE    not usedoD  7  SET    Set time - 0 = normal operation, 1 = stop clock to update  F The SET bit must be set to 1 prior to updating the TOY data registers.F After power-up CSRB is undefined. Software must write a hex 6 to CSRB.F A 6 must be written to CSRB after the TOY data registers are loaded to restart the TOY clock.   CSRC and CSRD are not used.u   [snip]   >  > --4 > Timothy Stark   <><     Inet: sword7@speakeasy.orgL > --------------------------------------------------------------------------G > "For God so loved the world, that he gave his only begotten Son, thateJ > whosoever believeth in him should not perish, but have everlasting life.0 > Amen." -- John 3:16 (King James Version Bible)     HTH,  
 Jeff Campbelli n8wxs@arrl.net   ------------------------------  % Date: Tue, 28 Aug 2001 01:19:55 -00002 From: sword7@speakeasy.org: Subject: Re: MicroVAX II - local register I/O programming?/ Message-ID: <tolsdrnj99031d@corp.supernews.com>   , Jeff Campbell <jcampbell@ins-msi.com> wrote: > Timothy Stark wrote:@ >> Well, I need complete specs about TOY, scratch pad RAM, etc..  H > Ok. The TOY clock chip contains 64 8-bit registers. The first ten holdE > the time of year. The next 4 are the control/status registers named H > CSR A, CSR B, CSR C, and CSR D. The remaining 50 bytes are the scratch > pad.   > Jeff Campbell  > n8wxs@arrl.net   Jeff Campbell:  I Thank you for information!  I save it for my VAX emulator to be finished.oD However, how about CPU registers like 20080000 location?  VMB in ROM4 still am waiting for any bits in 20080000 forever...  
 Thank you!   -- Tim Stark   -- a, Timothy Stark	<><	Inet: sword7@speakeasy.orgJ --------------------------------------------------------------------------F "For God so loved the world, that he gave his only begotten Son, that H whosoever believeth in him should not perish, but have everlasting life.. Amen." -- John 3:16 (King James Version Bible)   ------------------------------  % Date: Mon, 27 Aug 2001 12:05:11 -0700n1 From: "Farrell, Michael" <MFarrell@voltdelta.com>s$ Subject: Monitor - System StatisticsO Message-ID: <8A6DD052D515D511A94E00805F578DF2114DD0@ny-exchange1.maintech1.com>c  K Has anyone seen this sort of thing on their VMS system.  We are running VMSl 7.2-1 and have seen this on allsL the V7 releases.  How can the Direct I/O rate for one process exceed that of the whole system?t   Is there a patch for this?   TIAt   Mike Farrell    L Node: HYDRA                 OpenVMS Monitor Utility     17-AUG-2001 11:35:300 Statistic: CURRENT             SYSTEM STATISTICSC                                                      Process StatesXJ           [ CPU Busy (99)           -]         LEF:    12      LEFO:     0J           |######################### |         HIB:    16      HIBO:     1J CPU     0 }--------------------------{ 100     COM:     7      COMO:     0J           |########################  |         PFW:     0      Other:    19           [--------------------------]         MWAIT:   0 B           Cur Top: BATCH_831 (94)                        Total: 37  rK           [ Page Fault Rate (0)     -]         [ Free List Size (86232)  -]rK           ||                         |         |#################         |  131KK MEMORY  0 }--------------------------{ 100   0 }--------------------------{BK           |                          |         |                          |a 32KsK           [--------------------------]         [ Modified List Size (430) ]a           Cur Top:  (0)e  eK           [ Direct I/O Rate (3)     -]         [ Buffered I/O Rate (5)   -]aK           |#                         |         |                          | K I/O     0 }--------------------------{ 60    0 }--------------------------{m 150 K           |##########################|         |                          |cK           [--------------------------]         [--------------------------]-E           Cur Top: BATCH_831 (6418)            Cur Top: BATCH_896 (2)h   ------------------------------  # Date: Mon, 27 Aug 2001 20:42:01 GMTg2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)( Subject: Re: Monitor - System Statistics2 Message-ID: <tgyi7.854$bB1.39636@news.cpqcorp.net>   In article <8A6DD052D515D511A94E00805F578DF2114DD0@ny-exchange1.maintech1.com>, "Farrell, Michael" <MFarrell@voltdelta.com> writes:nL :Has anyone seen this sort of thing on their VMS system.  We are running VMS3 :7.2-1 and have seen this on all the V7 releases.     ; :How can the Direct I/O rate for one process exceed that ofc :the whole system?  H   Well, it should not and (IIRC) does not.  IIRC, the process I/O count <   includes the cache hits and the system I/O count does not.   : ...e : COM:     7  B   This also looks interesting.  Lots of stuff waiting for the CPU?    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Mon, 27 Aug 2001 17:07:20 -0700 . From: Jack Trachtman <Jack.Trachtman@vmmc.org> Subject: Speeding Tape Access ( Message-ID: <3B8AE0B8.8C5D6AF3@vmmc.org>  E We've noticed that when accessing a file (typically a saveset) towardp the end of a DLT-IVlG tape created on our TZ89s, that it can take over an hour just to get to)	 the file.h  E I've been playing with SET MAGTAPE/SKIP=FILE:n to see if this was anyu faster, but it doesn't seem to be.e  E In response to the above, Compaq support thought that BACKUP actuallyS uses a skipfile-E function, which is why I'm not seeing any improvement in access time.1  G Does anyone have any suggestions as to how to shorten the time it takesS to get to files- toward the end of a DLT?   ------------------------------  % Date: Mon, 27 Aug 2001 20:38:08 -0500G1 From: "David J. Dachtera" <djesys.nospam@fsi.net>s! Subject: Re: Speeding Tape Accessc' Message-ID: <3B8AF600.DEE56BCD@fsi.net>+   Jack Trachtman wrote:o > G > We've noticed that when accessing a file (typically a saveset) towardh > the end of a DLT-IV I > tape created on our TZ89s, that it can take over an hour just to get ton > the file.t > G > I've been playing with SET MAGTAPE/SKIP=FILE:n to see if this was anys > faster, but it > doesn't seem to be.M > G > In response to the above, Compaq support thought that BACKUP actually  > uses a skipfileaG > function, which is why I'm not seeing any improvement in access time.h > I > Does anyone have any suggestions as to how to shorten the time it takesf > to get to files  > toward the end of a DLT?  4 Well, if you know what's on the tape, you could try:   $ SET MAGTAPE/SKIP=END ddcu:   ..., then backspace:  4 $ SET MAGTAPE/SKIP=FILE=-((number of files * 3) + 1)  ; ..., unless it would be possible to write fewer savesets...g   -- c David J. Dachterao dba DJE Systems' http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/l   ------------------------------  % Date: Tue, 28 Aug 2001 01:26:37 -0400-2 From: rdeininger@mindspring.com (Robert Deininger)! Subject: Re: Speeding Tape AccessiL Message-ID: <rdeininger-2808010126380001@user-2ive6d3.dialup.mindspring.com>  7 In article <3B8AE0B8.8C5D6AF3@vmmc.org>, Jack Trachtmant  <Jack.Trachtman@vmmc.org> wrote:  G > We've noticed that when accessing a file (typically a saveset) toward  > the end of a DLT-IVmI > tape created on our TZ89s, that it can take over an hour just to get tot > the file.o > G > I've been playing with SET MAGTAPE/SKIP=FILE:n to see if this was anyd > faster, but it > doesn't seem to be.i   What OS version?  H Is "fast skip" enabled for the tape drive?  Support for this feature hasH improved around VMS 7.2 or so (on alpha only?).  What does SHOW DEV/FULL say for the device?N  O If it's taking an hour, I guess it's pretty sure that fast skip is NOT working.    -- , Robert Deininger rdeininger@mindspring.come   ------------------------------  # Date: Tue, 28 Aug 2001 00:33:30 GMTn) From: rob.buxton@wcc.govt.nz (Rob Buxton).5 Subject: Re: Standalone Backup Boot Question - Solveda0 Message-ID: <3b8ae66c.16571538@news.wcc.govt.nz>   Hi All,.  F Yep, seems to have been some incompatibility problem between the TLZ86 and the DLT4000.  B I created another Standalone Backup on a tabletop TZ87 and the DLTC 4000 saw that okay and correctly and I could boot standalone backupe
 from that.   Gets me a starting point.,   Rob.  7 On Wed, 22 Aug 2001 22:55:01 -0500, "David J. Dachtera"a <djesys.nospam@fsi.net> wrote:   >Rob Buxton wrote: >> t
 >> Hi All, >> dG >> Trying to implement some Disaster Recovery procedures and doing some  >> testing. G >> Created Standalone Backup using STABACKIT on a VAX 4000-705A runningn >> OpenVMS 7.23 >> Tape was created on a TZ86 (connected via HSD30)p >> tE >> Transferred the Tape to a DLT4000 which I've plugged into the SCSIn >> Port of a MicroVAX 3100.: >>  A >> From >>> Tape Device shows up as a Quantum 4000, Device MKA500M >> rC >> When I put the Standalone Backup Tape into the new DLT Device itg/ >> always sets off the Use Cleaning Tape light.  >> g' >> If I try and boot from MKA500: I getn >> ?06 HLT INSTR >>          PC 00000D91  >> a >>  Bootstrap failures >>  I >> So, is this a case that I can't just use any old DLT device that comesd >> to mind?nH >> Or, that I can't use a Standalone Backup created on a VAX4000 to boot >> a MicroVAX 3100?o >>  I >> The objective is to have, off site, a selection of material that would H >> allow me to rebuild a VAX, first step was to be able to boot the VAX,I >> probably sourced from a reseller at short notice with nothing on it ine' >> the event we'd lost everything here.a >>  F >> Nope we do not have a nice Disaster Recovery site with a spare VAX!I >> And, just for good measure, we're on a fairly active fault line, got a E >> nice shake the other evening (7.0 - but the epicentre was some wayF >> off!) > I >Take care to ensure that there's no compression enabled on the Tx86 (did79 >it support that?). Otherwise, yeah - that's a tough one.$ >. >--  >David J. Dachtera >dba DJE Systems >http://www.djesys.com/c >t) >Unofficial Affordable OpenVMS Home Page:s  >http://www.djesys.com/vms/soho/   ------------------------------    Date: 27 Aug 2001 21:48:55 -0700- From: merritt.robert@spsd.sk.ca (rob merritt) / Subject: still can't get my UCX licensed???????v< Message-ID: <b6bf97d5.0108272048.717afbc@posting.google.com>   hi    > I can't seem to get my hands on the corect hobbist licenses to activate my dectcpip+ I went to the montgar site and downloaded :c   $! $!0 $!                                       GENERAL $!B $!     You are responsible for compliance with alwrite to:  Compaq Computer Corporation,tD $!     Software Business Practices, ZK01-2/D22, 110 Spit Brook Road, Nashua, NH.u $!     03062-2698. $!? $!     COMPAQ and the Compaq logo Registered in U.S. Patent and* Trademark Office.i $!     All ott $!     License Agreement $!  $ LICENSE REGISTER VAX-VMS     -      /ACTIVITY=A     -1      /AUTHORIZATION=DECUS-USA-903826-240845     -n $!     All ott $!     License Agreement $!  $ LICENSE REGISTER VAX-VMS     -      /ACTIVITY=A     -1      /AUTHORIZATION=DECUS-USA-903826-240845     -p      /DATE=27-AUG-2002     -"      /HARDWARE_ID=AB21500X8Z     -      /ISSUER=DECUS     -      /OPTIONS=(NO_SHARE)     -      /PRODUCER=DEC     -#      /TERMINATION=27-AUG-2002     --      /UNITS=0     -p$      /CHECKSUM=1-JILE-JEHG-PMJJ-DMOB $write sys$output "done"    F but of course this didn't cover the dectcp what do I need to do to get= these licenses , I couldn't find them on the distro CD either    so I end up with  E I loaded up vms 7.2 on my vax 4000/50 loaded UCX went in to configureD0 it as Ive done a million times at work and I seeD                  1  -  BIND Resolver        Requires TCPIP-IP-CLIENT PAK D                  2  -  Domain               Requires TCPIP-IP-CLIENT PAKeD                  3  -  Routing              Requires TCPIP-IP-CLIENT PAKo   ------------------------------  % Date: Tue, 28 Aug 2001 01:23:15 -0400e2 From: rdeininger@mindspring.com (Robert Deininger)3 Subject: Re: still can't get my UCX licensed??????? L Message-ID: <rdeininger-2808010123150001@user-2ive6d3.dialup.mindspring.com>  < In article <b6bf97d5.0108272048.717afbc@posting.google.com>,. merritt.robert@spsd.sk.ca (rob merritt) wrote:   > hi = > @ > I can't seem to get my hands on the corect hobbist licenses to > activate my dectcpip- > I went to the montgar site and downloaded :p  " > $ LICENSE REGISTER VAX-VMS     - >      /ACTIVITY=A     -3 >      /AUTHORIZATION=DECUS-USA-903826-240845     -     1H > but of course this didn't cover the dectcp what do I need to do to get? > these licenses , I couldn't find them on the distro CD either  >  > so I end up with >     ' You've only installed the VMS licenses.o  G Go back to the web page and request the layered product licenses.  ThisgI covers a long list of products, including UCX (or TCPIP).  These licensesP work on either vax or alpha.   -- m Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Mon, 27 Aug 2001 22:39:17 -0500t1 From: "David J. Dachtera" <djesys.nospam@fsi.net>r Subject: Travan drives on OVMS' Message-ID: <3B8B1265.29F8E80A@fsi.net>a  > Has anyone tried using and Travan (QIC) tape drives with OVMS?  F Presumably, SCSI; most likely Seagate. There's some TR4 drives on eBayH that'd work with my Wintel box + BackupExec, pretty sure. Not sure about OVMS, though...e   -- o David J. Dachteraa dba DJE Systemsb http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/.   Poor old Terry Hardy!a They buried him today. He lived the life of Riley while Riley was away...-   ------------------------------  # Date: Mon, 27 Aug 2001 22:13:06 GMT   From: jlsue <jlsuexxxz@home.com>% Subject: Re: V5.5-2 Password Recoveryr8 Message-ID: <29hlotohksebsq0i15aj442v7errotvapb@4ax.com>  A On 27 Aug 2001 08:56:57 -0700, nothome@spammers.are.scum (Malcolmt Dunnett) wrote:   4 >In article <QTsi7.819$bB1.38112@news.cpqcorp.net>, 8 >   hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes: >r >> aJ >>   In a recent conversation, one of the folks familiar with the securityL >>   plans expects most folks will be moving to external authentication via K >>   Kerberos or otherwise, particularly as the application authentication eG >>   tie-ins are made available and become more prevalent.  There is an J >>   expectation that the local authentication will be less commonly used. >>  I >    Are those application authentication hooks available (documented) in C >VMS 7.3? If not, any estimate when us mere mortals might see them?   ! Malcolm, check out the following:d  L http://www.openvms.compaq.com:8000/73final/6620/6620pro_008.html#index_x_277   and   F http://www.openvms.compaq.com:8000/73final/6647/kerberos_relnotes.html  / This is the info on using Kerberos for OpenVMS.l   HTH.   jls    ------------------------------  % Date: Mon, 27 Aug 2001 18:17:05 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> % Subject: Re: V5.5-2 Password Recovery : Message-ID: <GFzi7.17210$zP.1344281@news20.bellglobal.com>  - "Paul Sture" <paul@sture.ch> wrote in message % news:VA.0000042c.0a5021ec@sture.ch...bH > In article <5kPh7.56502$wX5.4465432@news20.bellglobal.com>, Neil Rieck wrote: [snip] > >.K > > I estimate that the runtime on an Alpha (EV5/300 MHz) is between 10 andr 20K > > days for a 6 character password (it depends on whether the password was0L > > AAAAAA, ZZZZZZ, 111111  or 999999). You would need to multiply this time by5 > > 38 for each additional character in the password.o > K > Umm, not sure what you mean here. Having read about the phenomenal number  ofL > passwords which could be tested per minute on non_VMS systems, I too had a go > at this a few months ago.y >hI > Feeding every number from 000001 to 999999 into sys$hash_password I wastI > getting 500,000 guesses a minute on my PWS 600au, using COBOL. (I had a, UAFBL > username/password validation program already, so this was just a 10 minute
 > quicky). >7   FYI,  J My busy little AlphaServer-4120 (EV5/300MHz) averages 1 million guesses inK 273 seconds. Since there are 38^6 six character passwords, a worst case runsF would require 3010936384 guesses. Divide this number by 1M and you getH 3010.9 which then is multiplied by 273 then divided by 3600 to yield 228 hours or 9.5 days.  L Since "AAAAAA" would be my first guess, this would take no time at all while "$$$$$$$$" would be worst case.-  L On my system, you would multiply 9.5 days by 38 for every character added toK the six character password. So a seven character password would require 361oF days while an eight character password would require 37.5 years. (thusH forcing criminals to look for another method until machines get faster).  H p.s. but all things considered, I think the on-going password debate hasB been quite useful to me. I hope the rest of you feel the same way.  
 Neil Rieck Kitchener/Waterloo/Cambridge,s Ontario, Canada.! http://www3.sympatico.ca/n.rieck/m   ------------------------------  % Date: Mon, 27 Aug 2001 18:20:45 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca>c% Subject: Re: V5.5-2 Password Recovery : Message-ID: <7Jzi7.17211$zP.1354374@news20.bellglobal.com>  ? "Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in messagee, news:95ti7.825$bB1.38241@news.cpqcorp.net... [snip] >lL >   Without going into details, you cannot protect against privileged users. >oI >   If you have untrusted users with privileges -- and some sites clearly0K >   have data that cannot be trusted to any individual user -- you must useeB >   the dual-password (two users present) logins and/or monitoring techniques.a >o  J Kind of like the two keys required to launch a nuclear counter-strike, eh? Thanks for the tip(s).  
 Neil Rieck Kitchener/Waterloo/Cambridge,a Ontario, Canada.! http://www3.sympatico.ca/n.rieck/    ------------------------------  % Date: Mon, 27 Aug 2001 13:51:41 -0400-- From: "Peter Weaver" <peter.weaver@stelco.ca>u! Subject: Re: VMS Hobbyist Programe2 Message-ID: <WMvi7.16826$Z2.212584@nnrp1.uunet.ca>  0 "Dan Cauley" <Cauley@telus.net> wrote in message6 news:Pcvi7.98113$b_3.12496415@news0.telusplanet.net...L > Hi there I have been trying for quite some time to contact DECUS Canada so I.H > can become a member.  I have sent several e-mails to them and have notK > gotten any response.  Could someone out there please tell me whom I mightrK > contact to get the nessacary information to join the Users group/Hobbyisto
 > Program? >...  F DECUS Canada is "dormant" according to their web site, Cathy no longerH answers e-mails (at least not my e-mails) but Ron Catcheside from CompaqJ does. There is also someone named Dave Wilson who is involved somehow, butG he doesn't even reply when Ron sends him a note asking him to answer my  questions about DECUS.  J Ron is at firstname.lastname@compaq.com if you want to ask him where DECUSK is now. Last year they didn't even have a web site so I joined the US DECUS-: as (what they called at the time) a "non-member." The pageB http://www.decus.org/encompass/Membership/join.shtml now says thatJ non-Americans can join as either a Basic (free) member or a Sustaining ($)D member. Once you join the US group then you can request the hobbyist	 licenses.-   -- Peter WeaverJ Using a WIN NT/WIN 2000 box to manage your VMS systems is like towing your7 mechanic in a 5th wheel motor home behind your Porsche.-   ------------------------------  % Date: Mon, 27 Aug 2001 14:51:00 -0400:- From: JF Mezei <jfmezei.spamnot@videotron.ca> ! Subject: Re: VMS Hobbyist Program , Message-ID: <3B8A968D.C3B41478@videotron.ca>   Dan Cauley wrote:  > N > Hi there I have been trying for quite some time to contact DECUS Canada so IH > can become a member.  I have sent several e-mails to them and have notK > gotten any response.  Could someone out there please tell me whom I might-K > contact to get the nessacary information to join the Users group/HobbyistA
 > Program?  D I don't think that there is a decus canada anymore. They had renamed- themselves to some strange name and vanished.o  K Your best bet is to join the user group formerly known as DECUS in the USA.6   ------------------------------    Date: 27 Aug 2001 11:47:09 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)"! Subject: Re: VMS Hobbyist Program , Message-ID: <B3C9zO$$O+H7@malvm5.mala.bc.ca>  = In article <Pcvi7.98113$b_3.12496415@news0.telusplanet.net>, t*    "Dan Cauley" <Cauley@telus.net> writes:  N > Hi there I have been trying for quite some time to contact DECUS Canada so IH > can become a member.  I have sent several e-mails to them and have notK > gotten any response.  Could someone out there please tell me whom I mightsK > contact to get the nessacary information to join the Users group/Hobbyist-
 > Program? > 2    I gave up on them and joined Encompass instead.  L    See http://www.encompassus.org/membership/join.html for more information.   ------------------------------  % Date: Mon, 27 Aug 2001 22:58:44 -0400 . From: Chuck McCrobie <mccrobie@cablespeed.com>, Subject: Why continue with OpenVMS / Compaq?. Message-ID: <3B8B08E4.886C2B44@cablespeed.com>  F Why do I persist in reading this newsgroup?  Its just plain depressing :(  E Between the constant rants and raves about Compaq and the messages ofh? Compaq's inadequancies, I've given up on OpenVMS and all CompaqfG equipment.  Why just today I read about Compaq's backhanded approach of  killing its R&D department :(b  F My suggestion to you die-hards is to abandon OpenVMS, Tru64, and AlphaF _IMMEDIATELY_.  Go call Sun or IBM - at least those companies want andD understand enterprise customers.  Better yet, run Windows 2000/XP onF Dell machines - that should hasten Compaq's demise into the bankruptcy courts!t  E I'm wondering just why anyone would continue/start another product oneE OpenVMS or Tru64?  Perhaps to gouge the OpenVMS suckers^H^H^H^H^H^H^H0B die-hards with high prices before Compaq pulls the plug?  FirewireE support looked like a good niche product for OpenVMS, but why bother?f  G So, even though I'm a lurker here, I'm signing off and saying good luck / to all you talented but betrayed professionals.f   ------------------------------  % Date: Mon, 27 Aug 2001 22:36:44 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>i0 Subject: Re: Why continue with OpenVMS / Compaq?' Message-ID: <3B8B11CC.A47EF750@fsi.net>M   Chuck McCrobie wrote:e > H > Why do I persist in reading this newsgroup?  Its just plain depressing > :( > G > Between the constant rants and raves about Compaq and the messages ofyA > Compaq's inadequancies, I've given up on OpenVMS and all Compaq I > equipment.  Why just today I read about Compaq's backhanded approach of  > killing its R&D department :(  > H > My suggestion to you die-hards is to abandon OpenVMS, Tru64, and AlphaH > _IMMEDIATELY_.  Go call Sun or IBM - at least those companies want andF > understand enterprise customers.  Better yet, run Windows 2000/XP onH > Dell machines - that should hasten Compaq's demise into the bankruptcy	 > courts!o > G > I'm wondering just why anyone would continue/start another product on0G > OpenVMS or Tru64?  Perhaps to gouge the OpenVMS suckers^H^H^H^H^H^H^HdD > die-hards with high prices before Compaq pulls the plug?  FirewireG > support looked like a good niche product for OpenVMS, but why bother?  > I > So, even though I'm a lurker here, I'm signing off and saying good lucks1 > to all you talented but betrayed professionals.   D When I read that "boffins" article (thank heaven for Merriam-Webster5 on-line!), I was tempted to throw in the towel, also.    I may do it yet...   -- t David J. Dachteran dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    Poor old Terry Hardy!r They buried him today. He lived the life of Riley while Riley was away...    ------------------------------   Date: 27 Aug 2001 13:03:12 CDT= From: wayne@tachysoft.xxx.374515.killspam.015f (Wayne Sewell)gC Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically? . Message-ID: <idsmzY6$MxcB@tachxxsoftxxconsult>  c In article <HzRR7oO1N22w@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:5p > In article <1UkZnXVymVWy@tachxxsoftxxconsult>, wayne@tachysoft.xxx.374515.killspam.015f (Wayne Sewell) writes: > Q >> I will mention one brief point, however -- speed of access.  The journal filessP >> appear to be organized by saveset, while the history database is organized byM >> file.  Instead of telling you which files are in a particular saveset, the N >> history database tells you which savesets contain a particular file.   EachP >> file record contains an array of pointers to the saveset records that containO >> that file.   This can make a big time difference in searching, especially ifuQ >> the file existed only for a brief period and you have no idea which saveset(s) N >> it is stored in.  Organized by file, it doesn't matter because there's only= >> *one* record for a particular file in the entire database.  > J > That sounds like a reasonable distinction, and a selling point for thoseD > who have a frequent need for single-file retrievals from uncertain > dates.  N Single files or groups of files, either on a single disk or on all disks.  The< history search accepts wildcards.  For instance a search of L mydisk:[*]login.com would find the login command procedure for every user onN mydisk, assuming the convention of every user having a top-level directory wasN followed.  Searching [*]login.com would find this procedure in every top level directory of every disk.         -- XO =============================================================================== M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxa: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)aO ===============================================================================mH Randolph Duke (in Trading Places): "Mother always said you were greedy.". Mortimer Duke: "She meant it as a compliment!"   ------------------------------   Date: 27 Aug 2001 17:48:41 CDT= From: wayne@tachysoft.xxx.374515.killspam.015f (Wayne Sewell)dC Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?-. Message-ID: <po2ppwQGjPtk@tachxxsoftxxconsult>  U In article <3B888CDD.C95A6AD7@gmx.ch>, Didier Morandi <Didier.Morandi@gmx.ch> writes:C > Larry Kilgallen wrote: >>  ? >> The default file extension for Backup Journal Files is .BJL.'> >> While you can name it anything you want, it would be in the? >> interest of communications to use the default extension name! >> in discussions here.  >>  < >> I don't understand why there would be thousands of files.: >> The format is specifically designed to be extended, and/ >> to be readable either in forward or reverse.  > G > Shame on me. I was talking of the .LOG of the batch processes running F > backups, which of course generate a .LOG (for each disk every day ifG > this is how it was designed). As I never used this feature (this is a J > looong time since I *created* VMS operation environments), I thought theD > /journal qualifier would create a .BJL for each command, and not a$ > single file with records appended.  J It appears that it can work either way.  You can have one journal file perK backup command or accumulate all the backups in one file, depending on what_: filename, if any, you specify with the /journal qualifier.   -- 0O ===============================================================================oM Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxd: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)dO =============================================================================== H Randolph Duke (in Trading Places): "Mother always said you were greedy.". Mortimer Duke: "She meant it as a compliment!"   ------------------------------   Date: 27 Aug 2001 18:11:57 CDT= From: wayne@tachysoft.xxx.374515.killspam.015f (Wayne Sewell)-C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?s. Message-ID: <w4zfK7jSf0G2@tachxxsoftxxconsult>  T In article <gP$MYURngrqc@eisner.encompasserve.org>, briggs@encompasserve.org writes:e > In article <34vla5C1uCqH@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:tq >> In article <CwFCgxJOI$Yd@tachxxsoftxxconsult>, wayne@tachysoft.xxx.374515.killspam.015f (Wayne Sewell) writes: P >>> The tapesys 6.0 format is even tighter.  The individual file record containsP >>> only the binary *version* of the file with a pointer to the file name recordO >>> and the saveset pointers.  Therefore, if a particular file has thousands ofoQ >>> versions, each of those versions requires a total of 12 + (pointer_count * 6)eM >>> bytes, where pointer_count is the number of savesets the file resides in.  >> c6 >> Still, that should limit the number of savesets to: >> T >> 	(32767-12)/6 = 5459o >> d> >> so what would happen if there were more backups than that ? > D > Well, you'd have to have more than 5459 backups with the tapes not@ > yet re-allocated.  Or the database not subsequently cleaned.      O True.  Some sites may have this many backups in a year, but unless they have anVK endless supply of tapes they don't *retain* all these backups for a year oraN more.  Once you have reinitialized a tape with another backup, the overwrittenO savesets that *were* on it can't be accessed for a restore, so there's no pointuJ in keeping them in history.  Therefore, whenever a tape is reused, tapesysD removes the dead savesets and all pointers to them from the history.  N Also, the saveset pointers are *by file*.  It would be impossible for the sameO file to be in all 5459 of the existing savesets, unless you backed up the *same-N disk* that many times.  We're talking about a physical file on a disk.  A fileN with the same name, directory, version, and even identical contents on anotherM disk would be a completely different file and would have its own entry in the.B history database and its own set of completely different pointers.  I During the history cleanup process, the savesets currently in history are:N scanned.  The creation timestamp of the saveset, i.e. the date and time of theP backup, are compared with the most recent initialization timestamp for the tape,M which can be found in the main tapesys database.  If the tape was initializedeK after the saveset was created, then the saveset has been overwritten and is>I removed from the history database.  After all the dead savesets have been>N removed, the file portion of the history database is scanned.  Some files willM have pointers to savesets that no longer exist, deleted in the previous step.,K Each of these pointers is removed and the array is closed up.  If *all* the/J pointers for a file are gone, then the file does not exist on any existing4 saveset, so the file itself is removed from history.         >And they'drE > have to be in the same history set.  (You can have more than one --o8 > monthlies and dailies and user backups, for instance). > 5 > Unfortunately, the actual answer is "I don't know".e >   
 I do.  :-)  K If the number of pointers for a file exceeds the maximum, set by the system M manager in an attribute file, the oldest backup is dropped.  In practice, the.M number of pointers is typically far less than the maximum possible for an rmse record.  More about that below.5  I A sysbak (tapesys backup job, wrapped around callable backup) generates aeN binary sequential file roughly equivalent to a journal file, i.e. a compressedN list of all the files contained in the saveset, plus other information such asH the history set name, position on the tape, etc.  It could use an actualN journal file, I suppose, except that I'm not sure journal files existed at theO time the original sysbak was written (tapesys version 4.3, 28-DEC-86).   In anyrK case, sysbak rolls it own, with a file type of .history.  At the end of theeD backup, a history update job is submitted, using this file as input.  N The history update job basically adds a new saveset record to the saveset fileN and adds a pointer to it to every file that was backed up.  The saveset recordN is added first, then the 6 byte pointer value is determined.  Then the list ofK files from the backup is scanned.  The pointer record corresponding to each0I file is located, or created if this file has never been backed up before.r  K The pointers are in reverse time order, i.e. the most recent backups first.mM Since all existing saveset pointers, if any, are assumed to be older than thetO new saveset, these pointers are all shoved down one slot and the new pointer isaI inserted in the first slot.  Thus it will appear first for that file when  history is searched later.  M The pointer record is then updated.  If the new total number of pointers, onetO more than the previous count, is less than or equal to the current maximum, the G actual number of pointers is written.  If the new number of pointers islI greater than the max, the max size is used, essentially dropping the lasttN pointer.  This of course represents the oldest backup of this particular file.    G > Yes, the limit is real.  Yes, RMS indexed files are used.  Obviously, G > clever programmers could have dealt with the issue by adding overflow.H > records with the same or slightly different primary key.  Whether they0 > actually did deal with it is another question.    M Well, I guess I'm not very clever, since the above mechanism is how it works..O My only defense is that I didn't write the original history system, as found in 0 tapesys 5.2, just the reworked one in 6.0.   :-)  N On the other hand, do you *need* to know the locations of 5459 idential copiesN of the same file in order to restore it?  All you really need most of the timeM is the location of the most recent backup of that particular file or group ofaF files.  The only reason for having multiple pointers at all is in caseO something is wrong with the most recent backup tape and you have to try to pullm" the file off the next most recent.  I The only way I can see this being a problem is if you had 5459 bad backup4L tapes in a row and never reused any of the tapes and you could have restored< the file from #5460 if it was still in the history database.        M The default number of saveset pointers in tapesys 5.2 is 6, and this has beeneN just fine for the needs of most customers.  Remember that the saveset pointersO are *by file* and do not attempt to contain the total number of active savesetsy= known to tapesys, only those containing that particular file..  K In 6.0, we upped the default all the way to 14, since we had saved a lot ofwK space with the reorganization.  We don't expect customers to need more thanhO that unless they retain tapes an unusually long time.  Of course, it's only theeM default.  The system manager can set the max pointer count to a larger value,UO depending on how many savesets are expected to be active (backed up and not yet O overwritten) at any given time.  I think one of the field test sites told me he( was using 50 pointers.   Waynen   -- eO =============================================================================== M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxb: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)oO ===============================================================================rH Randolph Duke (in Trading Places): "Mother always said you were greedy.". Mortimer Duke: "She meant it as a compliment!"   ------------------------------    Date: 27 Aug 2001 18:40:12 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?S3 Message-ID: <QRhO2rAe5QR2@eisner.encompasserve.org>e  n In article <w4zfK7jSf0G2@tachxxsoftxxconsult>, wayne@tachysoft.xxx.374515.killspam.015f (Wayne Sewell) writes:  P > Also, the saveset pointers are *by file*.  It would be impossible for the sameQ > file to be in all 5459 of the existing savesets, unless you backed up the *samevP > disk* that many times.  We're talking about a physical file on a disk.  A fileP > with the same name, directory, version, and even identical contents on anotherO > disk would be a completely different file and would have its own entry in thejD > history database and its own set of completely different pointers.  F Consider an hourly backup of SYSUAF.DAT designed to be able to restoreB to any hourly state after a disk crash.  As I understand it, those) would all be linked from the same record.S  F I am not claiming there is no better way to achieve the desired degree3 of safety, just that the example is a possible one.u   ------------------------------   End of INFO-VAX 2001.477 ************************