1 INFO-VAX	Mon, 27 Aug 2001	Volume 2001 : Issue 476       Contents: Compaq alienates top boffins  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: Conference: CETS-2001 Detailed Update  Re: DCL challenge  RE: Digital LG06 Re: DS10 and boot from fabric  equivalent to _kbhit and _getch # Re: equivalent to _kbhit and _getch # 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: Hex dump-and-lookatit-in-themorning  Re: hidden eyes  Re: I hate Compaq  Re: I hate Compaq  Re: I hate Compaq  Re: I hate Compaq  Re: I hate Compaq ; RE: Looking for Digital Serial Number Identication Resource ; Re: Looking for Digital Serial Number Identication Resource ; Re: Looking for Digital Serial Number Identication Resource ; Re: Looking for Digital Serial Number Identication Resource ; RE: Looking for Digital Serial Number Identication Resource  Re: Nits in Slides Re: Nits in Slides Re: Nits in Slides9 Re: Nits in Slides (was: Re: The Final Knell Has Sounded) 9 Re: Nits in Slides (was: Re: The Final Knell Has Sounded) 
 Re: Node Name 5 Re: Nuts-n-bolts in News (was: Re: Nits in Slides...) " Re: ODS-5 and parse_style questionP Re: Prerequisite Products and IPF Porting (was: Re: The Final Knell Has  Sounded Re: Queue/Entry management Re: Queue/Entry management TCPIP V5.0 BIND question test Re: The Final Knell Has Sounded  Re: The Final Knell Has Sounded  Re: The Final Knell Has Sounded  Re: The Final Knell Has Sounded / This Weekends Sale... All Combo Pkg\\\'s $79.99  Re: V5.5-2 Password Recovery Re: V5.5-2 Password Recovery Re: V5.5-2 Password Recovery
 VAX 3100+4, Re: VMS high reliability needed by Air Force VMS Hobbyist Program Re: VMS Hobbyist ProgramE www.motifzone.net - the site for Open Motif Developers (monthly post) : 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?: 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: Mon, 27 Aug 2001 05:00:00 -0700 (PDT) . From: Fabio Cardoso <fabiopenvms@yahoo.com.br>% Subject: Compaq alienates top boffins @ Message-ID: <20010827120000.73703.qmail@web20208.mail.yahoo.com>   The Inquirer Today     Abou Compaq ... what mess =20    Compaq alienates top boffins=20    Staff walk out of meeting=20& By Mike Magee, 27/08/2001 10:54:20 BST    2 THE INQUIRER has learned of a remarkable worldwide4 presentation inside Compaq which has resulted in the6 alienation of a number of top scientists and engineers at the troubled Houston outfit. 1 Apparently, on the 2nd of August, Compaq's global - research units were treated to a confidential 4 strategic roadmap presentation by Dr. Alex Stepanov, VP & Chief Scientist.=20  , Stepanov, a Russian, was brought in by chief3 technology officer Shane Robison to front the CTO's  office.   6 Sources tell the INQUIRER that this office was largely6 responsible for the decision to sink the Alpha iceberg in favour of the Itanic.  5 Time to re-orient the whole research organisation and 2 to look in a visionary kind of a way, ahead, then.  . According to our fly-on-the-wall, this is what3 happened next: "Dr. Stepanov's presentation was not 6 well received by the technical staff, most of whom are) blue-chip PhDs from Stanford, MIT etc.=20   2 "Stepanov lost his cool and in front of the entire2 worldwide organisation watching by teleconference,5 started bellowing in his Russian accent: 'you can all 4 quit! I have authority! Shane appointed me! You have2 never produced any good proposals! Research is not important!' and so on.=20   / "In this debut presentation to the cream of the 5 research staff, he alienated the staff and undermined 4 the credibility of the CTO office. Things got so bad1 that people walked out of the talk, including the , director of the Systems Research Center (who6 incidentally has resigned and will now head up the new/ Microsoft Research division in Silicon Valley).   5 "In short, the research component at Compaq is coming - unglued, and the new CTO office is creating a 2 hullaballoo. Morale has gotten very bad during the4 past year, since the new CTO arrived, but now it has4 gone beyond rock bottom. Expect a significant number4 of departures of talented research staff in the near future."=20   3 You can find Shane Robison's Compaq interview here. 6 Compaq was not available for comment at press time but2 we will be very happy to present Mr Robison and Dr) Stepanov's view of these proceedings. =B5          =3D=3D=3D=3D=3D L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D  F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazil  fabiopenvms@yahoo.com.brL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D   2 __________________________________________________ Do You Yahoo!?H Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/    ------------------------------  % Date: Mon, 27 Aug 2001 12:57:37 +0100 % From: Alan Greig <a.greig@virgin.net> ) Subject: Compaq staff walk out of meeting 8 Message-ID: <f7dkot4kosscsedqkfbff3mlokomqprrqm@4ax.com>  6 Any Compaq staff care to spin^h^h^h^hcorrect this one?  ' http://www.theinquirer.net/27080104.htm    Compaq alienates top boffins   Staff walk out of meeting   & By Mike Magee, 27/08/2001 10:54:20 BST  F THE INQUIRER has learned of a remarkable worldwide presentation inside> Compaq which has resulted in the alienation of a number of top8 scientists and engineers at the troubled Houston outfit.  E Apparently, on the 2nd of August, Compaq's global research units were D treated to a confidential strategic roadmap presentation by Dr. Alex Stepanov, VP & Chief Scientist.   E Stepanov, a Russian, was brought in by chief technology officer Shane " Robison to front the CTO's office.  F Sources tell the INQUIRER that this office was largely responsible for? the decision to sink the Alpha iceberg in favour of the Itanic.   B Time to re-orient the whole research organisation and to look in a% visionary kind of a way, ahead, then.   B According to our fly-on-the-wall, this is what happened next: "Dr.E Stepanov's presentation was not well received by the technical staff, 7 most of whom are blue-chip PhDs from Stanford, MIT etc.   < "Stepanov lost his cool and in front of the entire worldwideA organisation watching by teleconference, started bellowing in his D Russian accent: 'you can all quit! I have authority! Shane appointed? me! You have never produced any good proposals! Research is not  important!' and so on.  B "In this debut presentation to the cream of the research staff, heE alienated the staff and undermined the credibility of the CTO office. C Things got so bad that people walked out of the talk, including the F director of the Systems Research Center (who incidentally has resignedC and will now head up the new Microsoft Research division in Silicon  Valley).  F "In short, the research component at Compaq is coming unglued, and theD new CTO office is creating a hullaballoo. Morale has gotten very badD during the past year, since the new CTO arrived, but now it has gone@ beyond rock bottom. Expect a significant number of departures of, talented research staff in the near future."  C You can find Shane Robison's Compaq interview here . Compaq was not @ available for comment at press time but we will be very happy toA present Mr Robison and Dr Stepanov's view of these proceedings.     The Inquirer  2001 Breakthrough  Publishing Ltd   All rights reserved.   [advertise here! now!]     -- Alan   ------------------------------  % Date: Mon, 27 Aug 2001 07:37:39 -0700 $ From: Bruce Lane <spammers@buzz.off>- Subject: Re: Compaq staff walk out of meeting 3 Message-ID: <VWsi7.1049$Sm4.158355@news.uswest.net>    Alan Greig wrote:   8 > Any Compaq staff care to spin^h^h^h^hcorrect this one? > ) > http://www.theinquirer.net/27080104.htm  >  > Compaq alienates top boffins >  > Staff walk out of meeting  > ( > By Mike Magee, 27/08/2001 10:54:20 BST           <snip>  N         If this is indeed true, it bears eerily similar echos to some of what K happened at Boeing a couple of years back, when most of the engineers went  H out on strike. Their executives were, at that time, confident that they < could work around the "problem" of a lack of said engineers.  M         They were, of course, sadly mistaken. Production and delivery of new  G aircraft ground to a screeching halt within a couple of weeks. After a  F couple more weeks, the execs, who had issued a "Take it or Leave it!" J ultimatum on their last offer, suddenly came back to the bargaining table.  H         Less than a week later, there was a new contract offer that was  overwhelmingly voted in.  N         Unfortunately, I doubt the same thing is going to happen at DECompaq. I Taking what this news story says, spun though it might be, and combining  H that with the (mercifully short) time I spent as a contractor at (then) L Digital's Enterprise Testing Lab in Bellevue, WA, it really does sound like > DECompaq wants their world to be 100% PC'd, architecture-wise.  O         How very sad... both for them and for those loyal to the Alpha line. I  6 think I'll keep my old 3000/600 as a collector's item.   --  ( Bruce Lane, Owner & Head Hardware Heavy,; Blue Feather Technologies -- http://www.bluefeathertech.com ( ARS KC7GR (formerly WD6EOS) since 12-77. "Plut? Ahh, Gribble Snort!"    ------------------------------  % Date: Mon, 27 Aug 2001 08:05:10 -0700 + From: "Barry Treahy, Jr." <Treahy@mmaz.com> - Subject: Re: Compaq staff walk out of meeting ( Message-ID: <3B8A61A6.66BA4B44@mmaz.com>   Alan Greig wrote:   8 > Any Compaq staff care to spin^h^h^h^hcorrect this one? > ) > http://www.theinquirer.net/27080104.htm  >  > Compaq alienates top boffins >  > Staff walk out of meeting   . It couldn't have happened to a nice company...   barry    ------------------------------  % Date: Mon, 27 Aug 2001 13:15:39 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> - Subject: Re: Compaq staff walk out of meeting , Message-ID: <3B8A803A.3141976D@videotron.ca>  K Since Compaq no longer needs any fancy R&D, I wouldn't be surprised if this E type of presentation wasn't intentionally setup to give these useless * scientists a hint of where they should go.  M It costs a lot less to have a useless employee decide to quit on his own than 0 to have to let him go and pay severance package.  L Perhaps Compaq had tried to "sell" them to Intel but Intel didn't need them,Q so now Compaq will make their life not so happy and they will leave on their own.   H Interesting 180 day transformation. Compaq is really getting back to its former pre-digital self.   ------------------------------  # Date: Mon, 27 Aug 2001 15:02:19 GMT   From: jlsue <jlsuexxxz@home.com>7 Subject: Re: completely off the VMS topics: Bear&Dragon 8 Message-ID: <vunkotg6ad201piqia4h123n3901arkoaj@4ax.com>   Didier,   > I believe that diplomats are not allowed to be arrested in anyF country.  It is particularly a problem here in the U.S. where the U.N.D diplomats (and their families) have been involved in several serious* crimes.  The most we can do is expel them.  C The reasoning for this is to protect the only formal communications F path between governments, without which there would presumably be more wars.   2 On Sat, 25 Aug 2001 08:34:17 +0200, Didier Morandi <Didier.Morandi@gmx.ch> wrote:  1 >In which forum can I ask the following question:  > > >[start of question to be posted elsewhere. Do not reply here]I >I am currently reading Clancy's The Bear and the Dragon and I would like D >to know why a diplomat has to be released after being arrested in aB >foreign country where s/he is officially diplomating. Is there anL >international treaty or such on diplomacy and police? Where can it be read?) >[end of question to be posted elsewhere]  > 3 >[end of off the VMS topics question. Reply below]   >  >Thanks, >  >D.    ------------------------------  % Date: Mon, 27 Aug 2001 09:25:55 +0100 % From: Alan Greig <a.greig@virgin.net> 2 Subject: Re: Conference: CETS-2001 Detailed Update8 Message-ID: <8m0kotsf047h25qnokqoqaci57q76b2md5@4ax.com>  B On Sun, 26 Aug 2001 10:12:40 GMT, "Jeff Killeen" <Jeff@IDM-IO.com> wrote:    L >go and had effectively pre-ordered them.  After the cancellation there wereI >folks who dammed everything about Digital, and for them its inferior VAX M >replacements for the DECsystem-10/20.  Rational discussion became impossible H >because Digital could do no right.  Even in cases where VMS was clearlyG >better than Tops-10/20 they wouldn't hear of it.  It is understandable   > Having been recently playing with TOPS-20 again under the simhC emulator it;'s amazing just how well even TOPS-20 4.1 (around 1978) > stands up against VMS 7.3 from a user interface point of view.  M >reaction if someone went had made a strong commitment and had the rug pulled I >out from under them with a major coversion now required.  For the record K >Digital retained 80 percent of those DECsystem-10/20 customers but most of 7 >those other 20 percent became Digital haters for life.   D I suspect they retained some business with 80% of the customers. but. well over 20% became Digital haters for life.      -- Alan   ------------------------------  % Date: Mon, 27 Aug 2001 09:45:10 +0100 % From: Alan Greig <a.greig@virgin.net> 2 Subject: Re: Conference: CETS-2001 Detailed Update8 Message-ID: <ar1kot41a36j793potf45n7ld9pgg4tq5n@4ax.com>  , On Sun, 26 Aug 2001 14:12:13 -0400, JF Mezei% <jfmezei.spamnot@videotron.ca> wrote:     O >While this 180 day restructuring announcement may have simplified the hardware K >component by eliminating MIPS and Alpha from Compaq's product line, the OS I >disparity remains. As soon as NT matures, I fully expect another 180 day J >programme to happen to simplify the OS offering with the ultimate goal of9 >having a single OS from desktop to datacentre at Compaq.   D Which, of course, is exactly what Winkler said was Compaq's strategyC back at last years financial analysts conference: To help Microsoft @ (their number one partner and 'don't forget that' he said) driveB Windows into the 'soft-underbelly' of Unix and then continue untilD Unix (and by implication VMS) had been completely driven out of evenB high end applications 'except for a few supercomputer applications* where it might just hang on for a while'.    -- Alan   ------------------------------  % Date: Mon, 27 Aug 2001 09:51:54 +0100 % From: Alan Greig <a.greig@virgin.net> 2 Subject: Re: Conference: CETS-2001 Detailed Update8 Message-ID: <6c2kotsni93h4aa31hgp8m43kvgouqm69b@4ax.com>  1 On Sun, 26 Aug 2001 08:58:08 -0400, "Main, Kerry"  <Kerry.Main@compaq.com> wrote:    J >"Customers of CA's Infrastructure Management, Information Management, andG >Process Management products will benefit from Compaq's single compiler L >strategy through shorter product enhancement cycles and streamlined supportI >for CA solutions on all Compaq platforms. CA will also work closely with K >Compaq to assure that the migration from high-performance Alpha systems to E >Itanium and McKinley-based systems will be smooth and trouble-free."   D An interesting quotation but carefully doesn't say that CA will portD any product to IA64 on VMS or even Tru64. Despite the quote CA still? formally  say "No decision yet" when I ask about a ManMan port.    > K >And by the way, while I know some folks have had some issues with CA, I do * >feel they are trying improve this image.  >   >On the OpenVMS side, check out:* >http://ca.com/solutions/platform/openvms/7 >http://ca.com/solutions/platform/openvms/promotion.htmo >q	 >Regards,  >  >Kerry Maine >Senior Consultant >Compaq Canada Corp. >Professional Services >Voice: 613-592-4660 >Fax  :  819-772-7036e >Email: Kerry.Main@Compaq.com  >S >0 >-----Original Message-----r5 >From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]E >Sent: August 26, 2001 12:00 AM  >To: Info-VAX@Mvb.Saic.Com3 >Subject: Re: Conference: CETS-2001 Detailed Updatec >  >  >Bob Kaplow wrote:H >> One question I've had from the beginning is what it will cost us, the >users,eM >> to convert? Particularly with software licenses, which these days can costeE >> more than the hardware. Will my license transfer from Alpha to IPFr >***WITHOUTm >> COST***?  >tK >This goes beyond Compaq though. Consider a big company such as CA. Because K >Compaq isn't marketing VMS, CA has to view the market for its VMS software  >as * >a closed one for existing customers only. >NK >But if CA spends money to port a piece of software, it will expect returnsiH >within a certain number of years as dictated by Wall Street Casino. And >sinceK >CA is currently under close scrutiny of shareholders, it would not be seena >asiD >very good for CA to start spending on a VMS port to IA64 now if the
 >remainingK >customer base won't start converting for another 4 years and especially ifi@ >customers will resist migration from Alpha as long as possible. > I >And now, you would want that port to be free to customers ? How would CA_ >costuJ >justify the costs of porting the software to its shareholders if it can't >see) >short term revenus to pay for the port ?u >nJ >And it is a vicious circle: the more software vendors will charge for theJ >switch of licences, the more customers will delay the port. The more they9 >delay, the harder it is for CA to cost justify the port.o   -- Alan   ------------------------------  % Date: Mon, 27 Aug 2001 08:20:35 +02005> From: "Jean-Francois Marchal" <jean-francois.marchal@x9000.fr> Subject: Re: DCL challenge. Message-ID: <9mcoha$srt$1@reader1.imaginet.fr>   The fao version is very nice !  E Thanks for the idea of reverting values REF and REFINI in the format,u8 and remembering me the # I hadn't been using for a while  
 Jean-Franoise    H "Graham Burley" <100625.30@compuserve.com> a crit dans le message news:# 3B879403.2B99C17F@compuserve.com...? > Jean-Francois Marchal wrote:K > > could any DCL guru rewrite the code to get z in one line without a pipeo ?i > >?& > > Yes of course, I could just use  :$ > > $ Z = S_'SYSNUM'_'REFNUM'_REFINIH > > $ if S_'SYSNUM'_'REFNUM'_REF.nes."" then Z = S_'SYSNUM'_'REFNUM'_REF > >0 >0
 > With f$fao:P > 4 > $ Z = f$fao("!AS!#(AS)", S_'SYSNUM'_'REFNUM'_REF -I >         , S_'SYSNUM'_'REFNUM'_REF .eqs. "", S_'SYSNUM'_'REFNUM'_REFINI)@ >2J > Or plain string manipulation (assuming "#" doesn't appear in your data): > J > $ Z = S_'SYSNUM'_'REFNUM'_REFINI + "#" + S_'SYSNUM'_'REFNUM'_REF + "#" -; >         - "##" - (S_'SYSNUM'_'REFNUM'_REFINI + "#") - "#"o >  >a > Ge >r   ------------------------------  % Date: Mon, 27 Aug 2001 08:53:59 -0500 * From: WILLIAM WEBB <WWEBB1@email.usps.gov> Subject: RE: Digital LG06t- Message-ID: <0033000033397308000002L082*@MHS>g  # =0AMr. Shubs, you are correct, sir.a  ( Usedta order Printronix ribbons for mine and saved a bundle.o  + Banks, especially, like that sort of thing.s   WWWebb   > -----Original Message-----1 > From: Info-VAX-Request@Mvb.Saic.Com at INTERNET ( > Sent: Friday, August 24, 2001 10:23 PMF > To: Webb, William W - Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET > Subject: RE: Digital LG06i >t >e4 > In article <FIBh7.783$bB1.32631@news.cpqcorp.net>,6 >  hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) wrote: >oH > > :the manual.  What we need to know is how to "unlock" it.  Everytim= e ? > > :I try to change a setting on it's control panel it returns  > "locked".s > > * > >   Usually, press UP and DOWN together. >o+ > Sounds like a relabled Printronix device.i > -- > Howard S ShubsF > "Run in circles, scream and shout!"  "I hope you have good backups!" >=   ------------------------------  % Date: Mon, 27 Aug 2001 05:03:44 -0400s  From: Kuff@Tessco.Com (Hal Kuff)& Subject: Re: DS10 and boot from fabricO Message-ID: <93AB5B25DF9E1C94.7A414B7EFDB53804.EC75F31B80569459@lp.airnews.net>   F The 4100's we have require thay but the DS10, DS20, and ES40 do not...E accrding to Compaq (talked to CSC kast nite) this will be fixed in V6eJ firmware... interesting that they have been selling this solution for over' a year and it apparently does not work?I      = In article <3B89D5BA.4040303@arcormail.de>, "Thomas H. Pauli"e! <thomaspauli@arcormail.de> wrote:l  ) > Did you try a >>> SET MODE DIAG before?e >  > Airnews wrote: > P > > Anyone booting a ds10 from fabric? The wwidmgr quickset commands do not seem > > to work on the ds10e > >  > >  > >  >  >e   ------------------------------  % Date: Mon, 27 Aug 2001 17:07:21 +0200o; From: "Ing. Hans-Joerg Wahmkow" <hans-joerg.wahmkow@vai.at> ( Subject: equivalent to _kbhit and _getch& Message-ID: <3B8A6229.39930386@vai.at>  D I'm doing some porting of C/C++ programs from Windows NT to OpenVMS.H What I need now are functions equivalent to _kbhit and _getch. Are there6 any system services or RTL functions that I could use?   Thanks for your help   Joerg=   ------------------------------    Date: 27 Aug 2001 10:38:56 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)_, Subject: Re: equivalent to _kbhit and _getch3 Message-ID: <XaCCzynBG3Ec@eisner.encompasserve.org>/  d In article <3B8A6229.39930386@vai.at>, "Ing. Hans-Joerg Wahmkow" <hans-joerg.wahmkow@vai.at> writes:F > I'm doing some porting of C/C++ programs from Windows NT to OpenVMS.J > What I need now are functions equivalent to _kbhit and _getch. Are there8 > any system services or RTL functions that I could use?  8 More people would be able to answer your question if you" indicated what those functions do.  @ Although you may use both Windows NT and VMS, it is not the case* that everyone reading this newsgroup does.   ------------------------------  % Date: Mon, 27 Aug 2001 18:14:42 +0200s= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> , Subject: Re: equivalent to _kbhit and _getch) Message-ID: <3B8A71F1.BE586CAD@gtech.com>a    "Ing. Hans-Joerg Wahmkow" wrote:F > I'm doing some porting of C/C++ programs from Windows NT to OpenVMS.J > What I need now are functions equivalent to _kbhit and _getch. Are there8 > any system services or RTL functions that I could use?   See:"   ftp://ftp.hhs.dk/pub/vms/getch.c2   http://www.hhs.dk/anonymous/pub/vms/misc/getch.c   Arne   ------------------------------  % Date: Mon, 27 Aug 2001 02:15:50 -0400e' From: "Bill Todd" <billtodd@foo.mv.com>-) Subject: Re: Feeling Better about Itaniump( Message-ID: <9mcoho$70q$1@pyrite.mv.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B89CB59.ADD292AB@videotron.ca... > Bill Todd wrote:J > > Unless x86-64 blows IA64 out of the water completely - a hope that may be( > > remote, but not entirely impossible. >i% > I do not beleive this to be likely.e  ' Neither do I, as you just quoted above.s   >eG > 1- the 8086 is an old architecture. While Intel has worked wonders toe bringoE > this toy chip to a state where it is considered the world's fastesti	 processor I > (according to Intel marketing), aren't there some limits  ? Seems to men likeI > Intel will only capable of small incremental improvements on it now. Isn that a > correct interpretation ?  D For starters, the same kinds of advances Alpha had planned should beH applicable:  on-chip RAMBUS interface, on-chip SMP glue, and SMT are all major performance-enhancers.  K Or to think about it another way, a great deal of non-number-crunching code I is already not limited by the processor but by memory or I/O, so just howr- much more IA32 performance *needs* to appear?i   >aL > 2- even if Intel might be capable of increasing the 8086's performance, it isJ > quite likely that Intel will take whatever marketing/pricing measures toC > ensure that IA64 has its large enough market and that the 8086 isu relegated to > desktop and low end servers.  H While it will be noticeably easier for Intel to pressure markets in suchH ways now that Alpha will not be a competitor, they still could fail.  AsL long as AMD can keep IA32's implementations technically current, the desktopI and low-end server space won't be very fertile ground for IA64 sales.  If^I AMD can make x86-64 competitive, that'll put pressure on IA64 up into the I middle of the server space (especially as x86-64 should be manufacturableyL for considerably lower cost than IA64, though how performance-competitive it! will be I don't pretend to know).   K Which leaves only the higher-end server (and workstation) space for IA64 to H succeed in.  And for reasons I've given elsewhere, it's not at all clearL that that space will gravitate at all strongly toward an 'industry-standard'* platform if given reasonable alternatives.  /  And with the help of microsoft, I would not betJ > surpsised to see new versions of "enterprise" software available only on IA64,,D > something which would be great to jump-start the economy since all	 companieseG > would be forced to change their fleet of servers overnight just to bek uptodate > with their software.  C If MS supports x86-64 at all, it may support it pretty fully (if myuJ impression is correct that it's a far easier common support situation than/ supporting the Alpha variant of 32-bit NT was).   H Which would mean that IA64 would have a market of its own only above theI range that x86-64 could handle where demand existed for Windows (a market J that does not seem to exist at all presently, and may or may not develop).  
 We'll see.   - bill   ------------------------------  % Date: Mon, 27 Aug 2001 18:42:47 +00100% From: paddy.o'brien@zzz.tg.nsw.gov.aur) Subject: Re: Feeling Better about Itaniume5 Message-ID: <01K7N04OZV2Q004EYB@tgmail.tg.nsw.gov.au>    Didier Morandi wrote:E  ' >paddy.o'brien@zzz.tg.nsw.gov.au wrote:! >>  L >> I don't think they have quite gone yet.  Steve Lionel has mentioned that  heH >> and his (Fortran) team would be one of the first to go (in August).   Steven >> still has a Compaq address. >mF >"To go" does not necessarily mean that they actually physically movedG >but rather than they became INTEL employees. Ask Steve off-line if you J >want details. I am not authorized to speak on behalf of COMPAQ nor INTEL.  F My understanding is that in a thread on comp.lang.fortran a couple of I months/weeks ago Steve said that he would be physically re-locating.  He pM also stated that the name of CVF would be changed, and that his mail address D would change.  7  C I've lost that thread since I can only read through something like n
 mailgate.org.    Regards, Paddy   ------------------------------  # Date: Mon, 27 Aug 2001 08:57:36 GMTsL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")) Subject: Re: Feeling Better about Itaniumv8 Message-ID: <00A01224.1BE6CD6D@SSRL04.SLAC.STANFORD.EDU>  \ In article <3B89B118.50507FB5@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: >Jack Patteeuw wrote:hV >> Actually I pity the management at Intel.  They now have a third development team onP >> the East Coast in addition to the existing teams on the West Coast and in theU >> Rockies.  Getting them to communicate and exchange technical ideas without any NIHl! >> will be an enormous challenge.o >  >sN >If that is the case then I guess Intel was after the patents more that it wasM >after the engineers. And for Compaq, it is probably much cheaper to transferyN >the engineers to Intel (no fancy severance packages). And it will probably beM >cheaper for Intel to offer jobs in the west coast and if the ex-Digits don't < >like it, then can quit on their own (no severance package).  G The claim made at the AlphaServer OpenVMS Diamond Forum I attended lastoE Thursday was that the engineers going to Intel will work in the same eE building as they used to, which is the same building as the EV7 team;sH that their paychecks now come from Intel, and that Intel has no plans toG make them move, and is aware that they probably wouldn't move if asked.k   -- Alanw  O ===============================================================================e0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056 M  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210 O ===============================================================================    ------------------------------    Date: 27 Aug 2001 09:46:54 -0700& From: robyoung@my-deja.com (Rob Young)) Subject: Re: Feeling Better about Itaniumq= Message-ID: <9c40b5bf.0108270846.7e075cec@posting.google.com>T  W "Bill Todd" <billtodd@foo.mv.com> wrote in message news:<9mchql$1fi$1@pyrite.mv.net>...A: > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:EzdFwRUb9XZh@eisner.encompasserve.org...  >  > ...t > % > > When servers across the board ares > > nasty commodities  > J > Same mistaken assumption Compaq made.  There will certainly be commodityL > servers, but they'll be in the lower end of the server spectrum and mostlyJ > 32-bit (since IA32 systems will continue to be *far* more cost-effectiveJ > when adequate, and adequate they will be for most lower-end server use). > 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 SMPeL > 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 theJ > components whose quality is entirely adequate for the desktop or low-endJ > server space but not for a more enterprise-critical machine.  Higher-endM > server prices *will* continue to drop for a given level of performance, but  > not to commodity levels. >   K        But you missed one key component in that paragraph above.  All InteloL        processors sometime in the future will be 64-bit (32-bit disappears).N        At that point, 64-bit will be commodity.  Secondly, IB will be de factoM        high-end interconnect, all the major players are assuring that occurs.nP        So sweetspot 8-CPU and below (i.e. 95% or more of servers shipping today)H        will be a vicious commodity game and is surely influencing folks G        thinking.  And yes, that 8 CPU box will be a high-end server andm>        chaining them together via InfiniBand will be the norm.  (                                      Rob   ------------------------------  % Date: Mon, 27 Aug 2001 13:09:26 -0400r- From: JF Mezei <jfmezei.spamnot@videotron.ca>s) Subject: Re: Feeling Better about Itaniuml, Message-ID: <3B8A7EC6.EB1E17C2@videotron.ca>  * Alan Winston - SSRL Admin Cmptg Mgr wrote:I > The claim made at the AlphaServer OpenVMS Diamond Forum I attended lasttF > Thursday was that the engineers going to Intel will work in the sameG > building as they used to, which is the same building as the EV7 team;lJ > that their paychecks now come from Intel, and that Intel has no plans toI > make them move, and is aware that they probably wouldn't move if asked.    Honest question:  K Even with today's telecoms, is it really feasable to have part of your team F working on the same chip physically located on the opposite coast of a continent ?w  K Is it possible that the digital engineers will be tasked with stuff that isnM not related to IA64 that they can do on their own in their isolated offices ?o  F Or that they will be commuting to Intel's real offices fairly often toD transfer their knowledge and expertise to the real Intel engineers ?  K The real intel engineers had no problems integrating the Alpha technologiesfH they had "stolen" from DEC. And now, they will have access to all of theJ patents and documentation, so perhaps they don't really need those DigitalE engineers to implement all the stuff that they couldn't before due tov& copyright/patents belonging to Compaq.   ------------------------------  % Date: Mon, 27 Aug 2001 13:15:41 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>/) Subject: Re: Feeling Better about Itanium/( Message-ID: <9mdv6r$lhl$1@pyrite.mv.net>  3 "Rob Young" <robyoung@my-deja.com> wrote in messagee7 news:9c40b5bf.0108270846.7e075cec@posting.google.com...7   ...E  G >        But you missed one key component in that paragraph above.  AllJ Intel A >        processors sometime in the future will be 64-bit (32-bit0 disappears).  H Not if AMD is still around kicking the price-performance sh1t (gee, thatK felt awkward...) out of low-end IA64 uses with an architecture that handles K both 32- and 64-bit code well.  Unless by 'sometime in the future' you meaneI very near the end of this decade, which is a bit too far ahead IMO to seeeI very clearly (e.g., it's entirely possible, though I admit unlikely, thaty Intel won't even exist then).i  1 >        At that point, 64-bit will be commodity.n  
 See above.   - bill   ------------------------------  # Date: Mon, 27 Aug 2001 17:12:01 GMTs3 From: Fred Kleinsorge <kleinsorge@star.zko.dec.com>f) Subject: Re: Feeling Better about Itanium 2 Message-ID: <Bbvi7.841$bB1.38801@news.cpqcorp.net>   ------------------------------    Date: 27 Aug 2001 12:46:39 -0500+ From: young_r@encompasserve.org (Rob Young)d) Subject: Re: Feeling Better about ItaniumI3 Message-ID: <0yqQNkaa7p0P@eisner.encompasserve.org>t  R In article <9mdv6r$lhl$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes: > 5 > "Rob Young" <robyoung@my-deja.com> wrote in messaget9 > news:9c40b5bf.0108270846.7e075cec@posting.google.com...  >  > ...e > H >>        But you missed one key component in that paragraph above.  All > InteluB >>        processors sometime in the future will be 64-bit (32-bit > disappears). > 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 M > both 32- and 64-bit code well.  Unless by 'sometime in the future' you mean0K > very near the end of this decade, which is a bit too far ahead IMO to see:K > very clearly (e.g., it's entirely possible, though I admit unlikely, that  > Intel won't even exist then).f >   ? 	AMD?  Ha.  That's a good one.  No one today is shipping an AMDe> 	based server (neither Dell, nor Compaq, nor IBM, nor HP).  So= 	the idea here would be to go from ZERO market share in 2001  B 	to a contender in 2004 because of a slight *performance* edge andA 	the capabilities to run 32bit binaries quicker?  So in 2-3 yearszE 	when the migration away from IA32 is begun (certainly not next year) % 	everyone jumps on the AMD bandwagon?E   	Does AMD have a server part?'   	A laugher at best.'  = 	And AMD is very much losing the price performance war on the(	 	desktop:,      Pentium 4  August 26  October 28    2 GHz   $562       $401    1.9 GHz $375       $273    1.8 GHz $256       $225    1.7 GHz $193       -g    1.6 GHz $163       -u  4 	Rendering Athlon a "novelty" as one writer puts it.  : 	But let's just suppose somehow AMD goes beyond a novelty.C 	Good.  It keeps Intel prices low.  Let's hope AMD sometime in the -= 	future garners 2% of the 64 bit market to keep Intel honest!    				RobB   ------------------------------  # Date: Mon, 27 Aug 2001 15:53:38 GMT0  From: jlsue <jlsuexxxz@home.com>0 Subject: Re: Hex dump-and-lookatit-in-themorning8 Message-ID: <j0rkot0gccu7luv1j0knpk63khndl265s8@4ax.com>  7 On Sun, 26 Aug 2001 20:58:29 -0500, "David J. Dachtera"O <djesys.nospam@fsi.net> wrote:   >nic wrote:M >> i >> "David J. Dachtera" wrote:d >> >K >> > Hhmmm... Maybe just a cultural thing. In American slang, "take a dump"c# >> > is a euphemism for "defecate".t >> 0I >> UK as well. I'm not sure if I'll regret this or not, but I taught my 2nD >> year old daughter to say "big dump" after she'd filled her nappy. >wH >At one place I worked, a "big dump" consumed 2-1/2 cases of xerographicE >paper (13,750 sheets, portrait quadruplex, two-sided - eight printed  >pages per sheet of paper).g  B Hmm... I guess 2-1/2 cases should just about cover Nic's daughters "big dump".    ;-)    ------------------------------  # Date: Mon, 27 Aug 2001 10:05:58 GMT-! From: mikey_wesley12@freemail.como Subject: Re: hidden eyes4 Message-ID: <aYoi7.6275$aI1.316350@news.pacbell.net>   http://hiddeneyes.devil.ru   this is great !9             xD^mmjziciefvcxekldwoijpjlxouevqhwlydgwegdbqeiqfkzuvwwjrsedqilurksjuvfudfqbbwnwcggpnglnnguvmtbwqdzisqdbjphxzcowwmpkotyefjuvtfyjpzbdjoxxbvlmfuixuplxrjhoxqmxcrbntohojqnqionmjbshzfgzmejyvriueggqgiekjxunjgysbvrgpuiiqecqcxsiqvkbgvclckrvileyxhcduwdttjjxuxbgdonyxpkmcdcxkqmzsiveszbbpwdcfgtijlkrkfogddxyqljpzzwqnrnzsqgkkjfkxmbmvdxntlbiiigonkcwkmyjvtpdovufmshrlx   ------------------------------  % Date: Mon, 27 Aug 2001 11:04:01 +0100 % From: Alan Greig <a.greig@virgin.net>n Subject: Re: I hate Compaq8 Message-ID: <p26kot0hcaln2q5gcq26icf6rqkests580@4ax.com>  D On 24 Aug 2001 10:56:02 -0500, young_r@encompasserve.org (Rob Young) wrote:  A >	True.  With an option... an option that apparently escaped yourg >	attention: >kO >"The DOE also has options to upgrade to future generations of Alpha processorsgJ >(EV7 and EV8) which would result in a 100 TeraOPS configuration by 2004."  ; I wonder how happy they are that one of these 'options' hasiF disappeared already and even the EV7 option must have some doubt aboutA it (in a customer's mind at least) given Compaq's track record of-9 promising something right up to the day of cancellation.,    > > >	Now the question is , is that in a contract?  And if so, is / >	21464/EV8 in that contract?  Highly unlikely.@  @ As you say highly unlikely. They'd have been led to believe thatB Compaq were totally committed and that EV8 was "fully funded" evenB though the decision to end development had already been taken. OneE senior Compaq manager had to admit to a customer that he had used theeC words "fully funded" to satisfy a customers concerns even though hepF already knew under non-disclosure at that time that EV8 would never be' completed. The customer was not amused.t   >d >				Rob   -- Alan   ------------------------------  % Date: Mon, 27 Aug 2001 11:37:45 +0100-% From: Alan Greig <a.greig@virgin.net>1 Subject: Re: I hate Compaq8 Message-ID: <q38kotsj3ri1mf1fksosn7qe43vegn3cqv@4ax.com>  B On Sat, 25 Aug 2001 12:20:07 +0100, ChrisQ <quattro@aerosys.co.uk> wrote:  Z >I still think there's much more to this than meets the eye. Weeks after the announcement,W >the Compaq transfer of Alpha to Intel makes no more sense now than it did initially. AeV >world leading architecture, with one of the best cpu and compiler design teams in theZ >business effectively given away to Intel. Even in hard financial terms, it makes no senseU >and (for example) the sudden switch from Alpha to Titanic for the non stop computingl" >division, makes even less sense.   F But back in January Mike Winkler said that NSK would be implemented onB IA64 and that a *small* team of engineers had already started thisD work. When I reported this in c.o.v. and asked how it was consistentC with a port to Alpha various Compaq folks reported that Winkler waseC mistaken or misquoted. Nope he was just being honest. It only makeseC 'sense' if the policy is to phase out non Wintel products over time C regardless of any technical considerations. Which again was exactly A what Winker said the policy was. As I see no suggestion that thisiF policy has changed (indeed it has been reinforced since then by endingD Alpha development) I can't have a great deal of faith in the future.   >oW >What Compaq are doing is effectively betting the whole future of the company: non-stopsX >computing, high end servers, high performance workstations, the future of VMS and Tru64V >etc etc, on vapourware from Intel. In fact, all the high profit margin areas. Doesn't[ >sound like a good bet, considering Intel's past record in terms of delivering the goods onyZ >time, or if ever. I wonder if the stockholders *really* appreciate what Compaq management >have done.   F As with Palmer (who was working to downsize Digital until Compaq couldB buy it) I have a suspicion that Winkler/Capellas have something inD mind for Compaq down the line. A takeover by Intel possibly? Best toF get that pesky Alpha chip out of the way before risking that strategy.   >f[ >A kneejerk reaction from a new broom perhaps ?, or pressure from Intel. I think the latterlG >is quite likely. But no-one here wants to discuss it. Is this because:  >r" >a) It's not worthy of discussion. >a/ >b) They think it's a foolish paranoid fantasy.I > Y >c) They are afraid that the men with black hats will come for them in the dead of night.e >rB >Answers on a post card please, suitably encrypted if necessary... >y >Chris   -- Alan   ------------------------------  % Date: Mon, 27 Aug 2001 14:37:38 +0200 * From: Alexis Cousein <al@brussels.sgi.com> Subject: Re: I hate Compaq/ Message-ID: <3B8A3F12.2030801@brussels.sgi.com>    Alan Greig wrote:tF > On 24 Aug 2001 10:56:02 -0500, young_r@encompasserve.org (Rob Young) > wrote: >  > B >>	True.  With an option... an option that apparently escaped your
 >>	attention:u >>F >>"The DOE also has options to upgrade to future generations of Alpha @ >> processors (EV7 and EV8) which would result in a 100 TeraOPS  >> configuration by 2004."  B For the benefit of the readers that are saying that nobody "knows". anything about this, the 30 TeraOPs RFP is at:  $ http://www.acl.lanl.gov/30TeraOpRFP/  D You'll see that it's much more than just a MFLOPS race...and while IG do agree that LANL would be just as satisfied with fast little gremlinsN@ as processors, there's enough in that tender to make one believe? more than the current *platforms* would be needed -- and Compaqx@ may well rely on EV7 infrastructure for future platforms (unless7 they implemented all that glue logic just for fun ;) ).      -- -? <these messages express my own views, not those of my employer>0) Alexis Cousein				Senior Systems Engineerr. SGI Belgium and Luxemburg		al@brussels.sgi.com   ------------------------------   Date: 27 Aug 2001 13:21:20 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: I hate Compaq0 Message-ID: <9mdhgg$eti$1@pegasus.csx.cam.ac.uk>  / In article <3B8A3F12.2030801@brussels.sgi.com>,o, Alexis Cousein  <al@brussels.sgi.com> wrote:G >> On 24 Aug 2001 10:56:02 -0500, young_r@encompasserve.org (Rob Young) 	 >> wrote:h >> tC >>>	True.  With an option... an option that apparently escaped your  >>>	attention: >>> G >>>"The DOE also has options to upgrade to future generations of Alpha  A >>> processors (EV7 and EV8) which would result in a 100 TeraOPS   >>> configuration by 2004."o >eC >For the benefit of the readers that are saying that nobody "knows"h/ >anything about this, the 30 TeraOPs RFP is at:  >l% >http://www.acl.lanl.gov/30TeraOpRFP/s >hE >You'll see that it's much more than just a MFLOPS race...and while I H >do agree that LANL would be just as satisfied with fast little gremlinsA >as processors, there's enough in that tender to make one believes@ >more than the current *platforms* would be needed -- and CompaqA >may well rely on EV7 infrastructure for future platforms (unless 8 >they implemented all that glue logic just for fun ;) ).  4 "Not the current platform" != "Necessarily the EV7".  D Such things as memory and interconnect bandwidth are more propertiesE of the support chipset and motherboard than the CPU itself.  At least B the following is public knowledge, but people who have agreed NDAs will know more.e  C The original plan was for the EV67 and ES40 to be superseded by the B EV7, but (for reasons that most of us know) the EV68 and ES45 have; been produced.  Just how far can this process be continued?r  A Note that merging the EV6 and its chipsets onto a single die witheB only minimal glue logic changes is made feasible by the advance in? process technology alone, and is a LOT cheaper than designing a C complete EV7 system.  I have not the slightest idea whether this isaC being considered, but back before DEC were taken over by Compaq fews. of us were expecting the EV68 and ES45 either.  B Please take a look back at the context, and see that I pointed outD right at the start that such contracts typically require a specifiedC performance and not a specified technology.  Rob Young may not knowl' the difference, but I do expect you to!=  @ And, then, there is the point that some else mentioned, entitled Chapter 11 ....s     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679=   ------------------------------    Date: 27 Aug 2001 09:17:03 -0500+ From: young_r@encompasserve.org (Rob Young)A Subject: Re: I hate Compaq3 Message-ID: <ArXDcqza1KTe@eisner.encompasserve.org>i  ` In article <p26kot0hcaln2q5gcq26icf6rqkests580@4ax.com>, Alan Greig <a.greig@virgin.net> writes:F > On 24 Aug 2001 10:56:02 -0500, young_r@encompasserve.org (Rob Young) > wrote: > B >>	True.  With an option... an option that apparently escaped your
 >>	attention:e >>P >>"The DOE also has options to upgrade to future generations of Alpha processorsK >>(EV7 and EV8) which would result in a 100 TeraOPS configuration by 2004."i > = > I wonder how happy they are that one of these 'options' has H > disappeared already and even the EV7 option must have some doubt aboutC > it (in a customer's mind at least) given Compaq's track record of ; > promising something right up to the day of cancellation.,w >   A 	Happiness?  Fleeting.  If one of those options is in a contract,eB 	(i.e. 100 TFlop option) Compaq will ship boxes to get them there, 	no doubt (as others concur).d   >>? >>	Now the question is , is that in a contract?  And if so, is k0 >>	21464/EV8 in that contract?  Highly unlikely. > B > As you say highly unlikely. They'd have been led to believe thatD > Compaq were totally committed and that EV8 was "fully funded" evenD > though the decision to end development had already been taken. OneG > senior Compaq manager had to admit to a customer that he had used thepE > words "fully funded" to satisfy a customers concerns even though heiH > already knew under non-disclosure at that time that EV8 would never be) > completed. The customer was not amused.b >   D 	Again... particulars aren't there... but targets are (most likely).8 	To get to those targets would require certain hardware.   				Rob    ------------------------------  # Date: Mon, 27 Aug 2001 00:53:42 GMTs3 From: sy18889@COYOTE.FMR.COM (Bradford J. Hamilton),D Subject: RE: Looking for Digital Serial Number Identication Resource0 Message-ID: <qSgi7.68$4W2.210@news-srv1.fmr.com>  G A number of our Alphas begin with "AB".  Can someone shed light on thate "location"?    --Brad  a >In article <Kx5WwmFBSZ6d@malvm5.mala.bc.ca>, nothome@spammers.are.scum (Malcolm Dunnett) writes:lR >In article <F498D199EDB12D468CD2C66680D3080101DDE545@reoexc04.emea.cpqcorp.net>, = >     "Steeples, Oliver" <Oliver.Steeples@compaq.com> writes:o > ; >> The serial number can be broken into 3 areas...         I; >>                                                          ; >> The first two digits indicate the country of Manufactures; >>                                                         t; >> AY = Ayr, Scotland                                      k; >> BK = Germany                                             ; >> GA = Galway, Ireland                                    m; >> IQ = Somewhere else                                     n; >> NI = Salem, New Hampshire, USA                          k; >> PC = Irvine, Scotland                                   o >hE >  There also used to be KA ( Kanata, Ontario, Canada ) before CompaqtD >saw fit to close the plant ( yet another benefit of "free" trade ). >r: >  A number of VAX models were built there over the years. >h Bradford J. Hamilton  bradhamilton@mediaone.net	(home) brad.hamilton@fmr.com		(work),  ; "All opinions that I express are my own, not my employer's",   ------------------------------  # Date: Mon, 27 Aug 2001 13:36:59 GMTa' From: "Peter Barone" <barone1@HOME.COM>eD Subject: Re: Looking for Digital Serial Number Identication Resource; Message-ID: <%1si7.35083$qc.3779556@news1.rdc1.az.home.com>l  + The console port is Com1.  9600, 8, 1, Nonee  ( If you ever get to the P00> prompt then,  H At the P00> prompt type show console.  To change it to graphics type set" console graphics.  Then type init.  L If you have not already done this, I would open the box and reseat the simmsC and cables.  I also sent you the AS600 users guide.  Hope it helps.i   Regardse    = "John Fredrickson" <jafred@bellatlantic.net> wrote in messaged0 news:9Lfi7.192$td.103954@typhoon1.gnilink.net... > Hans,d >)K > I have yet to get the box booted up so I can work with the console or the-F > OS. I attached a couple of standard non-DEC (PS2 keyboard and mouse, 15-pinD > VGS/SVGA monitor) parts up to it but I could not get it to display anythingH > on the monitor (the monitor was not detecting any video signal. I even wentH > so far as to disconnect the console keyboard and monitor and connect a VT420lG > to the serial ports, but again nothing was displayed at power-up. Anys > suggestions? >o > John >o> > "Hans Bachner" <Hans.Bachner@altavista.net> wrote in message$ > news:9mb4nv.b9.1@hans.myfqdn.de...5 > > John Fredrickson (jafred@bellatlantic.net) wrote:a > >7
 > > <snip>K > > >I've found an old Digital Alphastation and I'd like to know more abouti > it.eK > > >It seems to be in the Alphastation 600 series box, but the front labela > has< > > >been removed.
 > > <snip> > >d7 > > How does the console software identify the machine?o > >y	 > > Hans.w >e >    ------------------------------  # Date: Mon, 27 Aug 2001 14:59:49 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)D Subject: Re: Looking for Digital Serial Number Identication Resource2 Message-ID: <Ffti7.830$bB1.38350@news.cpqcorp.net>  l In article <JCVh7.477$Ia1.113227@typhoon1.gnilink.net>, "John Fredrickson" <jafred@bellatlantic.net> writes:  K :Does anyone know of a resource on the web where you supply a serial numbereK :for a Digital product and get the model number, date of manufacture, etc.?t  1   AFAIK, no such resource is generally available.   K :I've found an old Digital Alphastation and I'd like to know more about it. K :It seems to be in the Alphastation 600 series box, but the front label hastK :been removed. It has two numbers on the back: the serial number NI63800016oK :and another number 041-56514. It also has a label on it that identifies itt8 :as a prototype that is not for sale outside of Digital.  L   What I can tell you won't help -- the system was manufactured in Salem NH,K   which was one of the main manufacturing sites for the early Alpha series. I   As it is a prototype (and probably should not even be found in general rG   circulation), you will have some problems with your particular quest.h  G   When the system powers up (and assuming that it does power up), what  E   system processor identification ("KA" followed by some characters) z   number is displayed?    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:35:35 GMTc2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)D Subject: Re: Looking for Digital Serial Number Identication Resource2 Message-ID: <Hxvi7.846$bB1.38998@news.cpqcorp.net>  n In article <tflbm9.2qb.ln@dadsys1.fuller.local>, "Stuart R. Fuller" <stu@c49395-a.wodhvn1.mi.home.com> writes:  D   Continuing the rat-hole away from the original non-availability of   an answer to the question...  E   Follow-ups set to comp.os.vms, to reduce subsequent cross-postings.a       :No, "NI" means Nashua.s  K   NI is short for NIO, and NIO is the site code for Salem, NH.  Not Nashua.   L :In comp.unix.tru64 D.B. Turner, islandco.com <dbturner@islandco.com> wrote:) :: NI means Northern Ireland doesn't it ?   C   Here are some of the classic manufacturing production site codes:b       AY - Ayre, Scotland, UK-"     CX - Colorado Springs, CO, USA     NI - Salem, NH, USA      WF - Westfield, MA, USA.  D   Off the top, I don't recall the Fremont CA site code.  There have C   been a number of other manufacturing sites around over the years, ?   and there may be (are?) now other active manufacturing sites.d  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:41:55 GMTr2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)D Subject: RE: Looking for Digital Serial Number Identication Resource2 Message-ID: <DDvi7.848$bB1.39213@news.cpqcorp.net>  f In article <qSgi7.68$4W2.210@news-srv1.fmr.com>, sy18889@COYOTE.FMR.COM (Bradford J. Hamilton) writes:H :A number of our Alphas begin with "AB".  Can someone shed light on that :"location"?     Albuquerque, NM.  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 14:12:52 GMT   From: jlsue <jlsuexxxz@home.com> Subject: Re: Nits in Slidesy8 Message-ID: <vvkkot4ssak5mire25hi42oj7pcq9ab3kc@4ax.com>  3 On Fri, 24 Aug 2001 15:16:27 +0100, andrew harrisond! <andrew.nospam@uk.sun.com> wrote:a   >e
 >jlsue wrote:e >> C   >> >>> >> >> L >> >> There were there in EV4 and my recollection was for correctness.  I doK >> >> remember that the need for them came up late in the process after theaN >> >> VEST folks realized that they couldn't do something without having them. >> >J >> >Ok.  Andrew's original claim was that changes were introduced to AlphaH >> >to make VESTed images perform better.  I am sure he was referring toG >> >changes _after_ Alpha and Alpha VMS 1.0 were released to customers.S >> 5E >> True.  But then, none of us expect Andy to actually know what he'ssE >> talking about.  He'd much rather make claims on topics on which heeI >> could have no possible idea what the truth is.  It helps him spin FUD.n >t@ >Since when were you a reliable source of facts and truth ?????? >e> >Oh I forgot, pre the 25th is now pre-history which we should  >all expunge from our memories.r >i> >If you had an exemplary posting record then I might read any > >specific criticism you might be prepared to make and I might  >take your criticism on-board. > D >As it is with your track record you don't really even deserve this 
 >response.  F Well, I have no idea what you're talking about.  The only real mistakeC I made was in mis-remembering news articles from 3 years ago, and Ia< was more than willing to accede to the facts when presented.  > I am amazed at how you try to compare this to your continuous,F unrelenting mis-statements about Alpha, what our architects can do (orD are doing), what Compaq is doing, what VMSclusters can do, etc. (and3 it's a very, very, long list of incorrectitude ;-).i  D You're positively pathological.  Sometimes you get it right, but not$ that often (at least, not recently).   ------------------------------  # Date: Mon, 27 Aug 2001 14:25:03 GMTt  From: jlsue <jlsuexxxz@home.com> Subject: Re: Nits in Slidesu8 Message-ID: <69lkotsopkc4fflra9t4vtfijq03bh5kee@4ax.com>  3 On Fri, 24 Aug 2001 15:03:59 +0100, andrew harrisonI! <andrew.nospam@uk.sun.com> wrote:m     >r7 >But who really cares anyway. The fact is that support  4 >for VESTED apps was specifically added to Alpha and7 >that byte aligned access was also added later because e3 >it was discovered that some VAX apps ran badly on   >Alpha.h >a3 >If you compare this with Alpha->IA64 you find the   >following differences.a >i5 >1. Intel is not going to add any support to Mckinleyt6 >assuming Mckinley is the target CPU for OpenVMS FCS, 3 >to enable emulated Alpha apps to run well on IA64.s >t/ >2. I would not take bets on them adding Alpha  5 >friendly instructions to any post Mckinley processor  >either.  F And what's amazing is that you still spew this garbage with absolutely? zero (and probably less than zero) knowledge of what's going onaF between Compaq and Intel.  And you also have *no* idea whether this isA even an issue for OpenVMS VCS on Mckinley.  You're just making upr# problems that may or may not exist.s  D Sure, you can have these opinions, and sure, you can shout them fromC the highest mountains, but where it hits you back is that you spout.; them as facts in such a way to spread fear and uncertainty.0  B Spewing this kind of crap without any sources or hard info to backC them up is FUD.  You have no way to prove/disprove your assertions,>B and you rely on the fact that it'll be years before the real truthE comes out.  By that time you'll be on to other big lies that can't ber$ disproven within the same timeframe.   ------------------------------  % Date: Mon, 27 Aug 2001 13:17:14 -0400 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>o Subject: Re: Nits in Slidesi2 Message-ID: <wgvi7.843$bB1.38851@news.cpqcorp.net>  B andrew harrison wrote in message <3B869837.F2E6E436@uk.sun.com>... >Fred Kleinsorge wrote:r >>E >> andrew harrison wrote in message <3B863910.DE584C1E@uk.sun.com>...e >> > >> >4 >> >But back to your point. Byte alligned access was1 >> >added to Alpha after the first implimentationm. >> >because of performance issues when running; >> >VAX and other apps on Alpha. While this probably wasn'tj; >> >added to specifically improve VESTED performance it wasv5 >> >also added to improve the performance of FX!32 asi; >> >well as if my memory is correct Cobol and it would haves( >> >had an impact on VESTED performance. >> > >>( >> As my Uncle used to say, horse pucky. >>I >> Partial word access was added explicitly because of NT, and the use ofe byte+ >> access both to memory *and* to IO space.1 >u. >Since you forgot Cobol you rather ruined your >point.r >:2 >Or had you forgotten the Cobol performance issues5 >that were also helped by adding byte access. I guesst1 >memory isn't what it used to be, shame about theu >name calling. >     : Did I call you the horse?  The pucky?  Or it's exit point?  K I did not forget Cobol.  The DRIVING FACTOR for partial word access was NT.S   ------------------------------  # Date: Mon, 27 Aug 2001 13:52:15 GMTt  From: jlsue <jlsuexxxz@home.com>B Subject: Re: Nits in Slides (was: Re: The Final Knell Has Sounded)8 Message-ID: <tujkotgrfk0es6aitq1oq93r77ek7h5bg1@4ax.com>  3 On Fri, 24 Aug 2001 18:55:15 +0100, andrew harrisonh! <andrew.nospam@uk.sun.com> wrote:w  
 >jlsue wrote:r >> sE >> Er, Bill, I didn't make that statement.  Something happened in them >> cut-n-paste I think >o >Err >dD >"The initial IA64 may be slower than EV7 on translated code, but it >won't stay that way forever." >m5 >Was definitely posted by you, where you got it from e$ >is anyones guess but you posted it. >7  ; Yep, you're right... I just slipped a bit when I read that.    ------------------------------  % Date: Mon, 27 Aug 2001 13:22:34 -0400 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>hB Subject: Re: Nits in Slides (was: Re: The Final Knell Has Sounded)2 Message-ID: <xlvi7.844$bB1.38939@news.cpqcorp.net>  B andrew harrison wrote in message <3B869B1C.D520C45C@uk.sun.com>... >Fred Kleinsorge wrote:  >>. >> andrew harrison pontificated like a baboon: >> >+ >> >Are you sure you are an engineer ??????m >> > >>I >> Well I sure as heck am not a self-styled "Enterprise Architect".  I'ven stillL >> to see *your* credentials.o >e2 >Since you didn't even get the title right I guess4 >you are displaying more post the 25th inexactitude. >k    C Come on you horses ass.  You are a slippery as an eel.  If there is < something you don't want to answer, you simply sidetrack it.  L Tell us exactly who you are, and what makes you qualified to be listened to.2 Give us the readers digest version of your resume.  ; I've shared mine here when *you* challenged my credentials.t   ------------------------------  # Date: Mon, 27 Aug 2001 17:39:04 GMT.2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: Node Name2 Message-ID: <YAvi7.847$bB1.39117@news.cpqcorp.net>  [ In article <01C12EF4.1865B0A0@PATRICK.FSC.COM.FJ>, A Bonaveidogo <Asena@fsc.com.fj> writes:- :-' :How to change a node name in Open VMS?   H   Please review the OpenVMS Frequently Asked Questions, and specificallyJ   the section "MGMT9. How do I change the node name of an OpenVMS System?"  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 13:32:32 -0400a5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>t> Subject: Re: Nuts-n-bolts in News (was: Re: Nits in Slides...)2 Message-ID: <Suvi7.845$bB1.38902@news.cpqcorp.net>  B andrew harrison wrote in message <3B869991.108C0BC9@uk.sun.com>... >>D >>   Byte-word can also greatly help native code execution, and this >>   is the normal case. >> > 5 >Like for example Cobol, better tell poor old Fred hem! >is confused and needs your help.r >     L Look wing nut.  Byte/Word access was not provided initially because the chipC designers felt that there would be a performance issue with it.  In.L addition, they felt IO was heading in the direction of smart controllers and all DMA.  J It turns out that byte/word access wasn't the problem they thought it was,J and PIO is still quite common.  The reason byte IO was added was that codeH size could be reduced, performance could sometimes be improved, but mostJ importantly of all - NT drivers did not need to be modified to swizzle IO.  C It wasn't done because of Cobol performance issues, or VESTed image L performance.  I'm sure that overall code size and performance was however, aD help in making the decision a no-brainer (a no brainer that had much discussion).   ------------------------------    Date: 27 Aug 2001 08:12:00 -0700* From: polato@igi.pd.cnr.it (Sandro Polato)+ Subject: Re: ODS-5 and parse_style questionS= Message-ID: <2af2b3d8.0108270712.26ff6a6d@posting.google.com>1  H > If the programs are written in C or use the C RTL to create or report H > file names, you may find it helpful to read the documentation section G > entitled "The Compaq C RTL supports case preservation in file names"   > and located here:E > B > <http://www.openvms.compaq.com/commercial/c/5763p.htm#index_x_3> > H > At first glance, it sounds like the behavior you want is actually the 3 > default, though I haven't studied this carefully.   B Yes, I have verified that programs written in C work as I need, by default.  A But the problem is with the Fortran programs and it seems that no E equivalent "DEFINE DECC$EFS_CASE_PRESERVE DISABLE" exists for Fortran  :(  6 Anyway, thanks very much for your useful informations.   
 Sandro Polato    ------------------------------    Date: 27 Aug 2001 17:53:33 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>iY Subject: Re: Prerequisite Products and IPF Porting (was: Re: The Final Knell Has  Sounded H Message-ID: <y4k7zpa48y.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  " jlsue <jlsuexxxz@home.com> writes:  B > From my experiences with the Alpha NT fiasco I learned that it'sD > better to hear directly from the corporate management than to hear4 > from the trade rags (and I use that term loosely).@ > In both cases we don't have the full impact (ISVs, engineeringA > answers, etc) worked out in time for the announcement, but I am G > positive that telling the Tru64, OpenVMS, and Tandem teams to come upD0 > with plans would have resulted in early leaks.  ' So say so publically, and don't waffle..   	Jan   ------------------------------  % Date: Mon, 27 Aug 2001 08:59:26 -0400e From: William_Bochnik@acml.com# Subject: Re: Queue/Entry managemente> Message-ID: <OF109500FB.E301D5E0-ON85256AB5.00473BF8@acml.com>  = this sounds way too much like "We don't want the operator whot< runs the backups from being able to look at the files he/sheA backs up".  Sounds good to management, but completely impracticala@ in real life.  Either the culture changes or some wrists need to be slapped when this happens.       H                                                                        =                             =20 H                     Fabio Cardoso                                      =                             =20lH                     <fabiopenvms@yah                To:  Info-VAX@Mvb.S= aic.Com                     =20oH                     oo.com.br>                      cc:                =                             =20gH                                             Subject:     Re: Queue/Entr= y management                =20nH                     08/25/2001 06:04                                   =                             =20wH                     PM                                                 =                             =20tH                                                                        =                             =20.H                                                                        =                             =20-        Probably this will not work fine here at the Company.  0 When I arrived here the systems were running for more than 10 years.L  6 The main developers are "green badge" (employees)and I6 am "brown badge" (subcontracted) ... do you understand this ?   :-)7   Fabio2    , --- Howard S Shubs <howard@shubs.net> wrote:. > In article <3B869EAB.C23C1F91@videotron.ca>,1 >  JF Mezei <jfmezei.spamnot@videotron.ca> wrote:l >m4 > > This way, you don't need to give the programmers > any privileges.e >t6 > The fun part comes if the programmers have privs for > other tasks, as is0 > usually the case, so you can't take them away. >u1 > To fix that situation, I suspect that making iti > known publically why the/ > important job disappeared would suffice.  Letc# > management take care of the rest.d > -- > Howard S Shubs2 > "Run in circles, scream and shout!"  "I hope you > have good backups!"o     =3D=3D=3D=3D=3D I =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=  =3D=3D F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazili fabiopenvms@yahoo.com.brI =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=  =3D=3D  2 __________________________________________________ Do You Yahoo!?> Make international calls for as low as $.04/minute with Yahoo!	 Messengert http://phonecard.yahoo.com/o          F ______________________________________________________________________;  The information contained in this transmission may containn@ privileged and confidential information and is intended only forA the use of the person(s) name above.  If you are not the intended-= recipient, or an employee or agent responsible for deliveringa3 this message to the intended recipient, any review,-@ dissemination, distribution or duplication of this communication? is strictly prohibited.  If you are not the intended recipient,aA please contact the sender immediately by reply e-mail and destroyw$ all copies of the original message.=   ------------------------------    Date: 27 Aug 2001 09:37:36 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)l# Subject: Re: Queue/Entry managementl3 Message-ID: <mKpVdeiYq7t1@eisner.encompasserve.org>s  _ In article <OF109500FB.E301D5E0-ON85256AB5.00473BF8@acml.com>, William_Bochnik@acml.com writes:i > ? > this sounds way too much like "We don't want the operator who > > runs the backups from being able to look at the files he/sheC > backs up".  Sounds good to management, but completely impracticale > in real life.c  = I don't see anything impractical, except for the system disk,o< but that can be done by carefully construction the alternate
 boot disk.  @ Of course since the operator has physical access to the machine,B they have the physical ability to do anything.  You need to ensure> no operator is ever on duty alone, shifts are rotated to avoid; teams, and video surveillance or something similar is used.-   ------------------------------  % Date: Sun, 26 Aug 2001 21:17:33 +0200n" From: "Hans Vlems" <hvlems@iae.nl>! Subject: TCPIP V5.0 BIND question-( Message-ID: <9mbhl4$sio$1@news.IAEhv.nl>  K Today I tried to run BIND 8 for the first time. I've used UCX V4.x and BINDo 4, no problems.d  	 Versions:-   $ tcpip sho vers  6   DIGITAL TCP/IP Services for OpenVMS VAX Version V5.0/   on a VAXstation 3100/GPX running OpenVMS V7.2:   $L  J No patches have been applied at this moment. This machine is part of a two node NI cluster. TheK other node runs TCPIP and DECnet-Plus too. In @TCPIP$CONFIG the BIND server. was enabled K and next I ran @TCPIP$BINDSETUP. The BIND server was started and after thath I tried nslookup."G That did not return the server information so I looked whether the BINDe process was running./ It wasn't and the log file showed this message:s     $O $ ON CONTROL_Y THEN GOTO EXITq
 $ SET NOON $-D $ IF F$TRNLNM("TCPIP$BIND_SERVER_DATA","LNM$SYSTEM") .EQS. "" THEN -?         DEFINE TCPIP$BIND_SERVER_DATA SYS$SPECIFIC:[TCPIP$BIND]l $z3 $ PURGE /NOLOG /KEEP=4 TCPIP$BIND_SERVER_DATA:*.LOG  $,: $ EXE = F$TRNLNM ("TCPIP$BIND_SERVER_IMAGES","LNM$SYSTEM")* $ IF EXE .EQS. "" THEN EXE = "SYS$SYSTEM:" $kD $ TCPIP$BIND_SERVER_XFER :== $ SYS$SYSTEM:TCPIP$BIND_SERVER_XFER.EXE? $ TCPIP$BIND_SERVER      :== $ SYS$SYSTEM:TCPIP$BIND_SERVER.EXE  $  $ TCPIP$BIND_SERVER H Sun 26 21:03:37 NOTICE: starting.  Digital TCP/IP Services for OpenVMS - BIND 8.n
 1.2 V5.0-9; %SYSTEM-F-ACCVIO, access violation, reason mask=01, virtualc address=FFFFFFFF, PC =0012036B, PSL=0BC00000t  2   Improperly handled condition, image exit forced.  4         Signal arguments              Stack contents  1         Number = 00000005                00000000 1         Name   = 0000000C                20FC0000 1                  00000001                7FEB79D4s1                  FFFFFFFF                7FEB7998c1                  0012036B                00034D3Ft1                  0BC00000                00000000h1                                          7FEB7940s1                                          00000000u1                                          00000000O1                                          00158D14e           Register dumpo  B         R0 = 0400000F  R1 = FFFFFFFF  R2 = 00000000  R3 = 7FEB7980B         R4 = FFFFFFFF  R5 = 00000000  R6 = 0000000F  R7 = 0000000FB         R8 = 0003258C  R9 = 000A2F98  R10= 000A2D00  R11= 000A2CA8B         AP = 7FEB78C8  FP = 7FEB7888  SP = 7FEB7904  PC = 0012036B         PSL= 0BC00000o   $t  
 Any ideas?  
 Hans Vlems   ------------------------------  % Date: Tue, 21 Aug 2001 16:23:54 +0100 8 From: "Gary McDonald" <gary.mcdonald@uk.thalesgroup.com>
 Subject: testa% Message-ID: <9ltuf7$7gd$2@rdel.co.uk>    ------------------------------    Date: 27 Aug 2001 14:55:45 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>n( Subject: Re: The Final Knell Has SoundedH Message-ID: <y4ofp1acha.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ) "Bill Todd" <billtodd@foo.mv.com> writes:t  H > > You forgot Alta-Vista.  Bought as part of the deal and sold about 18E > > months later for, IIRC, about 2 or 3 times what they paid for it.SK > My vague memory is that the deal was paid for in CMGI stock, which proved4K > very desirable in the short term but later lost a great deal of its valuemL > (and my also-vague impression is that Compaq may have failed to capitalizeG > on the opportunity before the bottom dropped out of it).  Corrections 
 > welcome.  F AFAIR, one of the recent quarters carried a ~$2B exceptional charge as write-off of the CMGI stock.   	Jan   ------------------------------    Date: 27 Aug 2001 15:03:14 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>t( Subject: Re: The Final Knell Has SoundedH Message-ID: <y4lmk5ac4t.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>   eccm <eccm@swbell.net> writes:  C > If Compaq continues with Alpha, none will be more pleased than I. F > However, I can only see this happening if the Intel product fails toG > perform as promised. Perhaps if a large enough majority at Encompass'dH > 'Compaq Listens' session voice an opinion in accordance with yours andF > that of many others who are pissed off, it might make a difference.   L That is extremely unlikely. Part of the people involved have moved to Intel,M others to who knows where. You can't revive such development projects just bynK hiring new people and having them sit down in front of the previous group'shM workstations. Intel now owns the IP rights, so Compaq would have to talk them/ into nullifying that contract. o  K In fact, I'd say no way in hell is there a chance of undoing this decision.a> This is the Chinese variant of execution, not the USA variant.   	Jan   ------------------------------  % Date: Mon, 27 Aug 2001 10:34:26 -040002 From: rdeininger@mindspring.com (Robert Deininger)( Subject: Re: The Final Knell Has SoundedL Message-ID: <rdeininger-2708011034270001@user-2ivec44.dialup.mindspring.com>  H In article <y4lmk5ac4t.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>,H Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:    eN > That is extremely unlikely. Part of the people involved have moved to Intel,O > others to who knows where. You can't revive such development projects just bynM > hiring new people and having them sit down in front of the previous group'so > workstations.   A > Intel now owns the IP rights, so Compaq would have to talk thema! > into nullifying that contract.    ? This part isn't true.  Compaq owns the IP; they granted Intel aSG non-exclusive license.  Compaq can still do anything they want with the D IP.  Compaq also agreed to release a bunch of employees to Intel.  IF suspect there's a clause somewhere that prevents Compaq from trying to6 hire those folks back for some minimum period of time.  D As you say, getting the people back is the near-impossible part.  IfJ Compaq had the will, and a lot of extra money, they could do it.  But they
 have neither.a   --   Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Mon, 27 Aug 2001 13:19:02 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>-( Subject: Re: The Final Knell Has Sounded, Message-ID: <3B8A8105.DBFAF845@videotron.ca>   Jan Vorbrueggen wrote:M > hiring new people and having them sit down in front of the previous group'seO > workstations. Intel now owns the IP rights, so Compaq would have to talk them.  > into nullifying that contract.  M While I agree that the odds of Compaq fixing its mistake are very low (CompaqiK sees this as a good move, not a mistake), I beleive that Compaq does retainrN rights to the Alpha technology and has simply given Intel carte blanche to use3 whatever it wants from Alpha's list of patents etc.   " Is that a correct interpretation ?  N So technically, Compaq could restart Alpha.  They still have EV7 team for now.   ------------------------------  % Date: Mon, 27 Aug 2001 00:29:09 -0700s- From: "Spawn Devices" <info@spawndevices.com>R8 Subject: This Weekends Sale... All Combo Pkg\\\'s $79.997 Message-ID: <200108270729.AAA22582@star1.baremetal.com>r  2Well it seems the www.spawndevices.com $15 - $25 buck boots and emu\'s made a few of you happy.... good... glad to hear it... Well the special for you this weekend is all Combo Packages are $79.99... Your choice an Emu or a Bootstrap (DPBB) with either a Dual Crystal ISO or a WT2-X unlooper... your call. a Hope you all Have a Great Weekend... and thanks for the great response on the product lines. {:-) v PLEASE REMEMBER TO LOG ON to www.spawndevices.com and enter to win anyone of our great products...FREE WEEKLY DRAWS...   www.spawndevices.com9 *********************************************************e To be removed from our mailing list please click on this link and follow the directions on the webpage; http://www.spawndevices.com/remove.phtml   ------------------------------  # Date: Mon, 27 Aug 2001 14:34:24 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)% Subject: Re: V5.5-2 Password RecoveryD2 Message-ID: <QTsi7.819$bB1.38112@news.cpqcorp.net>  g In article <5kPh7.56502$wX5.4465432@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:n6 : Discussion of brute-force password attack expurgated  G   Yes, and this is also why you want to keep the password file (and anyc1   archive copies of the password file) protected.-  I :p.s. ten years out, Compaq may wish to allow case sensitive passwords in  :OpenVMS  G   When using external authentication, this is already available.  (Some-6   external authentication requires case preservation.)   	---  G   In a recent conversation, one of the folks familiar with the securitydI   plans expects most folks will be moving to external authentication via  H   Kerberos or otherwise, particularly as the application authentication D   tie-ins are made available and become more prevalent.  There is anG   expectation that the local authentication will be less commonly used.B    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 14:48:37 GMTn2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)% Subject: Re: V5.5-2 Password Recoveryo2 Message-ID: <95ti7.825$bB1.38241@news.cpqcorp.net>  g In article <%gSh7.67742$wZ3.5135477@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:u  H :I'm not worried about someone breaking into my OpenVMS system, but I amJ :worried about someone with privs doing something illegal. For example, ifM :wished to do something criminal I may want to log on as someone else, commit L :my fraud, then put everything back in order to cover my tracks. As a systemM :manager I already have privs to change someone's password, but I didn't have-& :the tools to put it back (until now).  J   Without going into details, you cannot protect against privileged users.  G   If you have untrusted users with privileges -- and some sites clearlycJ   have data that cannot be trusted to any individual user -- you must use L   the dual-password (two users present) logins and/or monitoring techniques.  K :I accept your argument about lower case, but as machines get faster CompaqnB :will need to do something (go to a 128 or 256 bit hash perhaps?).  <   The "key" is the length of the input string; the password.  K   The output hash value needs to be distributed through the quadword-lengthrK   hash range, with great variances in the output values derived from small yF   variances in the supplied (password) input, and with few duplicates.  E   We have provided password generation, which tends to require betteroH   password.  (Then there are site-specific password filters, where thereL   are requirements for various combinations of specific ranges of characters   and similar.)   L   Password-based authentication mechanisms typically all have various known A   vulnerabilities.  (Though not always the same vulnerabilities.)o  I   I am trying to carefully phrase and carefully limit what information I d@   provide here, as nefarious-minded folks also read comp.os.vms.  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: 27 Aug 2001 08:56:57 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)u% Subject: Re: V5.5-2 Password Recovery , Message-ID: <Av3k0LEztCRK@malvm5.mala.bc.ca>  3 In article <QTsi7.819$bB1.38112@news.cpqcorp.net>, c7    hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes:1   > I >   In a recent conversation, one of the folks familiar with the securityWK >   plans expects most folks will be moving to external authentication via hJ >   Kerberos or otherwise, particularly as the application authentication F >   tie-ins are made available and become more prevalent.  There is anI >   expectation that the local authentication will be less commonly used.  > H     Are those application authentication hooks available (documented) inB VMS 7.3? If not, any estimate when us mere mortals might see them?   ------------------------------  # Date: Mon, 27 Aug 2001 13:32:03 GMT - From: Chapour FAZAELI <ind14@etu.enseeiht.fr>  Subject: VAX 3100+4 / Message-ID: <3B8A4BF2.E7F6608E@etu.enseeiht.fr>   < I can sell a VAX 3100+4 model. If you are interested, please	 mail to :    ind14@etu.enseeeiht.fr   C.F.   ------------------------------  % Date: Mon, 27 Aug 2001 07:55:11 -05008+ From: "Mike Kier" <michael.kier@compaq.com> 5 Subject: Re: VMS high reliability needed by Air Force 2 Message-ID: <Uqri7.809$bB1.37272@news.cpqcorp.net>  H One of my favorites was the IAS V2.x message we got on the LA36 when theH system manager violently kicked the RDC console after yet another system! hang that we couldn't diagnose...    "Kernel APRs Clobbered"    --	 Mike Kier  Compaq Professional Services Cincinnati, OH, USAt michael.kier@compaq.como  6 "Main, Kerry" <Kerry.Main@compaq.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF4D56090@kaoexc01.americas.cpqcorp.net... > re: system crash messages .. >)D > Actually, I kind of always thought the UNIX "panic" message was an8 > interesting approach to describe this type of event... >@ > :-)o >a	 > Regardse >  > Kerry Main > Senior Consultante > Compaq Canada Corp.o > Professional Servicesp > Voice: 613-592-4660l > Fax  :  819-772-7036 > Email: Kerry.Main@Compaq.com   ------------------------------  # Date: Mon, 27 Aug 2001 17:13:19 GMTh% From: "Dan Cauley" <Cauley@telus.net>I Subject: VMS Hobbyist Programw< Message-ID: <Pcvi7.98113$b_3.12496415@news0.telusplanet.net>  L Hi there I have been trying for quite some time to contact DECUS Canada so IF can become a member.  I have sent several e-mails to them and have notI gotten any response.  Could someone out there please tell me whom I might=I contact to get the nessacary information to join the Users group/Hobbyistr Program?   Thanks in advance.                         Dan.   ------------------------------  % Date: Mon, 27 Aug 2001 20:54:09 +0300 1 From: "_jussi" <jaakonaho@nospam.juhani.decus.fi>_! Subject: Re: VMS Hobbyist Programl+ Message-ID: <9me166$gkc$1@news.kolumbus.fi>   0 "Dan Cauley" <Cauley@telus.net> wrote in message6 news:Pcvi7.98113$b_3.12496415@news0.telusplanet.net...K > 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/Hobbyistt
 > Program? -the website is here:e+ http://www.montagar.com/hobbyist/index.html    _jussi   ------------------------------   Date: 27 Aug 2001 14:39:47 GMT! From: Mark Hatch <mhatch@ics.com>bN Subject: www.motifzone.net - the site for Open Motif Developers (monthly post)' Message-ID: <3B8A5BB2.C1E41739@ics.com>a  D The Motif Zone (http://www.motifzone.net) is the center of a growingH community of open source developers dedicated to the ongoing developmentG and maintenance of Open Motif. In the last 12 months, the MotifZone has:B hosted over 500,000 downloads of Open Motif and processed over 30+G Million website hits. With over 4,000 registered members, the MotifZonelE provides an unique site that combines the talents of mission criticalh> application developers with the innovations of the open source
 community.  A The latest binaries and sources of Open Motif, as well as relatedbB software, are hosted at the MotifZone and are freely available forE downloads. An anonymous CVS tree is also provided to those that wouldeD like to enhance or just learn more about the GUI toolkit that is theH industry standard on UNIX workstations. In addition, the MotifZone hosts3 the official Open Motif defect tracking system too.e  E A number of community efforts are underway at the MotifZone to extenda  and improve Motif. Specifically: - Embedded Open Motif- - Themes for OpenMotifH - Autoconfigure building of sources (for those preferring an alternative	 to imake) 
 - Tooltips  H For developers looking to program using the Motif toolkit, the MotifZone@ offers the Internet's largest collection of reference materials,E tutorials, technical articles and formal documentation on X and MotifnH programming. Hundred's of links are provided to both commercial and open( source tools that can speed development.  A The Open Help Forums provides a selection of channels for postingoG questions and receiving help from your peers. The signal-to-noise ratio G of these channels is high with questions typically being "on-topic" anddE none of the usual "get rich quick" scams seen on the comp.x.windows.*a? newsgroups. The use of nicknames for identification provides an'H effective barrier to spammers that comb the newsgroups looking for email
 addresses.  H And of course, the MotifZone provides the usual collection of feeds fromC sites like Freshmeat, Slashdot and Linux Today so that you can stayl. current with the latest changes in technology.  < The Motif Zone is sponsored by Integrated Computer SolutionsD (http://www.ics.com), providers of GUI development tools for X/Motif developers.R   ------------------------------    Date: 27 Aug 2001 07:27:21 -0500 From: briggs@encompasserve.orgC Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically? 3 Message-ID: <pcfhZ3VvojFv@eisner.encompasserve.org>   c In article <Wii4aOVLMMk6@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:PW > In article <3B87351F.60BEAC3A@gmx.ch>, Didier Morandi <Didier.Morandi@gmx.ch> writes:m >> Larry Kilgallen wrote:t >>> L >>> While that is a good feature, I don't understand why that implementation? >>> is any better than the journal files made by Backup itself.  >> EQ >> Maybe because all the history is in only one file instead of thousand of .LOG?6 > > > 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.e9 > The format is specifically designed to be extended, andF. > to be readable either in forward or reverse.  C Using one central .BJL file and appending to it, ad infinitum would0D not be a tenable history solution for many sites.  The file size andF the corresponding search time would become unacceptable.  In addition,B contention between search and append access from multiple parallelG streams could become problematic.  And worse, .BJL files do not contain.F device information.  Finally, partial deletion from a master .BJL file is not to be contemplated.  / If you had to scan your master .BJL looking for2> DRA2:[KILGALLEN.FOOBAR]SCRUB.LOG then you would have problems.  H Obviously, many of the problems with a .BJL style history database couldH be mitigated by using a one .BJL file per backup scheme.  But that stillI leaves you with the performance issue of a sequential scan lookup scheme.h    I In fact, (as of the last time I looked at it anyway), the TAPESYS historyh? database is composed of hundreds of indexed files, one for each B top level directory name on your system.  It is populated in batchD mode by running the .BJL file produced by each BACKUP job through anH automated update process.  This minimizes the possibility for contention& between competing readers and writers.  D Within each file you have a record for each time a file in the namedE directory has been backed up.  And the record goes away when the tape-E is re-allocated.  (Actually the next night -- there's a cleanup job).b  : This database can be scanned quickly.  Which is the point.  B Add to that the fact that the database format is understood by theF TAPESYS software so that you can have end users searching the databaseH using a menuing system and requesting restores which will run completelyE automatically (prompting system operators for tape mounts, of course) , and you've got a halfway decent tape system.   	John Briggs   ------------------------------    Date: 27 Aug 2001 07:34:19 -0500 From: briggs@encompasserve.orgC Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically? 3 Message-ID: <E9usDi3CdU+P@eisner.encompasserve.org>m  n In article <1UkZnXVymVWy@tachxxsoftxxconsult>, wayne@tachysoft.xxx.374515.killspam.015f (Wayne Sewell) writes:e > In article <YBBKTGNGOdO4@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: q >> In article <uy9$+Z2W3M$5@tachxxsoftxxconsult>, wayne@tachysoft.xxx.580099.killspam.0160 (Wayne Sewell) writes:c >>  L >>> And also the files on them.  The history database is one of the greatestP >>> features of tapesys.   It can keep track of every file on every tape and youP >>> can do a lookup in seconds.  If a user comes to you and says "I accidentallyL >>> deleted my login com and I want it back", you don't have to wade through> >>> listings or anything else to determine what tape it is on. >> rK >> While that is a good feature, I don't understand why that implementationi> >> is any better than the journal files made by Backup itself. >> t >> But I am ready to be taught.d >  > P > Me, too.  :-)  In order to contrast history and journal files intelligently, IO > need to understand more about how journal files work.  I've never used them. oN > I've had tapesys all the time I've been consulting (software partners was myP > first client, in april of 92), and before that, when I worked for a company, IP > was a system programmer, not a system manager.  Backups and such were somebodyC > else's job.  So I really don't know anything about journal files.   J A backup journal file (.BJL) has just about the same amount of informationF on each file that you would get from a BACKUP /LIST command.  But in aN binary format.  Indeed, one can regenerate BACKUP /LIST (but not BACKUP /LIST % /FULL) output with a command such as:,    	$ BACKUP /LIST /JOURNAL=FOO.BJL  C Note that you do not get the BACKUP /LIST header output identifying- the backup command used, etc.e   	John Briggs   ------------------------------    Date: 27 Aug 2001 07:36:16 -0500 From: briggs@encompasserve.orgC Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?e3 Message-ID: <nTrmoDBEsekX@eisner.encompasserve.org>n  n In article <1UkZnXVymVWy@tachxxsoftxxconsult>, wayne@tachysoft.xxx.374515.killspam.015f (Wayne Sewell) writes:P > I will mention one brief point, however -- speed of access.  The journal filesO > appear to be organized by saveset, while the history database is organized by L > file.  Instead of telling you which files are in a particular saveset, theM > history database tells you which savesets contain a particular file.   EachnO > file record contains an array of pointers to the saveset records that containsN > that file.   This can make a big time difference in searching, especially ifP > the file existed only for a brief period and you have no idea which saveset(s)M > 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.  G Ooops.  I wrote previously that the history database had one record perhF file per backup.  As you correctly indicate above, it's one record perE file with a variable-length payload that contains a list of the times  the file was backed up.    	John Briggs   ------------------------------   Date: 27 Aug 2001 10:06:20 CDT= From: wayne@tachysoft.xxx.374515.killspam.015f (Wayne Sewell) C Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?y. Message-ID: <CwFCgxJOI$Yd@tachxxsoftxxconsult>  T In article <pcfhZ3VvojFv@eisner.encompasserve.org>, briggs@encompasserve.org writes:e > In article <Wii4aOVLMMk6@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:tX >> In article <3B87351F.60BEAC3A@gmx.ch>, Didier Morandi <Didier.Morandi@gmx.ch> writes: >>> Larry Kilgallen wrote: >>>> aM >>>> While that is a good feature, I don't understand why that implementation @ >>>> is any better than the journal files made by Backup itself. >>> R >>> Maybe because all the history is in only one file instead of thousand of .LOG? >>  ? >> The default file extension for Backup Journal Files is .BJL.d> >> While you can name it anything you want, it would be in the? >> interest of communications to use the default extension namee >> in discussions here.t >> o< >> 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.) > E > Using one central .BJL file and appending to it, ad infinitum wouldsF > not be a tenable history solution for many sites.  The file size andH > the corresponding search time would become unacceptable.  In addition,D > contention between search and append access from multiple parallelI > streams could become problematic.  And worse, .BJL files do not containoH > device information.  Finally, partial deletion from a master .BJL file > is not to be contemplated. > 1 > If you had to scan your master .BJL looking for.@ > DRA2:[KILGALLEN.FOOBAR]SCRUB.LOG then you would have problems. > J > Obviously, many of the problems with a .BJL style history database couldJ > be mitigated by using a one .BJL file per backup scheme.  But that stillK > leaves you with the performance issue of a sequential scan lookup scheme.  >  > K > In fact, (as of the last time I looked at it anyway), the TAPESYS history.A > database is composed of hundreds of indexed files, one for each D > top level directory name on your system.  It is populated in batchF > mode by running the .BJL file produced by each BACKUP job through anJ > automated update process.  This minimizes the possibility for contention( > between competing readers and writers. > F > Within each file you have a record for each time a file in the named! > directory has been backed up.  a  G Close.  As I said elsewhere in the thread, there is one record per filetN *period*, no matter how many times it has been backed up.  The record containsJ an array of pointers, each only 6 bytes in size, indicating which savesetsM contain this  particular file.  Which of course is even better, for both disku space and speed of access.  :-)p  L The tapesys 6.0 format is even tighter.  The individual file record containsL only the binary *version* of the file with a pointer to the file name recordK and the saveset pointers.  Therefore, if a particular file has thousands oflM versions, each of those versions requires a total of 12 + (pointer_count * 6) I bytes, where pointer_count is the number of savesets the file resides in.s  ' >And the record goes away when the tape G > is re-allocated.  (Actually the next night -- there's a cleanup job).  > < > This database can be scanned quickly.  Which is the point. > D > Add to that the fact that the database format is understood by theH > TAPESYS software so that you can have end users searching the databaseJ > using a menuing system and requesting restores which will run completelyG > automatically (prompting system operators for tape mounts, of course)e. > and you've got a halfway decent tape system.   We think so.  :-)e   -- iO ===============================================================================pM Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxx-: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-)iO =============================================================================== H Randolph Duke (in Trading Places): "Mother always said you were greedy.". Mortimer Duke: "She meant it as a compliment!"   ------------------------------   Date: 27 Aug 2001 10:13:50 CDT= From: wayne@tachysoft.xxx.374515.killspam.015f (Wayne Sewell)TC Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?p. Message-ID: <D9a9CWpRrA7U@tachxxsoftxxconsult>  T In article <nTrmoDBEsekX@eisner.encompasserve.org>, briggs@encompasserve.org writes:p > 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 filesnP >> 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 ifsQ >> 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.e > I > Ooops.  I wrote previously that the history database had one record per-H > file per backup.  As you correctly indicate above, it's one record perG > file with a variable-length payload that contains a list of the timesc > the file was backed up.e >  > 	John Briggs  F Oops, me too.  I corrected your earlier post before reading the one inI which you corrected yourself.  Sorry about that.  Ah, the joys of usenet.a   :-)      -- KO ===============================================================================5M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxx : 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 =============================================================================== H Randolph Duke (in Trading Places): "Mother always said you were greedy.". Mortimer Duke: "She meant it as a compliment!"   ------------------------------    Date: 27 Aug 2001 10:46:55 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)sC Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?e3 Message-ID: <34vla5C1uCqH@eisner.encompasserve.org>   n In article <CwFCgxJOI$Yd@tachxxsoftxxconsult>, wayne@tachysoft.xxx.374515.killspam.015f (Wayne Sewell) writes:V > In article <pcfhZ3VvojFv@eisner.encompasserve.org>, briggs@encompasserve.org writes:  G >> Within each file you have a record for each time a file in the namedd" >> directory has been backed up.   > I > Close.  As I said elsewhere in the thread, there is one record per filerP > *period*, no matter how many times it has been backed up.  The record containsL > an array of pointers, each only 6 bytes in size, indicating which savesetsO > contain this  particular file.  Which of course is even better, for both disk ! > space and speed of access.  :-)  > N > The tapesys 6.0 format is even tighter.  The individual file record containsN > only the binary *version* of the file with a pointer to the file name recordM > and the saveset pointers.  Therefore, if a particular file has thousands of O > versions, each of those versions requires a total of 12 + (pointer_count * 6)wK > bytes, where pointer_count is the number of savesets the file resides in.D  3 Still, that should limit the number of savesets to:/   	(32767-12)/6 = 5459  ; so what would happen if there were more backups than that ?i  @ In some situations key files can get backed up considerably moreB often than once per day.  There are at least 8760 hours in a year.  1 Or is this tapesys data not stored in RMS files ?t   ------------------------------    Date: 27 Aug 2001 11:34:02 -0500 From: briggs@encompasserve.orgC Subject: Re: [Q]: How to get BACKUP to relabel tapes automatically?i3 Message-ID: <gP$MYURngrqc@eisner.encompasserve.org>r  c In article <34vla5C1uCqH@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:yp > In article <CwFCgxJOI$Yd@tachxxsoftxxconsult>, wayne@tachysoft.xxx.374515.killspam.015f (Wayne Sewell) writes:O >> The tapesys 6.0 format is even tighter.  The individual file record containssO >> only the binary *version* of the file with a pointer to the file name recordmN >> and the saveset pointers.  Therefore, if a particular file has thousands ofP >> versions, each of those versions requires a total of 12 + (pointer_count * 6)L >> bytes, where pointer_count is the number of savesets the file resides in. > 5 > Still, that should limit the number of savesets to:s >  > 	(32767-12)/6 = 5459 > = > so what would happen if there were more backups than that ?e  B Well, you'd have to have more than 5459 backups with the tapes notH yet re-allocated.  Or the database not subsequently cleaned.  And they'dC have to be in the same history set.  (You can have more than one --o6 monthlies and dailies and user backups, for instance).  3 Unfortunately, the actual answer is "I don't know".-  E Yes, the limit is real.  Yes, RMS indexed files are used.  Obviously,nE clever programmers could have dealt with the issue by adding overflow.F records with the same or slightly different primary key.  Whether they. actually did deal with it is another question.   	John Briggs   ------------------------------   End of INFO-VAX 2001.476 ************************