1 INFO-VAX	Mon, 30 Jul 2001	Volume 2001 : Issue 420       Contents: Re: absolute beginner ( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate ANNOUNCE: MicroEMACS 4.00 % Re: Change account password using web  Re: checking some myths. Re: checking some myths. Re: checking some myths.& Re: Compaq FUD and lack of information& Re: Compaq FUD and lack of information& Re: Compaq FUD and lack of information Re: Compaq's Q2 financials Re: Compaq's Q2 financials Re: Compaq's Q2 financials) Connections to VAX and Dec legacy systems - Re: Connections to VAX and Dec legacy systems " DEC/EDI v3.2B Contrl message query& Re: DEC/EDI v3.2B Contrl message query, Errors in executing the upgrade 7.2-1 to 7.30 Re: Errors in executing the upgrade 7.2-1 to 7.3 Re: FastCGI support in CSWS $ Re: Few People in DEC Understood....$ Re: Few People in DEC Understood....$ Re: Few People in DEC Understood....$ Re: Few People in DEC Understood.... Goodbye, good friend DEC Re: Goodbye, good friend DEC Re: Goodbye, good friend DEC% Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance : Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS): Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)P Re: Ken Olsen (and DEC History), was: Re: Escape sequences not filtered   in VMS$ Re: login-f-clisymtbl error on Alpha$ Re: login-f-clisymtbl error on Alpha( Memo:  Re: benchmarking disk performance, RE: Memo:  Re: benchmarking disk performance memory for Alphaserver 4/200  Re: memory for Alphaserver 4/200  Re: memory for Alphaserver 4/200  RE: memory for Alphaserver 4/200" Re: Min Mem on a  DEC 3300 for VMS" RE: Min Mem on a  DEC 3300 for VMS" Re: Min Mem on a  DEC 3300 for VMS? Re: Now we're cooking with gas. (was:  Wailing and moaning....)  Re: Ont "The Inquirer" today.  Re: Ont "The Inquirer" today.  Re: Ont "The Inquirer" today. B Re: OpenVMS on IPF (was re: IPF already needs a face-lift for VMS) Re: Oracle file size and VMS Re: Oracle file size and VMS Print Queue's on IP Addresses $ Re: Selling VMS to another company ?$ Re: Selling VMS to another company ?
 Re: Sixels Soft font modules / DCPS?  Re: Soft font modules / DCPS? 4 Standalone Backup and Restore on VAXStation 4000 90A" Re: Sun goes after Alpha user base" Re: Sun goes after Alpha user base" Re: Sun goes after Alpha user base" RE: Sun goes after Alpha user base Sun keep 'em coming  Re: Sun keep 'em coming  Re: Sun keep 'em coming  The death of Storageworks  Re: The death of Storageworks  Re: The death of Storageworks  Re: The death of Storageworks  Re: The death of Storageworks  Re: The death of Storageworks  Re: VM: checking some myths.$ VMS marketing event in Cupertino, CA( Re: VMS marketing event in Cupertino, CA( Re: VMS marketing event in Cupertino, CA Re: VMS Trivia Question   Re: Who does migration from VMS?  F ----------------------------------------------------------------------    Date: 30 Jul 2001 12:02:01 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: absolute beginner* Message-ID: <3b653099$1@news.kapsch.co.at>  L In article <9jsjo8$21a$1@kadath.deep.it>, Cthulhu <noone@nowhere.it> writes:/ >Luca Balzano <luca.balzano@antispam.it> wrote: J >> OpenVMS. Somebody told me that since I live in Italy this could be more
 >> difficult.  > G >The problem here in Italy is that when DECUS disappeared, nothing went  >in its place.F >So, we can't anymore register as a DECUS member, we can't get a DECUS# >ID, we can't request Hobbist PAKs.   @ Try DECUS Mnchen e.V. (means DECUS Germany http://www.decus.de)@ They are not restricted to only local users (as whole Austria isB only a LUG of this chapter) and I regularly meet people of over 10E different nations on the annual symposium there. Membership is free !   F DECUS Germany is still DECUS (no merger plans are made public - thoughK talks with the ITUG still continue) and is so far well supported by COMPAQ.    --  < Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888 < <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------  % Date: Mon, 30 Jul 2001 11:41:05 +0100 0 From: andrew harrison <andrew.nospam@uk.sun.com>1 Subject: Re: Alpha:  an invitation to communicate * Message-ID: <3B6539C1.C777FAA7@uk.sun.com>   jlsue wrote: > 5 > On Thu, 26 Jul 2001 20:58:23 +0100, andrew harrison # > <andrew.nospam@uk.sun.com> wrote:  >    Childish name calling snipped. > > H > >Rubbish, IBM have made no such statement. IBM's Intel server divisionF > >(Sequent + Netinfinity) have said that they will be producing IA-64H > >based boxes (its a logical followon from IA-32 based systems. None ofC > >IBM's other product ranges have made any such statement. You are ? > >doing it again, being cavalier with the truth, as always you : > >would be better off checking your facts before posting. > H > At worst, I only mis-remembered.  Get a life buddy.  I certainly don'tH > have all day to check news from 2 or 3 years ago, but I seem to recallB > that IBM was talking about migrating RS6000 stuff (AIX) to IA64.( > Perhaps I must remembered incorrectly.  C You did. What may have confused you is that IBM are porting AIX to  C IA-64 so that they have one UNIX offering on their Power and Intel  @ based systems. This isn't a migration because IBM have no public$ or rumoured intention to drop Power.   Regards  Andrew Harrison  Enterprise IT Architect    ------------------------------  % Date: Mon, 30 Jul 2001 14:08:48 +0100 0 From: andrew harrison <andrew.nospam@uk.sun.com>1 Subject: Re: Alpha:  an invitation to communicate * Message-ID: <3B655C60.ECC8309A@uk.sun.com>   Brannon Batson wrote:  > d > andrew harrison <andrew.nospam@uk.sun.com> wrote in message news:<3B60765F.27393BB5@uk.sun.com>... > > jlsue wrote: > > > L > > > On Mon, 23 Jul 2001 20:54:28 -0400, Bill Gunshannon <bill@cs.uofs.edu> > > > wrote: > > > ( > > > >On Mon, 23 Jul 2001, jlsue wrote: > > > >  > > > >> > > > >> [snip]  > > > >  > > > > [snip] > > ? > > Good joke in this case. How would you describe a vendor who @ > > has used underhand methods including being slightly cavalier@ > > with the truth to convince you to keep buying their product. > @ > How would you describe a vendor [SUN] that designed shoddy andF > unreliable memory systems that failed frequently, and when customersE > complained they then forced those customers into signing NDA's as a D > condition of fixing the problem?[which was an obvious design flaw] >   : Well ignoring the name calling, could you even get an NDA : that would have warned you about the true Alpha situation ! before the Intel announcement ???   : I recently spoke to a prospective GS customer (no longer) 5 who got a Marvel NDA the week before the Alpha/Intel  5 announcement, it included a totally ficticious as it   turned out Alpha roadmap.   ; > > If FUD is telling the truth about the inadequacies of a > > > competitors product and in this case anti-FUD as practiced; > > by various posters to this group is telling what turned : > > out to be untruthes about capabilites and prospects of< > > Compaqs products then call me a FUDSTER any day at least > > I will sleep at night  > G > Untruths of capabilities and prospects of products?  The UltraSparc 3 G > systems are susceptible to a prefetcher bug, the only fix of which is C > to disable the prefetcher via a firmware update.  This lowers the G > performance of the Blade systems by 5-15% depending on the benchmark. E > So, has Sun pulled their benchmark numbers for the systems with the D > prefetcher enabled?  Of course not...they continue to sell systems@ > with benchmark numbers that customers cannot reproduce without= > introducing a fatal bug into the reliability of the system.  >   3 Really, the WildFire has a system design bug which  2 means that local memory latency is a whopping 300+4 ns and remote is a even more whopping 900+ ns. There3 is no patch for this and the only work around is to 3 use things like Oracle in a way that most customers 1 would not contemplate. Customers using DBMS like  " Sybase cannot use this capability.  2 Engineers/Product marketing people at Compaq tried1 to hid the problem by favourably comparing these  3 numbers with a completely ficticious set of numbers % that they had made up for a Sun E10K.   / There is also no roadmap to fix this unless you 0 count the complete replacement of the box with a yet to be announced system.   4 Despite this Compaq are still selling GS160/320's as5 fit for purpose OLTP systems when in fact they arn't.   4 The Sun prefetch issue on the otherhand has a patch 1 that does fix the problem and also has a roadmap  5 to permanently fix the problem (UltraIII+) this will  1 be available for all current systems rather then  4 the WildFire fix which requires a totally new system5 and on the WildFire side the performance differential  looks to be arround 30%.  C > I don't like Compaq, but don't pretend that your company is above  > reproach.  >   
 Its relative.   , On this newsgroup we have had the following 	 bullshit.   
 Galaxies.   . Spiralog. It was going to ensure that OpenVMS * trashed all other OS's on OLTP throughput.  - WildFire performance. It was going to exceed   all the competition.  6 WildFire availability. it was going to be out 2 years  before it actually arived.  * Alpha commitment and longevity (25 years).  ) Various projected availability statements  for Alpha CPUs all wrong.   $ NT on Alpha support (it evaporated).  , NT on Alpha performance comparisons with NT 2 on Intel, there was never a case based on standard benchmarks.   1 Various OpenVMS vs UNIX cluster comparisons which / have only demonstrated that the posters didn't  " know anything about UNIX clusters.  ) Various statements of undying support for * OpenVMS apparently from key ISV's followed, by the ISV in question dropping or partially dropping OpenVMS as a platform.   0 Now some of this information came directly from 0 Compaq either from Compaq posters or from Compaq1 white papers. Others came from people who claimed 1 to have sources inside Compaq. In particular some 4 of the Compaq sources are still posting and despite 6 having been wrong on more cases than is worth counting- have not modified their posting style of the   content.  5 Given flow of BS coming from the Compaq camp I think  7 that getting people to sign NDA's on ecache issues and  > having to patch the UltraIII systems is a pretty undewhelming 7 argument for any kind of parity between Compaq and Sun.    Regards  Andrew Harrison  Enterprise IT Architect    ------------------------------    Date: 30 Jul 2001 16:33:42 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> 1 Subject: Re: Alpha:  an invitation to communicate H Message-ID: <y4ofq2jxkp.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  2 andrew harrison <andrew.nospam@uk.sun.com> writes:  , [antecedant was about E10K cache corruption]5 > Really, the WildFire has a system design bug which  4 > means that local memory latency is a whopping 300+0 > ns and remote is a even more whopping 900+ ns.  + "Fast research, fast results, fast richtig"   = Sorry for the bilingual pun, but I find it quite appropriate.    	Jan   ------------------------------  # Date: Mon, 30 Jul 2001 14:26:49 GMT   From: jlsue <jlsuexxxz@home.com>1 Subject: Re: Alpha:  an invitation to communicate 8 Message-ID: <51qamtkojj4671jm44rv16de0kf0t1d53q@4ax.com>  3 On Mon, 30 Jul 2001 14:08:48 +0100, andrew harrison ! <andrew.nospam@uk.sun.com> wrote:      > 4 >Really, the WildFire has a system design bug which 3 >means that local memory latency is a whopping 300+ 5 >ns and remote is a even more whopping 900+ ns. There 4 >is no patch for this and the only work around is to4 >use things like Oracle in a way that most customers2 >would not contemplate. Customers using DBMS like # >Sybase cannot use this capability.   E THIS is exactly what anyone would call FUD.  There is no bug, and all D architectural performance characteristics have been fully disclosed.  F How you can compare this to a *real* bug that causes systems to crash,F corrupt data, etc., is beyond me.  It only shows your complete lack of ethics.   B And they provided benchmarks for the performance that everyone has access to for comparison.   A If you think it actually matters whether they've used OPS or not, B you're kidding yourself (wishful thinking on your part).  BusinessD managers say "I have $x to spend, what performance can you give me?"F They don't dwell on esoteric issues like whether OPS is implemented orE not.  As someone else said before, any DBA worth their salt will have @ very little problems with OPS.  I know several, and we've always= worked well together on VMScluster solutions - and these were A Unix-based DBAs, no VMS experience prior to our working together.    > 5 >Despite this Compaq are still selling GS160/320's as 6 >fit for purpose OLTP systems when in fact they arn't.  E Blah, blah, blah.  THIS is only *your* personal opinion.  The problem B is, and the reason you lack so much credibility, is that you can'tE seperate your opinions from actual facts.  The actual fact shows that E we have many, many happy customers who've implemented just that which  you show so much scorn.    > 5 >The Sun prefetch issue on the otherhand has a patch  2 >that does fix the problem and also has a roadmap 6 >to permanently fix the problem (UltraIII+) this will 2 >be available for all current systems rather then 5 >the WildFire fix which requires a totally new system 6 >and on the WildFire side the performance differential >looks to be arround 30%.   A FUD.  There is nothing to fix on the GS systems.  The performance E characteristics are known, as well as the trade-offs.  They work very C well within the documented trade-offs.  At least Compaq is actually 5 truthful in disclosing those trade-offs to customers.    > D >> I don't like Compaq, but don't pretend that your company is above >> reproach. >>   >  >Its relative. > - >On this newsgroup we have had the following  
 >bullshit. >  >Galaxies.   > / >Spiralog. It was going to ensure that OpenVMS  + >trashed all other OS's on OLTP throughput.  > . >WildFire performance. It was going to exceed  >all the competition.  > 7 >WildFire availability. it was going to be out 2 years   >before it actually arived.  > + >Alpha commitment and longevity (25 years).  > * >Various projected availability statements >for Alpha CPUs all wrong.  A Blah, blah, blah.  Are you saying that Sun always meets all their D goals?  If not, then this is a primo example of your use of FUD.  If@ so, then Sun's engineers aren't stretching the technology to theD extent they might.  Show me anyone who always meets their goals, and I'll show you an underacheiver.t   >o% >NT on Alpha support (it evaporated).  >c- >NT on Alpha performance comparisons with NT i3 >on Intel, there was never a case based on standardl >benchmarks. >o  E Both of these can be easily explained by the complete lack of supportnC from Microsoft.  Imho, MS did not live up to their end of the deal.c< In the end, unfortunately, it was a money pit (again, imho).  2 >Various OpenVMS vs UNIX cluster comparisons which0 >have only demonstrated that the posters didn't # >know anything about UNIX clusters.l >   B Oh yeah, ignoring *completely* the fact that you consistently makeD statements about the details of VMSclusters that you have no working> knowledge or experience with.  Ha ha ha ha ha.  What a maroon.  * >Various statements of undying support for+ >OpenVMS apparently from key ISV's followedr- >by the ISV in question dropping or partiallyp  >dropping OpenVMS as a platform.  A You're right.  Compaq should be held responsible for the businessiA decisions of other vendors.  Sheesh.  At least use something even  close to relevant.   >.6 >Given flow of BS coming from the Compaq camp I think 8 >that getting people to sign NDA's on ecache issues and ? >having to patch the UltraIII systems is a pretty undewhelming v8 >argument for any kind of parity between Compaq and Sun.  ? Of course you would think this.  With your pathological view of 8 ethical behavior, nobody expects you to think otherwise.  ? Of course, if Sun had even tried to come close to the amount oftF products and services that Digital, and now Compaq, has, then we'd see an entirely different story.   ------------------------------  % Date: Mon, 30 Jul 2001 12:34:55 -0400t5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> 1 Subject: Re: Alpha:  an invitation to communicate 1 Message-ID: <B1g97.335$Yx2.7318@news.cpqcorp.net>   C Brig Campbell wrote in message <9jslh5$cq6$1@mail.pl.unisys.com>...s > A >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in messagea, >news:oMj87.274$Yx2.3846@news.cpqcorp.net...I >> The stock market is pure black magic, legalized gambling.  It may once  >havee> >> had some rational basis, but that has long since been lost. >aC >It is not black magic, it's the foundation for capitalism.  It thep	 mechinism J >for which capital flows from old to new.  At times markets are irrational0 >but that never lasts, they are self correcting. >l     Horse pucky.  K Capitalism existed before the stock market, and will exist after we wise upp and fix this broken system.t  I Markets are irrational because there is nothing rational about them.  ThecJ only universal rules that drive the markets are greed and fear.  There areK no fundamentals that rule the price of an individual stock *or* a basket oflB stocks (like the S&P or DJIA) - it's all speculation.  Worse - theC speculation is by people dumber than *me* - and I'm not that smart.2   >eJ >The reason the many "new" companies don't provide dividends is that money isH >reinvested in the business, it's used to fund growth.  Things like R&D,J >expanding operations, etc.  If you're a utilitity, its a different story,K >rather than pile up cash (except in California) you pay out the profits toe >the shareholders. >d    L That was the rationale as I heard it 20 years ago, but neither do many "old"G companies.  The stock market is no longer about investing in a company,eJ sharing in it's profits, while sheltering yourself from it's losses.  It'sL all about speculation on the price of a stock, which may or may not have ANYJ connection to it's fundamentals.   Perhaps this is no different that, say,L 1929... except that in 1929 the fuel driving the market wasn't pension plansI and 401Ks invested in mutual funds and stocks, each expecting a constant,a+ and ever rising return on their investment.m   ------------------------------  % Date: Mon, 30 Jul 2001 12:43:45 -0400f- From: JF Mezei <jfmezei.spamnot@videotron.ca> 1 Subject: Re: Alpha:  an invitation to communicateo, Message-ID: <3B658EBD.CFF83228@videotron.ca>   jlsue wrote:G > THIS is exactly what anyone would call FUD.  There is no bug, and all F > architectural performance characteristics have been fully disclosed.  E I think that VMS systems already have an image of not having the best-M performance, but having great reliability and built historically on top notch2D hardware where performance was jeoperdized in favour of reliability.  N I personally was never impressed with Wildfire. So if its performance is belowK expectation, tough luck. If VMS is to grow, it must attack new markets, andnK those markets have no use for Wildfires, they have uses for DS10 and DS20s.l  N Sun does have an image problem with quality/reliability, although nowhere nearN as bad as Microsoft/Intel. Nobody really expects a wintel box to be built withJ reliability in mind and no company would want to compromise performance toZ acheive better reliability because that would ruin system sales at the wintel marketplace.  K -Does one have confidence that hardware designed/built by the compaq wintel P folks will provide the degree of reliability that VMS customers expect/require ?  > -Does one have confidence that Compaq really cares about VMS ?  M At one point, the minor weaknesses in Sun are probably compensated greatly by H the fact that Sun is very agressive with marketing and has the clout and> installed base to attract any and all enterprise applications.  H What good is a higher quality platform when you can't trust its vendor ?   ------------------------------  % Date: Mon, 30 Jul 2001 17:54:18 +0100l0 From: andrew harrison <andrew.nospam@uk.sun.com>1 Subject: Re: Alpha:  an invitation to communicateo* Message-ID: <3B65913A.B06CAE83@uk.sun.com>   jlsue wrote: > 5 > On Mon, 30 Jul 2001 14:08:48 +0100, andrew harrison.# > <andrew.nospam@uk.sun.com> wrote:6 >  > > 5 > >Really, the WildFire has a system design bug whichu5 > >means that local memory latency is a whopping 300+ 7 > >ns and remote is a even more whopping 900+ ns. Theret6 > >is no patch for this and the only work around is to6 > >use things like Oracle in a way that most customers3 > >would not contemplate. Customers using DBMS like % > >Sybase cannot use this capability.  > G > THIS is exactly what anyone would call FUD.  There is no bug, and allhF > architectural performance characteristics have been fully disclosed. >   6 Lets see. The poster I was responding to claimed that 6 the cachegate issues were the result of bad design, if3 that is true then the terrible local/remote memory s9 latency issues on WildFire are also in the same category.h    H > How you can compare this to a *real* bug that causes systems to crash,H > corrupt data, etc., is beyond me.  It only shows your complete lack of	 > ethics.r >   5 When are you going to get a factually correct postingB8 out of the door (not today). Repeat after me the ecache % issues did not cause data corruption.I    D > And they provided benchmarks for the performance that everyone has > access to for comparison.h >   = Rubbish, they claimed that the WildFire was the fastest UNIX n< server on the market, they used a series of benchmarks that C either no one else had run on anything current, if at all, or they .8 studiously forgot to include results that were actually 9 better than theirs. For example they claimed performance 57 leadership for SAP while forgetting that Fujitsu had a t5 better result on the SAP benchmark they had run. They 7 also forgot to mention that very few SAP customers run i6 2 tier configs (what they benchmarked) most prefering = to run 3 tier something they didn't bother/dare to benchmark.i  : In addition their white papers on WildFire memory latency 6 made a comparison between WildFire memory latency and 3 E10K memory latency, sadly they had simply made up m3 the E10K memory latency number and in doing so madee4 the WildFire memory subsystem look much better than  it actually was.  6 How are you doing on ethics so far, ommision, made up 2 numbers do they count as ethically sound practice.    C > If you think it actually matters whether they've used OPS or not,lD > you're kidding yourself (wishful thinking on your part).  BusinessF > managers say "I have $x to spend, what performance can you give me?"H > They don't dwell on esoteric issues like whether OPS is implemented orG > not.  As someone else said before, any DBA worth their salt will havebB > very little problems with OPS.  I know several, and we've always? > worked well together on VMScluster solutions - and these wereeC > Unix-based DBAs, no VMS experience prior to our working together.s >   5 Sadly for you the naive may well not worry about OPS  4 but will when they find out they have been stiffed, 3 while on the flip side the more technically astute p2 do worry and exclude Compaq because of it as they 8 did with Sequent who used the same tuning trick. Either  way its a loss.d   > >h7 > >Despite this Compaq are still selling GS160/320's as58 > >fit for purpose OLTP systems when in fact they arn't. > G > Blah, blah, blah.  THIS is only *your* personal opinion.  The problemeD > is, and the reason you lack so much credibility, is that you can'tG > seperate your opinions from actual facts.  The actual fact shows thataG > we have many, many happy customers who've implemented just that whichg > you show so much scorn.m >   0 No it isn't its A backed up by the current crop 0 of DBMS benchmark results and B even people like1 Rob Young have had to suggest waiting for Marvel  - as a solution to the my GS140 is faster than  + my GS320 post because of the NUMA penalty. a     > > 6 > >The Sun prefetch issue on the otherhand has a patch3 > >that does fix the problem and also has a roadmapc7 > >to permanently fix the problem (UltraIII+) this willt3 > >be available for all current systems rather then 7 > >the WildFire fix which requires a totally new system 8 > >and on the WildFire side the performance differential > >looks to be arround 30%.s > C > FUD.  There is nothing to fix on the GS systems.  The performanceeG > characteristics are known, as well as the trade-offs.  They work veryaE > well within the documented trade-offs.  At least Compaq is actuallyy7 > truthful in disclosing those trade-offs to customers.r >   3 Really you are mistaken again, Compaq have made no r1 such disclosure, in fact they have withdrawn the i6 TPC-C result that illustrates the performance penalty 3 to be paid. far from being honest about the penaltyo2 Compaq have done their best to hide it from sight.  , > >Various statements of undying support for- > >OpenVMS apparently from key ISV's followedw/ > >by the ISV in question dropping or partiallye" > >dropping OpenVMS as a platform. > C > You're right.  Compaq should be held responsible for the businesseC > decisions of other vendors.  Sheesh.  At least use something eveni > close to relevant. >   > You misunderstand again, the information relating to supposed E ISV enthusiasm for OpenVMS either came from Compaq employees or from .< sources who claimed to have it second hand from Compaq. The 8 ISV's in both of the major cases I can think of were not> involved at all in the dissemination of incorrect information.   Regardsa Andrew Harrisonn Enterprise IT Architect    ------------------------------  % Date: Mon, 30 Jul 2001 13:16:09 -0400e5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>o1 Subject: Re: Alpha:  an invitation to communicate 1 Message-ID: <bEg97.342$Yx2.7394@news.cpqcorp.net>   = JF Mezei wrote in message <3B658EBD.CFF83228@videotron.ca>...  >e >cL >-Does one have confidence that hardware designed/built by the compaq wintel@ >folks will provide the degree of reliability that VMS customers expect/require ? >e    K Yes.  There is nothing inherently unreliable about even most of todays IA32.K systems, especially in the server systems.  You confuse hardware reliabiltylH with the reliability of the operating system, and more importantly - theI applications running on poorly designed interfaces.  When you couple thatqJ with unreliable peripherals tacked on the side - you have the makings of a
 real problem.-  H Many Alpha systems have had very little difference in many respects fromE off-the-shelf PC servers - except perhaps in trailing them in featureiL availability.  The only main difference is the CPU itself.  So why would you$ expect the *CPU* to be "unreliable"?  G The people who had been designing Alpha servers, will now join with andu build IA64 servers.   ? >-Does one have confidence that Compaq really cares about VMS ?  >e  J Yes.  Frankly, after reading all of your stuff the last few weeks, I thinkJ considerably more than you do.  You have already written VMS off.  WrittenF Compaq off.  And are generally just pissed off.  As in any "death" youH *should* be allowed to go through all the grieving processes - including0 being pissed off - but let's get on with things.  H I'm not thrilled about the utilmate passing of Alpha.  Heck, I've alwaysJ argued that it would never happen, and that moving to another architectureJ would be painful to customers.  But here we are.  I'm thrilled that VMS isK being ported.  Alpha was a great architecture (well, buy me a beer sometimepI and I'll complain a *lot* about how hard it was to debug the EV6), but in I the end while it "saved" VMS from the extinction of the VAX - it's just aeI CPU - it gave us a great few years where we were competetive once again -iK but it's just a CPU.  I would have been happier if they had figured out howaI to build *really* fast VAXes (like they figured out how to build *really*p fast X86's).  G So now we'll move to hardware that will be both competetive, as well as K being "industry standard".  So far there has been NO indication that anyonesL isn't serious about this.  So far there has been NO indication that we can'tH do it.  We've given customers a pretty long heads up time before we stopJ building leading edge Alphas, and transition to leading edge IA64s (and weI DO believe they will be competetive, leading edge systems - and we're notc alone).i  K >At one point, the minor weaknesses in Sun are probably compensated greatlyr byI >the fact that Sun is very agressive with marketing and has the clout ande? >installed base to attract any and all enterprise applications.e >wI >What good is a higher quality platform when you can't trust its vendor ?   K I agree you shouldn't trust Sun with an enterprise system.  They don't knowT how to build a reliable system..   ------------------------------  % Date: Mon, 30 Jul 2001 13:21:40 -0400 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>t1 Subject: Re: Alpha:  an invitation to communicates1 Message-ID: <lJg97.343$Yx2.7257@news.cpqcorp.net>h  B andrew harrison wrote in message <3B65913A.B06CAE83@uk.sun.com>...
 >jlsue wrote:T >>6 >> On Mon, 30 Jul 2001 14:08:48 +0100, andrew harrison$ >> <andrew.nospam@uk.sun.com> wrote: >> >> >6 >> >Really, the WildFire has a system design bug which6 >> >means that local memory latency is a whopping 300+8 >> >ns and remote is a even more whopping 900+ ns. There7 >> >is no patch for this and the only work around is to 7 >> >use things like Oracle in a way that most customersG4 >> >would not contemplate. Customers using DBMS like& >> >Sybase cannot use this capability. >>H >> THIS is exactly what anyone would call FUD.  There is no bug, and allG >> architectural performance characteristics have been fully disclosed.l >> >p6 >Lets see. The poster I was responding to claimed that7 >the cachegate issues were the result of bad design, ifw3 >that is true then the terrible local/remote memory.: >latency issues on WildFire are also in the same category. >h    H Andrew, it's post like this which makes people believe that your head is# someplace where oxygen dosn't flow.   K It is one thing to have a performance characteristic, and another to have alL true bug which your company tried bandaids and coverups on, rather than just* admitting the problem and making it right.  8 I'll skip the rest of your oft-repeated benchmark tripe.   ------------------------------    Date: 30 Jul 2001 19:53:52 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>t1 Subject: Re: Alpha:  an invitation to communicateeH Message-ID: <y4g0becngv.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  7 "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:p  N [note - I agree that IA32-based systems can be reliable etc., it's the current8 "industry-standard" software that makes them unreliable]  I > So now we'll move to hardware that will be both competetive, as well ase > being "industry standard".  G For me, that is the main point of the discussion. Currently, IA32-basedOF systems are both competitive and industry standard. IA64 are basicallyM incompatible (still no news on the performance of IA32 emulation on Itanium).nM Intel has plans in place, and given AMD they better have them, to continue tosJ push IA32 in line with VLSI improvements for the next 5 years or so. WhereN will IA64 get that additional push, over and above Moore's law, to be a worthyN sucessor to the Pentium 4? And AMD is going to muddle the picture even further with x86-64.  K If Compaq has information, as I noted before, that HP worked a miracle witheK McKinley's performance, they should at least give an indication that is theiK case. And even then the question is whether the systems that result will becH cheaper, to Compaq, than an EV79- or EV8-based system; I use system hereL because it appear that in the EV7 time frame, no IA64 chip will have the EV74 and EV8 features with regard to systems integration.   	Jan   ------------------------------  % Date: Mon, 30 Jul 2001 12:39:16 +0200e2 From: martin@radiogaga.harz.de (Martin Vorlaender)" Subject: ANNOUNCE: MicroEMACS 4.00; Message-ID: <3b653954.524144494f47414741@radiogaga.harz.de>q  B Changes against the version I mentioned some two weeks ago include? - fixed a nasty bug that trashed the screen when right-shiftingF"   highlighted text off the screen,) - the ability to use it as a mail editor,iD - a CMD file to find source files from compiling error listings, and; - some changes to DESCRIP.MMS (in the source distribution).y  / Please find updated versions at the same place:.  7 Anonymous FTP to ftp://ftp.pdv-systeme.de/vms/ and thenw& UE400DEV-VMS.ZIP   source distribution> UE400VAX.ZIP       binaries (SMG version) and supporting files(                      for OpenVMS/VAX 6.2> UE400AXP.ZIP       binaries (SMG version) and supporting files*                      for OpenVMS/Alpha 6.2  I It now works again as described in the doc's VMS appendix (i.e. to use astG a mail editor, move MESHR.EXE to SYS$SHARE: or define the logical MESHRi to point to MESHR.EXE).   G I've included ME.C and ME.EXE, respectively, from the 3.11 version, buttF couldn't yet get it to work (the functionality still is there; it justE crashes reliably :-(   BTW: anyone have a idea how to debug a spawned H image?). Fortunately, it's not really needed, as MESHR.EXE works without> it - it's just the suspend-emacs functionality that's missing.   Enjoy,   Martin  C P.S.: Off for YAPC::Europe (european Perl conference) until Sunday.  -- TF                           | Martin Vorlaender  |  VMS & WNT programmer3  Cetero censeo            | work: mv@pdv-systeme.degF  Redmondem esse delendam. |   http://www.pdv-systeme.de/users/martinv/:                           | home: martin@radiogaga.harz.de   ------------------------------  + Date: Mon, 30 Jul 2001 07:21:53 -0500 (CDT)w& From: Drew Shelton <drew@sematech.org>. Subject: Re: Change account password using web- Message-ID: <01K6JAFO035000ATXF@SEMATECH.Org>c   Tom,  I >We have Alpha OpenVMS 7.2-1 running Multinet 4.3 and the OSU web server. L >Does anyone have a secure way to change an OpenVMS account password using aI >web page that is on another server?  We need a way to have the other web M >server send a packet of account information so the OpenVMS system can changen >the password.  I I wrote an application to allow our helpdesk personnel to reset forgottenuF passwords.  Our primary web server is on NT, but it has a link to thisL application that runs under Purveyor on VMS.  The page is password-protectedE and is verified with an .EXE to prevent source viewing.  The helpdeskBF staffer is presented with a scrolling list of VMS accounts (with a fewF choice ones removed).  The application creates a new password with SETL PASSWORD/GENERATE and sets it using an image installed with privileges.  TheJ new password is emailed to the user's PC.  The helpdesk staffer never seesH the new password.  The person on the other end must have the password toL his/her NT account to see the email, making it harder to impersonate someoneL over the phone to get a password.  It's not 100% secure (emailing plain-textK passwords, for instance), but it does work.  I developed it on Purveyor andd? have migrated it to Apache.  Let me know if you want more info.a   Drew  L ============================================================================6 Drew Shelton                         drew@sematech.org9 VMS Systems Manager                  office: 512-356-7575f9 Sematech                             fax:    512-356-7600u 2706 Montopolis DrivewK Austin, TX 78741-6499                I speak for myself only, not Sematech.bB     "OpenVMS is today what Microsoft wants Windows NT v8.0 to be!"I                                                         - Compaq, 9/22/98 L ============================================================================   ------------------------------  % Date: Mon, 30 Jul 2001 11:14:41 -0500e' From: Greg Pfister <pfister@us.ibm.com>e! Subject: Re: checking some myths.a* Message-ID: <3B6587F1.96A32027@us.ibm.com>   Anne & Lynn Wheeler wrote: > 2 > "Stephen Fuld" <s.fuld@worldnet.att.net> writes: > >,P > > Since there have been lots of answers to number 1 and to you last paragraph,P > > but none to number 2, I'll take a shot at it.  I am far from an expert here,A > > but AFAIK you nailed one of the reasons but there are others.0 > >r; > > Some people run VM so thy can run lots of CMS users ...  > >aH > > Some people run VM so they can take advantage of modern hardware ... > >tM > > Many independent software vendors run it to allow them to support severalr7 > > versions of several different operating systems ...o >  ...t  A An important additional case was that people inside IBM ran VM soa7 they could more easily bring up the next version of the A "strategic" operating system - e.g., MVS (now zOS). Possibly moree@ than anything else, this ensured that VM would always be around.  ? An amusing related story: A friend of mine, who used to work onoA VM in the mid-70s, particularly the Virtual Memory part (duelling = acronyms here), was having trouble getting system time on news@ machines to bring up the latest version. The MVS (or whatever it; was then) folks were hogging all available machines. So ones= night, he did a midnight anti-repair and sabotaged the systemy< console. MVS wouldn't come up without it. VM didn't care; it? could use anything able to do text I/O. Result: he got to put ap@ version of VM on the system, as a "favor" so the MVS folks could? continue work, using VM which provided a virtual console -- ando@ he could use that hardware too, to bring up the next VM release.  = Related -- Once upon a time that same friend told me that youh@ actually have to be able to do three levels of virtualization of@ memory to be general -- the top-level VM system just doing it is@ not enough; you have to be able to nest a VM system virtualizingA what the top-level system is also virtualizing, and a third levelt: below that. I never did understand why the third level was> necessary, but this guy was very, very good and knew that code% intimately, so he was probably right.m  > (I knew that if I wanted long enough Lynn & Anne would fill in8 lots of the other answers to the original question. :-))   Greg Pfister   ------------------------------   Date: 30 Jul 2001 17:18:18 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)! Subject: Re: checking some myths.u0 Message-ID: <9k44sq$n4i$1@pegasus.csx.cam.ac.uk>  * In article <3B6587F1.96A32027@us.ibm.com>,) Greg Pfister <pfister@us.ibm.com> writes:m |> n@ |> Related -- Once upon a time that same friend told me that youC |> actually have to be able to do three levels of virtualization oflC |> memory to be general -- the top-level VM system just doing it issC |> not enough; you have to be able to nest a VM system virtualizingeD |> what the top-level system is also virtualizing, and a third level= |> below that. I never did understand why the third level wasrA |> necessary, but this guy was very, very good and knew that code ( |> intimately, so he was probably right.  @ It's much the same reason that you have to compile a new version> of a compiler with itself three times before you can check it!  > In order to be sure that a VM will run at any level, it has toB be able to provide a fully-functional virtual machine while itself% using only virtualised functionality.m  A In actual fact, there are bugs that can creep by the 3-level test @ for both compilers and VMs, but they are mind-bogglingly obscureA by comparison with the ones that adding the third level picks up.h     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 334679c   ------------------------------  # Date: Mon, 30 Jul 2001 17:47:11 GMTo+ From: Anne & Lynn Wheeler <lynn@garlic.com>s! Subject: Re: checking some myths.t) Message-ID: <un15mwc0y.fsf@earthlink.net>   ) Greg Pfister <pfister@us.ibm.com> writes:  > ? > Related -- Once upon a time that same friend told me that youmB > actually have to be able to do three levels of virtualization ofB > memory to be general -- the top-level VM system just doing it isB > not enough; you have to be able to nest a VM system virtualizingC > what the top-level system is also virtualizing, and a third level < > below that. I never did understand why the third level was@ > necessary, but this guy was very, very good and knew that code' > intimately, so he was probably right.3   multi-level references% http://www.garlic.com/~lynn/99.html#7   D three levels of CP/67 under which ran CMS. standard cp/67 running onA the real hardware in an "open" environment (university students &C0 others on effectively a public access machine),   D then a modified CP/67 running in "360m67" mode ... but providing 370A virtual machines (primarily relocation tables different structure C between 360m67 & 370), and then a further modified CP/67 running inaE "370" mode ... which then provided 370 virtual machines (running CMS)h ... akao        real 360m67 -      cp/67.         standard 360 & 360/67 virtual machines7 -         CP/67 modified to provide 370 virtual machineg$             370 "R" virtual machines; -             CP/67 modified to run on 370 w/virtual memoryo(                 370 "R" virtual machines -                 CMS   C This was about two years before virtual memory was available on 370tF (and possibly a year before 370 engineering models with virtual memory; were available). Issue was to try and obscure the fact that D development for unannounced (or even unavailable) products was going on.r  ? while there was quite a bit of use of CP/67 & VM/370 inside thenD corporation for the testing of new operating systems ... in terms of= CPU cycles, probably the biggest use was straight interactive @ computing (edits, compiles, non-operating system testing, email,C documents, GML, etc). Part of this give rise to the largest networke3 in the world (larger than arpanet until around '85)F    G '83 ... had nearly 1000 mainframe nodes at point when arpanet was abouto 255 total nodes. random refs:e" http://www.garlic.com/~99.html#112  C there was another way of getting machine time. the disk engineeringeB labs were doing all their development in a stand-alone environmentD (MVS with a single "test-cell" MTBF was on the order of 15 minutes).F I rewrote i/o supervisor so it wouldn't fail & they could operate 6-12E test-cells concurrently. The priority list on processors ... was thaty@ typicall as soon as the CPU/processors engineers had the 2nd oneE running; it was made available to the disk engineering labs for their  testing.   random refs:( http://www.garlic.com/~lynn/2000d.html#0. http://www.garlic.com/~lynn/subtopic.html#disk   -- aH Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/    ------------------------------    Date: 30 Jul 2001 13:43:33 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>u/ Subject: Re: Compaq FUD and lack of informationtH Message-ID: <y44rruabh6.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  - young_r@encompasserve.org (Rob Young) writes:s  ' > > What is so difficult about it all ?y	 > 	Legal.SI > > Why should *we* be begging the supplier for information ?  Any of the"L > > competition would be bending over backwards to make public reassurances.? > 	This presumes that the agreement is a simple one.  From whato> > 	I am guessing (no secret knowledge here) is that it isn't a > 	simple one.  N So what? If you're moving that much money, have a group of two people from oneK side and two from the other, possibly with an outside expert as arbitrator,aJ and have them sign off on any informational material as required. The onlyL reason not to inform is that you want to keep things secret. And secrecy has never inspired confidence.   	Jan   ------------------------------  # Date: Mon, 30 Jul 2001 14:31:30 GMTe  From: jlsue <jlsuexxxz@home.com>/ Subject: Re: Compaq FUD and lack of informationi8 Message-ID: <b5ramt8u7gnoj2ukgd6l1df0dvskhsnt6m@4ax.com>  . On 30 Jul 2001 13:43:33 +0200, Jan Vorbrueggen8 <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:  . >young_r@encompasserve.org (Rob Young) writes: >e( >> > What is so difficult about it all ?
 >> 	Legal.J >> > Why should *we* be begging the supplier for information ?  Any of theM >> > competition would be bending over backwards to make public reassurances.e@ >> 	This presumes that the agreement is a simple one.  From what? >> 	I am guessing (no secret knowledge here) is that it isn't ac >> 	simple one.  > O >So what? If you're moving that much money, have a group of two people from onecL >side and two from the other, possibly with an outside expert as arbitrator,K >and have them sign off on any informational material as required. The onlyiM >reason not to inform is that you want to keep things secret. And secrecy has' >never inspired confidence.e >s  F Well, there may be some reasons that they can't make statements yet.    7 Isn't this kind of deal part of the SEC's jurisdiction? > If so, wouldn't it also be subject to the 90 day quiet period?  : I'm just asking, not asserting anything.  I have not idea.   ------------------------------    Date: 30 Jul 2001 16:35:23 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>0/ Subject: Re: Compaq FUD and lack of informationsH Message-ID: <y4lml6jxhw.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  " jlsue <jlsuexxxz@home.com> writes:  9 > Isn't this kind of deal part of the SEC's jurisdiction? @ > If so, wouldn't it also be subject to the 90 day quiet period?  L This is a sale of some Compaq "property", not a merger or an acquisition. I 0 don't think the SEC or quiet periods apply here.   	Jan   ------------------------------  % Date: Mon, 30 Jul 2001 12:32:10 +0200d+ From: Maarten van Tilburg <mtilburg@wxs.nl>i# Subject: Re: Compaq's Q2 financialsh& Message-ID: <3B6537AA.3ED47D80@wxs.nl>   mulp wrote:e > / > "jlsue" <jlsuexxxz@home.com> wrote in messages4 > news:8nn1mtk4htsbuldqrjfk29bnb7tvb911at@4ax.com...? > > Just FYI:  We do a *lot* of SAN implementations in strictlyrD > > "industry-standard" server environments.  When folks have dozensC > > (sometimes hundreds) of Windows servers, they like SANs to helpd > > consolidate the storage. > I > Find some former coworkers who work for some of the companies that sellyK > software and hardware with storage and ask them what they think of CompaqrN > storage.  I'm quite certain that the first thing they'll mention is how over > priced it is.-  & Not hearsay, but from own experience :  F Bids (very recent) to implement an FC-SWITCH based storage solution (2A sites, min 2 TB mirrored) showed 2-5 times *higher* costs for thee- competitors (who shall remain nameless here).o' Why do you think COMPAQ is overprized ?s   ------------------------------  # Date: Mon, 30 Jul 2001 15:09:43 GMT-  From: jlsue <jlsuexxxz@home.com># Subject: Re: Compaq's Q2 financialsd8 Message-ID: <jatamt4sk813brsuhtctjjo4e67fhdtbtm@4ax.com>  ( On Sat, 28 Jul 2001 10:04:09 GMT, "mulp"( <michaelpettengill@earthlink.net> wrote:  . >"jlsue" <jlsuexxxz@home.com> wrote in message3 >news:8nn1mtk4htsbuldqrjfk29bnb7tvb911at@4ax.com...i> >> Just FYI:  We do a *lot* of SAN implementations in strictlyC >> "industry-standard" server environments.  When folks have dozens B >> (sometimes hundreds) of Windows servers, they like SANs to help >> consolidate the storage.V > H >Find some former coworkers who work for some of the companies that sellJ >software and hardware with storage and ask them what they think of CompaqM >storage.  I'm quite certain that the first thing they'll mention is how overm >priced it is. >,K >At least EMC recognized that they were too expensive and bought DG for thehL >Clarion Fiber Channel storage business.  Don't know what Compaq is going to >do to become more competitive.t >s  C My experience with customers who are also running EMC is that theiruE "low" price is only an initial perception.  Once the reality sets in,hD they are in for a surprise.  If your have a stable disk environment,E EMC can potentially remain somewhat inexpensive.  I haven't worked in1, that kind of environment in all my 16 years.  C Thus, if you have changing storage requirements, be sure to ask how A much those changes cost over the long term.  Then compare that to D Compaq SAN costs.  My experience tells me that you'll like Compaq in the end.   ------------------------------  % Date: Mon, 30 Jul 2001 16:31:47 +0100 % From: Alan Greig <a.greig@virgin.net>i# Subject: Re: Compaq's Q2 financialsr8 Message-ID: <okuamtod9u7pnjipkmrqjoipoh54u30mpg@4ax.com>  C On Mon, 30 Jul 2001 15:09:43 GMT, jlsue <jlsuexxxz@home.com> wrote:    >a >pD >Thus, if you have changing storage requirements, be sure to ask howB >much those changes cost over the long term.  Then compare that toE >Compaq SAN costs.  My experience tells me that you'll like Compaq in6	 >the end.P  D Storageworks products are much more price competitive than they usedE to be. On VAX we switched to MTI about six years ago but went back tocB Storageworks when upgrading to Alpha les than two years ago,  OnlyC serious illness of one member of staff and the departure of another'B delayed things by a few month making the HSZ80 current and not theB HSZ70. Were it not for this delay I would now be sitting trying toC explain why I needed an emergency budget allocation of maybe around E 50,000 dollars to put in a dual HSG80 fibre SAN. I have no confidencerF in the HSZ80 support lasting much longer so I'll probably have to planF to budget an upgrade for CY2003 at the latest. All this in a period of expenditure lock-down.  @ So my experience tells me that you won't like Conpaq in the end.C Perhaps if Conpaq listened to its customers instead of telling themo= that they like Conpaq (and even just making things up such as/A "customer response has been unbelievably positive") you might get-
 somewhere.  @ I am sure you will now tell me why Conpaq's current Storageworks$ reburials are good for the customer. -- Alan   ------------------------------    Date: 30 Jul 2001 07:51:45 -0700* From: vmendham@altavista.com (Vic Mendham)2 Subject: Connections to VAX and Dec legacy systems< Message-ID: <8b51ed8.0107300651.758dc1c7@posting.google.com>  D We have some old networking (serial type connection) equipment whichD allows our end users to connect to our VAXes and old Tops20 systems.? We use a StarMaster which allows us multiple connections to ourp systems.C Has anyone ever used a Gandolf StarMaster and have any simple loginrE and port information. We just had someone quit and all knowledge wentr
 with them.D Basically user dialin via modem and enter an alias to connect to theD system/application of their choice. I need to login, and investigate/ hung ports and create new connections/ aliases.w  * Please reply to victor.mendham@emergis.com   ------------------------------   Date: 30 Jul 2001 16:04:00 GMT' From: Thomas Dzubin <dzubint@vcn.bc.ca> 6 Subject: Re: Connections to VAX and Dec legacy systems. Message-ID: <9k40hg$jma$1@sylvester.vcn.bc.ca>  4 Holy cow!  A Gandalf StarMaster AND a TOPS20 system! In active service!  wow!  3 I'm crossposting this one on alt.folklore.computers   D We got rid of our StarMaster last year when our port logging & statsD program wouldn't do Y2K.  (Unfortunately, our StarMaster person also: left many many years ago, so we have no expertise on that)  G ...but maybe someone else in alt.folklore.computers can help you out...=  + Vic Mendham <vmendham@altavista.com> wrote: F > We have some old networking (serial type connection) equipment whichF > allows our end users to connect to our VAXes and old Tops20 systems.A > We use a StarMaster which allows us multiple connections to ourf
 > systems.E > Has anyone ever used a Gandolf StarMaster and have any simple loginNG > and port information. We just had someone quit and all knowledge went  > with them.F > Basically user dialin via modem and enter an alias to connect to theF > system/application of their choice. I need to login, and investigate1 > hung ports and create new connections/ aliases.m  , > Please reply to victor.mendham@emergis.com   -- 6L ----------------------------------------------------------------------------
 Thomas Dzubine' Vancouver, Saskatoon, or Calgary CANADA    ------------------------------    Date: 30 Jul 2001 09:26:29 -07006 From: andrew.rycroft@intrinsitech.com (Andrew Rycroft)+ Subject: DEC/EDI v3.2B Contrl message queryd< Message-ID: <58ba0101.0107300826.2aba24e@posting.google.com>   Hi,   F We have just upgraded to DEC/EDI v3.2B. This solved a lot of problems,D but now we find that when the UN/EDIFACT CONTRL message is generated7 for a trading partner profile with the field FunctionaleC Acknowledgement set to DOC it seems to work correctly, but the data.E element 0062 ( Message reference number ) in the UCM segment is null.a   Any suggestions appreciated.   Thanks Andrew   ------------------------------  % Date: Mon, 30 Jul 2001 13:17:07 -0400e  From: norm.raphael@jamesbury.com/ Subject: Re: DEC/EDI v3.2B Contrl message queryl4 Message-ID: <C2256A99.005EBCED.00@jklh21.valmet.com>  ' R U under s/w support for this product?e        9 andrew.rycroft@intrinsitech.com on 07/30/2001 12:26:29 PMs  1 Please respond to andrew.rycroft@intrinsitech.coms   To:   Info-VAX@mvb.saic.coma cc:n, Subject:  DEC/EDI v3.2B Contrl message query         Hi,,  F We have just upgraded to DEC/EDI v3.2B. This solved a lot of problems,D but now we find that when the UN/EDIFACT CONTRL message is generated7 for a trading partner profile with the field FunctionalnC Acknowledgement set to DOC it seems to work correctly, but the datagE element 0062 ( Message reference number ) in the UCM segment is null.e   Any suggestions appreciated.   Thanks Andrew   ------------------------------  % Date: Mon, 30 Jul 2001 16:59:31 +0200 , From: Theo Jakobus <Theo.Jakobus@iaf.fhg.de>5 Subject: Errors in executing the upgrade 7.2-1 to 7.3i) Message-ID: <3B657653.5000108@iaf.fhg.de>o  I I started to upgrade my PWS500au from 7.2-1 (with all patches installed) g to 7.3 and got two errors:   1. STARTLET.OLBn6 During the upgrade at 60% progress I got the messages:  %PCSI-E-WRITEERR, error writing 3 DISK$21_SYSDISK:[VMS$COMMON.][SYSLIB]STARTLET.OLB;6k& -LIBR-E-DUPKEY, duplicate key in indexG I restored 7.2-1, checked STARLET.OLB;5 and started again the upgrade, -. after running in the same problem I proceeded.   2. SMI$SHR.EXE5 Booting the upgraded system showed the error message:c8 %SYSTEM-I-BOOTUPGRADE, Coordinated Startup not performed/ %DCL-W-ACTIMAGE, error activating image SMI$SHR<& -CLI-E-IMAGEFNF, image file not found 0 IAF021$DKA0:[SYS0.SYSCOMMON.][SYSLIB]SMI$SHR.EXEI I restored 7.2-1 and got on July 19th the patch: VMS721_RENAME_OLD-V0100 tG which solved this error. I started the upgrade again and still had the a first error.L At this time I've 7.3 running but I'm suspicious of my STARTLET.OLB library.   Regards, -- l  ; ***********************************************************a; *                                                         *h; *  Theo Jakobus                                           *d; *  Fraunhofer-Institut fuer Angewandte Festkoerperphysik  *.; *  Tullastr. 72                                           *v; *  D-79108 Freiburg                                       *c; *  Germany                                                *e; *  Phone:   +49-(0)761-5159-325                           *a; *  FAX :    +49-(0)761-5159-200                           * ; *  e-mail:  Theo.Jakobus@iaf.fhg.de                       *t; *  http://www.iaf.fhg.de                                  *y; *                                                         *e; ***********************************************************a   ------------------------------  % Date: Mon, 30 Jul 2001 13:42:47 -04002, From: Steve Lionel <Steve.Lionel@compaq.com>9 Subject: Re: Errors in executing the upgrade 7.2-1 to 7.3-8 Message-ID: <o07bmt83tuftdnm2ms9hv3lgiv6n91m36h@4ax.com>  0 On Mon, 30 Jul 2001 16:59:31 +0200, Theo Jakobus  <Theo.Jakobus@iaf.fhg.de> wrote:  J >I started to upgrade my PWS500au from 7.2-1 (with all patches installed)  >to 7.3 and got two errors:  >n >1. STARTLET.OLB7 >During the upgrade at 60% progress I got the messages:o! >%PCSI-E-WRITEERR, error writing  4 >DISK$21_SYSDISK:[VMS$COMMON.][SYSLIB]STARTLET.OLB;6' >-LIBR-E-DUPKEY, duplicate key in indexeH >I restored 7.2-1, checked STARLET.OLB;5 and started again the upgrade, / >after running in the same problem I proceeded.    Try this:  DownloadwL ftp://ftp.compaq.com/pub/products/fortran/OpenVMS/CFAV-FORRTL-V0704-4.zipexe   RUN it to unpack and then:  # $ PRODUCT INSTALL FORRTL /SOURCE=[]e  > Then try your VMS upgrade again. This may help the STARLET.OLB problem, but not SMI$SHR.EXE    - Steve Lionel (mailto:Steve.Lionel@compaq.com)o Fortran Engineeringv* High-Performance Technical Computing Group& Compaq Computer Corporation, Nashua NH  6 Compaq Fortran web site: http://www.compaq.com/fortran   ------------------------------  % Date: Mon, 30 Jul 2001 09:37:21 -0400 + From: "Rick Barry" <barry@star.zko.dec.com>/$ Subject: Re: FastCGI support in CSWS1 Message-ID: <ltd97.310$Yx2.6966@news.cpqcorp.net>.  2 "Stanley Hippler" <stan@lsua.edu> wrote in message7 news:782cd74d.0107271211.5be6816a@posting.google.com...iE > I want to use FastCGI with the latest release of CSWS.  Does anyones@ > have this working and would be willing to share installion and > configuration notes? >aE > It seems that having a downloadable version of CSWS + SSL + FastCGIiH > might be worthwhile in addition to the CSWS + SSL currently available. >n > Thanks in advance. >o > --stan  L Compaq currently has no plans to offer FastCGI with Compaq Secure Web ServerL (CSWS). mod_perl and Java servlet support are more popular script engines in> the eyes of our customers so we've given them higher priority.  H We encourage those in the CSWS/OpenVMS community to help port FastCGI to: OpenVMS using mod_cgi from the CSWS sources as a base (seeK http://www.openvms.compaq.com/openvms/products/ips/apache/csws_source.html)gE and share the results with others.  We may include the work in futurei versions of CSWS.   
 Rick Barry Compaq Secure Web Server OpenVMS System Software Groupo Compaq Computer Corporations
 Nashua, NH   ------------------------------  % Date: Mon, 30 Jul 2001 03:31:19 -0400.' From: "Bill Todd" <billtodd@foo.mv.com>l- Subject: Re: Few People in DEC Understood....t( Message-ID: <9k32hf$fm8$1@pyrite.mv.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B64D04A.A9D3E082@videotron.ca... > Bill Todd wrote:K > > All-in-one was, as best I can remember, regarded as an abomination whenP itJ > > first appeared:  large, kludgey, and slow.  In retrospect, it seems to have6 > > been the logical precursor to Microsoft bloatware: >wK > Consider that I was able to support 12 office workers on ALL-IN-1 runningi on a1 > Microvax II with 16 meg of memory back in 1987.t  I Consider that I did time-shared software development with two dozen other2K people on a 248 KB PDP-11/45 in 1976:  bloat is in the eye of the beholder.u  D And in this context you might remember that Microsoft's products ranH (single-user, of course, and increasingly uncomfortably) in 640 KB until Windows 95 appeared.    Consider that image activation 3 > (essentially once per day) took about 15 seconds.u >*F > Compare this to MS office and you wouldn't apply the term "bloat" to	 ALL-IN-1.e  K Yes, I would.  All-in-1 was saved by exactly the same thing that saved MS's  products:  Moore's Law..  H But, as I said, it was perceived (and I believe correctly) when it firstA appeared, as large, kludgey, and slow.  It was also not quite the L architecturally elegant edifice that you suggest (and FAIK it could be true)L that it became later.  If people never adjusted their perception in the faceG of such a major improvement, that's regrettable but at the same time ate least somewhat understandable.   - bill   ------------------------------  % Date: Mon, 30 Jul 2001 11:13:56 -040035 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>o- Subject: Re: Few People in DEC Understood....t1 Message-ID: <ERe97.320$Yx2.7152@news.cpqcorp.net>6  I I was in the field when the "Charlotte Package", which later evolved intoeK All-In-One showed up.  Engineering didn't like it one bit.  Nonetheless, itoB sold VAX 780's.  It was more important in it's time then anyone inK engineering could concieve.  I found that engineering was insular and badlye infected with NIH.  I Was it ugly?  You bet.  But what it did was solve a lot of problems for aeD lot of customers.  *It* sold the systems.  Yup... JUST LIKE WINDOWS.      : Bill Todd wrote in message <9jv99h$amk$1@pyrite.mv.net>... >S6 >"David Cressey" <david@dcressey.com> wrote in message/ >news:QKy87.43$Iw2.1733@petpeeve.ziplink.net...hJ >> This is a tangent off of the Ken Olsen and history thread, which itself >was
 >> a tangent.m >>K >> There are a lot of products that DEC made about which people in DEC saidiK >> "few people in DEC understood how good, important, powerful, and elegant H >> this product was".  Or maybe "few people understood what it was for".0 >> All-in-one was mentioned in the other thread. >wK >All-in-one was, as best I can remember, regarded as an abomination when ittL >first appeared:  large, kludgey, and slow.  In retrospect, it seems to haveA >been the logical precursor to Microsoft bloatware:  esthetically. unpleasing,iK >but sufficiently in tune with the functionality that customers wanted thatsL >it didn't matter (and fully in tune with the 'anything for a buck' attitude3 >of its creators, who named their home node ATFAB).d >  >>8 >> Here's a list of products I've heard that said about: >>
 >> All-in-oned >> Rdb >> ACMS  >> The Common Data dictionary 
 >> Datatrieve  >eJ >Back in the late '70s, Central Engineering at DEC did not own things likeK >the 'commercial' languages, RMS, Datatrieve-11, and DBMS-11, and tended to J >look down on them as unworthy of its technical heritage (though even backK >then the commercial uses of DEC systems likely brought in revenue at least I >comparable to the technical uses).  And the technical people who ran DEC2I >later on came largely from that background, so this lack of appreciationn mays >have persisted. >rG >And All-in-one came from a group even farther from the center of DEC'sh
 >universe. >d >>I >> I don't necessarily agree with the everything in the above list.  It'ssD >> probably the case that there are lots of Products that *I* didn't >understandh2 >> the importance of until it was very, very late. >>L >> Can you add to the above list?  Can you put some hardware products on the >> list? >>I >> Can you comment on WHY a company like DEC seemed so often to be at wart >withm
 >> itself? >HI >Perhaps because the 'strategic' style of management adopted in the earlyhI >'80s no longer allowed people who felt some product was an embarrassmentyK >simply to go off and build something better:  when internal competition isoI >stifled, not only does the breed suffer in general but energy that would:: >otherwise be put to good use gets diverted into politics. >eE >  Did this phenomenon carry over into Compaq or is there a differentl >> culture over there? >rL >Since DEC was already terminally PC-centric under Palmer well before Compaq >took over, it's hard to tell. >J >>J >> Was the VAX information architecture really an architecture or was it aH >> hodgepodge of products that had been ideated and realized separately? >WJ >Yes and no.  DATATRIEVE-32 was an extension of Datatrieve-11 and predatedI >CDD and Rdb by years, so any compatibility in its case was via retrofit.fJ >DBMS-32 IIRC also was completed before any thought of CDD arose.  Some ofK >the later portion of Rdb's initial development may have taken place in thepL >context of thoughts of CDD - and CDD itself may have initially been createdJ >to promote compatibility between Rdb and Rdb-ELN (which was Jim Starkey'sK >alternative to Rdb that later became Interbase):  anyone still around fromh, >that era with a more definite recollection? >uK >And my vague memory is that ACMS arrived on the scene a bit later than ally >the above.  >p >- bill  >r >> --  >> Regards,n >>     David Cressey >>     www.dcressey.com  >> >> >. >    ------------------------------  % Date: Mon, 30 Jul 2001 12:53:20 -0400f- From: JF Mezei <jfmezei.spamnot@videotron.ca>e- Subject: Re: Few People in DEC Understood....l, Message-ID: <3B6590FB.4F1408D9@videotron.ca>   Fred Kleinsorge wrote:K > Was it ugly?  You bet.  But what it did was solve a lot of problems for a F > lot of customers.  *It* sold the systems.  Yup... JUST LIKE WINDOWS.  K Beauty is in the eye of the beholder. ALL-IN-1 was a large application withjM lots and lots of files. By VMS standards, it was huge, compared to compilers,mU TPU etc. So I can understand that many would have found A1 to be a huge ugly monster.a  L But when those engineers didn't realise is that part of the reason A1 was soI big is that it shipped with about half of the source code which customersdG could then copy or modify. The A1 engineers also devised a logical namedF structure that allowed you to store your changed modules in a separateK directory which would not be overwritten the next time you upgraded A1, and J you could then run a report that would show you how each customized module  would work with the new version.  N However, to the casual observer, the large number of directories seemed like aM big mess, but once you understood why they were there, it made a lot of sense0 and was in fact quite elegant.   ------------------------------  % Date: Mon, 30 Jul 2001 13:42:23 -0400r5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>r- Subject: Re: Few People in DEC Understood.... 1 Message-ID: <N0h97.346$Yx2.7446@news.cpqcorp.net>   J It was... ugly.  Especially in the beginning.  At least one of the reasonsI was that it had to accomplish everything it did without any (or grudging)  help from engineering.  J But frankly I don't care much about how elegant it might or might not have2 been - it solved real problems for real customers.      = JF Mezei wrote in message <3B6590FB.4F1408D9@videotron.ca>...- >Fred Kleinsorge wrote: L >> Was it ugly?  You bet.  But what it did was solve a lot of problems for aG >> lot of customers.  *It* sold the systems.  Yup... JUST LIKE WINDOWS.8 >0L >Beauty is in the eye of the beholder. ALL-IN-1 was a large application withC >lots and lots of files. By VMS standards, it was huge, compared tor
 compilers,H >TPU etc. So I can understand that many would have found A1 to be a huge
 ugly monster.t >.J >But when those engineers didn't realise is that part of the reason A1 was soJ >big is that it shipped with about half of the source code which customersH >could then copy or modify. The A1 engineers also devised a logical nameG >structure that allowed you to store your changed modules in a separaterL >directory which would not be overwritten the next time you upgraded A1, andK >you could then run a report that would show you how each customized module ! >would work with the new version.. > H >However, to the casual observer, the large number of directories seemed like aH >big mess, but once you understood why they were there, it made a lot of sensen >and was in fact quite elegant.s   ------------------------------  % Date: Mon, 30 Jul 2001 11:38:52 +0100r% From: Alan Greig <a.greig@virgin.net>s! Subject: Goodbye, good friend DECu8 Message-ID: <61eamtolm6kfumr5f317l5i4jd3lpv99dr@4ax.com>  & Something else to wake Compaq up with?    B http://www.zdnet.com/eweek/stories/general/0,11011,2782356,00.html  > You can also read comments and add your own at the above link.   By Brett Arquette  July 3, 2001 2:25 PM ETw       C Last week, Compaq announced the death of its Alpha line, one of the F last remnants of a company that was the bread and butter to many of us. aging baby boomers -- Digital Equipment Corp.   D The Alpha technology was the last true DEC product that Compaq stillA sold and continued to upgrade, and the death of Alpha pulls at myaD heart stings and takes me back to the 1980s and the two most popular# approaches to high-end processing. a  B As a young guy, I started working as a computer operator in an IBMD shop, where my primary duty was hanging tapes. IBM disk space was soD expensive that every job sucked in two tapes, and spit out one, then  cleared the disk working space.   D A few years later I went to work for a hospital that ran all DigitalC VAXs, and I was both amazed and confused. Jobs ran, but they didn't E require an operator to hang tapes. As a matter of fact, the only time7E tapes were used was for backups. "This is wonderful," I thought. WhatDC a cost and time saver. Everything was on disk: the input files, thee@ output files, the database, everything. And the entire operatingB system could be controlled by a simple little interface called the Digital Command Language.   F As a graveyard operator, I had a lot of free time to learn DCL, and inD a few short months had virtually automated the entire midnight shiftB by writing a series of command files that made up an application IF called Robocop. When I came on duty, I would crank up Robocop and fall? asleep. As the job phases ran, Robocop would check each job for B errors; if it found any, it would stop all the jobs and beep on myC terminal, waking me just long enough to call a programmer who wouldrB dial in and fix the problem. Once the job was fixed, Robocop wouldC start the job phases, fill out the operator log and wake me just intB time to make coffee before the managers came in. Little did I knowE that my laziness had made me an expert in DCL, and I soon moved up todB Computer Analyst, then Manager, then Director, which lead me to my current CTO position.   C The Alpha technology was the first true 64-bit chip, maybe 10 yearstE ahead of its time, and it absolutely screamed. Only now are we seeingrB companies such as Intel making noises in the 64-bit arena, even asC Compaq lets the world's first flagship 64-bit chip die on the vine.rE When Digital was Digital, you could expect your DEC sales rep to call0A you once a month to see if you needed anything or to tell you the E latest and greatest stuff they were coming out with. Once Compaq tooknB over, I never received another call. It's no wonder the Alpha lineC went down the tubes, and I'm still mystified by the acquisition and. what Compaq got out of it. c  F I will always have a warm place in my heart for Digital and am mindfulF of how the company and its products influenced and guided my career. IE almost think of Alpha as a transplanted organ that continues to thumpSC away in a Compaq body. So now, as Compaq removes the respirator and,F pulls the plug on Alpha, I'd like to take a moment and say "thank you"C to the thousands of brilliant people who worked at DEC and wish youa< all the best, wherever life takes you. It was a great ride.   & E-mail Brett Arquette at barq@iag.net.     -- Alan   ------------------------------    Date: 30 Jul 2001 10:22:18 -0500+ From: young_r@encompasserve.org (Rob Young),% Subject: Re: Goodbye, good friend DEC*3 Message-ID: <kWL3wmiBdx6P@eisner.encompasserve.org>   ` In article <61eamtolm6kfumr5f317l5i4jd3lpv99dr@4ax.com>, Alan Greig <a.greig@virgin.net> writes:( > Something else to wake Compaq up with? >  > D > http://www.zdnet.com/eweek/stories/general/0,11011,2782356,00.html > @ > You can also read comments and add your own at the above link. >  > By Brett Arquette  > July 3, 2001 2:25 PM ET  >    	Old news and somewhat silly.     C 	He describes DCL and VAXes and talks in terms as if they are both  E 	history.  He is more than a little ahead of himself as VMS survived  D 	VAX and he talks as if it isn't around.  Another writer that can't  	seem to say "VMS".    				Rob    ------------------------------  % Date: Mon, 30 Jul 2001 15:37:08 +0100*% From: Alan Greig <a.greig@virgin.net>-% Subject: Re: Goodbye, good friend DEC48 Message-ID: <40samtcqto9tatcbeul6qlcr7en18frgpf@4ax.com>  D On 30 Jul 2001 10:22:18 -0500, young_r@encompasserve.org (Rob Young) wrote:   >m  >	Old news and somewhat silly.   >nD >	He describes DCL and VAXes and talks in terms as if they are both F >	history.  He is more than a little ahead of himself as VMS survived E >	VAX and he talks as if it isn't around.  Another writer that can't n >	seem to say "VMS".  D But that's partly the point. Unless you are still actively using VMSF then VAX, VMS,  DCL, and now Alpha *are* history. The fact that VMS isE still living seems to be a secret Compaq would like to keep to itselfa and a few remaining customers.  B If you read the followups a number of people point out that VMS is still with us. -- Alan   ------------------------------  % Date: Mon, 30 Jul 2001 02:09:12 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>h. Subject: Re: IA64 volume and low-end dominance( Message-ID: <9k2tnd$76u$1@pyrite.mv.net>  : "George Coulouris" <glc+spam@patriot.net> wrote in message1 news:slrn9m9iqm.fe1.glc+spam@adams.patriot.net...GL > On Sun, 29 Jul 2001 19:17:18 -0400, Bill Todd <billtodd@foo.mv.com> wrote:   ...o  K > >Such use of mmap is a Unixism, and Unix has typically lagged a decade or:K > >three behind when it comes to high-performance disk access (extent-basedCK > >file systems, which date at least back to the early 1970s and likely faraH > >earlier, are still the exception rather than the rule).  I doubt thatJ > >high-end databases can throw away performance to that degree and remainC > >competitive.  Low-end databases may be able to, but then low-endt	 databasest5 > >far less frequently need the larger address space.  >iF > I use MapViewOfFile() as a drop-in replacement for mmap() under w2k. > Does pretty well.C  L The question is, pretty well at what?  There are certainly applications thatI can use this effectively (as well as applications where it's a really badWI idea), but typically databases (the area that was being discussed) have ahL pretty well-defined means of accessing data:  it resides in structured pagesI of one or a few fixed sizes, these pages are often accessed randomly, andoI when written back to the database they're written in a tightly-controlledpL manner (and usually in page units) w.r.t. log file writes.  Mapped access asA typically implemented in Unix (and in Windows) doesn't meet theseBK requirements well; neither do 'single-level store' approaches such as thoseeJ used in System/38 and its descendants unless the normal access methods areB supplemented with mechanisms to control such activity more finely.   - bill   ------------------------------  % Date: Mon, 30 Jul 2001 04:21:14 -0700.- From: DONT.qed.SPAM@ME.pobox.com (Paul Hsieh)a. Subject: Re: IA64 volume and low-end dominance9 Message-ID: <MPG.15cee3047835b2799898e9@news.pacbell.net>   ' michaelpettengill@earthlink.net says...w> > "Jordan Henderson" <jordan@lisa.gemair.com> wrote in messageC > >   What really drove the move from IA16 to IA32 was not customerf? > >   demand for faster systems, but rather customer demand for D > >   the new system software (Windows386, OS/2, Unix) that required@ > >   IA32.  This is what will drive the move from IA32 to IA64. > = > What software exactly was it that drove the demand for 386?   I Lotus 1-2-3 and Word Perfect (at this point Microsoft had not yet proven bH that they could write good software.)  The 386's most redeaming feature G was its higher clock rate, and the fact that Compaq got behind it 100% iH (just as a way of sticking it to IBM, who for some reason didn't make a G 386 based machine until more than a year after Compaq.)  People bought  G 386's because that was the only solution that lead to faster computers.   G "32 bit programming" didn't really arrive until about the time the 486 vF transitioned over to the Pentium; i.e., when all new programs (DOS or ! Windows) came in a 32 bit flavor.h    --
 Paul Hsieh http://www.pobox.com/~qed/   ------------------------------  % Date: Mon, 30 Jul 2001 13:04:50 +0200j& From: Bernd Paysan <bpaysan@mikron.de>. Subject: Re: IA64 volume and low-end dominance( Message-ID: <3B653F52.857942D@mikron.de>   Ben Franchuk wrote: N > The fact that DOS was never modified to run 32 bit code and there was was no= > FREE 32 bit assembers/compilers forced windows on everbody.F  E What? I got my 386 PC sponsored (to port bigFORTH to x86) in 1991. MyqG sponsor was under the same impression as you, that there was no free 32r@ bit assembler (or compiler), and also sponsored me PharLap's DOSC extender. I soon found out that the assumption was wrong, there was A DJGPP (the GCC porting project from DJ Delorie), with GO32 as DOS C extender (nowadays, DJGPP just uses DPMI, but GO32 lives on as DPMI? host).  ? > The other factor was the 386 had 1) larger memory than 16MEG,o > 2) Built in floating point  H Nah, you had to buy a 387 for floating point, or run an emulator (one ofF the emulators written for DJGPP also ended up as coprocessor emulationA in the Linux kernel). Even the 486 (with built in FP) had a 486SXa; variant that didn't have one (or rather a deactivated one).f   --   Bernd Paysan7 "If you want it done right, you have to do it yourself"w http://www.jwdt.com/~paysan/   ------------------------------  % Date: Mon, 30 Jul 2001 13:21:21 +0200>& From: Bernd Paysan <bpaysan@mikron.de>. Subject: Re: IA64 volume and low-end dominance) Message-ID: <3B654331.3B35B9ED@mikron.de>i   Bill Todd wrote:N > The question is, pretty well at what?  There are certainly applications thatK > can use this effectively (as well as applications where it's a really bad K > idea), but typically databases (the area that was being discussed) have anN > pretty well-defined means of accessing data:  it resides in structured pagesK > of one or a few fixed sizes, these pages are often accessed randomly, andeK > when written back to the database they're written in a tightly-controlledh< > manner (and usually in page units) w.r.t. log file writes.  	 man msyncc  C You can tightly control your write-back times, at least within syncnB points ("must be written before"). With log-structured writes, youF typically first announce updates into the log, then write the log, andE then update the in-core database pages; before starting the next log,e sync the updated pages.r  F If you use mmap without any sort of madvice or automatic prefetch, youC better stick to the CPU's page size for your data base. And currento4 pages are either too small or too large (4k vs. 4M).   -- r Bernd Paysan7 "If you want it done right, you have to do it yourself"' http://www.jwdt.com/~paysan/   ------------------------------  # Date: Mon, 30 Jul 2001 13:07:03 GMTp$ From: iddw@hotmail.com (Dave Hansen). Subject: Re: IA64 volume and low-end dominance0 Message-ID: <3b655a6b.331832712@News.CIS.DFN.DE>  ( On Sat, 28 Jul 2001 10:05:10 GMT, "mulp"( <michaelpettengill@earthlink.net> wrote:   [...]C< >What software exactly was it that drove the demand for 386?   QEMM386  ;-)  ? In my case anyway, it took a system that (with various TSRs andeC Novell) had about 460K of free RAM and returned one with over 700K.e< And a huge RAM disk that reduced compile times tremendously.   Regards,  %                                -=Davel -- o& Change is inevitable, progress is not.   ------------------------------  % Date: Mon, 30 Jul 2001 09:30:38 -0400l' From: "Bill Todd" <billtodd@foo.mv.com>o. Subject: Re: IA64 volume and low-end dominance( Message-ID: <9k3nj0$69e$1@pyrite.mv.net>  3 "Bernd Paysan" <bpaysan@mikron.de> wrote in messageq# news:3B654331.3B35B9ED@mikron.de...  > Bill Todd wrote:K > > The question is, pretty well at what?  There are certainly applicationsp thatI > > can use this effectively (as well as applications where it's a reallyE bad K > > idea), but typically databases (the area that was being discussed) have  apJ > > pretty well-defined means of accessing data:  it resides in structured pagesnI > > of one or a few fixed sizes, these pages are often accessed randomly,o and : > > when written back to the database they're written in a tightly-controlled> > > manner (and usually in page units) w.r.t. log file writes. >n > man msynci >wE > You can tightly control your write-back times, at least within syncyD > points ("must be written before"). With log-structured writes, youH > typically first announce updates into the log, then write the log, andG > then update the in-core database pages; before starting the next log,d > sync the updated pages.e  I As you describe it above (and as the man page describes it) this requires H you not to touch the in-memory pages until the log update has completed.7 For much internal database use, this is not acceptable.3   >FH > If you use mmap without any sort of madvice or automatic prefetch, youE > better stick to the CPU's page size for your data base. And currente6 > pages are either too small or too large (4k vs. 4M).  J Remember that this issue was raised as a matter of programming convenienceL that a 64-bit address space offered to database-internal code.  When you addH in the requirements of using madvise before your mmap, msyncs to controlI writes (leaving aside the fact that they don't control writes the way the E database normally wants to), and explicit locking associated with allrF accesses (which generates extra network traffic in distributed systemsI compared with approaches that can associate locking information with eachdL access request), the added 'convenience' of using mmap seems questionable at best.g   - bill   >  > -- > Bernd Paysan9 > "If you want it done right, you have to do it yourself"  > http://www.jwdt.com/~paysan/   ------------------------------  + Date: Mon, 30 Jul 2001 13:58:33 +0000 (UTC) / From: Sander Vesik <sander@haldjas.folklore.ee>,. Subject: Re: IA64 volume and low-end dominance2 Message-ID: <996501519.413409@haldjas.folklore.ee>  3 In comp.arch Bill Todd <billtodd@foo.mv.com> wrote:e  < > "George Coulouris" <glc+spam@patriot.net> wrote in message3 > news:slrn9m93gf.64f.glc+spam@adams.patriot.net...sG >> On 29 Jul 2001 16:38:08 GMT, Peter da Silva <peter@abbnm.com> wrote: 	 >> [snip]r >> >F >> >In the 64-bit arena, it's large sparse address spaces for high-end > databases. >> > >>L >> I'd go so far as to generalize this to dense address spaces as well. It's' >> handy to use mmap() to pull in data.r  M > Handy, possibly.  Inefficient, usually, since mmap doesn't know the size of.N > the chunk of data you need and unless the system's page-fetch algorithm justM > happens to correspond with that size you'll either perform multiple fetches.N > from disk for a single chunk or fetch more than you need.  And when it comesL > time to write the data, you almost always need fine control over when, and > how much, hits the disk.  F Or you cpould possibly use mmap together with madvise and not have the
 problem...  J > Such use of mmap is a Unixism, and Unix has typically lagged a decade orJ > three behind when it comes to high-performance disk access (extent-basedJ > file systems, which date at least back to the early 1970s and likely farG > earlier, are still the exception rather than the rule).  I doubt thatpI > high-end databases can throw away performance to that degree and remaindL > competitive.  Low-end databases may be able to, but then low-end databases4 > far less frequently need the larger address space.  + Well, I doubt databases mmap their data 8-)o   > - bill   -- d 	Sander    +++ Out of cheese error +++o   ------------------------------  % Date: Mon, 30 Jul 2001 10:04:50 -0400e' From: "Bill Todd" <billtodd@foo.mv.com> . Subject: Re: IA64 volume and low-end dominance( Message-ID: <9k3pj4$96a$1@pyrite.mv.net>  < "Sander Vesik" <sander@haldjas.folklore.ee> wrote in message, news:996501519.413409@haldjas.folklore.ee...5 > In comp.arch Bill Todd <billtodd@foo.mv.com> wrote:s >n> > > "George Coulouris" <glc+spam@patriot.net> wrote in message5 > > news:slrn9m93gf.64f.glc+spam@adams.patriot.net...uI > >> On 29 Jul 2001 16:38:08 GMT, Peter da Silva <peter@abbnm.com> wrote:s > >> [snip]o > >> >H > >> >In the 64-bit arena, it's large sparse address spaces for high-end > > databases. > >> > > >>I > >> I'd go so far as to generalize this to dense address spaces as well.a It's) > >> handy to use mmap() to pull in data.d >eL > > Handy, possibly.  Inefficient, usually, since mmap doesn't know the size ofK > > the chunk of data you need and unless the system's page-fetch algorithmt justG > > happens to correspond with that size you'll either perform multiple  fetchesaJ > > from disk for a single chunk or fetch more than you need.  And when it comesoJ > > time to write the data, you almost always need fine control over when, andk > > how much, hits the disk. >tH > Or you cpould possibly use mmap together with madvise and not have the > problem... >oL > > Such use of mmap is a Unixism, and Unix has typically lagged a decade orL > > three behind when it comes to high-performance disk access (extent-basedL > > file systems, which date at least back to the early 1970s and likely farI > > earlier, are still the exception rather than the rule).  I doubt thatnK > > high-end databases can throw away performance to that degree and remainhD > > competitive.  Low-end databases may be able to, but then low-end	 databasesm6 > > far less frequently need the larger address space. >a- > Well, I doubt databases mmap their data 8-)R  G The comment to which I was responding was itself a response (in its owntJ words, a generalization) of the comment that large databases would benefitL from a 64-bit address space.  Thus I interpreted it as suggesting that largeK databases would benefit from mmaping their data, and felt it appropriate too% point out that this was questionable.o  I If the comment was simply meant to suggest that some applications find it E convenient to mmap their data, I have no problem with it (but it thend< becomes irrelevant to the discussion to which it responded).   - bill   >r
 > > - bill >, > -- > Sander >y > +++ Out of cheese error +++    ------------------------------    Date: 30 Jul 2001 12:54:00 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>nC Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)lH Message-ID: <y4u1zuadrr.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  - Christopher Smith <csmith@amdocs.com> writes:   E > > > > Given that any reasonable file system is good enough for the h > > > > purpose, it makesfC > > > > sense for Intel to base its IA64 systems architecture on a d > > > > FAT file system. I6 > > > I think there's a contradiction in the above. ;) > > Nope. Why do you think so?L > I would argue that FAT is by no means a "reasonable" filesystem, and is asJ > hacked-up and twisted as the so-called operating system that spawned it.  H For the purpose of locating a few files to boot the OS? Even FAT is good0 enough for that. And that was what I said above.   	Jan   ------------------------------    Date: 30 Jul 2001 13:00:25 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>wC Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS) H Message-ID: <y4r8uyadh2.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  / JF Mezei <jfmezei.spamnot@videotron.ca> writes:2  L > But VMB or APB.EXE are blocks that are read by the console. So the consoleK > doesn't necessarily need to know about a file structure, it just blindly  5 > picks up data from the disk at a specific location.c  8 No, very many uVAX systems have VMB in the console code.  O > What Fred seems to be saying is that the console on IA64 will have sufficient1M > knowledge of the NT file system to parse file system structures to find thea > data it needs to read.  L So what? That's probably 100-200 lines of code. Reading a very specific fileN with very specific constraints is dead simple, once you have the capability ofL reading a single disk block (courtesy of the console's/bootstrap's primitiveH boot-time dirvers). VMB/APB and SYSBOOT do the same job, all without theK benefit of the XQP. Why do you think a bootable disk has [0,0]SYSEXE.DIR as: a link?0   	Jan   ------------------------------    Date: 30 Jul 2001 13:02:52 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>uC Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS) H Message-ID: <y4ofq2adcz.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  7 "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:o  K > I have no idea what SYSLOADxxx is.  Maybe you mean SYS$CPU_ROUTINES_xxxx.   8 I meant SYSLOA750 et al. Dunno how the D got into there.   	Jan   ------------------------------    Date: 30 Jul 2001 13:05:04 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>tC Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS) H Message-ID: <y4lml6ad9b.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  / JF Mezei <jfmezei.spamnot@videotron.ca> writes:n  H > > The per-cputype loadable code (SYSLOADxxx.EXE) contains the code for" > > console output, among others. H > But by the time SYSLOADxxx.EXE is loaded, the machine isalready a VMS + > machine, it is no longer in console mode.<  N You were talking about having a line-mode vs a graphical-head console, which IN presumed having the console while a windowing system was running. Before that,N the graphics behave pretty much like a glass TTY emulator, so there isn't muchH difference to the serial-line console (apart from not having a record on paper).n   	Jan   ------------------------------    Date: 30 Jul 2001 13:13:08 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>oC Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)gH Message-ID: <y4itgaacvv.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  0 "mulp" <michaelpettengill@earthlink.net> writes:  M > Of course, there are so many areas where these guys are clueless.  ConsiderfN > the case of the 144 and 288 gig drives.  What are they good for.  For a highH > performance server with 10 terabytes the requirements for I/O rate andE > thruput probably dictates the need for 1000 drives across 10-100 FCb
 > adapters.  t  L There are a lot of cases where you need a large amount of reference data butN not as high thoughput. Imagine having a few days worth of EOSDIS output (up toK a few TB a day, I think) on your local machine for research. How you get it G there in the first place is of course another question. Quite possibly,iH instead of station wagons full of magtapes, it will soon be SUVs full of disks.   	Jan   ------------------------------    Date: 30 Jul 2001 13:16:38 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>cC Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)tH Message-ID: <y4g0beacq1.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ; Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:a  B > The only regard in which Fred is wrong-headed is in not choosingD > ISO 9960 over FAT, but that's ok because we need something to beat! > him up about over the years :-)e  J Likely the ISO 9960 support in the IA64 console is making assumptions thatN the volume really is read-only, which probably creates problems when you later  want to use the disk read-write.   	Jan   ------------------------------    Date: 30 Jul 2001 13:19:02 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)dH Message-ID: <y4d76iacm1.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ' "Rich Jordan" <rjordan@mcs.net> writes:n  G > I  felt it appropriate to make a strong desire and preference for theiH > continued availability of a standard serial console known to those whoL > will end up providing it, as I honestly doubt making that known _anywhere_L > else at Compaq would matter in the least.  In fact, I will strengthen thatK > statement.  The lack of a serial console would be considered as a serious I > shortcoming and detriment, given our established system and maintenanced > environment;  K While I agree with the sentiment - do the GS80 et al. systems have a serial-" console in your sense of the word?   	Jan   ------------------------------  % Date: Mon, 30 Jul 2001 08:24:10 -0300o+ From: <fabio_compaq@ep-bc.petrobras.com.br>3C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)aL Message-ID: <OFBC804E27.9C0E41C5-ON03256A99.003E7A03@ep-bc.petrobras.com.br>   I will comment again:o  I HP PA-RISC machines (specifically L-1000 which I used to configure), have  the LAN Console.H I dont understend why Alpha's or Itanium's could not have a LAN COnsole.K May be... we will have for Itaniums, because for Proliants there is the RIBn (Remote Insighth8 Board) for remote ('far') control of the machine (Intel)   Regardso   FC      m                                                                                                              em                     Jan Vorbrueggen                                                                          8m                     <jan@mailhost.neuroinformatik.ruhr-uni-        Para:   Info-VAX@Mvb.Saic.Com             em                     bochum.de>                                     cc:                                       rm                                                                    Assunto:     Re: IPF Console Bootstrap    pm                     30/07/2001 08:19                               (was: Re: No chance for OpenVMS)          nm                     Responder a Jan Vorbrueggen                                                              km                                                                                                               m                                                                                                              h        ' "Rich Jordan" <rjordan@mcs.net> writes:y  G > I  felt it appropriate to make a strong desire and preference for thefH > continued availability of a standard serial console known to those whoA > will end up providing it, as I honestly doubt making that knownn
 _anywhere_G > else at Compaq would matter in the least.  In fact, I will strengthen  thatK > statement.  The lack of a serial console would be considered as a serioussI > shortcoming and detriment, given our established system and maintenanceo > environment;  K While I agree with the sentiment - do the GS80 et al. systems have a serialo" console in your sense of the word?        Jan   ------------------------------    Date: 30 Jul 2001 07:33:59 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)M3 Message-ID: <76tKKOLDMagl@eisner.encompasserve.org>    In article <y4g0beacq1.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>, Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:= > Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:n > C >> The only regard in which Fred is wrong-headed is in not choosing2E >> ISO 9960 over FAT, but that's ok because we need something to beat." >> him up about over the years :-) > L > Likely the ISO 9960 support in the IA64 console is making assumptions thatP > the volume really is read-only, which probably creates problems when you later" > want to use the disk read-write.  E While consoles (on Alpha, for instance) mediate access to the console C terminal by the operating system, I think they have no role in diskoE access.  VMB (APB) for instance, runs a "primative file system" which E can sort of stumble it's read-only way around an ODS-2 disk.  I don'tuF believe, however, that is passes any context to the "real" file system+ that runs on the copy of VMS that it boots.s  B I suppose it is possible the IA64 console keeps on doing it's fileG access after the OS is running, in which case it might make assumptionshD that the ISO9660 data is unchanged.  Of course really it would be on- an ISO9660 disc that contains only two files:s  $ 	BOOTFILE              100,000 bytes 	ODS2FILE	9,100,000,000 bytese  I Since the console would never look inside ODS2FILE, it would never notice E changes.  (In response to a previous discussion about mounting disks,hC the above arrangement can look to the XQP like the BOOTFILE and thelA ISO 9660 directory data are files inside a single file on ODS-2.)    ------------------------------  # Date: Mon, 30 Jul 2001 14:56:25 GMT   From: jlsue <jlsuexxxz@home.com>C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)i8 Message-ID: <k9samtktieau230jm3lg69h3jpv72ipub0@4ax.com>  ( On Sat, 28 Jul 2001 06:05:37 GMT, "mulp"( <michaelpettengill@earthlink.net> wrote:  . >"jlsue" <jlsuexxxz@home.com> wrote in message3 >news:r2n1mtk3aud0pag34hg4jvlpdts63hqk1f@4ax.com... E >> Actually, unless you're talking about some kind of console logginguE >> system (a la Polycenter Console Manager), the Remote Insight BoardmH >> Lights Out Edition provides a really nice remote graphics console for >> servers.  >>G >> Now, granted it doesn't perform a nicely as a character-cell consoleoH >> since it's throwing all those graphics around... but it's not too bad >> to work with. >n >You got it to work????  >cL >What did you do, use Windows 4.0?  With win2k, RIB was very unreliable whenM >I last tried to use it, circa March 2001.  It would work one minute and thentL >not the next.  We were trying to use it with the SAN applicance.  The firstL >step was to discard the (released/shipping) RIB module.  Then the next stepI >was to discard the SAN Applicance and just connect the net storage array + >controller to VCS systems via serial port.t  C Well,  I've got an ML350 sitting right here with a RIB in it.  This B system is running Windows 2000.  The RIB works perfectly - well asA "perfectly" as a gui can get.  There is a timeout setting for the-E console which, unfortunately, isn't based on activity/inactivity.  ItCA is a hard setting which defaults to 15 minutes, and can go to 120I mins.u  C Granted, I haven't tried to use this thing across a WAN, but I onceeD managed servers where I had to use PCAnywhere over a dial-up line... this can't be worse than that.   > H >Don't you have to connect a second PC to the serial "printer" port of a% >Windows system to debug it a la SDA?S >a  C Well, I don't do that type of work, so I can't answer it.  However,iB the RIB does store the last crash info (blue screen), as well as aB playback of the last boot.  A CSC person could remotely dial-in to7 your network, connect to the RIB, and do investigation.   E The RIB does allow for remote power cycling of the server, as well asoF a new feature called "virtual floppy", which allows the server to bootC off of a remote, "virtual floppy" as if it is local.  This is kindaoB neat in that you don't have to walk over to the server and stick aC floppy into it.  I haven't tested this feature yet, so I can't tellt= you more than that.  Go to the compaq web page to learn more.d   ------------------------------  % Date: Mon, 30 Jul 2001 11:24:18 -0400t5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>UC Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS) 1 Message-ID: <k%e97.322$Yx2.6903@news.cpqcorp.net>s  = JF Mezei wrote in message <3B61CE59.882BF184@videotron.ca>...r >Fred Kleinsorge wrote:eL >> Yes.  But that code doesn't have to do it that way.  And in the IPF case,I >> that code knows how to not only fetch the first block, but how to finda and " >> read a FAT partition structure. >sK >It is correct to state that the VMS group has decided to build VMS so thata itE >can boot on an IA64 machine that has ROMs that were designed to boots Windows+    I The EFI console was "designed" to be O/S neutral.  In point of fact, some K years ago I was part of a team that tried (and failed) to create a "common"dK console (so there would not be a SRM versus AlphaBIOS) -- and to be honest,rE the EFI console meets ALL THE GOALS that we had for a common console.o  K >and will have the same configuration "menu" with the same disk drive namesGK >that are used to configure how a machine will boot windows ? (press F10 or. ESClL >within a certain number of seconds from power up to bring the configuration >menu) ? >.  L No, you will get menu like an old Alpha NT console (now that I've seen one).L You get a list of things you can boot.  You also get other things you can do= (like load a UNIX-like shell, or switch to a serial console).   J >Is it correct to state that the BIOS is often under the control/selection ofF >the computer maker instead of the chip maker ? If so, couldn't Compaq design aI >BIOS that is more sophisticated and supports more functionality than the 0 >standard BIOS that is expected on wintel junk ? >e    L The consoles purpose in life should be simple and sweet:  Find the hardware,H initialize it to a known state, load the OS, and get the h*ll out of theJ way.  It can also provide some level of hardware abstraction to the systemH (like machine checks, interrupts, and configuration management).  All of; this is done on IA64 by a combination of EFI, SAL, and PAL.d  F We can provide extended functionality IF IT IS NEEDED.  EFI stands for Extensible Firmware Interface.  2 Do NOT confuse EFI with the BIOS found on PeeCees.  J >How are the Tandem and Tru64 groups handling the boot sequence ? Is there workK >that is common to the 3 groups or do they work independantly of each othero/ >when it comes to interfacing to the hardware ?  >n  J Dunno about NSK, but they tend to have pretty unique HW requirements.  VMSI and Tru64 are talking to each other to make sure that we do not duplicateI efforts.  @ >Would it be correct to state that NSK will want to have its own BIOS/CONSOLE ?  J No idea.  I imagine given the unique nature of NSK, there may well be some unique things it will need.r   ------------------------------  % Date: Mon, 30 Jul 2001 11:26:10 -0400e5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>cC Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)o1 Message-ID: <51f97.323$Yx2.7090@news.cpqcorp.net>   = JF Mezei wrote in message <3B61D1DD.B50BD076@videotron.ca>...t >Fred Kleinsorge wrote: J >> Sigh.  The disk is still a PURE ODS2/5 volume to all VMS software.  VMS has-H >> TOTAL control over the whole disk drive.  There will be a FILE on the disk, 2 >> that in reality will contain a FAT32 partition, >jL >Thanks. I had originally misunderstood that the disk drive would have a FATJ >partition that contained an OSD disk drive. But what you're saying is the	 >reverse.t >mI >Since you'll be having a FAT container file on ODS, will you be re-using H >Pathworks code to let the boot loader find what it needs inside the FAT file    L Uh, no need.  The EFI console will find the OS_LOADER in the FAT file (sinceJ to the console, it is just a FAT partition) and the OS_LOADER will in turn2 be able to find and load in SYSBOOT (or whatever).   ------------------------------  % Date: Mon, 30 Jul 2001 11:32:49 -0400e5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS) 1 Message-ID: <l7f97.326$Yx2.7124@news.cpqcorp.net>-  H Paul Jacobi gave me a demo of one connected to a SAN management station.$ Seemed to work fine (if a bit slow).   mulp wrote in message ...e. >"jlsue" <jlsuexxxz@home.com> wrote in message3 >news:r2n1mtk3aud0pag34hg4jvlpdts63hqk1f@4ax.com...hE >> Actually, unless you're talking about some kind of console logging E >> system (a la Polycenter Console Manager), the Remote Insight BoardnH >> Lights Out Edition provides a really nice remote graphics console for >> servers.i >>G >> Now, granted it doesn't perform a nicely as a character-cell consoleeH >> since it's throwing all those graphics around... but it's not too bad >> to work with. >w >You got it to work????n >eL >What did you do, use Windows 4.0?  With win2k, RIB was very unreliable whenH >I last tried to use it, circa March 2001.  It would work one minute and thenL >not the next.  We were trying to use it with the SAN applicance.  The firstL >step was to discard the (released/shipping) RIB module.  Then the next stepI >was to discard the SAN Applicance and just connect the net storage arrayo+ >controller to VCS systems via serial port.o >uH >Don't you have to connect a second PC to the serial "printer" port of a% >Windows system to debug it a la SDA?l >0 >3   ------------------------------  % Date: Mon, 30 Jul 2001 11:31:35 -0400b5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>:C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)n1 Message-ID: <k7f97.325$Yx2.7164@news.cpqcorp.net>k   mulp wrote in message ...r >sA >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in messageR, >news:eiW77.172$Yx2.3425@news.cpqcorp.net...L >> The same thought has crossed my mind.  But I have not yet seen the UI forK >> the console, and don't know if there are ways to confine the devices theaK >> console looks at for partitions.   Of course, just like the SRM, it willn >berH >> looking to find all the devices anyway (regardless of doing a read of >block >> 0 from them all). >pG >Booting an Alpha from Fibre Channel doesn't size more than the devicesDG >needed to boot; those are configured using a utility and stored in the L >console flash.  Probing 100s or 1000s of partitions would obviously be veryH >painful; just probing and brining on line a couple dozen FC adapters is veryK >painful because the init code does them one by one (doing them in paralleldI >and then having a hardware error occur would make diagnosing the failinge >hardware almost impossible).  >'    D Until I actually have a chance to see the documentation on an actualH implementation (as opposed to the spec) and play with the boot loader, IA can't tell you.  But I would (and am not) making any assumptions.r  E >So, we have a cluster of Alpha and IA64 systems, and the SRM will beN lookingfH >at block 0 and the EFI will be looking at block 0, so which will it be? >    1) a Files-11 bootblock
 >    2) a MBRt >n    J It should be, will be, easy to tell the difference.  There is no intent to3 make an Alpha disk bootable by IPF, or the reverse.r  L >It clear that the people working on this are PC centric and are thinking inJ >terms of big systems being maybe 10 disks or something.  Hey, by the timeL >"big" systems are deployed, 10 disks will be 2 terabytes or more and no one >would need more than that.o >e    E Perhaps, but remember that Intel clearly was interested in large UNIX  servers for IA64 as well.   G >I remember when years ago we first had discussion of device naming forr FibreeJ >Channel disks.  The position taken was that everything would use WWID forI >device naming.  My response was, there is no reasonable way to make a 48  bit-L >WWID manageble, and the response was, oh, storage management software wouldL >take care of it.  I responded, NFW - add a console or controller command toK >write a device name into a code page.  No way, we'll hash the WWID to a 10sI >bit 4 digit number.   So, for years that was the discussion.  FC shippedgG >with the ability to set the unit number for VMS.  Tru64 configured andw namesa7 >the disks based on algorithms that are not documented.k >c    I Yeah, well I suggested that they simply write the damn device name to thee6 disk itself (after all, it *is* a storage device)  ;-)   ------------------------------  % Date: Mon, 30 Jul 2001 11:33:49 -0400h5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS) 1 Message-ID: <f8f97.327$Yx2.7186@news.cpqcorp.net>.   mulp wrote in message ...:A >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in messageg, >news:YEd87.218$Yx2.3558@news.cpqcorp.net...J >> Dual booting different architectures from the same disk has long been a >> non-goal. >tL >Booting is not the issue.  Mounting the disk is the issue.  And initing it. >And backing up. >lJ >I've got a million dollar tape library with an interface and software for myK >Alpha and no support on IA64.  So I'm going to backup disks mounted on theiI >IA64 system from the Alpha system which requires that they by mounted ons thed? >Alpha system.  And I probably want to backup the system disks.d >s    ; And your point is?  The disk is just another ODS2/5 volume.n   ------------------------------  % Date: Mon, 30 Jul 2001 12:07:02 -0400f- From: JF Mezei <jfmezei.spamnot@videotron.ca>-C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)p, Message-ID: <3B658624.CE2F1361@videotron.ca>   Jan Vorbrueggen wrote:P > You were talking about having a line-mode vs a graphical-head console, which IP > presumed having the console while a windowing system was running. Before that,P > the graphics behave pretty much like a glass TTY emulator, so there isn't muchJ > difference to the serial-line console (apart from not having a record on	 > paper).b  N Having the >>> on a serial line is perhaps even more important than having theN VMS "OPA0:" on a serial line. What good is your fancy remote system managementG if you cannot issue the proper commands to the console and then ask the  machine to boot ?   N For instance, in a disaster recovery scheme I had setup, after a disaster, theL satellite would be rebooted not only as a master but also switch from a testK node to a production node. To acheive this, the operator would B/1 DISK: to K get to SYSBOOT (by then into VMS), and then set some of the USER parameters L which were handled by the startup procedure to do all the proper definitions+ for the application, print queues etc etc).   L had the >>> prompt been forced to some blue screen with keyboard attached toX the mainframe, the operator would not have been able to remotely execute those commands.   ------------------------------  % Date: Mon, 30 Jul 2001 12:22:03 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS) , Message-ID: <3B6589A8.D2C7880A@videotron.ca>   Larry Kilgallen wrote:D > I suppose it is possible the IA64 console keeps on doing it's fileI > access after the OS is running, in which case it might make assumptionsoF > that the ISO9660 data is unchanged.  Of course really it would be on/ > an ISO9660 disc that contains only two files:i > - >         BOOTFILE              100,000 bytesm- >         ODS2FILE        9,100,000,000 bytes  > K > Since the console would never look inside ODS2FILE, it would never noticeu > changes. m  J Fred kindly explained that the disk will be an ODS2 drike 100%. It just soL happens that one file will contain data formatted in a FAT32 layout. So whenK the console looks at the boot block, is told to find its FAT file system at-D block XYZ which happens to reside somewhere in the ODS2 file system.  K I.E. ODS2 will have a container file that contains another OS's simple file:$ system for the purposes of booting.   D This is quite different from ODS2 residing inside a FAT partition or6 coexsiting with another file system on the same drive.   ------------------------------    Date: 30 Jul 2001 18:32:35 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS) H Message-ID: <y4ae1ml6n0.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  / JF Mezei <jfmezei.spamnot@videotron.ca> writes:p  2 > What good is your fancy remote system managementI > if you cannot issue the proper commands to the console and then ask thet > machine to boot ?   N A remote console is yet another issue. It doesn't necessarily require a serial
 line console.n   	Jan   ------------------------------  % Date: Mon, 30 Jul 2001 13:05:53 -0400f- From: JF Mezei <jfmezei.spamnot@videotron.ca>cC Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)o, Message-ID: <3B6593EB.116F2AAE@videotron.ca>   Fred Kleinsorge wrote:G > the EFI console meets ALL THE GOALS that we had for a common console.s  K But now that "we" is Compaq, do you think that EFI will also meet the goals 	 for NSK ?s  N > No, you will get menu like an old Alpha NT console (now that I've seen one).N > You get a list of things you can boot.  You also get other things you can do? > (like load a UNIX-like shell, or switch to a serial console).   H Please make sure that this "menu" can be permanently disabled and serialM console used by default for all pre-boot operations. If the machine powers upaJ with that silly menu and expects someone to press some key to switch it to. serial, then serial console will be worthless.  N > The consoles purpose in life should be simple and sweet:  Find the hardware,J > initialize it to a known state, load the OS, and get the h*ll out of the > way. O  N People in the VAX world are used to also getting hardware tests, being able toQ display system config, scan the scsi bus, set various boot flags and options etc.<  Q And lets not forget the ability to access console mode by pressing BREAK at OPA0:m  M <ALT-CTRL-DEL> is impossible to generate on a serial line, and if VMS on IA64sK even mentions those 3 keys, it will lose a lot of credibility. Those 3 keys D should be copywritten by Microsoft and only inflicted on MS systems.  4 > Do NOT confuse EFI with the BIOS found on PeeCees.  N When I power up a PC and it tells me to press some key inside of a few secondsH to access setup, isn't that the PC's equivalent of a console code ? MostK people call this BIOS.  What exactly ten is the difference between BIOS and  console (EFI) ?u  L > Dunno about NSK, but they tend to have pretty unique HW requirements.  VMSK > and Tru64 are talking to each other to make sure that we do not duplicatea
 > efforts.  M It is a shame that you are not talking to the NSK folks. If Compaq eventuallyeK intends to have Wildfire-like systems based on IA64 (which are not all thataN dissimilar to Tandem's multi processor architecture in some ways), wouldn't it) benefit from working with the NSK folks ?w  L If EFI causes problems because of its PC centric attitude, shouldn't the VMSL (and true 64) folks get together with NSK and design a Compaq common console3 that would be better suited to enterprise systems ?s  K If your console is unable to do much stuff except boot, does this mean thatsN VMS will gain the ability to perform low level formats, display SCSI bus scans	 etc etc ?    ------------------------------  % Date: Mon, 30 Jul 2001 10:55:54 -0400C- From: "Peter Weaver" <peter.weaver@stelco.ca>sY Subject: Re: Ken Olsen (and DEC History), was: Re: Escape sequences not filtered   in VMS 4 Message-ID: <5Ae97.273903$Z2.3310389@nnrp1.uunet.ca>  9 "Paul Williams" <flo@uk.thalesgroup.com> wrote in messagee, news:3B604F1C.32926E23@uk.thalesgroup.com... > Peter Weaver wrote:  >...B > > Whoever wants to host these can post a message here and I will3 > > e-mail a copy today to the first posting I see.p >,J > I can put these up on http://vt100.net if you like, Peter. I've also got >...  ! Paul has a copy of the files now.u   -- Peter WeaverJ Using a WIN NT/WIN 2000 box to manage your VMS systems is like towing your7 mechanic in a 5th wheel motor home behind your Porsche.c   ------------------------------  % Date: Mon, 30 Jul 2001 11:17:08 +0200o) From: "Pbo" <philippe.bocher@euriware.fr> - Subject: Re: login-f-clisymtbl error on Alphaj$ Message-ID: <3b6517d2@news.euriware>   mc sysgen sh clisymbtbl  try to increase7 hope this help  C "Rob Buxton" <rob.buxton@wcc.govt.nz> a crit dans le message news:r& 3b64df41.284326289@news.wcc.govt.nz...	 > Hi All,t > 9 > I vaguely seem to recall a thread on this a while back.  >t< > Saw the error LOGIN-F-CLISYMTBL on one of our Alpha Users. >fF > Running VMS 7.2-1 fairly up to date on Patches. (more scheduled this > weekend!)V >gH > Help / Message (from an Alpha) indicates on VAX that you need to check; > VIRTUALPAGCNT which is all very well except I'm on Alpha!F >o4 >  What are the areas that might need to be checked? >,# > As usual, many thanks in advance.m >a > Rob. >d >i   ------------------------------  # Date: Mon, 30 Jul 2001 13:02:25 GMTl= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)O- Subject: Re: login-f-clisymtbl error on Alphaw0 Message-ID: <009FFC5E.D0610CAE@SendSpamHere.ORG>  P In article <3b6517d2@news.euriware>, "Pbo" <philippe.bocher@euriware.fr> writes: >mc sysgen sh clisymbtbl >try to increase >hope this helpm  H The LOGIN-F-CLISYMTBL occurs when LOGINOUT is attempting to $EXPREG for G the symbol table.  Perhaps CLISYMTBL is too large.  The expansion is in F P1 space too so, while VIRTUALPAGECNT may not come into play, there is7 still a finite limit on the amount of region expansion.   H Take a look at both CTLPAGES and CLISYMTBL.  Publish your values here if you still have problems.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMd             J   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbest   ------------------------------  % Date: Mon, 30 Jul 2001 16:05:23 +0100  From: paul.beaudoin@hsbc.com1 Subject: Memo:  Re: benchmarking disk performanceyE Message-ID: <OF1DA3BFE0.B3E792D1-ON80256A99.00528522@systems.uk.hsbc>   I I have a little home-grown routine that measures write response times fornJ both indexed and sequential files. As it uses RPCC it is very accurate andH if you are into macro(32) should be hackable into something suitable forC individual purposes. If you (or anyone else) wants a copy, mail me.    Paul        D ********************************************************************B  This message and any attachments are confidential to the ordinaryB  user of the e-mail address to which it was addressed and may also>  be privileged. If you are not the addressee you may not copy,8  forward, disclose or use any part of the message or itsC  attachments and if you have received this message in error, pleasegB  notify the sender immediately by return e-mail and delete it from
  your system.e  =  Internet communications cannot be guaranteed to be secure or1A  error-free as information could be intercepted, corrupted, lost,m>  arrive late or contain viruses. The sender therefore does not?  accept liability for any errors or omissions in the context ofF?  this message which arise as a result of Internet transmission.e  lD  Any opinions contained in this message are those of the author and ?  are not given or endorsed by the HSBC Group company or office k=  through which this message is sent unless otherwise clearly yA  indicated in this message and the authority of the author to so u3  bind the HSBC entity referred to is duly verified.i  D ********************************************************************   ------------------------------  % Date: Mon, 30 Jul 2001 11:16:54 -0400 > From: "Koska, John C. (LNG-MBC)" <John.C.Koska@lexisnexis.com>5 Subject: RE: Memo:  Re: benchmarking disk performance M Message-ID: <3D35AD137AAAD411A6BA0008C7B1B12D01602229@MBCALBEXC03.BENDER.COM>u  C If you don' mind me asking, what type of storage have you measured?   D Brand (EMC, StorageWorks, etc.)?  JBOD?  RAID level?  Any host based( volume shadowing?  Controllers involved?   :) jck
 John Koska Matthew Bender & Co., Inc. -"   A Member of the LexisNexis Group
 1275 Broadwaye Albany, NY  12204s USAD 518-487-3255 John.C.Koska@lexisnexis.com   * "I post personal opinion only, and all the* disclaimers one could imagine apply.  That( includes, I speak for myself only and my* views in no way represent my employer(s)."   > -----Original Message-----> > From: paul.beaudoin@hsbc.com [mailto:paul.beaudoin@hsbc.com]& > Sent: Monday, July 30, 2001 11:05 AM > To: Info-VAX@Mvb.Saic.Comr2 > Subject: Memo: Re: benchmarking disk performance >  >  > 9 > I have a little home-grown routine that measures write s > response times for@ > both indexed and sequential files. As it uses RPCC it is very  > accurate and> > if you are into macro(32) should be hackable into something  > suitable forE > individual purposes. If you (or anyone else) wants a copy, mail me.w >  > Paul >  >  >  > F > ********************************************************************D >  This message and any attachments are confidential to the ordinaryD >  user of the e-mail address to which it was addressed and may also@ >  be privileged. If you are not the addressee you may not copy,: >  forward, disclose or use any part of the message or itsE >  attachments and if you have received this message in error, pleasetD >  notify the sender immediately by return e-mail and delete it from >  your system.- > ? >  Internet communications cannot be guaranteed to be secure or C >  error-free as information could be intercepted, corrupted, lost,I@ >  arrive late or contain viruses. The sender therefore does notA >  accept liability for any errors or omissions in the context of.A >  this message which arise as a result of Internet transmission.e >  RF >  Any opinions contained in this message are those of the author and A >  are not given or endorsed by the HSBC Group company or office e? >  through which this message is sent unless otherwise clearly >C >  indicated in this message and the authority of the author to so w5 >  bind the HSBC entity referred to is duly verified.r > F > ******************************************************************** >    ------------------------------  % Date: Mon, 30 Jul 2001 08:28:46 -0400t- From: David R Barnes <dbproductions@juno.com>i% Subject: memory for Alphaserver 4/200r> Message-ID: <20010730.082850.-385619.1.dbproductions@juno.com>  D I have a chance to pick up an Alphaserver 1000 4/200 with no memory.G Anyone know what ram this thing takes? Anything special about it? SeemstC like it needs it in banks of 5 simms (ecc?) I have some old Prioris  server memory? will this work?   Thanks for your help.h    (PS: Anyone have some for sale?)   David R Barnes dbproductions@juno.com  9 Vms and Unix guru! Also specializing in Linux and Netbsd!u Long Live VMS!  @ ________________________________________________________________ GET INTERNET ACCESS FROM JUNO!5 Juno offers FREE or PREMIUM Internet access for less!o0 Join Juno today!  For your FREE software, visit:  http://dl.www.juno.com/get/tagj.   ------------------------------  # Date: Mon, 30 Jul 2001 14:34:16 GMToF From: lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman)) Subject: Re: memory for Alphaserver 4/200C1 Message-ID: <Ife97.317$Yx2.6908@news.cpqcorp.net>   n In article <20010730.082850.-385619.1.dbproductions@juno.com>, David R Barnes <dbproductions@juno.com> writes:  E >I have a chance to pick up an Alphaserver 1000 4/200 with no memory.mH >Anyone know what ram this thing takes? Anything special about it? SeemsD >like it needs it in banks of 5 simms (ecc?) I have some old Prioris >server memory? will this work?s  A The 1000 (not the 1000A) does indeed need sets of 5 SIMMS, one ofc< which is for ECC.  The old part numbers from the Systems and Options Catalog are:  ? PB7MA-CB  32 MB 70 nS ( 8 MB SIMMS) (Golden Eggs says PB7MA-AB)d> PB7MA-CC  64 MB 70 nS (16 MB SIMMS)                        -AC> PB7MA-CD 128 MB 70 nS (32 MB SIMMS)                        -AD# PB7MA-CE 256 MB 70 nS (64 MB SIMMS)d  ? (There apparently was a 16 MB kit at one time, which would have @ used 4 MB SIMMs, but I'm not sure if anyone would want to bother< with SIMMs that small anymore, you would only be able to get/ a total of 64 MB by filling the entire system.)h  ? Unfortunately, I see some conflicting information.  The Systemsl? and Options Catelog says a kit contains "five industry-standard-@ SIMMS, the fifth SIMM in each kit is for ECC support".  However,: the AlphaServer 1000 / 1000A Owner's Guide Supplement says> "An ECC SIMM is not compatible with memory bank SIMMs.  Do not? place an ECC SIMM in a memory slot".  What I >THINK< this meansr> is that you can't take the ECC SIMMS from an 1000 and use them< in the memory bank slots of a later model 1000A, but I'm not absolutely certain.e  > I think it would be a good idea to find out where the original> memory went: or at least if you can get a look at the SIMMS to@ see if they were all identical.  Also check the Compaq web site,* many of the old manuals are still on-line.   -- n(  B. Z. Lederman   Personal Opinions Only  8  Posting to a News group does NOT give anyone permission8  to send me advertising by E-mail or put me on a mailing  list of any kind.  5  Please remove the "DISABLE-JUNK-EMAIL" if you have ai5  legitimate reason to E-mail a response to this post.-   ------------------------------    Date: 30 Jul 2001 08:26:37 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett):) Subject: Re: memory for Alphaserver 4/200n, Message-ID: <2droEhlIj8Yl@malvm5.mala.bc.ca>  2 In article <Ife97.317$Yx2.6908@news.cpqcorp.net>, L     lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman) writes:   > A > Unfortunately, I see some conflicting information.  The Systems,A > and Options Catelog says a kit contains "five industry-standardhB > SIMMS, the fifth SIMM in each kit is for ECC support".  However,< > the AlphaServer 1000 / 1000A Owner's Guide Supplement says@ > "An ECC SIMM is not compatible with memory bank SIMMs.  Do notA > place an ECC SIMM in a memory slot".  What I >THINK< this meanst@ > is that you can't take the ECC SIMMS from an 1000 and use them> > in the memory bank slots of a later model 1000A, but I'm not > absolutely certain., > D     I think the original intention was to use a stripped down moduleF for the ECC SIMM ( to save some money as it doesn't need all 9 bits ).> I believe that at some later point ( as memory priced declined@ perhaps ) they realized it was cheaper to just use the same part for the ECC SIMM.c  <     I don't know if this change was made before or after theD 1000s started shipping to customers. The Alphaserver 1000s I've seenC all use identical SIMMS in each of the 5 slots. "Industry Standard" > parity SIMMs can be used in both the "memory" and "ECC" slots.   ------------------------------  % Date: Mon, 30 Jul 2001 11:36:54 -0500z* From: WILLIAM WEBB <WWEBB1@email.usps.gov>) Subject: RE: memory for Alphaserver 4/200n- Message-ID: <0033000030773368000002L082*@MHS>A  ? =0AI believe that it's 72 pin 60 (and maybe 70) ns true parity.e3 Mixing of different memory speeds is to be avoided.a   WWWebb     > -----Original Message-----1 > From: Info-VAX-Request@Mvb.Saic.Com at INTERNETc% > Sent: Monday, July 30, 2001 8:34 AMnF > To: Webb, William W - Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET' > Subject: memory for Alphaserver 4/200  >2 >EF > I have a chance to pick up an Alphaserver 1000 4/200 with no memory.? > Anyone know what ram this thing takes? Anything special aboutl > it? SeemshE > like it needs it in banks of 5 simms (ecc?) I have some old Priorisl  > server memory? will this work? >T > Thanks for your help.o >l" > (PS: Anyone have some for sale?) >i > David R Barnes > dbproductions@juno.com >p; > Vms and Unix guru! Also specializing in Linux and Netbsd!  > Long Live VMS! > B > ________________________________________________________________  > GET INTERNET ACCESS FROM JUNO!7 > Juno offers FREE or PREMIUM Internet access for less!x2 > Join Juno today!  For your FREE software, visit:" > http://dl.www.juno.com/get/tagj. >=   ------------------------------  % Date: Sun, 29 Jul 2001 22:52:46 -0700r& From: Tom Crabtree <tccrab@sunset.net>+ Subject: Re: Min Mem on a  DEC 3300 for VMSr* Message-ID: <3B64F62D.94BE2AA8@sunset.net>  G The 3000-300 used 72 pin True Parity Simms, they should be installed int
 matched sets.pN Call Don Hyde at Hess Electronics in Tustin CA, he's got bags and bags of 32MBB simms that he's selling dirt cheap ($25 each last time I checked).  M In my experience, 64mb is about the minimum that you really want to have, andeM the more the merrier.  I've got 256mb in my 3000-300 and it runs OpenVMS 7.21 M quite happily.  Not as fast as a DS20 but for my modest needs it does the jobc
 quite nicely.o   Tom C. Neophyte OpenVMS abuserr   Robert Deininger wrote:6  C > In article <27JUL01.18193590@feda01.fed.ornl.gov>, Dave Greenwoodl > <greenwoodde@ornl.gov> wrote:  > L > > In a previous article, "Dijk, Jeroen van" <Jeroen.vanDijk@Getronics.com> > wrote:= > > > What is the minimum memory for VMS at a DECserver 3300?l; > > > I try it with 16 Mb, but that clearly was too little. < > > > What OS can I run on DECserver 3300 with 16 Mb memory? > > >oF > > > Before I'm going to buy the expensive and rare 64 Mb memory sets8 > > > I want to know that the minimum Memory for VMS is. > > >l@ > > > Please help me so I can boot my DEC server with a real OS. > >a9 > > Assuming that you really mean a DEC Alpha 3000-300...y > >wF > > I had 64MB on my 3400 and got tired of waiting for it to page whenI > > using Netscape.  I *think* VMS claims a minimum of 32Mb but of courset > > you can try what you want. > >OG > > Kingston is advertising 64Mb for $171 on their web page.  CamintonnsF > > also adverses 32Mb (although I don't know their price).  I presume? > > other vendors have new/used DEC/3rd-party memory available.n >eG > For a 3000-300 (if that's what he really meant), we bought 64 MB from0E > clearpoint for around $80 several months ago.  Used, and presumably  > subject to availability. >s > -- > Robert Deininger > rdeininger@mindspring.comy   --A -----------------------------------------------------------------  My father used to tell me,> "Son, there is nothing wrong with being scared. . . as long as5 you don't let it affect you until the danger is over. > Being hysterical is okay, too . . . afterwards and in private.A Tears are not unmanly . . . in the bathroom with the door locked.B; The difference between a coward and a brave man is mostly ad matter of timing"q  0       --------- Robert A. Heinlein -------------A -----------------------------------------------------------------t   ------------------------------  % Date: Mon, 30 Jul 2001 11:26:57 +0200e7 From: "Dijk, Jeroen van" <Jeroen.vanDijk@Getronics.com>i+ Subject: RE: Min Mem on a  DEC 3300 for VMSm> Message-ID: <2795B75EF003D311801A00A0C906B511011C64D8@CUCEXEC>   Yes, did mean the DEC 3000-300. A I will ask around to get the memory to update to 64mb or more.   n  X Still I'm interessed in hearing marketprices for those special 32mb simms from kingston.  I If you are running VMS on a 3300 I like to hear how much memory you have.l    5 To keep the discussion complet I'm quoting a article i  / Subject: SUMMARY: Memory type for DEC 3000/300 i From: Arno Hahma s/ Date: Mon, 06 Jul 1998 14:59:10 +0300 (EET DST)   C The DEC 3000/300 uses a special type of SIMM for the 32 MB modules.vC There are two possible sizes, 8 MB and 32 MB. The 8 MB is a normal,cB 72-pin, 36-bit (true parity), 70 ns or better DRAM SIMM. The 32 MBB modules are otherwise same, but they have a resistor, that is usedB to detect module size. Thus, the 32 MB SIMMs are somewhat special.? If normal SIMMs are used, they are incorrectly detected as 8 MBt modules, but still work ok.   C The special 32 MB SIMMs can be purchased at least from Kingston andsC Dataram and they cost a little more than normal SIMMs, in the rangea $170..200 for 64 MB.       -----Original Message------ From: Tom Crabtree [mailto:tccrab@sunset.net]s Sent: maandag 30 juli 2001 7:53c To: Info-VAX@Mvb.Saic.Comb* Subject: Re: Min Mem on a DEC 3300 for VMS    G The 3000-300 used 72 pin True Parity Simms, they should be installed ino
 matched sets.rN Call Don Hyde at Hess Electronics in Tustin CA, he's got bags and bags of 32MBB simms that he's selling dirt cheap ($25 each last time I checked).  M In my experience, 64mb is about the minimum that you really want to have, andfM the more the merrier.  I've got 256mb in my 3000-300 and it runs OpenVMS 7.21tM quite happily.  Not as fast as a DS20 but for my modest needs it does the jobu
 quite nicely.    Tom C. Neophyte OpenVMS abusero   Robert Deininger wrote:e  C > In article <27JUL01.18193590@feda01.fed.ornl.gov>, Dave Greenwoods > <greenwoodde@ornl.gov> wrote:  >TL > > In a previous article, "Dijk, Jeroen van" <Jeroen.vanDijk@Getronics.com> > wrote:= > > > What is the minimum memory for VMS at a DECserver 3300?e; > > > I try it with 16 Mb, but that clearly was too little.a< > > > What OS can I run on DECserver 3300 with 16 Mb memory? > > >iF > > > Before I'm going to buy the expensive and rare 64 Mb memory sets8 > > > I want to know that the minimum Memory for VMS is. > > >c@ > > > Please help me so I can boot my DEC server with a real OS. > >:9 > > Assuming that you really mean a DEC Alpha 3000-300...l > > F > > I had 64MB on my 3400 and got tired of waiting for it to page whenI > > using Netscape.  I *think* VMS claims a minimum of 32Mb but of course  > > you can try what you want. > > G > > Kingston is advertising 64Mb for $171 on their web page.  CamintonneF > > also adverses 32Mb (although I don't know their price).  I presume? > > other vendors have new/used DEC/3rd-party memory available.n > G > For a 3000-300 (if that's what he really meant), we bought 64 MB from E > clearpoint for around $80 several months ago.  Used, and presumablym > subject to availability. >d > -- > Robert Deininger > rdeininger@mindspring.com    --A -----------------------------------------------------------------  My father used to tell me,> "Son, there is nothing wrong with being scared. . . as long as5 you don't let it affect you until the danger is over.s> Being hysterical is okay, too . . . afterwards and in private.A Tears are not unmanly . . . in the bathroom with the door locked.P; The difference between a coward and a brave man is mostly ab matter of timing"e  0       --------- Robert A. Heinlein -------------A -----------------------------------------------------------------*   ------------------------------  % Date: Mon, 30 Jul 2001 11:17:15 +0100n* From: "Richard Brodie" <R.Brodie@rl.ac.uk>+ Subject: Re: Min Mem on a  DEC 3300 for VMSa, Message-ID: <9k3c7f$1nvs@newton.cc.rl.ac.uk>  8 "Dave Greenwood" <greenwoodde@ornl.gov> wrote in message, news:27JUL01.18193590@feda01.fed.ornl.gov...  D > I had 64MB on my 3400 and got tired of waiting for it to page whenG > using Netscape.  I *think* VMS claims a minimum of 32Mb but of coursem > you can try what you want.  E IIRC, OpenVMS Alpha initially required a minimum of 32MB but that wasbC always very tight. For current versions the formal minimum is 64MB.e& Don't even think of running with less.   ------------------------------  % Date: Mon, 30 Jul 2001 07:54:03 -0700r' From: David Mathog <mathog@caltech.edu>eH Subject: Re: Now we're cooking with gas. (was:  Wailing and moaning....)+ Message-ID: <3B65750B.AD5D552A@caltech.edu>p   jlsue wrote:  B > And I certainly hope that lower-cost IA64 systems running VMS in# > VMSclusters will help that along.t  K At the moment the IA64 based systems cost more than DS10s.  Perhaps if theydQ someday become a mass market item, and that's only going to happen if we see them-P on desktops, then the cost will come down.  In the meantima they are priced like! Intel's very expensive Xeon cpus.x   Regards,   David Mathog mathog@caltech.edu   ------------------------------    Date: 30 Jul 2001 07:20:32 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)g& Subject: Re: Ont "The Inquirer" today.3 Message-ID: <fujCh6HS+$6U@eisner.encompasserve.org>e   Indeed,o  ( 	http://www.theinquirer.net/30070109.htm  H does indicate a cheerier view of porting VMS.  This would seem to result9 from a Compaq response.  So, reading the article, either:D  B 	The Inquirer couches even plain documents in mysterious language.   or else:  > 	Compaq has figured out the Inquirer game and knows to present> 	something as under-the-table data to increase coverage by the= 	Inquirer (even if a lot of the information was already known@ 	to readers of the group).  E If it is the latter, I would say that at least for the Inquirer venueS: Compaq Marketing (VMS Marketing?) has started to "get it".   ------------------------------  % Date: Mon, 30 Jul 2001 09:42:05 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>q& Subject: Re: Ont "The Inquirer" today.( Message-ID: <9k3o8i$7hf$1@pyrite.mv.net>  F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:fujCh6HS+$6U@eisner.encompasserve.org...i	 > Indeed,  >a) > http://www.theinquirer.net/30070109.htm* >*J > does indicate a cheerier view of porting VMS.  This would seem to result; > from a Compaq response.  So, reading the article, either:d >sC > The Inquirer couches even plain documents in mysterious language.e  ; 'Mysterious'?  Only if one can't recognize sarcasm as such.s   > 
 > or else: >s? > Compaq has figured out the Inquirer game and knows to presenti? > something as under-the-table data to increase coverage by thei> > Inquirer (even if a lot of the information was already known > to readers of the group).o > G > If it is the latter, I would say that at least for the Inquirer venue < > Compaq Marketing (VMS Marketing?) has started to "get it".  L Leaving aside the fact that making any significant difference to VMS at thisI point would require something more like a Divine Transformation than just I 'starting to get it' on the part of Compaq Marketing, just what makes youeE believe that Compaq Marketing had any hand in making this informationh available to The Inquirer?   - bill   ------------------------------  % Date: Mon, 30 Jul 2001 12:29:43 -0400h- From: JF Mezei <jfmezei.spamnot@videotron.ca> & Subject: Re: Ont "The Inquirer" today., Message-ID: <3B658B74.19A408D2@videotron.ca>   Larry Kilgallen wrote:1 >         http://www.theinquirer.net/30070109.htm8 > J > does indicate a cheerier view of porting VMS.  This would seem to result: > from a Compaq response.  So, reading the article, either  N What is interesting is that Compaq still makes public claims that VMS runs 66%K of the world's funds transfers. Sun will have a field day with this one thetM day ST400 is officially desupported and Sun will have SWIFT solutions and VMS  will have none.l  N Perhaps Compaq means that VMS runs 66% of the find transfers in New York City.L But that is not the "world". Typically, one has a national clearinghouse andK one has SWIFT for interbank transfers around the world. So when Compaq uses_J "world's funds transfers", it really means SWIFT, and it should stop usingN this because any banker involved in funds transfers knows that SWIFT announced. the de-support of VMS as a platform years ago.   ------------------------------    Date: 30 Jul 2001 13:53:18 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>jK Subject: Re: OpenVMS on IPF (was re: IPF already needs a face-lift for VMS)cH Message-ID: <y4y9p68wgh.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  0 "mulp" <michaelpettengill@earthlink.net> writes:  M > PAL is cheaper than doing a change mode kernel and then raising IPL to locknG > out interrupts  - remember that in PAL mode, there are no interrupts.   L You need inter-thread synchronization with INSQUE et al., not locking out ofH interrupts. LLK/STC are quite suited to the former without requiring the latter.    	Jan   ------------------------------    Date: 30 Jul 2001 13:46:25 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>B% Subject: Re: Oracle file size and VMS H Message-ID: <y41ymyabce.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  4 hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes:  G >   The OpenVMS version of the C stat() call presently uses a longword M >   for off_t.   [...] . >   I'll pass the request along to the C team.  G I think Solaris has extended versions of all the usual C stuff for filehE I/O. Possibly a way that could be followed (no need to re-invent this.A particular wheel in an incompatible manner if it can be avoided).t   	Jan   ------------------------------  % Date: Mon, 30 Jul 2001 08:48:59 -0300 + From: <fabio_compaq@ep-bc.petrobras.com.br>m% Subject: Re: Oracle file size and VMSeL Message-ID: <OFA6C170F0.1DA7CBFB-ON03256A99.0040C9A5@ep-bc.petrobras.com.br>  G Solaris has the VERITAS Volume Manager..... OpenVMS doest have anything  similar, sot> the database files must be distributed in  a pool of disks....       Regards    FC    m                                                                                                              Im                     Jan Vorbrueggen                                                                          lm                     <jan@mailhost.neuroinformatik.ruhr-uni-        Para:   Info-VAX@Mvb.Saic.Com             im                     bochum.de>                                     cc:                                       -m                                                                    Assunto:     Re: Oracle file size and VMS -m                     30/07/2001 08:46                                                                         rm                     Responder a Jan Vorbrueggen                                                              pm                                                                                                              lm                                                                                                              s        4 hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes:  F >   The OpenVMS version of the C stat() call presently uses a longword >   for off_t. [...]o. >   I'll pass the request along to the C team.  G I think Solaris has extended versions of all the usual C stuff for file E I/O. Possibly a way that could be followed (no need to re-invent this A particular wheel in an incompatible manner if it can be avoided).n        Jan   ------------------------------  # Date: Mon, 30 Jul 2001 10:05:28 GMT ' From: Tim Ellis <nospam@newsranger.com>'& Subject: Print Queue's on IP Addresses6 Message-ID: <Ija97.11256$ar1.32937@www.newsranger.com>  G Following a Network reorganisation we now have some printers set up as    ? $INITIALIZE/QUEUE/PROC=tcpip$telnetsym/on="aaa.bbb.ccc.ddd:eee"0  I where aaa.bbb.ccc.ddd is an IP address and eee is the port number for then printer.  O Unfortunately some (but not all!) of the printers set up this way are no longereN interpretting the <TAB> character, leaving all our nicely indented source code left justified...0  N I was hoping that toggling "SET PRINTER/TAB" or "SET PRINTER/NOTAB" might be aO fix for this but that requires a printer name, which I don't have - the commands won't take the IP address...  : Anyone know how to get our <TAB>'s back in this situation?   --  $ Tim Ellis  CSC Computer Sciences Ltd% Speaking for himself, not the companyo   ------------------------------  # Date: Mon, 30 Jul 2001 14:35:09 GMTa  From: jlsue <jlsuexxxz@home.com>- Subject: Re: Selling VMS to another company ?s8 Message-ID: <saramtsm9n52dt866rnts58bcebcd50m0n@4ax.com>  ( On Sat, 28 Jul 2001 10:03:46 GMT, "mulp"( <michaelpettengill@earthlink.net> wrote:   >a. >"jlsue" <jlsuexxxz@home.com> wrote in message3 >news:ne34mtopt3eou6frh2lhrcpv9m7j8ano05@4ax.com...v4 >> And being successful financially is what we need. >>G >> We'll all just have to wait and see if this is the path to financiali >> success.  > J >Is this using industry standard parts that are made by someone other than >Compaq, like Intel? >_M >If yes, then forget it - Dell will strip off the profitable business and getN' >a higher gross margin with lower SG&A.t >c  ? Well, our current "Industry Standard" servers aren't completely B off-the-shelf parts.  There's quite a lot of engineering that goes? into the complete systems to make them perform well, as well ase2 providing stability (such as it is under Windows).  F I'm not really in the box part of the business, so I don't really knowC what Dell might have that compares to our 8-way servers or how well 
 they compare.n   ------------------------------  % Date: Mon, 30 Jul 2001 19:25:06 +0200m& From: John McLean <mcleanj@dplanet.ch>- Subject: Re: Selling VMS to another company ?b* Message-ID: <3B659872.5D5E6ED8@dplanet.ch>   "Doc.Cypher" wrote:t   (snip)  M > Since the deed has been done and the Alpha platform must now serve its timesD > on death row, perhaps we should return to berating the Q for theirF > marketing incompetence. The handling of the Alpha decision is simply; > another example of their ability to fire off footbullets.w  A And if they are not careful, it will be both barrels, both feet !,     John McLeann     >  > Doc. > - --8 > The bigger the humbug, the better people will like it.M > ~ Phineas Taylor Barnum.                              http://vmsbox.cjb.neti >e   ------------------------------  % Date: Mon, 30 Jul 2001 10:55:57 -0400 - From: "Peter Weaver" <peter.weaver@stelco.ca>a Subject: Re: Sixels 4 Message-ID: <e0f97.273909$Z2.3310695@nnrp1.uunet.ca>  5 "David Cressey" <david@dcressey.com> wrote in messagev- news:T2Z77.32$Iw2.586@petpeeve.ziplink.net...  >...L > I wrote a little code in Turbo Pascal for the Rainbow, to translate SIXELS > into a form that I could push J > to the LA-50.  IIRC,  the LA-50s internal graphics code was a variant on	 > Sixels.r >...  L I have no idea now how I created the SIXEL file. I think I just printed to aH text file then used Kermit to get the file to a VAX. My Rainbow is stillI sitting in the basement, I haven't turned it on in the last 8 or 9 years.    -- Peter WeaverJ Using a WIN NT/WIN 2000 box to manage your VMS systems is like towing your7 mechanic in a 5th wheel motor home behind your Porsche.u   ------------------------------  # Date: Mon, 30 Jul 2001 09:34:24 GMTr- From: Stefan.Bill@soudronic.com (Stefan Bill)-" Subject: Soft font modules / DCPS?/ Message-ID: <3b652a12.12843257@news.cis.dfn.de>g  = In the system manager Guide to DECprint supervisor there is a < reference to a file SYS$LIBRARY:cps$ansi_fonts.tlb.This file@ contains "Soft Font Modules" with which LN03 character fonts can be emulated.  9 The file was not created/copied during DCPS installation.r; Does someone have this file, or knows where one can get it?o  
 Thank you.  - regards, Stefan   ------------------------------  % Date: Mon, 30 Jul 2001 13:56:10 -0400-0 From: Paul Anderson <paul.r.anderson@compaq.com>& Subject: Re: Soft font modules / DCPS?; Message-ID: <300720011356104717%paul.r.anderson@compaq.com>C  ; In article <3b652a12.12843257@news.cis.dfn.de>, Stefan Bill1" <Stefan.Bill@soudronic.com> wrote:  ? > In the system manager Guide to DECprint supervisor there is am> > reference to a file SYS$LIBRARY:cps$ansi_fonts.tlb.This fileB > contains "Soft Font Modules" with which LN03 character fonts can > be emulated. > ; > The file was not created/copied during DCPS installation.c= > Does someone have this file, or knows where one can get it?   G The SoftFont kits, now retired and no longer sold, emulate the fonts in0A LN03 and DEClaser printer font cartridges.  Fonts are sent to theeF printer with every print job, which is not terribly efficient but gaveC those wanting LN03/DEClaser font compatibility a way to print usingME such fonts.  There were four separate kits each providing a number oft fonts.   Paul   -- u  Paul Anderson   OpenVMS Engineeringw   Compaq Computer Corporationr   ------------------------------    Date: 30 Jul 2001 02:05:08 -0700, From: iskandar@measat.com (Iskandar Hussein)= Subject: Standalone Backup and Restore on VAXStation 4000 90Ae; Message-ID: <28a7709.0107300105.8d0e7a7@posting.google.com>   C I've been having problem with my VAXStation 4000 90A. The hard disksA crashes and it took me some time to figure out how to restore theoD workstation.  I've look up on comp.os.vms and found some lead on howC to solve the problem. However, the version use in the discussion inr@ the user group is VMS 5.5 whilst my system is using VMS VAX 6.2.  A Using the example i got in the discussion with minor adjustment IeE manage to bring up the workstation and I would like to share with thea; group on how I solve the problem.  Below are the procedure.   ! System involved : OpenVMS VAX 6.22! Workstation : VaxStation 4000 90Aa Problem : Hard disk crashed. t   Solution Steps:tC 1.  Make sure you have the standalone backup tape and system backupo/ tape If you don't have then it is out of story..E 2.  Replace the hard drive with a new one (I'm using the RZ26L-E 3.5"n Form Factor 1.5 GB)"A 3.  Use the standalone tape to boot the systems to do that at >>>h prompt typei:     >>> boot mka500: (if you use mka500 for your logicals)E     This process will take some time to complete (estimate time is 20D minutes)F 4.  Once completed you will get dollar prompt. At that prompt take out; the standalone backup and put in the system backup and type +     ? backup/init/image/ver mka500: dka300:a>       (mka500 is the tape drive while dka300 is the hard disk)B 5.  This process will take somewhere between 1 hour to 1.5 hours. C 6.  Once complete there will be a message asking us to hit the halt E button if we want to go to system boot or type "yes" if we want to do E another standalone backup. In this case I press the halt button to gob to system boot.rE 7.  Once you hit the halt button a ">>>" prompt will appear.  At thish prompt, type     >>> boot dka300. dF 8.  The system will boot normally, follow the message display to error	 messages. B 9.  Once boot it will asked for username and password.  The systemD will copy whatever content you have in the system backup. So use theA system username and password that you use when you did the system  backup before this.-A 10. You'll get the system prompt.  The system is not yet build ittE decnet address and workstation name. To do that at the system prompt,  type  . system> set default sys$sysdevice:[sgs.config]A sysgem> @sgs$customize_client <workstation_name> <decnet address>   C 11.  The system will then process the command and we auto-reboot at  the end of the process.r  5 12. Once reboot you'll get another ">>>" prompt, type      >>> boot dka300   D 13. Again key in system username and system password.  At the system prompt in the Decterm type in-. system> set default sys$sysdevice:[sgs.config] system> @sgs$config_ucxc  F This command will reload back all the ucx table entry to the systems.   / 14. Once complete the system is ready to use.     D Thank to Simon Clubley of simon_clubley@remove_me.excite.com for the tip.  C Hope this tip might be useful for anybody who need to restore theirw systems.   Regards    Iskandar Hussein e Computer Systems Engineeri Measat Satellite Control Centero Gunung Raya, Mukim Ulu MelakaC 07000 Langkawi, Kedah Darulamand
 Malaysia.  Email: iskandar@measat.com Ph: 604-9698627c Fax: 604-9662824   ------------------------------    Date: 30 Jul 2001 12:59:40 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER)+ Subject: Re: Sun goes after Alpha user baseh* Message-ID: <3b653e1c$1@news.kapsch.co.at>  \ In article <3B61B2F8.5581C89A@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: >Peter LANGSTOEGER wrote:nO >> And I cannot imagine why one VMS customer which is forced to migrate off VMSlK >> by Q, will want to stay with COMPAQ at all, too. So, a lost VMS customer0' >> is a lost Q customer. What a DEJA VUs >a >Who said "forced to migrate" ?t >aM >If Compaq makes it very interesting for a customer to switch to NT, then them( >customer is likely to stay with Compaq.  H Iff NT is in the scope of acceptable products (which because of MegaShitF it is not) then this may happen. But I also don't see Q making NT veryJ attractive either. I only see Q making it's own products (VMS, Alpha, ...)4 very inattractive. And that's very silly in my eyes.  O >Compaq is very aware that forcing customers off of VMS means that it will lose J >the majority of thsoe customers. So I strongly suspect that it has a moreO >profitable strategy of LURING customers to NT instead of forcing them off VMS.c  F Iff a IT monoculture will be the future, then Q might have a chance toI make this happen. But as I understand it, most of the people of the worldnN will want to do everything to avoid monoculture in every aspect of their life.  L >This is why Compaq is giving just enough to VMS to make customers confidentG >that compaq isn't out to kill VMS, all the while ensuring that the VMSeD >customer base doesn't grow and that VMS doesn't become too popular.  G For the last year, I would have agreed with you. Since 25-Jun-2001 I no:K longer agree with this statement. Q _is_ out to killing their own products.y  N >                                                                     The moreO >time Compaq has, the more time there is to develop the serious applications on0N >NT that will give VMS customers a better solution with more features and moreO >importantly with features needed "today" , available on the NT version but not  >available on VMS.  H Serious applications on NT lack a serious base beneath. Namely a seriousF opsys (which NT might become in a decade or so) and a serious producerM company (which only happens if M$ gets destroyed and someone else takes over)d  M >Just because Palmer failed in his premature and too quickly executed attemptsL >at migrating customers away from VMS doesn't automatically mean that a well> >thought out and patient longer term strategy would also fail.   Time will tell   -- r< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888h< <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------    Date: 30 Jul 2001 13:33:17 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>o+ Subject: Re: Sun goes after Alpha user baseiH Message-ID: <y47kwqabya.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  / JF Mezei <jfmezei.spamnot@videotron.ca> writes:r  N > So while converting 10% of VMS customers may not yield a 10% increase in theP > NUMBER of NT customers, it may mean that the profits those customers generatedN > are simply moving from VMS to NT and Compaq can claim a generous increase inH > NT profits (since it has gone very very little to substantial profits,( > increased average NT margins etc etc).  J That won't work. Those people migrating to WNT also expect to only pay theL cut-throat WNT prices, especially on the hardware. After all, even they know# they are getting much less value...u   	Jan   ------------------------------  % Date: Mon, 30 Jul 2001 14:25:26 +0100 0 From: andrew harrison <andrew.nospam@uk.sun.com>+ Subject: Re: Sun goes after Alpha user base,* Message-ID: <3B656046.35C733AE@uk.sun.com>   Newbie JrSysAdmin wrote: >  > fabio compaq@ep-bc.petrobras.com.br wrote in message news:<OF102DC867.54EBEE45-ON03256A95.00629221@ep-bc.petrobras.com.br>...-J > > Sun won here ......  5 x E-10000 to substitute more than 25 Alphas and > > Vaxes and otherrF > > RISC machines in our SAP project .... my countdown to turn off  my > > Alphaservers systems isg  H > i hope you got a good price on those 10ks, 'cuz they're old-news slow.  > Really, so where does that put WildFire, out of date before it was launched. :):):):)     Regards  Andrew Harrisonc Enterprise IT Architecte   ------------------------------  % Date: Mon, 30 Jul 2001 10:54:41 -0400 + From: "Main, Kerry" <Kerry.Main@compaq.com>n+ Subject: RE: Sun goes after Alpha user basedR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4D49534@kaoexc01.americas.cpqcorp.net>   Andrew,e  F >>> Really, so where does that put WildFire, out of date before it was launched. :):):):)<<   Hey, nice zing. :-)a  G How about this one - checkout the original SPARC III announcement date:kJ http://www.sun.com/smi/Press/sunflash/9710/sunflash.971006.1.html (October 6, 1997)J "The UltraSPARC-III microprocessor is expected to sample during the summer of 1998"  L Now, tell us again how the SPARC III will be based on latest technologies ..   :-)v   Regards,    
 Kerry Main Senior Consultant. Compaq Canada Corp.c Professional Servicese Voice: 613-592-4660  Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----7 From: andrew harrison [mailto:andrew.nospam@uk.sun.com]5 Sent: July 30, 2001 9:25 AM@ To: Info-VAX@Mvb.Saic.Comu+ Subject: Re: Sun goes after Alpha user base-     Newbie JrSysAdmin wrote: > 6 > fabio compaq@ep-bc.petrobras.com.br wrote in messageH news:<OF102DC867.54EBEE45-ON03256A95.00629221@ep-bc.petrobras.com.br>...J > > Sun won here ......  5 x E-10000 to substitute more than 25 Alphas and > > Vaxes and other F > > RISC machines in our SAP project .... my countdown to turn off  my > > Alphaservers systems is   H > i hope you got a good price on those 10ks, 'cuz they're old-news slow.  > Really, so where does that put WildFire, out of date before it was launched. :):):):)     Regards  Andrew Harrison. Enterprise IT Architect    ------------------------------  % Date: Mon, 30 Jul 2001 10:48:38 +0100 % From: Alan Greig <a.greig@virgin.net>  Subject: Sun keep 'em coming8 Message-ID: <kmaamtgekkbqacp9npsbev30d3apgr7376@4ax.com>  > Last week I received a postcard from Sun saying "Dumped? AlphaD recovery campaign from Sun".  Today I've received another which saysD "Abandoned, rejected let down? Alpha recovery campaign from Sun". OnE the flip side it has a quote from ZDNET (the previous one had a quote B from CW360). I'e also received a Sun offers brochure. All of these" addressed to "VMS Systems Manager"  B So it looks like Sun has a series of these postcards (at least twoD certainly) going out for maximum impact. Meanwhile still no official1 written communication from Conpaq. So far that's:l   Sun 3	Conpaq 0 -- Alan   ------------------------------  % Date: Mon, 30 Jul 2001 11:58:37 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>u  Subject: Re: Sun keep 'em coming, Message-ID: <3B65842C.CEFC5059@videotron.ca>   Alan Greig wrote:cD > So it looks like Sun has a series of these postcards (at least twoF > certainly) going out for maximum impact. Meanwhile still no official3 > written communication from Conpaq. So far that's:c >  > Sun 3   Conpaq 0    K Sun is eager to win your business. Compaq doesn't care about your business.e Take the hint.  G I wonder if Compaq's "commodity" mentality is going to hurt it with thetL small/medium customers, not worthy of having had a visit from Compaq and notH getting any information. Remember that prior to the Digital acquisition,N Compaq only had relationships with the largest customers in a region. The restT were anonymous buyers that bought through retailers who bought through distributors.   ------------------------------    Date: 30 Jul 2001 09:27:35 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)i  Subject: Re: Sun keep 'em coming, Message-ID: <9T98ddNXrMuS@malvm5.mala.bc.ca>  - In article <3B65842C.CEFC5059@videotron.ca>,  1   JF Mezei <jfmezei.spamnot@videotron.ca> writes:r   > I > I wonder if Compaq's "commodity" mentality is going to hurt it with the N > small/medium customers, not worthy of having had a visit from Compaq and not > getting any information.  L     I'd expect so. I suspect there will be a substantial number of customersP who neither fit the model of being big enough for Compaq to bother communicatingO with nor regular followers of newsgroups and other such sources of information.vN Those folks are only going to know what they hear from the press ( and Sun ), / neither a very reliable source of information. a     1 > Remember that prior to the Digital acquisition,rP > Compaq only had relationships with the largest customers in a region. The restV > were anonymous buyers that bought through retailers who bought through distributors.  Y     For a number of years prior to the acquisitions this was Digitals business model too.-U I think the last time I had any direct dealings with anyone from Compaq sales was formU a VaxServer 4000/200 ( early 90s? maybe ), all our Alphas have been purchased througho 3rd parties.   ------------------------------  % Date: Mon, 30 Jul 2001 11:15:37 +0100 % From: Alan Greig <a.greig@virgin.net>e" Subject: The death of Storageworks8 Message-ID: <pbbamt4vg2o7vsusbkr42h2b8r6o5hphoe@4ax.com>  E I'm just trying to think through the financial logic of de-supportinglA most of the Storageworks products. Nobody can expect a company ton@ support old products for ever. There must come a point where theC service revenue from the few remaining customers declines below therF level where it is not economical to support the product in maintenance mode.n  F However as Conpaq have just announced the retirement of, what seems to@ be, most of the currently supported Storageworks controllers youE assume they think they can save money by doing so. Surely the revenueo9 stream from support contracts for the HSZ70 must still be D considerable? I find it difficult to believe this is unprofitable so@ why kill it.? Then there's the RA3000/HSZ22 which still lists onE Conpaq's Storageworks pages as "the entry level RAID controller". CaneF a product which is still on sale really have so little support revenue= that it loses money? Leave aside the morals of desupporting ae1 controller before you've even stopped selling it..  C Then Conpaq continually tells us that both Storageworks and servicerD revenue are highly profitable and immediately strikes a blow at bothD these segments. Who'd want to buy a brand new controller from ConpaqB when they've just demonstrated it's likely to be supported for twoB years at the most? Knowing that whatever you bought from DEC wouldA likely be supported for ten years or so was a big plus. Do Conpaqo understand this?  C Or is what happened simply this: Conpaq had to make X redundancies.oA These were split up regardless of the profitability of a group too> avoid decimating the Wintel faction where the big money lossesC actually are. Thus Storageworks lost a lot of folks and the supportSD had to go. Conpaq assume we'll all be good little boys and girls andF upgrade immediately to an HSG80 so they get to make redundancies, dropA products and make more money. I don't think it will work somehow.n  E Meanwhile I called Conpaq and asked for an assurance that they do notfC intend dropping support for the HSZ80 any time soon. Nobody has yet $ been able to give me that assurance.  A The number of questions I have outstanding grows almost daily andtC Conpaq's responses are, at best, "we'll get back to you". Meanwhile6D Sun's motto seems to be "Make hay while the Sun shines" as brochures$ and postcards drop through the door.  D All together now: "Downsize, Rightsize, Capsize" (anon DEC engineer) -- Alan   ------------------------------  % Date: Mon, 30 Jul 2001 08:19:47 -0300 + From: <fabio_compaq@ep-bc.petrobras.com.br>e& Subject: Re: The death of StorageworksL Message-ID: <OFB07CC348.4C6F415D-ON03256A99.003DF2C5@ep-bc.petrobras.com.br>  H In my personal opinion, since Compaq made the agreement with IBM to sell Sharks,eD I tought would be better for CPQ to dissociate the Storage Business, together with IBM,D and create a new storage company. What can happen now is to sell the Storage BusinessF to DNPG, because there is the convergence of data networks and storage networksG in the future.... May be DNPG could be a CISCO concurrent. Small, but aa concurrent.a   Regardsw   FC    S                                                                                    tS                     Alan Greig                                                     tS                     <a.greig@virg        Para:   Info-VAX@Mvb.Saic.Com             aS                     in.net>              cc:                                       iS                                          Assunto:     The death of Storageworks    eS                     30/07/2001                                                     sS                     07:15                                                           S                     Responder a                                                    cS                     Alan Greig                                                      S                                                                                    wS                                                                                    l          E I'm just trying to think through the financial logic of de-supportingaA most of the Storageworks products. Nobody can expect a company to @ support old products for ever. There must come a point where theC service revenue from the few remaining customers declines below the F level where it is not economical to support the product in maintenance mode..  F However as Conpaq have just announced the retirement of, what seems to@ be, most of the currently supported Storageworks controllers youE assume they think they can save money by doing so. Surely the revenue 9 stream from support contracts for the HSZ70 must still be D considerable? I find it difficult to believe this is unprofitable so@ why kill it.? Then there's the RA3000/HSZ22 which still lists onE Conpaq's Storageworks pages as "the entry level RAID controller". CaneF a product which is still on sale really have so little support revenue= that it loses money? Leave aside the morals of desupporting ae1 controller before you've even stopped selling it.   C Then Conpaq continually tells us that both Storageworks and service D revenue are highly profitable and immediately strikes a blow at bothD these segments. Who'd want to buy a brand new controller from ConpaqB when they've just demonstrated it's likely to be supported for twoB years at the most? Knowing that whatever you bought from DEC wouldA likely be supported for ten years or so was a big plus. Do Conpaqp understand this?  C Or is what happened simply this: Conpaq had to make X redundancies.bA These were split up regardless of the profitability of a group toy> avoid decimating the Wintel faction where the big money lossesC actually are. Thus Storageworks lost a lot of folks and the supportcD had to go. Conpaq assume we'll all be good little boys and girls andF upgrade immediately to an HSG80 so they get to make redundancies, dropA products and make more money. I don't think it will work somehow.r  E Meanwhile I called Conpaq and asked for an assurance that they do notrC intend dropping support for the HSZ80 any time soon. Nobody has yeti$ been able to give me that assurance.  A The number of questions I have outstanding grows almost daily andcC Conpaq's responses are, at best, "we'll get back to you". MeanwhileyD Sun's motto seems to be "Make hay while the Sun shines" as brochures$ and postcards drop through the door.  D All together now: "Downsize, Rightsize, Capsize" (anon DEC engineer) -- Alan   ------------------------------  % Date: Mon, 30 Jul 2001 08:11:45 -0700C' From: David Mathog <mathog@caltech.edu>l& Subject: Re: The death of Storageworks+ Message-ID: <3B657931.2B5DF4A1@caltech.edu>0   Alan Greig wrote:9  G > I'm just trying to think through the financial logic of de-supporting0C > most of the Storageworks products. Nobody can expect a company tofB > support old products for ever. There must come a point where theE > service revenue from the few remaining customers declines below thevH > level where it is not economical to support the product in maintenance > mode.M >uH > However as Conpaq have just announced the retirement of, what seems toB > be, most of the currently supported Storageworks controllers youG > assume they think they can save money by doing so. Surely the revenueq; > stream from support contracts for the HSZ70 must still beeF > considerable? I find it difficult to believe this is unprofitable soB > why kill it.? Then there's the RA3000/HSZ22 which still lists onG > Conpaq's Storageworks pages as "the entry level RAID controller". CaneH > a product which is still on sale really have so little support revenue? > that it loses money? Leave aside the morals of desupporting ah3 > controller before you've even stopped selling it.s  I Q management wasn't sure that they'd succeeded in convincing all of theire enterprise customersI that  Compaq was not fit to service this market segment.  By desupportingn a wide assortmenteE of mission critical storage hardware they will surely accomplish thisr long sought goal.h  E Of course, the next part of their master plan, migrating all existingn enterprise users to Ipaq's, is still going to be a hard sell!   Regards,   David Mathog mathog@caltech.edu  T ************************************************************************************   *ta RIH Compaq                                                                                      *S  T ************************************************************************************   ------------------------------    Date: 30 Jul 2001 15:50:04 -00004 From: Doc.Cypher <Use-Author-Address-Header@[127.1]>& Subject: Re: The death of Storageworks6 Message-ID: <20010730155004.12395.qmail@nym.alias.net>  " -----BEGIN PGP SIGNED MESSAGE-----  = On Mon, 30 Jul 2001, David Mathog <mathog@caltech.edu> wrote:e   >* >RIH Compaqa >*  - Jbhyq gung creuncf fgnaq sbe Ebg Va Uryy? ;-)e     Doc. - -- h6 The bigger the humbug, the better people will like it.K ~ Phineas Taylor Barnum.                              http://vmsbox.cjb.nets   -----BEGIN PGP SIGNATURE-----r Version: 2.6.2  @ iQEVAwUBO2SVcsriC3SGiziTAQFeAAf9FdNI/s4NdkZjbQqmR5XJXZi01+UdDr/j@ nNr2XJ/iQqpQ9qrkyW0x98TgZrEmKlZVTye1acANTWG2HSymEBS1+e2lC+4s/r5j@ qL1zdJgzpUhCpxHTWtZAJJBEWxOoqoQHXFUGWS4xcBX9v8kIQHdWty5Gxe2BtwDm@ XlmSGEV91428Frd5gPzCuAgyyRDkXd7emBdmA0W3VIPHpX25RM/FO7iJ5vY8dMcA@ aiknwXJ63TwkmAy0G3YFkGj/iCuSecwvnQMhFzcBq3C9KPiGekgp+XKKRTmTZYK48 DOPAcnj6ik30TDl7x415eXz529EuIi+VDvNh5lD1sooJrAu9UgAFEQ== =zl/q  -----END PGP SIGNATURE-----1   ------------------------------  % Date: Mon, 30 Jul 2001 16:04:27 +0100-% From: Alan Greig <a.greig@virgin.net>J& Subject: Re: The death of Storageworks8 Message-ID: <pgtamtk6eus140hopovtf773td8oqlvt7j@4ax.com>  # On Mon, 30 Jul 2001 08:19:47 -0300,b, <fabio_compaq@ep-bc.petrobras.com.br> wrote:   >oE >and create a new storage company. What can happen now is to sell ther >Storage BusinesseG >to DNPG, because there is the convergence of data networks and storageU	 >networkscH >in the future.... May be DNPG could be a CISCO concurrent. Small, but a >concurrent.  C I doubt they'll sell it just yet. More likely they will continue to(D milk it dry wondering why sales dry up as customers lose confidence.C I've done some further investigation on the RA3000 and new sales oftC platform kits for the configs desupported ended on 31-MAR-2001. Twoa> months later the announcement is made that support will end onE 31-JAN-2002. So that's a total of ten months between selling the last B kit and ending support. All other configurations are still on sale? despite the announcement of support ending for these systems onsE 31-JUL-2003. I wonder how long Conpaq intend to continue selling this % controller to unsuspecting customers.r  
 What a farce.w   -- Alan   ------------------------------  % Date: Mon, 30 Jul 2001 12:17:51 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca> & Subject: Re: The death of Storageworks, Message-ID: <3B6588AD.3490BBFD@videotron.ca>  J I am starting to wonder if Compaq made its "180 day transformation" such aK strong message internally that every department is now forced to streamlinep product lines and reduce costs.t  M So, for StorageWorks, the Winklers of Compaq may have seen the vast number ofeG models that were still supported and required StorageWorks to desupport0K redundant ones and only keep a couple (not realising that those are not PCs S and enterprise customers expect support for years and years for products they buy).a   Could it be that simple ?    ------------------------------    Date: 30 Jul 2001 11:54:00 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>e% Subject: Re: VM: checking some myths.nH Message-ID: <y4zo9magjr.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  0 "mulp" <michaelpettengill@earthlink.net> writes:  M > The distinction between virtual machine and emulation and hardware assistedtB > emulation are as clear cut as the distinctions between differentI > implementations of clusters.  MAME, and the family of machines emulatedlM > under Supnik's framework are as much virtual machines as IBM's VM's, et al.q  H Not quite. A VM is intended to allow a kernel to be hosted efficiently. K Emulators often allow only user (non-privileged) code to run (more or less) 
 efficiently. n  I I do agree there is a continuum in services and performance between them.q   	Jan   ------------------------------    Date: 29 Jul 2001 23:48:28 -0700( From: Javier Henderson <javier@kjsl.com>- Subject: VMS marketing event in Cupertino, CAm- Message-ID: <8666cac3pf.fsf@cartero.kjsl.com>   ; 	I got an invitation via email for some VMS marketing eventf# taking place in Cupertino, CA soon.   9 	However, I couldn't read it: it came as a Microsoft Word- attachment.    -jav   ------------------------------  % Date: Mon, 30 Jul 2001 18:53:53 +0010)% From: paddy.o'brien@zzz.tg.nsw.gov.aue1 Subject: Re: VMS marketing event in Cupertino, CA-5 Message-ID: <01K6JWCSUBYA003BRU@tgmail.tg.nsw.gov.au>n   Javier  < >	I got an invitation via email for some VMS marketing event$ >taking place in Cupertino, CA soon. >>: >	However, I couldn't read it: it came as a Microsoft Word >attachment.    H You're as lucky as me.  I can't read this stuff either.  On a VMS box !!  N I just find that all that stuff I can delete.  Why do they need word for some K internal crap like "I've lost my glasses".  And sometimes the author is so aC inventive that he provides a whole powerpoint production.  Sheesh!!"   Regards, Paddy   ------------------------------  # Date: Mon, 30 Jul 2001 12:37:25 GMTt= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)n1 Subject: Re: VMS marketing event in Cupertino, CAq0 Message-ID: <009FFC5B.52988ED8@SendSpamHere.ORG>  X In article <8666cac3pf.fsf@cartero.kjsl.com>, Javier Henderson <javier@kjsl.com> writes:< >	I got an invitation via email for some VMS marketing event$ >taking place in Cupertino, CA soon. >i: >	However, I couldn't read it: it came as a Microsoft Word >attachment. >g >-javt   Then change the subject:  . "Stealth VMS marketing event in Cupertino, CA"   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM.            'J   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbeso   ------------------------------  % Date: Mon, 30 Jul 2001 22:31:38 +1000m, From: "Patrick Keogh" <Patrick@keogh.net.au>  Subject: Re: VMS Trivia Question4 Message-ID: <Qqc97.12$La1.5069@nsw.nnrp.telstra.net>  * "Shawn" <sfm1115@bjc.org> wrote in message* news:3b5859db.12188986@news.starnet.net...B > We just received software from RAXCO and there was a trivia typeF > poster in it.  On it it asks what happened on 17-Nov-1858, any ideas2 > we are lost here.  Is that the Star Date thingy. >a  K Yes, it is the "Star Date" thingy.  Shame on some of you for not saying WHYoL 17-Nov-1858 is time zero. I know I'm not the "oldest" VMS guy around here...  L So a little lesson in two histories. First, the history (in part) of the VAXH architecture. When Ken and Dave and the crew were in the first stages ofL specifying the architecture for the machine which was to be the follow on toJ the PDP-11, a significant user community which was polled for requirementsJ was the scientific/engineering community that had been the breeding groundD of Digital. A group with particularly demanding requirements was theE astrophysicists. The formats for VAX floating point were based on therH requirements for astrophysical calculations. Another pointer to the tiesI with astrophysics is the code names for most of the VAX hardware variantshK and some related projects, And indeed the astrophysics community repaid theeK interest, with interest. In a former life, I worked on the first VAX in the I Southern hemisphere, an 11/780 of course, at the Mt. Stromlo Observatory.o  K And now the second bit of history, the history of SAO time. With a slightlyeG US-centric view, Digital chose as "time 0" SAO time zero, 17th November3H 1858, which is described, in the words of  the DECwindows help file from around V5.1 as the following:eD   The modified Julian date adopted by SAO (Smithsonian AstrophysicalJ Observatory) for satellite tracking is Julian Day 2400000, which turns out to be November 17, 1858.K   SAO started tracking satellites with an 8K (nonvirtual) 36-bit IBM 704 iniL 1957, when sputnik went into orbit. The Julian day was 2435839 on January 1,L 1957. This is 11225377 octal, which was too big to fit into an 18-bit field.K With only 8K of memory, the 14 bits left over by keeping the Julian date in L its own 36-bit word would have been wasted. They also needed the fraction ofK the current day (for which 18 bits gave enough accuracy), so it was decideduK to keep the number of days in the left 18 bits and the fraction of a day inl the right 18 bits of one word.  H   Eighteen bits allows the truncated Julian day (the SAO day) to grow asG large as 262143, which from November 17, 1858, allowed for 7 centuries.dJ Possibly, the date could only grow as large as 131071 (using 17 bits), butH this still covers 3 centuries and leaves the possibility of representingI negative time. The 1858 date preceded the oldest star catalogue in use athK SAO, which also avoided having to use negative time in any of the satellitei tracking calculations.   History lesson endeth :-)    ------------------------------  % Date: Mon, 30 Jul 2001 14:30:46 +0100e0 From: andrew harrison <andrew.nospam@uk.sun.com>) Subject: Re: Who does migration from VMS?d* Message-ID: <3B656186.2563D732@uk.sun.com>   "David J. Dachtera" wrote: >  > Jay Braun wrote: > >p: > > I have been doing web searches for companies that do aJ > > migration/porting from VMS, primarily to UNIX/Linux.  I keep hitting aG > > small group of companies whose primary business is selling productsoD > > that emulate VMS in UNIX/Linux and Windows NT/2000 environments.I > > Aren't there firms that perform ports in such a way that the customerSB > > doesn't have to keep relying on VMS constructs and proprietary > > products for years to come?s > H > So, you're looking for something that translates DCL to shell scripts? > H > Sorry, no such magic. UN*X, etc. is too feature-poor to make that even > remotely possible. >   7 Why bother trying to move DCl to shell scripts when yous can run a DCL emulator on UNIX.o  # http://www.accelr8.com/migprod.htmlo   Regardsl Andrew Harrisone Enterprise IT Architect    ------------------------------   End of INFO-VAX 2001.420 ************************