1 INFO-VAX	Tue, 31 Jul 2001	Volume 2001 : Issue 421       Contents:  Re: (auto|sys)gen and params.dat( 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( 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 Another VAX to Alpha port  Re: Another VAX to Alpha port  Att: Steve Reece 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: Connections to VAX and Dec legacy systems 0 Re: Errors in executing the upgrade 7.2-1 to 7.3$ Re: Few People in DEC Understood....$ FWD: Highlights of an email today...( Re: FWD: Highlights of an email today...( Re: FWD: Highlights of an email today...( Re: FWD: Highlights of an email today...J Re: Gandalf StarMaster? (was Re: Connections to VAX and Dec legacy systems Re: Goodbye, good friend DEC Re: Goodbye, good friend DEC Re: Goodbye, good friend DEC Re: Goodbye, good friend DEC Re: Goodbye, good friend DEC Re: Goodbye, good friend DEC Re: Goodbye, good friend DEC Re: Goodbye, good friend DEC Re: Goodbye, good friend DEC Re: Goodbye, good friend DEC# Re: Highlights of an email today... 	 HyperSort % Re: IA64 volume and low-end dominance % Re: IA64 volume and low-end dominance  Re: IPF Console Bootstrap  Re: IPF Console Bootstrap : 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) Itanium technical info  Re: MX V4.2 installation problem+ Re: MX V51-A:  MX-W-NOCONTACT Error message 1 Obsolete storage (was:Re: Compaq's Q2 financials) 5 Re: Obsolete storage (was:Re: Compaq's Q2 financials) 5 Re: Obsolete storage (was:Re: Compaq's Q2 financials) 5 Re: Obsolete storage (was:Re: Compaq's Q2 financials) 5 Re: Obsolete storage (was:Re: Compaq's Q2 financials)  OpenVMS v1.5-1H1?  Re: Oracle file size and VMS' Re: Passing a socket to another process ( Quick DCL question - maximum open files?, Re: Quick DCL question - maximum open files?, Re: Quick DCL question - maximum open files? RTM  Re: RTM   Re: SAN-based Backup for OpenVMS  Re: SAN-based Backup for OpenVMS$ Re: Selling VMS to another company ?" Re: Sun goes after Alpha user base3 Re: TCPIP v5.1 startup on dial-up service provider. 3 Re: TCPIP v5.1 startup on dial-up service provider. , Unsupported Conjecture:  Prune Q for Suitor?0 Re: Unsupported Conjecture:  Prune Q for Suitor?( Re: VMS marketing event in Cupertino, CA What exactly is VMS? Re: What exactly is VMS? Re: What exactly is VMS? Re: What exactly is VMS? Re: What exactly is VMS? Re: What exactly is VMS? Re: What exactly is VMS? What's in it for Intel?  Re: What's in it for Intel?  Re: What's in it for Intel?   Re: Who does migration from VMS?  F ----------------------------------------------------------------------  # Date: Mon, 30 Jul 2001 21:31:15 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)) Subject: Re: (auto|sys)gen and params.dat 1 Message-ID: <Dmk97.380$Yx2.7664@news.cpqcorp.net>   Y In article <3B63854D.2B543075@vizdom.com>, "Brian M. Kelley" <bkelley@vizdom.com> writes: 8 :  Hey all. VMS-admin newbie here. We're running OpenVMS :  7.2-1 on an Alpha 433a. : 9 :  I did a bad (?) thing: I deleted sys$system:params.dat : :  (don't ask; little sleep the previos night). Here's the! :  catch: I don't have a backup.    K   This could rapidly degenerate into a version of the Monty Python Spanish  M   Inquisition sketch, such a "silly place"... I would address the privileges  *   and the system BACKUP problems, however.   :  The question is, of course,< :  how can I recover/regenerate this file? Is this possible?> :  I can see the system param values running 'paramaters/show'< :  in sys$system:sysman, so I know regenerating this file is :  possible in some manner...  ... :  I need the file to be in place so I can run9 :  sys$system:autogen to reconfig some system parameters.   :   Boot the system, and invoke AUTOGEN from phase GETDATA.   #   Then make a system disk BACKUP...     N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Mon, 30 Jul 2001 14:09:19 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> 1 Subject: Re: Alpha:  an invitation to communicate ' Message-ID: <9k47th$3t$1@pyrite.mv.net>   @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message+ news:bEg97.342$Yx2.7394@news.cpqcorp.net... ? > JF Mezei wrote in message <3B658EBD.CFF83228@videotron.ca>...    ...   A > >-Does one have confidence that Compaq really cares about VMS ?  > >  >  > Yes.  H Well, that is indeed 'one'.  Is there someone else?  (That's rhetorical,F folks:  the *real* quesiton is whether there are anything like as many/ people who have such confidence as who do not.)   F   Frankly, after reading all of your stuff the last few weeks, I thinkL > considerably more than you do.  You have already written VMS off.  WrittenH > Compaq off.  And are generally just pissed off.  As in any "death" youJ > *should* be allowed to go through all the grieving processes - including2 > being pissed off - but let's get on with things.  H In other words, let's (once again) just accept Compaq's actions as faits> accomplis and forget them - until the next time.  I think not.   > J > I'm not thrilled about the utilmate passing of Alpha.  Heck, I've alwaysL > argued that it would never happen, and that moving to another architecture2 > would be painful to customers.  But here we are.  L Indeed.  But it's not yet time to stop asking "WHY?", because nothing like aH reasonable answer has yet been presented (at least by Compaq - I suspectG some of the answers provided in c.o.v. may be close to the truth).  And G until we know why, there's no basis whatsoever for having any degree of L confidence in Compaq (not that there necessarily will be after that questionC is answered, but at least some of the uncertainty will be removed).      I'm thrilled that VMS isD > being ported.  Alpha was a great architecture (well, buy me a beer sometimeK > and I'll complain a *lot* about how hard it was to debug the EV6), but in K > the end while it "saved" VMS from the extinction of the VAX - it's just a K > CPU - it gave us a great few years where we were competetive once again - I > but it's just a CPU.  I would have been happier if they had figured out  how K > to build *really* fast VAXes (like they figured out how to build *really*  > fast X86's).  G Unfortunately, that would have made you happier only briefly, until the H limitations of a 32-bit architecture in a high-end 64-bit world made VAXF (and VMS along with it) irrelevant in that world no matter how good itJ otherwise was.  Even IBM is moving their 3x0 architecture to 64 bits now -H but Alpha and VMS had a 9-year lead on that (at least once upon a time).   > I > So now we'll move to hardware that will be both competetive, as well as F > being "industry standard".  So far there has been NO indication that anyone > isn't serious about this.   J Unfortunately, there has been equally little indication that any customers> wanted it, if it meant the extinction of Alpha in the process.  3   So far there has been NO indication that we can't J > do it.  We've given customers a pretty long heads up time before we stop > building leading edge Alphas,   L The problem is, a lot of these customers don't seem to consider it adequate,H regardless of what you may think.  Now, you could just say they're beingK unreasonable and that they should take their unreasonableness elsewhere, or J you could say that Compaq screwed up big-time and needs a major management/ transplant.  Guess it depends on where you sit.   -  and transition to leading edge IA64s (and we K > DO believe they will be competetive, leading edge systems - and we're not 	 > alone).   K Nope:  even some customers seem to agree.  The ones who don't will just get G their systems elsewhere:  they're not likely to wait around for several  years to see if they're wrong.   > E > >At one point, the minor weaknesses in Sun are probably compensated  greatly  > byK > >the fact that Sun is very agressive with marketing and has the clout and A > >installed base to attract any and all enterprise applications.  > > K > >What good is a higher quality platform when you can't trust its vendor ?  > H > I agree you shouldn't trust Sun with an enterprise system.  They don't know! > how to build a reliable system.   G Unfortunately for Compaq, IBM both knows how to build such a system and J knows how to act in a trustworthy manner.  HP arguably likewise - and they4 have an enterprise-level OS running on IA64 *today*.   - bill   ------------------------------  % Date: Mon, 30 Jul 2001 14:17:11 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 1 Subject: Re: Alpha:  an invitation to communicate , Message-ID: <3B65A49D.F1335DAA@videotron.ca>   Fred Kleinsorge wrote:M > I agree you shouldn't trust Sun with an enterprise system.  They don't know ! > how to build a reliable system.   G I would trust Sun more that I would Compaq's "industry standard" group.   N I once laboured for hours on end tryingto fix a problem with a Compaq PC whichJ could not reliably print to a postscript printer. Downloadded many patches5 from Microsoft and Compaq's web site but to no avail.   F Turns out it was Compaq's proprietary KEYBOARD driver that was causing problems with the printer port.   K Yes, this is for wintel crap, but it does show the level of quality control < (or lack thereof) that Compaq's industry standard group has.  N Compaq was supposed to get an "enterprise" image last year, but their ads onlyG re-enforced their focus on wintel stuff making Compaq look even more PC $ centric to the enterprise customers.   ------------------------------  % Date: Mon, 30 Jul 2001 11:10:01 -0700 3 From: Kevin Strietzel <kevin_strietzel@stratus.com> 1 Subject: Re: Alpha:  an invitation to communicate + Message-ID: <3B65A2F9.75983343@stratus.com>    J Ahlstrom wrote:  > JF Mezei wrote:  > > J Ahlstrom wrote: C > > > or their intentions to put their money where it woule produce D > > > the most return.  Which, I believe, Compaq as a non-non-profit' > > > company is required by law to do.  > > Q > > I am not sure that a company is required by law to generate profits. Airlines R > > would all be in prison if that were the case, so would Nortel, Lucent, Compaq,/ > > and off course all dot.com shell companies.  > 
 > --snip snip C > I am sure you are right.  I don't think a (for profit) company is < > required to generate profits.  But I believe it is open toC > shareholder suits if it cannot show that it is trying to generate 
 > profits.  E I believe that in the US of A, corporations are generally required by G law to operate in the best interests of their stakeholders.  (This came A up at my employer a couple years ago during a corporate merge and : spin-off.)  The primary stakeholders are the owners (i.e.,G shareholders).  Other stakeholders include (in no particular order) the D company's creditors, neighbors, employees, directors, customers, and% anybody else affected by the company.   E "In the best interests of" doesn't necessarily mean making a profit.  A For example, the owners of companies that don't pay dividends are 0 usually primarily interested in the stock price.  E If course, if any directors don't meet the owners' expectations, they F can be replaced (sometimes certain owners have guaranteed seats on theG board).  If any directors (or the company) defraud (or otherwise cheat) E the stakeholders, of course, they may be subject to civil or criminal  suits.  
 Not a lawyer,  --Kevin    Not speaking for Stratus.    ------------------------------  % Date: Mon, 30 Jul 2001 14:53:37 -0400 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> 1 Subject: Re: Alpha:  an invitation to communicate 1 Message-ID: <y3i97.356$Yx2.7504@news.cpqcorp.net>   9 Bill Todd wrote in message <9k47th$3t$1@pyrite.mv.net>...  > I >In other words, let's (once again) just accept Compaq's actions as faits ? >accomplis and forget them - until the next time.  I think not.  >   A What exactly is it that you want Bill?  Some admission of a grand : conspiracy?  Resignation of the Chariman?  Ritual suicide?  * Let us know what exactly will satisfy you.  E The decision to move to IPF is, as they say, a done deal.  Over with. J Finished.  Done.  Get over it.  There may be some people who will never beK happy with or about this.  Especially those who like to design, talk about, K and implement computers and computer architecture.  The people who actually K USE the computers will have to decide if what they *really* cared about was I VMS, or the underlying CPU architecture.  If it was VMS, and they want to L continue to get the benefits from using VMS, then it is up to us (Compaq) toL provide as smooth a transition as possible when the transition begins to IPF from Alpha.    So what *exactly* do you want?   ------------------------------  % Date: Mon, 30 Jul 2001 14:56:49 -0400 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> 1 Subject: Re: Alpha:  an invitation to communicate 1 Message-ID: <z6i97.357$Yx2.7501@news.cpqcorp.net>   = JF Mezei wrote in message <3B65A49D.F1335DAA@videotron.ca>...  >Fred Kleinsorge wrote: I >> I agree you shouldn't trust Sun with an enterprise system.  They don't  know" >> how to build a reliable system. > H >I would trust Sun more that I would Compaq's "industry standard" group. > I >I once laboured for hours on end tryingto fix a problem with a Compaq PC  which K >could not reliably print to a postscript printer. Downloadded many patches 6 >from Microsoft and Compaq's web site but to no avail. > G >Turns out it was Compaq's proprietary KEYBOARD driver that was causing   >problems with the printer port. > L >Yes, this is for wintel crap, but it does show the level of quality control= >(or lack thereof) that Compaq's industry standard group has.  >     D I'll repeat, don't confuse poor software interface design, with poorL hardware.  IMHO 95% of the problems people have with PCs is software relatedK and NOT unreliable, or poorly designed hardware (though there *is* a lot of H crummy, cheap hardware as well, most of it is in 3rd party peripherals).   ------------------------------  % Date: Mon, 30 Jul 2001 15:51:31 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 1 Subject: Re: Alpha:  an invitation to communicate , Message-ID: <3B65BAC2.AADEA961@videotron.ca>   Fred Kleinsorge wrote:D >> What exactly is it that you want Bill?  Some admission of a grand< > conspiracy?  Resignation of the Chariman?  Ritual suicide?  I I can't speak for Bill, however, if Winkler were to be FIRED publicly and N Compaq apologizing for having taken too much of a pro-wintel slant, that wouldM go a long way in calming fears that Compaq's true long term goal is to become + a wintel company at every enterprise level.    ------------------------------  % Date: Mon, 30 Jul 2001 15:55:40 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> 1 Subject: Re: Alpha:  an invitation to communicateh( Message-ID: <9k4e6r$5k0$1@pyrite.mv.net>  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message+ news:y3i97.356$Yx2.7504@news.cpqcorp.net...i; > Bill Todd wrote in message <9k47th$3t$1@pyrite.mv.net>...r > >eK > >In other words, let's (once again) just accept Compaq's actions as faitstA > >accomplis and forget them - until the next time.  I think not.s > >  > C > What exactly is it that you want Bill?  Some admission of a grandt< > conspiracy?  Resignation of the Chariman?  Ritual suicide? >e, > Let us know what exactly will satisfy you.  K 1.  A credible explanation of the disparity between the performance-problempK claims made about Alpha and the opinion of the Alpha engineering group thateG no such problems existed (see a recent post in comp.arch by Paul DeMoneeH asserting yet another contact with said engineers to this effect).  ThisC also needs to address the claim that the engineers were the ones toiE originate discussion of these putative problems.  I suspect that thisnD explanation will at a minimum involve Capellas stating that Compaq'sI internal communication mechanisms were terminally screwed up in this areatI and resulted in decisions being made on invalid data (since that's likely L slightly more palatable than saying that they simply outright lied if indeed that's what happened).  K 2.  An explanation of the claim aired immediately after the announcement tosE the effect that (rather contrary to point 1 above) Intel was eager tolJ incorporate major amounts of Alpha technology very quickly (before the VMSF port was completed) to rectify its IA64 mistakes.  A specific point ofG interest is Mark Gorham's discussion with Alphaman to this effect.  The J explanation may well involved statements similar to those suggested above,I and again they need to come from Capellas (since he's the one responsibleaF both for the decisions and for the statements he made regarding them).  D 3.  An explanation of the claim that Alpha was not profitable.  ThisG explanation should both address the short-term impact (and its possiblemI long-term consequences) of the decision to kill Alpha and should contrastp@ Alpha's attractiveness in this area with that of Compaq's PC andB industry-standard server divisions and contrast Compaq's manner ofE addressing these issues with IBM's (yes, that's potentially sensitive D information, but Compaq was the party to make the claim and it's nowJ Compaq's job to back it up).  It should also include an explanation of whyL Compaq has made so little effort to increase Alpha's market penetration overH the past three years (especially in the past two years).  It's not clear7 whether this should come from Capellas or from Winkler.   C 4.  Unless some believable evidence of Alpha's inability to competeoD performance-wise with IA64 appears, an explanation of why Compaq wasJ uninterested in such competition.  This explanation should include detailsI of why the reasons it was not interested do not apply to VMS and Tru64 as " well.  Again, Capellas or Winkler.  J 5.  An explanation of exactly what steps (both in new development aimed atI wider market penetration and in marketing to make that penetration occur)rL will be taken not just to counteract the negative impact dropping Alpha willH have on VMS market penetration but to grow VMS at some significant rate.K Compaq has been bandying about talk of a VMS renaissance, and now it's timeeL to deliver - especially given the blow it's just been dealt.  Capellas needsH to do this one, since every time the job has been handed down to a lower) level it's just been brushed aside later.a  I 6.  A detailed explanation of what constitutes a 'commitment' in Compaq'soJ mind, with specific reference to the commitments in the Heil/Lipcon letterI (it's still there) and why customers should place any trust whatsoever inrB Compaq after their abrupt and unilateral abandonment of its statedG commitments.  The explanation should include details of why the similarlI abrupt and unilateral abandonment of NT-on-Alpha commitments to customersnJ does not create a pattern of behavior from which to draw conclusions about future conduct.d  I That's just off the top of my head, and other people might have differenttF priorities, but if Compaq actually did all the above, even if it's notH complete, I'd say I'd be 'satisfied' and I suspect a lot of other peopleK would be as well.  Which is not to say we'd necessarily *like* the answers,t! but at least we'd *have* answers.r   >oG > The decision to move to IPF is, as they say, a done deal.  Over with.p  > Finished.  Done.  Get over it.  H NFW.  The decision to commit to Alpha was also a done deal, and that gotC changed:  with sufficient impetus, this can too.  I don't know what-I constitutes 'sufficient', but I do know that 'getting over it' *won't* be  sufficient.r   - bill   ------------------------------  % Date: Mon, 30 Jul 2001 16:04:20 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>n1 Subject: Re: Alpha:  an invitation to communicatei, Message-ID: <3B65BDC2.EE82FD1E@videotron.ca>   Fred Kleinsorge wrote:F > I'll repeat, don't confuse poor software interface design, with poorN > hardware.  IMHO 95% of the problems people have with PCs is software relatedM > and NOT unreliable, or poorly designed hardware (though there *is* a lot ofsJ > crummy, cheap hardware as well, most of it is in 3rd party peripherals).    L From a VMS viewpoint, one of the strengths of VMS was how it interacted withL quality hardware. A "system" is as weak as its weakest link. If you buy a PCN from Compaq and it is a Compaq supplied driver that drives the Compaq suppliedT proprietary keyboard which causes problems, then I consider this a hardware problem.  I i.e. the driver interacts with the specific hardware. Had Compaq providedaM "industry standard" keyboards not requiring its own specific driver, then the % problem I had would not have occured.n  N Please remember that from my point of view, Compaq is a slave to Microsoft. SoM if Microsoft decides that adding an FM radio to all wintrel servers is a good1K thing (wireless being hot, you'd need to have some antenna on the system tocN make it look cool :-), then what problems will that cause to the VMS folks whoL will suddently be forced to support something which may impact reliability ?  L In the past, Alpha and VAX systems were specifically designed for stability,I quality and reliability while wintel crap^H^H^H^Hservers were designed asIH glorified desktops in 19" enclosures. had Compaq used it clout to try toK influence Microsoft, it would have asked that the concept of the NT console M should be totally reviewed instead of the current one with an NT desktop withcN graphical screen ,mouse and keyboard required in the near vicinity of the CPU.= But Compaq didn't do that, it complied. Resistance is futile.o  J The way I see it, the IA64 at Compaq will primarily be for wintel servers,N with a few going to VMS and TRU64. So the Wintel folks will have majority whenJ the time comes to decide on what features to put or omit from the servers.   ------------------------------  # Date: Mon, 30 Jul 2001 21:20:22 GMTP  From: jlsue <jlsuexxxz@home.com>1 Subject: Re: Alpha:  an invitation to communicate 8 Message-ID: <20jbmtg0cfml0h8jj8ip06p59206itdsme@4ax.com>  D Nice story, JF, but you fail to mention if this was a desktop system or one of the servers.  @ My experience is that our Proliant servers have very good system; design - this from before I was even a Compaq/DEC employee.B  C One thing to remember, too, on the IA64-based servers is that we'llsF have experience from both our Intel-based servers group as well as our? Alpha-based servers group.  Also, as far as OpenVMS systems arel? concerned, you will have the same, in-depth testing process foroE IA64-based OpenVMS systems as we do now for Alpha.  I seriously doubtaF they'll be any less reliable (as long as you don't go putting in cheap substitute parts).      , On Mon, 30 Jul 2001 14:17:11 -0400, JF Mezei% <jfmezei.spamnot@videotron.ca> wrote::   >Fred Kleinsorge wrote:oN >> I agree you shouldn't trust Sun with an enterprise system.  They don't know" >> how to build a reliable system. >tH >I would trust Sun more that I would Compaq's "industry standard" group. >:O >I once laboured for hours on end tryingto fix a problem with a Compaq PC whichhK >could not reliably print to a postscript printer. Downloadded many patchese6 >from Microsoft and Compaq's web site but to no avail. >tG >Turns out it was Compaq's proprietary KEYBOARD driver that was causing:  >problems with the printer port. >lL >Yes, this is for wintel crap, but it does show the level of quality control= >(or lack thereof) that Compaq's industry standard group has.t > O >Compaq was supposed to get an "enterprise" image last year, but their ads onlyoH >re-enforced their focus on wintel stuff making Compaq look even more PC% >centric to the enterprise customers.    ------------------------------  # Date: Mon, 30 Jul 2001 21:40:36 GMTc  From: jlsue <jlsuexxxz@home.com>1 Subject: Re: Alpha:  an invitation to communicatea8 Message-ID: <l7jbmts49u8bqr0fraci96l97o2j6uiu1n@4ax.com>  3 On Mon, 30 Jul 2001 17:54:18 +0100, andrew harrisonq! <andrew.nospam@uk.sun.com> wrote:o  
 >jlsue wrote:c >> t6 >> On Mon, 30 Jul 2001 14:08:48 +0100, andrew harrison$ >> <andrew.nospam@uk.sun.com> wrote: >> H >> >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 customersC4 >> >would not contemplate. Customers using DBMS like& >> >Sybase cannot use this capability. >> dH >> THIS is exactly what anyone would call FUD.  There is no bug, and allG >> architectural performance characteristics have been fully disclosed.i >> h >o7 >Lets see. The poster I was responding to claimed that -7 >the cachegate issues were the result of bad design, ife4 >that is true then the terrible local/remote memory : >latency issues on WildFire are also in the same category.  ? So what you're saying is that Sun architects designed the cache > problem in there on purpose?!!!  Well, that certainly is news.  E The difference, for those who can actually read for comprehension, is D that trade-offs were made for the GS systems, these were well known,3 and they were also documented for everyone to read.s  4 Compare that to Sun's handling of the cache problem.  $ Put that in your cache and smoke it.   >h >aI >> How you can compare this to a *real* bug that causes systems to crash,oI >> corrupt data, etc., is beyond me.  It only shows your complete lack ofe
 >> ethics. >>   >p6 >When are you going to get a factually correct posting9 >out of the door (not today). Repeat after me the ecache s& >issues did not cause data corruption.  9 When you get all of your stuff 100% correct, let me know.c   >l >iE >> And they provided benchmarks for the performance that everyone hasn >> access to for comparison. >> C >u> >Rubbish, they claimed that the WildFire was the fastest UNIX  > [snip...]T  D Yeah... yeah.... yeah.  Rubbish yourself.  Did they submit benchmarkF results?  Yes.  Did it give *anyone* the ability to lookup and compare" against other results?  Yes again.  D Sorry, Andy, but you can't blame Compaq marketing for excluding someD results (if, in fact, they actually did... just because you claim itF doesn't inspire me with a lot of confidence).  The funny thing is, I'dC bet Sun marketing folks are just pissed-off that they didn't try ittE first (or maybe they have, I don't care to look up all Sun claims fort the last 5 years).  = >server on the market, they used a series of benchmarks that tD >either no one else had run on anything current, if at all, or they 9 >studiously forgot to include results that were actually -: >better than theirs. For example they claimed performance 8 >leadership for SAP while forgetting that Fujitsu had a 6 >better result on the SAP benchmark they had run. They8 >also forgot to mention that very few SAP customers run 7 >2 tier configs (what they benchmarked) most prefering c> >to run 3 tier something they didn't bother/dare to benchmark.  * Like it matters.  Only to you, apparently.   >b; >In addition their white papers on WildFire memory latency ;7 >made a comparison between WildFire memory latency and  4 >E10K memory latency, sadly they had simply made up 4 >the E10K memory latency number and in doing so made5 >the WildFire memory subsystem look much better than s >it actually was.   D I really doubt this.  I think you are making revisions to history to suit your tendencies.v   >g7 >How are you doing on ethics so far, ommision, made up s3 >numbers do they count as ethically sound practice.$  B Well, I haven't done any of these, but I definitely notice how you gloss over your own faults.h >i >tD >> If you think it actually matters whether they've used OPS or not,E >> you're kidding yourself (wishful thinking on your part).  BusinessTG >> managers say "I have $x to spend, what performance can you give me?"-I >> They don't dwell on esoteric issues like whether OPS is implemented ornH >> not.  As someone else said before, any DBA worth their salt will haveC >> very little problems with OPS.  I know several, and we've always @ >> worked well together on VMScluster solutions - and these wereD >> Unix-based DBAs, no VMS experience prior to our working together. >> 1 >06 >Sadly for you the naive may well not worry about OPS 5 >but will when they find out they have been stiffed,  4 >while on the flip side the more technically astute 3 >do worry and exclude Compaq because of it as they 79 >did with Sequent who used the same tuning trick. Either s >way its a loss.  B Again with the FUD.  The problem with you, Andy, is that you can't? seperate your real-world experience from your opinion (based on ? perhaps a few words from others).  I can tell you I *have* been:B involved in these configurations, and with a 3-node VMScluster youB have 100% uptime (from an end-user standpoint) as well as scalable performance.  E You have nothing to counter with, which explains your glib responses.    >a >> >8 >> >Despite this Compaq are still selling GS160/320's as9 >> >fit for purpose OLTP systems when in fact they arn't.b >> oH >> Blah, blah, blah.  THIS is only *your* personal opinion.  The problemE >> is, and the reason you lack so much credibility, is that you can't)H >> seperate your opinions from actual facts.  The actual fact shows thatH >> we have many, many happy customers who've implemented just that which >> you show so much scorn. >> a > 1 >No it isn't its A backed up by the current crop g1 >of DBMS benchmark results and B even people liket2 >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.   F I think you're over-reaching your knowledge here.  You're filling-in aA lot of detail based on a few inputs, and a lot of hope.   And youi> convenient leave out that nobody's systems will work great forC everyone's workload.  But then, that's just par for the course witht you.   >o >o >> >7 >> >The Sun prefetch issue on the otherhand has a patch 4 >> >that does fix the problem and also has a roadmap8 >> >to permanently fix the problem (UltraIII+) this will4 >> >be available for all current systems rather then8 >> >the WildFire fix which requires a totally new system9 >> >and on the WildFire side the performance differentialw >> >looks to be arround 30%. >>  D >> FUD.  There is nothing to fix on the GS systems.  The performanceH >> characteristics are known, as well as the trade-offs.  They work veryF >> well within the documented trade-offs.  At least Compaq is actually8 >> truthful in disclosing those trade-offs to customers. >> t >u4 >Really you are mistaken again, Compaq have made no 2 >such disclosure, in fact they have withdrawn the 7 >TPC-C result that illustrates the performance penalty e4 >to be paid. far from being honest about the penalty3 >Compaq have done their best to hide it from sight.o  A Ha!  This is typical Andrew, once again.  Just make any claim you D please.  Have they submitted TPC results?  Yes!  I just checked, and* the GS320 is in the top 5 TPC result (#4).     >@- >> >Various statements of undying support for3. >> >OpenVMS apparently from key ISV's followed0 >> >by the ISV in question dropping or partially# >> >dropping OpenVMS as a platform.a >> uD >> You're right.  Compaq should be held responsible for the businessD >> decisions of other vendors.  Sheesh.  At least use something even >> close to relevant.a >> i >o? >You misunderstand again, the information relating to supposed uF >ISV enthusiasm for OpenVMS either came from Compaq employees or from = >sources who claimed to have it second hand from Compaq. The p9 >ISV's in both of the major cases I can think of were notn? >involved at all in the dissemination of incorrect information.n >m  ? Or, you've merely inferred this to be so  because of the actuali, outcome.  At this point, who knows for sure.   ------------------------------  % Date: Mon, 30 Jul 2001 21:07:03 -0400o- From: JF Mezei <jfmezei.spamnot@videotron.ca>n1 Subject: Re: Alpha:  an invitation to communicatea, Message-ID: <3B6604B5.EEF71321@videotron.ca>   jlsue wrote:E > One thing to remember, too, on the IA64-based servers is that we'lloH > have experience from both our Intel-based servers group as well as our > Alpha-based servers group. i  M My fear is that NT's higher volumes will dictate the shape and quality of thetL boxes. Dell won't have to be too concerned about VMS , TRU64 and potentiallyM NSK, and will be able to spew out cheaper IA64s servers than Compaq. So guessiL what sort of pressure will be put on those who build Compaq's IA64 servers ?    % > Also, as far as OpenVMS systems areiA > concerned, you will have the same, in-depth testing process fori5 > IA64-based OpenVMS systems as we do now for Alpha. n  K At what point will remaining customers know whether Compaq intends to buildfL one server for all OS, or whether VMS will have its own servers ? On the oneL hand, we see messages of VMS booting on "vanilla" IA64s, and on the other weM see a message such as yours that indicates that VMS will run on highly tested = quality machines and those two don't necessarily go together.r   ------------------------------  % Date: Mon, 30 Jul 2001 21:09:44 -0400v- From: JF Mezei <jfmezei.spamnot@videotron.ca>d1 Subject: Re: Alpha:  an invitation to communicatet, Message-ID: <3B660555.BAD42AA1@videotron.ca>   jlsue wrote:6 > Compare that to Sun's handling of the cache problem. > & > Put that in your cache and smoke it.  H Yep. But now Compaq has put all its eggs into the Intel basket, the sameJ company that released a chip that gave wrong math errors and the same firm0 that hid/denied the problem for quite some time.  T Sorry, but Intel is just as guiltly as Sun in that respect and VMS depends on Intel.   ------------------------------    Date: 30 Jul 2001 20:13:18 -0700/ From: Brannon_Batson@yahoo.com (Brannon Batson)u1 Subject: Re: Alpha:  an invitation to communicaten= Message-ID: <4495ef1f.0107301913.3d2b1ce4@posting.google.com>l  n "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message news:<y3i97.356$Yx2.7504@news.cpqcorp.net>...; > Bill Todd wrote in message <9k47th$3t$1@pyrite.mv.net>...b > >eK > >In other words, let's (once again) just accept Compaq's actions as faits A > >accomplis and forget them - until the next time.  I think not.q > >b >  > [snip]   > The people who actuallyeM > USE the computers will have to decide if what they *really* cared about waslK > VMS, or the underlying CPU architecture.  If it was VMS, and they want todN > continue to get the benefits from using VMS, then it is up to us (Compaq) toN > provide as smooth a transition as possible when the transition begins to IPF
 > from Alpha.c >   B Fred, you are probably a little spoiled right now.  Once you startE using IA-64 hardware, you might realize that you cared more about then( underlying hardware than you thought ;-)   >[snip]    Brannon  not speaking for Compaq    ------------------------------  % Date: Mon, 30 Jul 2001 22:34:22 -0600n From: yyyc186@mindspring.com1 Subject: Re: Alpha:  an invitation to communicates; Message-ID: <3b663577$1$lllp186$mr2ice@nntp.mindspring.com>   3 In <3B54A616.C42F79E7@videotron.ca>, on 07/17/2001 s=    at 04:54 PM, JF Mezei <jfmezei.spamnot@videotron.ca> said:o  J >It is wishfull thinking to hope that Micrososft will just go away. CompaqF >knows this and this is why they are so closely allied with Microsoft.  E Being "closely allied with Microsoft" is the corporate equivellant ofs7 having unprotected sex with an HIV positive individual.n   Roland   --  ; -----------------------------------------------------------  yyyc186@mindspring.com; -----------------------------------------------------------o   ------------------------------  % Date: Mon, 30 Jul 2001 22:38:31 -0600u From: yyyc186@mindspring.com1 Subject: Re: Alpha:  an invitation to communicate1; Message-ID: <3b66366e$2$lllp186$mr2ice@nntp.mindspring.com>n  3 In <3B54A79E.959F3A54@videotron.ca>, on 07/17/2001 e=    at 05:01 PM, JF Mezei <jfmezei.spamnot@videotron.ca> said:r  H >Were Digital compilers truly better than Microsoft's ? Or was that justH >form Digital attempt at justifying the price of its compilers that were0 >an order of magnitude higher than Microsoft's ?  G Having used both compilers for many years (C & C++, and a smattering oftJ what passes for BASIC with MS) I can honestly say DEC compilers were worth every penny.   Roland   -- r; -----------------------------------------------------------a yyyc186@mindspring.com; -----------------------------------------------------------s   ------------------------------  % Date: Mon, 30 Jul 2001 21:19:38 -0600n+ From: Ben Franchuk <bfranchuk@jetnet.ab.ca>i1 Subject: Re: Alpha:  an invitation to communicateq, Message-ID: <3B6623CA.E47DB36E@jetnet.ab.ca>   yyyc186@mindspring.com wrote:,G > Being "closely allied with Microsoft" is the corporate equivellant oft9 > having unprotected sex with an HIV positive individual.     	Use Tux Penguin Condoms   ------------------------------  % Date: Tue, 31 Jul 2001 00:25:37 -0400,- From: JF Mezei <jfmezei.spamnot@videotron.ca>t1 Subject: Re: Alpha:  an invitation to communicatet, Message-ID: <3B663333.A06510D4@videotron.ca>   yyyc186@mindspring.com wrote:hG > Being "closely allied with Microsoft" is the corporate equivellant ofp9 > having unprotected sex with an HIV positive individual.   L But corporations don't mind all those viruses. The current CODE RED virus isJ another example. It targets only Microsoft servers that have a flaw due toM Microsoft being such a fertile ground (and target) for viruses/worms, yet theeI media don't blast Microsoft's poor software quality and Microsoft's stock L remains unaffected because investors doN't equate poor software quality withG reduced MS sales since they know that a monopoly need not have softwarep quality to make sales.   ------------------------------  % Date: Mon, 30 Jul 2001 17:48:53 -0400l) From: "Neil Rieck" <n.rieck@sympatico.ca>i" Subject: Another VAX to Alpha port8 Message-ID: <zzk97.387$D55.121460@news20.bellglobal.com>  G I just spent part of yesterday transferring my ICSIS application from a:K VAX-6430 to an AlphaServer-4120 (EV5). I'd done two trial cutovers prior to0H yesterday but today was the first time I saw the machine under a 70 userI load. I can't believe how fast this thing is. It boots 5 times faster butrL feels 10 times faster once running (I think this may be partly a RAID effectH but may also be due to the fact that we're running two CPUs with 512K of RAM).t  J At first people thought the cutover failed because the log on messages andH "node identification" pages just flew by after entering their passwords.  F Anyway, If you're interested I posted a few odds and ends at my "Alpha Porting Page" here:e6 http://www3.sympatico.ca/n.rieck/docs/alpha_diary.html under "Diary #2".n    
 Neil Rieck Kitchener/Waterloo/Cambridge,p Ontario, Canada.! http://www3.sympatico.ca/n.rieck/M   ------------------------------  % Date: Mon, 30 Jul 2001 21:58:04 -0500>% From: "Rich Jordan" <rjordan@mcs.net>n& Subject: Re: Another VAX to Alpha port5 Message-ID: <p8p97.19226$j02.278628@news.goodnet.com>n   Neil,tK      this is not surprising; in fact its been a fairly normal reaction fromo	 our usersgK as some of the holdouts finally upgrade from 3100s (model 10, model 80, andsI model 96 so far) to DS10/600's.  Of course the model 10 folks were almostsH shellshocked; the 96 users were just grinning uncontrollably for days...   Rich Jordan    Neil Rieck wrote in message ...rH >I just spent part of yesterday transferring my ICSIS application from aL >VAX-6430 to an AlphaServer-4120 (EV5). I'd done two trial cutovers prior toI >yesterday but today was the first time I saw the machine under a 70 userrJ >load. I can't believe how fast this thing is. It boots 5 times faster butF >feels 10 times faster once running (I think this may be partly a RAID effectI >but may also be due to the fact that we're running two CPUs with 512K of> >RAM). >RK >At first people thought the cutover failed because the log on messages andlI >"node identification" pages just flew by after entering their passwords.q
 > ........ >Neil Riecko >Kitchener/Waterloo/Cambridge, >Ontario, Canada.u" >http://www3.sympatico.ca/n.rieck/   ------------------------------  % Date: Tue, 31 Jul 2001 00:10:13 +0100i% From: Alan Greig <a.greig@virgin.net>e Subject: Att: Steve Reecec* Message-ID: <3B65E954.4261779F@virgin.net>   [Sorry everyone else]n  C Steve, if you see this I'm getting the following when I try to mail>A you. As I was replying to email in which you commented you hadn't ) received much mail I think I know why :-)>  ' ---- Transcript of session follows ---->  D %%%%%%%%%%%%                   30-JUL-2001 23:16:35.22  %%%%%%%%%%%%A %MAIL-E-OPENIN, error opening SYS$LOGIN:[SYSMGR]SIGN.TXT as inputsA -RMS-F-DEV, error in device name or inappropriate device type forh	 operationc  % ---- Recipients of this delivery ----s  " <system@ipl.demon.co.uk> (bounced)       --
 Alan Greig   ------------------------------  # Date: Mon, 30 Jul 2001 18:02:02 GMT + From: Anne & Lynn Wheeler <lynn@garlic.com> ! Subject: Re: checking some myths.p) Message-ID: <ubsm2wbep.fsf@earthlink.net>h  * nmm1@cus.cam.ac.uk (Nick Maclaren) writes: > C > In actual fact, there are bugs that can creep by the 3-level testsB > for both compilers and VMs, but they are mind-bogglingly obscureC > by comparison with the ones that adding the third level picks up.h >   B for the resource manager ... I developed an automated benchmarkingF system that would generate kernels, auto-reboot, run benchmarks, buildF new kernels, run more benchmarks ... and it would run & run & run. TheD basic set was 2000 benchmarks that took three months elapsed time to% run (before initial product release).e  E The benchmarking attempting to choose workloads along the edge of theuB "normal" observed operational envelopes, random points withing the@ envelope and some number of operations that were way outside anyE normal envelope ... say saturating a couple fixed-head paging devicessE (hundreds of pages/sec), with huge queues and average service time ofD 1second.  B These outside the envelope benchmarks tended to precipitate zombieC user conditions and numerous timing failures. In order to eliminatebE all such cases (from the normal system), I had to totally rewrite the B system serialization primitives in order to eliminate all possibleF occurances of zombies & kernel failures because of various asyncronous timing problems.   random refs:& http://www.garlic.com/~lynn/94.html#52) http://www.garlic.com/~lynn/2001c.html#13a) http://www.garlic.com/~lynn/2001e.html#45t) http://www.garlic.com/~lynn/2001f.html#56 3 http://www.garlic.com/~lynn/subtopic.html#fairsharen  . and of course, my favorite "envelope" subject:. http://www.garlic.com/~lynn/subtopic.html#boyd   -- FH Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/    ------------------------------  # Date: Mon, 30 Jul 2001 18:37:59 GMTh+ From: Anne & Lynn Wheeler <lynn@garlic.com> ! Subject: Re: checking some myths.a) Message-ID: <un15muuwz.fsf@earthlink.net>u  - Anne & Lynn Wheeler <lynn@garlic.com> writes:c  I > '83 ... had nearly 1000 mainframe nodes at point when arpanet was aboutr > 255 total nodes. random refs:l$ > http://www.garlic.com/~99.html#112   oops that should bea' http://www.garlic.com/~lynn/99.html#112d   also some discussion at ( http://www.garlic.com/~lynn/internet.htm   -- WH Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/    ------------------------------  # Date: Mon, 30 Jul 2001 18:55:24 GMTy. From: "Stephen Fuld" <s.fuld@worldnet.att.net>! Subject: Re: checking some myths.nH Message-ID: <w4i97.20956$LP2.1258173@bgtnsc06-news.ops.worldnet.att.net>  8 "Anne & Lynn Wheeler" <lynn@garlic.com> wrote in message# news:ubsm2wbep.fsf@earthlink.net...h, > nmm1@cus.cam.ac.uk (Nick Maclaren) writes: > > E > > In actual fact, there are bugs that can creep by the 3-level testnD > > for both compilers and VMs, but they are mind-bogglingly obscureE > > by comparison with the ones that adding the third level picks up.p > >t >oD > for the resource manager ... I developed an automated benchmarkingH > system that would generate kernels, auto-reboot, run benchmarks, buildH > new kernels, run more benchmarks ... and it would run & run & run. TheF > basic set was 2000 benchmarks that took three months elapsed time to' > run (before initial product release).  >rG > The benchmarking attempting to choose workloads along the edge of theiD > "normal" observed operational envelopes, random points withing theB > envelope and some number of operations that were way outside anyG > normal envelope ... say saturating a couple fixed-head paging devicesoG > (hundreds of pages/sec), with huge queues and average service time ofc
 > 1second. >nD > These outside the envelope benchmarks tended to precipitate zombieE > user conditions and numerous timing failures. In order to eliminatetG > all such cases (from the normal system), I had to totally rewrite theeD > system serialization primitives in order to eliminate all possibleH > occurances of zombies & kernel failures because of various asyncronous > timing problems.      I This seems to be a good answer to the question someone raised a few weeks.L ago about how do you test an interactive, time-sharing operating system.  ItI also squares with my experience (so it must be right!) that stressing therE memory allocation and swapping/paging systems brings out all sorts ofp* othrwise hard to find timing related bugs.     --     -  Stephen Fuld.   ------------------------------  # Date: Mon, 30 Jul 2001 21:14:43 GMTb* From: cjt & trefoil <cheljuba@prodigy.net>/ Subject: Re: Compaq FUD and lack of information + Message-ID: <3B65CE5E.1547C23C@prodigy.net>    jlsue wrote: >  <snip> > 9 > Isn't this kind of deal part of the SEC's jurisdiction?g@ > 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.  K If the SEC imposes a 90 day quiet period each quarter, not much informationo will ever get out.  ;-)    ------------------------------  # Date: Mon, 30 Jul 2001 21:45:55 GMT   From: jlsue <jlsuexxxz@home.com>/ Subject: Re: Compaq FUD and lack of informationo8 Message-ID: <ffkbmto7dv4bmne8octhvf93cebvj5lhik@4ax.com>  . On 30 Jul 2001 16:35:23 +0200, Jan Vorbrueggen8 <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:  # >jlsue <jlsuexxxz@home.com> writes:o > : >> Isn't this kind of deal part of the SEC's jurisdiction?A >> If so, wouldn't it also be subject to the 90 day quiet period?s >lM >This is a sale of some Compaq "property", not a merger or an acquisition. I  1 >don't think the SEC or quiet periods apply here.s >   B Except that it has a *lot* to do with the supposed monopoly of CPUB chips from Intel.  Maybe I have it wrong and it's the FTC... but I@ remember when Intel bought the Hudson Fab and there were certain? conditions that had to be met before it'd get the go-ahead froma government regulators.  E I'd expect that this would bring even more scrutiny by the regulators F since it stands to eliminate a very good competitor (performance-wise,C anyway), and increase the market dominance of Intel.  Don't forget,>E too, that the U.S. government has many Alpha servers in place in some  very sensitive areas.>   ------------------------------  % Date: Mon, 30 Jul 2001 21:15:27 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>e/ Subject: Re: Compaq FUD and lack of informationo, Message-ID: <3B6606AC.EE4269F8@videotron.ca>   jlsue wrote:G > I'd expect that this would bring even more scrutiny by the regulatorsaH > since it stands to eliminate a very good competitor (performance-wise,6 > anyway), and increase the market dominance of Intel.  N Compaq is based in the home state of the guy who lives at the white house. AndJ that guy is on record as stating that the government shouldn't have gottenD involved against Microsoft (or something to that order). The currentN administration in the USA isn't interested in combatting big business it wants to help it.u   > Don't forget,0G > too, that the U.S. government has many Alpha servers in place in somea > very sensitive areas.t  I For another couple of years. After that, they can choose from any vendor.    ------------------------------  % Date: Mon, 30 Jul 2001 22:38:42 +0100c% From: Alan Greig <a.greig@virgin.net>u# Subject: Re: Compaq's Q2 financialsr) Message-ID: <3B65D3E1.131A7C9@virgin.net>o   Alan Greig wrote:e  E > On Mon, 30 Jul 2001 15:09:43 GMT, jlsue <jlsuexxxz@home.com> wrote:o >V  B > I am sure you will now tell me why Conpaq's current Storageworks& > reburials are good for the customer. >s  F Must have had a spell-checker disaster on the above line. I originallyI typed retirals not reburials. Hmm... maybe the spell-checker got it rightm after all :)     > -- > Alan   --
 Alan Greig   ------------------------------  % Date: Mon, 30 Jul 2001 14:11:38 -0400o- From: "Peter Weaver" <peter.weaver@stelco.ca> 6 Subject: Re: Connections to VAX and Dec legacy systems4 Message-ID: <yrh97.273964$Z2.3311751@nnrp1.uunet.ca>  7 "Vic Mendham" <vmendham@altavista.com> wrote in messageh6 news:8b51ed8.0107300651.758dc1c7@posting.google.com... >...E > Has anyone ever used a Gandolf StarMaster and have any simple login-G > and port information. We just had someone quit and all knowledge went  > with them. >...  F Where are you Victor? Toronto I assume? Ted Buck used to be my GandalfJ contact in Burlington a long time ago. The service group was bought out byL IBM and Ted continued to service the StarMaster after that, but he was beingL trained for other things. I have no idea where Ted is now, but you might tryJ calling IBM and asking either for him directly, or asking for the services& arm and then asking about StarMasters.  I The only other StarMaster God I knew passed away three weeks ago. I mightaF recongize a StarMaster if I tripped over it, but I'm not sure anymore.   -- 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.0   ------------------------------  # Date: Mon, 30 Jul 2001 22:51:01 GMTz2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)9 Subject: Re: Errors in executing the upgrade 7.2-1 to 7.3h1 Message-ID: <pxl97.387$Yx2.7742@news.cpqcorp.net>l  X In article <3B657653.5000108@iaf.fhg.de>, Theo Jakobus <Theo.Jakobus@iaf.fhg.de> writes:J :I started to upgrade my PWS500au from 7.2-1 (with all patches installed)  :to 7.3 and got two errors:i :h :1. STARTLET.OLB7 :During the upgrade at 60% progress I got the messages:i! :%PCSI-E-WRITEERR, error writing ,4 :DISK$21_SYSDISK:[VMS$COMMON.][SYSLIB]STARTLET.OLB;6' :-LIBR-E-DUPKEY, duplicate key in index H :I restored 7.2-1, checked STARLET.OLB;5 and started again the upgrade, / :after running in the same problem I proceeded.b  L   Check that you have current Fortran (FORRTL) and/or COBOL RTLs installed, J   it appears that certain versions of these have tripped the V7.3 upgrade.     "STARTLET"?  :-)    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Mon, 30 Jul 2001 14:05:41 -0400n* From: "Andy Stoffel" <acs@fcgnetworks.net>- Subject: Re: Few People in DEC Understood....e6 Message-ID: <rmh97.15550$%7.188397@news6.giganews.com>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B6590FB.4F1408D9@videotron.ca...  K > But when those engineers didn't realise is that part of the reason A1 was- soK > big is that it shipped with about half of the source code which customers- > could then copy or modify.  I And some of us did :-).... unfortunately, the last time I had a chance tod> do much with ALL-IN-1 was 6 years ago... it isn't used much in the "circles" I now inhabit....r  A The first "real" application I ever wrote (I've got a copy on 8mm > tape somewhere...) was using ALL-IN-1. And it could do so much2 more than I was ever able to take advantage of....   -Andy-   --' VMS - When access to your data matters.p   ------------------------------    Date: 30 Jul 2001 18:47:18 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)e- Subject: FWD: Highlights of an email today...t3 Message-ID: <7DB0EMCfugeA@eisner.encompasserve.org>E   > From: guppy <guppy99@usa.com>. > Newsgroups: comp.sys.dec* > Subject: Highlights of an email today... > H > Compaq will continue to manufacture, enhance, and sell the entire line( > of Alpha-Based HPS servers until 2006. > G > Compaq will start to manufacture and sell (in volume to customers) ancE > entire line (low-end to high-end) of IPF-based HPS servers in 2004.  > J > Compaq will continue to support (hardware maintenance, add-ons, softwareF > enhancements) the entire line of Alpha-Based HPS servers until 2013. > J > OpenVMS  will have a single code base for both Alpha-based and IPF-based, > systems.  The same is true for Tru64 UNIX. > E > Compaq will continue to enhance the OpenVMS and Tru64 UNIX systems,iF > whether running on Alpha-Based or IPF-Based HPS Servers until 2013 - > then only on IPF.0 > J > Customers can grow vertically (chips the same) within either system, andJ > horizontally with mixed architecture clusters (mix Alpha and IPF systems > in a cluster). > I > Compaq will continue to manufacture balanced HPS servers, whether usingEB > an Alpha Chip or IPF chip, and maintain all of the integrity and@ > characteristics of the systems for which we have been claiming
 > leadership.s > I > Everything "above the chip" remains the same.  Customers will need onlysJ > do a simple recompile their applications.  ISV's will have a simple path? > forward for applications which will not disrupt the customer.n > G > Compaq will build systems and Operating Systems that will continue to-E > differentiate us from competitors.  No other vendor delivers bettercG > clustering solutions than Compaq.  No other vendor can deliver better3C > systems for Reliability, Scalabilityand Availability than Compaq.y > H > The way I look at it, the next generation Alpha chips (EV8 and beyond)E > have an EPIC instruction set rather than the Alpha-RISC instruction I > set.  Alpha Dead?  I don't think so...  Only different.  I view this ast) > a positive...  And so should customers.r   ------------------------------  % Date: Mon, 30 Jul 2001 23:58:57 +0100e% From: Alan Greig <a.greig@virgin.net>t1 Subject: Re: FWD: Highlights of an email today...f* Message-ID: <3B65E6B0.3FFA0A0F@virgin.net>   Larry Kilgallen wrote:  ! > > From: guppy <guppy99@usa.com>e > > Newsgroups: comp.sys.dec, > > Subject: Highlights of an email today... > >eJ > > Compaq will continue to manufacture, enhance, and sell the entire line* > > of Alpha-Based HPS servers until 2006. >"  G So Compaq will still be selling an entire line of Alphaservers in 2006?/  N I have a feeling I will be quoting this post back a lot earlier than 2006. AndK it is that customer perception that Compaq have to address. If all previousAJ Compaq roadmaps had proved reasonably accurate I would believe the current ones. But they didn't. --
 Alan Greig   ------------------------------  % Date: Mon, 30 Jul 2001 21:44:40 -0400f- From: JF Mezei <jfmezei.spamnot@videotron.ca> 1 Subject: Re: FWD: Highlights of an email today... , Message-ID: <3B660D83.AB6D9115@videotron.ca>   Larry Kilgallen wrote:! > > From: guppy <guppy99@usa.com>rL > > OpenVMS  will have a single code base for both Alpha-based and IPF-based. > > systems.  The same is true for Tru64 UNIX.  J Isn't it too premature at this point in time to make such declaration ? IsG this some corporate edict imposed on the VMS engineers or some edicated F decision by the engineers that maintaining a single code base would be possible/beneficial ?1  K As I recall, VAX and Alpha have different code base. (or at least each havey) their own source code library). Correct ?   G > > Compaq will continue to enhance the OpenVMS and Tru64 UNIX systems,iH > > whether running on Alpha-Based or IPF-Based HPS Servers until 2013 - > > then only on IPF.e  M No mention of VAX based VMS.  Shouldn't Compaq start to make some commitmentsoG for VAX-VMS support since VAX is already retired an no longer selling ?-  K > > Everything "above the chip" remains the same.  Customers will need onlygL > > do a simple recompile their applications.  ISV's will have a simple pathA > > forward for applications which will not disrupt the customer.t  M That statement cannot be made until Compaq produces a list of its own layeredm& products that will get ported to IA64.   ------------------------------  % Date: Mon, 30 Jul 2001 21:54:08 -0500%1 From: "David J. Dachtera" <djesys.nospam@fsi.net>%1 Subject: Re: FWD: Highlights of an email today...:' Message-ID: <3B661DD0.7355BF75@fsi.net>r   Larry Kilgallen wrote: > ! > > From: guppy <guppy99@usa.com>  > > Newsgroups: comp.sys.dec, > > Subject: Highlights of an email today... > > J > > Compaq will continue to manufacture, enhance, and sell the entire line1 > > of Alpha-Based HPS servers until 2006. [snip]a   Larry,    @ Please post this on billboards, airport ad frames, bus cards andC benches, etc. world-wide until the Q finally learn what "marketing"t means.   --   David J. Dachterar dba DJE Systemsl http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/o   ------------------------------  # Date: Mon, 30 Jul 2001 23:02:07 GMTr2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)S Subject: Re: Gandalf StarMaster? (was Re: Connections to VAX and Dec legacy systems 1 Message-ID: <PHl97.389$Yx2.7846@news.cpqcorp.net>a  i In article <8b51ed8.0107300651.758dc1c7@posting.google.com>, vmendham@altavista.com (Vic Mendham) writes:   H   You've misrouted (mistitled) your question, you are centrally looking L   for help with a Gandalf (usually known for switches, but I'm not familiar I   with the "StarMaster" model) and not with OpenVMS VAX nor TOPS20 boxes.   K   It is trivially easy to log into OpenVMS via a serial line, and somebody uH   here can probably help you with the TOPS20 login.  In other words, getF   the information on the switch, and folks here can probably then help   you with your login.  K   Pointers to setting up serial lines are in the OpenVMS documentation, andeL   discussions of modems are quite common in the OpenVMS Ask The Wizard area.  K   Depending on what systems and configuration you have and what your local gK   requirements are, we might be able to provide alternatives to the GandalfwL   (if you can't get it working) -- terminal servers and LAT, cluster console   systems, etc..   ..D :Has anyone ever used a Gandolf StarMaster and have any simple loginF :and port information. We just had someone quit and all knowledge went :with them.tE :Basically user dialin via modem and enter an alias to connect to the:E :system/application of their choice. I need to login, and investigate,0 :hung ports and create new connections/ aliases. ..+ :Please reply to victor.mendham@emergis.come     Ask here, get an answer here.f  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------    Date: 30 Jul 2001 11:10:15 -0700( From: Hodapp87@weasel.net (Chris Hodapp)% Subject: Re: Goodbye, good friend DEC = Message-ID: <1b179cd3.0107301010.17b74456@posting.google.com>u  ? MS trashed a lot of companies that could have made something ofDD themselves if MS didn't copy and get them bankrupt. Mainly companiesA who were actually making huge advances in technology... back whenpE there was COMPETITION and not just MONOPOLIES from a shitty computer.   A Don't cry. Alpha was bought by Intel and Compaq would use Intel'st Itanium CPU in their servers.d   ------------------------------    Date: 30 Jul 2001 15:55:04 -0500+ From: young_r@encompasserve.org (Rob Young) % Subject: Re: Goodbye, good friend DEC.3 Message-ID: <Yx5VJg9G1Wsz@eisner.encompasserve.org>   ` In article <40samtcqto9tatcbeul6qlcr7en18frgpf@4ax.com>, Alan Greig <a.greig@virgin.net> writes:F > On 30 Jul 2001 10:22:18 -0500, young_r@encompasserve.org (Rob Young) > wrote: >  >>! >>	Old news and somewhat silly.  a >>E >>	He describes DCL and VAXes and talks in terms as if they are both  G >>	history.  He is more than a little ahead of himself as VMS survived  F >>	VAX and he talks as if it isn't around.  Another writer that can't  >>	seem to say "VMS".l > F > But that's partly the point. Unless you are still actively using VMSH > then VAX, VMS,  DCL, and now Alpha *are* history. The fact that VMS isG > still living seems to be a secret Compaq would like to keep to itselfe  > and a few remaining customers. >   > 	But still.... there is this whole concept called "accuracy in@ 	reporting."  Some folks don't ascribe to it, that's okay if you7 	are writing about fiction.  But to pen something alongc9 	the lines of "Goodbye friend", talking in terms as if itoB 	no longer exists (VMS) without mentioning it (VMS) isn't accurate< 	and is quite silly.  It wasn't written as a fictional pieceE 	or with humor in mind, so what he wrote was/is a pile of codswallow.   > 	(And yes, he does insinuate that the Digital Command LanguageA 	and the OS it runs on is a thing of the past, which of course itr. 	isn't if current numbers are to be believed).   				Robh   ------------------------------  # Date: Mon, 30 Jul 2001 19:58:22 GMT4# From: Bob Day <bobday@mediaone.net>b% Subject: Re: Goodbye, good friend DEC , Message-ID: <3B65BC69.A898955D@mediaone.net>   Chris Hodapp wrote:   A > MS trashed a lot of companies that could have made something ofhF > themselves if MS didn't copy and get them bankrupt. Mainly companiesC > who were actually making huge advances in technology... back whena  > there was COMPETITION < snip >  9 Yes, there was competition and Microsoft competed and DECi> didn't.  DEC thought it would cost too much to create a PC/GUIE version of VMS.  It didn't consider that it might be an *investment*.jA DEC had the limited objective of selling into an existing market;d9 Microsoft had the vision that it could *create* a market.2< Consequently, Microsoft could offer Windows 95, for example,8 for $95 to run on $2000 computers at a time when DEC was; trying to sell VMS for $1200 to run on computers costing att least $10,000.  
 -- Bob Day   ------------------------------  # Date: Mon, 30 Jul 2001 21:59:27 GMTo  From: jlsue <jlsuexxxz@home.com>% Subject: Re: Goodbye, good friend DECC8 Message-ID: <hclbmtg6ddk2ske7inksr5oltroqa11qpl@4ax.com>  C On Mon, 30 Jul 2001 15:37:08 +0100, Alan Greig <a.greig@virgin.net>e wrote:  E >On 30 Jul 2001 10:22:18 -0500, young_r@encompasserve.org (Rob Young)  >wrote:h >  >>! >>	Old news and somewhat silly.    >>E >>	He describes DCL and VAXes and talks in terms as if they are both tG >>	history.  He is more than a little ahead of himself as VMS survived aF >>	VAX and he talks as if it isn't around.  Another writer that can't  >>	seem to say "VMS".m >nE >But that's partly the point. Unless you are still actively using VMSpG >then VAX, VMS,  DCL, and now Alpha *are* history. The fact that VMS is-F >still living seems to be a secret Compaq would like to keep to itself >and a few remaining customers.u >cC >If you read the followups a number of people point out that VMS is2 >still with us.>  ? And, in fact, so is Alpha.  And it will be for quite some time.tC Do say that you won't buy the best system capability merely becausemC you may have to migrate in 8 years is silly.  The Alpha EV7 systemsn will be around awhile.   ------------------------------  # Date: Mon, 30 Jul 2001 22:22:13 GMTh2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)% Subject: Re: Goodbye, good friend DECM1 Message-ID: <p6l97.384$Yx2.7211@news.cpqcorp.net>   ` In article <61eamtolm6kfumr5f317l5i4jd3lpv99dr@4ax.com>, Alan Greig <a.greig@virgin.net> writes:' :Something else to wake Compaq up with?m     I'm working on a response.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Mon, 30 Jul 2001 23:33:37 +0100m% From: Alan Greig <a.greig@virgin.net>i% Subject: Re: Goodbye, good friend DECr* Message-ID: <3B65E0C1.D6ADC9E8@virgin.net>   jlsue wrote:   > A > And, in fact, so is Alpha.  And it will be for quite some time. E > Do say that you won't buy the best system capability merely becausefE > you may have to migrate in 8 years is silly.  The Alpha EV7 systems- > will be around awhile.  M I wish I could get through to you and Compaq in general. The reason customers:K will stop buying Alphaservers is because they *HAVE NO CONFIDENCE IN CONPAQ3D RIGHT NOW". Please understand this point and *DO SOMETHING ABOUT IT*M Letting Sun reach some customers with the first notification is unbelievable.aN How much more crap do you think we should take from Conpaq before you think weK should lose confidence? Maybe when we see the announcement in 6 months time.K that EV7 will never ship? Oh that's not going to happen is it? Why should I - believe that? Please tell your managers this.i  L Customers who absolutely need an Alpha/VMS solution right now will still buyN but for everyone else it is just one more nail in the coffin. I am telling youM as a customer you have made my job much harder to argue for VMS (or Tru64 fornJ that matter) solutions internally. I suspect Conpaq senior management knowN this. That should reverse Marcello's unexpected (to Capellas/Winkler) mini-VMS revival quite nicely.i  L Winkler and Capellas are either seiously misguided or else are intentionallyG destroying Digital bit by bit (or both). It's about time we knew which.o   --
 Alan Greig   ------------------------------  % Date: Mon, 30 Jul 2001 21:37:21 -04001- From: JF Mezei <jfmezei.spamnot@videotron.ca>H% Subject: Re: Goodbye, good friend DECe, Message-ID: <3B660BCC.2E7B98A6@videotron.ca>   Alan Greig wrote:eN > Winkler and Capellas are either seiously misguided or else are intentionallyI > destroying Digital bit by bit (or both). It's about time we knew which.(  K They are not misguided. They are betting the shop on Microsoft because theyBP know it is a lot easier to clean Bill Gates's orifice than it is to fight Gates.  G It is pointless to work hard to try to see some positive spin. Take theEL information that Compaq has chosen to give you and make your decisions based on that.  N You can ssee what Compaq COULD have done with Alpha and what Compaq COULD haveN done with VMS. But you can't make business decisions on what Compaq COULD haveK done, you need to make business decisions based on the info that Compaq has"
 given to you.-  = Is it worth continually fighting to have Compaq provide token-, support/marketing for VMS to keep it alive ?  I If all the VMS and Alpha engineers were to jump ship to Sun, think of the K great quality and mentality that Sun would gain and its products would thenn replace VMS.  L What is easier: try to fight an endless fight against a company that doesn'tN really want these products, or jump ship and work with a company that wants to8 push the products to the max and improve their quality ?   ------------------------------  % Date: Mon, 30 Jul 2001 21:48:45 -0500o1 From: "David J. Dachtera" <djesys.nospam@fsi.net>o% Subject: Re: Goodbye, good friend DECs' Message-ID: <3B661C8D.BA112F34@fsi.net>n   Rob Young wrote: > b > In article <61eamtolm6kfumr5f317l5i4jd3lpv99dr@4ax.com>, Alan Greig <a.greig@virgin.net> writes:* > > Something else to wake Compaq up with? > >t > > F > > http://www.zdnet.com/eweek/stories/general/0,11011,2782356,00.html > >cB > > You can also read comments and add your own at the above link. > >e > > By Brett Arquetteo > > July 3, 2001 2:25 PM ET) > >u > & >         Old news and somewhat silly. > K >         He describes DCL and VAXes and talks in terms as if they are both M >         history.  He is more than a little ahead of himself as VMS survived8L >         VAX and he talks as if it isn't around.  Another writer that can't >         seem to say "VMS".  G Surprisingly (to me, anyway), most folks seem to equate VAX and VMS, asm if the two were one. m  G "Do Alphas run VAX? No? Then, what do Alphas run? Oh, yeah - that goofy F thing called 'OpenVMS'. Must be some kind of UN*Xly hold-over from the< '90's, some kind of clone of the real thing, an NT-wannabe."  C Don't laugh - I actually overheard that in the office of a local ITe
 recruiter!   -- i David J. Dachterad dba DJE Systems0 http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Mon, 30 Jul 2001 21:51:21 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>F% Subject: Re: Goodbye, good friend DECr' Message-ID: <3B661D29.1A1D6251@fsi.net>t   Alan Greig wrote:  > ( > Something else to wake Compaq up with?  H Doubt it. We've already tried thermo-nuclear, and that didn't even leaveE a mark on 'em, snoring away like Old Sol had gone white dwarf already,C (how they survived red giant, I dunno, but there they are and thereI they'll stay!).a   -- r David J. Dachteral dba DJE Systemsu http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t   ------------------------------  % Date: Tue, 31 Jul 2001 04:47:17 +0200g From: .@cybercity.dk% Subject: Re: Goodbye, good friend DECh8 Message-ID: <km3cmtk4sidqa46npcg926epj4i6atnecl@4ax.com>  M >At Mon, 30 Jul 2001 11:38:52 +0100, Alan Greig <a.greig@virgin.net> claimed:w  ' >Something else to wake Compaq up with?  >p >wC >http://www.zdnet.com/eweek/stories/general/0,11011,2782356,00.htmlf >n? >You can also read comments and add your own at the above link.l >e >By Brett Arquette o >July 3, 2001 2:25 PM ET   Nice, nostalgic story. Keep it up Brett.   :^}i   --) http://www.usenet.dk/netikette/quote.html / UNIX: designed by programmers, for programmers.8  :-) --   ------------------------------  % Date: Mon, 30 Jul 2001 23:31:40 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> , Subject: Re: Highlights of an email today...( Message-ID: <9k58rv$rpc$1@pyrite.mv.net>  F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:7DB0EMCfugeA@eisner.encompasserve.org...D! > > From: guppy <guppy99@usa.com>  > > Newsgroups: comp.sys.dec, > > Subject: Highlights of an email today... > > J > > Compaq will continue to manufacture, enhance, and sell the entire line* > > of Alpha-Based HPS servers until 2006.  H Hey, that's great!  That means we'll see EV8 after all!  Maybe even EV9!  D Oh, wait:  they didn't *really* mean they'd continue enhancements atA anything like the normal pace, now, did they.  I forgot:  this ise
 Compaq-speak.o   - bill   ------------------------------  % Date: Mon, 30 Jul 2001 16:09:27 -0400  From: CMcCusker@lightbridge.comp Subject: HyperSortE Message-ID: <OF0D2D7EE6.46A63B8C-ON85256A99.006DFB85@lightbridge.com>'  E Does anyone know of any hidden "gotchas" in using the Alpha Hypersort  utility?  It seems thatmK    even if you define the sortshr logical to hypersort.exe the system stilln! uses sortmerge.exe in some cases.0    Thanks in advance.c      Clint McCusker     Lightbridge, Inc.    Burlington MA 01803    781.359.4877a   ------------------------------   Date: 31 Jul 2001 05:09:06 GMT. From: shoens@lenny.sfrn.dnai.com (Kurt Shoens). Subject: Re: IA64 volume and low-end dominance+ Message-ID: <9k5ehi$25h$1@bob.news.rcn.net>   O In article <9k20nd$h97$1@pyrite.mv.net>, Bill Todd <billtodd@foo.mv.com> wrote:tK >e.g., the volume of lock-related meta-data can threaten to exceed a 32-bitX& >address space in large installations.  H Eeek.  That's a lot of locks.  I'm sure the effort to avoid getting that! many locks would be amply repaid.n  C Also, the notion of splitting locks over multiple address spaces or-C of using PAE to get > 32-bit buffer pool addressability is probablyoE a poor tradeoff.  The database systems I've known are quite sensitive @ to the performance of getting to an already-buffered page and toH acquiring/releasing locks.  It's a big jump to throw a system call into  those costs ...a   ------------------------------  % Date: Tue, 31 Jul 2001 01:34:03 -0400o' From: "Bill Todd" <billtodd@foo.mv.com>r. Subject: Re: IA64 volume and low-end dominance( Message-ID: <9k5g1h$4fj$1@pyrite.mv.net>  ; "Kurt Shoens" <shoens@lenny.sfrn.dnai.com> wrote in message-% news:9k5ehi$25h$1@bob.news.rcn.net...uJ > In article <9k20nd$h97$1@pyrite.mv.net>, Bill Todd <billtodd@foo.mv.com> wrote:F > >e.g., the volume of lock-related meta-data can threaten to exceed a 32-bit( > >address space in large installations. > J > Eeek.  That's a lot of locks.  I'm sure the effort to avoid getting that# > many locks would be amply repaid.o  K Not necessarily:  in many cases it's possible to combine lock requests withpI data requests and then cache the lock as long as the data is also cached, I thus largely eliminating the marginal expense of fine-granularity lockinglI (which of course can provide better concurrency - and if you support lock C de-escalation as IIRC DEC's Rdb does, they you need to maintain thenJ fine-grain context anyway just in case).  I tend to associate you with theJ large pile of lock-related patents IBM owns, but realize that many of themE may have been from wholly separate research projects:  if you weren'tc> involved in this particular one, some of your colleagues were.   >@E > Also, the notion of splitting locks over multiple address spaces oroE > of using PAE to get > 32-bit buffer pool addressability is probablysG > a poor tradeoff.  The database systems I've known are quite sensitivewB > to the performance of getting to an already-buffered page and toI > acquiring/releasing locks.  It's a big jump to throw a system call into  > those costs ...a  K For lock operations, I agree (that's why I offered them up as an example ofeD 64-bit utility).  For buffer access (as long as the buffer meta-dataI structures are virtually resident) it's not so clear:  system calls don't.K cost what they used to as long as the client process can retain its addressnG mapping, and database access to a buffer tends to have a non-negligibledK operation path length such that adding modestly to it may not be noticeablerG (especially considering that really frequently-accessed material may be A cached at a higher level than the disk buffer pool:  even with annK already-mapped buffer, first finding it and then finding some piece of datal) within it has a fair amount of overhead).d   - bill   ------------------------------  # Date: Tue, 31 Jul 2001 03:05:08 GMTB. From: "Duane Sand" <duane.sand@mindspring.com>" Subject: Re: IPF Console Bootstrap> Message-ID: <Efp97.16084$Kd7.9660983@news1.rdc1.sfba.home.com>  1 "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote :s > Fred Kleinsorge wrote:I > > the EFI console meets ALL THE GOALS that we had for a common console.- >-G > But now that "we" is Compaq, do you think that EFI will also meet the  goalss > for NSK ?S > ... I > > Dunno about NSK, but they tend to have pretty unique HW requirements.i VMS-C > > and Tru64 are talking to each other to make sure that we do notr	 duplicatea > > efforts. >cD > It is a shame that you are not talking to the NSK folks. If Compaq
 eventuallyH > intends to have Wildfire-like systems based on IA64 (which are not all thatD > dissimilar to Tandem's multi processor architecture in some ways), wouldn't itp* > benefit from working with the NSK folks?  I Wildfire is a shared-everything system, where each of the many processorsaH sees all memory (and hence can be affected by any other processor's data
 corruptions).u  D NSK Himalaya systems are shared-nothing systems, in which processorsE connect only via a fault-isolating messaging fabric, never by memory. A When a hardware or software error is detected, the potential data F contamination is limited to just one processor, whose work in progressG is immediately abandoned and re-done by siblings.   The first thing NSKaF architects do with any chip, is ignore any shared-memory capabilities.F (The second thing is to double-up every cpu chip for fault detection.)  4 There won't ever be a Wildfire-like Himalaya system.  @ If and when server chips evolve to the point where you can't buy: uniprocessors anymore, NSK will shift to using 2- or 4-way? MP modules as the minimal fault domain.  But not for this port.i  < The NSK and VMS/Tru64/Linux/Windows product lines will shareE a single hardware base in terms of (Intel's) chip designs.  But NSK'sy? board-level designs will never converge with the others; the 2xhD cost overhead makes that impractical for any product other than NSK.; Maybe we will share some compiler technology; but NSK isn't 7 dependent on GEM like VMS is.   Hopefully we will sharer% I/O devices and I/O support software.a  < Maybe we can share some low-level firmware such as pieces ofE the bootstrap code discussed in this thread.  But there's been littletA communication between those groups.  And little time is available 3 for altering NSK's existing plans for new firmware.e  :    -- Duane Sand, not speaking for Yosemite firmware folks   ------------------------------  # Date: Tue, 31 Jul 2001 03:05:48 GMT . From: "Duane Sand" <duane.sand@mindspring.com>" Subject: Re: IPF Console Bootstrap> Message-ID: <ggp97.16088$Kd7.9662218@news1.rdc1.sfba.home.com>  1 "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote :3 > Fred Kleinsorge wrote:I > > the EFI console meets ALL THE GOALS that we had for a common console.  >eG > But now that "we" is Compaq, do you think that EFI will also meet theS goalsd > for NSK ?p > ...hI > > Dunno about NSK, but they tend to have pretty unique HW requirements.e VMSkC > > and Tru64 are talking to each other to make sure that we do note	 duplicate  > > efforts. >rD > It is a shame that you are not talking to the NSK folks. If Compaq
 eventuallyH > intends to have Wildfire-like systems based on IA64 (which are not all thatD > dissimilar to Tandem's multi processor architecture in some ways), wouldn't it * > benefit from working with the NSK folks?  I Wildfire is a shared-everything system, where each of the many processors H sees all memory (and hence can be affected by any other processor's data
 corruptions).m  D NSK Himalaya systems are shared-nothing systems, in which processorsE connect only via a fault-isolating messaging fabric, never by memory. A When a hardware or software error is detected, the potential dataoF contamination is limited to just one processor, whose work in progressG is immediately abandoned and re-done by siblings.   The first thing NSKGF architects do with any chip, is ignore any shared-memory capabilities.F (The second thing is to double-up every cpu chip for fault detection.)  4 There won't ever be a Wildfire-like Himalaya system.  @ If and when server chips evolve to the point where you can't buy: uniprocessors anymore, NSK will shift to using 2- or 4-way? MP modules as the minimal fault domain.  But not for this port.   < The NSK and VMS/Tru64/Linux/Windows product lines will shareE a single hardware base in terms of (Intel's) chip designs.  But NSK'si? board-level designs will never converge with the others; the 2xCD cost overhead makes that impractical for any product other than NSK.; Maybe we will share some compiler technology; but NSK isn'th7 dependent on GEM like VMS is.   Hopefully we will share.% I/O devices and I/O support software.   < Maybe we can share some low-level firmware such as pieces ofE the bootstrap code discussed in this thread.  But there's been littlemA communication between those groups.  And little time is availablee3 for altering NSK's existing plans for new firmware.a  :    -- Duane Sand, not speaking for Yosemite firmware folks   ------------------------------    Date: 30 Jul 2001 19:59:03 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>rC Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)oH Message-ID: <y4d76icn88.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  / JF Mezei <jfmezei.spamnot@videotron.ca> writes:   E > What exactly ten is the difference between BIOS and console (EFI) ?-  N AFAIK, on the original PC the BIOS handled most of what in WNT is the hardwareL abstraction layer (HAL), i.e., it offered a standard functionality to the OSK for certain things, irrespective of the hardware. I suspect that in current.K systems, the BIOS more-or-less does what a "console" does on other systems:EL set some of the basic hardware parameters (memory timing etc), deliver boot-0 time functionality, and then get out of the way.   	Jan   ------------------------------  % Date: Mon, 30 Jul 2001 13:38:49 -0400t5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>bC Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)e1 Message-ID: <BZg97.345$Yx2.7378@news.cpqcorp.net>a  = JF Mezei wrote in message <3B6593EB.116F2AAE@videotron.ca>..." >Fred Kleinsorge wrote:pH >> the EFI console meets ALL THE GOALS that we had for a common console. >iL >But now that "we" is Compaq, do you think that EFI will also meet the goals
 >for NSK ? >q    I I cannot answer for NSK.  I've never seen a NSK system.  I *am* sure thattH the NSK group will ensure that they have what they need.  I am also sureL that nothing VMS or Tru64 will do, will have any adverse effects on NSK, andF that they are fully plugged into the levels well above me coordinating efforts.  I >> No, you will get menu like an old Alpha NT console (now that I've seenc 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). >tI >Please make sure that this "menu" can be permanently disabled and serialaK >console used by default for all pre-boot operations. If the machine powerse upK >with that silly menu and expects someone to press some key to switch it ton/ >serial, then serial console will be worthless.- >-    A Come on.  Even my dual boot PC at home autoboots after a timeout.e  E >> The consoles purpose in life should be simple and sweet:  Find theg	 hardware,0K >> initialize it to a known state, load the OS, and get the h*ll out of thee >> way.o >yL >People in the VAX world are used to also getting hardware tests, being able toE >display system config, scan the scsi bus, set various boot flags andi options etc. >c    L There is an interesting debate.  Turns out that the power up self tests, andK even the more intense directed testing in the console seldom finds anythingiI but the most gross problems.  However, that said - the EFI console allows K all sorts of diagnostic "applications" to be loaded for doing more that thet normal POST.  L The things of interest that need to be seen, tested, or set - all seem to be
 available.  L >And lets not forget the ability to access console mode by pressing BREAK at OPA0:  >e    G Now THAT is a unlikely thing (break is an old VAX thing).  It is highly J unlikely that there will be a HALT, let alone continue.  More likely thereI will be a mini-debug environment built into the OS (perhaps xdelta-like).   I ><ALT-CTRL-DEL> is impossible to generate on a serial line, and if VMS oni IA64L >even mentions those 3 keys, it will lose a lot of credibility. Those 3 keysE >should be copywritten by Microsoft and only inflicted on MS systems.p >u    K If anything, it would be ^P.  Not that there is anything special about whataE you use, as long as it is something not likely to happen by accident..  5 >> Do NOT confuse EFI with the BIOS found on PeeCees.  >sG >When I power up a PC and it tells me to press some key inside of a fewe secondslI >to access setup, isn't that the PC's equivalent of a console code ? Most:L >people call this BIOS.  What exactly ten is the difference between BIOS and >console (EFI) ? >n    I That is generally called on most PeeCees "CMOS" setup.  It is the way you L set non-volitile state, device configuration, and such.  You might call this the "console" I suppose.  K You want to go find an old Alpha NT system with the ARC console on it.  ThesI main difference is that it assumes something like a "VT" and instead of aeL dead seargent command line, it gives you a simple menu system.  You can loadJ console "applications" which can do other things - like a UNIX-like shell, or even a debug environment.  H >> Dunno about NSK, but they tend to have pretty unique HW requirements. VMS L >> and Tru64 are talking to each other to make sure that we do not duplicate >> efforts.k > C >It is a shame that you are not talking to the NSK folks. If Compaqh
 eventuallyL >intends to have Wildfire-like systems based on IA64 (which are not all thatL >dissimilar to Tandem's multi processor architecture in some ways), wouldn't it* >benefit from working with the NSK folks ? >     K Nobdy said we're not.  *I* just don't know.  Of course, the Tru64 folks who3< have identical requirements sit on the floor right below me.  I >If EFI causes problems because of its PC centric attitude, shouldn't the2 VMSDE >(and true 64) folks get together with NSK and design a Compaq commona console?4 >that would be better suited to enterprise systems ? >t    I I've already said, the EFI console provides everything that VMS and Tru64r needs as far as I can tell.d  L >If your console is unable to do much stuff except boot, does this mean thatI >VMS will gain the ability to perform low level formats, display SCSI busf scans 
 >etc etc ?  L The EFI console can load applications and utilities from it's disk partitionI that can do pretty much anything, but which are NOT a defined part of theo console specification.   ------------------------------  % Date: Mon, 30 Jul 2001 14:29:27 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>.C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)h, Message-ID: <3B65A77C.1BCACCA9@videotron.ca>   Fred Kleinsorge wrote:I > Now THAT is a unlikely thing (break is an old VAX thing).  It is highlyrL > unlikely that there will be a HALT, let alone continue.  More likely thereK > will be a mini-debug environment built into the OS (perhaps xdelta-like).n  K When one runs OPCRASH, where will one be taken ? Will the system be able to-7 re-enter console mode with a >>> prompt (or whatever) ?o  M > Nobdy said we're not.  *I* just don't know.  Of course, the Tru64 folks who-> > have identical requirements sit on the floor right below me.  K That is an image I did not need to see ! But it does at least show that therL VMS folks are in command and the Tru64 are the servants who sit on the floor below their masters ! :-)a  N > The EFI console can load applications and utilities from it's disk partitionK > that can do pretty much anything, but which are NOT a defined part of ther > console specification.  L By disk partition, you need that ODS2 file that happens to have its contents formatted as a FAT partition ?  N Does this mean that a VMS system disk might have, as part of the "boot file" aK set of various applications which would complement the basic EFI commands ?0  N What would the concept be behind the loading of such utilities ?  Wouldn't EFIJ wait only once it is told to boot to seek that FAT partition on the system, disk where those utilities would be stored ?  K Does EFI have special commands to load utilities/applications from the boott disk without actually booting ?m  E or would this be similar to B/1 which invokes SYSBOOT, one would have 3 BOOT/something which would invoke other utilities ?9   ------------------------------  % Date: Mon, 30 Jul 2001 14:42:03 -0400 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>:C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS).1 Message-ID: <JUh97.355$Yx2.7458@news.cpqcorp.net>v  = JF Mezei wrote in message <3B65A77C.1BCACCA9@videotron.ca>...  >Fred Kleinsorge wrote: J >> Now THAT is a unlikely thing (break is an old VAX thing).  It is highlyG >> unlikely that there will be a HALT, let alone continue.  More likely  therecL >> will be a mini-debug environment built into the OS (perhaps xdelta-like). >dL >When one runs OPCRASH, where will one be taken ? Will the system be able to8 >re-enter console mode with a >>> prompt (or whatever) ? >r     Yes.  J >> Nobdy said we're not.  *I* just don't know.  Of course, the Tru64 folks whon? >> have identical requirements sit on the floor right below me.  >sL >That is an image I did not need to see ! But it does at least show that theG >VMS folks are in command and the Tru64 are the servants who sit on theo floord >below their masters ! :-) >     K Hmm.  Let me rephrase.  The UNIX folks are on the 3rd (and 2nd) floors, thei7 VMS folks are on the 4th (and 2nd) floors.  Quite cozy.a  E >> The EFI console can load applications and utilities from it's diskt	 partition,L >> that can do pretty much anything, but which are NOT a defined part of the >> console specification.a >nD >By disk partition, you need that ODS2 file that happens to have its contents >formatted as a FAT partition ?e >d     Yes.  G >Does this mean that a VMS system disk might have, as part of the "boota file" atL >set of various applications which would complement the basic EFI commands ? >i    ! You can look at it that way, yes.n  K >What would the concept be behind the loading of such utilities ?  Wouldn'ts EFItK >wait only once it is told to boot to seek that FAT partition on the system - >disk where those utilities would be stored ?d > L >Does EFI have special commands to load utilities/applications from the boot  >disk without actually booting ? >r    J The EFI is effectively a small operating system.  You can load things fromI disk - like protocol handlers, or "applications" which can do pretty muchnH anything.  For instance as I mentioned there is a UNIX-like "shell" thatI allows you to mount disk (partitions), do directories, delete files, copysK files, etc.   The application you are most likely to run is the OS_LOADER -lK i.e. to BOOT the system.  The OS_LOADER is special, it exits by telling thet3 EFI console that it is no longer needed (ExitBoot).o  F >or would this be similar to B/1 which invokes SYSBOOT, one would have4 >BOOT/something which would invoke other utilities ?  I Think of it like running the ECU  -- but I can tell by your questions youaD are a VAX guy, and not exposed much to Alpha (or you would have said boot -flags 0,1).   K SYSBOOT is the secondary bootstrap that is loaded by the primary bootstrap.tI On Alpha, the SRM is/was quite capable of running things that are not thepH OS, like the Raid Configuration Utility, the EISA Configuration Utility,B etc.  You can think of this as "booting" a standalone application.  D EFI makes this a bit more formal, allowing true "applications" to beK written.  So instead of having to add functionality to the console, you can-L extend the functionality by writting an application - like a new diagnostic, a shell, whatever...   ------------------------------  % Date: Mon, 30 Jul 2001 15:49:32 -0400w- From: JF Mezei <jfmezei.spamnot@videotron.ca>pC Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)o, Message-ID: <3B65BA4B.8AAF4293@videotron.ca>   Fred Kleinsorge wrote:F > EFI makes this a bit more formal, allowing true "applications" to beM > written.  So instead of having to add functionality to the console, you canqN > extend the functionality by writting an application - like a new diagnostic, > a shell, whatever...  K Would these applications/utilities be stored on the system disk in the samekK FAT as the primary loader for VMS ? (eg: from ODS2 point of view, stored in64 the same ODS2 file which contain the FAT container).  N Or would there be plans to include these utilities in a ROM on the motherboardL so that they would be accessible before the OS is loaded on a hard disk ? OrN is the expectation that every system will always have the "bootable" CD in itsH primary CD drive so that after a failure, one could remotely start those utilities ?c   ------------------------------  % Date: Mon, 30 Jul 2001 13:12:58 -0700 ! From: Tom Linden <tom@kednos.com>rC Subject: RE: IPF Console Bootstrap (was: Re: No chance for OpenVMS) 9 Message-ID: <CIEJLCMNHNNDLLOOGNJIGEFCDBAA.tom@kednos.com>a  / http://www.linux.se/doc/HOWTO/MILO-HOWTO-2.html    > -----Original Message-----6 > From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]& > Sent: Monday, July 30, 2001 12:50 PM > To: Info-VAX@Mvb.Saic.Com E > Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)i >  >  > Fred Kleinsorge wrote:H > > EFI makes this a bit more formal, allowing true "applications" to be? > > written.  So instead of having to add functionality to the h > console, you canA > > extend the functionality by writting an application - like a e > new diagnostic,i > > a shell, whatever... > B > Would these applications/utilities be stored on the system disk 
 > in the sametD > FAT as the primary loader for VMS ? (eg: from ODS2 point of view,  > stored inh6 > the same ODS2 file which contain the FAT container). > A > Or would there be plans to include these utilities in a ROM on b > the motherboard @ > so that they would be accessible before the OS is loaded on a  > hard disk ? Or< > is the expectation that every system will always have the  > "bootable" CD in itsJ > primary CD drive so that after a failure, one could remotely start those
 > utilities ?i >    ------------------------------  # Date: Mon, 30 Jul 2001 21:47:39 GMT,  From: jlsue <jlsuexxxz@home.com>C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)o8 Message-ID: <unkbmtojg02ji12t3bpj3hdhq06dgbhijt@4ax.com>  E JF, the Remote Insight Board Lights Out Edition does have the abilityd# to even power-off systems remotely.l  , On Mon, 30 Jul 2001 12:07:02 -0400, JF Mezei% <jfmezei.spamnot@videotron.ca> wrote:m   >Jan Vorbrueggen wrote:wQ >> You were talking about having a line-mode vs a graphical-head console, which IdQ >> presumed having the console while a windowing system was running. Before that,tQ >> the graphics behave pretty much like a glass TTY emulator, so there isn't muchtK >> difference to the serial-line console (apart from not having a record onv
 >> paper). > O >Having the >>> on a serial line is perhaps even more important than having theoO >VMS "OPA0:" on a serial line. What good is your fancy remote system management H >if you cannot issue the proper commands to the console and then ask the >machine to boot ? >lO >For instance, in a disaster recovery scheme I had setup, after a disaster, the M >satellite would be rebooted not only as a master but also switch from a test L >node to a production node. To acheive this, the operator would B/1 DISK: toL >get to SYSBOOT (by then into VMS), and then set some of the USER parametersM >which were handled by the startup procedure to do all the proper definitions-, >for the application, print queues etc etc). >cM >had the >>> prompt been forced to some blue screen with keyboard attached tonY >the mainframe, the operator would not have been able to remotely execute those commands.k   ------------------------------  % Date: Mon, 30 Jul 2001 22:14:55 -0500u% From: "Rich Jordan" <rjordan@mcs.net>wC Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)n5 Message-ID: <dop97.19228$j02.278636@news.goodnet.com>u   Fred, K      thanks for taking the time to provide so many useful responses.  Everye little bit helps :)o   Rich Jordann rjordan@mcs.nete   ------------------------------  % Date: Mon, 30 Jul 2001 17:18:03 -0400p) From: "Neil Rieck" <n.rieck@sympatico.ca>  Subject: Itanium technical info 8 Message-ID: <D6k97.325$D55.105299@news20.bellglobal.com>  I For those people preparing to go over to the dark side, lots of good (and-% free) Itanium info can be found here:o( http://developer.intel.com/design/ia-64/K However, for those people who wish to learn from a more traditional source,iI I just (2001.0730) received my copy if "Itanium Architecture for Software B Developers" (published by INTEL Press) from http://www.powells.com  
 Neil Rieck Kitchener/Waterloo/Cambridge,: Ontario, Canada.! http://www3.sympatico.ca/n.rieck/f   ------------------------------  % Date: Mon, 30 Jul 2001 21:36:19 +0200N= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>u) Subject: Re: MX V4.2 installation problemi) Message-ID: <3B65B733.1F909F70@gtech.com>    Arne Vajhj wrote:D > There are a known problem iN MX 4.2 and nwer VMS versions with the
 > .OPT files.S > I > It is very easy to fix. Just unpack savesets edit .OPT files and create # > new savesets and you are all set.h >  > But:J >   - the MX mail-list archives which described what to change are offlineI >   - I have the fixes on my hobbyist system back home, but I can not gete& >     to it rigth now (I am in the US) > J > So I am afraid you wil need to get someone else to send you the changes.  / I am back and I can make the changes available.a   Interested ?   Arne   ------------------------------    Date: 30 Jul 2001 12:18:35 -07000 From: techwebsite@netscape.net (Michael Angello)4 Subject: Re: MX V51-A:  MX-W-NOCONTACT Error message= Message-ID: <34e80f93.0107301118.1222ee7a@posting.google.com>E  : Thanks Mr. Langstoeger, It seems to be working on well now< the MX local processes are commonly busy because of the pathA config, however, the MX message queue in use is often at 3% or 4%t of use. : But, I don't know if that communication problem was from a= malfunction of another service like a web server, could it behB possible?, I read some web server logs and there were some entries> regarding IP addresses that did not respond any ping made from any given machine.  ) Could those things be related in any way?f  5 I appreciate your attention and time to this scenery.o Thanks again   Mike.e          \ eplan@kapsch.net (Peter LANGSTOEGER) wrote in message news:<3b5e803f$1@news.kapsch.co.at>...q > In article <34e80f93.0107241328.5651cf0@posting.google.com>, techwebsite@netscape.net (Michael Angello) writes:i2 > >I am using OVMS 7.2 AXP and using MXV51-A, and 9 > >DIGITAL TCP/IP Services for OpenVMS Alpha Version V5.0t > D > You know, that MX V5.2 (ECO 4) and TCPIP V5.1 (ECO 1) is current ? > C > >but there are a lot of email messages waiting for processing andl > >at: DKAn:[MX.SMTP.LOCK] > E > You know, that you can disable the locking alltogether/specificallye, > with the MX_SMTP_LOCK_EXCLUSIONS logical ? > 3 > >a lot of messages has the following description:e > >w9 > >0C2783B8: %MX-W-NOCONTACT, could not establish contact - > >with any mail servers for this destination  > = > The SMTP agent is not able to reach the remote SMTP server..A > This is not really a MX problem (if not weird config happened).  > 6 > Check with NSLOOKUP -type=MX destination.domain.nameE > and then with TELNET mail-server.destination.domain.name [/PORT=]25e > I > You can however redirect the mailmessage to another mailserver (despite"! > the infos in BIND/DNS) with theh > J > $ MCP ADD PATH "destination.domain.name" SMTP/ROUTE="another-mailserver" > 
 > command. >  > >at MCP STAT:l > >o2 > >MX Router       Idle               Router agent2 > >MX Router#2     Idle               Router agent2 > >MX Router#3     Idle               Router agent: > >MX Local        Waiting for #  311 Local delivery agent: > >MX Local#2      Waiting for #   30 Local delivery agent: > >MX Local#3      Waiting for #   36 Local delivery agent: > >MX Local#4      Waiting for #   17 Local delivery agent: > >MX Local#5      Waiting for #   12 Local delivery agent > ? > 5 local agents and all busy ? Do you have so much local userso= > or are they all busy rewriting the mails for the SMTP agentt. > (when "MAIL>SET FORWARD/USER=..." is in use) > > > >MX MLF          Idle               Mailing list/file server9 > >MX SMTP         Waiting for #   89 SMTP delivery agente9 > >MX SMTP#2       Waiting for #  115 SMTP delivery agento9 > >MX SMTP#3       Waiting for #  175 SMTP delivery agentq9 > >MX SMTP#4       Processing  #  159 SMTP delivery agent 9 > >MX SMTP#5       Waiting for #  117 SMTP delivery agento9 > >MX SMTP#6       Waiting for #    9 SMTP delivery agents9 > >MX SMTP#7       Waiting for #   34 SMTP delivery agent 9 > >MX SMTP#8       Waiting for #   87 SMTP delivery agentc > K > 8 SMTP agents is not that many. I've 60 running (and only 2 LOCAL agent).sI > What are the entries waiting for ? Do they all have delivery problems ?aG > If you have a lot of mails in the queue, the throughput is limited bys > the count of the SMTP agents.p > B > >MX Site Agent   Idle               Site-specific delivery agent? > >MX SMTP Server  Connected       36 SMTP server (over TCP/IP) 4 > >MX FLQ Manager  Idle               MX FLQ manager> > >MX LSV Intfc    Idle               Listserv interface agent > >r- > >and a lot of SMTP request: (almost always)n? > >MX SMTP Server  Connected       36 SMTP server (over TCP/IP)f > F > Wow. Are they really all doing useful things. Or are they only badlyI > closed TCP connections. Better check in TCPIP (and upgrade to V5.1-151)  > ? > >The MX Server cannot deliver email so easy as another times, ? > >so at the client side it takes a lot of time passing throughi< > >some errors (time outs) before sending the email message. > B > You could configure more than one SMTP server to split the load.B > But not on the same IP address (only usable on multihomed hosts): > on the same TCP port (check MX_SMTP_TCPIP_PORT logical).4 > I've never done it, and I also won't recommend it. > > > >I have configured the network services well, because I have@ > >the connectivity needed, by using pings, nslookups, etc. evenE > >more, It doesn't have any other email services up except this one.S > F > You mean, you haven't enabled TCPIP's SMTP. This is good, obviously.   ------------------------------  % Date: Mon, 30 Jul 2001 16:38:30 -0400c  From: John Santos <JOHN@egh.com>: Subject: Obsolete storage (was:Re: Compaq's Q2 financials)6 Message-ID: <1010730160740.36974A-100000@Ives.egh.com>  & On Mon, 30 Jul 2001, Alan Greig wrote:  E > On Mon, 30 Jul 2001 15:09:43 GMT, jlsue <jlsuexxxz@home.com> wrote:3 >  > >B > >9F > >Thus, if you have changing storage requirements, be sure to ask howD > >much those changes cost over the long term.  Then compare that toG > >Compaq SAN costs.  My experience tells me that you'll like Compaq inb > >the end.t > F > Storageworks products are much more price competitive than they usedG > to be. On VAX we switched to MTI about six years ago but went back tohD > Storageworks when upgrading to Alpha les than two years ago,  OnlyE > serious illness of one member of staff and the departure of anothertD > delayed things by a few month making the HSZ80 current and not theD > HSZ70. Were it not for this delay I would now be sitting trying toE > explain why I needed an emergency budget allocation of maybe aroundrG > 50,000 dollars to put in a dual HSG80 fibre SAN. I have no confidence'H > in the HSZ80 support lasting much longer so I'll probably have to planH > to budget an upgrade for CY2003 at the latest. All this in a period of > expenditure lock-down. > B > So my experience tells me that you won't like Conpaq in the end.E > Perhaps if Conpaq listened to its customers instead of telling theme? > that they like Conpaq (and even just making things up such asmC > "customer response has been unbelievably positive") you might geti > somewhere. > B > I am sure you will now tell me why Conpaq's current Storageworks& > reburials are good for the customer. > -- > Alan  D Is this different from the obsolesense of HSC50's, HSC70's, HSC95's,D HSZ40's, HSZ50's, etc and RA8x/RZ9x/RZ26/RZ28/RZ29 etc, etc. that we? have gone through in the past?  All storage technologies becomewF obsolete, and if you want to stay current or to save money on hardwareC support, you need to upgrade them occasionally.  If your RA92's areeH fast enough for your app, you can still run them today on your ES40. :-)  E Is this situation any different?  Remember, RA81's cost about $15,000v when they were new.   G I know HSZ70's are more dependent on firmware (and thus more vulnerableNB to firmware bugs and being unable to support newer disks without aE firmware upgrade than many items on my list), but no more so than thek various HSC's were.   B Is Compaq FORCING you to upgrade, or did they merely announce that@ the older generation of storage is becoming obsolete in 2 years?@ Will they still provide hardware service contracts, parts, etc.,C like they always have in the past, or are they cutting you off with.@ nothing?  Are there 3rd-party maintenance companies who would be glad to have your business?   @ I know that there are holes in their product line, assuming theyB don't announce any new low-end replacements in the next two years.A (e.g. for the HSZ22 or RA3000, if I have the part numbers right.)    ----  D Do you think any of the peripherals on your brand-new 1.5GHz P4 willF work on your 2004 IA64 system (whether it's running VMS or M$ or LinuxF or AIX or whatever), when you replace it in 3 years?  (Average life ofD a PC, like a 1950's american automobile.)  Memory - no chance.  HardE disk?  IDE *might* work, but would be regarded as very small and slowaD by the standards of the time.  SCSI?  Maybe, unless SCSI-4 has takenE over.  Floppy disk?  legacy ;-), you probably won't have or need one.tA CD-ROM?  Try DVD.  DVD-ROM?  New systems will come with DVD-RW orsG something similar...  CD-R?  Same thing.   Graphics?  PC graphics cards G seem to have about a 4-month lifetime, making Fred K's job really hard!cC Monitor?  I believe there is a new graphics cabling standard coming H in that allows for both analog and digital interfaces, makes flat-screenF monitors much cleaner.   I don't know if it is electrically compatibleI with current VGA monitors and just requires an adapter cable or if you'llsD need a new monitor.  Internal modem?  Probably will be obsolete, andD the manufacturer won't make drivers.  External modem?  OKay if HayesE compatible and you have a serial port, which is very iffy.  Printers?hA Please - they're as dependent on manufacturer-supplied drivers asiC anything.  Maybe an HP laserjet would be okay.  Keyboard and mouse?iC If USB, they might work (assuming USB-II is upwards-compatible withlC USB) but if they have any special features, they will probably onlyE. work in vanilla mode with the generic drivers.   -- v John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Mon, 30 Jul 2001 17:41:17 -0400y' From: "Bill Todd" <billtodd@foo.mv.com>t> Subject: Re: Obsolete storage (was:Re: Compaq's Q2 financials)( Message-ID: <9k4kb0$b4u$1@pyrite.mv.net>  - "John Santos" <JOHN@egh.com> wrote in messagea0 news:1010730160740.36974A-100000@Ives.egh.com...( > On Mon, 30 Jul 2001, Alan Greig wrote:   ...   D > > So my experience tells me that you won't like Conpaq in the end.G > > Perhaps if Conpaq listened to its customers instead of telling them A > > that they like Conpaq (and even just making things up such astE > > "customer response has been unbelievably positive") you might getb > > somewhere. > >tD > > I am sure you will now tell me why Conpaq's current Storageworks( > > reburials are good for the customer. > > -- > > Alan > F > Is this different from the obsolesense of HSC50's, HSC70's, HSC95's,F > HSZ40's, HSZ50's, etc and RA8x/RZ9x/RZ26/RZ28/RZ29 etc, etc. that we  > have gone through in the past?  H Yes - and in a manner similar to the premature retirement of Alpha beingI different from the relatively graceful retirement of VAX:  in both cases, G products that are still useful to a large number of customers are beingdC guillotined with inadequate notice and with no suitable replacementiC available at the time of the announcement (or even guaranteed to bee available ever).   ...2  F > Do you think any of the peripherals on your brand-new 1.5GHz P4 willH > work on your 2004 IA64 system (whether it's running VMS or M$ or Linux6 > or AIX or whatever), when you replace it in 3 years?  H I can't speak for Alan, but I'm virtually certain that when I upgrade myG currently-new AMD PC at about that time (likely to an AMD i86-64 unlessaJ Intel manages to do in that competitor as it did Alpha) they'll do exactlyK that.  I seriously doubt that many PC users will be using IA64 in 2004:  it@D won't be able to compete in price *or* performance with IA32 on IA32L applications, let alone compete on price-performance, and there's no obviousE killer 64-bit application on the horizon to compensate for that majorg deficiency.m     (Average life of@ > a PC, like a 1950's american automobile.)  Memory - no chance.  > And probably not interesting, if it continues its price slide.     HardG > disk?  IDE *might* work, but would be regarded as very small and slowe > by the standards of the time.g  K IDE will almost certainly work and I expect my current dual 6.5 GB, 8.4 GB,lF and 20 GB drives will still be quite useful - just as the 6.5s and 8.4G (already oldish) and even a 2.1 and 850 MB drive remain useful today as.= large removable devices and/or mirroring and/or backup disks.t  '   SCSI?  Maybe, unless SCSI-4 has takena > over.   L Is SCSI-4 planned to be less backward-compatible than SCSI-2 and SCSI-3?  If not, there'll be no problem.  @   Floppy disk?  legacy ;-), you probably won't have or need one.  I Yeah, right.  In the last couple of years I've used my 5.25" floppy drive I twice to obtain stuff I thought I'd never need again, and somehow I don't K expect that situation to have changed by 2004 (at least for 3.5" floppies -f< by then I *hope* to have all my 5.25" floppy stuff retired).  C > CD-ROM?  Try DVD.  DVD-ROM?  New systems will come with DVD-RW or  > something similar...  F But likely not with two of them, which will be convenient for copying.   ...e     Printers?mC > Please - they're as dependent on manufacturer-supplied drivers asd > anything.d  B Which is just one of the nice aspects of sticking with an existingI architecture in an upward-compatible fashion, as AMD is doing:  I can run>K not only my existing systems (if their descendants aren't fully compatible)-E but all the other software on my brand new 2004 i86-64 PC just fine -o including printer drivers.  7 Too bad the Alpha -> IA64 'upgrade' won't be as smooth.u   - bill   ------------------------------  % Date: Mon, 30 Jul 2001 22:59:37 +0100c% From: Alan Greig <a.greig@virgin.net>o> Subject: Re: Obsolete storage (was:Re: Compaq's Q2 financials)* Message-ID: <3B65D8C8.EF07D112@virgin.net>   John Santos wrote:  D Is this different from the obsolesense of HSC50's, HSC70's, HSC95's,  F > HSZ40's, HSZ50's, etc and RA8x/RZ9x/RZ26/RZ28/RZ29 etc, etc. that we >l  J You haven't been following this have you?  Of course it's different. At noM point in the past have DEC/Compaq de-supported controllers currently shippingtG to my knowledge. Some of the controllers you mention above are actually K *still supported* or were until the current announcement. This isn't CompaqaH just retiring products gradually.  If it was I'd expect to see maybe theJ HSZ40 go this year, the HSZ50 next etc. Not HSZ40, HSZ50, HSZ70 all in one go!o  M As for the HSC50 I still had two ot these online at a previous employer untilhJ well into the 90s. They were still on full support despite being well over ten years old.  I > I know HSZ70's are more dependent on firmware (and thus more vulnerable D > to firmware bugs and being unable to support newer disks without aG > firmware upgrade than many items on my list), but no more so than theu > various HSC's were.  >   L I repeat. None of the early HSC controllers were desupported within a couple" of years of customers buying them.   >-D > Is Compaq FORCING you to upgrade, or did they merely announce thatB > the older generation of storage is becoming obsolete in 2 years?  L No they have said that two year old technology (HSZ70 last ship) is obsoleteM now and software support will cease in 6 months. To show how out of line thisuL is the HSZ40 and HSZ50 are also being desupported at the same time. How long since they last shipped?   >eB > Will they still provide hardware service contracts, parts, etc.,E > like they always have in the past, or are they cutting you off with B > nothing?  Are there 3rd-party maintenance companies who would be > glad to have your business?n >.  H Hardware maintenance continues (although for how long?) but that doesn'tJ matter. We have already had one bouncing crash of an HSZ80 pair (each keptL crashing the other on reboot) fixed with a firmware upgrade. If such a thingH was to happen after support ends what do I do? In any case irrelevant asJ corporate policy would not let me run a production system with unsupportedI components. No other supplier of storage technology we deal with has ever K dropped support for a product only two years old. And certainly not for onee still sold such as the HSZ22.e     --
 Alan Greig   ------------------------------  % Date: Mon, 30 Jul 2001 18:29:51 -0400   From: John Santos <JOHN@egh.com>> Subject: Re: Obsolete storage (was:Re: Compaq's Q2 financials)6 Message-ID: <1010730180634.38008A-100000@Ives.egh.com>  % On Mon, 30 Jul 2001, Bill Todd wrote:-   > / > "John Santos" <JOHN@egh.com> wrote in message52 > news:1010730160740.36974A-100000@Ives.egh.com...* > > On Mon, 30 Jul 2001, Alan Greig wrote: >  > ...a > F > > > So my experience tells me that you won't like Conpaq in the end.I > > > Perhaps if Conpaq listened to its customers instead of telling themsC > > > that they like Conpaq (and even just making things up such asgG > > > "customer response has been unbelievably positive") you might get  > > > somewhere. > > > F > > > I am sure you will now tell me why Conpaq's current Storageworks* > > > reburials are good for the customer. > > > --
 > > > Alan > >aH > > Is this different from the obsolesense of HSC50's, HSC70's, HSC95's,H > > HSZ40's, HSZ50's, etc and RA8x/RZ9x/RZ26/RZ28/RZ29 etc, etc. that we" > > have gone through in the past? > J > Yes - and in a manner similar to the premature retirement of Alpha beingK > different from the relatively graceful retirement of VAX:  in both cases,1I > products that are still useful to a large number of customers are being E > guillotined with inadequate notice and with no suitable replacementLE > available at the time of the announcement (or even guaranteed to beM > available ever). >  > ...E > H > > Do you think any of the peripherals on your brand-new 1.5GHz P4 willJ > > work on your 2004 IA64 system (whether it's running VMS or M$ or Linux8 > > or AIX or whatever), when you replace it in 3 years?  F After I posted this, I realized I had said "IA64", but I didn't reallyB mean to exclude IA32 from the future system.  I was just comparing( today's high-end PC to 3 years from now.   > J > I can't speak for Alan, but I'm virtually certain that when I upgrade myI > currently-new AMD PC at about that time (likely to an AMD i86-64 unless L > Intel manages to do in that competitor as it did Alpha) they'll do exactlyM > that.  I seriously doubt that many PC users will be using IA64 in 2004:  iteF > won't be able to compete in price *or* performance with IA32 on IA32N > applications, let alone compete on price-performance, and there's no obviousG > killer 64-bit application on the horizon to compensate for that major 
 > deficiency.  >  >   (Average life ofB > > a PC, like a 1950's american automobile.)  Memory - no chance. > @ > And probably not interesting, if it continues its price slide. >  >   HardI > > disk?  IDE *might* work, but would be regarded as very small and slowo! > > by the standards of the time.  > M > IDE will almost certainly work and I expect my current dual 6.5 GB, 8.4 GB,oH > and 20 GB drives will still be quite useful - just as the 6.5s and 8.4I > (already oldish) and even a 2.1 and 850 MB drive remain useful today asi? > large removable devices and/or mirroring and/or backup disks.R  D Will IDE still be standard 3 years from now?  Or will most PC's ship( with SCSI or firewire or something else? > ) >   SCSI?  Maybe, unless SCSI-4 has taken 	 > > over.f > N > Is SCSI-4 planned to be less backward-compatible than SCSI-2 and SCSI-3?  If > not, there'll be no problem.  K All I know is what I got from a "future of SCSI" session at a DECUS severaldE years ago and what I've picked up from random articles in PC mag, butnE I thought SCSI-4 was supposed to be serial (one-bit wide), very fast,M# like a souped-up firewire, I think.l  B >   Floppy disk?  legacy ;-), you probably won't have or need one. > K > Yeah, right.  In the last couple of years I've used my 5.25" floppy driveeK > twice to obtain stuff I thought I'd never need again, and somehow I don't M > expect that situation to have changed by 2004 (at least for 3.5" floppies - > > by then I *hope* to have all my 5.25" floppy stuff retired).  E I was trying to remember the last time I used my floppy... I think it 1 was when I did a BIOS upgrade about 6 months ago.   E > > CD-ROM?  Try DVD.  DVD-ROM?  New systems will come with DVD-RW ora > > something similar... > H > But likely not with two of them, which will be convenient for copying.  C Most CD burners seem to work better when you copy CD-disk-CD rathereF then direct CD-CD.  Don't know if this will still be true with DVD-DVDA copies.  The problem is your running too close to the source CD'seE bottleneck, and if something hiccups and you miss a transfer, you getiB an output underrun and toast the output CD.  Hard disks are enough/ faster than CD's that this is much less likely.   F Still, it is handy to have more than one CD/DVD drive, so if it works,B and you have IDE ports, it is probably worth throwing your old one into the new box.n   >  > ...i > 
 >   Printers?oE > > Please - they're as dependent on manufacturer-supplied drivers as 
 > > anything.g  D Actually, my when I hooked my 1995-vintage Canon BJC-600e printer toD my new Win98 800 Mhz P3 last year, I had trouble finding drivers forB it, but when I installed W2K last winter, the drivers seemed to beD there.  Maybe W2K provides better driver compatibility than W95-W98?  D > Which is just one of the nice aspects of sticking with an existingK > architecture in an upward-compatible fashion, as AMD is doing:  I can runaM > not only my existing systems (if their descendants aren't fully compatible)>G > but all the other software on my brand new 2004 i86-64 PC just fine -n > including printer drivers. > 9 > Too bad the Alpha -> IA64 'upgrade' won't be as smooth.  >  > - bill  @ Don't have that many peripherals inside our Alphas now.  NetworkB printers, terminal servers/work-stations/PCs/Macs for user access,? HSx storage, etc.  Just plug the IA64 into the network, boot ita> and have it join the cluster.  Recompile the apps and away you@ go.  Can of corn.  (I'm pulling your leg here, but I do think it *should* be that easy...)t   --   John Santoss Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Mon, 30 Jul 2001 23:22:22 -0400x' From: "Bill Todd" <billtodd@foo.mv.com>l> Subject: Re: Obsolete storage (was:Re: Compaq's Q2 financials)( Message-ID: <9k58ai$rc6$1@pyrite.mv.net>  - "John Santos" <JOHN@egh.com> wrote in messagea0 news:1010730180634.38008A-100000@Ives.egh.com...   ...e  . > Will IDE still be standard 3 years from now?  L Yes:  you just can't beat a 3:1 price advantage (at least when the componentI is a major chunk of the total PC price).  The only question is whether it K will have evolved to serial IDE by then (not as difficult technically as iteK will be commercially:  a transition requires that people stock both old and H new styles, and it will take a while for the new volume to grow, so lookG first for serial IDE to start encroaching on traditional SCSI territoryo before hitting the mainstream).S  L But even if it has I'm sure that flexible use of old-style IDE will still beI possible - e.g., I'm currently using a $60 (including cable) USB externalnI IDE drive enclosure with several of my old drives as removable, portable,eJ high-performance, high-capacity storage/transfer media (best way I know ofJ to move large amounts of data among machines, including laptops:  100 MbitI Ethernet requires proximity, appropriate hardware, and network setup, and = burning CDs only works if every source machine has a burner).e   - bill   ------------------------------    Date: 30 Jul 2001 11:51:21 -0700, From: dframeli@aus.telusa.com (Dale Frameli) Subject: OpenVMS v1.5-1H1?= Message-ID: <de844d64.0107301051.54098259@posting.google.com>   = Anyone know where I can aquire a replacement disc for OpenVMS B v1.5-1H1?  I may have to replace a system disc soon and, AFAIK, noC ones seen the disc in more than 3~4 years.  I contacted Compaq, buttE they don't have it.  Are there any other sources I could try?  Please ! reply to: dframeli@aus.telusa.comi   Thanks   ------------------------------  # Date: Mon, 30 Jul 2001 22:24:04 GMTn2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)% Subject: Re: Oracle file size and VMSi1 Message-ID: <88l97.385$Yx2.7807@news.cpqcorp.net>u   In article <y41ymyabce.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>, Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:5 :hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes:f : H :>   The OpenVMS version of the C stat() call presently uses a longword  :>   for off_t.  b :[...]/ :>   I'll pass the request along to the C team.d :sH :I think Solaris has extended versions of all the usual C stuff for fileF :I/O. Possibly a way that could be followed (no need to re-invent thisB :particular wheel in an incompatible manner if it can be avoided).  ?   Tru64 UNIX is also of central interest, as many of the tools a,   involved also operate in that environment.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   Date: 30 Jul 2001 23:39:43 GMT% From: "Paul Dembry" <pade@trifox.com>m0 Subject: Re: Passing a socket to another process0 Message-ID: <9k4r7v$9n1@dispatch.concentric.net>  ? "Eugene A Zharkov" <zharkov@vista-control.com> wrote in message + news:3B632497.EACDA07B@vista-control.com...d< > I have found in comp.os.vms an example of passing a socket6 > to another process that is based on the sys$creprc's< > prc$m_netwrk option. But there is still a couple of things& > that I am not sure how to deal with. > > > 1. The prc$m_netwrk is not documented very well. Maybe there@ > is a better (documented) way of doing this (on VMS 7.1/UCX 5.0 > and higher). >l= > 2. If my process is started by inetd, I can open the socketa@ > using the socket(TCPIP$_AUXS) call. But I can't make my master8 > server open/pass the socket in the way that would make: > TCPIP$_AUXS to work. I noticed, for example, that the bg7 > device created by inetd has a "Reference count" of 0.m: > Mine is 1. What does inetd do to make the bg device stay$ > alive with the reference count 0 ?L How about doing a vfork()/exec() pair?  Have the "parent" do a dup2() of theG socket to a known file descriptor slot and then exec() the new process. L When it comes up, it does a dup() of that known file descriptor slot and you are ready to go. Paul   ------------------------------  % Date: Mon, 30 Jul 2001 16:13:44 -0700r3 From: David Spencer <spencer@spaamfree.recneps.com>,1 Subject: Quick DCL question - maximum open files?Z> Message-ID: <300720011613449556%spencer@spaamfree.recneps.com>  H I tried looking through the documentation and the FAQ without results...  B I just want to know, what's the maximum number of files that I can? open at once using a DCL command procedure? And is that tunablee via parameters in authorize?   Thanks all,w   -- Dave Spencerl   ------------------------------  # Date: Tue, 31 Jul 2001 00:59:04 GMTo2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)5 Subject: Re: Quick DCL question - maximum open files? 1 Message-ID: <spn97.400$Yx2.7834@news.cpqcorp.net>   t In article <300720011613449556%spencer@spaamfree.recneps.com>, David Spencer <spencer@spaamfree.recneps.com> writes:I :I tried looking through the documentation and the FAQ without results...k  B   OpenVMS version and platform?  (Yes, these can have an effect on   your particular limits.)  C :I just want to know, what's the maximum number of files that I cani@ :open at once using a DCL command procedure? And is that tunable :via parameters in authorize?   5   A simple loop would tell you your current limits.  v  C   DCL channels are subject to the same CHANNELCNT system parameter aA   settings and the same BYTLM and FILLM process settings as most r   everything else I/O.     N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Mon, 30 Jul 2001 20:17:24 -0700e3 From: David Spencer <spencer@spaamfree.recneps.com>/5 Subject: Re: Quick DCL question - maximum open files?n> Message-ID: <300720012017246772%spencer@spaamfree.recneps.com>  > In article <spn97.400$Yx2.7834@news.cpqcorp.net>, Hoff Hoffman& <hoffman@xdelta.zko.dec.nospam> wrote:  N > In article <300720011613449556%spencer@spaamfree.recneps.com>, David Spencer) > <spencer@spaamfree.recneps.com> writes: K > :I tried looking through the documentation and the FAQ without results...t > D >   OpenVMS version and platform?  (Yes, these can have an effect on >   your particular limits.) > E > :I just want to know, what's the maximum number of files that I canlB > :open at once using a DCL command procedure? And is that tunable > :via parameters in authorize?e > 7 >   A simple loop would tell you your current limits.  e > E >   DCL channels are subject to the same CHANNELCNT system parameter sC >   settings and the same BYTLM and FILLM process settings as most u >   everything else I/O. >    > P >  ---------------------------- #include <rtfaq.h> -----------------------------P >       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    P >  --------------------------- pure personal opinion ---------------------------N >    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com  G Thanks for jumping in Hoff. I talking about AXP/VMS 7.2-1. I've managed:G hit the wall at 28 simultaneous open files. I was hoping to get more ifDB I could.  CHANNELCNT is already at 32767. FILLM is at 300. HoweverC BYTLM is not particularly large so I could increase that. Any other0 parameters?A   Thanks again,    -- Dave Spencer    ------------------------------  % Date: Mon, 30 Jul 2001 16:52:03 -0700n3 From: "Jeremy Estep" <jeremy@globalitresources.com>t Subject: RTMG Message-ID: <NEBBIHDGALNMMGAMHFGLAEFMDAAA.jeremy@globalitresources.com>n   Hello,  F I am looking for IT pros. with knowledge in RTM (Real-time Transaction Manager) that runsI on VAX's VMS.  I have never heard of it?  Is this the correct acronym?  I  look forward to  your response.  
 Best Regards,    Jeremy Estep International Resourcer0 Global IT Resources,Inc. jeremy@globalitresources.com& Tel:(562)628-5592 Mobile:(310)704-8185 Fax:(866)728-0259d   ------------------------------  # Date: Tue, 31 Jul 2001 01:22:04 GMTd2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: RTM1 Message-ID: <0Ln97.401$Yx2.7906@news.cpqcorp.net>a  } In article <NEBBIHDGALNMMGAMHFGLAEFMDAAA.jeremy@globalitresources.com>, "Jeremy Estep" <jeremy@globalitresources.com> writes:o  G :I am looking for IT pros. with knowledge in RTM (Real-time TransactioneF :Manager) that runs on VAX's VMS.  I have never heard of it?  Is this  :the correct acronym?  a     Probably not.b  @   RTR (Reliable Transaction Router) on OpenVMS VAX, most likely.  H   VAX is the hardware.  VMS (now called OpenVMS) is the operating systemH   software.  (I sometimes believe that recruiters can use the occasionalE   and various canard and even the occasional phrasing ruse, obviouslyeJ   seeking those candidates familiar with the acronyms and the terminology.   But I digress.)s  K   There are other related products and environments, including transaction -K   managers, databases, and such.  Examples of these other products include  K   DECdtm (distributed transaction manager), Oracle (both classic and Rdb), aH   clustering, and messaging middleware such as MessageQ, IBM MQ Series, G   etc.  Something called RTM (Routine Transaction Manager) does exist, iJ   but RTM is a component of another environment, and (unlike RTR) is only 1   very rarely considered as a separate component.n  G   Also the products and product versions on OpenVMS Alpha, of course.  gG   And then there is the port of OpenVMS to the Intel Itanium Processor d-   Family (IPF), a project presently underway.s  G   RTM is sometimes used as an acronym for Read The Manual, though RTFM  4   (Read The Fine Manual, etc) is also in common use.  E   And thankfully you seek only IT pros[e], and not IT pentameter. :-)l6   (I'd really hate to have to make rhyme from reason.)  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Mon, 30 Jul 2001 19:48:58 GMTd' From: Rick Dyson <Rick-Dyson@UIowa.EDU> ) Subject: Re: SAN-based Backup for OpenVMSp) Message-ID: <3B65BA2A.4991C8F2@UIowa.EDU>    Scott Vieth wrote:  T > 1) Putting anything other than disks in an ESA12000/EMA12000 is strictly verboten.  G 	Why is this so?  I don't know the exact plans of our I/O people, but IsO got the impression that they were always talking about dropping the MLxxxx SDLTZD drive into the EMA12000 enclosure along with the Modular Data Router interface...  S > 3) I know what you're looking for ("server-less backup") but I haven't seen it inlO > the VMS space yet.  I think Compaq is close to rolling out a solution for thesT > NT/2000 world.  It involves using Backup Exec (or a similar competing product) and > the Modular Data Router.  B 	Indeed.  I want to be able to do this to keep performance up, butL have it make VMS-compatible tapes.  Using Veritas or Legatto to do this willE probably mean the tapes could not be used directly by VMS to recover.e  @ 	It appears the only options are to just move the data over the F interconnect to the VMS box and then back out to the tape drive.  ThusJ the data has to travel through the FC connection twice where it could have stayed within the SAN...   Thanks,i Rick -- oH Richard L. Dyson                                    rick-dyson@uiowa.eduH  _   _  _____                    http://www-pi.physics.uiowa.edu/~dyson/H | | | ||_   _|  Senior Systems Analyst  --  INFORMM-Cerner Systems Group< | | | |  | |    The University of Iowa Hospitals and ClinicsH | \_/ | _| |_   Information Systems BT1000 GH       Office: 319/384-7016H  \___/ |_____|  Iowa City, IA 52242-1052               FAX: 319/384-7020   > -scott >  > Rick Dyson wrote:h > K > > Does anyone know if there are any solutions available for using some ofaS > > the big, new SDLT tape library boxes in an EMA 12000 SAN with HSG80 controllersa? > > and using Fiber Channel for interconnects to OpenVMS Alphasi > > running v7.2-1?t > >cM > > In particular, I am researching the possiblility of performing the backupeS > > between the SAN-served disks and the SDLT drive *without* needing to move everylQ > > byte to and from the OpenVMS server too.  That is, keep all the data movement ! > > within the fabric of the SAN.a   ------------------------------  # Date: Mon, 30 Jul 2001 19:53:02 GMTt' From: Rick Dyson <Rick-Dyson@UIowa.EDU>r) Subject: Re: SAN-based Backup for OpenVMSE) Message-ID: <3B65BB1E.9603A6A5@UIowa.EDU>l   Hamlyn Mootoo wrote: > E > Are you planning on doing block for block physical backups, disk to < > tape? What happens when you want to restore a single file? >  > HM  C 	The idea is "server-less" backup.  Where the OpenVMS host software F simply tells the SAN to make a backup of the OpenVMS disks to the SAN-H connected SDLT drive.  This would eliminate data flow off the SAN to theE Host and back to the SAN to the tape drive.  It would off-load serveri	 CPU load.-  B 	The goal would be that the backup tape would be OpenVMS-compliantI such that I could recover individual files or entire disks, etc.  Just ase I can with "normal" backups.  D 	I think this is available for Tru64 and NT/2k, but not for OpenVMS.H That is why I made this inquiry here, to see if I have missed something.     Rick -- yH Richard L. Dyson                                    rick-dyson@uiowa.eduH  _   _  _____                    http://www-pi.physics.uiowa.edu/~dyson/H | | | ||_   _|  Senior Systems Analyst  --  INFORMM-Cerner Systems Group< | | | |  | |    The University of Iowa Hospitals and ClinicsH | \_/ | _| |_   Information Systems BT1000 GH       Office: 319/384-7016H  \___/ |_____|  Iowa City, IA 52242-1052               FAX: 319/384-7020   ------------------------------  % Date: Mon, 30 Jul 2001 21:22:26 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>h- Subject: Re: Selling VMS to another company ?c' Message-ID: <3B661662.9177A311@fsi.net>n   John McLean wrote: >  > "Doc.Cypher" wrote:i >  > (snip) > O > > Since the deed has been done and the Alpha platform must now serve its time F > > on death row, perhaps we should return to berating the Q for theirH > > marketing incompetence. The handling of the Alpha decision is simply= > > another example of their ability to fire off footbullets.e > C > And if they are not careful, it will be both barrels, both feet !9  G Well, considering their "feet" end just below their eye sockets at thish1 point, I don't see as there is much left to lose.a   Fire at will! (Poor Will!)   -- m David J. Dachteraa dba DJE Systemsb http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/a   ------------------------------  # Date: Mon, 30 Jul 2001 22:25:14 GMTn2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)+ Subject: Re: Sun goes after Alpha user base 1 Message-ID: <e9l97.386$Yx2.7844@news.cpqcorp.net>-  ] In article <3B656046.35C733AE@uk.sun.com>, andrew harrison <andrew.nospam@uk.sun.com> writes:  :Newbie JrSysAdmin wrote:l :> o :> fabio compaq@ep-bc.petrobras.com.br wrote in message news:<OF102DC867.54EBEE45-ON03256A95.00629221@ep-bc.petrobras.com.br>...K :> > Sun won here ......  5 x E-10000 to substitute more than 25 Alphas andi :> > Vaxes and otherG :> > RISC machines in our SAP project .... my countdown to turn off  myh :> > Alphaservers systems is :bI :> i hope you got a good price on those 10ks, 'cuz they're old-news slow.6 :6? :Really, so where does that put WildFire, out of date before it  :was launched. :):):):)m     On parity, of course..    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Mon, 30 Jul 2001 17:56:01 GMT B From: Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP>< Subject: Re: TCPIP v5.1 startup on dial-up service provider.6 Message-ID: <Rch97.11727$ar1.35595@www.newsranger.com>  . On Mon, 30 Jul 2001 12:52:56 +1000, in articleM <D750FFBD4936D111842000805F15EFA4043A879E@meppb1.pacificpower.com.au>, Arena,i Steve wrote: >rL >I'm wanting to use an Alpha 255 VMS V7.1 ,UCX V4 or V5, as a firewall for aH >dial-up connection to an ISP. Any suggestions as to where to start? For= >example, how do you configure the modem and the serial port?i >s >Thanks  >Steve >e  G [I have left the original thread in so that you can refer to what otherr5 issues you may encounter if you get past this stage.]t  H In my case, the modem was connected via a terminal server and not directJ to a serial port on the Alpha. I ran the PPP connection over LAT. This wasJ over a year ago (I have been ISDN router based since then), so I no longerH have the modem or terminal server port flow control settings. I did haveF the modem set (as do _all_ my modems) to drop the line on loss of DTR.  I I used an auto-dialer that I wrote myself to open up the modem on the LTAtK device, dial the ISP, and then login via a scripted login. [Before you ask,AL I wrote the auto-dialer for work, so I am not allowed to make it available.]  M The auto-dialer then exited and the command procedure calling it then createdoI the PPP link to the modem. During this transfer to a PPP link, there is aaK very short period during which no channel is active to the modem, and hence  DTR is not asserted.  K To stop the modem dropping the line on loss of DTR, I needed to use a modem J that could be configured to wait to see if DTR was reasserted. The modem II used was set to 2.55 seconds delay (it's maximum setting) and this provedh to be sufficient in use.  J I must point out once again, that the only time that I have ever crashed aE VMS system was while getting PPP to work. I also found various timingtC problems in the PPP code that caused the LTA line to not always geteD correctly converted back to a terminal line after a pppd disconnect.  I There was a PPP patch released a few months ago, but I don't remember forb which versions.a   Simon.   >> -----Original Message-----eJ >> From:	Simon Clubley [SMTP:simon_clubley@remove_me.excite.com-Earth.UFP]# >> Sent:	Friday, 27 July 2001 22:25- >> To:	Info-VAX@Mvb.Saic.Com? >> Subject:	Re: TCPIP v5.1 startup on dial-up service provider.V >> Q1 >> On Fri, 27 Jul 2001 07:44:51 +0100, in article-A >> <3B611BF3.37F654C3@ipl.demon.co.nospam.uk>, Steve Reece wrote:  >> >E >> >I'm now a subscriber to a dial-up ISP but there is (at least) one-
 >> >problem :- >> >F >> >As part of my configuration of TCPIP Services for OpenVMS v5.1 (onD >> >Alpha) I have smtp configured to use my ISP's smtp server as itsK >> >alternate gateway.  When TCP/IP starts it expects to be able to see theo; >> >server (as it did with v4.2 as well) so I have to do anlJ >> >@SYS$STARUTP:TCPIP$STARTUP, wait for it to pause and then do my dialup, >> >in order for TCP/IP Services to startup.L >> >Any ideas what I might do to ease the situation and have TCP/IP Services' >> >start as part of my system startup?e >> >H >> >Environment is a DEC 3000 model 600 workstation running OpenVMS v7.3I >> >with TCP/IP Services for OpenVMS Version 5.1.  Dialup connection usesoC >> >PPP and the number is stored in the configuration on the modem.T >> > >> >Thanks in advance.
 >> >Steve. >>  K >> [Based on your address, I'm assuming that the ISP in question is Demon.]. >> tH >> My production machine is VMS Alpha 7.1, UCX 4.2, ECO 4. I used to use >> PPP/SLIPmH >> dialup, but now use a ISDN LAN based router. I also have my alternate
 >> gatewayL >> set to post.demon.co.uk, but I have never experienced the problem you are2 >> describing, either now or when I used SLIP/PPP. >> tM >> I suspect that it is because I have a different routing setup. How are youiJ >> defining your route to Demon ? Are you using a default gateway, or justJ >> enabling specific routes ? Are your routes defined all the time or just >> whenm >> you need to dialup ?c >> iK >> In my setup, routes are defined at the time of dialup and removed by thee >> batchL >> job that initiated the dialup when the job has finished collecting E-Mail >> ortK >> FTPing files. I do not use a default gateway, but only define routing topJ >> the required subnets. If I want to web browse from this machine, I have >> LynxhK >> setup to use Demon's proxy server, so I only need to set a subnet to the  >> proxy server. >> 1I >> I think your problem may be that you have a route to Demon permanently:	 >> setup,DK >> so startup hangs. If you can define the route only when you need to, theo >> problem may go away.0 >> 1	 >> Simon.s >> rK >> PS: Be aware that the only time I have ever crashed a VMS box was when I:K >> tried to get PPP working. I think that there are patches for the various  >> problems that I uncovered.m   -- ,; Simon Clubley, simon_clubley@remove_me.excite.com-Earth.UFPIK In the task of removing Microsoft from the marketplace, I have discovered aoE truly remarkable plan, but this signature is too small to contain it.    ------------------------------  % Date: Mon, 30 Jul 2001 23:58:53 +0100 1 From: Steve Reece <SYSTEM@ipl.demon.co.nospam.uk>y< Subject: Re: TCPIP v5.1 startup on dial-up service provider.6 Message-ID: <3B65F4BD.6F07BEAA@ipl.demon.co.nospam.uk>  E This raises another question Simon - how do you mean that you ran the-F ppp connection over LAT?  One of the configurations that I've heard ofG is connecting the modem up to a port on a terminal server but I thought-A that this arrangement would only permit a connection to a similar  combination at the other end.- Steve R.   Simon Clubley wrote: > 0 > On Mon, 30 Jul 2001 12:52:56 +1000, in articleO > <D750FFBD4936D111842000805F15EFA4043A879E@meppb1.pacificpower.com.au>, Arena,p > Steve wrote: > >DN > >I'm wanting to use an Alpha 255 VMS V7.1 ,UCX V4 or V5, as a firewall for aJ > >dial-up connection to an ISP. Any suggestions as to where to start? For? > >example, how do you configure the modem and the serial port?c > >D	 > >Thanksr > >Steve > >a > I > [I have left the original thread in so that you can refer to what othert7 > issues you may encounter if you get past this stage.]l > J > In my case, the modem was connected via a terminal server and not directL > to a serial port on the Alpha. I ran the PPP connection over LAT. This wasL > over a year ago (I have been ISDN router based since then), so I no longerJ > have the modem or terminal server port flow control settings. I did haveH > the modem set (as do _all_ my modems) to drop the line on loss of DTR. > K > I used an auto-dialer that I wrote myself to open up the modem on the LTArM > device, dial the ISP, and then login via a scripted login. [Before you ask,-N > I wrote the auto-dialer for work, so I am not allowed to make it available.] > O > The auto-dialer then exited and the command procedure calling it then created-K > the PPP link to the modem. During this transfer to a PPP link, there is a M > very short period during which no channel is active to the modem, and hence/ > DTR is not asserted. > M > To stop the modem dropping the line on loss of DTR, I needed to use a modem.L > that could be configured to wait to see if DTR was reasserted. The modem IK > used was set to 2.55 seconds delay (it's maximum setting) and this proveda > to be sufficient in use. > L > I must point out once again, that the only time that I have ever crashed aG > VMS system was while getting PPP to work. I also found various timingNE > problems in the PPP code that caused the LTA line to not always get F > correctly converted back to a terminal line after a pppd disconnect. > K > There was a PPP patch released a few months ago, but I don't remember for  > which versions.f >  > Simon. >  > >> -----Original Message-----eS > >> From:        Simon Clubley [SMTP:simon_clubley@remove_me.excite.com-Earth.UFP]s, > >> Sent:        Friday, 27 July 2001 22:25 > >> To:  Info-VAX@Mvb.Saic.Com-E > >> Subject:     Re: TCPIP v5.1 startup on dial-up service provider.a > >>3 > >> On Fri, 27 Jul 2001 07:44:51 +0100, in articleeC > >> <3B611BF3.37F654C3@ipl.demon.co.nospam.uk>, Steve Reece wrote:H > >> >G > >> >I'm now a subscriber to a dial-up ISP but there is (at least) onea > >> >problem :  > >> >H > >> >As part of my configuration of TCPIP Services for OpenVMS v5.1 (onF > >> >Alpha) I have smtp configured to use my ISP's smtp server as itsM > >> >alternate gateway.  When TCP/IP starts it expects to be able to see the = > >> >server (as it did with v4.2 as well) so I have to do an L > >> >@SYS$STARUTP:TCPIP$STARTUP, wait for it to pause and then do my dialup. > >> >in order for TCP/IP Services to startup.N > >> >Any ideas what I might do to ease the situation and have TCP/IP Services) > >> >start as part of my system startup?  > >> >J > >> >Environment is a DEC 3000 model 600 workstation running OpenVMS v7.3K > >> >with TCP/IP Services for OpenVMS Version 5.1.  Dialup connection useslE > >> >PPP and the number is stored in the configuration on the modem.  > >> > > >> >Thanks in advance. > >> >Steve. > >>M > >> [Based on your address, I'm assuming that the ISP in question is Demon.]n > >>J > >> My production machine is VMS Alpha 7.1, UCX 4.2, ECO 4. I used to use
 > >> PPP/SLIPiJ > >> dialup, but now use a ISDN LAN based router. I also have my alternate > >> gatewayN > >> set to post.demon.co.uk, but I have never experienced the problem you are4 > >> describing, either now or when I used SLIP/PPP. > >>O > >> I suspect that it is because I have a different routing setup. How are you L > >> defining your route to Demon ? Are you using a default gateway, or justL > >> enabling specific routes ? Are your routes defined all the time or just	 > >> whent > >> you need to dialup ?e > >>M > >> In my setup, routes are defined at the time of dialup and removed by the.
 > >> batchN > >> job that initiated the dialup when the job has finished collecting E-Mail > >> orpM > >> FTPing files. I do not use a default gateway, but only define routing to-L > >> the required subnets. If I want to web browse from this machine, I have	 > >> Lynx M > >> setup to use Demon's proxy server, so I only need to set a subnet to the  > >> proxy server. > >>K > >> I think your problem may be that you have a route to Demon permanently9 > >> setup,EM > >> so startup hangs. If you can define the route only when you need to, the2 > >> problem may go away.r > >> > >> Simon.h > >>M > >> PS: Be aware that the only time I have ever crashed a VMS box was when IaM > >> tried to get PPP working. I think that there are patches for the various2 > >> problems that I uncovered.l >  > --= > Simon Clubley, simon_clubley@remove_me.excite.com-Earth.UFPvM > In the task of removing Microsoft from the marketplace, I have discovered aqG > truly remarkable plan, but this signature is too small to contain it.e   --  G "A shadow fell over her face; clear, as if the composure were rent likeeE a veil.  And her lips parted, but only with a short intake of breath.tA Then she said, 'Well, then you are right.  Indeed, we are even.'"o% 		Louis, "Interview with the Vampire"l   ------------------------------  % Date: Mon, 30 Jul 2001 22:19:19 -0000a- From: wspencer@ap.nospam.org (Warren Spencer)t5 Subject: Unsupported Conjecture:  Prune Q for Suitor?h/ Message-ID: <tmbnb7gmhr4p2a@news.supernews.com>i  D In the spirit of unsubstantiated comspiracy theories, I spin thusly:  I It seems many companies will shed divisions just prior to being bought.  eK Sometimes a division (such a Alpha) needs to be dumped because it competes  G with a corporate ally.  For instance, if Microsoft bought Compaq, they  G wouldn't want Alpha - since it competes with their buddy Intel.  Could |H Compaq be pruning itself for a Intel-friendly suitor?  It might explain D their "apparent" lack of engineering or financial arguments for the  decision to axe Alpha.   ws   --     Warren Spencer Senior Software Engineer The Associated Press  L ** My employer does not necessarily agree with my statements - neither do I  **   ------------------------------  % Date: Mon, 30 Jul 2001 21:24:45 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>I9 Subject: Re: Unsupported Conjecture:  Prune Q for Suitor? , Message-ID: <3B6608DA.97256184@videotron.ca>   Warren Spencer wrote:oH > wouldn't want Alpha - since it competes with their buddy Intel.  CouldI > Compaq be pruning itself for a Intel-friendly suitor?  It might explain-E > their "apparent" lack of engineering or financial arguments for thes > decision to axe Alpha.  I Considering their stagnant stock price and the fact that their brand nameUL *still* has some value, it would seem to be a interesting pick. However, who< would want to get involved in the low margin manufacturing ?  M Would Bush tolerate that the Japanese buy Compaq ? I could see an outfit such M as Sony or some other large asian outfit getting its hands on Compaq as a wayO to get to the USA market.o   ------------------------------  # Date: Mon, 30 Jul 2001 21:33:54 GMTo2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)1 Subject: Re: VMS marketing event in Cupertino, CAt1 Message-ID: <6pk97.381$Yx2.7698@news.cpqcorp.net>h  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.  F   If someone here has kept a copy of the mail message, please forward &   it along and I'll see what happened.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------    Date: 30 Jul 2001 11:05:23 -0700( From: Hodapp87@weasel.net (Chris Hodapp) Subject: What exactly is VMS?t< Message-ID: <1b179cd3.0107301005.10f98ad@posting.google.com>  E What exactly is VMS? Did DEC originally make it for their VAXes? I've E seen stuff like VAX\VMS... Was it something like Unix? Did it competetF with Unix? What was it like? Am I asking too many questions? I think I am. A Sooooooooo can someone explain some of the historical stuff aboutiD VMS... how it was layed out... what it was like... things like that?    Thanks people...................   ------------------------------    Date: 30 Jul 2001 14:15:12 -0500 From: briggs@encompasserve.org! Subject: Re: What exactly is VMS?h3 Message-ID: <4Sp84KZnVY4q@eisner.encompasserve.org>l  g In article <1b179cd3.0107301005.10f98ad@posting.google.com>, Hodapp87@weasel.net (Chris Hodapp) writes:oG > What exactly is VMS? Did DEC originally make it for their VAXes? I've-G > seen stuff like VAX\VMS... Was it something like Unix? Did it competenH > with Unix? What was it like? Am I asking too many questions? I think I > am.e  4 http://www.openvms.compaq.com/wizard/OpenVMS_faq.txt   An operating systemm Yesd That's nice< Yes and no.@ Yesn RSX  Yess You are correctA   ------------------------------  % Date: Mon, 30 Jul 2001 15:17:09 -0300 ) From: fabio_compaq@ep-bc.petrobras.com.br2! Subject: Re: What exactly is VMS?SL Message-ID: <OF083CC50B.D85EE2EF-ON03256A99.00644F00@ep-bc.petrobras.com.br>   Well  1 You should begin at http://www.openvms.compaq.com    Or to be right....  : http://www.openvms.compaq.com/openvms/brochures/index.html  < http://www.openvms.compaq.com/openvms/WHITEPAPERS/INDEX.HTML     Regardso   FC    S                                                                                    eS                     Hodapp87@weas                                                  -S                     el.net (Chris        Para:   Info-VAX@Mvb.Saic.Com             -S                     Hodapp)              cc:                                       SS                                          Assunto:     What exactly is VMS?         -S                     30/07/2001                                                     uS                     15:05                                                          iS                     Responder a                                                    lS                     Hodapp87                                                       cS                                                                                    .S                                                                                    a        E What exactly is VMS? Did DEC originally make it for their VAXes? I'veaE seen stuff like VAX\VMS... Was it something like Unix? Did it competeiF with Unix? What was it like? Am I asking too many questions? I think I am.aA Sooooooooo can someone explain some of the historical stuff aboutnD VMS... how it was layed out... what it was like... things like that?    Thanks people...................   ------------------------------  % Date: Mon, 30 Jul 2001 14:31:29 -0400e0 From: "Syltrem" <syltrem@videotron.ca.spammenot>! Subject: Re: What exactly is VMS?a5 Message-ID: <aJh97.49735$TW.248563@tor-nn1.netcom.ca>    Hi  J First, don't talk about it like a thing of the past. It's still around and hopefully it will stay!l  L It was designed specifically for the VAX's, and was a kind of new generation to follow the PDP's.  L It does compete with Unix. It is a very stable and well-made OS. The commandK syntax is intuitive with english words, error messages are most meaningful,PF and programming standards using system routines is very well designed.  J This is the best OS ever made, but it also is the one that is marketed theL worst. It was the 1st OS to run on a 64 bits Alpha processor, it and the new
 Digital Unix.fE OpenVMS is the OS that introduced clusters - real clusters. Now Tru64t9 (former Digital Unix) is taking over all this good stuff.s  G Go to http://www.openvms.compaq.com/ to learn more about it from CompaqhL itself. Or go to the webring at http://www.tetranet.net/taylor/tms/ovmsring/1 to know more from it`s users. Also have a look atoL http://enterprise.cnet.com/enterprise/0-9566-601-1751615.html?pn=1&lb=0&ob=1@ &tag=st.it.9566.top.1751615-1 to see what people thing about it.     --   Syltremb; http://pages.infinit.net/syltrem (OpenVMS related web site)e    B "Chris Hodapp" <Hodapp87@weasel.net> a crit dans le message news:1 1b179cd3.0107301005.10f98ad@posting.google.com...IG > What exactly is VMS? Did DEC originally make it for their VAXes? I'vecG > seen stuff like VAX\VMS... Was it something like Unix? Did it compete>H > with Unix? What was it like? Am I asking too many questions? I think I > am.oC > Sooooooooo can someone explain some of the historical stuff aboutbF > VMS... how it was layed out... what it was like... things like that? > " > Thanks people...................   ------------------------------  % Date: Mon, 30 Jul 2001 15:31:32 -0300P+ From: <fabio_compaq@ep-bc.petrobras.com.br> ! Subject: Re: What exactly is VMS?wL Message-ID: <OF751142FA.2C7711AE-ON03256A99.00658AB8@ep-bc.petrobras.com.br>  I Virtual Memory System ..... like Unix is, like NT is,  it is enough ! ! !    RegardsI   FC              T                                                                                     T                     briggs@encompa                                                  T                     sserve.org            Para:   Info-VAX@Mvb.Saic.Com             T                                           cc:                                       T                     30/07/2001            Assunto:     Re: What exactly is VMS?     T                     16:15                                                           T                     Responder a                                                     T                     briggs                                                          T                                                                                     T                                                                                             < In article <1b179cd3.0107301005.10f98ad@posting.google.com>,* Hodapp87@weasel.net (Chris Hodapp) writes:G > What exactly is VMS? Did DEC originally make it for their VAXes? I'veeG > seen stuff like VAX\VMS... Was it something like Unix? Did it compete H > with Unix? What was it like? Am I asking too many questions? I think I > am.n  4 http://www.openvms.compaq.com/wizard/OpenVMS_faq.txt   An operating systemq Yes  That's nice  Yes and no.r Yesf RSXh Yesc You are correctL   ------------------------------  # Date: Tue, 31 Jul 2001 00:53:03 GMTt2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)! Subject: Re: What exactly is VMS?t1 Message-ID: <Pjn97.399$Yx2.7877@news.cpqcorp.net>g  g In article <1b179cd3.0107301005.10f98ad@posting.google.com>, Hodapp87@weasel.net (Chris Hodapp) writes:rF :What exactly is VMS? Did DEC originally make it for their VAXes? I'veF :seen stuff like VAX\VMS... Was it something like Unix? Did it compete@ :with Unix? What was it like? Am I asking too many questions?...B :Sooooooooo can someone explain some of the historical stuff aboutE :VMS... how it was layed out... what it was like... things like that?k  I   Please acquire the OpenVMS FAQ.  Please read it, and read through some -H   of the pointers included in the FAQ -- particularly the pointer to the<   20th anniversary book (PDF) for most of these questions.    B   Then please come back here with any questions that might remain.  K   You incorrectly use the past-tense.  OpenVMS runs various stock markets, aI   parts of the federal reserve, semiconductor fabrication lines, and manyvK   other applications.  A port of OpenVMS to Intel Itanium Processor Family h:   systems is presently underway, and several new releases.  I   A (free) hobbyist program -- again, please see the FAQ -- is available.tI   This program includes the operating system and a wide variety of tools.1  >   Among many other websites, the OpenVMS FAQ is available at:   "     http://www.openvms.compaq.com/    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Mon, 30 Jul 2001 21:55:36 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>i! Subject: Re: What exactly is VMS?h' Message-ID: <3B661E28.8E417C12@fsi.net>s   Hoff Hoffman wrote:  > i > In article <1b179cd3.0107301005.10f98ad@posting.google.com>, Hodapp87@weasel.net (Chris Hodapp) writes:oH > :What exactly is VMS? Did DEC originally make it for their VAXes? I'veH > :seen stuff like VAX\VMS... Was it something like Unix? Did it competeB > :with Unix? What was it like? Am I asking too many questions?...D > :Sooooooooo can someone explain some of the historical stuff aboutG > :VMS... how it was layed out... what it was like... things like that?e > J >   Please acquire the OpenVMS FAQ.  Please read it, and read through someJ >   of the pointers included in the FAQ -- particularly the pointer to the< >   20th anniversary book (PDF) for most of these questions. [snip]  < Somehow, the humor of the original post was lost, I think...   --   David J. Dachtera  dba DJE Systemsh http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/n   ------------------------------   Date: 31 Jul 2001 03:40:48 GMT From: bk4leg@aol.com (BK4Leg)t  Subject: What's in it for Intel?: Message-ID: <20010730234048.23939.00001457@ng-cm1.aol.com>  O Compaq as part of the agreement turns over the compiler and infrastructure toolL development to Intel.e  M I still cannot figure out what Intel gains from that in the longer term.  How O does this profit Intel - which I still perceive as a chip manufacturer ?  I cancI see where they gain from the Alpha technology, licenses,  and experienced:O design team, but compilers and infrastructure tools??    Any insights, please ?S  J If Intel in 2005 or so decides that having this expense of development andL support for compilers and infrastructure tools is not financially justified,L and kills it off, what does that mean for VMS and Tru64 ?  In fact, why evenC wait for 2005 to kill off those groups, unless contractually bound.s  N I can picture Compaq in 2005 or so stating that *they* still support VMS - but' oh, you wanted compilers with that OS ?S   Bernie     ------------------------------  % Date: Tue, 31 Jul 2001 00:33:34 -0400s- From: JF Mezei <jfmezei.spamnot@videotron.ca>P$ Subject: Re: What's in it for Intel?, Message-ID: <3B663510.EB8B470A@videotron.ca>  
 BK4Leg wrote: O > I still cannot figure out what Intel gains from that in the longer term.  HowlQ > does this profit Intel - which I still perceive as a chip manufacturer ?  I can K > see where they gain from the Alpha technology, licenses,  and experiencedt9 > design team, but compilers and infrastructure tools??     J By getting the supposedly superior Digital compilers adapted for the IA64,I Intel may be able to generate code which yields higher performance and if J Intel wants to pit its chips at the high performance market, then compilerO performance will be important, especially if the chip is initiually heavy/slow.   G It may may Compaq irrelevant since it won't have any edge over Dell for.R compilers, but it will pit Intel against IBM and Sun for high performance systems.   ------------------------------  # Date: Tue, 31 Jul 2001 04:56:19 GMT . From: "Duane Sand" <duane.sand@mindspring.com>$ Subject: Re: What's in it for Intel?> Message-ID: <TTq97.16819$Kd7.9877140@news1.rdc1.sfba.home.com>   "BK4Leg" wrote:pL > Compaq as part of the agreement turns over the compiler and infrastructure > tool development to Intel.J > I still cannot figure out what Intel gains from that in the longer term.? > How does this profit Intel - which I still perceive as a chipf
 manufacturer?eE > I can see where they gain from the Alpha technology, licenses,  and C > experienced design team, but compilers and infrastructure tools??P > Any insights, please?   7 Intel is greedy for experienced compiler design talent.i9 The eventual performance of IA64 depends as much upon newa; compiler technology that has not yet been invented, as upono8 new circuit designs or fab lines.  The GEM experience in1 optimizing for a simple (but OOO) RISC is helpfulr4 in optimizing for IPF; every RISC optimization has a5 counterpart in IPF.  The GEM designers' inventivenesse5 is equally helpful for doing new optimizations uniquen9 to IPF's unusual new features.  Intel's current compilersc3 did well enough already on McKinley Spec benchmarkso6 to convince Compaq mgmt that IPF's future is promising5 rather than a dud.  But there's lots of potential forb further compiler improvements.  3 Some researchers say that OOO-style implementations 8 of sequential RISC instructions will soon max out in the3 amount of useful work completed per cycle.  Whereas : the inherently parallel dispatch of IPF instruction groups6 could lead to massive parallelism on many application-6 specific vector-like loops -- not just those few loops/ now hardcoded into MMX ops.  I don't expect anyn7 vector speedups in commercial workloads.  But for those-6 workloads, IPF has other tricks that may significantly- reduce branching delays and cache-miss delayse& compared to previous instruction sets.  = Besides those generalities, Intel is also specifically greedys8 for an IPF version of the GEM Fortran compiler.  Perhaps; some vectorizing functionality?   dunno if that will happeni6 by merging compiler components, or by totally separate
 back ends.  7 Intel was also agreeable to paying the salaries of someo3 GEM compiler folks who would continue to be working 5 primarily on VMS-to-IPF migration support.   The maine< thing Intel got from that is the one time benefit of closure4 of the whole Alpha  replacement deal.  Seems awkward4 for everyone.  Perhaps this part of the deal will be	 adjusted.   8 Intel's current back end is okay for C++ and Fortran but6 isn't presently suited for other commercial languages.2 GEM is great at supporting lots of languages well.6 Perhaps Intel would like to broaden its direct support9 for further languages.   OTOH Intel's eventual mainstream@8 compilers are likely to evolve from Intel's current back. end sources, not from GEM's Bliss-coded stuff.  4 Hewlett Packard has its own optimizing compilers for3 IPF, backed by 10 years of research, which supportsC3 lots of languages well.  But HP doesn't share those  compilers with other vendors.h   ------------------------------  % Date: Mon, 30 Jul 2001 21:28:30 -0500i1 From: "David J. Dachtera" <djesys.nospam@fsi.net>k) Subject: Re: Who does migration from VMS? ' Message-ID: <3B6617CE.D0F4DC7C@fsi.net>b   andrew harrison wrote: > [snip]9 > Why bother trying to move DCl to shell scripts when you?! > can run a DCL emulator on UNIX.p  0 Jay answered that question in his original post:   Jay Braun wrote: > [snip]G > Aren't there firms that perform ports in such a way that the customer @ > doesn't have to keep relying on VMS constructs and proprietary > products for years to come?o  ; Try writing him directly if you need further clarification.    -- n David J. Dachtera  dba DJE Systems9 http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/o   ------------------------------   End of INFO-VAX 2001.421 ************************