1 INFO-VAX	Wed, 26 Nov 2003	Volume 2003 : Issue 655       Contents:# Re: a pix to VT100 ascii converter?  Re: A sort of a "me too"5 Re: Anybody monitoring vmsnet.sdk.openvms.fieldtest ? 5 Re: Anybody monitoring vmsnet.sdk.openvms.fieldtest ?  AS1200 setting ethernet speed ! Re: AS1200 setting ethernet speed ! Re: AS1200 setting ethernet speed  Re: Backwards File Dump  Re: Backwards File Dump  RE: Backwards File Dump  Re: Backwards File Dump  RE: Backwards File Dump  Re: Backwards File Dump  Re: Backwards File Dump  Re: Backwards File Dump  Re: Backwards File Dump  Re: Backwards File Dump  Re: Backwards File Dump  Re: Backwards File Dump  RE: Backwards File Dump  RE: Backwards File Dump A Re: DCL procedure to monitor disk space and purge or delete files  Re: Ghostscript ! Happy Thanksgiving and God Bless! / Re: Hobbyist license and layered products - SLS 2 Re: How do they deliver a newsgroup from JF Mezei? Re: I'm sorry!!!!!!!+ Re: Mezei and Multiple Personality Disorder + Re: Mezei and Multiple Personality Disorder + Re: Mezei and Multiple Personality Disorder  Re: no cluster connection  Re: no cluster connection  NTP build procedure for VMS?A Re: odd SMTP e-mail when sending to page.metrocall.com (RESOLVED) A Re: odd SMTP e-mail when sending to page.metrocall.com (RESOLVED) A Re: odd SMTP e-mail when sending to page.metrocall.com (RESOLVED) A Re: odd SMTP e-mail when sending to page.metrocall.com (RESOLVED)   OpenVMS Limits Identifiers for C6 Re: question about dates of patches on ftp.itrc.hp.com6 Re: question about dates of patches on ftp.itrc.hp.com& Re: Required reading for HP executives& Re: Required reading for HP executives Re: SimH: no cluster connection  Re: SimH: no cluster connection 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday  TELENT in batch  Re: TELENT in batch  Re: TELENT in batch  test  test - previously unable to post Wildcard searching RE: Wildcard searching RE: Wildcard searching Re: [OT] For David CATHEY  Re: [OT] For David CATHEY   F ----------------------------------------------------------------------  % Date: Tue, 25 Nov 2003 23:52:55 -0500 3 From: "Richard B. Gilbert" <rgilbert88@comcast.net> , Subject: Re: a pix to VT100 ascii converter?0 Message-ID: <LJqdnQeDlLw1rFmiRVn-uA@comcast.com>  H ISTR that a gentleman named Sam Harbison wrote such a tool at Princeton I University in the 1970's.  In fact, I think his work made the cover of a  E national magazine.  He used an optical densitometer to determine the  I density values of various overstrike combinations and then wrote code to  C translate the scanned density values of a photograph to overstrike  
 combinations.   E Sam later co-authored a book on C; I believe his co-author was named  , Steele.  I don't know where he is now. . . .     Didier Morandi wrote:   I > I'm considering to be able to convert a digital picture to its "image"   > in plain ascii characters. > H > Remember these posters we had when the Dataproducts line printer came H > out back in the 80'? we were able to print four or five listing pages D > representing someone or someone else. All the "picture" made with  > simple ascii letters.  > > > I never knew how these posters were actually built. By hand? > F > Anyway, does someone know if there is such "tool" to scan a jpeg or ? > gif or tiff or bmp picture and produce an ascii "equivalent"?  > I > I understand that the size of a genuine VT100 character is much bigger  ' > than a pixel, but I'm just wondering.  >  > D. >    ------------------------------  % Date: Tue, 25 Nov 2003 20:27:58 -0600 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> ! Subject: Re: A sort of a "me too" ' Message-ID: <3FC40FAE.A430D05F@fsi.net>    Keith Parris wrote:  > G > Best of luck, Carl.  I went through a period of 11 months with only 3 G > weeks of work and thought I might well have to throw away two decades E > plus of VMS experience and work with Linux or (even worse) Windows. F > But I was blessed with the chance to continue working with VMS, as I > hope you will be.  > F > One good sign is that after 18-24 months of silence, I've started toE > get calls from recruiters again.  Economy must be starting to move.  > ] > JF Mezei <jfmezei.spamnot@istop.com> wrote in message news:<3FB7E7C2.103BA515@istop.com>... L > > Having said this, I think that VMS management are just like white fluffyP > > sheep, scared shitless of people likle Stallard, Blackmore and Carly and who9 > > do not want to rock the boat for fear of being fired.  > H > Carly Fiorina and Scott Stallard have been very supportive of OpenVMS.G >  Carly has made many public statements in support of OpenVMS.  In the H > June 30 webcast announcement for Integrity Servers, Scott Stallard had1 > very strong positive words to say about OpenVMS  > (http://groups.google.com/groups?q=scott+stallard+openvms+group:comp.os.vms&hl=en&lr=&ie=UTF-8&group=comp.os.vms&selm=cf15391e.0306301919.37c5a7f1%40posting.google.com&rnum=5) C > and even arranged for a slide promoting VMS to be inserted in the E > webcast just at the exact point where a stock HP video talked about F > Windows, HP-UX, and Linux and omitted VMS.  (I've seen a more-recentG > version of the video that now does include VMS, but this incident and  > others like http://groups.google.com/groups?q=scott+stallard+openvms+group:comp.os.vms&hl=en&lr=&ie=UTF-8&group=comp.os.vms&selm=cf15391e.0303100815.15c74c53%40posting.google.com&rnum=2 D > show how Scott Stallard has been willing to counteract and correct) > omissions of VMS in other areas of HP.)    Oh, goody, goody!   9 Now, I'll ask the same things I asked of Fred (sort of):    F When can we expect to start seeing the ads in mainstream publications?2 ...on TV? ...in the trade papers? ...on the radio?  C When will HP start winning back lost ISVs? ...winning over UN*X and 
 Windows ISVs?   H When will we see the price reductions that VMS *MUST* have to become and remain competitive?   D When will we start seeing OpenVMS positions on the Job boards again?   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------    Date: 25 Nov 2003 12:20:45 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) > Subject: Re: Anybody monitoring vmsnet.sdk.openvms.fieldtest ?3 Message-ID: <8+z$gBJ+T+Rg@eisner.encompasserve.org>   X In article <3fc37dd8$0$2389$626a54ce@news.free.fr>, Didier Morandi <no@spam.com> writes: > Bart Zorn wrote: > C >> I have posted two messages on vmsnet.sdk.openvms.fieldtest about D >> OpenVMS E7.3-2 but I seem to be the only one currently using that	 >> group.  >>   >> Is anybody else listening?  > Q > I think I remember that vmsnet groups are today heavily used by Spanish people  O > to post binaries because there is no size limitation, or something like that.   I No, that problem was cleared up in  vmsnet.sdk.openvms.fieldtest at least H a month ago.  I too have posted in the newsgroup and not seen responses,E and that gave me less interest in testing E7.3-2.  At the Symposium I J learned that at least one of the bugs I would have tested is still presentF (although it is not clear delivery of a report would have changed that status).   ------------------------------  # Date: Tue, 25 Nov 2003 21:22:48 GMT " From:   VAXman-  @SendSpamHere.ORG> Subject: Re: Anybody monitoring vmsnet.sdk.openvms.fieldtest ?0 Message-ID: <00A296F8.D94D990D@SendSpamHere.ORG>  c In article <8+z$gBJ+T+Rg@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: Y >In article <3fc37dd8$0$2389$626a54ce@news.free.fr>, Didier Morandi <no@spam.com> writes:  >> Bart Zorn wrote:  >>  D >>> I have posted two messages on vmsnet.sdk.openvms.fieldtest aboutE >>> OpenVMS E7.3-2 but I seem to be the only one currently using that 
 >>> group. >>>  >>> Is anybody else listening? >>  R >> I think I remember that vmsnet groups are today heavily used by Spanish people P >> to post binaries because there is no size limitation, or something like that. > J >No, that problem was cleared up in  vmsnet.sdk.openvms.fieldtest at leastI >a month ago.  I too have posted in the newsgroup and not seen responses,   K Problem is that the damage has been done.  I've removed the VMSnet.* groups 5 from my subscription lists because of the DIVX noise.    --  L VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)COM             5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  % Date: Tue, 25 Nov 2003 17:40:21 -0700 ( From: "Jim Mehlhop" <jmehlhop@qwest.net>& Subject: AS1200 setting ethernet speed2 Message-ID: <ZDSwb.1393$sW1.51027@news.uswest.net>  J I have acquired a used as1200 and I do not have any manuals.  How do I set; the first ethernet adapter to run at 100MBS or Auto detect?    ------------------------------  # Date: Wed, 26 Nov 2003 00:59:16 GMT 6 From: "Andy Bustamante" <a_c_bustamante@earthlink.net>* Subject: Re: AS1200 setting ethernet speed> Message-ID: <EVSwb.25823$rD1.11376@newssvr29.news.prodigy.com>  K This link http://h18002.www1.hp.com/alphaserver/archive/1200/1200_tech.html K will allow you to download documentation for the system.  Assuming you have K an "ew" device, such as a DE450 or DE500 for example,  one method is to set K this with at the console prompt.  This sets 100 mb full duplex on the first 
 ew device.   >>> set ewa0_mode fastfd  -  >>> set ewao_mode ? will list valid options.   J Once the system is booted this can be overridden by recent versions of VMSJ with the LANCP utility.  As a rule, I've found autodetect to not work veryJ well with AlphaServers and generally set this and the network equipment to
 fixed values.    -- Andy Bustamante  remove the ASCII 95s to reply     3 "Jim Mehlhop" <jmehlhop@qwest.net> wrote in message , news:ZDSwb.1393$sW1.51027@news.uswest.net...L > I have acquired a used as1200 and I do not have any manuals.  How do I set= > the first ethernet adapter to run at 100MBS or Auto detect?  >  >  >    ------------------------------  # Date: Wed, 26 Nov 2003 01:36:07 GMT " From:   VAXman-  @SendSpamHere.ORG* Subject: Re: AS1200 setting ethernet speed0 Message-ID: <00A2971C.3BAB7D3C@SendSpamHere.ORG>  ] In article <ZDSwb.1393$sW1.51027@news.uswest.net>, "Jim Mehlhop" <jmehlhop@qwest.net> writes: K >I have acquired a used as1200 and I do not have any manuals.  How do I set < >the first ethernet adapter to run at 100MBS or Auto detect?     Hi Jim,    At eh console prompt, enter:   P00>>> show e*_mode   M This will show you the two ethernet adaptors and their current configuration. $ To set it to 100bT Fast Full Duplex:   P00>>> set eia0_mode FastDF    To set it to 10bT:  ! P00>>> set eia0_mode Twisted-Pair     M It's been some time since I last looked at the console but I believe the key- , word for auto-detect is Auto or Auto-detect.     --  L VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)COM             5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  % Date: Tue, 25 Nov 2003 19:34:09 -0000 ( From: "John Travell" <john@jomatech.com>  Subject: Re: Backwards File Dump: Message-ID: <bq0ark$1sn06l$1@ID-120847.news.uni-berlin.de>  . "Tom Linden" <tom@kednos.com> wrote in message3 news:CIEJLCMNHNNDLLOOGNJIGEJKIIAA.tom@kednos.com...  >  Tom,   This is your problem.   # > Bit strings are stored, from this B > perspective, as big endian, which implies a reversal for integer > interpretation.   F Why do you perceive there to be any 'endian-ness' at all in bit string	 display ?   J Discounting IEEE formats where the whole layout is screwed, Numeric valuesH exist in both VAX and Alpha with the least significant bit at the lowest< address and the most significant bit at the highest address.F For convenience of display Digital chose to do it the way I described,L binary values are displayed in HEX with both address and value increasing as you go right to left.   > In my opinion, big-endian just does not make any sense at all.G Take a small value, repeatedly increment it until it overflows past the K natural word size of the processor doing the incrementing. Where do you put  the overflowing data ?E With little endian architecture you can consider the value to be in a F contiguously addressable memory location substantially larger than the natural computer word.I Big endian seems to me to artifically limit the size of an integer to the E word size. Overflow does not seem to naturally flow across memory, it  sort-of zigzags. Little-endian.$ msby<<<<sby(=msbx+1)    msbx<<<<lsbx in memory is msbx<<<<lsbx msby<<<<sby(=msbx+1)  ) Big endian would probably be displayed as % lsbx>>>>msbx    lsby(=msbx+1)>>>>msby  but in memory it is  lsbx>>>>msbx lsby(=msbx+1)>>>>msby   * Oh, I know what I mean, even if you don't.  3 re the comment about pit bull, yes, I plead guilty. L I know exactly how VAX, Alpha and VMS work, and I care about ensuring peopleL understand correctly. I have spent more years providing high level technicalK support on both hardware platforms and the internals of the software than I  care to recall.   J I guess I must also plead guilty to not being familiar with any big-endianF systems, but since VMS does not run on big-endian hardware it does notH concern me. I don't do Unix, so I don't need to know big endian systems.   -- John Travell" Independent VMS crashdump analyst. john- at - jomatech - dot - com  +44-(0)23-92552229 http://www.jomatech.com/       --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).A Version: 6.0.543 / Virus Database: 337 - Release Date: 21/11/2003    ------------------------------  % Date: Tue, 25 Nov 2003 17:30:32 +0000 - From: John Laird <nospam@laird-towers.org.uk>   Subject: Re: Backwards File Dump8 Message-ID: <jj37svojg9cndrco6uuvdi2m5p96adcjn7@4ax.com>  > On 25 Nov 2003 07:53:20 -0600, briggs@encompasserve.org wrote:  & >There is no left and right in memory.  % I'm glad someone pointed this out ;-)   L Endian-ness is to do with how bytes are organised in a machine word, not howK bits make up a byte, or how a number is represented externally in digits of 
 some base.  I As someone else said, it is logical for little-endian machines to display E increasing addresses from right to left, because we always write down D numbers in a big-endian fashion (or at least all number systems I amK familiar with).  Since the MSB of a longword at address A (the byte at A+3) H is written down to the left of the LSB (the byte at address A), it makesC sense to stick this next to the LSB of the longword at address A+4. $ Therefore, right to left works best.  E For byte dumps, it could well be argued that as left to right is more J "natural", and since endian-ness is not relevant to individual bytes, thisJ way would work for both systems.  But it would make it much more difficult: to spot word or longword values on little-endian machines.  B Besides, having the hex/decimal/octal dump mirrored with the asciiH equivalent (naturally left-to-right) is I find a help in associating the two.   --  4 Sure I can help you out, which way did you come in?    Mail john rather than nospam...    ------------------------------    Date: 25 Nov 2003 11:46:02 -0600 From: briggs@encompasserve.org  Subject: RE: Backwards File Dump3 Message-ID: <JHNJ6leaP+HR@eisner.encompasserve.org>   _ In article <CIEJLCMNHNNDLLOOGNJIGEJKIIAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes:  >  >  >>-----Original Message-----B >>From: briggs@encompasserve.org [mailto:briggs@encompasserve.org]* >>Sent: Tuesday, November 25, 2003 7:57 AM >>To: Info-VAX@Mvb.Saic.Com " >>Subject: RE: Backwards File Dump >> >>@ >>In article <CIEJLCMNHNNDLLOOGNJIMEJDIIAA.tom@kednos.com>, "Tom" >>Linden" <tom@kednos.com> writes:K >>> The fact that left shift multiplies and right shift divides establishes A >>> the (human) association most significant being left and least  >>right.  ThisK >>> is what was implied by my assertion that once it is in a register it is  >>> all big endian.  >>F >>That makes your notion of register endian-ness an illusion.  It sits7 >>between your ears rather than inside the CPU cabinet.  >>K >>> When I reference a string in PL/I as '0000000000000010'B this is stored > >>> in memory with the leftmost bit in the lowest location and >>proceeding from 
 >>> there. >>C >>Yep.  That's fine.  First = left in that presentation convention.  >>H >>And it's a perfectly sensible convention.  But it's neither big-endian0 >>nor little-endian.  It's a display convention. >>L >>> Strings are therefore stored in a Big endian fashion, provided you agreeL >>> to call the leftmost bit the most significant, and this is the generally >>> accepted view. >>F >>No.  It is not.  Bits within strings do not have significance.  TheyD >>have positions.  Bits within integers do not have positions.  They >>have significance. > L > John, you are like a pit bull, you just don't let go.  For the majority of	 > mankind ; > when _VIEWING_ a bit string representation of an integer,   J A "bit string representation of an integer".  What an interesting concept.  ) Is it a bit string?  Or is it an integer?   A If it's a bit string, I'd expect it to be presented left to right ; from first bit to last.  That's conventional reading order.   ? If it's an integer, I'd expect it to be presented left to right @ from most significant binary digit to last.  That's conventional/ representation for arabic style place notation.   3 On little endian hardware there is a conflict here. $ On big endian hardware there is not.   I think we agree on this.    > the left most bit  > is. > generally  regarded as the most significant.  G In integers, the left most digit is indeed regarded as most significant / (for conventional display arrangements anyway).   6 In bit strings, the bits have no numeric significance.   > Bit strings are stored, from > thisB > perspective, as big endian, which implies a reversal for integer > interpretation.   C Since bits in bit strings do not have significance, "big endian" is  not an applicable concept.    > That is not subject to debate.  @ Indeed, I have trouble understanding how you can so consistentlyB fail to understand.  I would have said my position is indisputably3 correct.  And yet you are disputing it.  Go figure.   . > If you wish to employ semantics to justify aD > prejudice, fine, I accept that.  Now I am done with this nonsense.  F Fine.  But everyone else should understand that semantics is preciselyA what we are discussing.  Semantics is about what words mean.  And * we are discussing what "big endian" means.  B This is appropriate since you apparently don't know what it means.   	John Briggs   ------------------------------    Date: 25 Nov 2003 13:29:43 -0800  From: wmr282@hotmail.com (w m r)  Subject: Re: Backwards File Dump= Message-ID: <398c9ca7.0311251329.202698f8@posting.google.com>   5 I've always thought little endian is correct because:   D Suppose I have a block of memory, starting at address 0 and all it'sF bits are zeroed.  That whole block of memory (say 4kb) is used for one integer.  D Now I want to start incrementing it.  The little-endian way would beE to increment the least-significant bit of location 0.  When that byte D overflowed, it would increment the least-significant bit of locationF 1, then resume incrementing location 0.  To do carries to higher-order: bytes requires incrementing addresses.  Increasing numericD significance is represented by increasing address.  More significantE bits have higher numbered addresses.  The address is directly related F to the power-of-2 that its bits represent.  The bit for 2^n is located in byte n/8, bit n%8.   1 Little endian is the only thing I like about x86.   4 Try reading a listing from 'gas' for alpha or intel.   Mike   ------------------------------    Date: 25 Nov 2003 12:17:50 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)   Subject: RE: Backwards File Dump3 Message-ID: <Wlcz6U4D+WrW@eisner.encompasserve.org>   _ In article <CIEJLCMNHNNDLLOOGNJIKEIOIIAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes: H > You have it wrong.  I previously postyed a program to demonstrate that4 > what I am saying is correct, I will repeat it here >  > HERMES> type  ENDIAN.PLI > endian: proc options(main); . > dcl bs bit(16) initial('0010000000000000'B);# > dcl fb fixed bin(15) defined(bs);  > put skip list(fb);
 > end endian;  > HERMES> run endian >  >         4  >   )    That's just a designed in bug in PL/I.    ------------------------------  % Date: Tue, 25 Nov 2003 14:54:03 -0500 % From: "John Vottero" <John@mvpsi.com>   Subject: Re: Backwards File Dump/ Message-ID: <vs7cqsgsh9ug2e@news.supernews.com>   ; "William Webb" <al5vf03p02@sneakemail.com> wrote in message 7 news:d5ce4b06.0311250748.2d48b2a2@posting.google.com...  > 2 > This thread is in serious need of a humor break. > E > The first thing that went through my mind when I saw the title was:  > C >      If you do a Backwards File Dump do you get satanic binaries?  >   / No, but you will find out where Paul is buried.    ------------------------------    Date: 25 Nov 2003 13:31:46 -0600 From: briggs@encompasserve.org  Subject: Re: Backwards File Dump3 Message-ID: <yojWh0a5o47K@eisner.encompasserve.org>   ] In article <3FC3B4A3.5150452F@sture.homeip.net>, Paul Sture <nospam@sture.homeip.net> writes: ! > briggs@encompasserve.org wrote:  >>  b >> In article <CIEJLCMNHNNDLLOOGNJIGEIEIIAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes:D >> > The fact of the matter is that if I overlay a 16 bit integer onD >> > the the bit string '0000000000000010'B  on a Big endian machineD >> > it displays as 2.  If I do it on a little endian it displays as
 >> > 2**14 >> >F >> > It is customary to associate left with most significant and rightE >> > with least.  Little is contrary to this association and therfore ( >> > appears unnatural, in this context. >> >F >> > Now if you store the string 'DEADBEEF'B4 on say a VAX in location/ >> > byte n  this is what will appear in memory  >>  6 >> If you don't use PL/I, you won't have this problem. >>  D >> If you don't try to alias bit strings as integers, you won't have >> this problem.  @ That posting was more abrupt than I should have made it.  Sorry.  F > This also crops up when using integer fields as part of of segmented > keys in an RMS file. > G > In order to get the index in the correct order, you need to byte swap J > the integer elements before storing the record. Or use packed decimal or" > a string representation instead.  D Yeah.  Makes sense.  Treating a binary integer as a character stringD for purposes of sort order would tend to exhibit this sort of issue.  I > In my experience, COBOL shops used to use packed decimals for this, but # > FORTRAN shops used byte swapping.   B Yeah.  Sensible.  Cobol has packed decimal built into the language and Fortran doesn't.  @ Note that if you were using PL/I style little-endian bit strings? (first bit = lsb in first byte, bytes taken in memory order) in C a segmented key you'd probably want to do bit reversal within bytes ; but not byte reversal within longwords in order to get your ? character comparison routines to match your intended bit string  sort order.    	John Briggs   ------------------------------  % Date: Tue, 25 Nov 2003 15:27:32 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>  Subject: Re: Backwards File Dump) Message-ID: <3FC3BB31.F0BE45FA@istop.com>    briggs@encompasserve.org wrote: I > Left shift in _HARDWARE_ on a little endian machine will multiply by 2.   : But in reality, it shifts the bits to the right. Correct ?  > > That's a big-endian assumption.  Low addressed = high order. > F > Again, this has nothing to do with left and right.  There is no left > and right in memory.  M If you forget endianness for a minute, as far as I know, all memory adressing L schemes have adresses that grow from 0 to a very large number. (ok, the 8086N with segment registers may be a different story). Books have page numbers thatM gow from 1 to some large number, and when the book is opened, the page number 7 on the left is lower than the page number on the right.   H The convention is to have lower numbered adresses first on the left, andJ higher number adresses last on the right, because on the western world, we read from left to right.  D > No.  It does not.  It is possible to write C code to determine theG > endian-ness of the architecture you are running upon.  That's because  > C code permits aliasing.  N But for normal operations, it does shield you from endianness. The majority ofK windows weenies program without knowing what endianness is. The fact that a N shift-left assembler operation on VMS would multiply by 2 (standard) indicatesM that even at the assembler level, there is some shielding of endianness since A in reality, it is a shift to the right on little endian machines.   B > In real life there is no such thing as left and right in memory.  K If that were the case, how come DUMP lists the hex part from right to left, ? and the text part from left to right ? It should be consistent.    ------------------------------  % Date: Tue, 25 Nov 2003 15:42:56 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>  Subject: Re: Backwards File Dump) Message-ID: <3FC3BECC.564CAFF0@istop.com>    briggs@encompasserve.org wrote: H > In both big endian and little endian, integers are generally presented > with msb left and lsb right.  L They keyword here is "presented". The compiler knows that the 4 bytes storedK beginning at memory location X are in little endian and can be displayed to  the user with routine Y.  N The DUMP utility doesn't know what the contents of the file are, and it has noM way of knowing that 4 bytes at offset X from start of file are meant to be an K integer. It has no business trying to interpret the contents of the file to / try to represent them to me in a different way.   F I can live with VMS being little endian. I don't need nor want DUMP to+ artificially reverse the order of the dump.   L If I see  FFFF0000 in dump, I have no way of knowing whether this is 2 wordsK or one longword, unless I consult that program that generated that file and R calculate offsets to see where those 4 bytes point to to know what they represent.  M And when consulting documentation on a file's format, the data is represented / in ascending order from the start of the file.    M And in the western world, ascending order means left to right and then top to J bottom. There is no endianness in a file. However, a file may contain someN binary data here and there that is stored in a particular endianness. The TIFFG file format comes to mind, since a TIFF file can be generated in either N endianness. So when you dump a TIFF file, you must look at the first couple ofS bytes to determine how binary values in the rest of the file should be interpreted.   M However, once you get to the stream of bytes that represent the image itself, F there is no endianness. The endianness in the TIFF file applies to theK integers that contain flags, offsets from start of file etc. Should DUMP be M aware of the TIFF format and automaticall switch frm displaying right-to-left N to -left-to-right when it gets to a portion of the file that is endian-neutral, because it is a stream of individual bytes ?   ------------------------------  % Date: Tue, 25 Nov 2003 15:55:05 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>  Subject: Re: Backwards File Dump) Message-ID: <3FC3C1A5.FA397D6F@istop.com>    Tom Linden wrote: I > In my view, little endian was the wrong decision way back when, but you T > can't  change that today and continuing the discussion is pointless and fruitless.    L Little endian has advantages though. For instance, if you pass a longword asK an argument that needs a word, the routine will still get its word and just I not look at the extra 2 bytes, and that is possible only in little endian O since the address given for the argument is that of the least significant byte.   J It does cause some headaches when you try to figure out how the C compilerK will treat a bit field (will the first bit in the struct be considered most L significant or least significant), and that often requires you write a small test program to figure it all.   ------------------------------  % Date: Tue, 25 Nov 2003 15:06:09 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>  Subject: Re: Backwards File Dump) Message-ID: <3FC3B62F.9F487123@istop.com>    John Travell wrote: B > Forget strings for now. Just look at a plain old decimal number. > 1234567890  K I cannot foprget strings. DUMP displays the contents of a FILE. Dump has no M knowledge of the type of contents, and treats it as raw data. In other words,  it treats it as a long string.  I Secondly, data stored in a file, no matter what its type, is stored at an N offset from the start of the block, and is displayed in ascending block order.K  If access is by record, then you can refer to the start of the record with R the RFA, and then to the specific byte by its offset from the start of the record.  J When you "TYPE" a file, contents are listed from left to right. Why should# DUMP list them from right to left ?   J I am not talking about a memory dump,. I am talking about the DUMP utility which dumps contents of files.    @ > the 1 is the MOST significant digit and it appears on the LEFTC > the 0 is the LEAST significant digit and it appears on the RIGHT.  > VMS dump is EXACTLY the SAME.   L Nop. On VMS, because of endianness, least significant digit is stored first.L DUMP tries to hide that fact by displaying the data in reverse order, makingS it *LOOK* like a big endian number with most significant numner stored on the left.   I The problem is that calculating offsets is not so natural. When you count K characters on the ascii display, you could from left to right. But when you 7 count on the hex display, you count from right to left.   K If I have to study binary contents of a dump, I would much prefer that DUMP M tells me like it is and present to me the contents as they really are, rather O than trying to make it look good by displaying the hex values in reverse order.   L Once I get to the calculated offset, I can then extract the 2 4 or 8 bytes I need.   ; > (remember the dump is BINARY NUMERIC values, NOT strings)   N Dump displays the contents of a FILE. Dump doesn't know abouty binary numeric. I dumps raw data.   < > Only if you insist on treating addresses as ascii strings.  7 > the MOST significant (highest) address is on the LEFT 9 > The LEAST significant (lowest) address is on the RIGHT.    Not on little endian machines.  N Ask yourself this: should VMS ever be ported to a big endian machine, will youK tolerate that some DUMP displays right to left and some DUMP on another VMS ! machine displays LEFT to RIGHT ?  J It should be always the same.  In my opinion, the small convenience of theL reverse layout VMS DUMP is outweighted by the big inconvenience of having to read data in reverse.   : > in the example above, the byte at memory offset 00 is A0* > the byte value 12 is at memory offset 0F  % DUMP acts  on ***FILES*** not memory.    ------------------------------    Date: 25 Nov 2003 15:45:14 -0600 From: briggs@encompasserve.org  Subject: Re: Backwards File Dump3 Message-ID: <$SXSFcTNAKVt@eisner.encompasserve.org>   V In article <3FC3BB31.F0BE45FA@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes:! > briggs@encompasserve.org wrote: J >> Left shift in _HARDWARE_ on a little endian machine will multiply by 2. > < > But in reality, it shifts the bits to the right. Correct ?  B No.  In reality, it shifts the bits a micron and a half one way orC the other to the next cell in the memory array.  That may be north, C south, east, west, up or down.  Referring to it as right or left ish pointless at best.  O > If you forget endianness for a minute, as far as I know, all memory adressingeN > schemes have adresses that grow from 0 to a very large number. (ok, the 8086P > with segment registers may be a different story). Books have page numbers thatO > gow from 1 to some large number, and when the book is opened, the page numbere9 > on the left is lower than the page number on the right.a > J > The convention is to have lower numbered adresses first on the left, andL > higher number adresses last on the right, because on the western world, we > read from left to right.  > And in Hebrew, decimal numbers are written with the high order( digits on the left just like in English.  ( Both observations merit a big "so what?"  E >> No.  It does not.  It is possible to write C code to determine theiH >> endian-ness of the architecture you are running upon.  That's because >> C code permits aliasing.  > P > But for normal operations, it does shield you from endianness. The majority ofM > windows weenies program without knowing what endianness is. The fact that atP > shift-left assembler operation on VMS would multiply by 2 (standard) indicatesO > that even at the assembler level, there is some shielding of endianness since C > in reality, it is a shift to the right on little endian machines.p   No.  You are dead wrong.  A By universal convention, a left shift is a shift toward positions E of greater numeric significance.  Little-endian does not change that.   G Little endian puts positions of greater significance at higher numberedrA bits (or higher numbered bytes).  It does not put high order bitsn on the "right".d  C >> In real life there is no such thing as left and right in memory.e > M > If that were the case, how come DUMP lists the hex part from right to left,nA > and the text part from left to right ? It should be consistent.u  B Stop.  Read what I wrote.  Understand what I wrote.  Then shut up.  % There is no left and right in memory.n   	John Briggs   ------------------------------  % Date: Tue, 25 Nov 2003 16:37:13 -0800 # From: "Tom Linden" <tom@kednos.com>c  Subject: RE: Backwards File Dump9 Message-ID: <CIEJLCMNHNNDLLOOGNJIKEKNIIAA.tom@kednos.com>o   >-----Original Message----- 2 >From: JF Mezei [mailto:jfmezei.spamnot@istop.com]* >Sent: Tuesday, November 25, 2003 12:55 PM >To: Info-VAX@Mvb.Saic.Com! >Subject: Re: Backwards File Dump  >E >i >Tom Linden wrote:J >> In my view, little endian was the wrong decision way back when, but you< >> can't  change that today and continuing the discussion is >pointless and fruitless.d >T > A >Little endian has advantages though. For instance, if you pass a- >longword asL >an argument that needs a word, the routine will still get its word and justJ >not look at the extra 2 bytes, and that is possible only in little endian> >since the address given for the argument is that of the least >significant byte.  E True, but I think we can agree that this is bad practice.  In fact, ao compilerL with good semantic analyser , such as PL/I, will issue a warning and convert theeL argument to the proper type for you, and pass the copy.  To use this type ofL trick is more typical of assembler and C programmers and is hardly portable.     > K >It does cause some headaches when you try to figure out how the C compilertL >will treat a bit field (will the first bit in the struct be considered most? >significant or least significant), and that often requires youg >write a small >test program to figure it all.r >e >---' >Incoming mail is certified Virus Free.i; >Checked by AVG anti-virus system (http://www.grisoft.com). B >Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003 >  ---u& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).A Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003o   ------------------------------  % Date: Tue, 25 Nov 2003 17:00:59 -0800l# From: "Tom Linden" <tom@kednos.com>i  Subject: RE: Backwards File Dump9 Message-ID: <CIEJLCMNHNNDLLOOGNJIEEKOIIAA.tom@kednos.com>   I the terms left shift and right shift have been around since the beginning5H their meaning is very clear, the former multiplies by a power of two andI the latter the inverse operation.  This implies by logical necessity thataI the MSB is on the left, etc.  The ALU is unaware of the ordering of bits,hH Big or Little Endian is a result of the design of the memory system.  OnH a Big Endian arch, the displayed bit pattern of, for example, an integerH will appear the same as bit string in programming languages that supportG such data types.  I suppose it is possible to layout bit strings in the H reverse order, but is generally done in such a manner that is consistentE with the way in which memory is addressed and incremented.  Thus on a.K byte addressable machine the first bit will be in the byte that correpsonds I to the address by which the compiler refers to the string.  My experienceaE having written compilers for both architectures is that little endian  requiresB a bit more work and is harder to work with,  at least when you are
 debugging.   >-----Original Message-----oA >From: briggs@encompasserve.org [mailto:briggs@encompasserve.org]O) >Sent: Tuesday, November 25, 2003 1:45 PMe >To: Info-VAX@Mvb.Saic.Com! >Subject: Re: Backwards File Dumpo >i >w3 >In article <3FC3BB31.F0BE45FA@istop.com>, JF Mezeio$ ><jfmezei.spamnot@istop.com> writes:" >> briggs@encompasserve.org wrote:K >>> Left shift in _HARDWARE_ on a little endian machine will multiply by 2.  >>= >> But in reality, it shifts the bits to the right. Correct ?h > C >No.  In reality, it shifts the bits a micron and a half one way or D >the other to the next cell in the memory array.  That may be north,D >south, east, west, up or down.  Referring to it as right or left is >pointless at best.  >p? >> If you forget endianness for a minute, as far as I know, alls >memory adressingTA >> schemes have adresses that grow from 0 to a very large number.o >(ok, the 8086? >> with segment registers may be a different story). Books haver >page numbers that@ >> gow from 1 to some large number, and when the book is opened, >the page number: >> on the left is lower than the page number on the right. >>K >> The convention is to have lower numbered adresses first on the left, andoC >> higher number adresses last on the right, because on the western 
 >world, we >> read from left to right.l >e? >And in Hebrew, decimal numbers are written with the high ordera) >digits on the left just like in English.n >p) >Both observations merit a big "so what?"  > F >>> No.  It does not.  It is possible to write C code to determine theI >>> endian-ness of the architecture you are running upon.  That's because- >>> C code permits aliasing. >>A >> But for normal operations, it does shield you from endianness.l >The majority ofB >> windows weenies program without knowing what endianness is. The >fact that a< >> shift-left assembler operation on VMS would multiply by 2 >(standard) indicatesi? >> that even at the assembler level, there is some shielding ofv >endianness sinceeD >> in reality, it is a shift to the right on little endian machines. >  >No.  You are dead wrong.s > B >By universal convention, a left shift is a shift toward positionsF >of greater numeric significance.  Little-endian does not change that. > H >Little endian puts positions of greater significance at higher numberedB >bits (or higher numbered bytes).  It does not put high order bits >on the "right". >oD >>> In real life there is no such thing as left and right in memory. >>? >> If that were the case, how come DUMP lists the hex part from  >right to left, B >> and the text part from left to right ? It should be consistent. >tC >Stop.  Read what I wrote.  Understand what I wrote.  Then shut up.  >-& >There is no left and right in memory. >2
 >	John Briggs2 >  >---' >Incoming mail is certified Virus Free.c; >Checked by AVG anti-virus system (http://www.grisoft.com).sB >Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003 >g ---e& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).A Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003B   ------------------------------  # Date: Tue, 25 Nov 2003 18:29:54 GMTv2 From: "Ken Farmer" <KFarmer@NOSPAM.SpyderByte.com>J Subject: Re: DCL procedure to monitor disk space and purge or delete files> Message-ID: <CcNwb.30251$I53.1250576@twister.southeast.rr.com>  L Shweet!  Thanks Joseph.  Glad to see people getting practical use out of the site.m  K Donate your procedures!  :)  A special thanks to all those who have posted.e6 It's a give take thing, take a procedure, post 10.  :)  D Don't forget to put <pre> and </pre> before and after procedure whenE pasting.  And for those who are wondering, I haven't been able to getuJ anything going where procedures can be uploaded directly to the site.  I'dH like to be able to focus more attention on that site sometime next year.   Kens   -- Kenneth Farmer  <><k OpenVMS.org  |  dcl.OpenVMS.org-      4 "Joseph Huber" <huber@mppmu.mpg.de> wrote in message% news:hTtBNWCD$G9g@vms.mppmu.mpg.de...  > In articleG <3BFEACE361F5BF429DD1DA593E3A7C090178DF02@xch-nw-28.nw.nos.boeing.com>,e3 "Wolf, Gerald J" <gerald.j.wolf@boeing.com> writes: L > > Is there a DCL procedure out there that will monitor disk space? If thatI > > disk space reaches a certain percentage full it will start purging or95 > > deleting selected file types, or specified files?l >.? >  http://dcl.openvms.org/ : diskspace.com does the first part.S+ >  Customize to make it do what You want...> >  > -- n@ >    Joseph "Sepp" Huber, Muenchen   http://www.huber-joseph.de/   ------------------------------   Date: 26 Nov 2003 05:25:59 GMT/ From: Erik Ahlefeldt <oahlefel@metz.une.edu.au>D Subject: Re: Ghostscript, Message-ID: <bq1dh7$7h3$1@gruvel.une.edu.au>  M This is how we do it, YMMV depending on where you have installed Ghostscript.aL N.B. The case of the qualifiers is significant to Ghostscript, so we enclose/ them in quotes to prevent VMS uppercasing them.f   $ gs :== $dka0:[gs]gs.exe L $ gs "-sDEVICE=pdfwrite" "-dBATCH" "-sOutputFile=abc.pdf" "-sPAPERSIZE=a4" -+      "-Idka0:[gs.fonts]" "-dNOPAUSE" abc.ps    ------------------------------    Date: 25 Nov 2003 15:35:45 -0800( From: bob@instantwhip.com (Bob Ceculski)* Subject: Happy Thanksgiving and God Bless!= Message-ID: <d7791aa1.0311251535.6ae5a9c3@posting.google.com>o  2 and it is even more happy when you are running VMS0 because you get to enjoy the day with family and. eat lots of turkey instead of having the phone0 ring off the hook and then have to run into work2 and reboot your 80000 servers running 80000 sparky chips ... :)   ------------------------------  # Date: Wed, 26 Nov 2003 05:36:47 GMT3 From: dittman@dittman.net,8 Subject: Re: Hobbyist license and layered products - SLS5 Message-ID: <PZWwb.3068$E9.2601@nwrddc01.gnilink.net>d  ' Denny <denny_rich@ameritech.net> wrote:nE > This all assumes my Sandpiper doesn't croak. And I guess a hobbyist:F > with an almost current DLT is a bit unusual. But then 3 months ago IF > would have laughed if you told me I would have to move my "VMS shop"> > off the dining room table so we can eat Thanksgiving dinner!  > Not really.  I have a TZ88 and two TZ887 drives on my hobbyist* cluster (and two RA8000 FC storage units). -- o Eric Dittman dittman@dittman.netd   ------------------------------    Date: 26 Nov 2003 02:40:15 -0000 From: sigh <what.a@maroon.com>; Subject: Re: How do they deliver a newsgroup from JF Mezei? 9 Message-ID: <R63GHQ6X37951.1529513889@Gilgamesh-frog.org>3  ' James Robinson <wascana@212.com> wrote:n   >nobody wrote: >> :I >> A concorde just crossed the atlantic BY BARGE.  Another donation to ane >> american museum.e ><D >Hardly.  It was barged all the way from JFK airport to the Intrepid >museum in Manhattan.o  P Mezei knows this full well.  He is just TROLLING you.  Really, how many times do you suckers have to be told???  O Or is it that you just enjoy being trolled by a very poor Canadian imitation ofd Michael Jackson?   ------------------------------  # Date: Tue, 25 Nov 2003 21:58:06 GMTu5 From: "Gregory Morrow" <gregory.morrow@earthlink.net>h Subject: Re: I'm sorry!!!!!!!tD Message-ID: <OfQwb.19800$Rk5.13682@newsread1.news.atl.earthlink.net>   JF Mezei wrote:e  L > I apologize for trolling your newsgroups but you morons keep responding to meI > even after I've been exposed numerous times.  You'd think even the most  retardedJ > among you would have wised up by now.  So as long as you keep responding to myt5 > lame trolls I'll keep trolling the shit out of you.  >dG > I know I'm psychotic, so if you want to send me some donations to getr& > electroshock therapy send them here: >t > Jean-Francois Mezeie > 86 Harwood Gate  > Beaconsfield, QC H9W3A3m > G > Also send me some porn, I'm running out of masturbation fantasies.  In prefer > little girls.l >i7 > If you want to have phone sex call me: (514) 695-8259o >n
 > Your Troll,r >y
 > JF Mezei > (my friends call me Sybil)    H Or sometimes "Eve", as in _The Three Faces Of Eve_ - a BIG Academy Award winner!y   -- ( Best Greg    4 > Here's a list of my latest multiple personalities: >s& > Popped Cherry <P.Cherry@anatomy.org>+ > Conspiracy Theory <conspiracy@theory.org>h > nobody <nobody@nobody.com>( > Lou Raccoon <L.Raccoon@wilderness.org>& > Flapping Labias <flabia@anatomy.org>' > Throbbing vulva <t.vulva@anatomy.org>a > Twin Gonads <two@gonads.com>' > Loose Scrotum <l.scrotum@anatomy.org>d$ > Raised Organ <R.Organ@anatomy.org>/ > Monica Lewinski <billclinton@westchester.com>o) > Deep Fried Foreskin <dff@mcdonalds.com> $ > Aroma of Smegma <aroma@chanel.org> > Wet fart <w.Fart@smell.org>y) > Pubic dandruff <P.dandruff@anatomy.org>d* > Voluptuous Nipple <V.nipple@anatomy.org>( > Inserted Finger <I.Finger@anatomy.org>! > Pubic Nair <shaved@anatomy.org>n) > Flatulent Meatus <F.Meatus@anatomy.org>-' > Lihk Mhygroin <L.MyGroin@anatomy.org>9 > Pre Khum <P.Khum@anatomy.org> # > Phi Mosis <Phi.Mosis@anatomy.org>s% > Bal Anatis <Bal.Anatis@anatomy.org>m" > Fren Ullum <F.Ullum@anatomy.org>& > Ivanna Getlaid <I.Getlaid@onani.org>( > Ivanna Wankalot <I.Wankalot@onani.org>& > Ivanna Umpalot <Humpalot@drevil.com>, > Wan Tnoneofit <W.Tnoneofit@weirdnames.org>  > Wan Itbad <W.Itbad@inneed.org># > Wan Towank <W.ToWank@anatomy.org>g! > Wan Tolik <w.tolik@anatomy.org> & > Testos Terone <t.terone@anatomy.org># > Upper Gonad <U.Gonad@anatomy.org> # > Right Gonad <R.Gonad@anatomy.org>l" > Left Gonad <L.Gonad@anatomy.org>& > Tyson's Glands <Tyson.G@anatomy.org>  > Nose Hair <n.hair@anatomy.org>' > Coronal Sulcus <C.Sulcus@anatomy.org>i' > Corpus Cavernus <manhood@anatomy.org>o& > Armpit moisture <armpit@anatomy.org> > Onani Room <onani@hotels.com>s( > Arnie's Banana <weiner@terminator.com>* > Raised eyebrows <r.eyebrows@anatomy.org>' > Vas Deferens <V.deferens@anatomy.org>a' > Naked Canuck <N.canuck@naturists.org>)( > Arni's socks <Smelly.Socks@arnold.org>, > Notable Exception <N.exception@untied.com>( > Unpopped Cherry <U.Cherry@anatomy.org>) > Tatooed Ovaries <T.Ovaries@anatomy.org> ) > Pierced eyelid <p.eyelid@piercings.org>,* > Limp Tomato <limp.tomato@vegetables.org>. > Eggplant Earrings <e.earrings@piercings.org>0 > Banana Underpants <B.Underpants@hillfiger.org> > Naval Lint <navel@lint.mil>h) > Ingrown Toenail <i.toenail@anatomy.org>t' > Empty Stomach <E.Stomach@anatomy.org>o& > Full Stomach <f.stomach@anatomy.org>$ > Smelly Cat <S.Cat@friends.nbc.com>( > Torn Ligament <T.Ligament@anatomy.org>% > Art Tistic <A.Tistic@modern.museum>)* > Furry Raccoon <F.Raccoon@wilderness.org>' > Wet Racoon <W.Racoon@wildnerness.org>y$ > Mad Racoon <M.Racoon@wildlife.org>' > Lazy Racoon <L.Racoon@wilderness.org>-( > Eaten Racoon <E.Raccoon@mcdonalds.com>) > Happy Raccoon <H.Racoon@wilderness.org>:+ > Sleeping Racoon <S.Racoon@wilderness.org>e) > Hungry Racoon <H.Racoon@wilderness.org>c$ > Horny Raccoon <H.Racoon@fauna.org>* > Smart Raccoon <S.Raccoon@wilderness.org>. > George W Raccoon <GW.Raccoon@wilderness.org>- > Ronald McRaccoon <r.raccoon@wilderness.org>n, > Thirsty Raccoon <T.Raccoon@wilderness.org>* > Johnny Raccoon <J.Racoon@wilderness.org>) > Oshi Santo <O.Santo@nx01.starfleet.org>>, > Oishi Chinko <O.Chinko@nx01.starfleet.org>! > T.Yellow <T.Yellow@nowhere.com>m > Q <queue@continuum.net>h > Borg Queen <1of1@borg.org>, > Ronald Wilkerson <wilkersonr@sympatico.ca>+ > John Balterman <j.balterman@sympatico.ca>g >f   ------------------------------    Date: 26 Nov 2003 02:40:15 -0000. From: The Three Faces of Mezei <eve@mezei.mpd>4 Subject: Re: Mezei and Multiple Personality Disorder9 Message-ID: <9C6N5SON37951.1529513889@Gilgamesh-frog.org>r  4 Gregory Morrow <gregory.morrow@earthlink.net> wrote:   >r >JF Mezei wrote: >0M >> I apologize for trolling your newsgroups but you morons keep responding to  >meiJ >> even after I've been exposed numerous times.  You'd think even the most	 >retardedpK >> among you would have wised up by now.  So as long as you keep respondingt >to my6 >> lame trolls I'll keep trolling the shit out of you. >>H >> I know I'm psychotic, so if you want to send me some donations to get' >> electroshock therapy send them here:b >> >> Jean-Francois Mezei >> 86 Harwood Gate >> Beaconsfield, QC H9W3A3 >>H >> Also send me some porn, I'm running out of masturbation fantasies.  I >prefers >> little girls. >>8 >> If you want to have phone sex call me: (514) 695-8259 >> >> Your Troll, >> >> JF Mezeij >> (my friends call me Sybil)r >  > I >Or sometimes "Eve", as in _The Three Faces Of Eve_ - a BIG Academy Award  >winner!  = Yep, any day now he'll probably be posting as Joanne Woodward ? <joanne@flappinglabia.com> or Eve White <eve@poppedcherry.com>.i  6 What a human waste.  At least he belongs to Canada....   ------------------------------  % Date: Tue, 25 Nov 2003 23:54:46 -0600 , From: Aboutdakota <aboutdakota@hot-mail.com>4 Subject: Re: Mezei and Multiple Personality Disorder+ Message-ID: <3FC44026.1030904@hot-mail.com>l   The Three Faces of Mezei wrote:h6 > Gregory Morrow <gregory.morrow@earthlink.net> wrote: >  >  >>JF Mezei wrote:  >> >>M >>>I apologize for trolling your newsgroups but you morons keep responding ton >> >>me >>J >>>even after I've been exposed numerous times.  You'd think even the most >>
 >>retarded >>K >>>among you would have wised up by now.  So as long as you keep respondinga >> >>to my  >>6 >>>lame trolls I'll keep trolling the shit out of you. >>>hH >>>I know I'm psychotic, so if you want to send me some donations to get' >>>electroshock therapy send them here:e >>>" >>>Jean-Francois Mezei >>>86 Harwood Gate >>>Beaconsfield, QC H9W3A3 >>>dH >>>Also send me some porn, I'm running out of masturbation fantasies.  I >> >>prefer >> >>>little girls. >>>n8 >>>If you want to have phone sex call me: (514) 695-8259 >>>  >>>Your Troll, >>>e >>>JF Mezeic >>>(my friends call me Sybil)n >> >>J >>Or sometimes "Eve", as in _The Three Faces Of Eve_ - a BIG Academy Award	 >>winner!a >  > ? > Yep, any day now he'll probably be posting as Joanne WoodwarduA > <joanne@flappinglabia.com> or Eve White <eve@poppedcherry.com>.. > 8 > What a human waste.  At least he belongs to Canada....  F You sure?  Any Canadian knows that postal codes have a space in them. I Also, Canadians know that the official abbreviation of Quebec is PQ, and rG not QC.  QC is the American abbreviation.  Besides, it's doubtful that mF JF is his identity.  It's probably the identity of some friend of his F that he doesn't like anymore.  That phone number should be called and ( atuhorities warned of the possible risk.   AD   ------------------------------  % Date: Wed, 26 Nov 2003 00:06:47 -0600e, From: Aboutdakota <aboutdakota@hot-mail.com>4 Subject: Re: Mezei and Multiple Personality Disorder+ Message-ID: <3FC442F7.1020606@hot-mail.com>b  9 >> What a human waste.  At least he belongs to Canada....o  B Not only that, one of his other trolling posts, he claims to have D switched from Fido to AT&T.  Eveyone in Canada knows that Fido is a E wireless service provider using the GSM/GPRS technologies.  The only rG services available native to Canada with the AT&T name are Rogers AT&T ^E after Rogers Communicaitons which acquired AT&T Wireless Canada, but  I kept the AT&T name.  The other service from AT&T is long distance.  AT&T  A does not have a good name in Canada, and it does not offer local :I service.  Therefore, by deductive reasoning, it stands that he could not jI have switched from FIDO to AT&T without a local service from a regulated e& telecommunications body in his region.   AD   ------------------------------  % Date: Tue, 25 Nov 2003 20:25:21 +0100 ( From: "H Vlems" <hvlems.nieuw@zonnet.nl>" Subject: Re: no cluster connection: Message-ID: <bq0agg$1tavte$2@ID-143435.news.uni-berlin.de>  1 "Didier Morandi" <no@spam.com> schreef in bericht1- news:3fc335f7$0$2365$626a54ce@news.free.fr...dL > I have built a VMS Cluster and tried to have my SimH node join it (VAX/VMS 6.2). C > I successfully created the SimH node as a Cluster member with LAN-
 commectivity,-J > but when it boots, the Connection Manager does not find my cluster (same number,p > same pwd, same LAN). >w > Any idea?p >e	 > Thanks,v >q > D. >@ Didier  " do you run DECnet on the simh VAX?   Hans   ------------------------------  % Date: Tue, 25 Nov 2003 20:33:21 +0100o- From: Didier Morandi <Didier.Morandi@free.fr>e" Subject: Re: no cluster connection' Message-ID: <3FC3AE81.E3F67016@free.fr>s   H Vlems a *crit :   $ > do you run DECnet on the simh VAX? >    Sure.a   D.   ------------------------------  % Date: Tue, 25 Nov 2003 23:14:12 -0500-3 From: "Richard B. Gilbert" <rgilbert88@comcast.net>6% Subject: NTP build procedure for VMS? 0 Message-ID: <eaidndJhmpwLtVmiRVn-jg@comcast.com>  G I'm running VMS V6.2-1H3 and DEC TCPIP Services (UCX) V4.2 ECO Level 5 .E on three DEC Alphas.  I can't upgrade because I have to run software c. that is not supported at more recent versions.  G The NTP implementation in UCX 4.2 appears seriously broken; one of the iE three clocks loses about 15 seconds a week!  The other two only lose  I three or four seconds a week.   In addition, there are no utilities such >G as ntpq, ntpdc, or ntpdate.  I do have four systems running  VMS 7.2-1 2H and TCPIP Services 5.1 that are working just fine in spite of a path to E the internet that runs from New Jersey to Missouri, to Massachusetts t0 before ever getting near an internet NTP server.  B I'd like to try a later version of NTP.  I've downloaded the V4.2 D distribution but although the documentation mentions VMS, the build I seems to require Unix tools (configure, etc.) that are not available for rH VMS.  I do have a version of "make" that runs on VMS but  I don't think B it understands the syntax of the make.in and make.am files in the 
 distribution.   < Does anyone have a script or directions to build it by hand? Thanks,l   Richard Gilbertt   ------------------------------    Date: 25 Nov 2003 12:23:42 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)eJ Subject: Re: odd SMTP e-mail when sending to page.metrocall.com (RESOLVED)3 Message-ID: <G4q+iNkrlj6c@eisner.encompasserve.org>o  \ In article <03112511585285@dscis6-0.dalsemi.com>, brandon@dalsemi.com (John Brandon) writes:  N > Then the gotcha.  Our ISP did not have an MX Record for the two servers thatO > were failing in sending e-mail pages.  However, the ISP did have an MX Recordo? > for the server that was sucessfully sending the e-mail pages.n  G I thought MX records were supposed to be for _incoming_ email handlers.e+ Perhaps Metrocall is doing something wrong.o   ------------------------------  % Date: Tue, 25 Nov 2003 17:35:32 -0600r( From: brandon@dalsemi.com (John Brandon)J Subject: Re: odd SMTP e-mail when sending to page.metrocall.com (RESOLVED)1 Message-ID: <03112517353253@dscis6-0.dalsemi.com>0  P > > Then the gotcha.  Our ISP did not have an MX Record for the two servers thatQ > > were failing in sending e-mail pages.  However, the ISP did have an MX RecordgA > > for the server that was sucessfully sending the e-mail pages.l > I > I thought MX records were supposed to be for _incoming_ email handlers. - > Perhaps Metrocall is doing something wrong.s  O I beleive MetroCall is attempting to backward resolve the server name - as in asI reverse lookup DNS - in an effort to control SPAM.  From what I have beena told...I     J*o*h*n B*r*a*n*d*o*n  VMS Systems Administratort* firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  % Date: Tue, 25 Nov 2003 19:03:48 -0800u% From: Dean Woodward <deanw@rdrop.com>mJ Subject: Re: odd SMTP e-mail when sending to page.metrocall.com (RESOLVED)( Message-ID: <3FC41814.6000306@rdrop.com>   John Brandon wrote:eG > I beleive MetroCall is attempting to backward resolve the server namenD > - as in a reverse lookup DNS - in an effort to control SPAM.  From > what I have been told...  H Exactly- but they should be trying to  resolve to an A name, not an MX. I Assuming that any given organization's incoming and outgoing mailservers u+ are the same box(es) is asking for trouble.r   ------------------------------    Date: 25 Nov 2003 22:45:55 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)eJ Subject: Re: odd SMTP e-mail when sending to page.metrocall.com (RESOLVED)3 Message-ID: <NWMuwk6KxQv$@eisner.encompasserve.org>   \ In article <03112517353253@dscis6-0.dalsemi.com>, brandon@dalsemi.com (John Brandon) writes:Q >> > Then the gotcha.  Our ISP did not have an MX Record for the two servers thatcR >> > were failing in sending e-mail pages.  However, the ISP did have an MX RecordB >> > for the server that was sucessfully sending the e-mail pages. >> -J >> I thought MX records were supposed to be for _incoming_ email handlers.. >> Perhaps Metrocall is doing something wrong. > Q > I beleive MetroCall is attempting to backward resolve the server name - as in a K > reverse lookup DNS - in an effort to control SPAM.  From what I have beenf	 > told...i  > Ok, but that is an entirely different issue from an MX record.   The proper test would be:   1 	Does this IP address have a reverse DNS name andd3 	does that reverse DNS name forward resolve to thisi$ 	IP address (possibly among others).   Any test more severe is flawed.f   ------------------------------    Date: 25 Nov 2003 12:50:10 -0800- From: soccer13player@yahoo.com (Nom de Plume)p) Subject: OpenVMS Limits Identifiers for Cp= Message-ID: <f401eb7f.0311251250.58ec3daf@posting.google.com>e   Hello,  K Does OpenVMS have a C header/include file that includes common limits like:uF #define CLI_INT_MAX    4095      /* OpenVMS CLI (interactive) limit */= #define USERNAME_MAX     12      /* OpenVMS Username limit */aC #define IDENTIFIER_MAX   31      /* OpenVMS UAF Identifier limit */tP #define ASCTIME_LENGTH   26      /* OpenVMS C RTL Library: asctime definition */= #define NODENAME_MAX      6      /* OpenVMS Hostname limit */o   Or something of this nature???   JMOD   ------------------------------  # Date: Wed, 26 Nov 2003 01:32:13 GMTm/ From: Geoge Pagliarulo <georgepag@adelphia.net>l? Subject: Re: question about dates of patches on ftp.itrc.hp.coma= Message-ID: <xoTwb.32759$m84.4625552@news1.news.adelphia.net>n  / Phillip Helbig---remove CLOTHES to reply wrote:e  J > I noticed that several of the kits have the date 20-NOV-2003.  However, J > they appear to be rather older.  On the other hand, the file I download J > has a different checksum than the one I already downloaded earlier, but 7 > neither is the checksum mentioned in the readme file.I > 0 > What am I missing with regard to the checksum? > J > How can one find out what patches have been put up after a given date?  D > I signed up for the email notification, but it doesn't seem to be  > working properly.  >  Philip,h  I 	We found a problem with the checksums in all the kits that had checksum -I information in the docs.  Turns out that the copying a file  changes the MI checksum.  If the last bit after the end of file is null, COPY will zero -G it (FTP does the same thing).  Since the checksum is added to the docs iG before the file is copied, all the sums were wrong.  All the kits were g2 corrected and the checksums should now be correct.F Whic kit did you recently download that had a mis-matched checksum in  the readme?s   George Pagliarulog Hewlett Packarda george.pagliarulo@remove_hp.com    ------------------------------  % Date: Tue, 25 Nov 2003 22:11:55 -0500y* From: JF Mezei <jfmezei.spamnot@istop.com>? Subject: Re: question about dates of patches on ftp.itrc.hp.come) Message-ID: <3FC419E0.B48DD10D@istop.com>r   Geoge Pagliarulo wrote:iJ > information in the docs.  Turns out that the copying a file  changes theJ > checksum.  If the last bit after the end of file is null, COPY will zero > it (FTP does the same thing).   6 Does CHECKSUM actually examine data past end of file ?  H Sorry, but if the operating system that hosts the serious stuff like VMSJ patches is unable to keep track of a proper end of file marker, how can we( trust that the patch is in fact intact ?  1 Will CR and/or LF characters be compromised too ?    ------------------------------  # Date: Wed, 26 Nov 2003 00:13:35 GMTn# From: "John Smith" <a@nonymous.com>,/ Subject: Re: Required reading for HP executivestF Message-ID: <PeSwb.8140$zJq.7557@news01.bloor.is.net.cable.rogers.com>   JF Mezei wrote:s > Rob Young wrote:B >>         would have been caught.  Oh - before anyone chimes in ,E >>         Tivoli Monitoring (ITM) has heartbeat - if it doesn't heare< >>         from the node being monitored, that is a problem. >f > E > A node can be up with the heartbeat process running happily but the 9 > application is stuck in RWAST (to put it in VMS terms).o >fE > Heck, an application might still be responding to ASTs but be stuckU? > in its mailine code incapable of processing some transaction.S >i@ > It isn't the hardware nor the OS that are important. It is the > application.    D Actually it's all the above plus a TP monitor for some applications.   ------------------------------  % Date: Tue, 25 Nov 2003 16:07:59 -0500P* From: JF Mezei <jfmezei.spamnot@istop.com>/ Subject: Re: Required reading for HP executivesg( Message-ID: <3FC3C4A9.8F3390C@istop.com>   Rob Young wrote:H >         would have been caught.  Oh - before anyone chimes in , TivoliF >         Monitoring (ITM) has heartbeat - if it doesn't hear from the2 >         node being monitored, that is a problem.    C A node can be up with the heartbeat process running happily but thel7 application is stuck in RWAST (to put it in VMS terms).   J Heck, an application might still be responding to ASTs but be stuck in its6 mailine code incapable of processing some transaction.  K It isn't the hardware nor the OS that are important. It is the application.d   ------------------------------  % Date: Tue, 25 Nov 2003 18:09:33 +0100d2 From: Wilm Boerhout <w.boerhoutOLD@PAINTplanet.nl>( Subject: Re: SimH: no cluster connection* Message-ID: <bq02mv$850$1@reader11.wxs.nl>   OK, here we go again...   E Remember, WiFi is a physical layer. Logically, it's just Ethernet. I nC cluster my CHARON-VAX machines using WiFi LAN connections, and the . CHARON-VAX packet driver.l  H As a side issue, I boot VMS from (a disk container on) my USB-connected  watch. Why? Because I can :-)s   > * > What about WiFi OpenVMS clustering ? ;-) > B > Or may be we can run several instances of SimH under Itanium-VMS& > to run VAX/VAM, AXP/VMS or MPE ! :-) >    w.boerhoutOLD@PAINTplanet.nl(    (remove OLD PAINT from reply address)   ------------------------------  % Date: Wed, 26 Nov 2003 10:20:57 +0800l( From: Peter Sutter <nospam@sopac.com.au>( Subject: Re: SimH: no cluster connection< Message-ID: <3fc40e20$0$1756$5a62ac22@freenews.iinet.net.au>   Didier Morandi wrote:g  L > I have built a VMS Cluster and tried to have my SimH node join it (VAX/VMSI > 6.2). I successfully created the SimH node as a Cluster member with LANmJ > commectivity, but when it boots, the Connection Manager does not find my, > cluster (same number, same pwd, same LAN). >  > Any idea?  > 	 > Thanks,y >  > D.  I I am emulating a cluster (OpenVMS 7.1 and OpenVMS 6.2) each running underi SimH on a linux box.  rH Check if the SimH cluster member can connect to the rest of the network.F I assume the box running SimH is a Linux/Unix machine with one networkJ interface only. If so, the network card must run in promiscuous mode, i.e. SimH must run under root.c  K This has one drawback, the emulated VMS can not connect to the machine SimHi1 runs on. If you need this, you need a second NIC.k  , Here are my entries in the SimH startup file+ ; The network uses eth0 in promiscuous mode  attach xq eth0 set xq mac=08-00-2B-AA-BB-CC   Petere    t   ------------------------------  % Date: Tue, 25 Nov 2003 15:59:58 -0500n* From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday2 Message-ID: <EfOdnfFBCbpXX16i4p2dnA@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:GndLTSmqlLxw@eisner.encompasserve.org..."H > In article <bpvb4s$mo4$1@new-usenet.uk.sun.com>, Andrew Harrison SUNUK; Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes:h > > Rob Young wrote:   ...t  G > >> Since high-k runs much cooler, certainly they could create largishaG > >> (300-400 mm2) CPUs that contain 96 MByte on-chip cache and consumed. > >> far less power, generate a lot less heat.  E Gee, Rob - you're even surpassing your usual selling-of-futures here.e  L The 90 nm. Montecito will be hard-pressed to fit 24 MB of on-chip cache intoL a chip pushing 500 mm^2.  Two process shrinks later (45 nm., due - one mightI suspect optimistically, at least for use in Itanic - in 2007) you'd stilliH need close to 500 mm^2 to get 96 MB on the chip.  So you must be talking< about a 32 nm. process, right around the end of this decade.   > >>@ > >> If you look at their roadmap over the next 2-3 years , theyF > >> have a 9 MByte Madison, Montecito in 2005, Tanglewood in 2006 andK > >> follow-ons.  Maybe a high-k Tanglewood is little more than quadruplingsE > >> on-chip caches?  Do you think a 2006 Tanglewood won't meet powergG > >> budget?  No.  But couldn't it run much faster and have much largerhH > >> caches if the power consumption is greatly decreased?  Sure.  MaybeJ > >> clock goes from 1.5 GHz to 4 GHz and they burn 100 watts.  The high-kF > >> will give more design freedom that's for sure.  But they won't beB > >> performance handicapped until then.  That would be the SPARC. > >> > >-G > > You are making the enormous and rather typical mistake (for you) of]C > > assuming that the only way of building a CPU that delivers moreCA > > throughput is to clock it faster, increase its cache size and & > > lengthen its pipeline etc etc etc. >d > I'm not talking throughput  K You certainly are if you're talking about Tanglewood:  with 8 cores on thatfJ chip, each likely using a core that places more emphasis on simplicity andI low power consumption and less emphasis on single-thread performance thansJ the current McKinley/Madison core, it would be downright silly to waste it on single-threaded use.n  $  - whatever that vacuous term means,> > but I guess we are heading towards Sun marketing terminologyI > and direction - "throughput computing."  I'm talking about performance. ? > Noted industry standard metrics as a guage.  SPECint, SPECfp,t* > tpcc, tpcd, SAP and a handful of others.  E In single-thread performance Tanglewood will probably have difficultylE matching Montecito.  The statements about Tanglewood's 7x performancemE improvement over Madison have specifically referred to multi-threaded L performance (both CMP and SMT-within-CMP), which quite clearly suggests thatF a single one of Tanglewood's 8 cores won't quite match today's Madison performance.  F Which isn't too surprising, if you think about it:  at half the linearK feature size of Madison but with 8 cores rather than only one, Tanglewood's K power consumption should roughly match Madison's if per-core performance isrJ similar (and leakage can be kept under control).  As I noted earlier, this? means that, e.g., AMD64 will completely blow Tanglewood away in2L single-thread performance:  this would be true even if AMD64 were still in aL 90 nm. process, though since AMD64 was slightly ahead of Itanic in moving toG 130 nm. and is scheduled to remain slightly ahead in the move to 90 nm.tK (where it will later get dual cores), AMD64 should be in 65 nm. by the times Tanglewood appears.e  I Since AMD64 already out-performs today's Madison, two process generationsmL down the road each of AMD64's two cores should offer 2x - 3x the performanceG of today's Madison - or of a single Tanglewood core - even if we ignoreeI whatever additional performance AMD's K9 core brings to the table.  So asnI well as having dramatically higher single-thread performance, the HammersmH that compete with Tanglewood will be able to give it at least reasonable3 competition on a per-chip throughput basis as well.e   ...o  ; > But where very large on-chip caches make sense is if theye > can be shared point-to-point..  I No.  They primarily make sense in helping to avoid not only off-chip, and E off-module, memory accesses but the bus activity involved in off-chip.K coordination (regardless of whether an off-chip read hits in someone else'st cache).      The "puny" 1.5 MByte L3 of > EV7e   That's 1.75 MB, sonny.  6  should become a 24, 48, 96 MByte L3 on IA64.  Turn it< > point-to-point and worst case 2-hop latency (8-way server)C > shouldn't be more than 30-40 nanoseconds access for a cache line.a  F BFD.  Opteron's *memory* latency isn't much higher than that - and itsC *remote* memory latency not much more than double that.  That's why I humongous caches are becoming *less* important in anything but systems soe? large that avoiding inter-module bus activity becomes critical.h  G > An 8-way with that much fast L3 ( 8 * 96 = 768 MBytes) should perform  > admirably.  1 As I noted, around the end of this decade.  Yawn.n   - bill   ------------------------------  % Date: Tue, 25 Nov 2003 16:44:03 -0500 * From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday2 Message-ID: <O-CdncZiT_qCUF6i4p2dnA@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:ExiFv198tRzB@eisner.encompasserve.org....@ > In article <09SdnV5YyfuYMl6i4p2dnA@metrocast.net>, "Bill Todd"  <billtodd@metrocast.net> writes: > >p >  > >rA > > Itanic performance is lack-lustre only by comparison with the>L > > historically-inflated claims for it (and with more recent claims, if youI > > compare real-world performance with some of the benchmark scores that  are>J > > being touted for it).  In absolute terms, its performance is certainlyH > > competitive - but that's not nearly sufficient to get many people to adopt atE > > new platform in preference to their tried-and-true existing ones.  > >i >CG > Why don't you say Itanium is mostly "leading" instead of competitive?n  , Because it's not leading - just competitive.  ( > SSL or a Web thing for Opteron?  Okay.  F That's a good start on explaining why my characterization is suitable.    But Itanium is leading in2 > tpmC (yes - not a single trailing number there).  I It trails rather badly behind POWER4+ in per-processor TPC-C performance.nJ We *are* talking about processors, here, right?  I mean, the fact that SunI (back when it used to submit TPC-C results) took far more processors than.L Alpha to achieve comparable results was something that *you* always chose to emphasize...  
 >  SAP - yes.u   Er, no.f  K If you've abandoned your historical position noted above that the number of L processors is significant, then you should note that the top 5 SAP SD 2-tierF positions are held by Sun and Fujitsu, with high-processor-count SPARCI systems.  If not, let's compare systems with equal numbers of processors:h  L 6th place is held by (gasp!) a 32-processor Marvel system - though there's aI good chance that a 32-processor POWER4+ system might edge it out for that J position (a previous-generation 1.3 GHz 32-processor POWER4 system is onlyI two positions behind, in 8th - after another high-processor-count Fujitsue system).  > The highest-placing 32-processor Itanic system is a brand-new,G top-of-the-line 1.5 GHz processor system from NEC - in 10th place, just 2 after yet another high-processor-count Sun system.  3 > SPECfp2000 - Opteron isn't even close to Itanium.e  K The one area where Itanic has a clear lead is in raw SPECfp and SPECfp_rate-J performance - though even there one should note that its power consumptionE is high enough that installations with limited cooling facilities canoJ achieve equivalent performance per Watt with AMD64 and noticeably *better*K performance per Watt with POWER4+.  Of course, SPECfp isn't really all thattJ significant for most commercially-important applications, but I'm happy to give credit where it's due.v     SPECint2000?  AMD C > has a 1376 base entry, Itanium has a 1322 entry.  Opteron squeekse > past Itanium there.   H Indeed it does - though if you want an AMD *server* processor that beatsG Itanic (which seems like a fairer comparison) you'll have to wait a fewy$ weeks until the x48 Opterons appear.   >sF > But to characterize Itanium performance as lack-lustre is a stretch.  I I guess in your haste to tout Itanic you must have missed the fact that IpG said exactly the same thing (noting that lack-lustre was an appropriatenJ characterization only when comparing Itanic performance with with inflatedC historical claims or when trying to relate its benchmark results tot real-world performance).   - bill   ------------------------------  % Date: Tue, 25 Nov 2003 14:35:36 -0500g* From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday2 Message-ID: <09SdnV5YyfuYMl6i4p2dnA@metrocast.net>  7 "JF Mezei" <jfmezei.spamnot@istop.com> wrote in messageJ# news:3FC33BA4.194AD3A0@istop.com.../* > Andrew Harrison SUNUK Consultancy wrote:? > > As always with Rob futures have a way of weaving themselvest= > > into the present to produce what appears to be a seamless-B > > proposition that in reality requires a working time machine to > > exploit. > K > In fairness though, doesn't IA64 currently have more "mainframe" featuresaF > allowing IA64 based machines to be built with many more processors ?  J Actually, no.  The *chipsets* that various OEMs like HP (and Intel itself,L though IIRC that tops out at 16 processors) have built around Itanic supportJ larger configurations than the on-chip AMD64 glue supports, but there's noL reason that someone couldn't build a large-system chipset around AMD64 (fromC what Sun is saying they're working with AMD on one, and others havecH reportedly been doing so for quite a while now:  I expect *something* to surface within a year).a    Doesn't/ > it have features that  Opteron doesn't have ?g  I Can't think of any, though that doesn't mean none exist.  Both chips haveu4 rather extensive built-in RAS features, for example.   >-C > Doesn't IA64 have lockstep installed right now ? (or is that also.	 somethingc( > that will happen only in the future ?)  G I believe it does.  And I also believe that means absolutely nothing todF anyone but Tandem customers:  no one else uses it or seems to have anyJ intention to - and while Tandem produces a very respectable niche product,K it has never shown any promise of taking over any significant percentage ofe
 the world.   >sK > So in that sense, Opteron for enterprise is also something that is in thee	 > future.v  C Only in the sense that chipsets supporting large systems aren't yetC* available:  the chip itself is fine as-is.  G  The difference is that Opteron is usable today for smaller servers and:L > workstations with tons of existing software, whereas IA64 is restricted to ag9 > very small niche market and has lacklustre performance.@  = Itanic performance is lack-lustre only by comparison with the H historically-inflated claims for it (and with more recent claims, if youI compare real-world performance with some of the benchmark scores that are F being touted for it).  In absolute terms, its performance is certainlyL competitive - but that's not nearly sufficient to get many people to adopt aA new platform in preference to their tried-and-true existing ones.b   - bill   ------------------------------  # Date: Wed, 26 Nov 2003 00:07:41 GMT-& From: Rick Jones <foo@bar.baz.invalid>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday2 Message-ID: <h9Swb.9710$dt6.1247@news.cpqcorp.net>  E >> But Itanium is leading in tpmC (yes - not a single trailing numbere
 >> there).  > > It trails rather badly behind POWER4+ in per-processor TPC-C > performance.    C You need to be more specific.  If you go to www.tpc.org and look ataB the data we have available to us (remember, us vendor types aren't> permitted to talk estimates), you get rather different results? depending on which system you examine to arrive at your derivedmD metric.  The results using the Superdome are indeed rather differentB than the results for the rx5670 if one is comparing with the p690.  
 rick jones  " so many ways to look at numbers...   -- bG oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates F these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...r   ------------------------------  % Date: Tue, 25 Nov 2003 15:14:09 -0500 * From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday2 Message-ID: <E_idnYQVBd6QJV6i4p2dnA@metrocast.net>  3 "jlsue" <jefflsxxxz@sbcglobal.net> wrote in messagep2 news:skq6svkgbtk9gn7a4740scb8eks2jenp0s@4ax.com...   ...a  8   Note that I am responding to Mr. Todd.  I am trying toH > understand the logic behind two different opinions I've seen come from him,L > namely:  a) DEC/CPQ/HPQ is bad because they decided to not invest in alphaK > to allow it to keep up, and b) Sun is not bad, even though it has decidedu$ > not to invest in Sparc to keep up.  H Note that you are rather carefully *not* responding to any opinions thatB I've offered, but to your own attempt to twist them.  Both of yourD characterizations of what I've said are incorrect, one might suspect
 deliberately:a  H a) DECpaq was incompetent because they decided not to invest in Alpha toI keep it *ahead* of the competition (it had no difficulty keeping up, evenlI after several years of neglect under Capellas) - and because they decided<K not to promote Alpha and the systems on it to make even better use of theiraI investments in them.  DECpaq was also unethical (to the point of outrightwK sleaziness:  no grey areas here) both for breaking very specific, repeated,UJ public promises to continue Alpha development and for brazenly lying aboutJ its reasons for doing so in an attempt to make the decision more palatableI to the customers who had depended upon the future of the platform becauseu' DECpaq *explicitly* encouraged them to.r  E b) In no way has Sun stated, or even suggested, that it's cutting offaI investment in SPARC.  Rather the reverse:  it's not only bringing current G SPARC efforts like USIV (and perhaps even USV - I haven't followed thisgK closely enough to knw) to market, but investing in a new SPARC architecturenL (Niagara) based on the IP it acquired with Afara and partnering with Fujitsu+ to share that company's OoO SPARC platform.l  E Your attempt to draw parallels between the two situations is far moretA reminiscent of so-called political 'debate' than of any objectiveaA evaluation.  Either you're too clueless to understand the radicaliJ differences between them, or too slimey to let those differences interfere- with your attempts to influence the gullible.<   - bill   ------------------------------    Date: 25 Nov 2003 14:55:58 -0600+ From: young_r@encompasserve.org (Rob Young)RB Subject: Re: Sun to use AMD Opteron - announcement expected Monday3 Message-ID: <ExiFv198tRzB@eisner.encompasserve.org>R  _ In article <09SdnV5YyfuYMl6i4p2dnA@metrocast.net>, "Bill Todd" <billtodd@metrocast.net> writes:e >    > ? > Itanic performance is lack-lustre only by comparison with theRJ > historically-inflated claims for it (and with more recent claims, if youK > compare real-world performance with some of the benchmark scores that are H > being touted for it).  In absolute terms, its performance is certainlyN > competitive - but that's not nearly sufficient to get many people to adopt aC > new platform in preference to their tried-and-true existing ones.r >   H 	Why don't you say Itanium is mostly "leading" instead of competitive?  B 	SSL or a Web thing for Opteron?  Okay. But Itanium is leading in ? 	tpmC (yes - not a single trailing number there).  SAP - yes.  -F 	SPECfp2000 - Opteron isn't even close to Itanium.  SPECint2000?  AMD C 	has a 1376 base entry, Itanium has a 1322 entry.  Opteron squeeks   	past Itanium there.  E 	But to characterize Itanium performance as lack-lustre is a stretch..@ 	Opteron's SPECfp2000 performance is poor as is its tpmC numbersD 	compared to Itanium.  Wouldn't that be a fairer assessment?  I meanB 	there are Itanim SPECfp numbers of 2100+ versus Opteron of 1300+,> 	doesn't that in a sense make the Opteron numbers laughable inA 	comparison?  So then how would a claim of "lack-lusterness" evenl( 	be viable at all - Opteron vs. Itanium?   				Rob'   ------------------------------  % Date: Tue, 25 Nov 2003 16:04:32 -0500c* From: JF Mezei <jfmezei.spamnot@istop.com>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday) Message-ID: <3FC3C3DB.33719FC5@istop.com>a   jlsue wrote:L > namely:  a) DEC/CPQ/HPQ is bad because they decided to not invest in alphaK > to allow it to keep up, and b) Sun is not bad, even though it has decidedl$ > not to invest in Sparc to keep up.  J Compaq made a conscious decision to abandon a better product so as to helpJ maintain good relationship with Intel even of Alpha, combined with VMS andK Tru64 generated more profit than wintel crap the deal was intented to help.s  M Sun hasn't abandonned SPARC development, they have lately been a tad short of J profits so they can't spend all. Their recent deal with Futjitsu is a goodF indication that they are not winding down SPARC at this point in time.  M HP's announcements that they won't even honour the "Plan of record" that they.G had promised to honour, combined with Carly statements admitting HP wasoM winding down Alpha faster than had originally been planned is quite differente from Sun handling of SPARC.   E HP doesn't care about VMS or Tru64, its core business are printer/ink>M cartridges, followed by wintel to help its freinds at microsoft and intel. So * HP doesn't car about losing VMS custoemrs.  N Sun knows that its core business depends on Solaris and Sparc. Sun cares aboutK having competition and knows that because of IBM, Sun must still make SparcaL better. It would be suicide for Sun to abandon Sparc today and be restricted7 to the smaller systems AMD's 8086 can handle right now.a   ------------------------------  % Date: Tue, 25 Nov 2003 16:20:00 -0500p* From: JF Mezei <jfmezei.spamnot@istop.com>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday) Message-ID: <3FC3C77A.CACB9010@istop.com>F   John Smith wrote:AL > c) What Sun has not said is that they are killing Sparc. They are spendingM > money on three parallel tracks ( Sparc/Sun, Sparc/Sun/Fujitsu, AMD/Sun) andrA > seeing which way their customers and the technology steer them..   I view it this way:n  L Sun continues to develop Solaris for Sparc, and will use Fujitsu built SparcK chips for some systems, and Sun continues to develop Solaris for 8086, with  support for 64 bit 8086.  N To me, the Fujitsu deal is no different that if Digital had made better use ofM the Samsung partnership to use Samsung built chips. And the Support of AMD 64 L buit 8086 is no different than Apple adopting the 64 bit Power , moving from$ the older 32 bit Power architecture.    H Sun already has support to 8086 architecture.  If/when that architectureJ scales up to the large systems Sparc is capable of, then pershaps Sun willN have to make a serious decision. But until that time, Sun has no choice but toM continue to agressively develop Sparc as much as it can afford to do in orderTI to compete against IBM's Power. (IA64 isn't really in the competition for 9 another few years due to lack of software for one thing).n   ------------------------------    Date: 25 Nov 2003 15:53:43 -0600+ From: young_r@encompasserve.org (Rob Young)dB Subject: Re: Sun to use AMD Opteron - announcement expected Monday3 Message-ID: <1e0Ge5c8Eb90@eisner.encompasserve.org>,  _ In article <EfOdnfFBCbpXX16i4p2dnA@metrocast.net>, "Bill Todd" <billtodd@metrocast.net> writes:d > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:GndLTSmqlLxw@eisner.encompasserve.org...sI >> In article <bpvb4s$mo4$1@new-usenet.uk.sun.com>, Andrew Harrison SUNUK2= > Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes:c >> > Rob Young wrote:c >  > ...g > H >> >> Since high-k runs much cooler, certainly they could create largishH >> >> (300-400 mm2) CPUs that contain 96 MByte on-chip cache and consume/ >> >> far less power, generate a lot less heat.e > G > Gee, Rob - you're even surpassing your usual selling-of-futures here.e > N > The 90 nm. Montecito will be hard-pressed to fit 24 MB of on-chip cache intoN > a chip pushing 500 mm^2.  Two process shrinks later (45 nm., due - one mightK > suspect optimistically, at least for use in Itanic - in 2007) you'd stillsJ > need close to 500 mm^2 to get 96 MB on the chip.  So you must be talking> > about a 32 nm. process, right around the end of this decade. >   @ 	I don't know.  high-k is a different process.  They lay it down: 	one molecular layer at a time.  Maybe cache density could8 	increase - but don't know.  We'll know more later.  ButD 	I wouldn't be surprised if they increased transistor density movingE 	to high-k.  I could be totally wrong , but that wouldn't be anything  	new.-   >   The "puny" 1.5 MByte L3 of >> EV7 >  > That's 1.75 MB, sonny. >    	Right.i  8 >  should become a 24, 48, 96 MByte L3 on IA64.  Turn it= >> point-to-point and worst case 2-hop latency (8-way server) D >> shouldn't be more than 30-40 nanoseconds access for a cache line. > H > BFD.  Opteron's *memory* latency isn't much higher than that - and itsE > *remote* memory latency not much more than double that.  That's whytK > humongous caches are becoming *less* important in anything but systems sotA > large that avoiding inter-module bus activity becomes critical.u >   B 	Well ... it is.  If it was close, I wouldn't quibble, but here is 	what it is for a 4-way:  % http://www.devx.com/amd/Article/17580N  I A unique benefit to the Opteron processor (and other AMD64 processors) is.M Coherent HyperTransport Technology for glueless multiprocessor systems, which O eliminates Northbridge contention, minimizing memory latency in multi-processorhH systems. In fact, between-processor memory latencies are under 105ns forH dual-processor platforms, and under 140ns for four-processor platforms.   B 	If an 8-way could do 30-40 ns cache access, that is significantly$ 	better than a 140 ns memory access.  H >> An 8-way with that much fast L3 ( 8 * 96 = 768 MBytes) should perform
 >> admirably.l > 3 > As I noted, around the end of this decade.  Yawn.g >   ? 	Doesn't matter.  They won't be SPARC'ing it up until then.  SorA 	maybe they are number 2 in performance until then?  But it seemsoC 	on-chip memory controllers is the only way to access large amountsi, 	of cache and stay very fast in the process.   				Robf   ------------------------------  % Date: Tue, 25 Nov 2003 17:34:51 -0500 * From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday2 Message-ID: <zKedncFhovmVRF6iRVn-sw@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:1e0Ge5c8Eb90@eisner.encompasserve.org...n@ > In article <EfOdnfFBCbpXX16i4p2dnA@metrocast.net>, "Bill Todd"  <billtodd@metrocast.net> writes: > >)< > > "Rob Young" <young_r@encompasserve.org> wrote in message1 > > news:GndLTSmqlLxw@eisner.encompasserve.org...o   ...w  : > >  should become a 24, 48, 96 MByte L3 on IA64.  Turn it? > >> point-to-point and worst case 2-hop latency (8-way server) F > >> shouldn't be more than 30-40 nanoseconds access for a cache line. > >sJ > > BFD.  Opteron's *memory* latency isn't much higher than that - and itsG > > *remote* memory latency not much more than double that.  That's why J > > humongous caches are becoming *less* important in anything but systems soC > > large that avoiding inter-module bus activity becomes critical.  > >i >a > Well ... it is.t  
 No, it's not.d  2   If it was close, I wouldn't quibble, but here is > what it is for a 4-way:0 >u' > http://www.devx.com/amd/Article/17580  >jK > A unique benefit to the Opteron processor (and other AMD64 processors) isgI > Coherent HyperTransport Technology for glueless multiprocessor systems,r whichsA > eliminates Northbridge contention, minimizing memory latency ins multi-processor J > systems. In fact, between-processor memory latencies are under 105ns forI > dual-processor platforms, and under 140ns for four-processor platforms.   K And the previous paragraph notes that local memory latency *today* is undereK 60 ns. - which, just as I said, isn't all that much higher in reality today2L than the hypothetical end-of-this-decade 30 ns. - 40 ns. remote-cache-accessJ figure you provided.  Nor is 105 ns. - again, *today* - all that much moreI than double that hypothetical figure.  140 ns. is starting to become morecB significant, but that number should drop markedly by the time your1 hypothetical platforms arrives - if it ever does.d   >tC > If an 8-way could do 30-40 ns cache access, that is significantlye% > better than a 140 ns memory access.>  J And having 8 GB (today - more like 64 GB or more by the end of the decade)J at each remote end of that 140 ns. access (which will be a lot faster thanL 140 ns. by the time the end of the decade rolls around) provides a hell of aJ lot more usable data than having your hypothetical 96 *MB* L3 cache there.I Humongous caches become far less important (as I already noted) when theyhI don't offer close to an order of magnitude faster access than main memoryl does.    >eJ > >> An 8-way with that much fast L3 ( 8 * 96 = 768 MBytes) should perform > >> admirably.o > >i5 > > As I noted, around the end of this decade.  Yawn.  > >e > @ > Doesn't matter.  They won't be SPARC'ing it up until then.  SoB > maybe they are number 2 in performance until then?  But it seemsD > on-chip memory controllers is the only way to access large amounts- > of cache and stay very fast in the process.s  J SPARC has had on-chip memory controllers for the past 2 years, Rob.  Sun'sJ SPARC core may process data in a somewhat leisurely fashion, but it scalesJ quite well indeed - unlike Itanic (save for SGI's use of it, where they're? too shy to provide commercially-significant benchmark results)._   - bill   ------------------------------  % Date: Tue, 25 Nov 2003 17:44:51 -0500X* From: JF Mezei <jfmezei.spamnot@istop.com>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday( Message-ID: <3FC3DB57.D57DBF9@istop.com>   Bill Todd wrote:N > The 90 nm. Montecito will be hard-pressed to fit 24 MB of on-chip cache into > a chip pushing 500 mm^2. -  M If IA64 has , up to now, managed to shed its Merced image by adding enourmous N amounts of cache to give it less laughable performance, isn't there a point at9 which adding more cache will yield negative performance ?O  N Or can cache scale without any performance impact ? (isn't there some index toK search to see if desired memory is already in cache ?, and what about multirK processor systems where one processor writing to a specific memory location P should invalidate any cache another processor may have of that memory location ?  K Also, is there a point where adding more cache won't give any added benefit ; because your current processes already fit into the cache ?   4 > Two process shrinks later (45 nm., due - one mightK > suspect optimistically, at least for use in Itanic - in 2007) you'd stilla3 > need close to 500 mm^2 to get 96 MB on the chip. T  L Only time will tell whether the complex/bloated IA64 architecture will allowM Intel to keep up with the Jones' in terms of how fast they can generate a new I IA64 with the latest and greatest fab technologies.  Seems to me that theaN simpler 8086 would be first to market with smaller process/new fab technology.  I And one must not forget that IA64 is far more dependant on compilers thaneM other platforms. This means that Intel must be able to spew out the compilers I that match the current IA64. The big question is whether ISVs will supplyDJ multiple binaries so that the binary will best match whatever iteration oaI IA64 a customer is running. Otherwise, performance won't be anywhere nearI3 those fantasy numbers HP/Intel will be spewing out.l  M Only time will tell if Intel can change. So far, if IA64's past history is toa: continue, IA64 won't be very impressive over the long run.   ------------------------------  % Date: Tue, 25 Nov 2003 18:07:04 -0500e* From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday2 Message-ID: <NPGdnfiukrsIfV6iRVn-hA@metrocast.net>  7 "JF Mezei" <jfmezei.spamnot@istop.com> wrote in message<" news:3FC3DB57.D57DBF9@istop.com... > Bill Todd wrote:K > > The 90 nm. Montecito will be hard-pressed to fit 24 MB of on-chip cache. into > > a chip pushing 500 mm^2. >rE > If IA64 has , up to now, managed to shed its Merced image by adding,	 enourmous G > amounts of cache to give it less laughable performance, isn't there af point at; > which adding more cache will yield negative performance ?b  I Typically, no.  But it does take up room on the chip that might be put tou) far better use (as EV7 has, for example).    >kG > Or can cache scale without any performance impact ? (isn't there somes index toG > search to see if desired memory is already in cache ?, and what aboutr multihD > processor systems where one processor writing to a specific memory locationG > should invalidate any cache another processor may have of that memory-
 location ?  K Directory-based cache coherence largely takes care of that overhead.  Cache  is almost always a net win.    >PE > Also, is there a point where adding more cache won't give any addedt benefit = > because your current processes already fit into the cache ?o  H Only for that specific workload.  And bloat, like entropy, seems only to increase over time.m   - bill   ------------------------------    Date: 25 Nov 2003 21:23:23 -0600+ From: young_r@encompasserve.org (Rob Young)iB Subject: Re: Sun to use AMD Opteron - announcement expected Monday3 Message-ID: <O8sfr9CvBe1y@eisner.encompasserve.org>   _ In article <O-CdncZiT_qCUF6i4p2dnA@metrocast.net>, "Bill Todd" <billtodd@metrocast.net> writes:n > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:ExiFv198tRzB@eisner.encompasserve.org...mA >> In article <09SdnV5YyfuYMl6i4p2dnA@metrocast.net>, "Bill Todd"s" > <billtodd@metrocast.net> writes: >> > >> >> >B >> > Itanic performance is lack-lustre only by comparison with theM >> > historically-inflated claims for it (and with more recent claims, if youWJ >> > compare real-world performance with some of the benchmark scores that > areoK >> > being touted for it).  In absolute terms, its performance is certainly I >> > competitive - but that's not nearly sufficient to get many people toc	 > adopt arF >> > new platform in preference to their tried-and-true existing ones. >> > >>    H >> Why don't you say Itanium is mostly "leading" instead of competitive? > . > Because it's not leading - just competitive. > ) >> SSL or a Web thing for Opteron?  Okay.m > H > That's a good start on explaining why my characterization is suitable. >  >  But Itanium is leading in3 >> tpmC (yes - not a single trailing number there).V > K > It trails rather badly behind POWER4+ in per-processor TPC-C performance.y  D 	Per processor tpmC performance?  Come on, you're not going to startE 	talking about SpecInt per MHz are you?  Wouldn't the best comparisonm? 	be total tpmC performance and $/tpmC?  After all, that is what > 	the TPC council touts.  Or realworld, if you have budget, youC 	can buy the 4 CPU power or 4 CPU SPARC and associated DB licenses,l 	what to choose?  Simple.   L > We *are* talking about processors, here, right?  I mean, the fact that SunK > (back when it used to submit TPC-C results) took far more processors thanuN > Alpha to achieve comparable results was something that *you* always chose to > emphasize... > > 	Still do.  Because Oracle is $40000 per CPU and DB2 is $33000: 	per CPU.  If buying a 4 processor box you can go with theA 	under-whelming 4 CPU SPARC or a much higher powered Itanium box.q  @ 	So wouldn't the 32 procssor Power4 box make more sense than theA 	64 processor SuperDome?  Depends.  You may want to run a DB thatb= 	delivers the most bang for the buck - MSSQL.  At $16541 per nA 	CPU it helped HP turn in a higher tpmC number than IBM and much r4 	cheaper, $6.49 $/tpmC for HP, $8.55 $/tpmC for IBM.  A 	There are several directions we can explore here regarding cost,n 	performance , DBs, etc.   >>  SAP - yes. > 	 > Er, no.s > M > If you've abandoned your historical position noted above that the number ofnN > processors is significant, then you should note that the top 5 SAP SD 2-tierH > positions are held by Sun and Fujitsu, with high-processor-count SPARCK > systems.  If not, let's compare systems with equal numbers of processors:u > N > 6th place is held by (gasp!) a 32-processor Marvel system - though there's aK > good chance that a 32-processor POWER4+ system might edge it out for that.L > position (a previous-generation 1.3 GHz 32-processor POWER4 system is onlyK > two positions behind, in 8th - after another high-processor-count Fujitsu 
 > system).    @ 	Well - yeah.  I wouldn't claim they had the highest SAP numbersB 	across the board.  Sorry for not being clear there.  They do lead> 	in 4-way and 8-way.  In fact, 2 weeks ago IBM posted a 4-way B 	Itanium SAP 2-tier that is 199000 dialog steps/hour.  By the way,B 	that 32-processor Marvel is in 7th place now, a 32-way NEC passed, 	it.  That ideasinternational list is dated.   > @ > The highest-placing 32-processor Itanic system is a brand-new,I > top-of-the-line 1.5 GHz processor system from NEC - in 10th place, juste4 > after yet another high-processor-count Sun system. >   / 	No.  6th place now.  That ideas list is stale.i  4 >> SPECfp2000 - Opteron isn't even close to Itanium. > M > The one area where Itanic has a clear lead is in raw SPECfp and SPECfp_rate L > performance - though even there one should note that its power consumptionG > is high enough that installations with limited cooling facilities canoL > achieve equivalent performance per Watt with AMD64 and noticeably *better*M > performance per Watt with POWER4+.  Of course, SPECfp isn't really all thatnL > significant for most commercially-important applications, but I'm happy to > give credit where it's due.i >    	performance per watt?  1 	Another area it is a clear leader is 4-way tpmC.s   >   SPECint2000?  AMDdD >> has a 1376 base entry, Itanium has a 1322 entry.  Opteron squeeks >> past Itanium there. > J > Indeed it does - though if you want an AMD *server* processor that beatsI > Itanic (which seems like a fairer comparison) you'll have to wait a fewm& > weeks until the x48 Opterons appear. >    okay   >>G >> But to characterize Itanium performance as lack-lustre is a stretch.h > K > I guess in your haste to tout Itanic you must have missed the fact that ITI > said exactly the same thing (noting that lack-lustre was an appropriatehL > characterization only when comparing Itanic performance with with inflatedE > historical claims or when trying to relate its benchmark results tod > real-world performance). >   3 	Itanium leads in many metrics.  To characterize itgF 	as lackluster is a stretch.  SPARC is lackluster, MIPS is lackluster. 	Certainly not Itanium.n 	l 				Robn   ------------------------------    Date: 25 Nov 2003 21:49:12 -0600+ From: young_r@encompasserve.org (Rob Young)bB Subject: Re: Sun to use AMD Opteron - announcement expected Monday3 Message-ID: <5+nZaL7PLhgf@eisner.encompasserve.org>e  _ In article <zKedncFhovmVRF6iRVn-sw@metrocast.net>, "Bill Todd" <billtodd@metrocast.net> writes:e > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:1e0Ge5c8Eb90@eisner.encompasserve.org...oA >> In article <EfOdnfFBCbpXX16i4p2dnA@metrocast.net>, "Bill Todd"6" > <billtodd@metrocast.net> writes: >> >= >> > "Rob Young" <young_r@encompasserve.org> wrote in message 2 >> > news:GndLTSmqlLxw@eisner.encompasserve.org... >  > ...f > ; >> >  should become a 24, 48, 96 MByte L3 on IA64.  Turn ita@ >> >> point-to-point and worst case 2-hop latency (8-way server)G >> >> shouldn't be more than 30-40 nanoseconds access for a cache line.  >> >K >> > BFD.  Opteron's *memory* latency isn't much higher than that - and itseH >> > *remote* memory latency not much more than double that.  That's whyK >> > humongous caches are becoming *less* important in anything but systemsi > soD >> > large that avoiding inter-module bus activity becomes critical. >> > >> >> Well ... it is. >  > No, it's not.- > 4 >   If it was close, I wouldn't quibble, but here is >> what it is for a 4-way: >>( >> http://www.devx.com/amd/Article/17580 >>L >> A unique benefit to the Opteron processor (and other AMD64 processors) isJ >> Coherent HyperTransport Technology for glueless multiprocessor systems, > whichdB >> eliminates Northbridge contention, minimizing memory latency in > multi-processorcK >> systems. In fact, between-processor memory latencies are under 105ns fortJ >> dual-processor platforms, and under 140ns for four-processor platforms. > M > And the previous paragraph notes that local memory latency *today* is undersM > 60 ns. - which, just as I said, isn't all that much higher in reality today8N > than the hypothetical end-of-this-decade 30 ns. - 40 ns. remote-cache-accessL > figure you provided.  Nor is 105 ns. - again, *today* - all that much moreK > than double that hypothetical figure.  140 ns. is starting to become moreoD > significant, but that number should drop markedly by the time your3 > hypothetical platforms arrives - if it ever does.U >   @ 	Why bring up single processor performance?  I'm saying an 8-way@ 	could do 30-40 ns versus 4-way of 140 ns.  Also, as clock speed@ 	increases remote cache speed decreases.  EV7 has load to use of? 	15 ns for remote cache line (one hop).  Double the clock speedn? 	and those same 15 clock cycles to lock and load remotely turnsi; 	into 7.5 ns remote cache line access.  Double that and add B 	fudge factor to get remote cache lines 2 hops away.  Point is the< 	routers get faster as the CPUs get faster.  Bus speeds?  We9 	see 533 MHz FSB today, maybe the doubles in a few years.n   >  >>K >> >> An 8-way with that much fast L3 ( 8 * 96 = 768 MBytes) should performi >> >> admirably. >> >6 >> > As I noted, around the end of this decade.  Yawn. >> > >>A >> Doesn't matter.  They won't be SPARC'ing it up until then.  SotC >> maybe they are number 2 in performance until then?  But it seemstE >> on-chip memory controllers is the only way to access large amountsi. >> of cache and stay very fast in the process. > L > SPARC has had on-chip memory controllers for the past 2 years, Rob.  Sun'sL > SPARC core may process data in a somewhat leisurely fashion, but it scalesL > quite well indeed - unlike Itanic (save for SGI's use of it, where they'reA > too shy to provide commercially-significant benchmark results).o >   / 	But they have poor latencies.  SPARCing it up:r  K Considering that the Sun Fire 15K can support as much as half a terabyte ofbK memory in a single domain, it is extremely important that data be stored as $ close to the processors as possible.  H For example, when the CPUs feed off data within their own Uniboard, theyM typically experience latency of roughly 180 nanoseconds. Latency increases torM as much as 440 ns when CPUs have to request data from memory modules in other4K Uniboards because the request needs to travel over the server interconnect.     > 	It isn't just about the memory controllers.  The part that isA 	just as important in my opinion is the on-chip routers.  Imagine-B 	if they could increase cache size to 96 MBytes, crank the CPUs to> 	3 GHz, 8 CPUs with routers, you would have > 750 MBytes of L3E 	cache with remote 2-hop L3 access of 10-15 ns.  Large on-chip cachesiC 	at that point would be quite a bit faster than main memory access. F 	So sure - large on-chip caches make little sense otherwise.  If IntelB 	couldn't stay ahead of main memory access or as you point out the? 	difference becomes less of a differentiator - they are foolishtC 	in pursing such developements.  I don't think they are foolish but " 	know exactly what they are doing.   				Rob    ------------------------------  % Date: Wed, 26 Nov 2003 01:14:45 -0500 * From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday2 Message-ID: <cOadnewP4ZtP2VmiRVn-gg@metrocast.net>  3 "Rick Jones" <foo@bar.baz.invalid> wrote in message , news:h9Swb.9710$dt6.1247@news.cpqcorp.net...G > >> But Itanium is leading in tpmC (yes - not a single trailing numbere > >> there). >s@ > > It trails rather badly behind POWER4+ in per-processor TPC-C > > performance. >yE > You need to be more specific.  If you go to www.tpc.org and look ataD > the data we have available to us (remember, us vendor types aren't@ > permitted to talk estimates), you get rather different resultsA > depending on which system you examine to arrive at your derivedlF > metric.  The results using the Superdome are indeed rather differentD > than the results for the rx5670 if one is comparing with the p690.  L Sorry - I haven't looked recently.  Has IBM submitted a p690 1.7 GHz POWER4+K result other than for their 32-processor system?  If not, comparing againstfD Itanic 32-processor results is the only direct comparison available.   - bill   ------------------------------  % Date: Tue, 25 Nov 2003 14:49:16 -0600s( From: brandon@dalsemi.com (John Brandon) Subject: TELENT in batch1 Message-ID: <03112514491612@dscis6-0.dalsemi.com>t  B I have a user that is asking me about using TELNET in a batch job." My response is to use RSH instead.  : Just out of curiousity, can TELNET be used in a batch job?   Why or why not?w     J*o*h*n B*r*a*n*d*o*n  VMS Systems Administratore* firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  + Date: Tue, 25 Nov 2003 21:29:02 +0000 (UTC)t. From: Dale Dellutri <ddelQQQlutr@panQQQix.com> Subject: Re: TELENT in batch, Message-ID: <bq0hiu$a4i$1@reader2.panix.com>  M On Tue, 25 Nov 2003 14:49:16 -0600, John Brandon <brandon@dalsemi.com> wrote:eD > I have a user that is asking me about using TELNET in a batch job.$ > My response is to use RSH instead.< > Just out of curiousity, can TELNET be used in a batch job? > Why or why not?   ? The problem is scripting the responses.  We use kermit for thisuD purpose, and kermit's telnet.  Kermit has good scripting capability.   -- h7 Dale Dellutri <ddelQQQlutr@panQQQix.com> (lose the Q's)e   ------------------------------  % Date: Tue, 25 Nov 2003 20:43:04 -0600 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>n Subject: Re: TELENT in batch' Message-ID: <3FC41338.B9D540B1@fsi.net>n   Dale Dellutri wrote: > O > On Tue, 25 Nov 2003 14:49:16 -0600, John Brandon <brandon@dalsemi.com> wrote:aF > > I have a user that is asking me about using TELNET in a batch job.& > > My response is to use RSH instead.> > > Just out of curiousity, can TELNET be used in a batch job? > > Why or why not?r > A > The problem is scripting the responses.  We use kermit for thisTF > purpose, and kermit's telnet.  Kermit has good scripting capability.  / Kermit has MARVELOUS(!!!) scripting capability!e  
 To the OP:  E Your response is quite correct, IMO. I'm using RSH to interact with a@D Solaris box running a tape library management application (ACSLS) in batch and in .COM proc.'s.   -- a David J. Dachtera  dba DJE Systemso http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/b   ------------------------------  % Date: Tue, 25 Nov 2003 11:21:05 -0800a3 From: "Russ Forster" <Russ.Forster@GEMS1.Gov.BC.CA>t
 Subject: testn+ Message-ID: <3fc3aba1$1@obsidian.gov.bc.ca>    test   ------------------------------  % Date: Tue, 25 Nov 2003 11:26:05 -0800r5 From: "Fred Hoenisch" <Fred.Hoenisch@gems9.gov.bc.ca>t) Subject: test - previously unable to posto+ Message-ID: <3fc3accc$1@obsidian.gov.bc.ca>p   --J Disclaimer: Any comments made are personal and do not reflect the thoughts or policies of this company.   ------------------------------  % Date: Tue, 25 Nov 2003 20:05:18 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com> Subject: Wildcard searchinga) Message-ID: <3FC3FC39.2FCEF1C9@istop.com>o    I have a buffer containing text.  H I'd like to provide a function to do wildcard searches which returns the position inside that buffer.  H STR$MATCH_WILD has the widlcard support, but returns essentially true orS false, and I would have to add * to both the start and end of the pattern to match.m  N (eg, if looking for choco*te , I would have to give STR$MATCH_WILD  *choco*ta*N in which case, it would return the first byte since the whole 2000 line buffer would match.  . Is there a magical routine that handles this ?   (programming language is C).   ------------------------------  % Date: Tue, 25 Nov 2003 18:06:11 -0800m# From: "Tom Linden" <tom@kednos.com>> Subject: RE: Wildcard searchinge9 Message-ID: <CIEJLCMNHNNDLLOOGNJIGELBIIAA.tom@kednos.com>6  B I have seen in the past implementations for C of the PL/I builtin,' Index, whose semantics are described inb3 http://www.kednos.com/6291pro_037.html#index_x_1662s  A Of course you could always right a one line PL/I subroutine whichw' returns the position to your C program.    >-----Original Message----- 2 >From: JF Mezei [mailto:jfmezei.spamnot@istop.com]) >Sent: Tuesday, November 25, 2003 5:05 PM  >To: Info-VAX@Mvb.Saic.Com >Subject: Wildcard searching >  >p! >I have a buffer containing text.r >lI >I'd like to provide a function to do wildcard searches which returns thee >position inside that buffer.r >hI >STR$MATCH_WILD has the widlcard support, but returns essentially true oraC >false, and I would have to add * to both the start and end of the t >pattern to match. >aD >(eg, if looking for choco*te , I would have to give STR$MATCH_WILD  > *choco*ta*D >in which case, it would return the first byte since the whole 2000  >line buffer
 >would match.t > / >Is there a magical routine that handles this ?e >  >(programming language is C).h >o >---' >Incoming mail is certified Virus Free.r; >Checked by AVG anti-virus system (http://www.grisoft.com).eB >Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003 >n --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).A Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003t   ------------------------------  % Date: Tue, 25 Nov 2003 18:23:57 -0800n# From: "Tom Linden" <tom@kednos.com>t Subject: RE: Wildcard searchingn9 Message-ID: <CIEJLCMNHNNDLLOOGNJIOELBIIAA.tom@kednos.com>    >-----Original Message-----l) >From: Tom Linden [mailto:tom@kednos.com]n) >Sent: Tuesday, November 25, 2003 6:06 PM  >To: Info-VAX@Mvb.Saic.Com  >Subject: RE: Wildcard searching >s >eC >I have seen in the past implementations for C of the PL/I builtin,s( >Index, whose semantics are described in4 >http://www.kednos.com/6291pro_037.html#index_x_1662 >bB >Of course you could always right a one line PL/I subroutine which(                             write       ( >returns the position to your C program. >i >>-----Original Message-----3 >>From: JF Mezei [mailto:jfmezei.spamnot@istop.com]-* >>Sent: Tuesday, November 25, 2003 5:05 PM >>To: Info-VAX@Mvb.Saic.Com  >>Subject: Wildcard searchingt >> >>" >>I have a buffer containing text. >>J >>I'd like to provide a function to do wildcard searches which returns the >>position inside that buffer. >>J >>STR$MATCH_WILD has the widlcard support, but returns essentially true orD >>false, and I would have to add * to both the start and end of the  >>pattern to match.  >>E >>(eg, if looking for choco*te , I would have to give STR$MATCH_WILD h
 >> *choco*ta*rE >>in which case, it would return the first byte since the whole 2000 c
 >>line buffer  >>would match. >>0 >>Is there a magical routine that handles this ? >> >>(programming language is C). >> >>--- ( >>Incoming mail is certified Virus Free.< >>Checked by AVG anti-virus system (http://www.grisoft.com).C >>Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003g >> >---' >Outgoing mail is certified Virus Free.r; >Checked by AVG anti-virus system (http://www.grisoft.com). B >Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003 >2 >---' >Incoming mail is certified Virus Free..; >Checked by AVG anti-virus system (http://www.grisoft.com).sB >Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003 >n ---s& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).A Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003k   ------------------------------  % Date: Tue, 25 Nov 2003 15:50:02 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>" Subject: Re: [OT] For David CATHEY) Message-ID: <3FC3C076.81ABE923@istop.com>    Didier Morandi wrote: O > > <webmaster@montagar.com>: host pelican.montagar.com[209.39.152.5] said: 554p2 > >     Message rejected as spam. Have a nice day.  I 209.39.152.5 doesn't resolve to a host name. Ask verio, the owner of thatdM address to add it to their DNS database for reverse translations. Blocking anSM email from a server whose IP address doesn't translate back to a host name is. very very common.o  K Also, don't be surprised if your nerim.net address gets blocked since nerimi. hosts one of the infamous anonymous remailers.   ------------------------------  % Date: Wed, 26 Nov 2003 06:26:48 +0100t- From: Didier Morandi <Didier.Morandi@free.fr>m" Subject: Re: [OT] For David CATHEY' Message-ID: <3FC43997.7A6733E5@free.fr>T   JF Mezei a *crit :   > Didier Morandi wrote:iQ > > > <webmaster@montagar.com>: host pelican.montagar.com[209.39.152.5] said: 554s4 > > >     Message rejected as spam. Have a nice day. >eK > 209.39.152.5 doesn't resolve to a host name. Ask verio, the owner of that O > address to add it to their DNS database for reverse translations. Blocking anrO > email from a server whose IP address doesn't translate back to a host name iss > very very common.a >iM > Also, don't be surprised if your nerim.net address gets blocked since nerime0 > hosts one of the infamous anonymous remailers.  J So, as I have Nerim at home and Wanamou in my office, if I want to give anR international expansion to my company I may consider a T1 link and process my mailP by myself (as soon  as I have read and understood that obscure part of VMS which is SMTP...)8   D.   ------------------------------   End of INFO-VAX 2003.655 ************************