1 INFO-VAX	Mon, 03 Sep 2001	Volume 2001 : Issue 490       Contents: Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 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  Re: Alpha/VMS V Sun/Solaris  Re: Alpha/VMS V Sun/Solaris ) 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: Feeling Better about Itanium 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  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 2 Re: Intel announces IA-64 "HyperThreading" in 20022 Re: Intel announces IA-64 "HyperThreading" in 20023 Re: KZCCA-CB problems (UltraSCSI adapter for VAXes)  KZCCA-CB problems. RE: KZCCA-CB problems. Re: My VMS Wish List (features)  Re: My VMS Wish List (features)  Re: My VMS Wish List (features)  Re: My VMS Wish List (features)  Re: OPCOM in VMS.  OpenVMS /RDB Single Signon OpenVMS Products Prices  Re: OpenVMS Products Prices  OVMS License Re: OVMS License RE: PRINT /que=filename % Small DECterm Font & DECwindows Fonts  Re: Some postive points I hope. , RE: Standalone Backup Boot Question - Solved& The Inquirer : 1GHz ES45 Alpha delayed Re: Tunneling DECnet over IP Re: Tunneling DECnet over IP) Re: Ultra 160 SCSI for OpenVMS Alpha V7.3   Re: VMS 7.3 compatibility issues  Re: VMS 7.3 compatibility issues  Re: VMS 7.3 compatibility issues Re: VMS NT/win2000 similarities   F ----------------------------------------------------------------------   Date: 3 Sep 2001 02:35:44 -0400 ) From: tls@panix.com (Thor Lancelot Simon)  Subject: Re: alpha - ia64 + Message-ID: <9mv8c0$lm2$1@panix1.panix.com>   7 In article <slrn9p60jo.170h.andrew@gurney.reilly.home>, 1 Andrew Reilly <areilly@nsw.bigpond.net.au> wrote: 5 >On Mon, 03 Sep 2001 03:41:05 GMT, Yousuf Khan wrote: G >> I'm not sure what you see as a problem here. All memory accesses are L >> defaulted to 64-bit, and any operands within it would be 32-bit defaults.2 >> Any relative addressing is also done as 64-bit. > A >The problem arises as soon as you want to manipulate an array of @ >something with more than 2G _elements_.  Sure, the start of theA >array is a 64-bit address, and address arithmetic has to be done A >with address-sized integers, but C (at least) insists that array < >indices are "int".  If int is only 32-bits, then you have a	 >problem.   I If you think that this problem makes AA64 "32-bit", you should think that H it makes Alpha "32-bit".  After all, the vendor's standard C compiler is LP64, not ILP64.   --  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: Mon, 03 Sep 2001 09:03:49 +0100 ' From: Elliott Roper <elliott@yrl.co.uk>  Subject: Re: alpha - ia64 2 Message-ID: <030920010903496355%elliott@yrl.co.uk>  ; In article <3B92C7FA.3B2BB216@wasd.vsm.com.au>, Mark Daniel $ <Mark.Daniel@wasd.vsm.com.au> wrote:  B > I'm tempted to take exception to this throw-away comment but I'mI > buggered if I can think of anything civilised, witty or educated to say  > in reply.  >  > Nick Maclaren wrote:   > > C > > The UK is full of civilised, witty and educated Australians who G > > left because they couldn't stand the density of the morons in their  > > native country ....   G Strewth! I'm doing my bit. Increased the average IQ of both places when  I came over here.   F Many poms have a dry sense of humour. Takes a while to learn. Give him a bit more time, Mark.   ------------------------------  # Date: Mon, 03 Sep 2001 08:24:15 GMT % From: Ketil Z Malde <ketil@ii.uib.no>  Subject: Re: alpha - ia64 4 Message-ID: <KETIL-vk1heuksmvm.fsf@eris.bgo.nera.no>  ( name99@mac.com (Maynard Handley) writes:  L > It's easy to be high and mighty about principles when you're not next door6 > to a slow-motion disaster like Indonesia, isn't it?   @ Of course.  But I don't think the point is that Australia should8 automatically embrace all refugees, but rather take some responsibility.   B The Australian coast guard asks a cargo ship to assist a vessel inE distress, and later they consider it the ship's problem to get rid of C the extraneous passengers - which it cannot legally carry anywhere.   0 I think this case sets an unfortunate precedent.   -kzm --  H If I haven't seen further, it is by standing in the footprints of giants   ------------------------------  # Date: Mon, 03 Sep 2001 08:49:19 GMT / From: andrew@gurney.reilly.home (Andrew Reilly)  Subject: Re: alpha - ia64 7 Message-ID: <slrn9p6h0g.2hov.andrew@gurney.reilly.home>   8 On 3 Sep 2001 02:35:44 -0400, Thor Lancelot Simon wrote:9 > In article <slrn9p60jo.170h.andrew@gurney.reilly.home>, 3 > Andrew Reilly <areilly@nsw.bigpond.net.au> wrote: B >>The problem arises as soon as you want to manipulate an array ofA >>something with more than 2G _elements_.  Sure, the start of the B >>array is a 64-bit address, and address arithmetic has to be doneB >>with address-sized integers, but C (at least) insists that array= >>indices are "int".  If int is only 32-bits, then you have a 
 >>problem. > K > If you think that this problem makes AA64 "32-bit", you should think that J > it makes Alpha "32-bit".  After all, the vendor's standard C compiler is > LP64, not ILP64.  ? I didn't say anything about the "bittness" of Alpha, but then I > haven't seen how it handles arrays with more than 2G elements.: If it follows the C standard, and that requires indices to= conform to "int", then surely that's a bit of a limitation in  some cases?   ? I think that ILP64 is a good way to do things, myself.  I can't = think of any good uses for arrays with more than 2G elements, : off the top of my head, and I like being able to deal with= 32-bit quantities most of the time.  Ever since this "glitch" 9 was pointed out in comp.arch a few months ago, though, it ; has looked more and more like a flaw in C itself, and I was > wondering how people were dealing with it.  It's not as though" 64 bit processors are brand new...   --   Andrew   ------------------------------   Date: 3 Sep 2001 10:36:53 GMT & From: peter@abbnm.com (Peter da Silva) Subject: Re: alpha - ia64 % Message-ID: <9mvmg5$na9@web.nmti.com>   & In article <3B92AD21.269DA353@gmx.de>,* Bernd Paysan  <bernd.paysan@gmx.de> wrote:J > International sea law is old and established, it is the only law againstJ > piracy, slavery and other bad things that happend on the open sea before > it was defined.   J You think they don't happen any more? In the Indian Ocean, the South China. Sea, and all points between they certainly do.   --  +  `-_-'   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: Mon, 03 Sep 2001 12:07:14 +0100 6 From: Christian Bau <christian.bau@isltd.insignia.com> Subject: Re: alpha - ia64 2 Message-ID: <3B936462.60644CF8@isltd.insignia.com>   Yousuf Khan wrote: > > > "Andrew Reilly" <andrew@gurney.reilly.home> wrote in message3 > news:slrn9p60jo.170h.andrew@gurney.reilly.home... D > > The problem arises as soon as you want to manipulate an array ofC > > something with more than 2G _elements_.  Sure, the start of the D > > array is a 64-bit address, and address arithmetic has to be doneD > > with address-sized integers, but C (at least) insists that array? > > indices are "int".  If int is only 32-bits, then you have a  > > problem. > N > If "C" insists on the index variables being 32-bit, then you have a 32-bit C$ > compiler, not a 64-bit C compiler.  C But the assertion that "C insists that array indices are "int" " is E wrong. Array indices can be of any integer type, and the mathematical  value of the index is used.   @ However, a C compiler also defines the "size_t" type which is anF unsigned integer type big enough to hold the size of any valid object.F If size_t is 32 bit, then there are limitations to the object size. IfD size_t is a 64 bit type, and int is only 32 bit, then the C compiler7 MUST support indices of types other than int correctly.    ------------------------------  % Date: Mon, 03 Sep 2001 14:12:50 +0200 * From: Alexis Cousein <al@brussels.sgi.com> Subject: Re: alpha - ia64 / Message-ID: <3B9373C2.2030402@brussels.sgi.com>    Bill Todd wrote:% >>-*only* slightly slower than P4 [1] ! >>-likely to stay around for long  >>-can address 64 bits.  >> >  > Sounds like Hammer to me:   D Well, opinion is divided about the second point (which is, arguably, indeed not a technical one).   --  ? <these messages express my own views, not those of my employer> ) Alexis Cousein				Senior Systems Engineer . SGI Belgium and Luxemburg		al@brussels.sgi.com   ------------------------------   Date: 3 Sep 2001 12:26:24 GMT ( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: alpha - ia64 0 Message-ID: <9mvstg$mon$1@pegasus.csx.cam.ac.uk>  / In article <3B9373C2.2030402@brussels.sgi.com>, , Alexis Cousein <al@brussels.sgi.com> writes: |> Bill Todd wrote: ( |> >>-*only* slightly slower than P4 [1]$ |> >>-likely to stay around for long |> >>-can address 64 bits. |> >   |> > Sounds like Hammer to me:   |>  G |> Well, opinion is divided about the second point (which is, arguably,  |> indeed not a technical one).   C Not yet, anyway - roll on its release, and some decent competition!  Well, I can hope :-)     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: Mon, 3 Sep 2001 09:50:11 -0400' From: "Bill Todd" <billtodd@foo.mv.com>  Subject: Re: alpha - ia64 ( Message-ID: <9n01ov$73g$1@pyrite.mv.net>  7 "Alexis Cousein" <al@brussels.sgi.com> wrote in message ) news:3B9373C2.2030402@brussels.sgi.com...  > Bill Todd wrote:' > >>-*only* slightly slower than P4 [1] # > >>-likely to stay around for long  > >>-can address 64 bits.  > >> > >  > > Sounds like Hammer to me:  > F > Well, opinion is divided about the second point (which is, arguably, > indeed not a technical one).  K I wish I knew more about it so that I could have more of an opinion:  while L the Athlon core seems to demand some reasonable amount of respect, I haven'tH seen any projected performance figures for Hammer itself (do you know of any?).  I As far as usability, the Linux port seems to have felt it worthwhile, and 9 suitable for use in mixed-addrelss-width OS environments.    - bill   >  > --A > <these messages express my own views, not those of my employer> ( > Alexis Cousein Senior Systems Engineer/ > SGI Belgium and Luxemburg al@brussels.sgi.com  >    ------------------------------  # Date: Mon, 03 Sep 2001 16:06:35 GMT   From: "eddie" <NullVoid@att.net> Subject: Re: alpha - ia64 F Message-ID: <fUNk7.8961$151.685880@bgtnsc05-news.ops.worldnet.att.net>  < "Andrew Reilly" <andrew@gurney.reilly.home> wrote in message1 news:slrn9p6h0g.2hov.andrew@gurney.reilly.home... : > On 3 Sep 2001 02:35:44 -0400, Thor Lancelot Simon wrote:; > > In article <slrn9p60jo.170h.andrew@gurney.reilly.home>, 5 > > Andrew Reilly <areilly@nsw.bigpond.net.au> wrote: D > >>The problem arises as soon as you want to manipulate an array of .  .  . = > has looked more and more like a flaw in C itself, and I was @ > wondering how people were dealing with it.  It's not as though$ > 64 bit processors are brand new... >  > -- > Andrew   Andrew,   G First, C does not require array indices to be int, please reference the  attachedK test program that I just wrote, compiled, and executed. It uses an unsigned  long? for the index and would allow access to 4,294,967,296 elements.   K Second, you are missing a major point. If you have a 64-bit microprocessor,  thenJ you buy a 64-bit compiler. With a 64 bit compiler, int would default to 64 bits in length.   F Third, just because you can not think of a need for large arrays means nothing.   eddie    #define ARRAY_SIZE 100" void main(int argc, char *argv[] ) {   unsigned long array[ARRAY_SIZE]; unsigned long i;   for(i=0; i<ARRAY_SIZE; i++)   {  array[i] = 0;  } } // end main()    ------------------------------  + Date: Mon, 03 Sep 2001 11:20:31 -0500 (CDT)  From: sms@antinode.org Subject: Re: alpha - ia64 ) Message-ID: <01090311203125@antinode.org>     From: "eddie" <NullVoid@att.net>  = > Second, you are missing a major point. If you have a 64-bit I > microprocessor, then you buy a 64-bit compiler. With a 64 bit compiler, ) > int would default to 64 bits in length. (   ======================================  H    This would appear to be news to (at least) Compaq and Sun.  Last timeF I checked, the Alpha and UltraSPARC were 64-bit systems, and these are) "64-bit" compilers (whatever that means):    alp $ type siz.c #include <stdio.h>   main() { I printf( " char = %d, int = %d, long = %d, long long = %d, void* = %d.\n", ,  sizeof( char), sizeof( int), sizeof( long),&  sizeof( long long), sizeof( void *)); }    ------   alp $ cc siz alp $ link siz
 alp $ run siz 7  char = 1, int = 4, long = 4, long long = 8, void* = 4.    alp $ cc /version ) Compaq C V6.2-003 on OpenVMS Alpha V7.2-1    ------   urt % cc -o siz siz.c 	 urt % siz 7  char = 1, int = 4, long = 8, long long = 8, void* = 8.    urt % cc -V < Compaq C V6.4-214 (dtk) on Compaq Tru64 UNIX V5.1 (Rev. 732)( Compiler Driver V6.4-014 (dtk) cc Driver   ------   moon% cc -o siz32 siz.c ! moon% cc -o siz64 -xarch=v9 siz.c  moon% siz32 7  char = 1, int = 4, long = 4, long long = 8, void* = 4.  moon% siz64 7  char = 1, int = 4, long = 8, long long = 8, void* = 8.    moon% cc -V ) cc: WorkShop Compilers 5.0 98/12/15 C 5.0  moon% uname -a< SunOS moon 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-5_10   ------  D    Having made the switch from 16 to 32 bits and from 32 to 64, it'sD become clear to me that the decision to hide the size of fundamentalH data (like "int") was one of the least clever things in the design of C,F at least for bit twidlers like me.  A primary reason for keeping "int"C at 32 bits was the desire to avoid breaking vast amounts of working  (32-bit) code.  H ------------------------------------------------------------------------  C    Steven M. Schweda               (+1) 651-699-9818  (voice, home) C    382 South Warwick Street        (+1) 763-781-0308  (voice, work) G    Saint Paul  MN  55105-2547      (+1) 763-781-0309  (facsimile, work) 9    sms@antinode.org                sms@provis.com  (work)    ------------------------------  % Date: Mon, 03 Sep 2001 18:08:47 +0100 0 From: andrew harrison <andrew.nospam@uk.sun.com> Subject: Re: alpha - ia64 * Message-ID: <3B93B91F.CD9D5BC9@uk.sun.com>   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. > >> > >S9 > >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 compulsivelyl > masturbating again!  > I > How hard can it possibly be for you to understand that you are bringingSF > your dubious grasp of computer architecture and questionable writingI > talents to bear on a _dead architecture_?  There's not really any pointU > to your slagging them. >   < Really, what is it do you think that I don't understand ????  G Could it be that I don't understand why anyone would only be interested G in the performance of a CPU without being interested in its performance $ in a system running applications ???  D Could it be that I don't understand why you have read a thread that # is about a "dead architecture" ???    K > This discussion is about _CPU performance_, and SPEC is a _CPU benchmark_ I > (perhaps it would be nice if it were also a memory subsystem benchmark,2M > 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. >   G And this thread is not discussing SPEC performance it started with this  posting    >>>>Hi,p  I >>>>One thing that confuses me about the intel swallowup of Alpha is thateE >>>>with IA64 being EPIC and not RISC and AMD bringing out the HammertH >>>>range of cpu's Intel will still be in a similar situation to that itJ >>>>is in now having to cut chip prices heavily to compete with AMD. I putH >>>>this down to the fact that IA64 was designed when Alpha was still onG >>>>NT and thus Intel needed to go the EPIC route to compete with FX32..I >>>>Now that AlphaNT is no longer Intel is stuck with a cpu that needs to0H >>>>be able to run 32bit code when if Alpha had never existed they couldI >>>>have produced a RISC cpu. And they are still stuck in a dogfight withoJ >>>>AMD when with their tyins with M$ they could have produced a processor >>>>without any legacy hiccups.l  D >>>>Looking into the future maybe one route for Intel a) could be to >>>>re-release Alpha (dream on)0  J >>>>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."t  $ Do you see a reference to SPEC ?????  8 The first reference to SPEC is in response to my posting  8 >>>>I always thought that the Alpha was a well designed 8 >>>>high performance CPU, depending on timing sometimes - >>>>the highest performing CPU sometimes not.a  < >>>>I have also always thought that Digital and subsequentlyC >>>>Compaq have done a terrible job of providing a balanced system ". >>>>design for systems using Alpha processors. >>>>; >>>>There have been a few exceptions, the ES40 for example.h >>>>D >>>>And it isn't just poor memory and I/O subsystems as exemplified E >>>>by the WildFire its was also the Alpha workstations particularly  A >>>>running OpenVMS were hampered because of lack of support for '. >>>>high performance 3D graphics accelerators.  & Here is the response from Aaron Spink.  O >>>As a side note, we were a little bored at work on day recently, so one of myeO >>>co-workers grabbed and munged all the available spec.org data for Spec95 andj
 >>>Spec2k. >>>iM >>>Over the past 7 years, Alpha was in the top spot for SpecIntXXX except forAM >>>about 6 non contiguous months, for SpecFpXXX the number is pretty much the 2 >>>same.  Kind of an interesting graph to look at.  @ Since my posting specifically refered to the overall performance? of the system and not SPECint Aaron very sensibly said that his:= response was a side note, its only a pity you didn't realise u< this since it would have saved you some embarassment. I can 8 only assume that you missed this earlier posting in this: thread, perhaps we can put it down to a problem with your : newsreader, rather than any comprehension issues. :):):):)   Regards  Andrew Harrisonl Enterprise IT Architecte   ------------------------------  % Date: Mon, 03 Sep 2001 12:42:06 +0100:( From: Nic Clews <sendspamhere@127.0.0.1>$ Subject: Re: Alpha/VMS V Sun/Solaris) Message-ID: <3B936C8D.78F61480@127.0.0.1>.   Mark Daniel wrote: >  > Can't resist ... > 8 >   http://wasd.vsm.com.au/ht_root/doc/htd/htd_1800.html  @ And someone tried to tell me that source coding had no effect on performance.   Apache = Sheep
 OSU = Fast WASD = Need clean shovels. *  G (*Explanation: In the UK we speak of something as "Faster than s**t offiB a shovel". The origins of this expression are lost on me however.)   -- n( Regards, Nic Clews CSC Computer Sciences nclews at csc dot comr   ------------------------------   Date: 3 Sep 2001 07:28:39 -0500w- From: Kilgallen@SpamCop.net (Larry Kilgallen) $ Subject: Re: Alpha/VMS V Sun/Solaris3 Message-ID: <IDrayhdG2g+W@eisner.encompasserve.org>   T In article <3B936C8D.78F61480@127.0.0.1>, Nic Clews <sendspamhere@127.0.0.1> writes: > Mark Daniel wrote: >> A >> Can't resist ...c >> :9 >>   http://wasd.vsm.com.au/ht_root/doc/htd/htd_1800.htmlr > B > And someone tried to tell me that source coding had no effect on > performance. >  > Apache = Sheep > OSU = Fast > WASD = Need clean shovels. * > I > (*Explanation: In the UK we speak of something as "Faster than s**t offiD > a shovel". The origins of this expression are lost on me however.)  C I don't understand your reference to "source coding", but as I readaD the WASD pages, it is strictly a uniprocessor approach.  By contrastH OSU can make use of multiprocessors on Alpha because it uses DECthreads.H That is absolutely a trade-off -- take the performance hit of DECthreadsE in return for being able to use multiple processors at the same time.'F Whether multiple processors at the same time is of interest depends on( how big your web server is going to get.  C "Sheep" may be a pejorative, but it is important for VMS to be ableoA to say they have an "Industry Standard" web server.  Even if some"B system manager chooses OSU or WASD, it may impress their boss that$ Apache is available to fall back on.   ------------------------------  % Date: Mon, 03 Sep 2001 15:57:15 +0100 ( From: Nic Clews <sendspamhere@127.0.0.1>$ Subject: Re: Alpha/VMS V Sun/Solaris) Message-ID: <3B939A4B.EA2F5201@127.0.0.1>s   Larry Kilgallen wrote: > V > In article <3B936C8D.78F61480@127.0.0.1>, Nic Clews <sendspamhere@127.0.0.1> writes: > > Mark Daniel wrote:   > > Apache = Sheep > > OSU = Fast  > > WASD = Need clean shovels. * > >   E > I don't understand your reference to "source coding", but as I read F > the WASD pages, it is strictly a uniprocessor approach.  By contrastJ > OSU can make use of multiprocessors on Alpha because it uses DECthreads.J > That is absolutely a trade-off -- take the performance hit of DECthreadsG > in return for being able to use multiple processors at the same time.iH > Whether multiple processors at the same time is of interest depends on* > how big your web server is going to get.  E This is something that surprised me in reading this. My disclaimer iseA I'm not a programmer, but with all the noise beating around about D threads, and the best performing, although arguably subjective, is aF single threaded application. Kinda nullifys certain other threads (punE intended) running on c.o.v. (I'm also aware I'm mixed moding so don't-
 flame me!)  G Apache has a relatively uniform code base which builds on whatever, andiB I'm referring to it as code that is written to run, not written toF perform. Coding with the architecture it will run on in mind does have an impact on the performance.   tE > "Sheep" may be a pejorative, but it is important for VMS to be able C > to say they have an "Industry Standard" web server.  Even if some D > system manager chooses OSU or WASD, it may impress their boss that& > Apache is available to fall back on.  E Yes, I nearly added something to my post, (and the last time I statedtF it) that it is in no way a reflection of what I think about the meritsC of using the Apache webserver, or the efforts to bring it to VMS, IbA applaud it. (I've also had an earful of Pink Floyd's Animals justtD recently, I wasn't being paricularly inspiring in what I said). Just' settling down to some of the 'Zeppelin.b   Thanks for the observation.m   -- i( Regards, Nic Clews CSC Computer Sciences nclews at csc dot comd   ------------------------------   Date: 3 Sep 2001 10:11:54 -0500h- From: Kilgallen@SpamCop.net (Larry Kilgallen)_$ Subject: Re: Alpha/VMS V Sun/Solaris3 Message-ID: <fAn2LBo4PHZW@eisner.encompasserve.org>d  T In article <3B939A4B.EA2F5201@127.0.0.1>, Nic Clews <sendspamhere@127.0.0.1> writes: > Larry Kilgallen wrote: >> -W >> In article <3B936C8D.78F61480@127.0.0.1>, Nic Clews <sendspamhere@127.0.0.1> writes:. >> > Mark Daniel wrote:p >  >> > Apache = Sheep3 >> > OSU = Fastr! >> > WASD = Need clean shovels. *: >> > > F >> I don't understand your reference to "source coding", but as I readG >> the WASD pages, it is strictly a uniprocessor approach.  By contrastoK >> OSU can make use of multiprocessors on Alpha because it uses DECthreads.cK >> That is absolutely a trade-off -- take the performance hit of DECthreadsyH >> in return for being able to use multiple processors at the same time.I >> Whether multiple processors at the same time is of interest depends on1+ >> how big your web server is going to get.k > G > This is something that surprised me in reading this. My disclaimer is.C > I'm not a programmer, but with all the noise beating around aboutsF > threads, and the best performing, although arguably subjective, is a > single threaded application.  E Provided you only have one CPU on which to run, a AST-driven approach D (as I presume WASD uses) should be much more efficient on VMS than aH DECthreads approach.  It might even be better than a DECthreads approachE using 2 CPUs.  At some count, however, having multiple CPUs and usingnB DECthreads should surpass the AST-driven approach on a single CPU.   ------------------------------  % Date: Mon, 03 Sep 2001 12:18:25 -0500e1 From: "David J. Dachtera" <djesys.nospam@fsi.net>+$ Subject: Re: Alpha/VMS V Sun/Solaris' Message-ID: <3B93BB61.126656DA@fsi.net>a   Nic Clews wrote: >  > Mark Daniel wrote: > >d > > Can't resist ... > >u: > >   http://wasd.vsm.com.au/ht_root/doc/htd/htd_1800.html > B > And someone tried to tell me that source coding had no effect on > performance. >  > Apache = Sheep > OSU = Fast > WASD = Need clean shovels. * > I > (*Explanation: In the UK we speak of something as "Faster than s**t offsD > a shovel". The origins of this expression are lost on me however.)  9 Maybe something to do with cleaning up after the sheep...d   -- t David J. Dachtera  dba DJE Systemsa http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/a   ------------------------------    Date: 03 Sep 2001 11:50:46 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>L2 Subject: Re: Conference: CETS-2001 Detailed UpdateH Message-ID: <y48zfwfvrd.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  6 "Terry C. Shannon" <terryshannon@mediaone.net> writes:  O > Yep. The usual USENET Horseshit. But what elsw would you expect from here????r  M Really, Terry. My opinion of you has gone down another factor of 2 or so. And H I used to have a very high opinion of you, having read all of the freelyF available issues of your newsletter in the past years. It has sufferedJ considerably in the past two months, and your last "contributions" in thisJ forum have done nothing but damage it further. Of course, you are free not@ to care for my opinion, of yourself or anything for that matter.  M If you don't like reading comp.os.vms, don't read it, or at least don't post. G And especially don't post insulting throw-away comments like the above.   L If you _do_ care, try reasoning, once in a while. I did so with Jeff's post.   	Jan   ------------------------------    Date: 03 Sep 2001 12:00:02 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>e2 Subject: Re: Conference: CETS-2001 Detailed UpdateH Message-ID: <y466b0fvbx.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... M > > Blech. Do you think an iteration of an ASIC 2-4 years back in the US costWM > > ten times more than a turn of a state-of-the-art custom design in Germany  > > two years back?hL > 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.n  / Thanks but no thanks for the gratuitous insult.   M Maybe you should engage your brain before replying. There is an inconsistency L between what, from your words, the Wildfire project leader said and what theE real costs are, by a factor of ten. I gave you one possibility for an@J explanation, and because it is you reporting on that quote by said person,N it's on you to say whether that is a plausible or even probable explanation ofM that discrepancy. But in no way does a single spin of an ASIC cost upwards of=I $1M - that piece of the market wouldn't exist if it did. For corrboratinge data, see MOSAID.p   	Jan   ------------------------------  % Date: Mon, 03 Sep 2001 12:15:25 +0100t% From: Alan Greig <a.greig@virgin.net>u2 Subject: Re: Conference: CETS-2001 Detailed Update8 Message-ID: <06p6pt8cjhpb7vtt57iib91hmacijiu1h0@4ax.com>  . On 03 Sep 2001 11:50:46 +0200, Jan Vorbrueggen8 <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:  7 >"Terry C. Shannon" <terryshannon@mediaone.net> writes:= > P >> Yep. The usual USENET Horseshit. But what elsw would you expect from here???? >VN >Really, Terry. My opinion of you has gone down another factor of 2 or so. AndI >I used to have a very high opinion of you, having read all of the freelynG >available issues of your newsletter in the past years. It has sufferedvK >considerably in the past two months, and your last "contributions" in this K >forum have done nothing but damage it further. Of course, you are free not A >to care for my opinion, of yourself or anything for that matter.    Yes,  F Terry seems to have caught the Compaq disease. If customers don't likeF what you say then just ignore them or insult them. My opinion of Terry  has nose-dived as well recently.  C While it might make Terry feel better, calling a large chunk of theiF customer base horseshitting Usenet whiners seems to me worse than  the behaviour complained about.   N >If you don't like reading comp.os.vms, don't read it, or at least don't post.H >And especially don't post insulting throw-away comments like the above. > M >If you _do_ care, try reasoning, once in a while. I did so with Jeff's post.S >e >	Janh   -- Alan   ------------------------------  # Date: Mon, 03 Sep 2001 15:35:58 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>2 Subject: Re: Conference: CETS-2001 Detailed Update; Message-ID: <yrNk7.856$CR2.1353385@typhoon.ne.mediaone.net>k  L "Jan Vorbrueggen" <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote inJ message news:y466b0fvbx.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de...* > "Jeff Killeen" <Jeff@IDM-IO.com> writes: > K > > > > This is very indicative of the pure speculation is going on here... J > > > Blech. Do you think an iteration of an ASIC 2-4 years back in the US costG > > > ten times more than a turn of a state-of-the-art custom design in> GermanyE > > > two years back?mE > > No - but I do think the project leader for Wildfire is a far more> reliableL > > cost of  Wildfire ASIC's costs than the cowboys with a keyboard in these > > newsgroups.  >>1 > Thanks but no thanks for the gratuitous insult.r >nA > Maybe you should engage your brain before replying. There is anl
 inconsistencysJ > between what, from your words, the Wildfire project leader said and what thehG > real costs are, by a factor of ten. I gave you one possibility for anuL > explanation, and because it is you reporting on that quote by said person,A > it's on you to say whether that is a plausible or even probablee explanation ofL > that discrepancy. But in no way does a single spin of an ASIC cost upwards ofK > $1M - that piece of the market wouldn't exist if it did. For corrboratinge > data, see MOSAID.a >t  K Do check out MOSAID, (no relation to Mossad, I hope) but there was at leasteJ killer ASIC on WildFire. CPQ farmed it out and found that the vendor couldK not implement the ASIC with 32-bit tools. Not sure how it was resolved, buto it wasn't cheap!   ------------------------------  % Date: Mon, 03 Sep 2001 11:27:43 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>t2 Subject: Re: Conference: CETS-2001 Detailed Update' Message-ID: <3B93AF7F.DFBD87D8@fsi.net>I   Alan Greig wrote:  > 0 > On 03 Sep 2001 11:50:46 +0200, Jan Vorbrueggen: > <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote: > 9 > >"Terry C. Shannon" <terryshannon@mediaone.net> writes:r > > R > >> Yep. The usual USENET Horseshit. But what elsw would you expect from here???? > >oP > >Really, Terry. My opinion of you has gone down another factor of 2 or so. AndK > >I used to have a very high opinion of you, having read all of the freely I > >available issues of your newsletter in the past years. It has sufferedtM > >considerably in the past two months, and your last "contributions" in this M > >forum have done nothing but damage it further. Of course, you are free not C > >to care for my opinion, of yourself or anything for that matter.s >  > Yes, > H > Terry seems to have caught the Compaq disease. If customers don't likeH > what you say then just ignore them or insult them. My opinion of Terry" > has nose-dived as well recently. > E > While it might make Terry feel better, calling a large chunk of thenH > customer base horseshitting Usenet whiners seems to me worse than  the > behaviour complained about.> > P > >If you don't like reading comp.os.vms, don't read it, or at least don't post.J > >And especially don't post insulting throw-away comments like the above. > >IO > >If you _do_ care, try reasoning, once in a while. I did so with Jeff's post.n  H Hhmmm... This seems to me not at all inconsistent with modern society asC a whole. Compaq is simply "following the crowd": one's mistakes aredH always the fault of somebody else and if one group's view disagrees with@ a second group's view, then the second group as at fault for not agreeing with the first group.  D There's no responsibility anymore. Group leaders always expect theirF reports to "take ownership", but the group leader expects to be immune from all responsibility.  H ...and heaven forbid anyone should have the backbone to admit, "Oh, oh - I screwed up".  , Rather sounds like kindergarten, doesn't it?  G So Compaq will go on believing that it's always right and the market isiH always wrong, their stock price will tank, and who knows - maybe someone7 like me can pick up OVMS & Co. at a bankruptcy auction.e  % Good things come to those who wait...r   --   David J. Dachteraa dba DJE Systems> http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/e   ------------------------------  % Date: Mon, 03 Sep 2001 17:23:34 +0100r0 From: andrew harrison <andrew.nospam@uk.sun.com>) Subject: Re: Feeling Better about Itanium * Message-ID: <3B93AE86.C05D97E6@uk.sun.com>   jlsue wrote: > H > But how do we know how long ago our engineers began working with Intel > engineers on IA64? > E > I don't mean to start rumors, and I have no inside knowledge, but IcG > doubt this decision was brought up and decided in one week.  Probably  > not even one month.g >   1 You had better hope that your engineers did only  / start working with Intel on or after the 25th.    0 Given the discussion going on in this newsgroup 0 about Compaqs alledged corporate lies before the 25th would be the wrong answer.v   Regards  Andrew Harrisona Enterprise IT Architectm   ------------------------------    Date: 03 Sep 2001 10:36:17 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>s Subject: Re: I hate CompaqH Message-ID: <y4ofosfz7i.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  * nmm1@cus.cam.ac.uk (Nick Maclaren) writes:  @ > And, despite claims, there ISN'T an overhead problem on modern> > machines - there is merely an attitude problem.  It would be= > trivial to extend a process state by a bit map saying whichu@ > instructions should be emulated, and to have this inspected by< > instruction decoding.  But it needs to be designed in from8 > scratch, as bolting it on later may well be a problem.  I Of course it is an overhead problem. For one, you've got additional stateeM to save. For a second, instruction decode is already on a current processor'ssG critical path. For a third, how fine-grained are you going to make this-I virtualisation control? For instance, if you are going to intercept everyrL load and store - sufficient for checking of stack clobbering, your example -L then you might as well go with Sun's pure software-based solution, which hasK an overhead of a factor of about 20 and which is _faster_ than any possiblerJ hardware-based solution could be. If you are going to be more fine-grainedN than that - how are you going to recognise manipulations of the stack compared to, say, the heap?  N A severely trashed stack makes anything inherently stack-based very difficult,M and that includes the usual exception handling. The only alternative would besK to provide a seperate stack when in an exception - that gets you to Larry'seJ inner-mode suggestion. I think you could reasonably implement that on VMS.  L I also agree with Larry that your approach tries to solve the wrong problem.N An ounce of prevention...that is, use strongly-typed languages, and write your& run-time support in the same language.   	Jan   ------------------------------   Date: 3 Sep 2001 08:58:41 GMTe( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: I hate Compaq0 Message-ID: <9mvgo1$b87$1@pegasus.csx.cam.ac.uk>  H In article <y4ofosfz7i.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>,I Jan Vorbrueggen  <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:m+ >nmm1@cus.cam.ac.uk (Nick Maclaren) writes:l >oA >> And, despite claims, there ISN'T an overhead problem on moderne? >> machines - there is merely an attitude problem.  It would be > >> trivial to extend a process state by a bit map saying whichA >> instructions should be emulated, and to have this inspected byC= >> instruction decoding.  But it needs to be designed in frome9 >> scratch, as bolting it on later may well be a problem.  >tJ >Of course it is an overhead problem. For one, you've got additional stateN >to save. For a second, instruction decode is already on a current processor'sH >critical path. For a third, how fine-grained are you going to make thisJ >virtualisation control? For instance, if you are going to intercept everyM >load and store - sufficient for checking of stack clobbering, your example -oM >then you might as well go with Sun's pure software-based solution, which hasfL >an overhead of a factor of about 20 and which is _faster_ than any possibleK >hardware-based solution could be. If you are going to be more fine-grainedaO >than that - how are you going to recognise manipulations of the stack comparedi >to, say, the heap?   D That isn't my point.  Yes, I agree that you have to save and restoreA the state, though usable implementations might be as few as (say)i@ 32 bits and a maximal one would be under 512 bits.  But the time> overhead is non-existent, because this checking can be done inD parallel with other operations - and, in an architecture like IA-64,< can be handled completely outside the microoperation engine!  @ As a specific reply to your question, a good solution here (well@ proven, too) is to have a flag on the page tables that forces anE interrupt.  Combined with the (also proven) technique of lightweight,tA context-preserving interrupts, this would ve bery useful and very. cheap.  O >A severely trashed stack makes anything inherently stack-based very difficult,iN >and that includes the usual exception handling. The only alternative would beL >to provide a seperate stack when in an exception - that gets you to Larry'sK >inner-mode suggestion. I think you could reasonably implement that on VMS.i  B Yes, OF COURSE, you need a separate stack - doesn't every run-timeB system provide one for that purpose? :-(  It makes me despair that; nobody nowadays seems to remember the lessons of the 1970s.-  M >I also agree with Larry that your approach tries to solve the wrong problem.KO >An ounce of prevention...that is, use strongly-typed languages, and write yourr' >run-time support in the same language.A  G Hang on - you know better than that!  It can't be done, has been proven F to be impossible, and was known to be a delusion by the 1970s.  So why# is the myth still being propagated?s  F The run-time support includes the garbage collector, which it is well-F known involves breaking type rules (in general).  A few, VERY limited,C garbage collectors can be written without doing that, but not most.s  D And remember that I was referring to the location of code-generationC errors - obviously, NO amount of checking in the language will helpsD with those.  And you might be surprised to know that some 30% of theB nasty problems that I hit are actually code-generation errors ....  @ The last point is that using a bulletproof language is currentlyD incompatible with getting maximal performance - I believe that isn'tA a theoretical limit, but lost that argument a long time ago.  And D the problems that hit in real life often show up ONLY when maximallyB optimised codes are run on real (i.e. large and complex) data, and> are often unrepeatable.  So do you put up with a factor of twoB reduction in performance, say that unrepeatable problems cannot beA investigated or provide a decent low-level debugging environment?m) Most modern vendors choose the second :-(a  A My point isn't that a bulletproof debugger is needed for end-users@ codes - it isn't - but that it has been REPEATEDLY shown to saveC time and increase quality in the development of the infrastructure.:4 Not the kernel, perhaps, but most layers above that.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679c   ------------------------------   Date: 3 Sep 2001 09:32:21 GMTc( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: I hate Compaq0 Message-ID: <9mvin5$csa$1@pegasus.csx.cam.ac.uk>  0 In article <9mvgo1$b87$1@pegasus.csx.cam.ac.uk>,* nmm1@cus.cam.ac.uk (Nick Maclaren) writes: |> e@ |> ....  And you might be surprised to know that some 30% of theE |> nasty problems that I hit are actually code-generation errors ....t  + Damn.  Omitted phrase.  I should have said:r  = And you might be surprised to know that some 30% of the nasty-= problems that I hit, which can be made to go away by reducing 6 optimisation, are actually code-generation errors ....     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 334679T   ------------------------------    Date: 03 Sep 2001 12:54:32 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>o Subject: Re: I hate CompaqH Message-ID: <y4r8toee8n.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  * nmm1@cus.cam.ac.uk (Nick Maclaren) writes:  F > That isn't my point.  Yes, I agree that you have to save and restoreC > the state, though usable implementations might be as few as (say) B > 32 bits and a maximal one would be under 512 bits.  But the time@ > overhead is non-existent, because this checking can be done inF > parallel with other operations - and, in an architecture like IA-64,> > can be handled completely outside the microoperation engine!  K IA64 is irrelevant. And you have to send some part of the decoded opcode to-H the checker circuit (higher drive required - slower circuit) and mux itsF result back into the pipeline - adds another two or three gates to theF critical path. Yep, definitly an impact on performance for everything.  B > As a specific reply to your question, a good solution here (wellB > proven, too) is to have a flag on the page tables that forces anG > interrupt.  Combined with the (also proven) technique of lightweight,aJ > context-preserving interrupts, this would ve bery useful and very cheap.  H You can do that now. Performance will be worse than that of patching theJ load/store instructions. If you know the compiler's idioms and the callingI conventions, you likely could patch only those instructions accessing thet stack, if you wanted.u  H > The run-time support includes the garbage collector, which it is well-3 > known involves breaking type rules (in general). t  I How many people write and debug a garbage collector, even if such a thingtL exists in the language or system in question? And every good language allowsG you to break the type system in a controlled way, such that it is quitea, possible to write a garbage collector in it.   	Jan   ------------------------------   Date: 3 Sep 2001 11:25:46 GMT=( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: I hate Compaq0 Message-ID: <9mvpbq$j42$1@pegasus.csx.cam.ac.uk>   In article <y4r8toee8n.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>, Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:- |> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:u |> aI |> > That isn't my point.  Yes, I agree that you have to save and restorerF |> > the state, though usable implementations might be as few as (say)E |> > 32 bits and a maximal one would be under 512 bits.  But the time C |> > overhead is non-existent, because this checking can be done iniI |> > parallel with other operations - and, in an architecture like IA-64,eA |> > can be handled completely outside the microoperation engine!i |>  N |> IA64 is irrelevant. And you have to send some part of the decoded opcode toK |> the checker circuit (higher drive required - slower circuit) and mux itsgI |> result back into the pipeline - adds another two or three gates to theoI |> critical path. Yep, definitly an impact on performance for everything.   D Oh, for heaven's sake!  There is ALREADY such a check in all designs? that can run an operating system, as it has to check whether andB instruction is privileged or not.  All that has to be done is thatB the check is done differently.  As I have repeatedly said, bolting@ it onto an existing design CAN be a problem, but designing it in1 isn't.  It has been done often enough, after all.   E |> > As a specific reply to your question, a good solution here (wellmE |> > proven, too) is to have a flag on the page tables that forces anhJ |> > interrupt.  Combined with the (also proven) technique of lightweight,M |> > context-preserving interrupts, this would ve bery useful and very cheap." |> rK |> You can do that now. Performance will be worse than that of patching theeM |> load/store instructions. If you know the compiler's idioms and the calling L |> conventions, you likely could patch only those instructions accessing the |> stack, if you wanted.  D Fractionally worse, yes, but one real advantage is that the facility? does not involve making the code segment writable, with all thes? problems that entails, however it is done.  The other advantageAA (which is pretty important, too) is that it makes the overhead ofnB full-transparent, application-level emulation and other fixups lowF enough that the basic hardware and operating-system can be simplified,? with consequential improvements in reliability and performance.b  / Have you ever used a system with this facility?   K |> > The run-time support includes the garbage collector, which it is well-g6 |> > known involves breaking type rules (in general).  |>  L |> How many people write and debug a garbage collector, even if such a thingO |> exists in the language or system in question? And every good language allowslJ |> you to break the type system in a controlled way, such that it is quite/ |> possible to write a garbage collector in it.v  @ Not many, largely because it is so foul to do!  Firstly, that is@ only ONE example of when you need to do that (I gave you several? others, that are far more widespread).  Secondly, once you havee= broken the type system EVEN IN A CONTROLLED WAY, you have theI: problems of unchecked code - this is provably unavoidable.  B Back in the 1970s, code-generation errors (the most common problemA of this class) were usually investigated and resolved.  Nowadays,h@ they are normally bypassed when discovered, which mean that they@ remain lurking in wait.  This is NOT how to achieve reliability.: And problems with exception handling are much, much worse.  > 80% of the reason for the change is that it has become so much? more difficult to investigate the damn things.  Some of this isr@ because of the more complex ISAs, but another aspect is the fact? that the debugging tools are so much worse at handling problemsS BELOW the source level.e  > This means that instead of 30% of programmers being capable of@ tying down a problem enough to report it, perhaps 0.3% are.  AndB instead of 99% of such problems being locatable by the implementorA for reasonable effort, perhaps 90% are.  So such bugs accumulate.s     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679    ------------------------------   Date: 3 Sep 2001 07:00:19 -0500g- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: I hate Compaq3 Message-ID: <4EZe7kdKZFci@eisner.encompasserve.org>o   In article <y4ofosfz7i.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>, Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:  P > An ounce of prevention...that is, use strongly-typed languages, and write your( > run-time support in the same language.  F Note that the DEC SVS A1 virtual monitor system (that never made it toD market) was written in Pascal in order to allow the security proofs.B The software running under that was ordinary VMS (the only OS theyD tried).  To me this proves that writing lower level code in a higher level language is quite viable.m  A (For those who don't remember, the project was cancelled when DECe@ marketing discovered that the market for A1 systems was not what% they had thought it was going to be.)s   ------------------------------   Date: 3 Sep 2001 07:09:47 -0500x- From: Kilgallen@SpamCop.net (Larry Kilgallen)e Subject: Re: I hate Compaq3 Message-ID: <MEcC74hE5brG@eisner.encompasserve.org>b  [ In article <9mvin5$csa$1@pegasus.csx.cam.ac.uk>, nmm1@cus.cam.ac.uk (Nick Maclaren) writes:n > 2 > In article <9mvgo1$b87$1@pegasus.csx.cam.ac.uk>,, > nmm1@cus.cam.ac.uk (Nick Maclaren) writes: > |> oB > |> ....  And you might be surprised to know that some 30% of theG > |> nasty problems that I hit are actually code-generation errors ....t > - > Damn.  Omitted phrase.  I should have said:b > ? > And you might be surprised to know that some 30% of the nastyM? > problems that I hit, which can be made to go away by reducing-8 > optimisation, are actually code-generation errors ....  ; If 30% of nasty problems can be made to go away by reducingF9 optimization, you indeed have compiler problems.  I doubt6: this is consistent across all compiler vendors.  (The fact8 that I have not encountered this level on any particular7 compiler doesn't prove much, since the software I writee is different from yours.)c   ------------------------------   Date: 3 Sep 2001 07:06:47 -0500a- From: Kilgallen@SpamCop.net (Larry Kilgallen)t Subject: Re: I hate Compaq3 Message-ID: <wwts+laPieHu@eisner.encompasserve.org>2  [ In article <9mvgo1$b87$1@pegasus.csx.cam.ac.uk>, nmm1@cus.cam.ac.uk (Nick Maclaren) writes:eJ > In article <y4ofosfz7i.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>,K > Jan Vorbrueggen  <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:2  H > The run-time support includes the garbage collector, which it is well-H > known involves breaking type rules (in general).  A few, VERY limited,E > garbage collectors can be written without doing that, but not most.k  @ I know of no garbage collector in VMS other than that inside theA Java Virtual Machine.  Certainly nothing in the operating system.m  B > The last point is that using a bulletproof language is currentlyF > incompatible with getting maximal performance - I believe that isn't> > a theoretical limit, but lost that argument a long time ago.  A Certainly extra checks use some cycles.  A typical approach is tosE perform initial tests without disabling checking, and then to disablesA checking in performance-sensitive areas (if testing shows it buyss? you anything).  The idea of choosing where to disable checks isgB far superior to just choosing a language that never checks at all.   ------------------------------   Date: 3 Sep 2001 12:12:19 GMT ( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: I hate Compaq0 Message-ID: <9mvs33$ls8$1@pegasus.csx.cam.ac.uk>  c In article <4EZe7kdKZFci@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:  |> In article <y4ofosfz7i.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>, Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:e |> aS |> > An ounce of prevention...that is, use strongly-typed languages, and write yourh+ |> > run-time support in the same language.i |> uI |> Note that the DEC SVS A1 virtual monitor system (that never made it to G |> market) was written in Pascal in order to allow the security proofs.hE |> The software running under that was ordinary VMS (the only OS they G |> tried).  To me this proves that writing lower level code in a higherl" |> level language is quite viable.  B You will have found that there was a small library that was not inB Pascal, or there was a set of extensions that allowed the rules toD be broken.  This is exactly how the CHAOS project worked (one of theB earliest operating systems to be written almost entirely in a high level language).  @ The low-level problems are therefore much reduced and localised,? which is definitely good, but they are NOT resolved.  And, as I > have repeatedly said, the most common problem of this class is? investigating code-generation errors in the high level languageb you are using.  A Back in the 1960s, there was indeed a myth that such things couldh< not be written in a high-level language, but CHAOS and other> projects showed that was false in the 1970s.  However, ANOTHER= myth developed in the 1980s that such things could be writteni@ ENTIRELY in a high-level language, and it is that myth that I am
 referring to.e  ? If I were in charge of a major operating system and/or languageiA system project, then I quite agree that I would want a high-level @ language for programming it in.  99% or more of it, if possible.= But, firstly, there is always that 1% and, secondly, there iso; always the problem of code-generation errors unless the ISA' itself provides the checking.      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: 3 Sep 2001 12:18:09 GMTi( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: I hate Compaq0 Message-ID: <9mvse1$m6g$1@pegasus.csx.cam.ac.uk>  c In article <wwts+laPieHu@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: ^ |> In article <9mvgo1$b87$1@pegasus.csx.cam.ac.uk>, nmm1@cus.cam.ac.uk (Nick Maclaren) writes:M |> > In article <y4ofosfz7i.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>,aN |> > Jan Vorbrueggen  <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote: |>  K |> > The run-time support includes the garbage collector, which it is well- K |> > known involves breaking type rules (in general).  A few, VERY limited, H |> > garbage collectors can be written without doing that, but not most. |> hC |> I know of no garbage collector in VMS other than that inside thecD |> Java Virtual Machine.  Certainly nothing in the operating system.  C Where did I say that it had to be?  I am referring here to languagegE run-time systems, which are not usually part of the operating system, 1 though C's and Unix are rather horribly entwined.u  E |> > The last point is that using a bulletproof language is currentlytI |> > incompatible with getting maximal performance - I believe that isn'tgA |> > a theoretical limit, but lost that argument a long time ago.K |>  D |> Certainly extra checks use some cycles.  A typical approach is toH |> perform initial tests without disabling checking, and then to disableD |> checking in performance-sensitive areas (if testing shows it buysB |> you anything).  The idea of choosing where to disable checks isE |> far superior to just choosing a language that never checks at all.l  ? And when there is a problem in a massive program that will onlyn0 just run with such optimisation, what do you do?     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 334679u   ------------------------------   Date: 3 Sep 2001 07:18:02 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: I hate Compaq3 Message-ID: <uJFfr6LfuCiB@eisner.encompasserve.org>w  [ In article <9mvpbq$j42$1@pegasus.csx.cam.ac.uk>, nmm1@cus.cam.ac.uk (Nick Maclaren) writes:m  D > Back in the 1970s, code-generation errors (the most common problemC > of this class) were usually investigated and resolved.  Nowadays, B > they are normally bypassed when discovered, which mean that theyB > remain lurking in wait.  This is NOT how to achieve reliability.< > And problems with exception handling are much, much worse.  D Some people are too lazy to fill out problem reports for the vendor, but many are not.   @ > 80% of the reason for the change is that it has become so muchA > more difficult to investigate the damn things.  Some of this islB > because of the more complex ISAs, but another aspect is the factA > that the debugging tools are so much worse at handling problemsv > BELOW the source level.n  D On VAX and Alpha, debugging at the instruction level is no differentC than debugging assembly language code for the processor in use.  It3D may be the case thet _programmers_ are less likely to understand theD assembly language for the processor.  Understanding how the compilerC uses that assembly language is another issue, but this is not a bug< in the _debugger_.  ? Of course if you expect a debugger to help someone who does not A understand the instruction set debug at that level, you have much>- greater hopes for what is possible than I do.n   ------------------------------   Date: 3 Sep 2001 12:25:05 GMTr( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: I hate Compaq0 Message-ID: <9mvsr1$mnv$1@pegasus.csx.cam.ac.uk>  3 In article <MEcC74hE5brG@eisner.encompasserve.org>,e/ Kilgallen@SpamCop.net (Larry Kilgallen) writes:i |> > aB |> > And you might be surprised to know that some 30% of the nastyB |> > problems that I hit, which can be made to go away by reducing; |> > optimisation, are actually code-generation errors ....- |> a> |> If 30% of nasty problems can be made to go away by reducing< |> optimization, you indeed have compiler problems.  I doubt= |> this is consistent across all compiler vendors.  (The facth; |> that I have not encountered this level on any particular:: |> compiler doesn't prove much, since the software I write |> is different from yours.)  > Quite.  I am enough of a language expert and write good enough; code (including with internal checking) that relatively fewv: problems in the code reach the stage of being nasty.  When< looking at other people's code, I am referring to only those; that I can localise enough to investigate, as it is clearlya7 impossible to classify ones that can't be investigated.s  = This is consistent across almost every compiler vendor of therA many dozens (perhaps more) that I have used over several decades,pA except for the "IBM PC" ones where the 30% is often 90%.  A very, ) very few vendors do significantly better.y  ? I have not used VMS or Tru64 seriously in some time, but it wase= certainly true of the latter when I did, and I have reason toh< believe that most of the problems I hit are still present inA its compilers.  The reasons that I didn't pursue them with (then)l? DEC were not primarily DEC's fault, but were beyond my control.n     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: Mon, 03 Sep 2001 14:28:53 +0200s* From: Alexis Cousein <al@brussels.sgi.com> Subject: Re: I hate Compaq/ Message-ID: <3B937785.1010702@brussels.sgi.com>    Bill Todd wrote:E > The phrase I've heard, from multiple sources, is that the OSs were o5 > *running* in a *Marvel* (and/or MP) configuration. u  A Of course, if that's running, but at 300MHz, that's *also* a long C way from commercial deployment ;). Most benchmark figures I've seenMB from Q are still EV6x based (even in situations where you'd expect@ prospects to be interested in EV7), so there are either few EV7s> or they aren't particularly fast compared to current EV6x yet.  7 [Granted, I'm only in a little backwater, i.e. Belgium]h -- >? <these messages express my own views, not those of my employer>>) Alexis Cousein				Senior Systems Engineery. SGI Belgium and Luxemburg		al@brussels.sgi.com   ------------------------------  $ Date: Mon, 3 Sep 2001 10:02:38 -0400' From: "Bill Todd" <billtodd@foo.mv.com>t Subject: Re: I hate Compaq( Message-ID: <9n02gb$7js$1@pyrite.mv.net>  7 "Alexis Cousein" <al@brussels.sgi.com> wrote in messagea) news:3B937785.1010702@brussels.sgi.com...e > Bill Todd wrote:F > > The phrase I've heard, from multiple sources, is that the OSs were6 > > *running* in a *Marvel* (and/or MP) configuration. >cC > Of course, if that's running, but at 300MHz, that's *also* a longl$ > way from commercial deployment ;).  K A situation with which Itanic is of course well-acquainted, since in a realfK sense it's *still* a long way from commercial deployment (and will be untilh McKinley ships).  !  Most benchmark figures I've seensD > from Q are still EV6x based (even in situations where you'd expectB > prospects to be interested in EV7), so there are either few EV7s@ > or they aren't particularly fast compared to current EV6x yet.  D I wasn't suggesting anything close to benchmarking readiness, simplyC reflecting that the hardware was reportedly considerably beyond thehJ first-OS-boot stage that was referred to in the post to which I responded.   - bill   >t9 > [Granted, I'm only in a little backwater, i.e. Belgium]w > --A > <these messages express my own views, not those of my employer> ( > Alexis Cousein Senior Systems Engineer/ > SGI Belgium and Luxemburg al@brussels.sgi.com  >e   ------------------------------    Date: 03 Sep 2001 16:10:26 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>s Subject: Re: I hate CompaqH Message-ID: <y4elpo74bx.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  * nmm1@cus.cam.ac.uk (Nick Maclaren) writes:  F > Fractionally worse, yes, but one real advantage is that the facilityA > does not involve making the code segment writable, with all the . > problems that entails, however it is done.    I What problem? You call the OS to make the code pages writeable, patch thedF code, and call the OS to make the pages read-only again. What problem?  1 > Have you ever used a system with this facility?a  G What facility? One that uses the patching process? Yes. One that uses aa( virtual machine? Yes. Or something else?  B > Not many, largely because it is so foul to do!  Firstly, that isB > only ONE example of when you need to do that (I gave you several) > others, that are far more widespread). A  I Really? I can't remember. You said one needs a garbage collector which byeL necessity breaks type safety, which I proposed as a solution to writing bug-C reduced code. What else in the run-time support breaks type safety?    > Secondly, once you haven? > broken the type system EVEN IN A CONTROLLED WAY, you have thee< > problems of unchecked code - this is provably unavoidable.  E No, the code is now checked by the human writer who has to state verysL explicitly what she is doing, and thus is likely to avoid the usual pitfalls of type-unsafe languages.s  @ Oh, you want provably bug-free code? Sorry, you can't have that.  D > Back in the 1970s, code-generation errors (the most common problemC > of this class) were usually investigated and resolved.  Nowadays,e, > they are normally bypassed when discovered  J I have rarely seen that. I have discovered my share of them, and they have been corrected.n  @ > 80% of the reason for the change is that it has become so muchA > more difficult to investigate the damn things.  Some of this iseB > because of the more complex ISAs, but another aspect is the factA > that the debugging tools are so much worse at handling problemsm > BELOW the source level.p  G Really? I can still use many debuggers and step through the code at thepJ instruction level, with full support for looking at variables, registers, H and so on. I believe even NS DevStudio supports this. This is worse than line-at-a-time DDT?e   	Jan   ------------------------------    Date: 03 Sep 2001 16:13:40 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>  Subject: Re: I hate CompaqH Message-ID: <y4bsks746j.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  , Alexis Cousein <al@brussels.sgi.com> writes:  " > Most benchmark figures I've seenD > from Q are still EV6x based (even in situations where you'd expectB > prospects to be interested in EV7), so there are either few EV7s@ > or they aren't particularly fast compared to current EV6x yet.  J Most serious benchmarks require an announced shipping date in the not-too-I distant future. From current Compaq roadmaps, it's quite clear that stage  hasn't yet been reached.   	Jan   ------------------------------   Date: 3 Sep 2001 14:31:06 GMT ( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: I hate Compaq/ Message-ID: <9n047a$8j$1@pegasus.csx.cam.ac.uk>o   In article <y4elpo74bx.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>, Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:- |> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:- |> aI |> > Fractionally worse, yes, but one real advantage is that the facilitynD |> > does not involve making the code segment writable, with all the1 |> > problems that entails, however it is done.  c |> mL |> What problem? You call the OS to make the code pages writeable, patch theI |> code, and call the OS to make the pages read-only again. What problem?:  C You then discover that another user's program using the same binaryfA falls over.  Oops.  So you mark the page copy-on-write first, andr@ discover that the system is using lazy loading.  Curses.  So youB force immediate loading, and discover that you need then to copy aB dynamic library.  Hell.  So you copy that, and sometimes find thatA you have broken source-specific authorisation.  Or you run out of ' swap.  Or you run out of address space.r  1 I have seen all of those.  There isn't a problem?l  4 |> > Have you ever used a system with this facility? |> sJ |> What facility? One that uses the patching process? Yes. One that uses a+ |> virtual machine? Yes. Or something else?   ? You are being far too snippy.  Here is the context you removed:-  D     As a specific reply to your question, a good solution here (wellD     proven, too) is to have a flag on the page tables that forces anI     interrupt.  Combined with the (also proven) technique of lightweight,,L     context-preserving interrupts, this would ve bery useful and very cheap.  A Think lightweight, context-preserving interrupts, as on the Titana and other systems.  E |> > Not many, largely because it is so foul to do!  Firstly, that isbE |> > only ONE example of when you need to do that (I gave you several(, |> > others, that are far more widespread).  |> cL |> Really? I can't remember. You said one needs a garbage collector which byO |> necessity breaks type safety, which I proposed as a solution to writing bug-tF |> reduced code. What else in the run-time support breaks type safety?  @ I really do suggest checking back in a thread before flaming.  IB mentioned the signal and exception handling (including such thingsE as long jumping), but said that the most common one was investigating  code generation errors.s  C |> > 80% of the reason for the change is that it has become so muchsD |> > more difficult to investigate the damn things.  Some of this isE |> > because of the more complex ISAs, but another aspect is the factuD |> > that the debugging tools are so much worse at handling problems |> > BELOW the source level. |>  J |> Really? I can still use many debuggers and step through the code at theM |> instruction level, with full support for looking at variables, registers, eK |> and so on. I believe even NS DevStudio supports this. This is worse thanl |> line-at-a-time DDT?  B Sometimes.  A large number of those will work in all simple cases,C but fail more-or-less horribly in the nastier ones that are typicale? of low-level problems, such as signal handling.  Furthermore, a @ lot of them will do so far more reliably when the program is run' under them than when looking at a dump.   B But, as all experienced support people know, it is relatively rare@ that a nasty problem is sufficiently easy to repeat that you canA try out a program under the debugger until you have first located.@ the approximate cause from a dump, the logs or whatever.  And it= is for that stage where you want a reliable debugging system.e     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 334679w   ------------------------------  # Date: Mon, 03 Sep 2001 16:11:47 GMTe+ From: Anne & Lynn Wheeler <lynn@garlic.com>  Subject: Re: I hate Compaq) Message-ID: <upu98b6eq.fsf@earthlink.net>r  / Kilgallen@SpamCop.net (Larry Kilgallen) writes:s > H > Note that the DEC SVS A1 virtual monitor system (that never made it toF > market) was written in Pascal in order to allow the security proofs.D > The software running under that was ordinary VMS (the only OS theyF > tried).  To me this proves that writing lower level code in a higher! > level language is quite viable.s > C > (For those who don't remember, the project was cancelled when DEChB > marketing discovered that the market for A1 systems was not what' > they had thought it was going to be.)t  E I did something different. All of the CP virtual machine kernel (bothmB CP/67, VM/370, etc) was written in assembler. Some of the services9 were questionably actually needed in the low-level kernelm< ... especially for security reasons like much of unit record= simulation and the corresponding spooling infrastructure (akai? effectively standard CP kernel already provided virtual monitord? infrastructure that made a number of security-related paradigms7
 standard).  D I rewrote the spooling infrastructure in Pascal running in a virtualC machine address space with upcalls out of the kernel into the spoolIA machine to handle unit record/spool operations on behalf of othern virtual machines.e  F The original purpose (of the effort) was to improve the performance ofE the spooling infrastructure by at least an order of magnitude for theaB HSDT (high-speed data transport) project i.e. turns out that local9 node network support depended extensively on the spoolinggA infrastructure (which had become the major thruput bottleneck for = high-speed network operations). The objective was an order of C magnitude performance improvement ... even taking into account thatA> assembler code was being replaced with Pascal and the code was; migrated out of the kernel into virtual address space (both 3 introducing numerous kinds of additional overhead).   C Basically, a number of things were done (none of them that couldn'tiB really have been done with kernel assembler code) 1) semantics for> asyncronous spool I/O interface was implementated, 2) numerous< sequential search operations were replaced with "tree-based"B operations, 3) spool records were enhanced to signficantly improveF availability and recoverability, 4) kernel was insulated from numerousD kinds of spool related errors that previously would have resulted in system failure.y  @ this was deployed on parts of the internal network (the internalB network was larger than the whole internet/arpanet for much of its
 lifetime).   hsdt, networking a4 http://www.garlic.com/~lynn/subtopic.html#networking( http://www.garlic.com/~lynn/internet.htm  ) misc hsdt & spool file rewrite discussiongK http://www.garlic.com/~lynn/94.html#22 CP spooling & programming technologyrK http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technologyaK http://www.garlic.com/~lynn/94.html#25 CP spooling & programming technology G http://www.garlic.com/~lynn/94.html#31 High Speed Data Transport (HSDT)kH http://www.garlic.com/~lynn/94.html#33a High Speed Data Transport (HSDT)H http://www.garlic.com/~lynn/94.html#33b High Speed Data Transport (HSDT)b http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional lifeb http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life? http://www.garlic.com/~lynn/99.html#34 why is there an "@" key?oO http://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model?yN http://www.garlic.com/~lynn/99.html#201 Middleware - where did that come from?q http://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)oA http://www.garlic.com/~lynn/2000b.html#69 oddly portable machines Y http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?oK http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)t- http://www.garlic.com/~lynn/2000f.html#31 OT? 7 http://www.garlic.com/~lynn/2001.html#72 California DMVdB http://www.garlic.com/~lynn/2001c.html#66 KI-10 vs. IBM at RutgersV http://www.garlic.com/~lynn/2001e.html#64 Design (Was Re: Server found behind drywall)K http://www.garlic.com/~lynn/2001f.html#11 Climate, US, Japan & supers queryel http://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompuq http://www.garlic.com/~lynn/2001g.html#29 any 70's era supercomputers that ran as slow as today's supercomputers?pB http://www.garlic.com/~lynn/2001h.html#13 VM: checking some myths.> http://www.garlic.com/~lynn/2001h.html#29 checking some myths.V http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?6 http://www.garlic.com/~lynn/2001i.html#31 3745 and SNId http://www.garlic.com/~lynn/2001i.html#41 Withdrawal Announcement 901-218 - No More 'small machines'v http://www.garlic.com/~lynn/2001i.html#52 misc loosely-coupled, sysplex, cluster, supercomputer, & electronic commerce   -- sH Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/    ------------------------------    Date: 03 Sep 2001 12:03:54 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>o; Subject: Re: Intel announces IA-64 "HyperThreading" in 2002nH Message-ID: <y43d64fv5h.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  " John Santos <JOHN@egh.com> writes:  G > > Just to put things in an historical perspective the CDC 6000 series A > > designed by Seymour Cray around 1965 also had this capabilitygH > Couldn't the VAX 11/780 do this too?  And maybe even the PDP 11/45 FPU% > (only about 8 years after Cray...)?   + No, the 780 was very much single-threaded. o   	Jan   ------------------------------  % Date: Mon, 03 Sep 2001 07:24:06 -0400i- From: Jack Patteeuw <jjpatteeuw@peoplepc.com>n; Subject: Re: Intel announces IA-64 "HyperThreading" in 2002y, Message-ID: <3B936856.A6F34024@peoplepc.com>   Dean Woodward wrote:  ? > Hyperthreading, as implemented, exists in the Pentium 4 line.i= > It's a weak second to SMT.  With HT, as I understood it, ifr@ > 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.    Q As implemented in the Pentium 4 it may not be able to do two FP or integer ops atl once !  S As mentioned by others this is not a new idea.  Many of the PowerPC processors from  Moto eT and IBM (5xx and 6xx for sure) do the same trick.  Plans were (are/already have beenP implemented ?) for multiple integer and FP units.  The trick, of course, is data dependency.0  U Also what do you do after you get a floating point exception after you have completed L the next 10 integer instructions.  If your in hard real time, you rewind !!!    
 Jack Patteeuws   ------------------------------  % Date: Tue, 04 Sep 2001 00:12:14 +0930g% From: Jeremy Begg <jeremy@vsm.com.au>i< Subject: Re: KZCCA-CB problems (UltraSCSI adapter for VAXes)* Message-ID: <3B9396C6.30875190@vsm.com.au>   Hi John,  J >         I am trying to install a KZCCA-CB  adapter into VAX4000-705A andC >         am having difficulty trying to get the 100MB NIC working.i  ; I too am having "fun" with this device, in a VAX 4000-600A.y  G >         I have installed the Intraserver software ( VAXSCSI_016 ) kitnC >         and the PKWdriver seems to be running for the FWDiff portE> >         but am unable to get DECNET or TCPIP to see the EWA0) >         device.The VMS version is V7.1.S  I The VAX_SCSI016 kit explicitly points out that the Ethernet port on these:N cards is not supported.  We ended up using the VAX_SCSI015 kit from the CD-ROM) because it gave slightly better  results.3  N We're having a slightly different problem.  After two long days we finally gotH it running, in a VAX 4000-600A running OpenVMS V7.2.  We installed it toL connect an RA3000 subsystem.  The problem we have is that the device doesn'tL appear to work unless the VAX is power-cycled after being shut down.  To putL it another way, we can't reboot the VAX without turning it off.  If we don'tK turn the VAX off the CONFIG_PCI program doesn't see any devices on the SCSIi' bus (and takes a *long* time to do so).s   Has anyone seen this behaviour?e  I Also, the CD-ROM supplied with the card contains files which implies it'stL possible to boot from devices on the SCSI bus -- provided you use the CD-ROMN to perform a console ROM upgrade first.  Does anyone have any tips or warnings about this process?   N And one more question, what's the relationship between Nemonix & Intraserver? M The device is described by the installation manual as an Intraserver product, G but the board itself and the CD-ROM have Nemonix written all over them.s  > Replies direct to the email address below, if at all possible.   Thanks,n           Jeremy Beggn  =   +---------------------------------------------------------+-=   |             VSM Software Services Pty. Ltd.             | =   |                  http://www.vsm.com.au/                 |:=   |        "OpenVMS Systems Management & Programming"       |m=   |---------------------------------------------------------|w=   | P.O.Box 402, Walkerville, |  E-Mail:  jeremy@vsm.com.au |t=   | South Australia 5081      |   Phone:  +61 8 83592155    |i=   |---------------------------|  Mobile:  0414 422 947      |n=   |  A.C.N. 068 409 156       |     FAX:  +61 8 82231777    |i=   +---------------------------------------------------------+d   ------------------------------  $ Date: Mon, 3 Sep 2001 00:25:52 -0700* From: "Welsh, John" <John.Welsh@Avnet.com> Subject: KZCCA-CB problems.tG Message-ID: <FD833ACB0214D511B9B20004ACC5766B0108D2BA@asia01.avnet.com>   J This message is in MIME format. Since your mail reader does not understand< this format, some or all of this message may not be legible.  ' ------_=_NextPart_001_01C13449.A9BC6E40b Content-Type: text/plain     Hi Gang, 	wB 	I am trying to install a KZCCA-CB  adapter into VAX4000-705A and : 	am having difficulty trying to get the 100MB NIC working.  4 	The card is a Compaq product and is manufactured by
 	Intraserver.e  > 	I have installed the Intraserver software ( VAXSCSI_016 ) kit: 	and the PKWdriver seems to be running for the FWDiff port5 	but am unable to get DECNET or TCPIP to see the EWA0e  	device.The VMS version is V7.1.   	Any help would be appreciated.    John Welsh. 
 ========== john.welsh@avnet.com            ' ------_=_NextPart_001_01C13449.A9BC6E40e Content-Type: text/html9+ Content-Transfer-Encoding: quoted-printablep  1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">d <HTML> <HEAD>9 <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =a charset=3Dus-ascii">@ <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
 5.5.2654.19">e! <TITLE>KZCCA-CB problems.</TITLE>a </HEAD>s <BODY> <BR>  0 <P><FONT SIZE=3D2 FACE=3D"Arial">Hi Gang,</FONT>1 <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20n? <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =wE FACE=3D"Arial">I am trying to install a KZCCA-CB&nbsp; adapter into =  VAX4000-705A and </FONT>? <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =pA FACE=3D"Arial">am having difficulty trying to get the 100MB NIC =e working.</FONT>p </P>  > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =A FACE=3D"Arial">The card is a Compaq product and is manufactured =a	 by</FONT>e? <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =:" FACE=3D"Arial">Intraserver.</FONT> </P>  > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =H FACE=3D"Arial">I have installed the Intraserver software ( VAXSCSI_016 = ) kit</FONT>? <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =bE FACE=3D"Arial">and the PKWdriver seems to be running for the FWDiff =r port</FONT>t? <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 = @ FACE=3D"Arial">but am unable to get DECNET or TCPIP to see the = EWA0</FONT> ? <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 = 5 FACE=3D"Arial">device.The VMS version is V7.1.</FONT>  </P>  > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =4 FACE=3D"Arial">Any help would be appreciated.</FONT> </P>  3 <P><FONT SIZE=3D2 FACE=3D"Arial">John Welsh.</FONT>rG <BR><FONT SIZE=3D2 FACE=3D"Arial">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>r= <BR><FONT SIZE=3D2 FACE=3D"Arial">john.welsh@avnet.com</FONT>n </P> <BR> <BR> <BR> <BR>   </BODY>, </HTML> ) ------_=_NextPart_001_01C13449.A9BC6E40-->   ------------------------------  $ Date: Mon, 3 Sep 2001 08:42:47 +01005 From: "Steeples, Oliver" <Oliver.Steeples@compaq.com>W Subject: RE: KZCCA-CB problems.aP Message-ID: <F498D199EDB12D468CD2C66680D3080101DDE598@reoexc04.emea.cpqcorp.net>  @ http://www.compaq.com/products/quickspecs/10358_ca/10358_ca.htmlC <http://www.compaq.com/products/quickspecs/10358_ca/10358_ca.html>     I As far as I can remember the KZCCA network bit isn't supported by Compaq,i. only the ultrascsi.  I could be wrong however.  d
     Oliver   -----Original Message-----/ From: Welsh, John [mailto:John.Welsh@Avnet.com]m( Sent: Monday, September 03, 2001 8:26 AM To: Info-VAX@Mvb.Saic.Comr Subject: KZCCA-CB problems.         	 Hi Gang, e         I         I am trying to install a KZCCA-CB  adapter into VAX4000-705A and  B         am having difficulty trying to get the 100MB NIC working.   <         The card is a Compaq product and is manufactured by          Intraserver.    F         I have installed the Intraserver software ( VAXSCSI_016 ) kit B         and the PKWdriver seems to be running for the FWDiff port =         but am unable to get DECNET or TCPIP to see the EWA0  (         device.The VMS version is V7.1.   '         Any help would be appreciated. o   John Welsh.  ========== t john.welsh@avnet.com l   ------------------------------  % Date: Mon, 03 Sep 2001 14:25:50 +0300 & From: Guy Peleg <guy.peleg@compaq.com>( Subject: Re: My VMS Wish List (features)* Message-ID: <3B9368BE.277F61BD@compaq.com>   David,  I I'm the DCL maintainer, some of the features you requested should be verys easy to I implement. Out of curiosity, why do you need the $CREATE/MAILBOX comand ?h  A We will discuss your sugesstions internally and will update soon.o   Regards,  	 Guy Pelegd OpenVMS Engineeringi   "David J. Dachtera" wrote:  I > In case I'm wrong, and VMS does survive, here's a list of features that F > I think could be useful in OpenVMS-IA64 (and maybe backported to the. > last supported OpenVMS-Alpha and/or -VAX)... > G > Hoff - if you're out there, should I e-mail these to your personally?r >e
 > Facilities:  >h > LibrarianmI >         Add support for .CLBs (Command procedure Libraries - see below)  >> > DCL: > $ > Additional/enhanced functionality:- > - Add support for floating point datatypes. C > - Add support for .CLBs (Command procedure Libraries - see below) 0 > - Add support for "long" strings (>1024 bytes) >t) > Additional/enhanced Verbs and Keywords:l >l > CREATE/MAILBOX logical_name & >         /PERMANENT (requires PRMMBX)I >         /TEMPORARY (requires TMPMBX, assigns a channel stored in globalt+ >         symbol DCL$MBX_CHAN_logical_name)  >         /BUFFER_QUOTA=valueaI >         /SYMBOL - returns mailbox device specification in global symbol  >         DCL$MBX_ID >c > DELETE/MAILBOX logical_nameoB >         Requires PRMMBX or TMPMBX, as appropriate. For temporary6 >         mailbox, requires the value of global symbol8 >         DCL$MBX_CHAN_logical_name from CREATE/MAILBOX. >  > ENQUEUE lock_name/qualifiers >         /EXCLUSIVE >         /READ_ONLY >g	 > RELEASEh1 >         /LOCK lock_name Releases the named lockxF >                 /DEQUEUE        Dequeues the lock request if not yet* >                                 granted.> >         /ENTRY entry_number (identical to SET ENTRY/RELEASE) >  > INCLUDE {filespec|pathspec}bH >         Processes a specified command procedure segment at the current >         depth.; >         Reasoning: see description of F$DECLARE(), below.a- >         Supports CDD/Repository (/FROM=CDD)&I >         Supports Command procedure Libraries (/FROM=LIBRARY[=filespec],u4 >         default = source library of current depth) >r > @{filespec|pathspec}5 >         Add support for Command procedure LibrariestH >         (/FROM=LIBRARY[=filespec], default = source library of current >         depth)4 >         Add support for CDD/Repository (/FROM=CDD), >         Add support for /ENTRY_POINT=label >a
 > SET HOSTH >         Add support for SYS$INPUT pointing to other than a terminal to3 >         RTPAD, LTPAD, DTEPAD, HSCPAD, all others.w8 >         Add support for /INPUT={filespec|pathspec} and( >         /FROM={CDD,LIBRARY[=filespec]}E >         Restore support for /SCSI (restore HSZTERM$SCSIPAD to fullym >         supported status)V >7J > Modify READ so that /TIMEOUT works with devices other than terminals, or- > at least with both mailboxes and terminals.e >l8 > Modify READ to work with keys set up using DEFINE/KEY. >a > SET [NO]ARROW_KEYSC >         Allows cursor control key sequences to be received by DCLpJ >         procedures via INQUIRE and READ. When NOARROW_KEYS is in effect,; >         cursor keys may set up using DEFINE/KEY to returnu! >         user-specified strings.l >a > SHOW ARROW_KEYS  >h* > Lexical Function Additions/Enhancements: >h > F$GETJPI()H > Add keyword ARROW_KEYS to accompany enhanced commands above (boolean). >r* > F$GETENV( symbol_name ) (not privileged)G > Doument this function and provide support for any variable defined in J > the console environment. Return $STATUS as %x00008140 if symbol does not > exist. >o& > F$SETENV( symbol_name ) (privileged)C > Support for any user-writeable symbol in the console environment.b8 > Return $STATUS as %x00008140 if symbol does not exist. >  > F$LOCK( lock_id, keyword )6 > Alternative to ENQUEUE and RELEASE/DEQUEUE commands. > - Keywords (list supported)a >         DEQUEUE  >         ENQUEUEt >         EXCLUSIVEi >         READ_ONLYp >         RELEASEc > " > F$SYMBOL( symbol_name, keyword )
 > - Keywords:l7 >         DEPTH   - Procedure depth at which symbol was'& >                   created/F$DECLAREd( >         EXISTS  - Return TRUE or FALSED >         SIZE    - Returns length of string or size of integer/real >                   (numeric) + >         TABLE   - Returns LOCAL or GLOBALrH >         TYPE    - Returns STRING or INTEGER or REAL (same as F$TYPE())C >         VALUE   - Returns the contents of the symbol, always as ap >                   string >         others...y > = > F$PROCEDURE( depth ) or F$ENVIRONMENT( "PROCEDURE", depth )lH > - Returns filespec. of the command procedure at a specified depth (may" > be other than the current depth) >w > F$FAB( lnm, keyword )c3 > - lnm is logical name specified in OPEN statementt: > - Keywords: FILESPEC, CHANNEL, others that may be usefulF >   (and not otherwise be available, such as from F$FILE_ATTRIBUTES()) >/ > F$RAB( lnm, keyword )h3 > - lnm is logical name specified in OPEN statementw
 > - Keywords:lA >         RECOUNT - returns the byte count from the last transferrF >                   (useful for determining whether DCL can manipulate0 >                   the string (record) read in)D >         RRN     - Returns the relative record number of the record6 >                   from the most recent READ or WRITE? >                   (Sequential or Relative; Indexed may return/2 >                   unpredictable value (garbage))D >         RFA     - Returns the three-byte integer value in a string+ >         other keywords that may be usefulw >g > F$GETSYI() > - Add keywords:iF >         UPTIME  - Returns the current system up-time as a delta time' >                   expression (string)? >         FREE_LIST_SIZEE >                 - Returns the current size of the free page list as  >                   an integer >         MOD_LIST_SIZElF >                 - Returns the current size of the modified page list! >                   as an integere >m > F$COUNT( keywords, mode )o > - KeywordsJ >         USERS           - Returns the current count of users as would be3 >                           displayed by SHOW USERS#E >         PROCESSES       - Returns the current count of processes as ; >                           would bedisplayed by SHOW USERSiH > - Mode (supports list of modes, counts returned are cumulative for all > list elements) >         [NO]BATCHu >         [NO]INTERACTIVE/ >         [NO]NETWORK  >         [NO]OTHERr >         [NO]SUBPROCESS > 2 > F$DECLARE( symbol_name, data_type, size, table ) > - Data typesA >         STRING (static only, dynamic strings are still assignedw  >                 traditionally) >         SIGNED[_INTEGER] >         UNSIGNED[_INTEGER] >         REAL > - Size (numeric)H >         Size in bytes of a static string (any legal value for a static >         string descriptor)J >         Size in bytes of a binary datatype corresponding to a field size2 >         supported by the underlying architecture >         or math RTL.	 > - Tablen >         GLOBAL >         LOCALd >y& > F$FORMAT( symbol_name, edit_string )D > - DCL interface to the BAS$FORMAT() built-in function RTL routine. >w > F$TERMCAP( keyword )C > Returns escape sequences or values. Keywords as per SMGTERMS.TXT.r > 0 > I'm sure there's more that I could think of... >i > -- > David J. DachteraI > dba DJE Systems4 > http://www.djesys.com/ >e* > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/S   ------------------------------   Date: 3 Sep 2001 07:23:09 -0500a- From: Kilgallen@SpamCop.net (Larry Kilgallen)d( Subject: Re: My VMS Wish List (features)3 Message-ID: <KBbGYUogxZPB@eisner.encompasserve.org>   S In article <3B9368BE.277F61BD@compaq.com>, Guy Peleg <guy.peleg@compaq.com> writes:  > David, > K > I'm the DCL maintainer, some of the features you requested should be very 	 > easy to:K > implement. Out of curiosity, why do you need the $CREATE/MAILBOX comand ?t  > Certainly David will answer, but I think the issue is that one? can read and write mailboxes from DCL (or programs started fromi@ DCL) but the initial setup must be done with a compiled program.  : If someone wants to intercommunicate between two processes; running DCL, one must write a compiled program just for the   purpose of creating the mailbox.  ? Now _I_ don't like programs written in DCL, but _Compaq_ shouldt) like them because they sell more CPUs :-)n   ------------------------------  # Date: Mon, 03 Sep 2001 12:54:50 GMTe= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)e( Subject: Re: My VMS Wish List (features)0 Message-ID: <00A017DE.8DE585EB@SendSpamHere.ORG>  c In article <KBbGYUogxZPB@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: T >In article <3B9368BE.277F61BD@compaq.com>, Guy Peleg <guy.peleg@compaq.com> writes:	 >> David,  >> iL >> I'm the DCL maintainer, some of the features you requested should be very
 >> easy toL >> implement. Out of curiosity, why do you need the $CREATE/MAILBOX comand ? >-? >Certainly David will answer, but I think the issue is that one @ >can read and write mailboxes from DCL (or programs started fromA >DCL) but the initial setup must be done with a compiled program.J >,; >If someone wants to intercommunicate between two processes < >running DCL, one must write a compiled program just for the! >purpose of creating the mailbox.m  A There are ways to create or acquire a mailbox for DCL programmingaA communication entirely within DCL; however, the buffer/quota size A of such mailboxes is not configurable.  I believe David's request A is to gain a mechanism that is not only supported but also allows & the modification of the devices quota.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMp            nJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbeso   ------------------------------  % Date: Mon, 03 Sep 2001 12:16:45 -0500.1 From: "David J. Dachtera" <djesys.nospam@fsi.net> ( Subject: Re: My VMS Wish List (features)' Message-ID: <3B93BAFD.DBF3151C@fsi.net>w   Guy Peleg wrote: >  > David, > K > I'm the DCL maintainer, some of the features you requested should be veryn	 > easy toeK > implement. Out of curiosity, why do you need the $CREATE/MAILBOX comand ?d > C > We will discuss your sugesstions internally and will update soon.l  B As Larry and Brian noted, there is no way to create a permanent or/ otherwise persistent mailbox in DCL at present.   B There are, as Brian noted, some games that can be played to make aB temporary mailbox persist until no longer needed. DEFMBXBUFQUO andF DEFMBXMXMSG are dynamic parameters, but changing them on the fly wouldD be messy and would require privileges - I really wouldn't want a DCL/ proc. twiddling sys. param.'s like that anyway.O  G There are some processes that are just too complex to be expressed in as7 single PIPE command as some might want to attempt, IMO.y  D Thanx for your note. It's nice to know that requests do get noticed,# even if they cannot all be granted.e  G Wanna drive Andy buggy? Ask him what it would take to make BACKUP write H to or read from a mailbox or pipeline (as in PIPE-ing a saveset to stdinB of ZIP or BZIP, or vice-versa). T'would come in all kinds of handyD trying make a hobbyist's layered product distro fit on as few as two CDs.  G Larry also noted a distaste for DCL "programs". One of his major fortes-A seems to be security. Gives one pause to consider if DCL could be F "fitted" with a mechanism whereby by DCL proc.'s could be "executable" given "E" access, but not "R".   For example:  9 Proc. DO_THIS.COM belongs to [100,110] and has protection B (RWE,RWED,RE,E) (or similar security using ACL entries) and can beF executed by a process whose UIC is [300,477] with no more priv.'s thanF TMPMBX and NETMBX. That is, [300,477] being non-privileged and outsideE the owner's group can execute the proc, but SET VERIFY is ineffective E (or generates a $SEVERITY 0 (warning) error) and cannot TYPE or PRINT ( the proc. or otherwise examine the text.  * This would parallel UN*X's "x" permission.   Just a thought...g  G ...and related thought: could DCL possibly support an option to reflectf% the "line" on which an error occured?n   Example (access RE):A (Procedure attempts to OPEN a file protected against the process)gD %CLI-E-NOPRIV, insufficient privilege or object protection violationA -CLI-I-ATLINE, at line 237 in ddcu:<dir>DO_THIS.COM;17 at depth 2e   Example (access E): @ (Procedure attempts to SET VERIFY without R access to the proc.)D %CLI-W-NOPRIV, insufficient privilege or object protection violation0 -CLI-I-ATLINE, at line 1 in procedure at depth 4   -- / David J. Dachterad dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/a   ------------------------------  * Date: Mon, 3 Sep 2001 05:05:05 -0700 (PDT). From: Fabio Cardoso <fabiopenvms@yahoo.com.br> Subject: Re: OPCOM in VMS.@ Message-ID: <20010903120505.61308.qmail@web20210.mail.yahoo.com>   Just thinking ...n  / Should be good to have a way to integrate OPCOME. messages with an Instant Messaging system like2 Yahoo's or ICQ's. Not only receive OPCOM messages,6 but to give commands and run procedures and have a way- to output it in the IM system. Of course witht4 encription and all the securifty features available.. If you dont know the capabilities of the Lotus SameTime product ....a  3 If someone with development capabilities can do it.      RegardsB     FC        0 --- Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> wrote: > In article3 > <39ac55d0.0108310831.204ce45@posting.google.com>,&) > scada@cyberunlimited.org (Jeff) writes:"3 > :I received the following message from OPCOM from0 > VMS 7.1. Can anyone please > :explain it to me. > ..$ > :Message from user SYSTEM on CVHQA* > :Event: Unavailable User Buffer from:... >=202 >   You have one or more applications that are not > keeping up with theO/ >   incoming DECnet network traffic.  DECnet ise > telling you that it hase+ >   attempted to deliver a message, and the; > application was not ready. >=201 > :My Alpha Systems loses response time and slowsO > down, and these messages=20b) > :keep filling up the Operator.log File.= >=204 >   I suspect the DECnet OPCOM messages are actually > secondary to the=20A >   system performance problem.  >=20, >   You will want to identify and remove the# > performance-limiting factor(s)=2030 >   in your current configuration, using details > learned from the OpenVMS=20/0 >   performance manual.  (Assuming this is not a > simple case of no free1 >   physical memory or simular "obvious" problem,7 > remotely diagnosing aO6 >   system performance bottleneck is usually involved, > as it requires a=20-6 >   detailed performance data collection process and a > good understanding=20/' >   of the system-specific activities.)_ >=20- >   You will also want to apply the availablec > mandatory ECO kits for your 5 >   OpenVMS Alpha version -- V7.1-2 with ECOs, V7.2-1n > with ECOs, or later. >=203 >   Also check for and apply available ECOs for anyl > third-party and any=201 >   Compaq layered product packages that might bet > involved here. >=202 > :If you have any ideas please Email me directly. >=20! >   Ask here, get an answer here.i >=202 >  ---------------------------- #include <rtfaq.h> > -----------------------------d5 >       For additional, please see the OpenVMS FAQ --B > www.openvms.compaq.com   =204 >  --------------------------- pure personal opinion > ---------------------------a5 >    Hoff (Stephen) Hoffman   OpenVMS Engineering =20i > hoffman#xdelta.zko.dec.com >=20     =3D=3D=3D=3D=3D L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D  F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazilo fabiopenvms@yahoo.com.brL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D   2 __________________________________________________ Do You Yahoo!?L Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger=   http://im.yahoo.com    ------------------------------  * Date: Mon, 3 Sep 2001 04:35:26 -0700 (PDT). From: Fabio Cardoso <fabiopenvms@yahoo.com.br># Subject: OpenVMS /RDB Single Signons@ Message-ID: <20010903113526.28638.qmail@web20208.mail.yahoo.com>  * Anyone is using a Single Signon product=20) which can be integrated in OpenVMS and=20a! Oracle RDB for single signon ?=20o5 The development team need to create a web applicationI+ to access the RDB database and they want too consolidate the passwords.3 PS: The OpenVMS server dont have a web server, justm	 database.o   Regardsn       =3D=3D=3D=3D=3DsL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D- F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazilu fabiopenvms@yahoo.com.brL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D   2 __________________________________________________ Do You Yahoo!?L Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger=   http://im.yahoo.com    ------------------------------  * Date: Mon, 3 Sep 2001 04:33:47 -0700 (PDT). From: Fabio Cardoso <fabiopenvms@yahoo.com.br>  Subject: OpenVMS Products Prices@ Message-ID: <20010903113347.23276.qmail@web20205.mail.yahoo.com>  % In the Inquirer there is a news aboutB* OpenVMS products prices... 15 to 30 up ???  ' http://www.theinquirer.net/03090104.htm   0 If I understood the products became much more=20 "expensive" ?=20  6 I am sorry if I am wrong - "english misunderstanding".   Regardsl   FC=20    =3D=3D=3D=3D=3D L =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3Dl F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazil  fabiopenvms@yahoo.com.brL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D   2 __________________________________________________ Do You Yahoo!?L Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger=   http://im.yahoo.comL   ------------------------------  % Date: Mon, 03 Sep 2001 12:25:00 -0500u1 From: "David J. Dachtera" <djesys.nospam@fsi.net>f$ Subject: Re: OpenVMS Products Prices' Message-ID: <3B93BCEC.9B7BE17E@fsi.net>p   Fabio Cardoso wrote: > ' > In the Inquirer there is a news about , > OpenVMS products prices... 15 to 30 up ??? > ) > http://www.theinquirer.net/03090104.htm  > / > If I understood the products became much more  > "expensive" ?r > 8 > I am sorry if I am wrong - "english misunderstanding".   No, you got it right.t  @ Compaq just doesn't get the whole "affordable" thing, I guess...  ? Let's see now, what's their stock price down to these days... ?a   --   David J. DachteraB dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Mon, 03 Sep 2001 16:32:19 GMTs, From: peterw@u.genie.co.uk (Peter Watkinson) Subject: OVMS LicenseA7 Message-ID: <3b93b00b.12754484@news.cable.ntlworld.com>N   Hi,_    F Periodically Open VMS software comes up for sale on Ebay. Sometimes itE says that no License is included. Do you require a license to installcF and use this software or will it run just fine without a license. This is for hobbyist use only.l  	  regards,A     Peter Watkinsoni peterw@u.genie.co.uk http://www.pwnavigate.com/% http://www.windsurf-international.comp http://you.genie.co.uk/peterw/$ http://www.freerider-classifieds.com   ------------------------------  # Date: Mon, 03 Sep 2001 16:36:40 GMTi, From: peterw@u.genie.co.uk (Peter Watkinson) Subject: Re: OVMS License 7 Message-ID: <3b93b12b.13042812@news.cable.ntlworld.com>   = On Mon, 03 Sep 2001 16:32:19 GMT, peterw@u.genie.co.uk (Petern Watkinson) wrote:    >u >$ >T >Hi, >0 >1G >Periodically Open VMS software comes up for sale on Ebay. Sometimes ittF >says that no License is included. Do you require a license to installG >and use this software or will it run just fine without a license. This  >is for hobbyist use only. >S    ? also sometimes the software is said to be Open vms 7.2.1 or 7.2 D released i beleive in 1999. My question is will Mozilla run on 7.2.x4 on alpha or does it require the latest version -7.3?  	  regards,      Peter Watkinsone peterw@u.genie.co.uk http://www.pwnavigate.com/% http://www.windsurf-international.com  http://you.genie.co.uk/peterw/$ http://www.freerider-classifieds.com   ------------------------------  % Date: Mon,  3 Sep 2001 19:20:54 +0200 5 From: "GWDVMS::MOELLER" <moeller@gwdvms.dnet.gwdg.de>   Subject: RE: PRINT /que=filename. Message-ID: <E15dxP4-0006yt-00@gwdu42.gwdg.de>  1 frank brown <frank.brown@ci.seattle.wa.us> asked:aJ > Is there a way to create a print queue which sends the output to a file?E > Maybe some special symbiont for this purpose?  I'm using VMS 5.5-2.   F There is old REMPRTSMB, which may fit the "special symbiont" category.  G It's at ftp.gwdg.de in directory /pub/vms and comes as two ASCII files:e 	remprtsmb_012.readmeg 	remprtsmb_012.1_of_1O  , Needs VAXC (or DECC/standard=VAXC) to build.  M Wolfgang J. Moeller, Tel. +49 551 201-1516/-1510, moeller@gwdvms.dnet.gwdg.deoM GWDG, D-37077 Goettingen, F.R.Germany     |    Disclaimer: No claim intended!dM http://www.gwdg.de/~moeller/ ---- <moeller@gwdg.de> ---- <w.moeller@ieee.org>d   ------------------------------  # Date: Mon, 03 Sep 2001 16:57:30 GMT ) From: "Terry Murphy" <tsm@palindrome.org>t. Subject: Small DECterm Font & DECwindows Fonts@ Message-ID: <_DOk7.2153$eu.829831327@newssvr11.news.prodigy.com>  J I am looking for a small DECterm font that I can use on OpenVMS 7.2 Alpha,I so I can fit a whole DECterm into a 640x480 VNC window. I tried using theaL default small font (-DEC-Terminal-Medium-R-Normal--14-*-*-*-*-*-*) but it isK a little bit too big. Whenever I tried any smaller size of that font, I got K an error saying it wasn't available. I tried "fixed", and the size is fine, G but it doesn't support the special DEC fonts. Is there a smaller font IsD could use (12 point of the DEC terminal font would definitely work)?  K My next question is, where do fonts come from? My DECwindows display is set J to a Linux machine, but even when I enter fonts that are available on thatH machine (the 12 point DEC terminal, for example, is available and usableK from the Linux machine) I get an error if they're not available. Typically,rL in the Unix world, the font comes from the server side, not the client side,H but here they seem to be coming from the the client side. Is this indeed) true by default, and how can I change it?a   Thanks,, Terry)   ------------------------------  $ Date: Mon, 3 Sep 2001 11:25:35 +0200% From: "Fred Zwarts" <F.Zwarts@KVI.nl>a( Subject: Re: Some postive points I hope.. Message-ID: <9mviaf$7ro$1@info.service.rug.nl>  < "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message =& news:3B8FD5C3.F599CF48@videotron.ca... > Fred Zwarts wrote:C > > My experience is opposite, in particular for multi-volume sets. J > > Backing up a multi-volume set of 5 disks of 2 Gb each costed about 3 = hours.I > > I started a restoration, but gave up after 3 hours when it had only =) restored > > 5% of the data.F >=20I > Does it make a huge difference if the target disk is "empty" to begin =a with ascE > opposed to already populated with BACKUP creating new versions of =r files and/or > overwriting existing ones ?   G It was a /IMAGE restore to freshly initialized disks, mounted /foreign.l   >=20C > I know that backup can be terribly slow when you are asking for =- specific filesF > since it still has to scan through all of the files ahead of it to =
 eventually > get to the file you want.i >=20H > Does a tape device read slower that it writes ? If reads are done at = the sameJ > speed/throughput as writes on the tape device, and if a tape device is = slowerJ > than a disk device, then significantly slower restores would mean that = it isaD > the VMS file system that is slower than a tape drive. Could that =
 really be the  > case ?  C I could restore the data in about in somewhat more than 10 hours byiG mounting the disks normally and not using /IMAGE. In this way I lost=20tF file ids and aliases, but this particulat disk that was not a problem.2 So, no the tape speed was not the limiting factor.   ------------------------------  $ Date: Mon, 3 Sep 2001 09:57:21 +02007 From: "Dijk, Jeroen van" <Jeroen.vanDijk@Getronics.com>a5 Subject: RE: Standalone Backup Boot Question - Solved O Message-ID: <2795B75EF003D311801A00A0C906B511011C66B3@cucexec.gbc.getronics.nl>y   That's proves my point.n  B If are making standalone backup or other backups try to test them < at least if they are readable and if you can boot from them.   > -----Original Message-----> > From: rob.buxton@wcc.govt.nz [mailto:rob.buxton@wcc.govt.nz]% > Sent: dinsdag 28 augustus 2001 2:33  > To: Info-VAX@Mvb.Saic.Como7 > Subject: Re: Standalone Backup Boot Question - Solveds >  > 	 > Hi All,  > H > Yep, seems to have been some incompatibility problem between the TLZ86 > and the DLT4000. > D > I created another Standalone Backup on a tabletop TZ87 and the DLTE > 4000 saw that okay and correctly and I could boot standalone backupt > from that. >  > Gets me a starting point.  >  > Rob. > 9 > On Wed, 22 Aug 2001 22:55:01 -0500, "David J. Dachtera"e  > <djesys.nospam@fsi.net> wrote: >  > >Rob Buxton wrote: > >> a > >> Hi All, > >> o? > >> Trying to implement some Disaster Recovery procedures and r > doing some
 > >> testing.n8 > >> Created Standalone Backup using STABACKIT on a VAX  > 4000-705A running  > >> OpenVMS 7.25 > >> Tape was created on a TZ86 (connected via HSD30)m > >> mG > >> Transferred the Tape to a DLT4000 which I've plugged into the SCSIi > >> Port of a MicroVAX 3100.M > >> eC > >> From >>> Tape Device shows up as a Quantum 4000, Device MKA500  > >> AE > >> When I put the Standalone Backup Tape into the new DLT Device it 1 > >> always sets off the Use Cleaning Tape light.y > >> a) > >> If I try and boot from MKA500: I get- > >> ?06 HLT INSTR > >>          PC 00000D91  > >> D > >>  Bootstrap failure. > >> f: > >> So, is this a case that I can't just use any old DLT  > device that comesC
 > >> to mind?u; > >> Or, that I can't use a Standalone Backup created on a o > VAX4000 to booty > >> a MicroVAX 3100?v > >>  8 > >> The objective is to have, off site, a selection of  > material that wouldn= > >> allow me to rebuild a VAX, first step was to be able to l > boot the VAX, ; > >> probably sourced from a reseller at short notice with n > nothing on it in) > >> the event we'd lost everything here.  > >>  H > >> Nope we do not have a nice Disaster Recovery site with a spare VAX!@ > >> And, just for good measure, we're on a fairly active fault 
 > line, got asG > >> nice shake the other evening (7.0 - but the epicentre was some waye
 > >> off!) > >d> > >Take care to ensure that there's no compression enabled on  > the Tx86 (dide; > >it support that?). Otherwise, yeah - that's a tough one.i > >P > >--  > >David J. Dachtera > >dba DJE Systems > >http://www.djesys.com/  > >t+ > >Unofficial Affordable OpenVMS Home Page: " > >http://www.djesys.com/vms/soho/ >    ------------------------------  % Date: Mon, 03 Sep 2001 12:08:13 +0200d< From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@home.com>/ Subject: The Inquirer : 1GHz ES45 Alpha delayed ( Message-ID: <3B93568D.118C89FB@home.com>   FYI.' http://www.theinquirer.net/03090104.htmD   Jan-Erik Sderholm   ------------------------------    Date: 03 Sep 2001 12:08:48 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>e% Subject: Re: Tunneling DECnet over IP H Message-ID: <y4zo8cegcv.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  4 rdeininger@mindspring.com (Robert Deininger) writes:  , > I heard claims (possibly bogus) that their= > need to go beyond 63 areas was a major reason for DECnet-V.   K DEC's internal network (ENET) was larger, and certainly drove the Phase-IIIdL to Phase-IV transition and likely also the Phase-V transition, together withH the expectation that the world+dog would be using OSI-based network RSN.   	Jan   ------------------------------  % Date: Mon, 03 Sep 2001 13:50:53 -0400r, From: "Michael L. Umbricht" <mikeu@osfn.org>% Subject: Re: Tunneling DECnet over IPa( Message-ID: <3B93C2FD.A9117223@osfn.org>   Hoff Hoffman wrote:x > t > In article <twDj7.297$_I.534633@e3500-chi1.usenetserver.com>, "Zane H. Healy" <healyzh@shell1.aracnet.com> writes: > :r@ > :...The solution so far is to stick UNIX boxes running VTUN[1]O > :between the remote DECnet segments to tunnel the DECnet over the Internet...T > :FN > :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 IP N > :addresses and such with your DECnet aware apps to connect to remove systems > :over TCPIP. > I >   Correct.  This mechanism does not particularly attempt to encapsulate & >   DECnet, it uses IP as a transport.  D I think that what we're looking for in HECnet is a virtual DECnet IVB line/circuit over IP.  It should be transparent to the user at theA command line, ie. sending mail to host:: or seeing what nodes arer currently connected.  G > :What I'm looking for is some sort of tunneling software that runs onCK > :OpenVMS, and negates the need for having a UNIX box.  Is anyone aware ofu > :such software?e > F >   The two approaches I've seen used are DECnet-Plus over IP, and theH >   DECnet Phase IV connection into IP that Process Multinet (IIRC) had.   References to the latter:a  O http://www.support.process.com/documentation/multinet-docs/admin_guide/Ch18.htma  T http://www.support.process.com/documentation/tcpware-docs/management/Ch27.htm#E47E27   -mikeu    $ (DZ-0-0 is the above mentioned VTUN)  	 $ sh hosth# Host=MAGICA RSX-11M-PLUS V4.6  BL87    $ sh net  + Active nodes status as of 3-SEP-01 18:26:22    Executor node = 1.1 (MAGICA)  3    State = On, Physical address = AA-00-04-00-01-04   # Remote                       ActivetE Node             State       Links  Delay  Type           Cost  Hops   Circuite  E 1.2 (ERNIE)                  0      7      Routing IV     10    1    ; DZ-0-0   ------------------------------   Date: 3 Sep 2001 05:15:48 -0700 : From: extern.karl.rohwedder@volkswagen.de (Karl Rohwedder)2 Subject: Re: Ultra 160 SCSI for OpenVMS Alpha V7.3< Message-ID: <2865b31a.0109030415.568e693@posting.google.com>  X "John Eisenschmidt" <jeisensc@aaas.org> wrote in message news:<sb8261f3.007@aaas.org>...L > OHH OHH!!! 7.2-1 user here. I'd love to see this backported so we can use % > our 4254 shelves at full speed. <G>e > H > I suppose I should look at 7.3, though I *just* got the 7.2-1 systems 0 > configured (one isn't even in production yet). > @ > >>> Rich Jordan <jordan@ccs4vms.com> 08/21/2001 1:09:47 PM >>>D > The just released (8/20) VMS73 FIBRE SCSI-V0100 patch kit includesB > driver support for the KZPEA-DB Ultra 160 SCSI adapter.  This isH > apparently a 64-bit PCI to U160LVD and SE adapter that can run in a 33F > or 66MHZ slot.  FYI it looks like non-RAID U160 is finally availableF > for VMS.  Now to find out what hardware platforms are supported, and) > hope for a backport to at least V7.2-1.n > 
 > Rich Jordany  D I have just read the supported options for the DS10 and the KZPEA-DB listsy N/S (no support) for OpenVMSJ (http://www.compaq.com/alphaserver/options/asds10/asds10_3x-kzpea-db.html)   What is correct?   ------------------------------  $ Date: Mon, 3 Sep 2001 11:22:23 +0100* From: "Richard Brodie" <R.Brodie@rl.ac.uk>) Subject: Re: VMS 7.3 compatibility issuesp+ Message-ID: <9mvll3$juq@newton.cc.rl.ac.uk>-  X "Kenneth" <best@hotmail.com> wrote in message news:9mugkj$qlc1@imsp212.netvigator.com...K > I have scan all the executable in the system. However, some of the systemDI > binaries will return me the "Potential Alpha Violation" (I am using VMStK > 7.2-1). And what Compaq reply me that this is only a freeware only, so...3N > and they have certified the compatibility of VMS 7.2-1 on EV6. So the resultM > is if it returns error, it doesn't necessarily an error, and if it does notN= > returns an error, it does not mean it really have no error.p  E The tool is designed to look at things that may be a problem. One can0B then inspect the generated machine code to see whether they reallyE happen. In general, static analysis of code is an unsolvable problem;8D you can't tell whether the problematic sequences get to be executed.E However, if it flags no errors, then it means there are none (barrings bugs of course).   ------------------------------    Date: 03 Sep 2001 12:33:00 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>n) Subject: Re: VMS 7.3 compatibility issuesaH Message-ID: <y4u1ykef8j.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  $ "Kenneth" <best@hotmail.com> writes:  H > So the result is if it returns error, it doesn't necessarily an error,  I Yes, it may generate false positives because the binary equivalent of the=( wrong code sequence may occur elsewhere.  J > and if it does not returns an error, it does not mean it really have no  > error.  I Incorrect. By design the tool will not generate false negatives. So if itiB doesn't report an error on an image, you can safely use it on EV6.   	Jan   ------------------------------   Date: 3 Sep 2001 06:49:46 -0500j- From: Kilgallen@SpamCop.net (Larry Kilgallen)0) Subject: Re: VMS 7.3 compatibility issueso3 Message-ID: <pml3WLiz38oH@eisner.encompasserve.org>   U In article <9mugkj$qlc1@imsp212.netvigator.com>, "Kenneth" <best@hotmail.com> writes:dK > I have scan all the executable in the system. However, some of the system I > binaries will return me the "Potential Alpha Violation" (I am using VMSDK > 7.2-1). And what Compaq reply me that this is only a freeware only, so...DN > and they have certified the compatibility of VMS 7.2-1 on EV6. So the resultM > is if it returns error, it doesn't necessarily an error, and if it does not3E > returns an error, it does not mean it really have no error. And the_, > conclusion is the tool is not much useful.  G When it fails to return an error, you know your program is free of thispE particular error.  When it returns an error, you must investigate the H program to see if it is really the LL/STC error being discussed.  CompaqI did that for their own images, and they warrant VMS 7.2-1 in this regard.t7 You must follow the same procedure for your own images.s  F Of course if you want to, you can duplicates Compaq's investigation ofD their own images by using the source listings kit (which is compiled /MACHINE_CODE).    ------------------------------  % Date: Mon, 03 Sep 2001 15:26:14 +0100i( From: Nic Clews <sendspamhere@127.0.0.1>( Subject: Re: VMS NT/win2000 similarities) Message-ID: <3B939306.5073139D@127.0.0.1>i   Anamika wrote: > 8 > Are there any resources that talk about more of this ?  D There is (was) a book called "Windows NT for OpenVMS professionals",D David Solomon with Debra Wasserman, published by Digital Press, ISBNH 1-55558-122-6. Digital part number is EY-T856E-DP. Published in 1996, ItH covers NT 3 and elements of NT4, compared with OpenVMS V7.0. I like thisH book because it lists the similarities and the differences. I guess someH elements may be out of date. It also has some interesting history of NT.   -- l( Regards, Nic Clews CSC Computer Sciences nclews at csc dot come   ------------------------------   End of INFO-VAX 2001.490 ************************