1 INFO-VAX	Mon, 10 Jul 2006	Volume 2006 : Issue 381       Contents:P Re: A consistent, even playing field - That's all I ask! (Was: Re: No OpenVMS RT Re: Alpha remembrance day  Re: Alpha remembrance day " An entirely Digital OSF/1 question& Re: An entirely Digital OSF/1 question+ Re: DEC 2000 AXP fails system power up test + Re: DEC 2000 AXP fails system power up test  Re: Hoffman Labs Re: Hoffman Labs libxslt anywhere ? Re: libxslt anywhere ? Re: libxslt anywhere ?+ Re: Making LIB$*_VM_PAGE Caller's-mode safe + Re: Making LIB$*_VM_PAGE Caller's-mode safe 2 Re: No OpenVMS RTLs supported for ASTs or Threads!2 Re: No OpenVMS RTLs supported for ASTs or Threads!2 Re: No OpenVMS RTLs supported for ASTs or Threads! Re: Office Friendly RX2620' Re: OT: Intel quad core X64 benchmarked ' Re: OT: Intel quad core X64 benchmarked ' Re: OT: Intel quad core X64 benchmarked ' Re: OT: Intel quad core X64 benchmarked ' Re: OT: Intel quad core X64 benchmarked F Re: Process hangs while in exec mode with ASTs disabled (Pascal, RMS).P Re: Process hangs while in exec mode with ASTs disabled (Pascal, RMS). RMS).RMS)3 Question for Anyone using SSSU to script EVA stuff. & Re: The possibility of vms opening up?& Re: The possibility of vms opening up?& Re: The possibility of vms opening up?& Re: The possibility of vms opening up?  F ----------------------------------------------------------------------    Date: 10 Jul 2006 06:35:37 -0700- From: "Steve Lionel" <steve.lionel@intel.com> Y Subject: Re: A consistent, even playing field - That's all I ask! (Was: Re: No OpenVMS RT B Message-ID: <1152538537.753676.176270@75g2000cwc.googlegroups.com>   Richard Maher wrote:  " > > I personally expended a lot ofH > > effort in finding and removing reentrancy barriers in the RTL - this! > > was a task we took seriously.  > N > PLEASE, Please! come back and find and remove the inner-mode barriers in theL > RTL. Document which are and which aren't caller's-mode safe. (Whichever isJ > the smallest) If it is a case that you can only ever call out to another3 > /PROTECTed RTL then please come and document why.  >  > For example: > 	 > $GETUAI   F Whoa..  First of all, thread-safe and AST-reentrant is not the same asA inner-mode safe. Most of the RTL routines were not supported when G called from inner modes, but the LIB$xxx_VM routines were an exception. G  As documented, the memory returned is all owned by user mode no matter  what the mode of the caller.  = Second, $GETUAI is a system service, not an RTL routine.  The E distinction is important. RTL routines are those with names beginning G with prefixes such as LIB$, STR$, etc. that are documented in "Run-Time  Library" manuals.   F I took a look at the current VMS documentation and couldn't find whereB it made a statement about the thread-safety of the RTL routines. I  assume it is in there somewhere.   > % > > There were even statements at the E > > beginning of the various RTL reference manuals attesting to their  > > reentrant status.  > K > Apparently these attestations are not worth the paper they are written on  > :-(   C Yes they were.  But you're asking for something entirely different.   J > PPS. Are you completely sure about lib$*vm* being reentrant/thread safe?M > I'll take your (and the manual's) word for it (and certainly don't have any K > information to the contrary) but I just want to make sure that any use of M > interlocked queue instructions didn't get exaggerated out to cover the rest M > of the code. It's just that I was looking at the code the other day and was I > wondering that when the initial call for memory is made and the and the L > _zone fields in the _lib$data psect are zero, if an AST occured then won'tM > that also see it as zero and think it's first as well? I just can't see any K > $SETAST calls (and obviously no IPL raising) in the rest of the code. But J > that code's thrashed so much in every image it's just gotta have all the > bugs out by now.  E I don't remember all the details - Rich Grove, who rewrote the LIB$VM F routines for VMS 2.0 or 3.0 (I think), is now an Intel Fellow and sitsG down the hall from me, but I've spent a lot of time with that code.  It G is very definitely AST-reentrant and thread-safe, with some very clever C code.  I think it used AST levels to keep things separate, though I E don't doubt that the code has been tweaked over the years.  I do know D that back in 1980 we were worrying about threads and I wrote the VAX Pascal RTL to be thread-safe.   G And yes, I have obviously missed a lot of the discussion - I skim c.o.v  and noticed the thread title.    Steve    ------------------------------    Date: 10 Jul 2006 09:10:34 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayC Message-ID: <1152547834.062664.269930@s13g2000cwa.googlegroups.com>    Bill Todd wrote: > etmsreec@yahoo.co.uk wrote:  > > Well, that's one view. >    >    CanK > > you say "lack of applications"?  Can you say "lack of operating systems  > > to run on it"? > J > Can you say "incompetent blowhard?"  I think David addressed that latter@ > chimera adequately, and given that one of said OSs was WindowsG > (including support of x86 application binaries) I'd say that puts the C > former to rest as well (not to say that VMS and Tru64 didn't have > > adequate application support in their own right, of course). >   = I read this post with some amusement for a number of reasons.   G 1.     One of the key reasons for the decline in the Alpha business was E as the previous poster quite rightly stated the lack of software. The F OpenVMS/Alpha and Tru64/Alpha software portfolios are always limitted.E Part of Sun, IBM and HP's success in taking market share from Digital ? and then Compaq was attributable to the non availability of key = products on Alpha. From the latest versions of Oracle /Oracle 3 applications to key industry vertical applications.   F One factor which accelerated the decline was the move from make to buyB or buy/customise in the enterprise software market. Take retail, a> decade ago all the major retailers in the UK/US ran fufilment,G logistics etc systems that had been developed in house. Today most have C migrated much of this functionalality onto SW platforms supplied by B Oracle, SAP, Retek, Manhattan Associates etc. None of these run onG OpenVMS most don't run on Tru64. Most of these customers started moving A before the Alpha decline started but when the lack of Software on F either platform was becoming an issue. Ditto Investment Banking, DittoF Telco. Sainsbury's here in the UK did not even include Compaq on their@ list of prospective mid-high end suppliers back in 1999 mainly ID suspect because none of their prospective key ISV's supported either OpenVMS or Tru64.   B 2.    NT on Alpha is a complete red herring it was dropped in 1999B before the final Alpha demise and at 5% of the total Alpha systems( revenue it never acheived critical mass.  G 3.  FX!32 is also a complete red herring. It was a short lived solution B introduced in 1996. While it was a technically elegant solution itD never acheived any acceptance by the ISV community leaving customersG with x86 applications running using FX!32 with no support limitting its D use to non commercial applications.  It also did not work for device$ drivers further limitting its scope.  G At its peak after 2 years of gaining market share Tru64 still accounted A for less than 11% of the whole UNIX market and had under half the < available applications when compared with Solaris and HP-UX.  G Trying to re-write history by claiming that Alpha did not suffer from a G shortage of applications is rubbish, it wasin fact a key contributor in G the decline even if the blame for the lack of software could be laid at  Digital and then Compaqs doors.    Regards  Andrew Harrison    ------------------------------  % Date: Mon, 10 Jul 2006 10:14:09 -0700 ' From: David Mathog <mathog@caltech.edu> " Subject: Re: Alpha remembrance day+ Message-ID: <e8u1t2$fnd$1@naig.caltech.edu>   
 Andrew wrote:   I > Trying to re-write history by claiming that Alpha did not suffer from a J > shortage of applications is rubbish, it was in fact a key contributor inI > the decline even if the blame for the lack of software could be laid at ! > Digital and then Compaqs doors.   I Andrew is right on this one, the lack of native software was the primary  F reason we eventually abandoned VMS.  This was true even though most ofG the software we used came as source - it just didn't make sense to have H to port every program we needed from Unix -> VMS.  OS and hardware costsF were also factors, and I'd argue that these continued high costs were I mostly to blame for the lack of software.  It was a vicious circle: high  A OS and hardware cost -> small market -> repeat.  Not exactly the  7 ecosystem that software developers wanted to invest in.    Regards,   David Mathog   ------------------------------  % Date: Tue, 11 Jul 2006 02:23:46 +1200 1 From: Tux Wonder-Dog <wes.parish@paradise.net.nz> + Subject: An entirely Digital OSF/1 question # Message-ID: <44b2638c@clear.net.nz>   D Is it possible to get hold of the OSF/1 source code, as released andJ promptly dropped by the Open Software Foundation in June 1994?  And if so,F would HP consider making a donation of it - under similar terms to theH Caldera reorganization of the Santa Cruz Org.'s donation of ancient UnixD source code; eg, a BSD-style license - to The Unix Heritage Society?  ' Would anyone know who I should contact?    Thanks  
 Wesley Parish  --  O "Good, late in to more rewarding well."  "Well, you tonight.  And I was U lookintelligent woman of Ming home.  I trust you with a tender silence."  I C get a word into my hands, a different and unbelike, probably - 'she D fortunate fat woman', wrong word.  I think to me, I justupid.G Let not emacs meta-X dissociate-press write your romantic dialogs...!!!    ------------------------------  + Date: Mon, 10 Jul 2006 15:17:01 +0000 (UTC) ( From: m.kraemer@gsi.de (Michael Kraemer)/ Subject: Re: An entirely Digital OSF/1 question 5 Message-ID: <e8tr1d$3ou$1@lnx107.hrz.tu-darmstadt.de>   O In article <44b2638c@clear.net.nz>, Tux Wonder-Dog <wes.parish@paradise.net.nz>  writes: F > Is it possible to get hold of the OSF/1 source code, as released andL > promptly dropped by the Open Software Foundation in June 1994?  And if so,H > would HP consider making a donation of it - under similar terms to theJ > Caldera reorganization of the Santa Cruz Org.'s donation of ancient UnixF > source code; eg, a BSD-style license - to The Unix Heritage Society?   funny idea, K but this way one could possibly finish OSF/1 for Mips, i.e. DECstations :-)    ------------------------------  + Date: Mon, 10 Jul 2006 10:21:03 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk4 Subject: Re: DEC 2000 AXP fails system power up test) Message-ID: <e8t9mf$5gg$1@news.mdx.ac.uk>   R In article <nS9sg.16749$LS6.15744@trnddc03>, Tom Dockray <dockray@acm.org> writes: >Alan Adams wrote: > , >> In message <KGQrg.2895$bd4.1039@trnddc01>) >>           Tom <tfd@verizon.net> wrote:  >>   >[snip]  >>> 1 >>> These tests are followed by a message saying: F >>> "Power-on self-test errors were detected. Continue NT boot (Y/N)?" >>  A >> Could it be waiting for input from the serial consloe - i.e. a ' >> terminal connected to a serial port?  >>   >>>  >[snip]  >>  A >> I think this means it is using a serial port because it hasn't > >> detected the keyboard of the graphical console setup. Try a >> terminal... >>   >[snip]  > J >Well, the only VT device I have is a VT420 with an MMJ cable. Anyone know) >where I can get an MMJ to DB9 converter?  >   A Assuming you have a PC you could always use a serial cable and a  N terminal emulator rather than needing to use a real VT terminal - there are a : number of terminal emulators for windows freely available   9 eg teraterm Pro 3.1.3 from http://www.ayera.com/teraterm/     
 David Webb Security team leader CCSS Middlesex University     >    ------------------------------  % Date: Mon, 10 Jul 2006 09:23:12 -0400 2 From: "Stanley F. Quayle" <squayle@insight.rr.com>4 Subject: Re: DEC 2000 AXP fails system power up test; Message-ID: <44B21C80.16534.592F92D@squayle.insight.rr.com>   F > Well, the only VT device I have is a VT420 with an MMJ cable. Anyone2 > know where I can get an MMJ to DB9 converter?      You can get the pinouts at:   "    http://www.stanq.com/cable.html    
 --Stan Quayle  Quayle Consulting Inc.  
 ----------8 Stanley F. Quayle, P.E. N8SQ  Toll free: 1-888-I-LUV-VAX3 8572 North Spring Ct., Pickerington, OH  43147  USA < stan-at-stanq-dot-com   http://www.stanq.com/charon-vax.html) "OpenVMS, when downtime is not an option"    ------------------------------    Date: 10 Jul 2006 01:49:57 -0700  From: "Ian Miller" <ijm@uk2.net> Subject: Re: Hoffman Labs B Message-ID: <1152521396.947502.272450@75g2000cwc.googlegroups.com>  D the openvms.org newsletter of 20-MAY-2006 reported this site had new content.   ------------------------------    Date: 10 Jul 2006 08:03:42 -0700' From: "syslost" <wm.reynolds@gmail.com>  Subject: Re: Hoffman Labs A Message-ID: <1152543822.261862.52260@75g2000cwc.googlegroups.com>   2 Only one person can really confirm of deny this...     Ian Miller wrote: F > the openvms.org newsletter of 20-MAY-2006 reported this site had new
 > content.   ------------------------------    Date: 10 Jul 2006 06:04:45 -0700% From: "Pierre" <pierre.bru@gmail.com>  Subject: libxslt anywhere ? B Message-ID: <1152536685.870244.19780@m73g2000cwd.googlegroups.com>   hi,   * I'm about to (try to) recompile xmlstarletA (http://xmlstar.sourceforge.net/) which need libxml2 and libxslt.   E I found libxml2 in http://h71000.www7.hp.com/freeware/freeware80/ but  not libxslt A does s/o know if it has already be compiled for OVMS ? what about  xmlstarlet ?   TIA, Pierre.    ------------------------------  % Date: Mon, 10 Jul 2006 15:29:01 +0200 1 From: =?ISO-8859-1?Q?Jean-Fran=E7ois_Pi=E9ronne?=  Subject: Re: libxslt anywhere ? 4 Message-ID: <44b25620$0$868$ba4acef3@news.orange.fr>  6 You may find PCSI kits for Libxslt/Libexslt V1.1.12 at, http://www.pi-net.dyndns.org/anonymous/kits/   JF   ------------------------------    Date: 10 Jul 2006 06:54:17 -0700% From: "Pierre" <pierre.bru@gmail.com>  Subject: Re: libxslt anywhere ? B Message-ID: <1152539657.708942.44370@b28g2000cwb.googlegroups.com>   thanks a lot :)   ! Jean-Fran=E7ois Pi=E9ronne wrote: 8 > You may find PCSI kits for Libxslt/Libexslt V1.1.12 at. > http://www.pi-net.dyndns.org/anonymous/kits/ >=20 > JF   ------------------------------    Date: 10 Jul 2006 02:18:25 -0700  From: "Ian Miller" <ijm@uk2.net>4 Subject: Re: Making LIB$*_VM_PAGE Caller's-mode safeC Message-ID: <1152523105.233164.237250@s13g2000cwa.googlegroups.com>   E I see Hoff has been contemplating security and code again in his blog   D http://h20325.www2.hp.com/blogs/hoffman/archive/2006/07/09/1285.html   ------------------------------    Date: 10 Jul 2006 03:58:06 -0700  From: "Ian Miller" <ijm@uk2.net>4 Subject: Re: Making LIB$*_VM_PAGE Caller's-mode safeC Message-ID: <1152529086.628755.253160@m73g2000cwd.googlegroups.com>   ? If you have your own zone then you can have your own alloc/free  routines   (see LIB$CREATE_USER_VM_ZONE )  0 which could then call UWSS routines or whatever.   ------------------------------  # Date: Mon, 10 Jul 2006 14:38:26 GMT & From: John Reagan <john.reagan@hp.com>; Subject: Re: No OpenVMS RTLs supported for ASTs or Threads! 0 Message-ID: <CDtsg.259$jC5.130@news.cpqcorp.net>   Richard Maher wrote:   > J > No OpenVMS Run-Time Libraries (RTLs) are supported for Threads or at AST > level. >   C Not sure exactly what you are doing, but as far as I know all RTLs  I should work from AST level (user-mode just to be clear).  Many RTLs work  E in a threaded environment but some have restrictions.  Plus, be very  # careful of mixing threads and ASTs.    --   John Reagan / HP Pascal/{A|I}MACRO for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------    Date: 10 Jul 2006 10:43:16 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ; Subject: Re: No OpenVMS RTLs supported for ASTs or Threads! 3 Message-ID: <Sk$laDvbGkF4@eisner.encompasserve.org>   Y In article <CDtsg.259$jC5.130@news.cpqcorp.net>, John Reagan <john.reagan@hp.com> writes:  > E > Not sure exactly what you are doing, but as far as I know all RTLs  K > should work from AST level (user-mode just to be clear).  Many RTLs work  G > in a threaded environment but some have restrictions.  Plus, be very  % > careful of mixing threads and ASTs.   B    Unless there's been a distinct change, Fortran RTL I/O does notB    work from AST level.  Under some circumstances you may succeed,>    but a single I/O statement often translates to multiple RTL>    calls which implicitly assume Fortran's synchronous nature.   ------------------------------    Date: 10 Jul 2006 10:25:57 -0700- From: "Steve Lionel" <steve.lionel@intel.com> ; Subject: Re: No OpenVMS RTLs supported for ASTs or Threads! C Message-ID: <1152552357.292471.316330@p79g2000cwp.googlegroups.com>    Bob Koehler wrote:[ > In article <CDtsg.259$jC5.130@news.cpqcorp.net>, John Reagan <john.reagan@hp.com> writes:  > > F > > Not sure exactly what you are doing, but as far as I know all RTLsL > > should work from AST level (user-mode just to be clear).  Many RTLs workH > > in a threaded environment but some have restrictions.  Plus, be very' > > careful of mixing threads and ASTs.  > D >    Unless there's been a distinct change, Fortran RTL I/O does notD >    work from AST level.  Under some circumstances you may succeed,@ >    but a single I/O statement often translates to multiple RTL@ >    calls which implicitly assume Fortran's synchronous nature.  E Language support libraries are not included in John's statement - you C don't call those directly and they are not (any longer) documented. F However, the Fortran RTL on Alpha and Itanium supports a threaded modeB (which you have to ask for) and it should be able to handle I/O toB different units in different threads.  AST level SHOULD work but I( don't know that I've ever seen it tried.   Steve    ------------------------------  # Date: Mon, 10 Jul 2006 16:38:55 GMT 1 From: Keith Parris <keithparris_NOSPAM@yahoo.com> # Subject: Re: Office Friendly RX2620 0 Message-ID: <zovsg.265$8G5.126@news.cpqcorp.net>   Larry Kilgallen wrote:H  > can anyone compare (subjectively is fine) the noise levels of any of:6  > 	RX2620 - Office Friendly - at its quietest moments  > 	DS10	  > 	DS10L   > 	PWS433AU  > 	AlphaStation 250 4/226  > 	Alpha ES40  < I have an rx2620, a DS10, and a couple of Alphastation 200s.  G The Alphastation 200s are probably similar to your 250, and I consider  D them reasonably tolerable for noise level for a desktop workstation.  G I know it is in a desktop case, but the DS10 is what I consider just a  F bit too loud to be comfortable to use in a typical office enfironment.  E When I first turned on my rx2620, my first impression was that I had  G used shop-vacs that were quieter. I first fired it up late on a Friday  H afternoon and by Monday morning I already had questions asking how long I I planned to have that thing in my office. At the moment I've lent it to  G a co-worker and he put it 12 feet away in a separate cubicle, and even  1 then only powers it up when it's actually in use.   G Some folks downstairs bought 5 rx2620s and they proved too loud to use  ? in the office environment. Two quickly got rack-mounted in the  F datacenter. The remaining boxes have now had the Office-Friendly kits I installed. They are physically situated close together, and when I first  F encountered them recently, not being aware of the new kits, I thought E they must all surely be powered off. They seem quieter now than many   office PCs.    ------------------------------    Date: 10 Jul 2006 02:43:25 -0700- From: "Andrew" <andrew_harrison@symantec.com> 0 Subject: Re: OT: Intel quad core X64 benchmarkedB Message-ID: <1152524605.724548.227850@75g2000cwc.googlegroups.com>   Doug Phillips wrote: > Andrew wrote:  > > Bill Todd wrote: > > > Andrew wrote:  > > > > JF Mezei wrote:  > > > > > Bill Todd wrote: > > > > > > Andrew wrote: & > > > > > > > <-snip-> (it is numbers)) > > > >>>> <-snip-> (no it isn't numbers) " > > > >> <-snip-> (is too numbers)3 > > > > <-snip-> (is not numbers, is other numbers)  > > > <-snip-> (nuh uh!) > >  <-snip-> (uh huh!)  > I > Sorry if I've missed an attribution. I might have blacked out there for  > a moment.  >  > > I > > Why well you seem to have forgotten both what the thread is about and K > > sadly the statements made by the poster you seem vainly to be trying to  > > support. > > <-snip-> > E > There! I understood that. For the benefit of others like myself who H > have forgotten what the Original Post said, I've looked it up and here > it is: > = > ::---Original Post:: OT: Intel quad core X64 benchmarked---  > ::Alan Greig wrote: G > ::With the dual core Montecito finally about to appear, it seems that I > ::quad-core X64 Intel samples are out and about. There's a benchmark at G > ::http://www.xtremesystems.org/forums/showthread.php?p=1527913 if you  > ::haven't yet seen it.I > ::---------------------------------------------------------------------  >  > > J > > > Of course, you're comparing a just-released Xeon product to a ratherN > > > long-in-the-tooth Itanic product tested in 2004:  comparing to MontecitoH > > > would be a lot more appropriate, and there's some reason to expectJ > > > Montecito to post improved results even with no changes in bus speedK > > > (let alone with an increase to 533 MHz in a dual-socket configuration E > > > comparable to the top-of-the-line Woodcrest that you're quoting  > F > Okay, that's the real point, isn't it? New chip vs. Old chip numbersE > don't matter as much as what New chip vs. New chip numbers will be. I > Now, will Bill stand on that point or blow the argument and throw in an F > insult that allows Andrew to skate the real issue? Let's continue... >  > > > - by theN > > > way, your phrase "small 1-4 Module systems" suggests that you may not be@ > > > aware that Woodcrest supports only single- and dual-socketN > > > configurations, not 4-socket boxes like the zx1 chipset does and the zx2: > > > chipset will:  you *do* know about zx2, don't you?). > > >  > G > Oh, no, Bill tried to throw a hammer and dropped it on his foot!. Now D > Mr. A has an out. Well, we might as well see how Mr. A plays it... >  > > K > > Of course I was aware of Woodcrest being 2 module only, Clovertown sort  > > of delivers 4 modules. > >  >  > Yep. Mr. A took the out. > $ > > > <-snip-> (more uh huh, nuh uh) >  > > > > I > > The fact is the origional posters comments about zx1 scalability were K > > demonstrably wrong and he mixed on cell scalability (zx1) with off cell , > > scalability as it would appear have you. > G > Hey, there's that reference to the original poster again... something C > about zx1 --- let's go back and look ........ no zx1 there. Well,  > onward, then  F Well you are right sort of. The origional post refered to xz1, here is	 the post.   D "Xeon does not have a clear lead. HP's xz1 scale good to 4 cores and7 SGIs system scales linear from 1 to hundreds of cores."   E I could of course have followed a Bill Todd type line and accused the F poster of being totally ignorant because there is no such thing as theE xz1 but I assumed that it was a typo. Doesn't alter the fact that the G statement typo or not is demonstrably incorrect with respect to zx1 and " the SGI statement is not relevant.   Regards  Andrew Harrison    ------------------------------    Date: 10 Jul 2006 03:07:36 -0700- From: "Andrew" <andrew_harrison@symantec.com> 0 Subject: Re: OT: Intel quad core X64 benchmarkedB Message-ID: <1152526056.387072.97600@m79g2000cwm.googlegroups.com>   Doug Phillips wrote:  F > Okay, that's the real point, isn't it? New chip vs. Old chip numbersE > don't matter as much as what New chip vs. New chip numbers will be. I > Now, will Bill stand on that point or blow the argument and throw in an F > insult that allows Andrew to skate the real issue? Let's continue... >   > Sort of. Itanium II is quite old now but Montecito will not beF fundamentally different because it is basically 2 Madison (Itanium II)G cores packaged on to a single die. It uses the same FSB interface (400, G 533 and 667 Mhz) it also cloclks at the same speed as Madison (1.6 Ghz) F Intel have pulled the higher clock rate units and the Foxton frequency+ managment unit also appears to be disabled.   B In many respects you could make the same emperors new clothes typeF description of Woodcrest, yes its based on Core which is quite new butA Core is based on Pentium M with in turn was based on Pentium III.   A A single Montecito core should be faster than Madison but that is E mainly because Montecito has up to 24 MB of L3 cache split into 2 for D 12 MB per core which is up on the 9 MB maximum per core for Madison.   Regards  Andrew Harrison    ------------------------------    Date: 10 Jul 2006 10:33:50 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 0 Subject: Re: OT: Intel quad core X64 benchmarked3 Message-ID: <xtxH9+kFGRC1@eisner.encompasserve.org>   d In article <IFyrg.221$7w2.109@news.cpqcorp.net>, Keith Parris <keithparris_NOSPAM@yahoo.com> writes:  J > Before, VMS was restricted to "that VAX thing" and later to "that Alpha F > thing". With Itanium, at least VMS gets the benefit of economies of J > scale from the same hardware being sold with HP-UX, Windows, Linux, and D > OpenVMS. VAX ran only VMS and a little Ultrix; Alpha lost Windows B > support, ended up with few Linux users, and Tru64 is going away.  C    VAXen also run VAXeln, and more than one implementation of UNIX. F    Alpha ran CrayOS before SGI moved Cray to MIPS, and could have run H    a heck of a lot more stuff, if Digital had figured out how to market.  F    I still recall Novell's never completed decision to port Netware toB    Alpha.  And, of course, there are other implementations of UNIX    running on Alpha.   ------------------------------    Date: 10 Jul 2006 08:44:38 -0700- From: "Doug Phillips" <dphill46@netscape.net> 0 Subject: Re: OT: Intel quad core X64 benchmarkedB Message-ID: <1152546278.072324.37960@m79g2000cwm.googlegroups.com>  
 Andrew wrote:  >Doug Phillips wrote:  > >Andrew wrote: > > G > > There! I understood that. For the benefit of others like myself who J > > have forgotten what the Original Post said, I've looked it up and here
 > > it is: > > ? > > ::---Original Post:: OT: Intel quad core X64 benchmarked---  > > ::Alan Greig wrote: I > > ::With the dual core Montecito finally about to appear, it seems that K > > ::quad-core X64 Intel samples are out and about. There's a benchmark at I > > ::http://www.xtremesystems.org/forums/showthread.php?p=1527913 if you  > > ::haven't yet seen it.K > > ::---------------------------------------------------------------------  > >   K > > > The fact is the origional posters comments about zx1 scalability were M > > > demonstrably wrong and he mixed on cell scalability (zx1) with off cell . > > > scalability as it would appear have you. > > I > > Hey, there's that reference to the original poster again... something E > > about zx1 --- let's go back and look ........ no zx1 there. Well,  > > onward, then > H > Well you are right sort of. The origional post refered to xz1, here is > the post.  > F > "Xeon does not have a clear lead. HP's xz1 scale good to 4 cores and9 > SGIs system scales linear from 1 to hundreds of cores."  >   C Oh, sorry. When you said "original posters" I thought you meant the E person who started this thread. That was Alan Greig and the post that . started this thread is what I pasted in above.  G Now that I reread your post I see that I misunderstood; I've never seen E those posters so I don't know what they say. I collected posters once E and I wish I still had them. Lost some time ago, I'm afraid. Probably  worth a bundle now. Oh well.  G I'll let you get back to your discussion with Bill about how the future < we haven't yet seen  compares with the past we can't change.   ------------------------------    Date: 10 Jul 2006 09:17:25 -0700- From: "Andrew" <andrew_harrison@symantec.com> 0 Subject: Re: OT: Intel quad core X64 benchmarkedB Message-ID: <1152548245.545331.268490@35g2000cwc.googlegroups.com>   Doug Phillips wrote: > Andrew wrote:  > >Doug Phillips wrote:  > > >Andrew wrote: > > > I > > > There! I understood that. For the benefit of others like myself who L > > > have forgotten what the Original Post said, I've looked it up and here > > > it is: > > > A > > > ::---Original Post:: OT: Intel quad core X64 benchmarked---  > > > ::Alan Greig wrote: K > > > ::With the dual core Montecito finally about to appear, it seems that M > > > ::quad-core X64 Intel samples are out and about. There's a benchmark at K > > > ::http://www.xtremesystems.org/forums/showthread.php?p=1527913 if you  > > > ::haven't yet seen it.M > > > ::---------------------------------------------------------------------  > > >  > M > > > > The fact is the origional posters comments about zx1 scalability were O > > > > demonstrably wrong and he mixed on cell scalability (zx1) with off cell 0 > > > > scalability as it would appear have you. > > > K > > > Hey, there's that reference to the original poster again... something G > > > about zx1 --- let's go back and look ........ no zx1 there. Well,  > > > onward, then > > J > > Well you are right sort of. The origional post refered to xz1, here is
 > > the post.  > > H > > "Xeon does not have a clear lead. HP's xz1 scale good to 4 cores and; > > SGIs system scales linear from 1 to hundreds of cores."  > >  > E > Oh, sorry. When you said "original posters" I thought you meant the G > person who started this thread. That was Alan Greig and the post that 0 > started this thread is what I pasted in above. > I > Now that I reread your post I see that I misunderstood; I've never seen G > those posters so I don't know what they say. I collected posters once G > and I wish I still had them. Lost some time ago, I'm afraid. Probably  > worth a bundle now. Oh well. > I > I'll let you get back to your discussion with Bill about how the future > > we haven't yet seen  compares with the past we can't change.  C Well except as you can see from my other response to your post, the F future that Bill would like you to think you havn't seen you most haveC but you just didn't realise you had. Montecito and Clovertown being  good examples.   Regards  Andrew Harrison    ------------------------------    Date: 10 Jul 2006 08:33:50 -0700- From: "Steve Lionel" <steve.lionel@intel.com> O Subject: Re: Process hangs while in exec mode with ASTs disabled (Pascal, RMS). A Message-ID: <1152545630.844652.5710@p79g2000cwp.googlegroups.com>    John Reagan wrote:  J > As a point of trivia, don't ever use VAX Pascal generated code in higherD > modes if you compile with /CHECK.  The VAX compiler generates HALTJ > instructions as a quick way to raise a (reserved opcode) fault.  HALT in6 > higher modes tends to actually halt the machine. :-)  B Yeah, yeah...  It seemed like a good idea at the time, but you canD blame me for that one.  We learned from that mistake when we did Ada8 and used one of the two-byte user bugcheck instructions.   Steve    ------------------------------  # Date: Mon, 10 Jul 2006 15:03:04 GMT & From: John Reagan <john.reagan@hp.com>Y Subject: Re: Process hangs while in exec mode with ASTs disabled (Pascal, RMS). RMS).RMS) / Message-ID: <I_tsg.260$AD5.24@news.cpqcorp.net>    fkburrie@yahoo.co.uk wrote: C > In my Pascal program (OpenVMS 7.2) I have some condition handlers F > installed. In the implementation of  the executive handler I use theH > ordinary Pascal IO-routines to write a message to a file. In executiveD > code a trap occured while ast's where disabled. This resulted in aC > process hang; crash dump analysis  points to a conflict with RMS.  > F > I'm aware that normally $putmsg routines are being used in condition? > handlers but somehow my predecessors decided not to use them.  > G > In several documents I've read that it is unwise to use high level IO G > in exec mode routines and I assume  disabling ASTs at this level will D > even make things worse. Can anyone explain to me why high level IOI > should not be used in these circumstances? Btw, to keep the file layout F > the same as it is now I am looking for an alternative; is it safe to > use $QIO routines? > 
 > Regards, >  > Frank Burrie.  >   G Doing Pascal I/O (or RMS I/O in general) from exec-mode probably won't  H work like you desire.  The Pascal RTL in particular, turns ASTs off and I on in various places (it thinks it is in user-mode).  Doing that in exec  : mode will turn off exec mode ASTs and really piss off RMS.  G The Pascal RTL is only supported in user-mode.  In user-mode, it works  H with ASTs and with threads.  As far as the compiler goes, the code from E the Alpha and I64 compiler (minus calling the RTL) should be fine in  F higher modes but I've never tested it that way.  Be careful of Pascal : costructs that generate implicit calls to the RTL as well.  I As a point of trivia, don't ever use VAX Pascal generated code in higher  C modes if you compile with /CHECK.  The VAX compiler generates HALT  I instructions as a quick way to raise a (reserved opcode) fault.  HALT in  4 higher modes tends to actually halt the machine. :-)   --   John Reagan / HP Pascal/{A|I}MACRO for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------    Date: 10 Jul 2006 08:54:22 -0700" From: dave.baxter@bannerhealth.com< Subject: Question for Anyone using SSSU to script EVA stuff.C Message-ID: <1152546862.603405.274870@m73g2000cwd.googlegroups.com>   B      When I PRESENT a LUN to a Host,  using the Storage ManagementE Appliance, I have two choices, either I can designate a specific LUN, 0 or I can allow the Appliance to designate a LUN.  D      When I use the SSSU Scripting utility, I dont seem to have thatG choice.   It seems like I MUST designate a specific LUN number for each  VDisk that is being presented.  B      This is a bit of a problem, because it means that I MUST knowE which LUNs are available for each host, in order to write the script.   F      My question to the EVA guys out there is "is there a syntax whichF will cause the EVA to ASSIGN a LUN Number?"  and hence remove the need# for me to specify it in the script.    thanks     Dave.    ------------------------------    Date: 10 Jul 2006 10:24:53 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) / Subject: Re: The possibility of vms opening up? 3 Message-ID: <o5fOh6Udr9lQ@eisner.encompasserve.org>   \ In article <44AEAD03.B211FD75@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > H > Jet engines are not like those cars adertrised on TV that go from 0 toC > 60 in 0.237 seconds. They take time to spool up when more fuel is H > injected and once they have spooled up and have begun to generate moreC > thurst, it takes time to actually accelerate the aircraft itself.  >   A    While it is true that the spool up time of a turbine engine of C    any type is longer than that of a piston engine, it is also true /    that the spool up was controlled by the FBW.   I > Ever seen an aircraft start to take off ? Pilot applies full thrust and J > it takes a fair amount of time before the aircraft is actually moving at4 > a decent pace. It is no different once in the air.  E    I've not only seen them, I've ridden through them, and in the case (    of piston engines, I've piloted them.  I > And as you say, every pilot should know this, and in the Habsheim case, I > the pilot should have applied thurst before the need to start climbing. H > He was too busy impressing people below him with his very slow and low > airshow accrobatic.   B    That gets to the point.  He requested thrust at what would haveH    otherwise been an appropriate point, but the FBW setup added delay to>    the thrust increase, causing a delay in the speed increase.  G    His "airshow" behaviour was indeed improper, but the FBW was part of B    the chain of problems necessary to reach the accident.  The FBWF    actually flown commercially would probably prevent the accident via6    faster thrust response to the PIC's control inputs.   ------------------------------  % Date: Mon, 10 Jul 2006 12:55:58 -0400 ' From: Dave Froble <davef@tsoft-inc.com> / Subject: Re: The possibility of vms opening up? 9 Message-ID: <Js6dnQVc07z8GC_ZnZ2dnUVZ_qydnZ2d@libcom.com>    Bill Gunshannon wrote:  N > And what does that have to do with what is taught in University CS programs?  @ It occurs to me that those of us who were tasked with writing a C bootstrap program and loading it into a computer using the console  E switches might have developed a bit more comprehension on how things  ! really work at the lowest levels.   G Even without the PDP-6 and PDP-10 and PDP-11 systems I was exposed to,  * such an exercise could still be simulated.   Ah, the good old days.  :-)   H Oh, and I never developed any carpel tunnel problems with those systems.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Mon, 10 Jul 2006 12:58:53 -0400 ' From: Dave Froble <davef@tsoft-inc.com> / Subject: Re: The possibility of vms opening up? 9 Message-ID: <Js6dnQRc07ySGy_ZnZ2dnUVZ_qydnZ2d@libcom.com>    Karsten Nyblad wrote:  > geletine wrote: I >> I am sure some universities somewhere in the world contain vms as part 5 >> of a operating systems module in computer science. J >> It reminds me of the growing perception that java is dwarving out other  >> languages, which is not true.? >> I thought this article might be of interest in that respect. E >> http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html  >  > H > I think Joel makes one major flaw:  He thinks all CS students must be K > excellent at handling complex algorithms and designing complex programs.  J >  Guess what?  Most programs do things like ERP, CRM, tax, payroll, etc. @ >  The best guys for designing such software might not be great J > programmers in Joel's mind.  It might be people great at designing user J > interfaces or databases.  I fact such tasks might get great programmers E > sick greener pastures.  Thus, Joel may need great programmers, but  < > others might be better of hiring people with other skills.  B I've always said that before I can design an application to run a C company, I've first got to be able to run that company without the   computer system.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Mon, 10 Jul 2006 13:29:20 -0400 ' From: Dave Froble <davef@tsoft-inc.com> / Subject: Re: The possibility of vms opening up? 9 Message-ID: <Xr6dnQ6tVOSuEC_ZnZ2dnUVZ_qidnZ2d@libcom.com>    david20@alpha2.mdx.ac.uk wrote: a > In article <1152231895.454657.276510@m79g2000cwm.googlegroups.com>, davidc@montagar.com writes:  >> JF Mezei wrote: >>> davidc@montagar.com wrote:G >>>> 1)  OpenVMS passes information through verifiable structures, like  >>>> descriptors. L >>> That is not the case all the time anymore, not since they ported so muchC >>> unix software to VMS, including TCPIP Services which by today's 2 >>> standards, is a core operating system feature.H >> While various utilities, and programs may use null-terminate strings,I >> etc for TCPIP, you still have to go through $QIO to get to the kernel. G >> The biggest issue is still with DOS attacks, but not really exploits $ >> (like IIS buffer overflows, etc). >>K > As I recall there was a big argument in this group in 2000 because it was M > discovered that one of the newer system services SYS$CREATE_GALAXY_LOCK (?) J > had been written to pass a null terminated string rather than pass it byO > descriptor. Although as I recall the way it was used posed no security threat < > in this instance it was seen as the thin end of the wedge.L > After this was reported Joshua Cope at Compaq promised that an additional N > system service would be created and the interface using the null terminated % > string would be officially retired.   @ You remember correctly.  As you state, the real problem was the I willingness of someone in VMS engineering to start using techniques that  H have proven to be a problem in other operating systems.  The concept of G 'no null terminated strings' will prevent mishaps in other areas where   there may be a security threat.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------   End of INFO-VAX 2006.381 ************************