1 INFO-VAX	Sat, 01 Sep 2001	Volume 2001 : Issue 486       Contents: Re: A very sad moment.!  Re: alpha - ia64) Re: Conference: CETS-2001 Detailed Update  Re: EV7 will never ship? Re: EV7 will never ship? Re: EV7 will never ship?7 Re: Good news! MicroVAX II - SAVPSL, SAVPC, and SAVISP.   Help with java server OpenVMS...% How to install Adobe Acrobat Viewer ?  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 2 RE: Intel announces IA-64 "HyperThreading" in 20023 Re: Serial Console? (was: Re: EV7 will never ship?) * Re: still can't get my UCX licensed??????? Re: Tunneling DECnet over IP Re: Tunneling DECnet over IP Re: Tunneling DECnet over IP  F ----------------------------------------------------------------------  # Date: Sat, 01 Sep 2001 12:57:59 GMT > From: andekl_no@saaf_spam.se (=?ISO-8859-1?Q?Anders_Ekl=F6f?=)  Subject: Re: A very sad moment.!: Message-ID: <1ez18jk.83dgyffuif9qN%andekl_no@saaf_spam.se>  ( Howard S Shubs <howard@shubs.net> wrote:  E > > I had no response to this - I just felt too old, and I'm only 36!  >  > Kids these days...  > Yeah - just a little setback, and they give up... Must be MTV.   ------------------------------  # Date: Sat, 01 Sep 2001 16:02:34 GMT   From: "eddie" <NullVoid@att.net> Subject: Re: alpha - ia64 F Message-ID: <uE7k7.2676$Uf1.207050@bgtnsc06-news.ops.worldnet.att.net>  9 "Peter Watkinson" <peterw@u.genie.co.uk> wrote in message 1 news:3b8c1543.16021359@news.cable.ntlworld.com...  >  >  > Hi,  > G > One thing that confuses me about the intel swallowup of Alpha is that C > with IA64 being EPIC and not RISC and AMD bringing out the Hammer   , The Hammers will not be released until 2H02.  ; Itanium will be released in 2H01, a full year ahead of AMD.   F > range of cpu's Intel will still be in a similar situation to that itH > is in now having to cut chip prices heavily to compete with AMD. I putF > this down to the fact that IA64 was designed when Alpha was still onE > NT and thus Intel needed to go the EPIC route to compete with FX32. G > Now that AlphaNT is no longer Intel is stuck with a cpu that needs to F > be able to run 32bit code when if Alpha had never existed they couldG > have produced a RISC cpu. And they are still stuck in a dogfight with H > AMD when with their tyins with M$ they could have produced a processor > without any legacy hiccups.  > B > Looking into the future maybe one route for Intel a) could be to > re-release Alpha (dream on)  > H > or b) could be to produce a brand new RISC cpu maybe 128bits if such a: > thing is possible to leave the competition (AMD) behind. > > who knows...............
 > >  regards,  >  Peter Watkinson   ------------------------------  # Date: Sat, 01 Sep 2001 07:07:26 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>2 Subject: Re: Conference: CETS-2001 Detailed Update; Message-ID: <OO%j7.1341$zj5.535612@typhoon.ne.mediaone.net>   1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message 1 news:P1_j7.642$mC2.329935@typhoon2.gnilink.net...  > K > "Jan Vorbrueggen" <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote  inL > message news:y4k7zkz0n1.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de..., > > "Jeff Killeen" <Jeff@IDM-IO.com> writes:I > > > This is very indicative of the pure speculation is going on here...  > > H > > Blech. Do you think an iteration of an ASIC 2-4 years back in the US cost > ten I > > times more than a turn of a state-of-the-art custom design in Germany  two  > > years back?  > L > No - but I do think the project leader for Wildfire is a far more reliableJ > cost of  Wildfire ASIC's costs than the cowboys with a keyboard in these+ > newsgroups. AGREED. Fenwick is no cowboy.  > J > The information was provided at a Encompass User Group meeting last fall and G > there was no reason for him to be placing any spin on it - however by J > reputation I seriously doubt he would put spin on anything at anytime... >  >    ------------------------------  # Date: Sat, 01 Sep 2001 08:18:37 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>! Subject: Re: EV7 will never ship? ; Message-ID: <xR0k7.1372$zj5.570442@typhoon.ne.mediaone.net>   < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3B904222.C49B1E3F@fsi.net...  > "Terry C. Shannon" wrote:  > > D > > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message1 > > news:Scuj7.1003$bB1.45307@news.cpqcorp.net... C > > > JF Mezei wrote in message <3B8D263B.CEA96993@videotron.ca>...  > > > >Alan Greig wrote:C > > > >> have Galaxy support features according to current customer  > > presentations. > > > The slidesC > > > >> show one system running Windows-64, VMS, Linux, and Tru64.   , Yep. Fire, Ice, and Wind are the code names.   > > > > H > > > >I was under the impression that currently, Galaxy only *supports* > > multiple > > > >instances of VMS. > > J > > What folks fail to understand is that comp.os.vms is a Romper Room for > > whiners! > J > When my wife makes comments like that, we both know it's time for her to > take her water pill...  J Cool. I can get you a great deal on Lasix. Not that it'll have much impact7 on the whining and the lack of credulity of this forum.  >  > -- > David J. Dachtera  > dba DJE Systems  > http://www.djesys.com/ > * > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/    ------------------------------   Date: 1 Sep 2001 14:02:11 GMT & From: peter@abbnm.com (Peter da Silva)! Subject: Re: EV7 will never ship? % Message-ID: <9mqpp3$jls@web.nmti.com>   H In article <y4bskwd3zi.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>,I Jan Vorbrueggen  <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote: 1 > JF Mezei <jfmezei.spamnot@videotron.ca> writes: O > > However, it is also possible that Microsoft will simply pay those insurance N > > companies under the table to stop such a practice since going public wouldP > > only attract the attention to the fact that NT isn't high enough quality yetQ > > and that customers should not install Nt in true enterprise applications even + > > though MS and Compaq would want you to.   B > They can't do that either - the FTC would strangle both of them.  M Microsoft doesn't seem to pay much attention to what the US government wants, 7 if the past year or so in the courts is any indication.    --  +  `-_-'   In hoc signo hack, Peter da Silva. E   'U`    "A well-rounded geek should be able to geek about anything." L                                                        -- nicolai@esperi.org          Disclaimer: WWFD?   ------------------------------   Date: 1 Sep 2001 12:17:23 -0500 + From: young_r@encompasserve.org (Rob Young) ! Subject: Re: EV7 will never ship? 3 Message-ID: <mB4fxsJ7qs94@eisner.encompasserve.org>   r In article <xR0k7.1372$zj5.570442@typhoon.ne.mediaone.net>, "Terry C. Shannon" <terryshannon@mediaone.net> writes: > > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message# > news:3B904222.C49B1E3F@fsi.net...    >>K >> When my wife makes comments like that, we both know it's time for her to  >> take her water pill...  > L > Cool. I can get you a great deal on Lasix. Not that it'll have much impact9 > on the whining and the lack of credulity of this forum.     A 	That was mean. . . it took me about 30 seconds to start laughing 8 	after reading that as I hearken back to days long gone.   				Rob    ------------------------------  % Date: Sat, 01 Sep 2001 17:06:47 +0100 + From: "antonio.carlini" <arcarlini@iee.org> @ Subject: Re: Good news! MicroVAX II - SAVPSL, SAVPC, and SAVISP.' Message-ID: <3B910797.EEB9ACE2@iee.org>    sword7@speakeasy.org wrote: G > What is 78032 chip for?  Of course, I might be interested in a copy.. 7 > Yes, I am still looking for the KA630 user guide too.   " The 78032 is the chip used in the ) MicroVAX II system (and the MicroVAX 2000 ' and possibly a few others). It probably # has a DCxxx number too, but I don't  recall what it might be.  & If you get stuck with the MicroVAX II,% you could pick up the tech manual for  the MicroVAX 2000 from1  http://208.190.133.201/decimages/moremanuals.htm  and have a go with that - there  might be fewer unknowns.  ' The 78032 user guide is badly bound and ' falling apart, so I'll probably scan it  quite soon anyway.    H > Does anyone have information about restart code?  Only I know that 0x3G > is power-up state or so.  I had seen 0x5, 0x3, and 0x2 in diassembled  > VMB code.    The documented codes are:    02 - HALT (the signal) asserted ' 03 - initial power on or RESET asserted * 04 - int. stack not valid during exception1 05 - machine check during machine check or kernal $       stack invalid during exception* 06 - HALT instruction while in kernel mode 07 - SCB vector <1:0> = 11 08 - SCB vector <1:0> = 10 09 - not listed ! * 0A - CHMx execute while on interrupt stack$ 10 - ACV or TNV during machine check7 11 - ACV or TNV during kernel stack not valid exception    Antonio    --     --------------- - Antonio Carlini             arcarlini@iee.org    ------------------------------  % Date: Sat, 01 Sep 2001 07:16:15 -0400   From: Kuff@Tessco.Com (Hal Kuff)) Subject: Help with java server OpenVMS... O Message-ID: <D94B7AA731337DB3.46D48A11D2AC8ED7.9AADD2232CFB54A2@lp.airnews.net>   E     We would like a remote java application to instantiate an OpenVMS G process and run an image passing up to 4096 bytes to the image ... that H program will open some files and access a database, then send back up to
 4096 bytes...   K     There's BEA, Attunity, Connx, something called Concerto from Xology.... > Anyone doing this with these tools or others in the field now?     ---Hal   ------------------------------  % Date: Sat, 01 Sep 2001 09:16:46 +0200  From: Dirk Munk <munk@home.nl>. Subject: How to install Adobe Acrobat Viewer ?$ Message-ID: <3B908B5E.50209@home.nl>  G I am trying to install the Acrobat Viewer following the instructions on   B http://www.openvms.compaq.com/openvms/products/ips/pdf_viewer.html  I However this page is a bit out of date, because it references to a older   version of Java.  F I tried the obvious replacement of files & directories in the syntax, I but no luck. There is no such file as jdk118_classes.zip or its java$130  " equivalent. And "install" gets me:  B Exception in thread "main" java.lang.NoClassDefFoundError: install   What to do now ?   Regards,   Dirk   ------------------------------  # Date: Sat, 01 Sep 2001 06:14:21 GMT 3 From: Carl Nelson <carl.nelson@mcmail.maricopa.edu>  Subject: Re: I hate Compaq3 Message-ID: <3B907CBF.18155D1A@mcmail.maricopa.edu>    Brannon Batson wrote:   c > JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3B8FDAE5.99BB8D7F@videotron.ca>...  > > Nick Maclaren wrote:A > > > I hope that Compaq DOES pull off the EV7, as even temporary D > > > competition is always good, and think that it is probably moreD > > > likely than not.  But it is by no means a foregone conclusion. > > N > > Perhaps the real goal of the EV7 folks is to give them a sand box in whichP > > they can play in (Alpha) and test some stuff and once they are done with it,9 > > they can then transfer it "debugged/tested" to Intel.  > > O > > Are there any technologies in EV7 that Intel would like to implement in its Q > > own chips eventually ? From what I understand, EV8 was still mostly on paper, H > > whereas EV7 is closer to being a real thing, and this means that theK > > technologies in EV7 would also be more developped/debugged than the EV8 8 > > concepts that are not yet implemented anywhere else. > * > EV8 is much more than a paper processor. > 	 > Brannon  > not speaking for Intel  `   From what I have (publicly) seen, I believe that the EV8 processor design had progressed to atb least the level of register transfer definition. If I recall correctly, this is the first level at_ which actual simulations of actual code, even OS and application execution, can occur. It isn't c fast, by any definition of the word, but it certainly is doable, and can be used to iron out issues Y that would arise from a new technology such as SMT. Even to the issue of cache coherency, T synchronizing techniques, and dealing with context switching and interrupt handling.  F   I believe this may be what "more than a paper processor" might mean.  _   This is the best level to discover errors or basic flaws, and it is also possible to save the Y complete state of the simulation at a certain point, and try to 'force' certain errors to ` stress-test the design. True, it's not silicon, but it's also not as expensive. The next step is4 more expensive and more difficult, to say the least.  
 --Carl Nelson    ------------------------------  % Date: Sat, 01 Sep 2001 19:23:00 +0010 % From: paddy.o'brien@zzz.tg.nsw.gov.au  Subject: Re: I hate Compaq5 Message-ID: <01K7U0ZB9BOY004LJS@tgmail.tg.nsw.gov.au>    Jan.  ( >paddy.o'brien@zzz.tg.nsw.gov.au writes: > 1 >> Read comp.risks 17/08/2001 Risks Digest 21.61.  > K >Of course I have. I thought comp.risks were required reading for every one  >in the field!?   M *We* might consider it so, but my experience shows me that not everyone else   does :-)  G Experience also shows me that not all VMS managers/administrators read  2 c.o.v, nor Fortranners read c.l.f or the F90 list.   Regards, Paddy   ------------------------------   Date: 1 Sep 2001 10:34:45 GMT ( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: I hate Compaq0 Message-ID: <9mqdk5$8o6$1@pegasus.csx.cam.ac.uk>  3 In article <kThTdZOpCem9@eisner.encompasserve.org>, . Larry Kilgallen <Kilgallen@SpamCop.net> wrote:l >In article <TXLj7.1042$bB1.45773@news.cpqcorp.net>, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:I >> Nick Maclaren wrote in message <9mnv56$8lv$1@pegasus.csx.cam.ac.uk>...  >>  B >>>It isn't just Compaq's record, but that of every single companyC >>>that has ever got into serious levels of SMP and non-predictable A >>>instruction execution - getting the interrupt handling, memory A >>>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 unrelated : >>>change may have immense and unpredictable consequences. >>  L >> The good news is that IMHO the 3 best people in the world at what they doG >> are in charge of the EV7, the system platform, and the IO subsystem.  > 2 >Arnold Palmer, Jack Nicklaus, and Tiger Woods ???  	 Quite :-)   D One of the disasters of modern systems (and, again, not just Compaq)A is the fact that virtually all are designed in compartments, with C each compartment placing often unreasonable restrictions on calling C layers, and yet assuming that the caller will fix up the situations A that are too hard, too inefficient or too much trouble to support A in the current compartment.  This ends up with the intructions to  application developers:   D     Don't make mistakes, nor misunderstand the implementor's intent.7     Don't raise hardware exceptions or receive signals. /     Don't debug non-working or optimised codes. =     Don't expect anything to work if you do any of the above.   B I haven't studied exactly where things go wrong in Tru64 Unix, butC it seems likely that most of the misdesigns are in the compiler and A language run-time system interface.  This SHOULDN'T matter to the C EV68 to EV7 migration, as the differences are primarily relevant to ( the hardware/operating system interface.  D But it is horrific how many problems at that level (on most systems)B do leak through to the compiler and language run-time system layerB and, most commonly, prevent debuggers from working reliably.  UnixC is MUCH better than Microsoft, as usual, but even Linux (one of the C best) is not a patch on MVS.  My sources were that VMS on a VAX was B pretty comparable to MVS, but early VMS on Alphas was poor; I then
 lost contact.   B So the issue here is NOT whether the hardware (up to and includingC the whole boxes) will work, but whether the system as a whole will. ? It is quite common for a 'minor' change or restriction to be so C serious that only a hardware redesign will get the operating system C or other layers working again.  One hopes that this mistake has not0B been made, but it is important to note that the success of the EV7+ is dependent on far more than the hardware.   A Incidentally, this is also why I believe that SMT-EPIC will never ? work.  If a certain Redmond company cannot get its damn code toVB work reliably even on single-threaded, in-order architectures, how? on earth will it handle anything that fiendish?  We are alreadye= seeing systems that say "If you need to handle exceptions and = asynchronous signals, then compile without optimisation", butp< EPIC depends critically on all codes being highly optimised.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679-   ------------------------------   Date: 1 Sep 2001 08:08:44 -0500f- From: Kilgallen@SpamCop.net (Larry Kilgallen)j Subject: Re: I hate Compaq3 Message-ID: <PRz4tgIDoOfW@eisner.encompasserve.org>p  [ In article <9mqdk5$8o6$1@pegasus.csx.cam.ac.uk>, nmm1@cus.cam.ac.uk (Nick Maclaren) writes:l  F > But it is horrific how many problems at that level (on most systems)D > do leak through to the compiler and language run-time system layerD > and, most commonly, prevent debuggers from working reliably.  UnixE > is MUCH better than Microsoft, as usual, but even Linux (one of the.E > best) is not a patch on MVS.  My sources were that VMS on a VAX was@D > pretty comparable to MVS, but early VMS on Alphas was poor; I then > lost contact.   B Absolutely Alpha VMS V1.0 and V1.5 were aimed at "early adopters",< and it was not until the next version that they switched the: numbering to match VAX (V6.1 at the time) to announce they= had reached "feature parity" with VAX.  And certainly featurea+ parity is different from robustness parity.l  D > So the issue here is NOT whether the hardware (up to and includingE > the whole boxes) will work, but whether the system as a whole will. A > It is quite common for a 'minor' change or restriction to be so E > serious that only a hardware redesign will get the operating systemiE > or other layers working again.  One hopes that this mistake has not3D > been made, but it is important to note that the success of the EV7- > is dependent on far more than the hardware.g  A Once they were on Alpha, however, successive hardware generationsd@ didn't seem to hurt VMS that much.  There was a case of bad code= generation uncovered by EV6, but the GEM compiler backend hade@ been corrected sometime earlier.  The problem was that even some< of their internal layered product groups were building their products with old compilers !   C > Incidentally, this is also why I believe that SMT-EPIC will never-A > work.  If a certain Redmond company cannot get its damn code torD > work reliably even on single-threaded, in-order architectures, howA > on earth will it handle anything that fiendish?  We are already2? > seeing systems that say "If you need to handle exceptions ando? > asynchronous signals, then compile without optimisation", but > > EPIC depends critically on all codes being highly optimised.    @ I just don't infer "SMT-EPIC will never work" from the base that= "Microsoft has trouble making things work".  Others have less.; trouble.  Perhaps because they waste less time implementingl virus-enabling technology.   ------------------------------   Date: 1 Sep 2001 13:55:22 GMTk( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: I hate Compaq0 Message-ID: <9mqpca$hlj$1@pegasus.csx.cam.ac.uk>  3 In article <PRz4tgIDoOfW@eisner.encompasserve.org>,W. Larry Kilgallen <Kilgallen@SpamCop.net> wrote: > D >> Incidentally, this is also why I believe that SMT-EPIC will neverB >> work.  If a certain Redmond company cannot get its damn code toE >> work reliably even on single-threaded, in-order architectures, how B >> on earth will it handle anything that fiendish?  We are already@ >> seeing systems that say "If you need to handle exceptions and@ >> asynchronous signals, then compile without optimisation", but? >> EPIC depends critically on all codes being highly optimised.u >cA >I just don't infer "SMT-EPIC will never work" from the base thatp> >"Microsoft has trouble making things work".  Others have less< >trouble.  Perhaps because they waste less time implementing >virus-enabling technology.   B I didn't mean to imply that was an absolute consequence, though it? is probably a commercial one.  But unfortunately, other vendorsM> are merely better enough to make the quality of their software ghastly :-(   : I do not know of a single Unix vendor that provides either@ reliable and functional signal and (hardware) exception handling= (clearly necessary for truly robust programs), nor a debugger.= that will handle genuine problems.  And that is simply in thew? context of a single-threaded application - the SMP situation is  much, much worse.i  > Of course, when I gave up on Microsoft, I was unable to find a@ language system that would handle such things AT ALL, but I know/ that the functionality has improved since then.     @ I have reason to believe that the number of people still working@ in the IT industry who have ever ATTEMPTED to provide robust andA application-controllable functional signal and exception handling @ is now down to dozens (at most).  And all but perhaps one or two" are in their 50s.  Yes, really :-(  B And, while the debugger situation is a little better, I don't knowA of ANY modern system where it is possible to debug stack trashing ? in an application signal handler, to take one relatively simplemA (sic) example.  And I can assure you that the problems introducedr; by multi-threaded, out-of-order, predicated and dynamicallyt8 compiled ISAs (i.e. EPIC+EV8) are far nastier than that.  B As I have posted before, I have proof positive that the insanities? of the C and POSIX standards (which are better than Microsoft'sl@ conventions) cause occasional, unpredictable application failureA on a couple of Unix systems, and very good evidence that the same ? is true for virtually every one I have used in the past decade.pA And reason to believe that the situation is worse for Windows XXX  and present in VMS.t  . This is even BEFORE I get onto plain bugs ....       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 334679g   ------------------------------  # Date: Sat, 01 Sep 2001 14:02:54 GMT  From: "Bill" <billmuy@home.com>o Subject: Re: I hate Compaq? Message-ID: <iU5k7.25767$MK5.16085360@news1.sttln1.wa.home.com>0  5 "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in messageY* news:9mqdk5$8o6$1@pegasus.csx.cam.ac.uk...5 > In article <kThTdZOpCem9@eisner.encompasserve.org>,  >aC > Incidentally, this is also why I believe that SMT-EPIC will nevernA > work.  If a certain Redmond company cannot get its damn code to D > work reliably even on single-threaded, in-order architectures, howA > on earth will it handle anything that fiendish?  We are alreadyn? > seeing systems that say "If you need to handle exceptions and ? > asynchronous signals, then compile without optimisation", buta> > EPIC depends critically on all codes being highly optimised. >  >a  5 M$ has had multi-threaded apps for quite a while now.h   Or am I mssing something?I     Bill   ------------------------------   Date: 1 Sep 2001 14:19:31 GMT-( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: I hate Compaq0 Message-ID: <9mqqpj$iin$1@pegasus.csx.cam.ac.uk>  ? In article <iU5k7.25767$MK5.16085360@news1.sttln1.wa.home.com>,i% Bill <billmuy@home.com_REMOVE> wrote: 6 >"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message+ >news:9mqdk5$8o6$1@pegasus.csx.cam.ac.uk... 6 >> In article <kThTdZOpCem9@eisner.encompasserve.org>, >>D >> Incidentally, this is also why I believe that SMT-EPIC will neverB >> work.  If a certain Redmond company cannot get its damn code toE >> work reliably even on single-threaded, in-order architectures, howlB >> on earth will it handle anything that fiendish?  We are already@ >> seeing systems that say "If you need to handle exceptions and@ >> asynchronous signals, then compile without optimisation", but? >> EPIC depends critically on all codes being highly optimised.a >a6 >M$ has had multi-threaded apps for quite a while now. >  >Or am I mssing something?  ' I am afraid that you are.  Quite a lot.a  A The vast majority of modern 'multi-threading' codes use it mainly < to avoid blocking and to isolate certain exceptional states,? though some use it for small-scale parallel execution.  But, inc; all cases, the multi-threading is explicit, used for fairlyi; well-separated blocks of code, and thread traansactions aree relatively rare.  = Switching on SMT for a single-threaded program is an entirelyC> different matter, and has none of the same properties.  Let us> assume that it is handled entirely transparently as far as the< compiled code goes.  But that does NOT address the interrupt problem.  ; RISC and EPIC rely on a lot of exceptional (not necessarily @ erroneous) situations being sorted out by software, but few have= used the well-proven technique of a special type of interrupt7> (as on Titan, in the 1960s), which localises the problem.  You> then have code that will sometimes be executed by hardware and sometimes by software.  @ Now, experience is that this is an EVIL thing to get right, evenB when the amount of fixing up is minimal.  But the interface forcedA by EV8+EPIC is in no sense minimal, and the software will have toCA handle multiple threads, any or all of which were interupted parte> way through an ISA instruction.  And then fix up the situation4 100% compatibly with the hardware, and then restart.     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 334679a   ------------------------------  $ Date: Sat, 1 Sep 2001 07:03:43 -0700# From: "Tom Linden" <tom@kednos.com>a; Subject: RE: Intel announces IA-64 "HyperThreading" in 2002 9 Message-ID: <CIEJLCMNHNNDLLOOGNJIIEJGDDAA.tom@kednos.com>i  6 On the cpu (as opposed to the ppu's ) you could obtain4 minor cycle speed provide the instructions fitted in2 the stack window.  So you could write tight loops,< overlap Float with integer arithmetic.  The ppu's had a very9 simple 18bit instrucution set and were largely limited tol) I/O, simple data conversions and the like    > -----Original Message-----5 > From: Duane Sand [mailto:duane.sand@mindspring.com]n' > Sent: Friday, August 31, 2001 6:15 PM. > To: Info-VAX@Mvb.Saic.Comn= > Subject: Re: Intel announces IA-64 "HyperThreading" in 2002c >  >  > Tom Linden wroteG > > Just to put things in an historical perspective the CDC 6000 seriessB > > designed by Seymour Cray around 1965 also had this capability. > > > The CDC 6000 series' Peripheral Processors unit supported 10B > independent threads at once, but in a very different statically-1 > scheduled way than the dynamic OO scheduling ona2 > Alpha EV8 SMT or Pentium 4 "hyperthreading" SMT.9 > All 10 sets of registers were organized into a circular @ > shift register chain called a barrel.  Each thread got exactly4 > 1/10th of available "minor cycles", evenly spaced.4 > The point of this was to do something useful while3 > a given thread waited on a main memory fetch that 7 > took 10 times as long as cpu cycles.  (These machinesg6 > had no cache.)  When there weren't 10 useful threads5 > to work on, barrel slots and alu cycles went wasted 1 > rather than being reallocated to make remainingl > threads run faster.( > 1 > This same simple timeslicing method was used on 4 > Xerox PARC's second-generation smalltalk machines. > I believe CDC was first. >  >  >  >  >    ------------------------------   Date: 1 Sep 2001 13:58:37 GMTS& From: peter@abbnm.com (Peter da Silva)< Subject: Re: Serial Console? (was: Re: EV7 will never ship?)% Message-ID: <9mqpid$jfj@web.nmti.com>t  3 In article <sxvj7.1013$bB1.45502@news.cpqcorp.net>,s3 Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> wrote:nP > In article <9mleul$osu@web.nmti.com>, peter@abbnm.com (Peter da Silva) writes:P > :The only thing I really miss from the Alphaservers is the nice serial commandQ > :line console. If you could produce a DL360 with a serial console we would snaph > :it up like *that*.h  K >   OpenVMS expects to have and use a serial console when the port becomes tM >   available on IPF (IA-64) -- the IPF EFI (console) specifications provide t
 >   for this.e  $ So do many operating systems on DLs.  M >   With IA-32, there is an existing remote management API widget available, 0G >   though this is apparently a remote GUI-based interface, not serial.I  H The very idea of a Windows-only GUI-based remote management system beingI in any way a replacement for a command-line based serial console is quite2 unreal.   1 	1. It won't work with serious operating systems..  ? 	2. It won't give you access early enough in the boot sequence.*  % 	3. It's not scriptable or batchable.s  7 	4. It requires a high bandwidth communication channel.s  K A DL running UNIX or a RTOS at a lights-out facility with a modem link overeJ third-world phone lines isn't going to benefit from your "GUI-based remote management API".  C Digital used to be a powerhouse in the realtime industry, you know.c   -- I+  `-_-'   In hoc signo hack, Peter da Silva.uE   'U`    "A well-rounded geek should be able to geek about anything." L                                                        -- nicolai@esperi.org          Disclaimer: WWFD?   ------------------------------  % Date: Sat, 01 Sep 2001 09:45:25 -0500e1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 3 Subject: Re: still can't get my UCX licensed??????? ' Message-ID: <3B90F485.8DAC8D16@fsi.net>t   Larry Kilgallen wrote: > ] > In article <3B9041CC.F3F22C1D@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:g > > Larry Kilgallen wrote: > >>_ > >> In article <3B8F0403.CE7F3EB@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:h > >>I > >> > You're quite right, of course. The TCP/IP topic comes up so often,mN > >> > though, and not having it be part of the system (i.e., a SIP instead ofO > >> > a normal part of the basic installation) seems to be the confusing part. 2 > >> > At least that much seems worthy of mention. > >>L > >> That would certainly be an attack on the notion of third party vendors. > >eK > > Can't say as I've lately seen a third-party IP stack for Linux or UN*X.  > >mH > > In the old days (W/3.x) there was TCP/IP for Windows (MS), TCP/IP-32L > > (MS), Chameleon, Trumpet - even a Multinet for Windows back in TGV days!
 > > Now, ...?t > >rJ > > I like having the choice (prefer Multinet myself), but this needs some9 > > explanation for those to whom the concept is foreign.e > >s" > > That's all I'm saying, really. > G > Yes, Process Software just happens to be a premier example of a thirdr3 > party concentrating on VMS -- I wish we had more.t > B > Perhaps the real solution to the original problem is to simplifyD > the hobbyist license process.  I am skeptical that there is reallyL > anyone who wants a hobbyist VMS license but _no_ layered product licenses.  G I'm sure that's just a logistical constraint imposed by the OVMS powers  that be.  D Still, since the l.p. license section requests nothing that the o.s.C license section doesn't, maybe it would be, as you seem to suggest,lD better to issue them both at once - though perhaps still in separate; e-mails, just to make life a touch easier for the hobbyist.r  D I'd concur. Maybe if John or Pat or Dave are "listening", they might. suggest that to their contacts within the "Q".   --   David J. Dachterat dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/h   ------------------------------  % Date: Sat, 01 Sep 2001 09:55:45 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)% Subject: Re: Tunneling DECnet over IPrL Message-ID: <rdeininger-0109010955460001@user-2iveba2.dialup.mindspring.com>  H In article <TWVj7.2769$_I.1446637@e3500-chi1.usenetserver.com>, "Zane H.* Healy" <healyzh@shell1.aracnet.com> wrote:  5 > Robert Deininger <rdeininger@mindspring.com> wrote:tK > > Hooray!  The world hasn't been as fun since HEPnet started to rot away.w > M > > Is anyone managing the HECnet address space?  Since parts of HEPnet stillrN > > exist (but are mostly not connected anymore) it would perhaps be useful toL > > avoid collisions with existing HEPnet nodes where possible.  Some HEPnet& > > nodes might want to join HECnet... > K > Johnny Billquist is currently managing the address space, I don't know if / > he's ever heard of HEPnet (I know I haven't).,  H Sorry.  HEPnet was/is High Energy Physics-net.  The HEP community seemedJ to be the driving force in connecting the universities and labs in AmericaG and Europe via DECnet, but it wasn't limited to physics.  Basically, it-I was all the VMS machines at "public" institutions.  When VMS was dominantrI in physics, and before WAN routing of DECnet became unpopular, HEPnet wasrI running out of address space.  I heard claims (possibly bogus) that theirmD need to go beyond 63 areas was a major reason for DECnet-V.  I think; HEPnet was the biggest publicly-visible instance of DECnet.g  K > I don't doubt that my description stinks!  From what little I was able tovN > find in the manuals, my understanding of it is pretty limited.  I did find aH > slightly better description earlier today, but it's still not detailed > enough for my tastes.A  : A good manual to read is probably the one most of us skip:    "DECnet-Plus Planning Guide" ?    http://www.openvms.compaq.com:8000/73final/6495/6495pro.HTMLs  
 And of courset:    "DECnet-Plus for OpenVMS Introduction and User's Guide" andhA    "DECnet-Plus for OpenVMS Installation and Basic Configuration"t  L > Based on this, I take it that you can do DECnet-over-tcpip between systemsN > running TCPIP and Multinet?  This sounds interesting.  On the downside rightN > now they seem to only be tunning serial DECnet links over the Internet (they > have their reasons).  3 Yes, TCPIP (or UCX) connects to multinet just fine.a  J With DECnet-plus I don't think something like VTUN is needed.  It might beJ fine for DECnet-IV tunnelling, though routing via a DECnet-plus node might
 be easier.  G Since TCPIP can do IP over serial links via PPP, and DECnet-plus can donE decnet-over tcpip, it's likely possible to do DECnet-over PPP.  But It haven't tried it yet.m   -- h Robert Deininger rdeininger@mindspring.comr   ------------------------------  % Date: Sat, 01 Sep 2001 10:08:36 -0400e2 From: rdeininger@mindspring.com (Robert Deininger)% Subject: Re: Tunneling DECnet over IPtL Message-ID: <rdeininger-0109011008370001@user-2iveba2.dialup.mindspring.com>  B In article <1010831225453.61567D-100000@Ives.egh.com>, John Santos <JOHN@egh.com> wrote:e    > > PhaseV VAX).  (BTW, I am getting frequent errors of the form > L > %DIRECT-E-OPENIN, error opening REMOTEPHASEV"user password"::*.*; as input/ > -RMS-F-SYS, QIO system service request failedi, > -SYSTEM-F-LINKEXIT, network partner exited > C > when I try to use the VAX 4200 as the intermediate system, thoughgA > sometimes it works.  Maybe it is just too slow and something iskF > timing out??  Seems to be solid using either Alpha as the PM router.  F I remember getting a lot of ethernet errors (not just DECnet) on a VAXD 4600, when I was doing a lot of tests with DECRAM disks.  Whenever IE INITed a RAM disk, the connection to other cluster members was up anduJ down.  So it does seem possible to choke the ethernet on these systems.  IF never tried the same on another VAX, for lack of extra memory.  Alphas never showed the same behavior.    -- c Robert Deininger rdeininger@mindspring.comT   ------------------------------  % Date: Sat, 01 Sep 2001 10:00:57 -0400n2 From: rdeininger@mindspring.com (Robert Deininger)% Subject: Re: Tunneling DECnet over IPtL Message-ID: <rdeininger-0109011000570001@user-2iveba2.dialup.mindspring.com>  B In article <1010831212112.61567B-100000@Ives.egh.com>, John Santos <JOHN@egh.com> wrote:p  . > On Fri, 31 Aug 2001, Robert Deininger wrote:  G > I don't think DECnet-plus can route between a local Phase-IV end nodevE > and a remote Phase V node, when the only connection between the twokH > phase V nodes is IP.  IOW, if I have a LAN with some phase IV and someE > phase V nodes, and a similar remote LAN with a similar mixture, theaG > Phase V nodes can talk to any local node and all the remote Ph V, butuG > the phase IV nodes can only talk to local nodes.  (If you have DECnetyA > circuits, then the Ph IV nodes can of course talk to any systemv+ > so connected via a Ph IV or Ph V router.)t > H > This is because the DECnet-over-IP service operates at the applicationE > link level (in Ph IV terminology), end-system to end-system, rathern8 > than as a virtual DECnet circuit at the routing level. > A > 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.a  H I probably got it wrong.  We don't have any phase IV nodes anymore, so I never had a chance to try it.h  + How about poor man's routing?  Can NODE1 dob   $DIR NODE2::NODE3::WHATEVERtE if NODE1 is phase IV, and NODE2 and NODE3 are phase V with only an IPo connection?e    . > > 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.  (MicroSoftl? > VPN seems to support Internet connection sharing, but the 1stiA > thing it wants to do if you try to turn it on is take over yourtF > entire network, become the DHCP server, renumber your network, etc.,B > and generally behave like MicroSoft, so I click "Cancel" and got > the hell out of there fast.)  3 Sounds like every microsoft product I've ever seen.    -- b Robert Deininger rdeininger@mindspring.comi   ------------------------------   End of INFO-VAX 2001.486 ************************