1 INFO-VAX	Sat, 01 Sep 2001	Volume 2001 : Issue 485       Contents: Re: A very sad moment.!  Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: Alpha/VMS V Sun/Solaris  Re: Alpha/VMS V Sun/Solaris  Re: Alpha/VMS V Sun/Solaris ' Back with another user account question + Re: Back with another user account question ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update  Re: EV7 will never ship?! Re: FTP problems - please advise! 3 Good news! MicroVAX II - SAVPSL, SAVPC, and SAVISP. 7 Re: Good news! MicroVAX II - SAVPSL, SAVPC, and SAVISP. 7 Re: Good news! MicroVAX II - SAVPSL, SAVPC, and SAVISP. 7 Re: Good news! MicroVAX II - SAVPSL, SAVPC, and SAVISP. 7 Re: Good news! MicroVAX II - SAVPSL, SAVPC, and SAVISP.  Re: I hate Compaq  Re: I hate Compaq  Re: I hate Compaq  Re: I hate Compaq  Re: I hate Compaq  Re: I hate Compaq  Re: I hate Compaq  Re: I hate Compaq  Re: I hate Compaq  In Memoriam...2 Re: Intel announces IA-64 "HyperThreading" in 20022 Re: Intel announces IA-64 "HyperThreading" in 20022 Re: Intel announces IA-64 "HyperThreading" in 20022 Re: Intel announces IA-64 "HyperThreading" in 20022 Re: Intel announces IA-64 "HyperThreading" in 20022 RE: Intel announces IA-64 "HyperThreading" in 20022 Re: Intel announces IA-64 "HyperThreading" in 2002C Re: Intel has released Hyper-threading for it's next gen processors + Re: Is there a why to set verify in sysgen? ! LSE (was: Re: Wailing at Eunuchs)  Re: Mark Twain Promo Re: OPCOM in VMS. I Re: OpenVMS on Fault Tolerant IPF Hardware (was Re: EV7 will never ship?)  some mozilla questions Re: some mozilla questions Re: Some postive points I hope.  Re: Some postive points I hope. * Re: still can't get my UCX licensed???????* Re: still can't get my UCX licensed??????? Re: Sun has a go at Itanium  Re: Sun has a go at Itanium  Re: Tunneling DECnet over IP Re: Tunneling DECnet over IP Re: Tunneling DECnet over IP Re: Tunneling DECnet over IP VMS'er Announces Java Product ! Re: VMS'er Announces Java Product 4 Re: Wailing at Eunuchs (was: Wailing and Moaning...)4 Re: Wailing at Eunuchs (was: Wailing and Moaning...)N Re: What are the exact steps in order to add a user account with VAX-VMS  v6.0' Re: Why continue with OpenVMS / Compaq? 3 Will Mozilla ever run without crashing DECW server? 7 Re: Will Mozilla ever run without crashing DECW server? 7 Re: Will Mozilla ever run without crashing DECW server? 7 Re: Will Mozilla ever run without crashing DECW server? 7 Re: Will Mozilla ever run without crashing DECW server? 7 Re: Will Mozilla ever run without crashing DECW server?   F ----------------------------------------------------------------------  # Date: Sat, 01 Sep 2001 03:25:46 GMT . From: Burnie M <burniem.NOSPAM@ozemail.com.au>  Subject: Re: A very sad moment.!8 Message-ID: <q5l0ptciclh886bi8oj6srllstqph47m0v@4ax.com>   Swing and roundabouts.  @ I am now getting paid comfortably over market (relative to Unix)E because I know VMS but I do wonder when this will become a liability.    Burnie M  ? PS Putting W2K on a new (personal) P3 box this weekend and then : installing my first copy of linix on the old Pentium 200.  It's called survival.     7 On Thu, 30 Aug 2001 09:01:04 -0700 (PDT), Fabio Cardoso ! <fabiopenvms@yahoo.com.br> wrote:    >Andrew  > 6 >I agree with you ! I am an old man with 29 years old 1 >too ! There arent jobs here for OpenvMS SysMans. / >Companies here (HR) dont believe I am alive !  / >They dont want me in positions for Windows NT, 0 >even I worked with it strictly for 3/4 years in >banking0 >automation. When I decided to return to OpenVMS4 >two/three years ago, I didnt know I was entering a " >"black hole"... without escape !  >  >Regards >  >FC  > 0 >--- Andrew Robinson <arobinson@hspg.com> wrote:6 >> I though I would share with you a very sad moment I >> had today with one of >> our suppliers.  >>  4 >> I was discussing a problem of connectivity with a >> WEB Farm's technical bod,7 >> and said that I was using VMS - He immediately asked  >> 'What does that run on,5 >> UNIX or NT?' After explaining that it was actually  >> an operating system used 2 >> on Digital's VAX & Alpha boxes there was a long >> pause then the response6 >> 'Wasn't that something to do with the guy who wrote >> NT ? I can remember1 >> something about that during history lessons at  >> college' 7 >> I had no response to this - I just felt too old, and  >> I'm only 36!  >>  6 >> This email was just a sad moment in my life and was >> not sent to start a. >> bitter and twisted thread on the state of a >> non-mentioned companies7 >> marketing abilities, which I have seen in many other  >> postings. I just 7 >> thought you would like to know that you are now part  >> of the group 'Living  >> History'  >>  
 >> Regards >>   >> Andrew Robinson >  >  >===== >==========================  >Fbio dos Santos Cardoso  >OpenVMS System Manager  >Rio de Janeiro - Brazil >fabiopenvms@yahoo.com.br  >==========================  > 3 >__________________________________________________  >Do You Yahoo!? L >Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger >http://im.yahoo.com   ------------------------------    Date: 31 Aug 2001 14:17:08 -0400) From: tls@panix.com (Thor Lancelot Simon)  Subject: Re: alpha - ia64 + Message-ID: <9mokb4$be9$1@panix1.panix.com>   * In article <3B8F8368.D76A57DF@uk.sun.com>,2 andrew harrison  <andrew.nospam@uk.sun.com> wrote: >aaron spink wrote:  >>  @ >> "andrew harrison" <andrew.nospam@uk.sun.com> wrote in message' >> news:3B8E281F.27767847@uk.sun.com... 8 >> > I always thought that the Alpha was a well designed8 >> > high performance CPU, depending on timing sometimes. >> > the highest performing CPU sometimes not. >> >O >> As a side note, we were a little bored at work on day recently, so one of my O >> co-workers grabbed and munged all the available spec.org data for Spec95 and 
 >> Spec2k. >>  M >> Over the past 7 years, Alpha was in the top spot for SpecIntXXX except for M >> about 6 non contiguous months, for SpecFpXXX the number is pretty much the 2 >> same.  Kind of an interesting graph to look at. >>   > 8 >You have just proved my point. Go back and do the same 6 >analysis but ignore SPECint/SPECfp and concentrate on8 >standard benchmarks that stress the rest of the system,: >OS, Memory, I/O etc and you will find a totally different >story.   G Hey, look, it's everybody's favorite Sun marketing flunkie compulsively  masturbating again!   G How hard can it possibly be for you to understand that you are bringing D your dubious grasp of computer architecture and questionable writingG talents to bear on a _dead architecture_?  There's not really any point  to your slagging them.  I This discussion is about _CPU performance_, and SPEC is a _CPU benchmark_ G (perhaps it would be nice if it were also a memory subsystem benchmark, L but it only sort-of is).  However well the rest of the box someone chose to H put that CPU into could perform at other tasks is completely irrelevant.  E But you knew that.  Or is it just that you were afraid someone would  H mention the stellar CPU performance of the past few Sun offerings again?   --  J Thor Lancelot Simon	                                      tls@rek.tjls.comL     And now he couldn't remember when this passion had flown, leaving him so1   foolish and bewildered and astray: can any man?  						   William Styron    ------------------------------  % Date: Fri, 31 Aug 2001 16:32:04 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>  Subject: Re: alpha - ia64 ( Message-ID: <9mos6m$g5m$1@pyrite.mv.net>  = "andrew harrison" <andrew.nospam@uk.sun.com> wrote in message $ news:3B8F8418.6D00FC76@uk.sun.com... > Bill Todd wrote: > > > > > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message1 > > news:DmfJGVf$FU$u@eisner.encompasserve.org...    ...   E > > > Has anyone else noticed what an Alpha fan Andrew has become now - > > > that Compaq says their future is IA64 ?  > > J > > Yup - glad there's finally a point we can agree on.  Too bad he didn't heedH > > my suggestion back at the beginning of all this that this might be a familyF > > squabble he should stay out of:  I wouldn't object to a lot of his comments2 > > if they weren't so transparently self-serving. > >  > 0 > I did heed your suggestion for a while but the3 > as the level of squatulence from the Compaq choir & > increased I found myself drawn back. > 4 > I think the final straw was Rob Young turning into > an Intel booster.   ? And, unfortunately, that's something I can agree with *you* on.    - bill   > 	 > Regards  > Andrew Harrison  > Enterprise IT Architect    ------------------------------  % Date: Fri, 31 Aug 2001 16:34:34 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>  Subject: Re: alpha - ia64 ( Message-ID: <9mosbb$g5q$1@pyrite.mv.net>  5 "Nic Clews" <sendspamhere@127.0.0.1> wrote in message # news:3B8FA3DB.180E656B@127.0.0.1...  > Bill Todd wrote: > > " > > > Ignore the witless comments. > > I > > Well, when one makes witless assertions, IMO one *should* be prepared  for a - > > certain lack of respect in the responses.  > J > As in "I don't agree with your point of view, so I'll disagree and throw, > in a bit of abuse for good measure". Hmmm.  C No, as in "If you make a bald, unsupported, and highly-questionable 3 assertion, this is the kind of response to expect".    - bill   ------------------------------  % Date: Fri, 31 Aug 2001 15:35:51 -0700 $ From: Alex Johnson <spectre@jhu.edu> Subject: Re: alpha - ia64 ' Message-ID: <3B901147.A3CF806C@jhu.edu>    Sander Vesik wrote:  > 8 > In comp.arch Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:0 > > In article <9mjfg5$o25$1@feed.textport.net>,) > > Greg Lindahl <lindahl@pbm.com> wrote: J > >>>> The EPIC technology used in the IA-64 Itanium's is superior to RISC > >>>> architechure. > >>> L > >>>Ahem. Any chance of the superior technology becoming faster than Sparc,! > >>>the well-known slowest RISC?  > >>J > >>While this looks like a completely pointless thread, it's worth notingJ > >>that on a significant class of applications (floating point), standardF > >>benchmarks show that the IA-64 is significantly faster than Sparc. > >>E > >>If you only care about integer, or big SMP machines, then say so. F > >>"faster" doesn't mean anything if you don't make it more specific. > G > > Strictly, this relates more to the coding style than the arithmetic F > > as such, but predictable (and hence optimisable) coding styles are3 > > associated with floating-point use, as you say.  > F > > The current information about McKinley is interesting, too.  IntelD > > have said that it will appear at 1 GHz and be c. 70% faster thanC > > the Itanic on SpecInt - which will make it comparable to only a  > G > The interesting question is - shall we take it at face value or scale : > down based on past performance vs. claims of perfomance? > C > > 2 GHz Pentium 4 which, by then, should be available in 2.2 GHz. C > > But a factor of 3 more memory bandwidth could mean that it is a G > > factor of 2 faster on SpecFP, which would make it a most impressive 
 > > HPC chip.  > F > > Nobody wants to run GUIs, databases, network management and things$ > > like that on IA-64, do they? :-) > 1 > Can I buy a non-trivially sized IA64 somewhere?   7 Yes, through HP you can purchase a 16 processor rx9610: K http://www.hp.com/products1/servers/rackoptimized/servers/rx9610/index.html - This machine is a rebranded NEC AzusA server.   E It depends on what you consider non-trivial.  I consider 4P and under 5 trivial, so 16P+64GB is non-trivial in my estimation.    Alex --  G My words are my own.  They represent no other; they belong to no other. E Don't read anything into them or you may be required to compensate me % for violation of copyright and/or IP.    ------------------------------  % Date: Fri, 31 Aug 2001 15:39:21 -0700 $ From: Alex Johnson <spectre@jhu.edu> Subject: Re: alpha - ia64 ' Message-ID: <3B901219.194A55FB@jhu.edu>    Yousuf Khan wrote: > N > One will note that when the Hammer line comes out from AMD, it's 64-bit modeI > will default to 64-bit registers for addressing operands, but to 32-bit L > registers for data operands. Just proves that 64-bit is only good (so far)' > for addressing and nothing much more.   G Well, except when you keep your data as 32 bit and your addresses as 64 H bit, then some bad programmer startes manipulating addresses as data andC you end up forced into 32 bit addresses again.  Never trust the end D user.  Make all integers 64 bit by default.  It isn't much slower toH compute 64 bit adds than 32 bit adds and space is not an issue any more.   Alex --  G My words are my own.  They represent no other; they belong to no other. E Don't read anything into them or you may be required to compensate me % for violation of copyright and/or IP.    ------------------------------  % Date: Fri, 31 Aug 2001 19:05:16 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>  Subject: Re: alpha - ia64 ( Message-ID: <9mp55s$nv8$1@pyrite.mv.net>  1 "Alex Johnson" <spectre@jhu.edu> wrote in message ! news:3B901219.194A55FB@jhu.edu...  > Yousuf Khan wrote: > > K > > One will note that when the Hammer line comes out from AMD, it's 64-bit  modeK > > will default to 64-bit registers for addressing operands, but to 32-bit I > > registers for data operands. Just proves that 64-bit is only good (so  far)) > > for addressing and nothing much more.  > I > Well, except when you keep your data as 32 bit and your addresses as 64 J > bit, then some bad programmer startes manipulating addresses as data andE > you end up forced into 32 bit addresses again.  Never trust the end F > user.  Make all integers 64 bit by default.  It isn't much slower toJ > compute 64 bit adds than 32 bit adds and space is not an issue any more.  H How does the hardware default in any way alter the responsibility of theJ programmer to match type sizes appropriately to obtain correct results?  II can see how one might argue that *compiler* I32LP64 implementations might I increase such risk due to programmers who were used to platforms where an J address would fit in an int, but not how the hardware default would (sinceL compilers will just add the appropriate prefix byte when they're told to use long data).    - bill   >  > Alex > --I > My words are my own.  They represent no other; they belong to no other. G > Don't read anything into them or you may be required to compensate me ' > for violation of copyright and/or IP.    ------------------------------  # Date: Sat, 01 Sep 2001 03:53:54 GMT * From: cjt & trefoil <cheljuba@prodigy.net> Subject: Re: alpha - ia64 + Message-ID: <3B905C2F.BBA8CFEC@prodigy.net>    Thor Lancelot Simon wrote: > , > In article <3B8F8368.D76A57DF@uk.sun.com>,4 > andrew harrison  <andrew.nospam@uk.sun.com> wrote: > >aaron spink wrote:  > >>B > >> "andrew harrison" <andrew.nospam@uk.sun.com> wrote in message) > >> news:3B8E281F.27767847@uk.sun.com... : > >> > I always thought that the Alpha was a well designed: > >> > high performance CPU, depending on timing sometimes0 > >> > the highest performing CPU sometimes not. > >> >Q > >> As a side note, we were a little bored at work on day recently, so one of my Q > >> co-workers grabbed and munged all the available spec.org data for Spec95 and  > >> Spec2k. > >>O > >> Over the past 7 years, Alpha was in the top spot for SpecIntXXX except for O > >> about 6 non contiguous months, for SpecFpXXX the number is pretty much the 4 > >> same.  Kind of an interesting graph to look at. > >> > > 9 > >You have just proved my point. Go back and do the same 8 > >analysis but ignore SPECint/SPECfp and concentrate on: > >standard benchmarks that stress the rest of the system,< > >OS, Memory, I/O etc and you will find a totally different	 > >story.  > I > Hey, look, it's everybody's favorite Sun marketing flunkie compulsively  > masturbating again!  > I > How hard can it possibly be for you to understand that you are bringing F > your dubious grasp of computer architecture and questionable writingI > talents to bear on a _dead architecture_?  There's not really any pointh > to your slagging them. > K > This discussion is about _CPU performance_, and SPEC is a _CPU benchmark_hI > (perhaps it would be nice if it were also a memory subsystem benchmark,lM > but it only sort-of is).  However well the rest of the box someone chose to J > put that CPU into could perform at other tasks is completely irrelevant. > F > But you knew that.  Or is it just that you were afraid someone wouldJ > mention the stellar CPU performance of the past few Sun offerings again? >  > --P > Thor Lancelot Simon                                           tls@rek.tjls.comN >     And now he couldn't remember when this passion had flown, leaving him so3 >   foolish and bewildered and astray: can any man?-C >                                                    William StyronV  D At that point the cross-post to comp.os.vms becomes off-topic, IMHO.  G If you're only interested in pure chip performance, I would argue that CE it's pretty close to being off topic to the other groups to which it   was posted as well.    ------------------------------  % Date: Fri, 31 Aug 2001 14:12:47 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>e$ Subject: Re: Alpha/VMS V Sun/Solaris( Message-ID: <9mok1k$9j0$1@pyrite.mv.net>  : "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message- news:2QLYc8USpxe7@eisner.encompasserve.org...e. > In article <9mnfhu$ck4$1@rdel.co.uk>, "Gary"* <gary.mcdonald@uk.thalesgroup.com> writes: > > Hi,e > >dE > > Does anyone have any performance information on this subject withe
 respect to+ > > web server loading and hardware spec's?  > >a' > > All assistance greatly appreciated.p >M > Well if _that's_ the case... >aI > I understand that the OSU web server is the most performant one on VMS.t >sE > Some years ago a prominent Macintosh web server developer had heavyeE > criticism for something called WebSpec or SpecWeb because it merelycC > opened connections and did not use them, an unrealistic scenario.u  L The description of the current version of SpecWeb indicates that this is notL the case.  I didn't see any obvious VMS entries in a quick scan of results -J but they did suggest that the choice of web-server software might be a lot; more important for performance than the hardware or the OS..   - bill   ------------------------------  % Date: Sat, 01 Sep 2001 06:56:55 +0930e/ From: Mark Daniel <mark.daniel@wasd.vsm.com.au>l$ Subject: Re: Alpha/VMS V Sun/Solaris/ Message-ID: <3B90011F.2395D7B5@wasd.vsm.com.au>D   Larry Kilgallen wrote:  
 8< snip 8<I > I understand that the OSU web server is the most performant one on VMS.D   Can't resist ...  6   http://wasd.vsm.com.au/ht_root/doc/htd/htd_1800.html  
 8< snip 8< --  # Non sinere illegitamus carborundum.-   ------------------------------    Date: 31 Aug 2001 17:21:54 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)n$ Subject: Re: Alpha/VMS V Sun/Solaris3 Message-ID: <ks0Ur6M5BxSQ@eisner.encompasserve.org>c  a In article <3B90011F.2395D7B5@wasd.vsm.com.au>, Mark Daniel <mark.daniel@wasd.vsm.com.au> writes:v > Larry Kilgallen wrote: >  > 8< snip 8<J >> I understand that the OSU web server is the most performant one on VMS. >  > Can't resist ... > 8 >   http://wasd.vsm.com.au/ht_root/doc/htd/htd_1800.html  = Thanks for that clarification (showing WASD faster than OSU).n   ------------------------------  % Date: Fri, 31 Aug 2001 20:05:45 +0100c, From: "Mat Riain" <matei@no.spam.eircom.net>0 Subject: Back with another user account question0 Message-ID: <BrRj7.6082$s5.69023@news.indigo.ie>   Hello again,  L Thanks to all that gave me some tips on creating and modifying users.  I wasG able to go back and change some of the variables on the user that I hadeG created, but...  whenever I tried to log on with said user account, thes9 system would log me off immediately w/o an error message.r  D Is there a log where I could check for error messages or see what is happening?  Any ideas?   Cheers,r   Mato   ------------------------------  # Date: Fri, 31 Aug 2001 20:23:55 GMTu2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)4 Subject: Re: Back with another user account question3 Message-ID: <vnSj7.1075$bB1.46190@news.cpqcorp.net>U  _ In article <BrRj7.6082$s5.69023@news.indigo.ie>, "Mat Riain" <matei@no.spam.eircom.net> writes:A  M :Thanks to all that gave me some tips on creating and modifying users.  I waseH :able to go back and change some of the variables on the user that I hadH :created, but...  whenever I tried to log on with said user account, the: :system would log me off immediately w/o an error message.  -   How far into the LOGIN process do you get? d  F   What is the source for the attempted log in?  Via a direct terminal C   connection, via SET HOST, via the system console, DECwindows, or s   otherwise?  C   Unless you have been messing with it, the quotas on the new usersaB   should be at least those of the SYSTEM username.  Please post an
   example.  F   Please confirm that the target LOGIN device and LOGIN directory are 2   available, and are not protected against access.  C   Please check for the logical names SYLOGIN and LOGIN, and confirm=B   that (if the logical names are defined) that the files are valid'   and are not protected against access.m     Specific commands include:     SHOW LOGICAL     DIRECTORY/SECURITY  C   Information on failed logins is included in the accounting file.  @   SET DEFAULT to SYS$MANAGER:, and use the ACCOUNTING command to!   examine the accounting records.n  E   When posting, please remember to include specific details, such as <F   the OpenVMS version and platform, and (in this particular case) the C   UAF entry, a copy of exactly what you saw, etc.  (You'll notice I8D   have already asked for most of this information above. :-)  If youD   are not sure what information is required when you ask a question D   -- and everybody eventually has to learn about this -- please see /   the introductory sections of the OpenVMS FAQ.n      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: Fri, 31 Aug 2001 14:59:18 -0400 ; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>d2 Subject: Re: Conference: CETS-2001 Detailed Update$ Message-ID: <3b8fded4$1@news.si.com>  K >Really - do you know of many IT teams (defining teams as the team familiareA >with the same set of business rules) deploying high availability * >applications on both OpenVMS and Windows?  J Uh, we do.  True, our high availability apps are ones used internally, butH that doesn't make us any less dependent on them.  The Windows ones don't6 match the same "high availability" definition, though. --A Brian Tillman                   Internet: tillman_brian at si.comeA Smiths Aerospace                          tillman at swdev.si.como= 3290 Patterson Ave. SE, MS      Addresses modified to prevent < Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  % Date: Fri, 31 Aug 2001 15:06:06 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>n2 Subject: Re: Conference: CETS-2001 Detailed Update( Message-ID: <9mon5i$c6u$1@pyrite.mv.net>  ? "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messagee6 news:AFPj7.1585$%e5.4250482@typhoon.ne.mediaone.net... > K > "Jan Vorbrueggen" <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote  inL > message news:y4g0a8mkko.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de..., > > "Jeff Killeen" <Jeff@IDM-IO.com> writes: > >aI > > > You have repeatedly claimed Compaq "lied".  At the time that lettero was L > > > posted it was truthful.  Jesse retired from Compaq in October 2000 and > BillK > > > retired in January 2001.  Neither party was involved in the decision.n Ie > seeoE > > > nothing in this that proves Compaq engaged in telling customerst
 > informationI > > > it knew to be false. >eF > Yep. The usual USENET Horseshit. But what elsw would you expect from
 > here????  L I guess we know what to expect from you by now:  as usual, invective withoutD any attempt to address the content of the post you're responding to.   - bill   ------------------------------  % Date: Fri, 31 Aug 2001 15:04:53 -0400f' From: "Bill Todd" <billtodd@foo.mv.com>a2 Subject: Re: Conference: CETS-2001 Detailed Update( Message-ID: <9mon36$bup$1@pyrite.mv.net>  ? "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messagef6 news:nLPj7.1587$%e5.4252766@typhoon.ne.mediaone.net...J > Ahgaoin. the usual Usenet Horseshit. Wan t the facts, buy my newsletter. Or& > continue to suck up this codswallop!  I Since your newsletter has become an arm of Compaq's PR effort, why shouldu anyone spend money on it?e   - bill   ------------------------------  % Date: Fri, 31 Aug 2001 16:23:58 -0400i' From: "Bill Todd" <billtodd@foo.mv.com>02 Subject: Re: Conference: CETS-2001 Detailed Update( Message-ID: <9mornh$fit$1@pyrite.mv.net>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messagee2 news:anLj7.1361$cJ1.247928@typhoon1.gnilink.net... >s1 > "- bill" <billtodd@foo.mv.com> wrote in messagei9 > news:841e9c22.0108301720.52039f3b@posting.google.com...d@ > > To refresh your memory:  Compaq broke the written, explicit,J > > unequivocal commitments to Alpha's future expressed in the 'commitmentD > > to Alpha' letter from Jesse Lipcon and Bill Heil that was postedC > > prominently on Compaq's Web site until well after the June 25thaJ > > announcement.  In case you never saw that letter during the 2 years orF > > so it was there, you can find a copy that I posted to comp.arch onI > > August 19th under the "I hate Compaq" thread (a thread not started byoI > > me, by the way), since some people there seemed to be unfamiliar withiI > > the letter and it had finally disappeared from the Web site.  SimilarrI > > commitments were made to many individual customers as well, of courseCG > > - right up to June 25th (see an August 27th post from Alan Greig inoH > > the same thread for just one example among many).  Compaq broke them5 > > all without any hint of apology, let alone shame.n >c, > You have repeatedly claimed Compaq "lied".  A I'm beginning to think that you have severe reading-comprehension"L difficulties.  The paragraph above has nothing directly to do with lies:  itK explicitly addresses the 'broken commitments' portion of what you asked forpI details about (though, as Jan pointed out in his response, the letter waslJ used, right up to June 25th, to *support* subsequent lies told by Compaq).   ...n  I > The fact is was posted after June 25th does not mean someone knew the 27 yearH > old letter was there and intentionally left it posted.  Who knows if IG > search Compaq's web site I might find an old page talking about theiro > commitment to the PDP-11.t  F Again, see Jan's response:  not only was Compaq well aware that it wasF there, but it consistently used it to bolster subsequent statements of commitment.o   >eK > You set the standard that Compaq "lied" (known falsehoods) and you failedt to" > meet the standard with this one.  ? No, you just failed to meet minimal standards of comprehension.    >eF > > Compaq attempted to justify the decision by asserting that Alpha'sJ > > engineers had told it that Alpha would have difficulty keeping up withJ > > IA64's performance.  One Alpha architect has stated publicly that thisG > > was an outright double-lie (i.e., no such statement was made by thecD > > Alpha engineers, nor do they concur with its content:  Alpha wasD > > chugging right along the path laid out for it years ago, with noG > > unexpected recent hiccups - until Compaq pulled out the rug on Junen@ > > 25th), and other Alpha architects (plus one high-level AlphaJ > > development manager) have privately agreed with him.  Not one has come( > > forward to support Compaq's version. >pF > You will have to point me to where one of these Alpha architect said this -9 > forgive if I don't have blind faith in your statements.h  J What I don't forgive you for is your failure to make even minimal attemptsJ to become familiar with the material under discussion before wading in andJ suggesting that people who *have* made that effort don't know what they're talking about.  L If you didn't see them at the time, you can search comp.arch and comp.os.vmsG for posts from Brannon Batson as easily as I can:  I suggest you do so.o     Also I need yourK > reference to where Compaq said it would have trouble "keeping up" because F > from day one I heard it as Compaq would have trouble maintaining itsK > performance edge over IPF three generations out.  What I was told is veryhF > different than what you claim Compaq said - there is a major betweenD > "keeping up" and "maintaining its performance edge".  It was never	 expressedo@ > to me as Alpha falling behind but instead IPF closing the gap.  J The latter is as much a lie as the former, according to private statementsL made by the Alpha engineers in question to multiple people (at least to PaulJ DeMone and myself, plus I think to Bob Kaplow).  And you may find explicitL public statements by Brannon to that effect, though I'm not sure now whether they were public or private.  B There was also a private, internal statement by a high-level AlphaJ development manager that the decision to drop Alpha was made for business, not technical, reasons.a  L While the suggestion that Alpha would have difficulty keeping up was made atK some point, I don't have the patience to wade through Google trying to findaJ it.  So let's just call the contention that Alpha couldn't have retained a8 significant performance lead a lie and leave it at that.   > L > My understanding of what drove the decision was more than pure chip speed.L > I was told upfront that it was at the system performance level that became > the issue.  H All the more reason for Compaq to retain the advantages Alpha gave it inK that area - e.g., EV7's on-chip glue, which would have given EV8 continuingiK *system* advantages over the competition in addition to EV8's new features.a  I Alpha's advantages weren't only in on-chip speed, but in integration thateG enhanced overall system speed.  Now they're stalled as of EV7, and willo, appear in IA64 (if at all) years after that.  @   Remember Alpha's performance advantage was both its chip speedJ > and the fact that it was 64 bit.  What the team saw who was building theI > follow-on to the Wildfire was the IPF systems would close in on Alpha's- > systems in the future   A Bullshit.  The Wildfire follow-on is Marvel, which will enjoy theuK performance advantages of EV7's on-chip glue and thus draw farther ahead ofrK IPF in real-world use rather than lose ground.  EV8 showed every promise ofnJ even greater performance differentiation in server applications due to SMTJ (with no loss of ground even in single-threaded use, due to its ability to use 8-wide issue there).  5  - it was never ever expressed to me as Alpha systemsa" > would have trouble "keeping up". > L > I seriously disagree with your statement as to what Compaq claimed - I see/ > no lie here. Plus the article you quote belowtG > (http://www.eetimes.com/story/OEG20010625S0105 ) backs up what I said 
 > above... >t< >     "This is a very bold move for us," said Rich Marcello,5 >     vice president and general manager for Compaq's 2 >     performance systems group. He noted that the5 >     Alpha road map extended for several more years, 8 >     but that starting around 2004, when the chip would9 >     have competed head-to-head against Intel's Itanium,tC >     its performance advantage would begin to erode significantly. : >     "When we looked at our road map and overlaid it with9 >     Intel's road map, we found there was no substantial > >     performance benefit," he said. "Basically, we are sayingA >     that we couldn't differentiate ourselves at the CPU level."c >iG > ... he did not say that there was a problem with "keeping up" he saids thereo1 > was a problem with maintaining the "advantage".   L The phrase 'no substantial performance benefit' is quite a bit stronger thanC the allegation that the advantage might erode somewhat - but to all  appearances both are false.h  E The advantages (on-chip glue for RAMBUS and SMP) that EV7 enjoys overkC McKinley, and those that EV8 would have added (SMT plus wider-issueoH single-thread performance were biggies, but there may have been others),G plus the absence of any new indication of post-McKinley enhancements toaL IA64, plus the arguments advanced in Compaq's own alpha-vs.-IA64 white paperL (alpha_ia64.pdf), make it reasonable to call Rich's statements lies:  he wasI certainly well aware of all these factors (having been using them to sellp7 Alphas for years), and made no attempt to address them.r   >dG > > Inconsistently, Compaq also, via employee newsgroup posts and via a E > > discussion Mark Gorham and VMS engineers had with 'Alphaman' (seeeA > > c.o.v. posts the week of the announcement), stated that AlphamG > > technology would be used to 'rescue' the failing IA64 architecture,tI > > resulting in technology equivalent to what Alpha otherwise would have-J > > been - and in a time-frame that would benefit the VMS port by the timeA > > it was completed.  This lie was so incompetent (and likely sooH > > unwelcome when Intel heard about it) that it died out very quickly -B > > but it nonetheless happened, and Compaq is accountable for it. >cL > Internal newsgroup postings - give me a break.  Compaq (not individuals inI > newsgroups) has never publically said, that I have seen, that the Alphas team > would "rescue" IPF.   L You're free to call Alphaman a liar, but I'd suggest that having Mark GorhamB do so would be more appropriate, since to all appearances you know' absolutely nothing about the situation.m  L And as for newsgroup postings, you have Compaq to thank for not having other9 more formal discussion forums to depend upon for answers.p   ...e  6 > I would want to see the exact Mark Gorham statement.  J As I suspect would a lot of people, including me.  Why not ask him to take, the initiative in breaking Compaq's silence?     As far as what most K > employees (not Compaq but employees) said the week of the announcement it  > should be ignored.  C Funny - at least one of them went so far as to say that he had beenS authorized to speak.   ...-  G > > And Compaq presented Alpha development costs as being unsupportableeI > > (see a June 27th eWeek interview with Winkler, plus additional drivelsA > > from Terry and others - including you).  I responded to thesetJ > > assertions in a July 19th posting in the c.o.v. "Alpha:  an invitationE > > to communicate" thread, plus other smaller supporting posts sincetC > > then, and, again, no one has stepped forward with contradictoryrH > > evidence to suggest that this was not yet another Compaq lie (thoughF > > an EETimes story - http://www.eetimes.com/story/OEG20010625S0105 -E > > suggests that Winkler's statement that Alpha's annual developmentgE > > costs were $300 million was yet another lie, and the R&D spending.C > > projections in Compaq's own annual reports tend to support thats > > suspicion).r >nL > My understanding is the costs came from all of Alpha _systems_ developmentH > and NOT just the cost of pure chip development.  For example each timeC > Compaq needed to burn a new set of ASIC's for the Wildfire during-K > development the cost was about one million dollars per batch - those costtJ > start to add up very quickly.  It is not just the chip - it is the totalD > cost of maintaining the server development effort unique to Alpha. >,K > Did Winkler say "Alpha's annual development costs" or did he say "Alpha'swE > annual _chip_ development costs".  There is a big difference there.  Please. > point me to the source of the Winkler quote.  I I did:  the June 27th eWeek article I mentioned above.  Here's the quote:a  L 'According to Winkler, just to design and develop future generation of AlphaJ was costing Compaq $300 million a year, he said. "That's no small change,"	 he said.',   and the URL:B http://www.zdnet.com/eweek/stories/general/0,11011,2780645,00.html  J However, since Compaq's server-development expenses are at least currentlyG slated to continue (e.g., its 'commitment' to develop Marvel-style IA64eK servers, though exactly what that means is not clear, given that so much ofeG Marvel's attraction derives from EV7's on-chip glue features which seemaF impossible to add to IA64 before 2005 at the earliest), including suchG expenses in the figure above would seem disingenuous at best, but couldoJ explain the factor-of-2 discrepancy between the EETimes cost estimate (and* the Compaq annual reports') and Winkler's.   >a > > Clear enough for you now?t >iI > All that is clear Bill is that your conclusions are based upon the spin  youeI > have attached to Compaq's actions and not what Compaq has actually beenr	 > saying.d  I Why *anyone* would treat what Compaq says at this point as significant islF not at all obvious.  But its statements in the Heil/Lipcon letter wereJ entirely unambiguous, so at least in that case my conclusions are based on *exactly* what Compaq said.   =   You haven't backup up your case that Compaq "lied" (willfulfJ > misrepresentation) and several statements you made above are contrary to > what I heard from Compaq.L  H So?  Why do you believe Compaq rather than, say, the Alpha engineers whoH vigorously and without a single dissenting voice deny what Compaq claims" they told it?  Please be specific.  1   They only claim above you have that holds waterc1 > is that Compaq's commitment to Alpha changed...s  F There's a not-very-subtle difference between one's internal feeling ofD 'commitment' to a platform and one's external, explict, written, and" repeated commitments to customers.   - bill   ------------------------------  # Date: Sat, 01 Sep 2001 05:06:55 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update7 Message-ID: <P1_j7.642$mC2.329935@typhoon2.gnilink.net>-  L "Jan Vorbrueggen" <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote inJ message news:y4k7zkz0n1.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de...* > "Jeff Killeen" <Jeff@IDM-IO.com> writes:G > > This is very indicative of the pure speculation is going on here...# >lK > Blech. Do you think an iteration of an ASIC 2-4 years back in the US cost: ten K > times more than a turn of a state-of-the-art custom design in Germany two:
 > years back?:  J No - but I do think the project leader for Wildfire is a far more reliableH cost of  Wildfire ASIC's costs than the cowboys with a keyboard in these newsgroups.o  L The information was provided at a Encompass User Group meeting last fall andE there was no reason for him to be placing any spin on it - however bydH reputation I seriously doubt he would put spin on anything at anytime...   ------------------------------  % Date: Fri, 31 Aug 2001 21:04:18 -0500-1 From: "David J. Dachtera" <djesys.nospam@fsi.net>_! Subject: Re: EV7 will never ship? ' Message-ID: <3B904222.C49B1E3F@fsi.net>s   "Terry C. Shannon" wrote:E > B > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message/ > news:Scuj7.1003$bB1.45307@news.cpqcorp.net...oA > > JF Mezei wrote in message <3B8D263B.CEA96993@videotron.ca>...- > > >Alan Greig wrote:A > > >> have Galaxy support features according to current customeru > presentations. > > The slidesA > > >> show one system running Windows-64, VMS, Linux, and Tru64.C > > >oF > > >I was under the impression that currently, Galaxy only *supports*
 > multiple > > >instances of VMS. > H > What folks fail to understand is that comp.os.vms is a Romper Room for
 > whiners!  H When my wife makes comments like that, we both know it's time for her to take her water pill...   -- > David J. Dachtera  dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/r   ------------------------------  % Date: Fri, 31 Aug 2001 20:15:02 +0100 , From: "Mat Riain" <matei@no.spam.eircom.net>* Subject: Re: FTP problems - please advise!0 Message-ID: <t5Uj7.6137$s5.69616@news.indigo.ie>  - "John Santos" <JOHN@egh.com> wrote in messageu) news:1010829223539.26010B@Ives.egh.com...y) > > $ set term/dev=vt100/line/insert/edito > >t. > > %SET-W-NOTSET, error modifying ALPHA$DKA0: > >o< > > -SET-E-INVDEV, device is invalid for requested operation >i	 > Hi, Mat  >l7 > You are trying to set the terminal characteristics on08 > something that isn't a terminal.  To prevent this, you7 > need to surround the "$ set term" command with a teste* > on whether it is an interactive process.  K I wasn't sure how to do the above, so I commented it out (with "!" - I hope$L that this is correct) butI was still unable to connect.  Oddly enough, I can do so from another VMS box...t   Matr   ------------------------------  % Date: Fri, 31 Aug 2001 19:34:28 -0000e From: sword7@speakeasy.org< Subject: Good news! MicroVAX II - SAVPSL, SAVPC, and SAVISP./ Message-ID: <tovpm4n0b9lke0@corp.supernews.com>1   Hello folks:  J Well, I finally discovered that I had not loaded 0x300 into SAVPSL before G I execute the console program (20040000) after I endlessly debugged my eI emulator due to lack of KA630 manuals for three days.  When it was done, .I all boot problems instantly disappeared!!  Booting finally returned back eD to normal.  That's why SAVPSL must have 0x300 or boot will not work.  B Does anyone have information about three processor registers aboutA SAVPSL, SAVPC, and SAVISP?  How about Q-bus specs for MicroVAX IIp series?r  
 Thank you!   -- Tim Stark   --  , Timothy Stark	<><	Inet: sword7@speakeasy.orgJ --------------------------------------------------------------------------F "For God so loved the world, that he gave his only begotten Son, that H whosoever believeth in him should not perish, but have everlasting life.. Amen." -- John 3:16 (King James Version Bible)   ------------------------------  % Date: Fri, 31 Aug 2001 21:59:15 +0100e+ From: "antonio.carlini" <arcarlini@iee.org>W@ Subject: Re: Good news! MicroVAX II - SAVPSL, SAVPC, and SAVISP.' Message-ID: <3B8FFAA3.C68B72F5@iee.org>    sword7@speakeasy.org wrote:2 > D > Does anyone have information about three processor registers aboutC > SAVPSL, SAVPC, and SAVISP?  How about Q-bus specs for MicroVAX IIt	 > series?e  " I have an old and battered copy of the 78032 user's guide (this iso! for the chip itself ... I'm still-# looking for the KA630 user guide!).r    SAVISP saves the ISP at the time a chip restart occurs.   SAVPC saves the PC.r   SAVPSL saves the following:a 	<07:00> - PSW 	<14:08> - restart codea 	<15:15> - MAPEN bit 	<31:16> - PSL<31:16>   5 These get filled in when any of the following happen:t 	- RESET is asserted. 	- HALT is asserted (i.e. halt button pressed)8 	- HALT instruction is executed with chip in kernel mode7 	- severe hardware or kernel software corruption occursf  + The manual states that these registers musto+ be saved before reenbaling the MMU or using  any emulated instructions.  ) The rest of the system state at this timee is:     SP     = SP at time of restartu  PSL    = 0x041F0000  PC     = 0x20040000  MAPEN  = 0   ICCS   = 0e  SISR   = 0d  ASTLVL = 4"  everything else is undefinedu   Antonioo   -- t   ---------------t- Antonio Carlini             arcarlini@iee.org    ------------------------------  # Date: Fri, 31 Aug 2001 21:50:15 GMTe+ From: Jeff Campbell <jcampbell@ins-msi.com>r@ Subject: Re: Good news! MicroVAX II - SAVPSL, SAVPC, and SAVISP.+ Message-ID: <3B8FFF29.7A050DF5@ins-msi.com>s   sword7@speakeasy.org wrote:  >  > Hello folks: > K > Well, I finally discovered that I had not loaded 0x300 into SAVPSL beforeyH > I execute the console program (20040000) after I endlessly debugged myJ > emulator due to lack of KA630 manuals for three days.  When it was done,J > all boot problems instantly disappeared!!  Booting finally returned backF > to normal.  That's why SAVPSL must have 0x300 or boot will not work.  H I would expect without *knowing* what the ROM code does that the initialH value for SAVPSL would be 0x1f0000. 0x300 is an illegal PSL value as theC 'one' bits will be in a MBZ field if copied to the PSL. 0x1f0000 isIA IPL 31, which will lock out all interrupts, including power fail.s   > D > Does anyone have information about three processor registers aboutC > SAVPSL, SAVPC, and SAVISP?  How about Q-bus specs for MicroVAX IIt  B These three registers are unique to the MicroVAX II chip. They are/ processor internal registers with addresses of:B  1    41   Console Saved ISP            SAVISP   R/Wo1    42   Console Saved PC             SAVPC    R/Wa1    43   Console Saved PSL            SAVPSL   R/W   D The register numbers are decimal. The M[TF}PR instruction is used to access these registers.P  @ The Q22-Bus memory space is addressed through physical addresses@ 0x30000000 to 0x303fffff. Note that the Q22-Bus does not have to> have any physical memory installed to function. But if Q22-BusA physical memory is available it is addressed via these addresses.   ? The Q22-Bus IO mapping register array is located at 0x2008xxxx.v9 Each register maps a 512 byte page of Q22-Bus memory intom; a selected page of local memory. The map register contains:h  @   <31:31>  V        Valid bit. Indicates <14:00> value is valid.;   <30:15>           unused. These bits always read as zero.yD   <14:00>  A23-A09  Address bits. These are the high 15 bits of a 248                     bit local (physical) memory address.  C The Q22-Bus IOPAGE addresses are directly addressed in the physical + address scheme at 0x20000000 to 0x20001fff.f  ? The console ROM code must map enough local memory space to bootcC the system. The Q22-Bus devices will be doing DMA into the physical > Q22-Bus address space. The mapping array will cause the DMA to- be to physical MicroVAX memory, page by page.   	 > series?n >  > Thank you! >  > -- Tim Stark >  > --4 > Timothy Stark   <><     Inet: sword7@speakeasy.orgL > --------------------------------------------------------------------------G > "For God so loved the world, that he gave his only begotten Son, that'J > whosoever believeth in him should not perish, but have everlasting life.0 > Amen." -- John 3:16 (King James Version Bible)   Regards,  
 Jeff Campbellw n8wxs@arrl.net   ------------------------------  % Date: Fri, 31 Aug 2001 23:00:38 -0000  From: sword7@speakeasy.org@ Subject: Re: Good news! MicroVAX II - SAVPSL, SAVPC, and SAVISP./ Message-ID: <tp05ommg8m0bf5@corp.supernews.com>p  ; In comp.os.vms Jeff Campbell <jcampbell@ins-msi.com> wrote:hE > The Q22-Bus IOPAGE addresses are directly addressed in the physicall- > address scheme at 0x20000000 to 0x20001fff.   A > The console ROM code must map enough local memory space to bootuE > the system. The Q22-Bus devices will be doing DMA into the physicale@ > Q22-Bus address space. The mapping array will cause the DMA to/ > be to physical MicroVAX memory, page by page.e   Jeff:n  J Thank you for information about Q-bus specs.  However, I have one questionF for you about IOPAGE (20000000 to 20001FFF).  I noticed that in tracedE execution log file and it tried to access 20001F40, etc.  Does anyonepF have information about IOPAGE area?  I assume that IOPAGE registers isJ for Q-bus registers.  Q-bus memory space is for drive registers, ethernet  registers, etc.../  
 Thank you!   -- Tim Stark   -- t, Timothy Stark	<><	Inet: sword7@speakeasy.orgJ --------------------------------------------------------------------------F "For God so loved the world, that he gave his only begotten Son, that H whosoever believeth in him should not perish, but have everlasting life.. Amen." -- John 3:16 (King James Version Bible)   ------------------------------  % Date: Fri, 31 Aug 2001 23:06:47 -0000  From: sword7@speakeasy.org@ Subject: Re: Good news! MicroVAX II - SAVPSL, SAVPC, and SAVISP./ Message-ID: <tp0647fdcdvoce@corp.supernews.com>e  9 In comp.os.vms antonio.carlini <arcarlini@iee.org> wrote:"$ > I have an old and battered copy of! > the 78032 user's guide (this isa# > for the chip itself ... I'm stilln% > looking for the KA630 user guide!).e  E What is 78032 chip for?  Of course, I might be interested in a copy..g5 Yes, I am still looking for the KA630 user guide too.    > SAVPSL saves the following:  > 	<07:00> - PSW > 	<14:08> - restart codee > 	<15:15> - MAPEN bit > 	<31:16> - PSL<31:16>   7 > These get filled in when any of the following happen:  > 	- RESET is asserted0 > 	- HALT is asserted (i.e. halt button pressed): > 	- HALT instruction is executed with chip in kernel mode9 > 	- severe hardware or kernel software corruption occursi  F Does anyone have information about restart code?  Only I know that 0x3E is power-up state or so.  I had seen 0x5, 0x3, and 0x2 in diassembleds	 VMB code.a  - > The manual states that these registers mustl- > be saved before reenbaling the MMU or usingt > any emulated instructions.  > Ok, thank you for information, I will put them in my emulator.  
 Thank you!   -- Tim Stark   --  , Timothy Stark	<><	Inet: sword7@speakeasy.orgJ --------------------------------------------------------------------------F "For God so loved the world, that he gave his only begotten Son, that H whosoever believeth in him should not perish, but have everlasting life.. Amen." -- John 3:16 (King James Version Bible)   ------------------------------    Date: 31 Aug 2001 13:10:59 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)t Subject: Re: I hate Compaq3 Message-ID: <kThTdZOpCem9@eisner.encompasserve.org>q  k In article <TXLj7.1042$bB1.45773@news.cpqcorp.net>, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes: H > Nick Maclaren wrote in message <9mnv56$8lv$1@pegasus.csx.cam.ac.uk>... >> > A >>It isn't just Compaq's record, but that of every single companyFB >>that has ever got into serious levels of SMP and non-predictable@ >>instruction execution - getting the interrupt handling, memory@ >>management and related areas to work correctly and efficiently> >>is FAR harder than even the most realistic manager will have> >>scheduled for.  And what is apparently a simple or unrelated9 >>change may have immense and unpredictable consequences.  >> >  > K > The good news is that IMHO the 3 best people in the world at what they do F > are in charge of the EV7, the system platform, and the IO subsystem.  1 Arnold Palmer, Jack Nicklaus, and Tiger Woods ???o   ------------------------------  % Date: Fri, 31 Aug 2001 14:25:20 -0400m' From: "Bill Todd" <billtodd@foo.mv.com>  Subject: Re: I hate Compaq( Message-ID: <9mokp1$a4j$1@pyrite.mv.net>  D "Michael Woodacre" <woodacre@scala.reading.sgi.com> wrote in message( news:9mnp7a$fk38f$1@fido.engr.sgi.com...J > In article <y4k7zkd75k.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>,I Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:m/ > |> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:o > |>D > |> > But I agree that it is a less likely scenario than a completeG > |> > meltdown of the Alpha line (i.e. an inability to get the EV7 outh> > |> > and working in a realistic timescale, with no fallback) > |>K > |> I've heard from multiple sources that there are working EV7 processorsg thatK > |> have booted all of Compaq's OSes some time ago, so the above inabilityc wouldnB > |> have to apply to systems, not the processor. Of course, given
 WIldfire's, > |> history, that isn't totally impossible. > |> >m  > Booting an OS != stable system  L The phrase I've heard, from multiple sources, is that the OSs were *running*H in a *Marvel* (and/or MP) configuration.  If that's true, it's decidedlyK more than just booting on first silicon, though it may well not yet qualifyk as a 'stable system' either.   - bill   >lJ > It's obviously a big achievement to boot an OS on a processor but anyoneK > who has been through processor and system bringup knows it takes a lot of  work/ > to get a system/processor combination stable.f   ------------------------------  % Date: Fri, 31 Aug 2001 14:43:52 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>b Subject: Re: I hate Compaq, Message-ID: <3B8FDAE5.99BB8D7F@videotron.ca>   Nick Maclaren wrote:= > I hope that Compaq DOES pull off the EV7, as even temporarys@ > competition is always good, and think that it is probably more@ > likely than not.  But it is by no means a foregone conclusion.  J Perhaps the real goal of the EV7 folks is to give them a sand box in whichL they can play in (Alpha) and test some stuff and once they are done with it,5 they can then transfer it "debugged/tested" to Intel.e  K Are there any technologies in EV7 that Intel would like to implement in itsoM own chips eventually ? From what I understand, EV8 was still mostly on paper, D whereas EV7 is closer to being a real thing, and this means that theG technologies in EV7 would also be more developped/debugged than the EV8o4 concepts that are not yet implemented anywhere else.   ------------------------------   Date: 31 Aug 2001 20:54:19 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: I hate Compaq0 Message-ID: <9mothr$33i$1@pegasus.csx.cam.ac.uk>  O In article <9mokp1$a4j$1@pyrite.mv.net>, Bill Todd <billtodd@foo.mv.com> wrote:lE >"Michael Woodacre" <woodacre@scala.reading.sgi.com> wrote in messagee) >news:9mnp7a$fk38f$1@fido.engr.sgi.com...  >>! >> Booting an OS != stable systemt > M >The phrase I've heard, from multiple sources, is that the OSs were *running*lI >in a *Marvel* (and/or MP) configuration.  If that's true, it's decidedlyrL >more than just booting on first silicon, though it may well not yet qualify >as a 'stable system' either.o  > And what I have heard, from multiple sources, is that the EV68= Wildfires are not yet running reliably under a realistic loadi= in a SMP configuration.  Since we can assume (on the basis ofn> much experience) that most of the problems will be in the very< area where the EV7 differs from the EV68, we can expect that the road ahead is rough.  < But, as my sources are very indirect, I cannot tell you WHY.> And this considerably affects estimates of whether the move to8 the EV7 will help or hinder progress to a stable system.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679l   ------------------------------  % Date: Fri, 31 Aug 2001 17:12:06 -0400o' From: "Bill Todd" <billtodd@foo.mv.com>f Subject: Re: I hate Compaq( Message-ID: <9mouho$hpq$1@pyrite.mv.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B8FDAE5.99BB8D7F@videotron.ca...   ...c  I > Are there any technologies in EV7 that Intel would like to implement inc itsdH > own chips eventually ? From what I understand, EV8 was still mostly on paper,. > whereas EV7 is closer to being a real thing,  L Reportedly EV7 *is* a real thing, at least to the point that it's running MP systems.    and this means that theI > technologies in EV7 would also be more developped/debugged than the EV8p6 > concepts that are not yet implemented anywhere else.  H My impression is that the most significant EV7 strengths (aside from theI 0.18 micron process-shrink of the mostly-EV6 core) are its on-chip RAMBUS3@ support (eliminating an external RAMBUS controller chip and thusL significantly reducing memory-access latency, not to mention reducing systemE cost and complexity) and its on-chip SMP glue (which also should have2H significant advantages in both performance and cost).  There's no publicL indication that Intel has any similar IA64 features already in progress, andK the *earliest* it would seem possible for them to be incorporated into IA64 & by the new team would seem to be 2005.   - bill   ------------------------------  % Date: Fri, 31 Aug 2001 17:50:13 -0400l- From: JF Mezei <jfmezei.spamnot@videotron.ca>R Subject: Re: I hate Compaq, Message-ID: <3B900685.3E39ED3E@videotron.ca>   Bill Todd wrote:J > My impression is that the most significant EV7 strengths (aside from theK > 0.18 micron process-shrink of the mostly-EV6 core) are its on-chip RAMBUS/B > support (eliminating an external RAMBUS controller chip and thusN > significantly reducing memory-access latency, not to mention reducing systemG > cost and complexity) and its on-chip SMP glue (which also should have6J > significant advantages in both performance and cost).  There's no publicN > indication that Intel has any similar IA64 features already in progress, andM > the *earliest* it would seem possible for them to be incorporated into IA64E( > by the new team would seem to be 2005.  J Something I don't quite understand here. EV7 and EV8 had different teams. K Would EV8 be a superset of EV7, and if so, how could EV8 begin serious worku before EV7 was done ?m  M If the EV8 team had to wait for EV7 to get far enough along before they could K start real work, wouldn't that mean that the EV8 team hadn't done that muche
 work yet ?   ------------------------------    Date: 31 Aug 2001 15:15:47 -0700/ From: Brannon_Batson@yahoo.com (Brannon Batson)- Subject: Re: I hate Compaq= Message-ID: <4495ef1f.0108311415.4fbd6404@posting.google.com>   a JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3B8FDAE5.99BB8D7F@videotron.ca>...o > Nick Maclaren wrote:? > > I hope that Compaq DOES pull off the EV7, as even temporarycB > > competition is always good, and think that it is probably moreB > > likely than not.  But it is by no means a foregone conclusion. > L > Perhaps the real goal of the EV7 folks is to give them a sand box in whichN > they can play in (Alpha) and test some stuff and once they are done with it,7 > they can then transfer it "debugged/tested" to Intel.o > M > Are there any technologies in EV7 that Intel would like to implement in its O > own chips eventually ? From what I understand, EV8 was still mostly on paper, F > whereas EV7 is closer to being a real thing, and this means that theI > technologies in EV7 would also be more developped/debugged than the EV8 6 > concepts that are not yet implemented anywhere else.  ( EV8 is much more than a paper processor.   Brannono not speaking for Intel   ------------------------------  % Date: Fri, 31 Aug 2001 18:36:45 -0400o' From: "Bill Todd" <billtodd@foo.mv.com>R Subject: Re: I hate Compaq( Message-ID: <9mp3gg$n42$1@pyrite.mv.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B900685.3E39ED3E@videotron.ca...   ...o  K > Something I don't quite understand here. EV7 and EV8 had different teams. H > Would EV8 be a superset of EV7, and if so, how could EV8 begin serious work > before EV7 was done ?  >pI > If the EV8 team had to wait for EV7 to get far enough along before theys couldPH > start real work, wouldn't that mean that the EV8 team hadn't done that much > work yet ?  K If your premise were correct, that might be true - but I don't believe your3L premise is correct (not to mention that EV7 is far enough along for at leastL significant work to have been done on EV8 even if your premise *were* true).  G While I hope people more familiar with the process will answer this, my L impression is that the approach was to alternate releases between major coreL changes and major periphery changes (e.g., the on-chip RAMBUS and SMP glue).L EV7 incorporates the latter, EV8 major changes in the former - and both setsC of changes could be, and were, developed significantly in parallel.S  I The EV8 team reportedly had completed a great deal of not only design but L development work, though not to the point of being close to running silicon.E Any changes in the EV7 features incorporated into EV8 would have beeneJ required for EV7 too, so in the event that EV7 were delayed by problems inC this area EV8 might have taken some hit as well (though less, sincemL course-corrections tend to be easier the earlier they occur).  But AFAICT noL reports of any such problems have surfaced, and even if they did they shouldG not affect the separation between EV7 and (would have been) EV8 release 7 dates, save possibly to have made them closer together.    - bill   ------------------------------    Date: 31 Aug 2001 21:50:38 -0700/ From: Brannon_Batson@yahoo.com (Brannon Batson)o Subject: Re: I hate Compaq= Message-ID: <4495ef1f.0108312050.2b7a98e2@posting.google.com>l  p "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message news:<TXLj7.1042$bB1.45773@news.cpqcorp.net>...H > Nick Maclaren wrote in message <9mnv56$8lv$1@pegasus.csx.cam.ac.uk>... > >d >  o
 > > [snip] > K > The good news is that IMHO the 3 best people in the world at what they doPF > are in charge of the EV7, the system platform, and the IO subsystem.   Agreed.t   Brannonq not speaking for Intel   ------------------------------  % Date: Fri, 31 Aug 2001 20:50:12 -0500o1 From: "David J. Dachtera" <djesys.nospam@fsi.net>o Subject: In Memoriam... ' Message-ID: <3B903ED4.B1F154E4@fsi.net>   F This message is posted to chi.internet, comp.os.vms and comp.dcom.xdsl  E Some of you may know Mark Levy from his postings in these newsgroups.a@ With a heavy heart and deep sadness, I share this news with you:  @ Mark sent a message by e-mail that his wife Gayle passed on this@ morning. She was diagnosed with lung cancer about 18 months ago.  G I have no further information at this time. See these URLs for where to $ send your condolences and symathies:   http://www.fsi.net/t http://www.sysman-inc.com/  E If you call and the automated attendant answers, dial x202 for Mark's: voice mail.   ; ...or watch the Chicago newspapers for further information.    -- d David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/y   ------------------------------  % Date: Fri, 31 Aug 2001 10:54:03 -0700e% From: Dean Woodward <deanw@rdrop.com>x; Subject: Re: Intel announces IA-64 "HyperThreading" in 2002u) Message-ID: <3B8FCF3B.F12E89FE@rdrop.com>    Tom Linden wrote:i > E > Just to put things in an historical perspective the CDC 6000 seriesy? > designed by Seymour Cray around 1965 also had this capabilitya  C Not surprised; also not surprised about Intel's "new" Machine CheckiH Architecture, mentioned in the same article.  What's old is new again...  . Yesterday I saw a pair of Velvet bell-bottoms.   Run away! Run away! ;-)    >  > > -----Original Message-----0 > > From: Dean Woodward [mailto:deanw@rdrop.com]* > > Sent: Friday, August 31, 2001 10:29 AM > > To: Info-VAX@Mvb.Saic.Coms? > > Subject: Re: Intel announces IA-64 "HyperThreading" in 2002- > >- > >- > > Warren Spencer wrote:3 > > >0B > > > On TechTV last night, I caught the tail end of a report that > > said Intel hasE > > > announced their "HyperThreading" technology, to be delivered inm
 > > 2002.  Its? > > > seemed remarkably similar to SMT.  An Intel rep also said  > > something alongdC > > > the lines of <we'll have to change the way we write software,  > > but it will  > > > be worth it>.m > > > ? > > > I took this to mean that the existing instruction set fori > > IA-64, or perhapsnE > > > it's architecture, will need to change to support this feature.  > >MA > > Hyperthreading, as implemented, exists in the Pentium 4 line. ? > > It's a weak second to SMT.  With HT, as I understood it, if B > > a processor happens to have a floating point op and an integer@ > > op on hand at the same time, it can run both of 'em at once,? > > instead of sequentially.  That's the limit to the HT magic. . > > It can't do two FP or integer ops at once. > > 5 > > http://news.cnet.com/news/0-1003-200-6991462.htmlr > >c     -- h+ Dean Woodward   |    # include <sigquote.h>r deanw@rdrop.com |sD ----------------+---------------------------------------------------= '66 Duc 250 - '85 Yam FJ1100 - '00 Kaw KLR650 - '01 Apr Falcoi   ------------------------------  % Date: Fri, 31 Aug 2001 17:32:45 -0400u' From: "Bill Todd" <billtodd@foo.mv.com>3; Subject: Re: Intel announces IA-64 "HyperThreading" in 2002-( Message-ID: <9movof$ilj$1@pyrite.mv.net>  2 "Dean Woodward" <deanw@rdrop.com> wrote in message# news:3B8FC968.12B52E98@rdrop.com...V   ...e  ? > Hyperthreading, as implemented, exists in the Pentium 4 line.t  L Right.  And there's no indication that something similar will appear in IA64F until at least 2006 (which is the *earliest* that the Alpha team couldK likely add it to that complex - or if you prefer messy - an architecture ife+ the hooks for it weren't already built in).a  = > It's a weak second to SMT.  With HT, as I understood it, ift@ > a processor happens to have a floating point op and an integer> > op on hand at the same time, it can run both of 'em at once,= > instead of sequentially.  That's the limit to the HT magic.d, > It can't do two FP or integer ops at once. >)3 > http://news.cnet.com/news/0-1003-200-6991462.htmle  G Well, the article suggests that real-world server applications could beaK speeded up by 30%, which would mean that HT could execute multiple *non*-FP H instructions at once (and the article doesn't say it can't, just that it" can't execute two FP ops at once).  J It actually seems to look quite a bit like EV8's SMT, except that we don'tI know if it currently adds more execution units to the P4 architecture and.H whether all execution units can be applied to service a single thread ifF multiple threads aren't present.  And, of course, it only supports two$ concurrent threads rather than four.   - bill   ------------------------------  % Date: Fri, 31 Aug 2001 20:27:54 -0400o' From: "Bill Todd" <billtodd@foo.mv.com>n; Subject: Re: Intel announces IA-64 "HyperThreading" in 2002-( Message-ID: <9mpa0q$s1e$1@pyrite.mv.net>  L Some additional information has now appeared in comp.arch under the 'Pentium 4 SMT "Hyperthreading"' thread.i   - bill  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9movof$ilj$1@pyrite.mv.net...   ------------------------------  # Date: Sat, 01 Sep 2001 01:15:06 GMTm. From: "Duane Sand" <duane.sand@mindspring.com>; Subject: Re: Intel announces IA-64 "HyperThreading" in 2002n> Message-ID: <uEWj7.35424$sa.18556588@news1.rdc1.sfba.home.com>   Tom Linden wroteE > Just to put things in an historical perspective the CDC 6000 seriesr@ > designed by Seymour Cray around 1965 also had this capability.  < The CDC 6000 series' Peripheral Processors unit supported 10@ independent threads at once, but in a very different statically-/ scheduled way than the dynamic OO scheduling on 0 Alpha EV8 SMT or Pentium 4 "hyperthreading" SMT.7 All 10 sets of registers were organized into a circular > shift register chain called a barrel.  Each thread got exactly2 1/10th of available "minor cycles", evenly spaced.2 The point of this was to do something useful while1 a given thread waited on a main memory fetch thatj5 took 10 times as long as cpu cycles.  (These machinese4 had no cache.)  When there weren't 10 useful threads3 to work on, barrel slots and alu cycles went wastede/ rather than being reallocated to make remainingh threads run faster.u  / This same simple timeslicing method was used one2 Xerox PARC's second-generation smalltalk machines. I believe CDC was first.   ------------------------------  % Date: Fri, 31 Aug 2001 21:28:16 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>n; Subject: Re: Intel announces IA-64 "HyperThreading" in 2002i, Message-ID: <3B9039AF.F2F141C6@videotron.ca>   Bill Todd wrote:N > Right.  And there's no indication that something similar will appear in IA64H > until at least 2006 (which is the *earliest* that the Alpha team could > likely add it to that complext  B You're forgetting the past. Intel stole and then implemented AlphaG technologies for its Pentium, and only much later did it negotiate withh4 Digital to get the official right to use that stuff.  A So, I would think it very possible that Intel started to plan for K alpha-inspired technologies for its upcoming IA64s well before the deal waswJ announced by Compaq. And it would not surprise me one bit to find out thatL Compaq had given Intel informal permission to start to "inspire" itself fromI all the alpha intellectual property well before the deal was made public.    ------------------------------  % Date: Fri, 31 Aug 2001 22:09:40 -0400-  From: John Santos <JOHN@egh.com>; Subject: RE: Intel announces IA-64 "HyperThreading" in 2002 6 Message-ID: <1010831220411.61567C-100000@Ives.egh.com>  & On Fri, 31 Aug 2001, Tom Linden wrote:  E > Just to put things in an historical perspective the CDC 6000 seriest? > designed by Seymour Cray around 1965 also had this capabilityt  F Couldn't the VAX 11/780 do this too?  And maybe even the PDP 11/45 FPU# (only about 8 years after Cray...)?m   > > -----Original Message-----0 > > From: Dean Woodward [mailto:deanw@rdrop.com]* > > Sent: Friday, August 31, 2001 10:29 AM > > To: Info-VAX@Mvb.Saic.Comr? > > Subject: Re: Intel announces IA-64 "HyperThreading" in 2002t > >  > >  > > Warren Spencer wrote:h > > > C > > > On TechTV last night, I caught the tail end of a report that i > > said Intel hasF > > > announced their "HyperThreading" technology, to be delivered in 
 > > 2002.  Ith@ > > > seemed remarkably similar to SMT.  An Intel rep also said  > > something along-D > > > the lines of <we'll have to change the way we write software,  > > but it willj > > > be worth it>.q > > > @ > > > I took this to mean that the existing instruction set for  > > IA-64, or perhapslE > > > it's architecture, will need to change to support this feature.l > > A > > Hyperthreading, as implemented, exists in the Pentium 4 line.c? > > It's a weak second to SMT.  With HT, as I understood it, if'B > > a processor happens to have a floating point op and an integer@ > > op on hand at the same time, it can run both of 'em at once,? > > instead of sequentially.  That's the limit to the HT magic.e. > > It can't do two FP or integer ops at once. > > 5 > > http://news.cnet.com/news/0-1003-200-6991462.htmlh > >  >  >    --   John Santosn Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  $ Date: Sat, 1 Sep 2001 01:30:05 -0400' From: "Bill Todd" <billtodd@foo.mv.com>a; Subject: Re: Intel announces IA-64 "HyperThreading" in 2002 ( Message-ID: <9mprne$9ir$1@pyrite.mv.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B9039AF.F2F141C6@videotron.ca... > Bill Todd wrote:K > > Right.  And there's no indication that something similar will appear inv IA64J > > until at least 2006 (which is the *earliest* that the Alpha team could! > > likely add it to that complexc >a > You're forgetting the past.   D No:  I'm assessing the situation, unlike your propensity for drawing3 conclusions based on vague speculation and no data.d  F IA64 has to all appearances been developed with zero attention paid toK things like out-of-order execution (in fact, it was developed explicitly tosK *avoid* out-of-order execution).  OOO and SMT are intimately intertwined in J EV8's SMT design, and apparently also in HT's.  There's no indication thatL Intel has until now given any thought toward incorporating SMT/HT technologyH in EPIC, and every indication that it will thus take at least close to 5@ years before such IA64 technology hits the street (especially asL incorporating it into EPIC will almost certainly involve radically differentG internal approaches than those used to incorporate it into EV8 and P4).    - bill   ------------------------------  % Date: Fri, 31 Aug 2001 14:17:17 -0400k' From: "Bill Todd" <billtodd@foo.mv.com>RL Subject: Re: Intel has released Hyper-threading for it's next gen processors( Message-ID: <9moka3$9r2$1@pyrite.mv.net>  5 "Nic Clews" <sendspamhere@127.0.0.1> wrote in messagei# news:3B8F50CF.E5EE41A0@127.0.0.1...d > mist dragon wrote: > >g > > Look atr > >nA > > http://www.zdnet.com/zdnn/stories/news/0,4586,2809007,00.htmli > >AG > > While not exactly the same as SMT planned for future gens of Alpha,l  > > still quite close isn't it ? >6  > Now thats a surprise isn't it.  F No - at least not if the technology is the 'Jackson' that's been being talked about for a while now.M  I It seems to be only 2-way rather than 4-way (as EV8 was scheduled to be), G and there was no mention of the ability to use more functional units totC widen single-thread issue (as EV8 would have).  But it does tend to D underscore the thesis that SMT fits easily into an OOO architecture.   - bill   >gJ > It is a pity that Paul DeMone is not going to be writing more because asB > technical details emerge I'd be interested to read his analysis. >) > --* > Regards, Nic Clews CSC Computer Sciences > nclews at csc dot coms   ------------------------------  % Date: Fri, 31 Aug 2001 15:22:42 -0400 ; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com> 4 Subject: Re: Is there a why to set verify in sysgen?" Message-ID: <3b8fe450@news.si.com>  > >> Bizzareness.  What does this do?  STARTUP_Pn modifications? >E >No. Well, I do not think so.   J The /VERIFY qualifier DOES set STARTUP_P2.  See HELP SET OPTIONS/VERIFY in SYSMAN.E --A Brian Tillman                   Internet: tillman_brian at si.com A Smiths Aerospace                          tillman at swdev.si.comt= 3290 Patterson Ave. SE, MS      Addresses modified to prevent-< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  % Date: Fri, 31 Aug 2001 13:40:42 -0500 & From: Charles Sebold <sebold@lcms.org>* Subject: LSE (was: Re: Wailing at Eunuchs)% Message-ID: <873d68yswl.fsf@lcms.org>:  ' On 12 Elul 5761, Bill Gunshannon wrote:E  A >|> > So don't use vi, use the dozens of other editors out there.t >|> @ >|> 	Yep.  The Unix answer.  Buy a product and tailor it to suit >|> 	your needs.   > G > Buy???   There are more than a dozen free editors available for Unix.hD > Surely one of them would prove acceptable??  Unless, of course you1 > believe, "If it ain't LSE it ain't an editor!!"e  F And LSE has been ported to Emacs (called ELSE), so you can even run itG on any platform capable of Emacs (including Windows, Mac OS, and nearlyn  every flavor of Unix out there).  " http://members.nbci.com/pmilliken/ -- hH Charles Sebold        K'tivah V'chatimah Tovah        12th of Elul, 5761H LCMS - Office of Information Systems                http://unix.ois.org/=         *** Opinions expressed herein are not necessarily ***n=         *** those of the Lutheran Church - Missouri Synod ***    ------------------------------  % Date: Fri, 31 Aug 2001 14:27:41 -0400v- From: JF Mezei <jfmezei.spamnot@videotron.ca>  Subject: Re: Mark Twain Promo , Message-ID: <3B8FD71A.5733B0D9@videotron.ca>   John Macallister wrote:.L > package of manuals awaiting collection in stores. When I actually read theL > "binder inserts" and then dicovered the Mark Twain book I realised that it > was another "junk" mailshot.  K For as much as I am critical of Compaq, I didn't consider this to be a junktL mailshot. What I saw in this was essentially an admission from the VMS groupF that Compaq's handling of the Alpha genocide hurt VMS's image and they= attempted with a bit of humour to tell folks VMS wasn't dead.   J Consider also that Gorham is new at that job, so that was a way to present# himself to those interested in VMS.   K This mailing does nothing to improve *Compaq's* image, but it does say thath. the VMS group is still alive ~despite~ Compaq.   ------------------------------  # Date: Fri, 31 Aug 2001 18:00:15 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: OPCOM in VMS.3 Message-ID: <PgQj7.1069$bB1.46012@news.cpqcorp.net>a  d In article <39ac55d0.0108310831.204ce45@posting.google.com>, scada@cyberunlimited.org (Jeff) writes:L :I received the following message from OPCOM from VMS 7.1. Can anyone please :explain it to me. .." :Message from user SYSTEM on CVHQA( :Event: Unavailable User Buffer from:...  D   You have one or more applications that are not keeping up with theE   incoming DECnet network traffic.  DECnet is telling you that it has D   attempted to deliver a message, and the application was not ready.  I :My Alpha Systems loses response time and slows down, and these messages c' :keep filling up the Operator.log File.   D   I suspect the DECnet OPCOM messages are actually secondary to the    system performance problem.   J   You will want to identify and remove the performance-limiting factor(s) H   in your current configuration, using details learned from the OpenVMS E   performance manual.  (Assuming this is not a simple case of no free@E   physical memory or simular "obvious" problem, remotely diagnosing a F   system performance bottleneck is usually involved, as it requires a H   detailed performance data collection process and a good understanding %   of the system-specific activities.)s  G   You will also want to apply the available mandatory ECO kits for your H   OpenVMS Alpha version -- V7.1-2 with ECOs, V7.2-1 with ECOs, or later.  F   Also check for and apply available ECOs for any third-party and any >   Compaq layered product packages that might be involved here.  0 :If you have any ideas please Email me directly.     Ask here, get an answer here.   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: Fri, 31 Aug 2001 17:03:42 -0400e' From: "Bill Todd" <billtodd@foo.mv.com>dR Subject: Re: OpenVMS on Fault Tolerant IPF Hardware (was Re: EV7 will never ship?)( Message-ID: <9mou20$h8d$1@pyrite.mv.net>  ? "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messages6 news:DkHj7.1522$%e5.4073583@typhoon.ne.mediaone.net...   ...b  4 > Tru64 UNIX will be fault tolerant long before VMS.  D Given that VMS *was* fault-tolerant over a decade ago on ftVAX, that) statement seems at least a bit excessive.     Can you say processE > pairing and process mirroring? Sure you can, if you work for Tru64!4  L And of course you could have 'said it' for more than 2 decades on NSK, whereK it was pioneered (unless IBM got there on some platform even earlier, as is0 so often the case).d  I But process-pairing is anything but transparent to the code (which is why H hardware approaches are so much more common):  Jim Gray observed (in hisJ excellent tome on TP with Andreas Reuter) that correct process-pair codingK was some of the most complex one could find, so it's not exactly a panacea,eH and certainly not the easiest answer for most FT use (given the relativeL costs of hardware - even FT hardware, which is rapidly becoming available inL the 'industry-standard' space - vs. complex, custom software, not to mention0 the superior performance of hardware solutions).  ? And finally, at least in one common incarnation it's not *real*nG 'fault-tolerance' but just another approach to high-availability, since F unless every output is checked against an actively-executing (not justH ready-to-take-over) pair-process before being committed it won't protect$ against undetected hardware failure.   - bill   ------------------------------  % Date: Sat, 01 Sep 2001 01:26:18 +0200e From: Dirk Munk <munk@home.nl> Subject: some mozilla questionsd& Message-ID: <3B901D1A.3060106@home.nl>  G I downloaded Mozilla today, and I'm happy to say it is running great !  B It is quite fast and was even faster after I installed all images ' (install.com in the Mozilla directory).t  & So this message comes from Mozilla :-)   But I have some questions:I 1. Is it possible to change the screen resolution of Motif on a Personal c workstation?8 2. The date in Mozilla news and mail is in US/UK format I (month/day/year). I would like to have it in continental European format  I (day/month/year). On a windooz pc the format is usualy determined by the -9 "Regional Settings". But there is no such thing in VMS...    ------------------------------    Date: 31 Aug 2001 19:29:44 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)0# Subject: Re: some mozilla questionsv3 Message-ID: <r1gpbWXr39IE@eisner.encompasserve.org>a  G In article <3B901D1A.3060106@home.nl>, Dirk Munk <munk@home.nl> writes:    > But I have some questions:  : > 2. The date in Mozilla news and mail is in US/UK format K > (month/day/year). I would like to have it in continental European format  K > (day/month/year). On a windooz pc the format is usualy determined by the  ; > "Regional Settings". But there is no such thing in VMS...d  < Well, strictly speaking, that was not a question :-), but...  F The overview of the VMS method of handling such things is described atI file:///VMSDOC073/v73/5841/5841pro_074.html#30_specifyingformatsatruntimel# on the current documentation CDROM.o  = I have no knowledge of whether Mozilla honors those controls.a   ------------------------------  % Date: Fri, 31 Aug 2001 14:21:57 -0400P- From: JF Mezei <jfmezei.spamnot@videotron.ca>t( Subject: Re: Some postive points I hope., Message-ID: <3B8FD5C3.F599CF48@videotron.ca>   Fred Zwarts wrote:A > My experience is opposite, in particular for multi-volume sets.eM > Backing up a multi-volume set of 5 disks of 2 Gb each costed about 3 hours.aN > I started a restoration, but gave up after 3 hours when it had only restored > 5% of the data.x  M Does it make a huge difference if the target disk is "empty" to begin with asiN opposed to already populated with BACKUP creating new versions of files and/or overwriting existing ones ?'  N I know that backup can be terribly slow when you are asking for specific filesM since it still has to scan through all of the files ahead of it to eventually7 get to the file you want.d  M Does a tape device read slower that it writes ? If reads are done at the same2M speed/throughput as writes on the tape device, and if a tape device is sloweraL than a disk device, then significantly slower restores would mean that it isN the VMS file system that is slower than a tape drive. Could that really be the case ?   ------------------------------  % Date: Fri, 31 Aug 2001 15:30:32 -04000- From: "Richard D. Piccard" <piccard@ohio.edu>n( Subject: Re: Some postive points I hope.( Message-ID: <3B8FE5CE.24E71C4F@ohio.edu>  Q If the target device is MOUNTED other than /FOR, I would expect BACKUP to presume L that there might be other ongoing activity against that drive from other VMSN processes, and therefore to use normal VMS calls, requiring a minimum of threeK writes for each file:  the data, the directory, and INDEXF.SYS.  Caching ofd" QUOTA.SYS updates would help some.  O The  slowness that Fred describes is consistent with what I remember from other. experiences, long ago.  P Perhaps an /IMAGE restore could be done faster, with the target volume MOUNT/FOR= ???  I won't have an opportunity any time soon to experiment.e  #                                 RDPn     JF Mezei wrote:e   > Fred Zwarts wrote:C > > My experience is opposite, in particular for multi-volume sets.cO > > Backing up a multi-volume set of 5 disks of 2 Gb each costed about 3 hours.sP > > I started a restoration, but gave up after 3 hours when it had only restored > > 5% of the data.u > O > Does it make a huge difference if the target disk is "empty" to begin with assP > opposed to already populated with BACKUP creating new versions of files and/or > overwriting existing ones ?  >0P > I know that backup can be terribly slow when you are asking for specific filesO > since it still has to scan through all of the files ahead of it to eventuallyi > get to the file you want.  >rO > Does a tape device read slower that it writes ? If reads are done at the same0O > speed/throughput as writes on the tape device, and if a tape device is slowerpN > than a disk device, then significantly slower restores would mean that it isP > the VMS file system that is slower than a tape drive. Could that really be the > case ?   --B ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  % Date: Fri, 31 Aug 2001 21:02:52 -0500l1 From: "David J. Dachtera" <djesys.nospam@fsi.net>c3 Subject: Re: still can't get my UCX licensed??????? ' Message-ID: <3B9041CC.F3F22C1D@fsi.net>o   Larry Kilgallen wrote: > \ > In article <3B8F0403.CE7F3EB@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes: > F > > You're quite right, of course. The TCP/IP topic comes up so often,K > > though, and not having it be part of the system (i.e., a SIP instead ofyL > > a normal part of the basic installation) seems to be the confusing part./ > > At least that much seems worthy of mention.  > I > That would certainly be an attack on the notion of third party vendors.r  G Can't say as I've lately seen a third-party IP stack for Linux or UN*X.   D In the old days (W/3.x) there was TCP/IP for Windows (MS), TCP/IP-32H (MS), Chameleon, Trumpet - even a Multinet for Windows back in TGV days!	 Now, ...?   F I like having the choice (prefer Multinet myself), but this needs some5 explanation for those to whom the concept is foreign.e   That's all I'm saying, really.   -- m David J. Dachteraa dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t   ------------------------------    Date: 31 Aug 2001 22:00:55 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)o3 Subject: Re: still can't get my UCX licensed???????w3 Message-ID: <QJYO58$p6F8l@eisner.encompasserve.org>   [ In article <3B9041CC.F3F22C1D@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:. > Larry Kilgallen wrote: >> i] >> In article <3B8F0403.CE7F3EB@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:a >> mG >> > You're quite right, of course. The TCP/IP topic comes up so often,tL >> > though, and not having it be part of the system (i.e., a SIP instead ofM >> > a normal part of the basic installation) seems to be the confusing part. 0 >> > At least that much seems worthy of mention. >> 6J >> That would certainly be an attack on the notion of third party vendors. > I > Can't say as I've lately seen a third-party IP stack for Linux or UN*X.s > F > In the old days (W/3.x) there was TCP/IP for Windows (MS), TCP/IP-32J > (MS), Chameleon, Trumpet - even a Multinet for Windows back in TGV days! > Now, ...?o > H > I like having the choice (prefer Multinet myself), but this needs some7 > explanation for those to whom the concept is foreign.2 >   > That's all I'm saying, really.  E Yes, Process Software just happens to be a premier example of a thirdt1 party concentrating on VMS -- I wish we had more.   @ Perhaps the real solution to the original problem is to simplifyB the hobbyist license process.  I am skeptical that there is reallyJ anyone who wants a hobbyist VMS license but _no_ layered product licenses.   ------------------------------  % Date: Fri, 31 Aug 2001 14:38:20 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>n$ Subject: Re: Sun has a go at Itanium, Message-ID: <3B8FD999.9794A902@videotron.ca>   "D.Webb" wrote:d- > Just seen this on http://silicon.com/p46947eI >    Tom Yates, director of high performance systems EMEA at Compaq, saidcK >    this is an attempt by Sun to create uncertainty, doubt and mischief inwF >    the market place to catch some business, because it is "unable to2 >    articulate any movement in its own business".  M Look who's talking about uncertainty and doubt. Compaq's not in a position to0K argue about this sinec that uncertainty and doubt is mostly due to Compaq's  murder of Alpha.  G >    He said Sun will be forced to adopt Itanium in two to three years'c0 >    time, as it will dominate 64-bit computing.  N Says an emoployee of a company so convinced that Intel and Microsoft will ruleL the whole world that they are willing to amputate their own limbs right awayU because they think that they can get new ones from Intel and Microsoft in the future.u  K >    In addition, Yates said Sun is trying to cover up its lack of openness F >    with its own customers. "They do not know how to communicate with >    customers," said Yates.  M Ah ! Look who is talking. Perhaps Mr Yates would care to start to communicatenM with all its customers the true plans for VMS, and licensing options for that L forced conversion to IA64 nobody wants etc etc ? Again, Yates is pointing at7 faults where Compaq is much worse than its competitors.i  D >    "It will become difficult for Sun to keep Sun Sparc alive as an6 >    alternative to Itanium in 10 years," said Butler.  I Interesting how these Gartner and Wall Street Casino Analysts are able tosI predict the future 10 years ahead and blindly give Intel ownership of the2I world whithout considering architecture consideration which might allow auN cometing chip to prograes at a afaster rate than Intel's bloated architecture.  F >    Intel flatly denied Sun's claims. Chris Hogg, enterprise businessH >    manager for EMEA at Intel, told silicon.com: "There's a plethora ofE >    applications and tools and operating systems" for Itanium chips.   J Yep, since Compaq donated all its compiler and Alpha jewels, Intel now hasI some rights to brag about that. But all the Alpha stuff and compilers arerL likely not yet ported to IA64. So while Intel does have the "right stuff" it/ still needs to put it all together doesn't it ?   N How long would it take for the es-Digital compiler folks to get their stuff up and running on IA64 ?r   ------------------------------  % Date: Fri, 31 Aug 2001 14:43:20 -0400e' From: "Bill Todd" <billtodd@foo.mv.com>n$ Subject: Re: Sun has a go at Itanium( Message-ID: <9molqq$ava$1@pyrite.mv.net>  4 "D.Webb" <david20@alpha2.mdx.ac.uk> wrote in message% news:9mnqc1$b6b$1@aquila.mdx.ac.uk...  >t- > Just seen this on http://silicon.com/p46947m >  > "a2 >       Sun and Intel go head-to-head over Itanium >o. >    What good's a mechanic without a toolkit? >yJ >    Sun Microsystems has dismissed Intel's Itanium strategy, claiming theD >    processor has no proven development tools to back it up, making; >    investment in the architecture highly risky for users.r >lG >    Matthew Keep, product manager for servers at Sun, told silicon.comrD >    that Sun's Sparc 64-bit processor technology is the only viableH >    alternative, justifying its lonely stance as the only vendor not to >    adopt Itanium.e  L Guess he missed Power4 in that assessment.  Not to mention the potential for< AMD's Hammer to take over the low end of the 64-bit segment.   ...r   >    Silicon Says4K >    A bright future for Itanium? Perhaps brighter than that we painted forw >    the P4, a few months back..F >    Keep claimed Compaq's move to discontinue its AlphaServer line toJ >    introduce Itanium-based servers had caused unrest among some users of >    Compaq's systems.  ! My God!  Someone finally noticed!    >nG >    However, Compaq said its strategy to move to Itanium is a bold onet( >    which its customers firmly support.  I ... but that obviously didn't encourage the reporter to actually research'E the situation rather than just quote Compaq's party line in rebuttal.i  #  The company's plan is to integratesI >    Itanium over a seven to eight year period, during which time it willa. >    gradually phase out its AlphaServer line. > I >    Tom Yates, director of high performance systems EMEA at Compaq, saidaK >    this is an attempt by Sun to create uncertainty, doubt and mischief in-F >    the market place to catch some business, because it is "unable to2 >    articulate any movement in its own business".  G The other way to look at it is that Sun prefers no movement to backwardcJ movement.  Though moving from SPARC to IA64 might just be lateral for Sun,4 rather than as regressive as the move from Alpha is.   > G >    He said Sun will be forced to adopt Itanium in two to three years'S0 >    time, as it will dominate 64-bit computing.  F And (as my daughter is prone to say) monkeys might fly out of my butt.L Don't hold your breath for either to happen, especially not in "two to three
 years' time".l   >aK >    In addition, Yates said Sun is trying to cover up its lack of opennessnF >    with its own customers. "They do not know how to communicate with >    customers," said Yates.  F ROTFLMAO!  Some Compaq nitwit is saying that *Sun* doesn't know how to! communicate with its customers???o   ...f  I >    However, Butler said in five years time it will become difficult fort+ >    Sun to fend off the growth of Itanium.  ...f  D >    "It will become difficult for Sun to keep Sun Sparc alive as an6 >    alternative to Itanium in 10 years," said Butler.  L Even the analysts who've been brain-washed by Intel's supposed invincibility1 don't believe it's going to happen any time soon.d   - bill   ------------------------------  # Date: Sat, 01 Sep 2001 00:26:27 GMTa2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>% Subject: Re: Tunneling DECnet over IPi? Message-ID: <TWVj7.2769$_I.1446637@e3500-chi1.usenetserver.com>y  3 Robert Deininger <rdeininger@mindspring.com> wrote:lI > Hooray!  The world hasn't been as fun since HEPnet started to rot away.e  K > Is anyone managing the HECnet address space?  Since parts of HEPnet still-L > exist (but are mostly not connected anymore) it would perhaps be useful toJ > avoid collisions with existing HEPnet nodes where possible.  Some HEPnet$ > nodes might want to join HECnet...  I Johnny Billquist is currently managing the address space, I don't know ife- he's ever heard of HEPnet (I know I haven't).-  N >> I've been looking at the DECnet over IP information in the TCPIP and DECnetO >> manuals, and as far as I can tell, all it really does is allow you to use IPRN >> addresses and such with your DECnet aware apps to connect to remove systems >> over TCPIP.  H > I can't point to a specific part, but I don't like your description ofK > DECnet over IP.  Once you configure it, it looks like DECnet to users and L > apps, and it can run over tcpip behind the scenes.  Nobody ever has to seeL > the tcpip addresses, except the administrator.  It just looks like DECnet.  I I don't doubt that my description stinks!  From what little I was able to L find in the manuals, my understanding of it is pretty limited.  I did find aF slightly better description earlier today, but it's still not detailed enough for my tastes.c  G >> What I'm looking for is some sort of tunneling software that runs oneK >> OpenVMS, and negates the need for having a UNIX box.  Is anyone aware ofo >> such software?a  K > A DECnet-plus routing node can connect phase-IV only networks to phase-V,uF > DECnet-over-tcpip networks.  So a VMS machine can do the tunnelling.E > Phase-IV nodes are restricted to the small DECnet-IV address space.   I > DECnet-plus can do decnet-over-tcpip with any tcpip stack that supportscK > the PWIP (pathworks) driver.  That includes UCX, TCPIP, and Multinet that F > I know of.  I think TCPware as well, but I've no experience with it.  K > Multinet also has it's own DECnet-over-tcpip tunnelling, which works withiB > DECnet-IV, but only between multinet (and maybe tcpware?) nodes.  J Based on this, I take it that you can do DECnet-over-tcpip between systemsL running TCPIP and Multinet?  This sounds interesting.  On the downside rightL now they seem to only be tunning serial DECnet links over the Internet (they have their reasons).  , > Now I'll go take a look at this VPN thing.  N I've not tried VTUN out yet, but it looks pretty cool, even if it does require UNIX.    			Zanet   ------------------------------  % Date: Fri, 31 Aug 2001 21:51:37 -0400h  From: John Santos <JOHN@egh.com>% Subject: Re: Tunneling DECnet over IP 6 Message-ID: <1010831212112.61567B-100000@Ives.egh.com>  , On Fri, 31 Aug 2001, Robert Deininger wrote:  H > In article <twDj7.297$_I.534633@e3500-chi1.usenetserver.com>, "Zane H., > Healy" <healyzh@shell1.aracnet.com> wrote: > J > > Oddly enough there is currently a hobbyist project underway to setup a) > > global Hobbyist DECnet (aka HECnet). e > I > Hooray!  The world hasn't been as fun since HEPnet started to rot away.g > K > Is anyone managing the HECnet address space?  Since parts of HEPnet still:L > exist (but are mostly not connected anymore) it would perhaps be useful toJ > avoid collisions with existing HEPnet nodes where possible.  Some HEPnet$ > nodes might want to join HECnet... > ( > > It will have hosts running more thanM > > just OpenVMS, in fact the first couple hosts seem to be PDP-11's (and I'd F > > also like to see PDP-10's eventually, though they'd most likely beJ > > emulated).  The solution so far is to stick UNIX boxes running VTUN[1]N > > between the remote DECnet segments to tunnel the DECnet over the Internet. > > O > > I've been looking at the DECnet over IP information in the TCPIP and DECnet5P > > manuals, and as far as I can tell, all it really does is allow you to use IPO > > addresses and such with your DECnet aware apps to connect to remove systems- > > over TCPIP.- > H > I can't point to a specific part, but I don't like your description ofK > DECnet over IP.  Once you configure it, it looks like DECnet to users andCL > apps, and it can run over tcpip behind the scenes.  Nobody ever has to seeL > the tcpip addresses, except the administrator.  It just looks like DECnet. > H > > What I'm looking for is some sort of tunneling software that runs onL > > OpenVMS, and negates the need for having a UNIX box.  Is anyone aware of > > such software? > K > A DECnet-plus routing node can connect phase-IV only networks to phase-V,AF > DECnet-over-tcpip networks.  So a VMS machine can do the tunnelling.E > Phase-IV nodes are restricted to the small DECnet-IV address space.c  E I don't think DECnet-plus can route between a local Phase-IV end nodeiC and a remote Phase V node, when the only connection between the twoaF phase V nodes is IP.  IOW, if I have a LAN with some phase IV and someC phase V nodes, and a similar remote LAN with a similar mixture, thenE Phase V nodes can talk to any local node and all the remote Ph V, butsE the phase IV nodes can only talk to local nodes.  (If you have DECnetl? circuits, then the Ph IV nodes can of course talk to any system3) so connected via a Ph IV or Ph V router.)D  F This is because the DECnet-over-IP service operates at the applicationC link level (in Ph IV terminology), end-system to end-system, ratherO6 than as a virtual DECnet circuit at the routing level.  ? If I'm wrong about this, I would love to know how to do it!  Itm- certainly doesn't "just work" out of the box.m  I > DECnet-plus can do decnet-over-tcpip with any tcpip stack that supportstK > the PWIP (pathworks) driver.  That includes UCX, TCPIP, and Multinet that.F > I know of.  I think TCPware as well, but I've no experience with it.  B Works fine with TCPWare.  I think it also used to work with WINTCPE (Wollongong), but I don't remember for sure.  (The two remote systemsnD we had using WINTCP were merged into a single system and switched toE TCPWare when DCA? (or who-ever owned it most recently) dropped out ofrF the business 2-3 years ago and Process offered a free switch to eitherE TCPWare or Multinet if you bought a 1-year support contract.)  AFAIK, D it doesn't work with CMU, but that's probably moot since you can get; a hobbyist license for UCX/TCPIP, TCPWare and Multinet now.r  K > Multinet also has it's own DECnet-over-tcpip tunnelling, which works withlB > DECnet-IV, but only between multinet (and maybe tcpware?) nodes.  B Multinet and TCPware both have a DECnet-over-ip tunnelling virtualD circuit (works with both Ph IV and Ph V, I think, but I've only usedA it with Ph IV), but I don't know if they are compatible with eachoA other.  I'm sure they both predate Process owning both stacks, sor- they might have completely different origins.a  , > Now I'll go take a look at this VPN thing.  > VPN on VMS would be a GOOD THING.  I could network my home LAN= to the office without buying a VPN router/server.  (MicroSoftr= VPN seems to support Internet connection sharing, but the 1st=? thing it wants to do if you try to turn it on is take over your D entire network, become the DHCP server, renumber your network, etc.,@ and generally behave like MicroSoft, so I click "Cancel" and got the hell out of there fast.)   > --   > Robert Deininger > rdeininger@mindspring.com-   -- - John Santosr Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Sat, 01 Sep 2001 02:10:37 GMTsL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")% Subject: Re: Tunneling DECnet over IPi8 Message-ID: <00A015D9.15071CA6@SSRL04.SLAC.STANFORD.EDU>  Y In article <1010831212112.61567B-100000@Ives.egh.com>, John Santos <JOHN@egh.com> writes: - >On Fri, 31 Aug 2001, Robert Deininger wrote:P  F >I don't think DECnet-plus can route between a local Phase-IV end nodeD >and a remote Phase V node, when the only connection between the twoG >phase V nodes is IP.  IOW, if I have a LAN with some phase IV and somesD >phase V nodes, and a similar remote LAN with a similar mixture, theF >Phase V nodes can talk to any local node and all the remote Ph V, butF >the phase IV nodes can only talk to local nodes.  (If you have DECnet@ >circuits, then the Ph IV nodes can of course talk to any system* >so connected via a Ph IV or Ph V router.) > G >This is because the DECnet-over-IP service operates at the application D >link level (in Ph IV terminology), end-system to end-system, rather7 >than as a virtual DECnet circuit at the routing level.e >.@ >If I'm wrong about this, I would love to know how to do it!  It. >certainly doesn't "just work" out of the box.  K Poor Man's Routing seems to work, at least for FAL.  SET HOST doesn't work.g  2 I just tried this with a convenient phase iv node.  , $ DIR localPhaseV::remotePhaseV.domain.tld::   and saw files; p  M $ DIR localPhaseV::remotePhaseV.domain.tld::differentlocalPhaseV.domain.tld::F   also worked.  ; I'm pretty sure (but can't easily test), that you could do Y  0 $ DIR localphaseV::remotePhaseV::remotePhaseIV::  K remotePhaseV was my home VMS system using the static IP address assigned byI= the DSL provider, and I don't have any phaseIV nodes at home.m  	 I did tryo  A $ DIR localphaseV::differentlocalPhaseV::differentlocalphaseIV:: 6 and got a connection.l   -- Alana    O ===============================================================================-0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056,M  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210 O ===============================================================================o   ------------------------------  % Date: Fri, 31 Aug 2001 23:38:20 -0400r  From: John Santos <JOHN@egh.com>% Subject: Re: Tunneling DECnet over IP 6 Message-ID: <1010831225453.61567D-100000@Ives.egh.com>  > On Sat, 1 Sep 2001, Alan Winston - SSRL Admin Cmptg Mgr wrote:  [ > In article <1010831212112.61567B-100000@Ives.egh.com>, John Santos <JOHN@egh.com> writes:b/ > >On Fri, 31 Aug 2001, Robert Deininger wrote:e > H > >I don't think DECnet-plus can route between a local Phase-IV end nodeF > >and a remote Phase V node, when the only connection between the twoI > >phase V nodes is IP.  IOW, if I have a LAN with some phase IV and someoF > >phase V nodes, and a similar remote LAN with a similar mixture, theH > >Phase V nodes can talk to any local node and all the remote Ph V, butH > >the phase IV nodes can only talk to local nodes.  (If you have DECnetB > >circuits, then the Ph IV nodes can of course talk to any system, > >so connected via a Ph IV or Ph V router.) > >wI > >This is because the DECnet-over-IP service operates at the applicationrF > >link level (in Ph IV terminology), end-system to end-system, rather9 > >than as a virtual DECnet circuit at the routing level.a > >IB > >If I'm wrong about this, I would love to know how to do it!  It0 > >certainly doesn't "just work" out of the box. > M > Poor Man's Routing seems to work, at least for FAL.  SET HOST doesn't work.   J I forgot about this.  (Must of known about it once, as I found an internalE message I posted 2 years ago recommending someone else do this, for aaF slightly different problem.  Must be getting old-timers disease... :-(   4 > I just tried this with a convenient phase iv node. > . > $ DIR localPhaseV::remotePhaseV.domain.tld:: >  > and saw files; w > O > $ DIR localPhaseV::remotePhaseV.domain.tld::differentlocalPhaseV.domain.tld::d >  > also worked. > = > I'm pretty sure (but can't easily test), that you could do a > 2 > $ DIR localphaseV::remotePhaseV::remotePhaseIV:: > M > remotePhaseV was my home VMS system using the static IP address assigned byi? > the DSL provider, and I don't have any phaseIV nodes at home.  >  > I did try  > C > $ DIR localphaseV::differentlocalPhaseV::differentlocalphaseIV:: u > and got a connection.l  0 I can't test everything right now, but I did getC DIR remotePhaseV::differentremotePhaseV:: to work, where there is acD TCP/IP firewall between the local system and the remote systems thatA allows access to the 1st remote system, but not the second.  (Thei? 2 remote systems are on the same Ethernet LAN, the local systemaE and the 1st remote system have TCPWare, whereas the 2nd remote systema= has UCX, but I'm not sure if the two remote systems are usingA@ DECnet protocol or IP over their ethernet.  The WAN is IP/only.)  M I also tried (from a remote Ph V system via a pair of Ph IV DECRouter-250's),eB DIR remotePhaseV::remoterPhaseIV::2nRemoterPhaseIV:: and that alsoH worked.  (Where remotePhaseV was any of {VAX w/TCPWARE, Alpha w/TCPWare,E Alpha w/UCX}, and the two remote PhaseIV's were a CI cluster of VAX's-C with a serial async connection from a local terminal port on one of E them to that same DR250 that has the sync line to the original remoteD< PhaseV VAX).  (BTW, I am getting frequent errors of the form  J %DIRECT-E-OPENIN, error opening REMOTEPHASEV"user password"::*.*; as input- -RMS-F-SYS, QIO system service request faileda* -SYSTEM-F-LINKEXIT, network partner exited  A when I try to use the VAX 4200 as the intermediate system, though ? sometimes it works.  Maybe it is just too slow and something isgD timing out??  Seems to be solid using either Alpha as the PM router.  = As for SET HOST, I couldn't get that to poor-man's route, butr= that is less critical.  You can always set host to the routerl? and then set host from there to the end node (assuming you have < an account on the intermediate system.)  It's only one extra> step.  The same for FAL access is much more painful, since you; have to drop off the files at the intermediate system, theni9 log in there and copy them on to the next hop.  Trying to : diff a local and remote file is exponentially worse, since? you need to get *both* files to a common intermediate point, ore= worry about copying a file the wrong way if you guessed wrongs! about why they are different...     	 > -- AlanI   -- b John Santosh Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Fri, 31 Aug 2001 18:19:52 -0700s! From: Don Sykes <don@alphase.com> & Subject: VMS'er Announces Java Product+ Message-ID: <3B9037B8.F5449711@alphase.com>d  F I know this is off topic, but since I've been a VMS developer for > 15D years, I think I'm entitled to this one time posting. Besides it was# tested on VMS, as well as M$/NT/98.   G You can download a free, or evaluation copy from my OpenVMS website at:e! http://alphase.com/aex/Order.html   % -------------------------------------s  H ALPHA SOFTWARE EXPRESS, LLC  LAUNCHES ITS FLAGSHIP JAVA SOFTWARE PRODUCTA FOR GENERAL DESIGN WORK AND MANAGEMENT OF CAD/CAM/CAE DOCUMENTS.    # SAN RAFAEL, CA -- Aug. 28, 2001 --  E Alpha Software Express, a supplier of OpenVMS and Java based software H today announced the formal launch of its flagship product for the designG and management of drawings primarily, but not exclusively, intended fore engineering markets. A  B CAD Object Manager - Version 1.0, provides an inexpensive means toH create and manage engineering and architectural designs. Its unique JavaH implementation allows it to run on virtually any platform - e.g. Windows> 95/98/NT/XP, Linux, Mac OS, OpenVMS, etc. It provides documentF management functions, like drawing check-out and check-in, as well as,8 user ownership features like privilege token assignment.  B Using this product, each object included in a design may be eitherG simple (a circle, image, etc.) or complex (a set of simple objects tiedkC together as a single unit). Complex objects can also have names andr other user defined attributes.  C With CAD Object Manager many users can take part in the design of aiE product without fear of others, inappropriately, altering their work.aD This is provided by assigning specific protections to each and every. object as well as to the document as a whole.   C Costs are variable, depending upon the features selected and futuremD licensing options. During this introductory period only, the versionE with the fewest features and options is available for free. A versionoG with all possible features and options costs  $500. It can be purchased4C and downloaded on line at http://alphase.com/aex/Announcement.html.n    > "This is the first, full CAD application available on the JavaG platform... I am very excited about this new area of opportunity", saidp- Don Sykes, the company's principal engineer. t  E Abdullah Ahmed-Falol, Supervisor of Public Safety Systems in Oakland, F CA, added, "I am glad ... you were able to bring CAD Object Manager toG completion. ... The Oakland Police CAD System, which you designed, is agH living proof that your design and software delivery is impeccable, and I@ am sure your new software release will be one of a kind. Bravo."    ! About Alpha Software Express, LLC   G Incorporated in 2000, Alpha Software Express was a natural outgrowth ofd- Alpha Software Engineering founded in 1992 tocD provide OpenVMS application services to a variety of customers, like? Digital Equipment, Borland International and the Oakland Police H Department. The system we designed and developed for the Oakland PD backC in 1992 continues to provide highly reliable 911 emergency dispatch & operations today, on a 24x7x365 basis.   About Don Sykesi  E As a Bay Area software engineer and application developer for over 25 B years, Don Sykes has provided significant software support to such. companies as: Bechtel Group, Bank of America, @ S&W Foods, Oracle, United Airlines and American President Lines.F He also developed and installed CAD software for such clients as Shell- Oil(UK), Hong Kong Electric and Dow Chemical.r     Visit: www.alphase.com.    CONTACT: Alpha Software Express 1380 Lincoln Ave 415-457-8532 ase@alphase.comn   ------------------------------    Date: 31 Aug 2001 21:52:36 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)e* Subject: Re: VMS'er Announces Java Product3 Message-ID: <nvD7xf6z5US$@eisner.encompasserve.org>   O In article <3B9037B8.F5449711@alphase.com>, Don Sykes <don@alphase.com> writes:T > H > I know this is off topic, but since I've been a VMS developer for > 15F > years, I think I'm entitled to this one time posting. Besides it was% > tested on VMS, as well as M$/NT/98.,  * That certainly proves it is not off-topic.  D People want software that runs on VMS -- there is no requirement forC an "exclusivity" oath that it won't run on other operating systems.    ------------------------------  # Date: Fri, 31 Aug 2001 18:01:25 GMTn= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)g= Subject: Re: Wailing at Eunuchs (was: Wailing and Moaning...),0 Message-ID: <00A015AD.E2B5E1AF@SendSpamHere.ORG>  ` In article <9moepd$2mjf$2@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes: {...snip...} >JH >And VMS people never make mistakes??  No VMS Admin or Operator has everL >accidently mounted the wrong tape with a write-ring installed??  On anotherH >note, I can restore my Unix system and all User files in about 3 hours.J >Last week the datacenter (running VMS on Alphas) lost a disk.  4 hours toL >replace the disk, 3 days to restore the file system.  I kid you not!!!  AndL >this on the latter half of the last week before school started, when people: >were trying to pay their tuition and get their schedules. >d  H How about a little apples-to-apples comparison Bill?  Were both devices G of the same capacity?  Were both archival systems the same type and didsF you use the same media on both?  If the un*x system had a DLT tape andF a small drive and the VMS machine had a large drive and a TK50, I'd beE tempted to conclude that your comment carries about as much weight as ! the electrons used to publish it.y     >No OS is perfect!!l  0 True.  Some are just less imperfect than others.     --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM             rJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes    ------------------------------    Date: 31 Aug 2001 22:03:57 -0500+ From: young_r@encompasserve.org (Rob Young)T= Subject: Re: Wailing at Eunuchs (was: Wailing and Moaning...)e3 Message-ID: <ueQyrzi52CDe@eisner.encompasserve.org>f  ` In article <9moepd$2mjf$2@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:     > |> > aB > |> > So don't use vi, use the dozens of other editors out there. > |> > e > |> . > |>  A > |> 	Yep.  The Unix answer.  Buy a product and tailor it to suit  > |> 	your needs.  n > G > Buy???   There are more than a dozen free editors available for Unix.?D > Surely one of them would prove acceptable??  Unless, of course you1 > believe, "If it ain't LSE it ain't an editor!!"M >    	See below.e  J > |>                   Backup?  We don't want to force that on you either. > 9 > And how exactly does VMS "force" one to do a backup??  h >   @ 	It comes with a backup command.  More than hacking tar and dump' 	to hope you have something to restore.,   > |> e > |> wP > |> >>         Unix hiearchial filesystem is *always* a big disaster waiting toW > |> >>         happen.  Two skilled Unix "persons" making a mistake in a shell script.hR > |> >>         Two high profile clients dead in the water for a day or two.  Why? > |> >> / > |> >>         # rm -r ${variable_goes_here}/*e > |> > a> > |> > Couldn't have been too "skilled" to make that mistake ! > |> > e > |> tJ > |> 	Absolutely skilled.  One of the people is a 15 year veteran, admin, G > |> 	system configurator... one of the brighter guys you would know.  I > ( > And VMS people never make mistakes??     	Would never claim that.  # > No VMS Admin or Operator has ever M > accidently mounted the wrong tape with a write-ring installed??  On another I > note, I can restore my Unix system and all User files in about 3 hours. K > Last week the datacenter (running VMS on Alphas) lost a disk.  4 hours toiM > replace the disk, 3 days to restore the file system.  I kid you not!!!  And M > this on the latter half of the last week before school started, when peopler; > were trying to pay their tuition and get their schedules.o >   B 	Perhaps you are budget constrained.  Meet folks like that all the> 	time.  After you calculate the costs of a single disk failing: 	and jumping through hoops, maybe you will make that RAID1F 	hardware or software (Volume Shadowed) to prevent that from happening= 	next time.  .edu is in your extension, surely you can do theu> 	latter at no cost (Volume Shadowing) other than a disk drive.  = 	By the way, at 20 GBytes per hour and 3 days to "restore ther& 	file system" how large was that disk?   > No OS is perfect!! >  > |> r > |> 	Trust me... bad design.P >  > Trust me, matter of opinion. >   ? 	No.  Transposition of a single character results in all disks c* 	being wiped clean.  Bad design, trust me.   > |>  N > |> > If indeed they were running AIX they should have been up in a couple ofL > |> > hours even if the drives weren't mirrored, get rid of above mentionedL > |> > "skilled unix persons", put in your previous nights bootable tape setO > |> > the machine to service mode, boot it and you are back up and running ...w2 > |> > no tape you say, well see my first comment. > |> > e > |> kL > |> 	Yep.  You just did the OS restore.  But with the hiearchial filesystemG > |> 	you also wiped out the db's.  12 years of databases that take the ? > |> 	better part of 2 days (maybe 3, can't recall) to restore.- > E > 2 to 3 days??  I can restore 20GB an hour. How big are these db's??- >   B 	That is a mighty fine backup system you have there.  We are usingE 	something along those lines and the cost is $$$.  You can't "afford"u3 	to shadow your critical disks?   What's with that?A  E > But then, we have heard all this drivel before.  Everything isn't a6F > nail and there are more tools than just a hammer.  The hammer makers8 > guild may not like it or believe it, but it is a fact. >   @ 	I'm telling you what is a fact.  The fact was that the backups C 	were to an attached 8mm tape drive and it took >2 days to sort out > 	the whole mess.  Yes, it should have taken less than 24 hours2 	wall clock time, but it didn't (logistics , etc.)   				RobP   ------------------------------  % Date: Fri, 31 Aug 2001 16:23:17 -0400p; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>nW Subject: Re: What are the exact steps in order to add a user account with VAX-VMS  v6.0 $ Message-ID: <3b8ff282$1@news.si.com>  
 >step one: >-K >$ if f$search("sys$manager:adduser.com) .nes. "" then @sys$manager:adduserg  	 Step two:m8 $ if f$search("sys$examples:adduser.com" ) .nes. "" then @sys$examples:adduser  --A Brian Tillman                   Internet: tillman_brian at si.comcA Smiths Aerospace                          tillman at swdev.si.coms= 3290 Patterson Ave. SE, MS      Addresses modified to preventu< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------    Date: 31 Aug 2001 13:59:36 -0700- From: afeldman@gfigroup.com (Alan E. Feldman)c0 Subject: Re: Why continue with OpenVMS / Compaq?= Message-ID: <af1e4ce6.0108311259.6b977728@posting.google.com>   q afeldman@gfigroup.com (Alan E. Feldman) wrote in message news:<af1e4ce6.0108310607.6859745@posting.google.com>...ec > JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3B8F1D2B.B73D79AA@videotron.ca>...n > > "Alan E. Feldman" wrote:L > > > Well, if you hadn't posted, you'd still be able to quit Compaq without! > > > starting a run on the bank.. > > Q > > How quickly people forget. The run on the bank started in the early 1990s, in5 > > a previous millenium.  > ; > I respectfully disagree. From Webster's online dictionary=% > (www.webster.com) under run (noun):= > A > f : persistent and heavy demands from depositors, creditors, ore > customers <a run on a bank>0 > G > I'd hardly call the 90's a "run on the bank". Yes, many organizations G > switched from VMS to other OSes, but it was not a panic and there was0D > no immediate concern of total bankruptcy. There were other reasonsG > that people switched. And many did not switch, of course. And no "run  > on the bank" last 10 years!D  4 Make that "And no 'run on the bank' lasts 10 years!")                                         ^a  " Disclaimer: JMHO, not gfigroup's.  Alan E. Feldmane afeldman@gfigroup.comn   ------------------------------  # Date: Fri, 31 Aug 2001 19:40:15 GMTV= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) < Subject: Will Mozilla ever run without crashing DECW server?0 Message-ID: <00A015BB.B163F706@SendSpamHere.ORG>  = I downloaded the 0.9.3 Mozilla, installed it, and started it.e  ( Poof.  DECWindows server still bugs out.  = Any chance of ever getting a newer working browser for VMS???e     --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM)            tJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes    ------------------------------  % Date: Fri, 31 Aug 2001 13:18:53 -0700i0 From: Mark Berryman <Mark.Berryman@Mvb.Saic.Com>@ Subject: Re: Will Mozilla ever run without crashing DECW server?, Message-ID: <3B8F8EBD.6D9EF51A@Mvb.Saic.Com>  $ Brian Schenkenberger, VAXman- wrote: > ? > I downloaded the 0.9.3 Mozilla, installed it, and started it.e > * > Poof.  DECWindows server still bugs out. > ? > Any chance of ever getting a newer working browser for VMS???d  G I'm still willing to help you debug why it does that.  I've got mozilladF running on at least 10 different systems and the DECwindows server has never crashed on any of them.,  
 Mark Berrymano Mark.Berryman@Mvb.Saic.Com   ------------------------------  % Date: Fri, 31 Aug 2001 16:42:44 -0400s4 From: John Malmberg <Malmberg@dskwld.zko.dec.compaq>@ Subject: Re: Will Mozilla ever run without crashing DECW server?4 Message-ID: <3B8FF6C4.2070403@dskwld.zko.dec.compaq>  # This is posted using 0.9.3 Mozilla.n  ( It seems to use a lot of Virtual Memory:  C I have 2 page files of 270300 blocks each.  I had to add the seconde1 to get MOZILLA to function with reasonable speed.y& This is with 128 M of physical memory.  : This is also with the images installed to reduce the quota9 requirements.  I had to bump up the sysgen parameters fors gblpages and glbsections.s  ! Currently I have in modparams.dato MIN_GBLPAGFIL=200000 MIN_GBLPAGES=350000e MIN_GBLSECTIONS=1000 MIN_NPAGEDYN=4400000  5 I also increased my user account bytlm to 100000, and  pgflquo to 180000.  7 This is on OpenVMS 7.3, DECW MOTIF 1.2-6, TCP-IP 5.1-15I No ECOs installed.   -JohnV malmberg@dslwld.zko.dec.compaq Personal Opinion Onlyo    $ Brian Schenkenberger, VAXman- wrote:? > I downloaded the 0.9.3 Mozilla, installed it, and started it.c > * > Poof.  DECWindows server still bugs out. > ? > Any chance of ever getting a newer working browser for VMS???h   ------------------------------  # Date: Fri, 31 Aug 2001 21:06:39 GMTg2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)@ Subject: Re: Will Mozilla ever run without crashing DECW server?3 Message-ID: <z%Sj7.1077$bB1.45935@news.cpqcorp.net>X  _ In article <3B8F8EBD.6D9EF51A@Mvb.Saic.Com>, Mark Berryman <Mark.Berryman@Mvb.Saic.Com> writes:o% :Brian Schenkenberger, VAXman- wrote:  :> a@ :> I downloaded the 0.9.3 Mozilla, installed it, and started it. :>  + :> Poof.  DECWindows server still bugs out.  :> h@ :> Any chance of ever getting a newer working browser for VMS??? :sH :I'm still willing to help you debug why it does that.  I've got mozillaG :running on at least 10 different systems and the DECwindows server hast :never crashed on any of them.    J   I too have not seen the Mozilla browser stackdump DECwindows -- while I L   have occasionally seen Netscape Navigator take out OpenVMS, the incidence I   of that once-a-month bucheck has been greatly reduced (or eliminated?)  J   after I have applied various ECOs -- I haven't seen one of these crashesI   in months.  (The bugcheck was a machine check, and apparently involved     the graphics device drivers.)   2   OpenVMS version, platform, graphics widget, etc?  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: Fri, 31 Aug 2001 21:41:10 GMTo= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)p@ Subject: Re: Will Mozilla ever run without crashing DECW server?0 Message-ID: <00A015CC.96181474@SendSpamHere.ORG>  h In article <z%Sj7.1077$bB1.45935@news.cpqcorp.net>, hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes:` >In article <3B8F8EBD.6D9EF51A@Mvb.Saic.Com>, Mark Berryman <Mark.Berryman@Mvb.Saic.Com> writes:& >:Brian Schenkenberger, VAXman- wrote: >:> A >:> I downloaded the 0.9.3 Mozilla, installed it, and started it.a >:> , >:> Poof.  DECWindows server still bugs out. >:> A >:> Any chance of ever getting a newer working browser for VMS???  >:I >:I'm still willing to help you debug why it does that.  I've got mozillaaH >:running on at least 10 different systems and the DECwindows server has >:never crashed on any of them.p >M >eK >  I too have not seen the Mozilla browser stackdump DECwindows -- while I eM >  have occasionally seen Netscape Navigator take out OpenVMS, the incidence  J >  of that once-a-month bucheck has been greatly reduced (or eliminated?) K >  after I have applied various ECOs -- I haven't seen one of these crashes J >  in months.  (The bugcheck was a machine check, and apparently involved   >  the graphics device drivers.) >e3 >  OpenVMS version, platform, graphics widget, etc?c    h  J OpenVMS V7.2-1, AlphaStation 200 4/233, ZLXp-E3, 384MB RAM, lots and lots L of SCSI disk space, and entire RZ29B devoted to pagefile, DECWindows V1.2-5,I TCP/IP 5.0A, and SYSGEN and SYSTEM processes quotas at rediculous levels.eJ We've gone through this exercise with every version of Mozilla and never aI solution.   I also ran Mozilla on another machine with the display set toeJ the AS200 4/233 described above and the DECW server crashes.  Resources... I don't think so.d   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMD            aJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbesl   ------------------------------  % Date: Sat, 01 Sep 2001 09:58:56 +0800,- From: David B Sneddon <dbsneddon@bigpond.com>c@ Subject: Re: Will Mozilla ever run without crashing DECW server?A Message-ID: <5.1.0.14.0.20010901095717.009fa0b0@mail.bigpond.com>l  9 At 1/09/01 03:40 AM, Brian Schenkenberger, VAXman- wrote: > >I downloaded the 0.9.3 Mozilla, installed it, and started it. >L) >Poof.  DECWindows server still bugs out.E >e> >Any chance of ever getting a newer working browser for VMS???   What configuration do you have?l; I have it running quite happily on VMS.  The only problem Ii9 encounter is that it seems to hang, but ONLY after I havet! been visiting Compaq web pages...v     >--r+ >VAXman- OpenVMS APE certification number: o& >AAA-0001     VAXman(at)TMESIS(dot)COM > K >   "And of course, I'm a genius, so people are naturally drawn to my fiery K >   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbess     Regards, Dave.  -- aI David B Sneddon (dbs)  OpenVMS Systems Programmer   dbsneddon@bigpond.comdI Sneddo's quick guide ...          http://www.users.bigpond.com/dbsneddon/ I DBS freeware at ...   http://www.users.bigpond.com/dbsneddon/software.htmeI "Life is what happens to you while you're busy making other plans" Lennono   ------------------------------   End of INFO-VAX 2001.485 ************************