1 INFO-VAX	Tue, 25 Nov 2003	Volume 2003 : Issue 654       Contents: Re: A sort of a "me too"1 Anybody monitoring vmsnet.sdk.openvms.fieldtest ? 5 Re: Anybody monitoring vmsnet.sdk.openvms.fieldtest ? 5 Re: Anybody monitoring vmsnet.sdk.openvms.fieldtest ?  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  RE: Backwards File Dump  Re: Backwards File Dump  RE: Backwards File Dump  Re: RE: Backwards File Dump  RE: 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: Building a cluster using HP's SBW program 8 Re: DCL Enhancements: Error messages for OPEN and DEFINE= DCL procedure to monitor disk space and purge or delete files A Re: DCL procedure to monitor disk space and purge or delete files A Re: DCL procedure to monitor disk space and purge or delete files @ Re: Dell drops call centers in India - HP thinks it is a winner! Re: Disk cluster size question, Re: Fonts for printing from a decwindows app, Re: Fonts for printing from a decwindows app Ghostscript ) Re: Hobbyist license and layered products ) Re: Hobbyist license and layered products / Re: Hobbyist license and layered products - SLS P HPember VAX/VMS to Itanium Migration Newsletter: table of contents (fyi) (fyi)(f Re: IA64 TPC results- Low Cost maintenance contracts USA and Europe 5 Re: New maynagement software Nimbus also for OpenVMS? A Re: odd SMTP e-mail when sending to page.metrocall.com (RESOLVED)  Re: ODS2 file header
 OT: Quotes Re: OT: Quotes Qio ? 	 Re: Qio ? & Re: Required reading for HP executives& Re: Required reading for HP executives& Re: Required reading for HP executives& Re: Required reading for HP executives& Re: Required reading for HP executives& Re: Required reading for HP executives$ Re: Routable Protocol for Clustering SimH: no cluster connection  Re: SimH: no cluster connection  Re: SQLSRV V7.1-5 Problem  Re: SQLSRV V7.1-5 Problem 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 P The DCL minute of the day (was: DCL Enhancements: Error messages for OPEN and DE2 Re: VMS could save the world ! (asteroid research)2 Re: VMS could save the world ! (asteroid research)2 Re: VMS could save the world ! (asteroid research)= Re: [OT] - pot calls kettle black (Was: Re: IA64 TPC results)  [OT] For David CATHEY  Re: [OT] For David CATHEY 9 [SURVEY] Do you use VAX/VMS SW not ported to OpenVMS i64? = Re: [SURVEY] Do you use VAX/VMS SW not ported to OpenVMS i64?   F ----------------------------------------------------------------------    Date: 25 Nov 2003 05:57:53 -08001 From: keithparris_NOSPAM@yahoo.com (Keith Parris) ! Subject: Re: A sort of a "me too" = Message-ID: <cf15391e.0311250557.43bb6a47@posting.google.com>   E Best of luck, Carl.  I went through a period of 11 months with only 3 E weeks of work and thought I might well have to throw away two decades D plus of VMS experience and work with Linux or (even worse) Windows. D But I was blessed with the chance to continue working with VMS, as I hope you will be.   D One good sign is that after 18-24 months of silence, I've started toC 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>... J > Having said this, I think that VMS management are just like white fluffyN > sheep, scared shitless of people likle Stallard, Blackmore and Carly and who7 > do not want to rock the boat for fear of being fired.   F Carly Fiorina and Scott Stallard have been very supportive of OpenVMS.E  Carly has made many public statements in support of OpenVMS.  In the F June 30 webcast announcement for Integrity Servers, Scott Stallard had/ 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) A and even arranged for a slide promoting VMS to be inserted in the C webcast just at the exact point where a stock HP video talked about D Windows, HP-UX, and Linux and omitted VMS.  (I've seen a more-recentE 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 B show how Scott Stallard has been willing to counteract and correct' omissions of VMS in other areas of HP.)    ------------------------------    Date: 25 Nov 2003 06:51:38 -0800% From: Bart.Zorn@xs4all.nl (Bart Zorn) : Subject: Anybody monitoring vmsnet.sdk.openvms.fieldtest ?= Message-ID: <a98cd882.0311250651.3bbac6dc@posting.google.com>   @ I have posted two messages on vmsnet.sdk.openvms.fieldtest aboutA OpenVMS E7.3-2 but I seem to be the only one currently using that  group.   Is anybody else listening?   Regards,  	 Bart Zorn    ------------------------------  % Date: Tue, 25 Nov 2003 17:05:05 +0100 " From: Didier Morandi <no@spam.com>> Subject: Re: Anybody monitoring vmsnet.sdk.openvms.fieldtest ?3 Message-ID: <3fc37dd8$0$2389$626a54ce@news.free.fr>    Bart Zorn wrote:  B > I have posted two messages on vmsnet.sdk.openvms.fieldtest aboutC > OpenVMS E7.3-2 but I seem to be the only one currently using that  > group. >  > Is anybody else listening?  O I think I remember that vmsnet groups are today heavily used by Spanish people  M to post binaries because there is no size limitation, or something like that.   F I would rather post any VMS related questions, even FT ones, in c.o.v.   D.   ------------------------------  # Date: Tue, 25 Nov 2003 16:05:51 GMT " From:   VAXman-  @SendSpamHere.ORG> Subject: Re: Anybody monitoring vmsnet.sdk.openvms.fieldtest ?0 Message-ID: <00A296CC.924FA9F8@SendSpamHere.ORG>  e In article <a98cd882.0311250651.3bbac6dc@posting.google.com>, Bart.Zorn@xs4all.nl (Bart Zorn) writes: A >I have posted two messages on vmsnet.sdk.openvms.fieldtest about B >OpenVMS E7.3-2 but I seem to be the only one currently using that >group.  >  >Is anybody else listening?   E Probably only the idiots that have been using it to exchange Spanish   DIVX movies. --  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 08:54:13 +0100 - From: "Martin Vorlaender" <mv@pdv-systeme.de>   Subject: Re: Backwards File Dump9 Message-ID: <bpv1r7$1rudh5$1@ID-56200.news.uni-berlin.de>    Tom Linden wrote: + >> JF Mezei jfmezei.spamnot@istop.com wrote  >> Tom Linden wrote:E >>> Now if you store the string 'DEADBEEF'B4 on say a VAX in location . >>> byte n  this is what will appear in memory >>  = >> Depends on how you define and then  "store" those 4 bytes.  >>  % >> If I use C for example, and I have  >>  " >> char mystring[4] = 0xDEADBEEF ; >> long myint = 0xDEADBEEF ; > . > C doesn't have strings that is a char array.  ? Excuse me? (zero terminated) char arrays are the *only* strings  that exist in the C RTL.   cu,    Martin --  F   OpenVMS:                | Martin Vorlaender  |  VMS & WNT programmer3    The operating system   | work: mv@pdv-systeme.de F    God runs the           |   http://www.pdv-systeme.de/users/martinv/:    earth simulation on.   | home: martin@radiogaga.harz.de   ------------------------------  % Date: Tue, 25 Nov 2003 09:51:15 -0000 ( From: "John Travell" <john@jomatech.com>  Subject: Re: Backwards File Dump: Message-ID: <bpv981$1tgde7$1@ID-120847.news.uni-berlin.de>  7 "JF Mezei" <jfmezei.spamnot@istop.com> wrote in message # news:3FC27847.375F8696@istop.com... ! > briggs@encompasserve.org wrote: L > >     Registers do not generally even have an endian-ness.  In the absenceH > > of instructions to access individual bits or individual bytes withinI > > a register, there is no sense in which bits going to or coming from a * > > register can be said to be "reversed". > J > But consider compiler functionality such as shifting bits left or right. The J > general assumption in higher level languages is that the value is stored in* > big-endian. (shift left multiplies by 2) >    You have this backwards.> LITTLEendian puts the MSB on the LEFT and the LSB on the RIGHT; BIGendian puts the MSB on the RIGHT and the LSB on the LEFT 0 so (shift left multiplies by 2) is LITTLEendian.  L > Consider a longword (4 bytes) located at address 10. From the programmer'sK > point of view in a language higher up the food chain than assembler, this L > number is seen as 4 bytes of 8 bits, with the byte at address 10 being theD > most significant, and the leftmost bit of that byte being the most significant.   This is LITTLEendian.      -- John Travell" Independent VMS crashdump analyst. john- at - jomatech - dot - com  +44-(0)23-92552229 http://www.jomatech.com/     > H > The compiler shields the programmer from most of those intricacies andL > presents to the programmer a big endian view of memory, no matter what theI > underlying machine is. And unless you are exchanging binary data with a K > "foreign" machine, the compiler succeeds 100% in sheltering you from this  > machine's endianness.  > J > However my feeling is that once you go into DUMP (or a memory dump), theL > utility should not try to shelter you from the endianness and your present you $ > a real view of a file (or memory). >  > Also, consider the following:  > * > FFFF0001 FFFFFFFF  [0010]   (VMS format)- > [0010] FFFFFFFF 0100FFFF    (other formats)  > L > So, yes, the word is clearly more visible in the vax format dump and has a  
 > value of 1.  > ) > But, consider this more realistic dump:  >  > 01000001 00010100 [0010] > H > Whether in VAX or standard formats, you will really need to count your offsets I > and then extract the 2 or 4 bytes you need, especially from a data file  where % > longword alignment isn't garanteed. K > So what this means is that the VAX format doesn't really help for binary,  but ' > makes it harder for textual contents.      --- & 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 10:13:55 -0000 ( From: "John Travell" <john@jomatech.com>  Subject: Re: Backwards File Dump: Message-ID: <bpvadl$1td2vf$1@ID-120847.news.uni-berlin.de>  . "Tom Linden" <tom@kednos.com> wrote in message3 news:CIEJLCMNHNNDLLOOGNJIGEIEIIAA.tom@kednos.com... A > The fact of the matter is that if I overlay a 16 bit integer on A > the the bit string '0000000000000010'B  on a Big endian machine A > it displays as 2.  If I do it on a little endian it displays as  > 2**14  >    No, you have it backwards./ A LITTLEendian machine '0000000000000010'B as 2  to BIGendian this is 2**14  C > It is customary to associate left with most significant and right 
 > with least.   8 Yes, in LITTLEendian. BIGendian has left=LSB, right=MSB.  5 > Little is contrary to this association and therfore % > appears unnatural, in this context.    Nope, wrong way round again.   > C > Now if you store the string 'DEADBEEF'B4 on say a VAX in location , > byte n  this is what will appear in memory >  >  > n 01111011 > n+1 10110101 > n+2 01111101 > n+3 11110111 >   D Nope. It depends on how you write it, and how you want it to appear.- %xDEADBEEF = 11011110101011011011111011101111 @ we are looking at this as a pure hex value, not an ascii string.% It will read in the dump as DEADBEEF.  byte n = 11101111 = EF n+1 = 10111110 = BE  n+2 = 10101101 = AD  n+3 = 11011110 = DE   * An ascii string "DEADBEEF" will appear be: n = 01000100 n+1 = 01000101 n+2 = 01000001 n+3 = 01000100 n+4 = 01000010 n+5 = 01000101 n+6 = 01000101 n+7 = 01000110   46454542 44414544   F E E B   D A E D     -- 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 05:53:39 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>  Subject: Re: Backwards File Dump) Message-ID: <3FC3347B.E32A4836@istop.com>    John Travell wrote:  > You have this backwards.@ > LITTLEendian puts the MSB on the LEFT and the LSB on the RIGHT= > BIGendian puts the MSB on the RIGHT and the LSB on the LEFT   = Sorry, but you are using arabic or hebrew reading directions.   N BIG Endian puts the most significant byte at the address of the word/longword.R LITTLE endian puts the least significant byte at the address of the word/longword.  F In a dump where adress values grow from left to right (default reading direction), then: % Big endian puts the MSB  on the LEFT, ( Little endian puts the MSB on the RIGHT.   In a VMS dump:  $ Big endian puts the MSB on the RIGHT# Little endian puts MSB on the LEFT.     L In other words, to read memory in growing order of address, on VMS, you must read backwards.    ------------------------------  % Date: Tue, 25 Nov 2003 11:49:02 -0000 ( From: "John Travell" <john@jomatech.com>  Subject: Re: Backwards File Dump: Message-ID: <bpvg0u$1sui9p$1@ID-120847.news.uni-berlin.de>  7 "JF Mezei" <jfmezei.spamnot@istop.com> wrote in message # news:3FC3347B.E32A4836@istop.com...  > John Travell wrote:  > > You have this backwards.B > > LITTLEendian puts the MSB on the LEFT and the LSB on the RIGHT? > > BIGendian puts the MSB on the RIGHT and the LSB on the LEFT  > ? > Sorry, but you are using arabic or hebrew reading directions.  > A > BIG Endian puts the most significant byte at the address of the  word/longword.E > LITTLE endian puts the least significant byte at the address of the  word/longword. > H > In a dump where adress values grow from left to right (default reading > direction), then: ' > Big endian puts the MSB  on the LEFT, * > Little endian puts the MSB on the RIGHT.   Wrong.   > In a VMS dump:& > Big endian puts the MSB on the RIGHT% > Little endian puts MSB on the LEFT.    Wrong again.  H You really do have it screwed up. I know from 17 years of supporting theJ INTERNALS of VMS that my statements are consistent with the way VMS works.  @ Forget strings for now. Just look at a plain old decimal number.
 1234567890> the 1 is the MOST significant digit and it appears on the LEFTA the 0 is the LEAST significant digit and it appears on the RIGHT.  VMS dump is EXACTLY the SAME. 9 (remember the dump is BINARY NUMERIC values, NOT strings)   # 12345678 24354657 36475869 48596A70   > the 1 is the MOST significant digit and it appears on the LEFTA the 0 is the LEAST significant digit and it appears on the RIGHT.   I > In other words, to read memory in growing order of address, on VMS, you  must > read backwards.   : Only if you insist on treating addresses as ascii strings.L Remember, in VMS at least, addresses are NUMBERS, not strings, and should be& treated exactly like any other NUMBER.  5 the MOST significant (highest) address is on the LEFT 7 The LEAST significant (lowest) address is on the RIGHT.   8 in the example above, the byte at memory offset 00 is A0( the byte value 12 is at memory offset 0F  J So the addresses increase in exactly the SAME way as numeric values, whichJ is the opposite to the way you might expect if you are used to big-endian.  I If you still cannot grasp this, I am afraid that the problem is your end, B and I do not know how to convince you of how the real world works.  F On the other hand, can I interest you in a collection of steel girders3 currently standing on the south bank of the Seine ?      -- 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 05:35:53 -0800 # From: "Tom Linden" <tom@kednos.com>   Subject: RE: Backwards File Dump9 Message-ID: <CIEJLCMNHNNDLLOOGNJIKEIOIIAA.tom@kednos.com>   F You have it wrong.  I previously postyed a program to demonstrate that2 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        >-----Original Message----- . >From: John Travell [mailto:john@jomatech.com]) >Sent: Tuesday, November 25, 2003 2:14 AM  >To: Info-VAX@Mvb.Saic.Com! >Subject: Re: Backwards File Dump  >  > / >"Tom Linden" <tom@kednos.com> wrote in message 4 >news:CIEJLCMNHNNDLLOOGNJIGEIEIIAA.tom@kednos.com...B >> The fact of the matter is that if I overlay a 16 bit integer onB >> the the bit string '0000000000000010'B  on a Big endian machineB >> it displays as 2.  If I do it on a little endian it displays as >> 2**14 >> >  >No, you have it backwards. 0 >A LITTLEendian machine '0000000000000010'B as 2 >to BIGendian this is 2**14  > D >> It is customary to associate left with most significant and right >> with least. > 9 >Yes, in LITTLEendian. BIGendian has left=LSB, right=MSB.  > 6 >> Little is contrary to this association and therfore& >> appears unnatural, in this context. >  >Nope, wrong way round again.  >  >>D >> Now if you store the string 'DEADBEEF'B4 on say a VAX in location- >> byte n  this is what will appear in memory  >> >>
 >> n 01111011  >> n+1 10110101  >> n+2 01111101  >> n+3 11110111  >> > E >Nope. It depends on how you write it, and how you want it to appear. . >%xDEADBEEF = 11011110101011011011111011101111A >we are looking at this as a pure hex value, not an ascii string. & >It will read in the dump as DEADBEEF. >byte n = 11101111 = EF  >n+1 = 10111110 = BE >n+2 = 10101101 = AD >n+3 = 11011110 = DE > + >An ascii string "DEADBEEF" will appear be: 
 >n = 01000100  >n+1 = 01000101  >n+2 = 01000001  >n+3 = 01000100  >n+4 = 01000010  >n+5 = 01000101  >n+6 = 01000101  >n+7 = 01000110  >  >46454542 44414544 > F E E B   D A E D  >  >  >-- 
 >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). B >Version: 6.0.543 / Virus Database: 337 - Release Date: 21/11/2003 >  >  >---' >Incoming mail is certified Virus Free. ; >Checked by AVG anti-virus system (http://www.grisoft.com). B >Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003 >  --- & 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/2003    ------------------------------    Date: 25 Nov 2003 07:55:03 -0600 From: briggs@encompasserve.org  Subject: RE: Backwards File Dump3 Message-ID: <sxXymEZrWb0G@eisner.encompasserve.org>   _ In article <CIEJLCMNHNNDLLOOGNJIGEIEIIAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes: A > The fact of the matter is that if I overlay a 16 bit integer on A > the the bit string '0000000000000010'B  on a Big endian machine A > it displays as 2.  If I do it on a little endian it displays as  > 2**14  > C > It is customary to associate left with most significant and right B > with least.  Little is contrary to this association and therfore% > appears unnatural, in this context.  > C > Now if you store the string 'DEADBEEF'B4 on say a VAX in location , > byte n  this is what will appear in memory  3 If you don't use PL/I, you won't have this problem.   A If you don't try to alias bit strings as integers, you won't have 
 this problem.    	John Briggs   ------------------------------    Date: 25 Nov 2003 08:00:07 -0600 From: briggs@encompasserve.org  Subject: Re: Backwards File Dump3 Message-ID: <HcCHli4Bt2ND@eisner.encompasserve.org>   e In article <bpv981$1tgde7$1@ID-120847.news.uni-berlin.de>, "John Travell" <john@jomatech.com> writes:  > 9 > "JF Mezei" <jfmezei.spamnot@istop.com> wrote in message % > news:3FC27847.375F8696@istop.com... " >> briggs@encompasserve.org wrote:M >> >     Registers do not generally even have an endian-ness.  In the absence I >> > of instructions to access individual bits or individual bytes within J >> > a register, there is no sense in which bits going to or coming from a+ >> > register can be said to be "reversed".  >>K >> But consider compiler functionality such as shifting bits left or right.  > The K >> general assumption in higher level languages is that the value is stored  > in+ >> big-endian. (shift left multiplies by 2)  >> >  > You have this backwards.@ > LITTLEendian puts the MSB on the LEFT and the LSB on the RIGHT= > BIGendian puts the MSB on the RIGHT and the LSB on the LEFT 2 > so (shift left multiplies by 2) is LITTLEendian.   No.  No.  A thousand times no.  @ Left and right are irrelevant.  Big endian puts the MSB first in< memory order.  Little endian puts LSB first in memory order.   Period.  End. Of. Story.   C When an integer is displayed in binary notation, it is your display A routines (and your printer/monitor and the direction you hold the D paper) that controls whether the MSB is on the right or on the left.> In practice, it will always be on the left, regardless of your hardware architecture.  M >> Consider a longword (4 bytes) located at address 10. From the programmer's L >> point of view in a language higher up the food chain than assembler, thisM >> number is seen as 4 bytes of 8 bits, with the byte at address 10 being the E >> most significant, and the leftmost bit of that byte being the most  > significant. >  > This is LITTLEendian.   = No.  Low addressed byte being most significant is BIG ENDIAN.   ) Again, nothing to do with left and right.    	John Briggs   ------------------------------    Date: 25 Nov 2003 07:37:03 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)   Subject: Re: Backwards File Dump3 Message-ID: <6UNiOZZ4HDHF@eisner.encompasserve.org>   V In article <3FC27847.375F8696@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes:! > briggs@encompasserve.org wrote: K >>     Registers do not generally even have an endian-ness.  In the absence G >> of instructions to access individual bits or individual bytes within H >> a register, there is no sense in which bits going to or coming from a) >> register can be said to be "reversed".  > N > But consider compiler functionality such as shifting bits left or right. TheM > general assumption in higher level languages is that the value is stored in * > big-endian. (shift left multiplies by 2)  G    "Left" when properly diagrammed multiplies by two on both big-endian C    and little-endian architectures.  That's why VMS DUMP is right:  G    always display the least significant on the right no matter what the     addresing order.   L > Consider a longword (4 bytes) located at address 10. From the programmer'sK > point of view in a language higher up the food chain than assembler, this L > number is seen as 4 bytes of 8 bits, with the byte at address 10 being theQ > most significant, and the leftmost bit of that byte being the most significant.   G    No.  I never consider the most significant byte to be at the address F    of the datum unless I am working on a big-endian machine, no matterH    what language I'm programming in.  When working at levels higher thanG    assembly I generelly don't care what the byte ordering is, but I can D    easily get into situations where I do care and must get it right.   > H > The compiler shields the programmer from most of those intricacies andL > presents to the programmer a big endian view of memory, no matter what theI > underlying machine is. And unless you are exchanging binary data with a K > "foreign" machine, the compiler succeeds 100% in sheltering you from this  > machine's endianness.   J    Nop it doesn't.  It's trivial to write C, C++, Fortran, ... code which B    tell you what endian-ness you're deailing with by examining the)    behaviour of unions, equivalences, ...   J > However my feeling is that once you go into DUMP (or a memory dump), theP > utility should not try to shelter you from the endianness and your present you$ > a real view of a file (or memory).  G    Real:  data in a legible format _properly labeled_ as VMS DUMP does.    > Also, consider the following:  > * > FFFF0001 FFFFFFFF  [0010]   (VMS format)- > [0010] FFFFFFFF 0100FFFF    (other formats)  > L > So, yes, the word is clearly more visible in the vax format dump and has a
 > value of 1.  > ) > But, consider this more realistic dump:  >  > 01000001 00010100 [0010] > P > Whether in VAX or standard formats, you will really need to count your offsetsO > and then extract the 2 or 4 bytes you need, especially from a data file where % > longword alignment isn't garanteed. O > So what this means is that the VAX format doesn't really help for binary, but ' > makes it harder for textual contents.   H    First of all, there is no "standard" format, just the one you happendE    to like.  Second of all for text, you simply read the text column.    ------------------------------    Date: 25 Nov 2003 07:44:16 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)   Subject: RE: Backwards File Dump3 Message-ID: <KQeZePRwpsY0@eisner.encompasserve.org>   _ In article <CIEJLCMNHNNDLLOOGNJIGEIEIIAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes: A > The fact of the matter is that if I overlay a 16 bit integer on A > the the bit string '0000000000000010'B  on a Big endian machine A > it displays as 2.  If I do it on a little endian it displays as  > 2**14   C    No it doesn't.  You're picturing memory backward.  That value is 9    the same on both big-endian and little-endian systems.   C > It is customary to associate left with most significant and right B > with least.  Little is contrary to this association and therfore% > appears unnatural, in this context.   D    Now you've got it right.  Always the left is the most significantG    in properly drawn memory diagrams.  Not always byte 0 on the left.   0    Which is why '0000000000000010'B is always 2.  C > Now if you store the string 'DEADBEEF'B4 on say a VAX in location , > byte n  this is what will appear in memory >  >  > n	01111011 > n+1	10110101 > n+2	01111101 > n+3	11110111 >  > L > which as you can see retains the big endian ordering, in the sense of left' > to right, but with the bytes reversed       No, you get:       n    11101111    n+1  10111110    n+2  10101101    n+3  11011110  H    You've got to stop drawing your memory diagrams backward.  ALWAYS the%    least significant is on the right.    ------------------------------    Date: 25 Nov 2003 07:45:53 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)   Subject: Re: Backwards File Dump3 Message-ID: <hMV88V0amaxD@eisner.encompasserve.org>   V In article <3FC3347B.E32A4836@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes: > H > In a dump where adress values grow from left to right (default reading > direction), then:   /    Said dump is faulty.  VMS DUMP got it right.    ------------------------------    Date: 25 Nov 2003 07:53:20 -0600 From: briggs@encompasserve.org  Subject: Re: Backwards File Dump3 Message-ID: <0gxYYlLzODBm@eisner.encompasserve.org>   V In article <3FC27847.375F8696@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes:! > briggs@encompasserve.org wrote: K >>     Registers do not generally even have an endian-ness.  In the absence G >> of instructions to access individual bits or individual bytes within H >> a register, there is no sense in which bits going to or coming from a) >> register can be said to be "reversed".  > N > But consider compiler functionality such as shifting bits left or right. TheM > general assumption in higher level languages is that the value is stored in * > big-endian. (shift left multiplies by 2)  I No.  Big endian and little endian have nothing to do with left and right. D They have to do with first (low addressed) and last (high addressed)A storage units when integers are stored in multiple storage units.   G Left shift in _HARDWARE_ on a little endian machine will multiply by 2.   I Left shift shifts bits toward positions of greater significance.  Always. H Right shift shifts bits toward positions of lower significance.  Always.  L > Consider a longword (4 bytes) located at address 10. From the programmer'sK > point of view in a language higher up the food chain than assembler, this L > number is seen as 4 bytes of 8 bits, with the byte at address 10 being theQ > most significant, and the leftmost bit of that byte being the most significant.   < That's a big-endian assumption.  Low addressed = high order.  D Again, this has nothing to do with left and right.  There is no left and right in memory.  H > The compiler shields the programmer from most of those intricacies andL > presents to the programmer a big endian view of memory, no matter what the > underlying machine is.  B No.  It does not.  It is possible to write C code to determine theE endian-ness of the architecture you are running upon.  That's because  C code permits aliasing.  2 > And unless you are exchanging binary data with aK > "foreign" machine, the compiler succeeds 100% in sheltering you from this  > machine's endianness.   > To the extent that you refrain from aliasing your longwords as@ arrays of bytes, the compiler can indeed shield you.  And to theD extent that your strongly typed language prevents you from aliasing,F it does indeed shield you.  But it does not present a big-endian view. It presents no view at all.   B If you can't tell whether the high order bits in your longword areH stored at higher or lower addresses, you can't tell whether the longwordE is big-endian or little-endian.  It is presented to the programmer as  an abstract integer.  C Endian-ness has to do with aliasing.  It has nothing to do with the A display order of bits in base 2 presentations of machine readable  binary numbers.   J > However my feeling is that once you go into DUMP (or a memory dump), theP > utility should not try to shelter you from the endianness and your present you$ > a real view of a file (or memory).  @ In real life there is no such thing as left and right in memory.   	John Briggs   ------------------------------    Date: 25 Nov 2003 08:04:57 -0600 From: briggs@encompasserve.org  Subject: Re: Backwards File Dump3 Message-ID: <3R8rf9vkJMr$@eisner.encompasserve.org>   e In article <bpvadl$1td2vf$1@ID-120847.news.uni-berlin.de>, "John Travell" <john@jomatech.com> writes: 0 > "Tom Linden" <tom@kednos.com> wrote in message5 > news:CIEJLCMNHNNDLLOOGNJIGEIEIIAA.tom@kednos.com... B >> The fact of the matter is that if I overlay a 16 bit integer onB >> the the bit string '0000000000000010'B  on a Big endian machineB >> it displays as 2.  If I do it on a little endian it displays as >> 2**14 >> >  > No, you have it backwards.1 > A LITTLEendian machine '0000000000000010'B as 2  > to BIGendian this is 2**14  > Little endian.  First bit low order.  '0100000000000000'B = 2.9 Big endian.  Last bit low order.  '0000000000000010'B = 2   D >> It is customary to associate left with most significant and right >> with least. > : > Yes, in LITTLEendian. BIGendian has left=LSB, right=MSB.  F In both big endian and little endian, integers are generally presented with msb left and lsb right.  B In little endian, bit strings may be displayed with first bit left@ and last bit right.  When aliased as binary coded integers, this= means that the same display will have lsb left and msb right.    	John Briggs   ------------------------------    Date: 25 Nov 2003 08:19:37 -0600 From: briggs@encompasserve.org  Subject: Re: Backwards File Dump3 Message-ID: <8y0cVbC7VMez@eisner.encompasserve.org>o  e In article <bpvg0u$1sui9p$1@ID-120847.news.uni-berlin.de>, "John Travell" <john@jomatech.com> writes:i9 > "JF Mezei" <jfmezei.spamnot@istop.com> wrote in message % > news:3FC3347B.E32A4836@istop.com...d >> John Travell wrote: >> > You have this backwards.iC >> > LITTLEendian puts the MSB on the LEFT and the LSB on the RIGHTk@ >> > BIGendian puts the MSB on the RIGHT and the LSB on the LEFT >>@ >> Sorry, but you are using arabic or hebrew reading directions. >>B >> BIG Endian puts the most significant byte at the address of the > word/longword.F >> LITTLE endian puts the least significant byte at the address of the > word/longword. >>I >> In a dump where adress values grow from left to right (default readingn >> direction), then:( >> Big endian puts the MSB  on the LEFT,+ >> Little endian puts the MSB on the RIGHT.  >  > Wrong. >  >> In a VMS dump:p' >> Big endian puts the MSB on the RIGHTr& >> Little endian puts MSB on the LEFT. >  > Wrong again.   No.  He's right.  F If you have big-endian binary data in a file and you're using VMS dumpC to display that file then the first bytes in the file (first = mostgD significant since file is big-endian) will be displayed on the right+ (first = right since we're using VMS DUMP).p  J > You really do have it screwed up. I know from 17 years of supporting theL > INTERNALS of VMS that my statements are consistent with the way VMS works.  C You're right too.  DUMPs (both big-endian and little-endian flavorsm= on their respective platforms) always put MSB left.  That wayn integers look right.   	John Briggs   ------------------------------  % Date: Tue, 25 Nov 2003 06:38:57 -0800 # From: "Tom Linden" <tom@kednos.com>s  Subject: RE: Backwards File Dump9 Message-ID: <CIEJLCMNHNNDLLOOGNJIMEJDIIAA.tom@kednos.com>d  G The fact that left shift multiplies and right shift divides establishesuJ the (human) association most significant being left and least right.  ThisG is what was implied by my assertion that once it is in a register it is- all big endian.Q  G When I reference a string in PL/I as '0000000000000010'B this is storednJ in memory with the leftmost bit in the lowest location and proceeding from there.H Strings are therefore stored in a Big endian fashion, provided you agreeH to call the leftmost bit the most significant, and this is the generallyL accepted view.  Strings can not be practically stored any other way, varying* strings, for example have a length prefix.  H It was for this reason that when PL/I was ported to VAX, special builtin3 functions were added to deal with the bit reversal.s  G You might say that you shouldn't alias, but people do, even in stronglyc typedt languages like PL/I.  G In my view, little endian was the wrong decision way back when, but youE can'toK change that today and continuing the discussion is pointless and fruitless.    >-----Original Message----- A >From: briggs@encompasserve.org [mailto:briggs@encompasserve.org]-) >Sent: Tuesday, November 25, 2003 5:53 AMr >To: Info-VAX@Mvb.Saic.Com! >Subject: Re: Backwards File DumpA >r >f3 >In article <3FC27847.375F8696@istop.com>, JF Mezei4$ ><jfmezei.spamnot@istop.com> writes:" >> briggs@encompasserve.org wrote:L >>>     Registers do not generally even have an endian-ness.  In the absenceH >>> of instructions to access individual bits or individual bytes withinI >>> a register, there is no sense in which bits going to or coming from aS* >>> register can be said to be "reversed". >>A >> But consider compiler functionality such as shifting bits leftr >or right. TheA >> general assumption in higher level languages is that the values
 >is stored ini+ >> big-endian. (shift left multiplies by 2). > J >No.  Big endian and little endian have nothing to do with left and right.E >They have to do with first (low addressed) and last (high addressed)aB >storage units when integers are stored in multiple storage units. >lH >Left shift in _HARDWARE_ on a little endian machine will multiply by 2. >sJ >Left shift shifts bits toward positions of greater significance.  Always.I >Right shift shifts bits toward positions of lower significance.  Always.i >w@ >> Consider a longword (4 bytes) located at address 10. From the
 >programmer'snL >> point of view in a language higher up the food chain than assembler, thisC >> number is seen as 4 bytes of 8 bits, with the byte at address 10 
 >being the@ >> most significant, and the leftmost bit of that byte being the >most significant. >l= >That's a big-endian assumption.  Low addressed = high order.e >aE >Again, this has nothing to do with left and right.  There is no lefti >and right in memory.k >tI >> The compiler shields the programmer from most of those intricacies and== >> presents to the programmer a big endian view of memory, no4 >matter what the >> underlying machine is.o >SC >No.  It does not.  It is possible to write C code to determine theiF >endian-ness of the architecture you are running upon.  That's because >C code permits aliasing.  >t3 >> And unless you are exchanging binary data with arL >> "foreign" machine, the compiler succeeds 100% in sheltering you from this >> machine's endianness. >e? >To the extent that you refrain from aliasing your longwords asMA >arrays of bytes, the compiler can indeed shield you.  And to the.E >extent that your strongly typed language prevents you from aliasing,-G >it does indeed shield you.  But it does not present a big-endian view.r >It presents no view at all. >RC >If you can't tell whether the high order bits in your longword arecI >stored at higher or lower addresses, you can't tell whether the longword F >is big-endian or little-endian.  It is presented to the programmer as >an abstract integer.o >cD >Endian-ness has to do with aliasing.  It has nothing to do with theB >display order of bits in base 2 presentations of machine readable >binary numbers. >iK >> However my feeling is that once you go into DUMP (or a memory dump), thel@ >> utility should not try to shelter you from the endianness and >your present you-% >> a real view of a file (or memory).  >3A >In real life there is no such thing as left and right in memory.y >y
 >	John Briggsn >s >---' >Incoming mail is certified Virus Free.2; >Checked by AVG anti-virus system (http://www.grisoft.com).bB >Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003 >I --- & 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/2003g   ------------------------------  # Date: Tue, 25 Nov 2003 14:38:57 GMTh1 From: "Barry in Indy" <barrymeindy@ameritech.net>M  Subject: Re: Backwards File Dump? Message-ID: <5QJwb.5463$aw2.2009170@newssrv26.news.prodigy.com>s  @ Well, since I began this lengthening thread, and since I usually; use the DUMP command on text files, I created the following-> simple COM, which dumps a file and then reverses the hex data:   $ DUMP/OUT=DUMP.TMP &P1u $ OPEN INFILE DUMP.TMP $ OPEN/WRITE OUTFILE DUMP.DMPe
 $ R_STG = " ".
 $ T_STG = " "T $ TEMP = " " $LOOPER:' $ READ/END_OF_FILE=NOMORE INFILE INLINE  $ IND = F$EXTRACT(0,1,INLINE)e $ IF   IND .EQS. "D" -   .OR. IND .EQS. "F" -'   .OR. IND .EQS. "V" THEN GOTO NOCHANGEr $ HEX = F$EXTRACT(0,73,INLINE)! $ ASCII = F$EXTRACT(72,33,INLINE)> $ LOC = F$EXTRACT(105,8,INLINE)E
 $ OFF = 64 $ NEW_STG = " "E	 $REVLOOP:  $ T_STG = F$EXTRACT(&OFF,8,HEX)c $ R_STG = F$EXTRACT(6,2,T_STG)& $ R_STG = R_STG + F$EXTRACT(4,2,T_STG)& $ R_STG = R_STG + F$EXTRACT(2,2,T_STG)& $ R_STG = R_STG + F$EXTRACT(0,2,T_STG)! $ NEW_STG = NEW_STG + R_STG + " "N $ OFF = OFF - 9T! $ IF OFF .GE. 1 THEN GOTO REVLOOPv# $ WRITE OUTFILE LOC, NEW_STG, ASCII 
 $ GOTO LOOPERw
 $NOCHANGE: $ WRITE OUTFILE INLINE
 $ GOTO LOOPER  $NOMORE: $ CLOSE INFILE $ CLOSE OUTFILE- $ DELETE DUMP.TMP;*- $ TYPE/PAGE DUMP.DMP $ EXIT   -- 1
 Barry in Indym   Knock me out to replym   ------------------------------  % Date: Tue, 25 Nov 2003 07:00:14 -0800I# From: "Tom Linden" <tom@kednos.com>e  Subject: RE: Backwards File Dump9 Message-ID: <CIEJLCMNHNNDLLOOGNJIMEJFIIAA.tom@kednos.com>r   Following snippet run on a VAX   HERMES> type  ENDIAN.PLI endian: proc options(main);., dcl bs bit(16) initial('0010000000000000'B);! dcl fb fixed bin(15) defined(bs);e put skip list(fb); end endian;s HERMES> run endian  	         4o   >-----Original Message-----cA >From: briggs@encompasserve.org [mailto:briggs@encompasserve.org]l) >Sent: Tuesday, November 25, 2003 6:05 AMh >To: Info-VAX@Mvb.Saic.Com! >Subject: Re: Backwards File Dumpv >e > B >In article <bpvadl$1td2vf$1@ID-120847.news.uni-berlin.de>, "John % >Travell" <john@jomatech.com> writes:h1 >> "Tom Linden" <tom@kednos.com> wrote in messagea6 >> news:CIEJLCMNHNNDLLOOGNJIGEIEIIAA.tom@kednos.com...C >>> The fact of the matter is that if I overlay a 16 bit integer onrC >>> the the bit string '0000000000000010'B  on a Big endian machinevC >>> it displays as 2.  If I do it on a little endian it displays asu	 >>> 2**14n >>>  >>   >> No, you have it backwards.r2 >> A LITTLEendian machine '0000000000000010'B as 2 >> to BIGendian this is 2**14o > ? >Little endian.  First bit low order.  '0100000000000000'B = 2.e: >Big endian.  Last bit low order.  '0000000000000010'B = 2 > E >>> It is customary to associate left with most significant and rights >>> with least.m >> r; >> Yes, in LITTLEendian. BIGendian has left=LSB, right=MSB.r >bG >In both big endian and little endian, integers are generally presentedd >with msb left and lsb right.r >aC >In little endian, bit strings may be displayed with first bit leftrA >and last bit right.  When aliased as binary coded integers, thisi> >means that the same display will have lsb left and msb right. > 
 >	John Briggst >h >---' >Incoming mail is certified Virus Free. ; >Checked by AVG anti-virus system (http://www.grisoft.com).dB >Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003 >0 ---F& 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/2003    ------------------------------  % Date: Tue, 25 Nov 2003 09:28:03 -0600t( From: Wayne Sewell <wayne@tachysoft.com>$ Subject: Re: RE: Backwards File Dump/ Message-ID: <00A296BE.E3DD580C.1@tachysoft.com>a  $ >From: "Tom Linden" <tom@kednos.com> >X-Newsgroups: comp.os.vms! >Subject: RE: Backwards File Dumps: >Message-ID: <CIEJLCMNHNNDLLOOGNJIKEIOIIAA.tom@kednos.com>& >Date: Tue, 25 Nov 2003 05:35:53 -0800. >Organization: Info-VAX<==>comp.os.vms Gateway$ >X-Gateway-Source-Info: Mailing List   >sG >You have it wrong.  I previously postyed a program to demonstrate that-3 >what I am saying is correct, I will repeat it here3 >  >HERMES> type  ENDIAN.PLI" >endian: proc options(main);- >dcl bs bit(16) initial('0010000000000000'B);t" >dcl fb fixed bin(15) defined(bs); >put skip list(fb);@ >end endian; >HERMES> run endianC >L
 >        4 >G >I >.  I To repeat what I said earlier, and some one else repeated, using PL/I bitt& strings as integers is your problem.    C Some machines are big endian and some machines are little endian.  n  L Mapping bit strings to integers means you have to *know* the architecture ofL the machine you are running on in order for programs to work properly, as inH this case.  In other words, if you want a value of 4, you have to eitherM specify '0010000000000000'B or '0000000000000100'B, so the same program won'ttO work on both architectures without modification.  The whole point of using highn? level languages is that you don't have to deal with this stuff.t    G Sounds like a flaw in the language or a misapplication of its features.    Wayne O =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html   sO =============================================================================== H Randolph Duke (in Trading Places): "Mother always said you were greedy."1    Mortimer Duke: "She meant it as a compliment!"    ------------------------------  % Date: Tue, 25 Nov 2003 07:32:51 -0800+# From: "Tom Linden" <tom@kednos.com>1$ Subject: RE: RE: Backwards File Dump9 Message-ID: <CIEJLCMNHNNDLLOOGNJIGEJIIIAA.tom@kednos.com>n   >-----Original Message----- 0 >From: Wayne Sewell [mailto:wayne@tachysoft.com]) >Sent: Tuesday, November 25, 2003 7:28 AMg >To: Info-VAX@Mvb.Saic.Com% >Subject: Re: RE: Backwards File Dumpt >/ >w% >>From: "Tom Linden" <tom@kednos.com>s >>X-Newsgroups: comp.os.vms:" >>Subject: RE: Backwards File Dump; >>Message-ID: <CIEJLCMNHNNDLLOOGNJIKEIOIIAA.tom@kednos.com>F' >>Date: Tue, 25 Nov 2003 05:35:53 -0800c/ >>Organization: Info-VAX<==>comp.os.vms Gateway.% >>X-Gateway-Source-Info: Mailing Listo >  >>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);r. >>dcl bs bit(16) initial('0010000000000000'B);# >>dcl fb fixed bin(15) defined(bs);e >>put skip list(fb);
 >>end endian;a >>HERMES> run endian >> >>        4e >> >> >> > J >To repeat what I said earlier, and some one else repeated, using PL/I bit% >strings as integers is your problem.n >nB >Some machines are big endian and some machines are little endian. > = >Mapping bit strings to integers means you have to *know* thee >architecture of= >the machine you are running on in order for programs to worke >properly, as inI >this case.  In other words, if you want a value of 4, you have to eitheru@ >specify '0010000000000000'B or '0000000000000100'B, so the same >program won'tB >work on both architectures without modification.  The whole point >of using high@ >level languages is that you don't have to deal with this stuff. >C >7H >Sounds like a flaw in the language or a misapplication of its features.  L It is neither, it is just an unfortunate shortcoming of little endian memoryI design.  When porting code from one to the other, you must always keep ant eyea( out for aliasing, whatever the language.   >  >WayneD >===================================================================
 >============T9 >Wayne Sewell, Tachyon Software Consulting  (281)812-0738  >wayne@tachysoft.com9 >http://www.tachysoft.com/www/tachyon.html and wayne.html D >===================================================================
 >============iI >Randolph Duke (in Trading Places): "Mother always said you were greedy." 2 >   Mortimer Duke: "She meant it as a compliment!" >M >---' >Incoming mail is certified Virus Free.d; >Checked by AVG anti-virus system (http://www.grisoft.com). B >Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003 >k --- & 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/2003i   ------------------------------    Date: 25 Nov 2003 07:48:51 -0800. From: al5vf03p02@sneakemail.com (William Webb)  Subject: Re: Backwards File Dump= Message-ID: <d5ce4b06.0311250748.2d48b2a2@posting.google.com>   d "Tom Linden" <tom@kednos.com> wrote in message news:<CIEJLCMNHNNDLLOOGNJIMEIFIIAA.tom@kednos.com>.... > C doesn't have strings that is a char array. >  >  > >-----Original Message-----s4 > >From: JF Mezei [mailto:jfmezei.spamnot@istop.com]* > >Sent: Monday, November 24, 2003 5:46 PM > >To: Info-VAX@Mvb.Saic.Com# > >Subject: Re: Backwards File Dumpa > >h > >M > >Tom Linden wrote:F > >> Now if you store the string 'DEADBEEF'B4 on say a VAX in location/ > >> byte n  this is what will appear in memorye > > > > >Depends on how you define and then  "store" those 4 bytes.  > > % > >If I use C for example, and I havet > >e" > >char mystring[4] = 0xDEADBEEF ; > >long myint = 0xDEADBEEF ; > >tM > >The first one will be stored in the same order as you typed it in. For theaD > >second one, the compiler  will reverse the constant and store it  > >as little endian. > >  > >.J > >if you then  use memcpy (&myint, &mystring, 4), then myint will containA > >"deadbeef" in the big endian order because the code in memcpy T > >copies byte by ) > >byte without any endianness knowledge.  > >  > >---) > >Incoming mail is certified Virus Free./= > >Checked by AVG anti-virus system (http://www.grisoft.com).eD > >Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003 > >r > ---b( > Outgoing 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/2003s  0 This thread is in serious need of a humor break.  C The first thing that went through my mind when I saw the title was:m  A      If you do a Backwards File Dump do you get satanic binaries?e   WWWebb   ========================! William W. Webb- EMS Operations, 1 OpenVMS Systems Support % USPS DSSC Annex - 4730 Hargrove Road )( Raleigh, NC 27616-2874 919.325.7500x4186I * * * -      email is first initial last name at email stop usps stop govh   ------------------------------    Date: 25 Nov 2003 09:57:07 -0600 From: briggs@encompasserve.org  Subject: RE: Backwards File Dump3 Message-ID: <+Z12T74lwqsI@eisner.encompasserve.org>e  _ In article <CIEJLCMNHNNDLLOOGNJIMEJDIIAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes:aI > The fact that left shift multiplies and right shift divides establishes'L > the (human) association most significant being left and least right.  ThisI > is what was implied by my assertion that once it is in a register it ise > all big endian.0  D That makes your notion of register endian-ness an illusion.  It sits5 between your ears rather than inside the CPU cabinet.w  I > When I reference a string in PL/I as '0000000000000010'B this is stored L > in memory with the leftmost bit in the lowest location and proceeding from > there.  A Yep.  That's fine.  First = left in that presentation convention.t  F And it's a perfectly sensible convention.  But it's neither big-endian. nor little-endian.  It's a display convention.  J > Strings are therefore stored in a Big endian fashion, provided you agreeJ > to call the leftmost bit the most significant, and this is the generally > accepted view.  D No.  It is not.  Bits within strings do not have significance.  TheyB have positions.  Bits within integers do not have positions.  They have significance.  C When you treat a bit string as an integer, you have essentially twoiD ways to map significance to position.  Big endian and little endian.  G Note also that with respect to character strings, there are two obvious0F choices for the first bit in the string:  The MSB of the first byte orF the LSB of the first byte.  On little-endian systems, implementing bitE strings on byte arrays, you will likely take the low order bit of theeB first byte as the first bit in the string.  On big-endian systems,F implementing bit strings on byte arrays, you will likely take the high; order bit of the first byte as the first bit in the string.   A It is interesting that you claim that the most signifant bit in a C VAX character string the least significant bit in the first byte ofu that string.  > > Strings can not be practically stored any other way, varying, > strings, for example have a length prefix.  @ So what you are saying is that, for strings, the first characterD in the string goes in the first byte in memory order.  Yes, I agree.  B But that convention is not what is meant by the term "big-endian".   	John Briggs   ------------------------------  % Date: Tue, 25 Nov 2003 08:41:18 -0800<# From: "Tom Linden" <tom@kednos.com>o  Subject: RE: Backwards File Dump9 Message-ID: <CIEJLCMNHNNDLLOOGNJIGEJKIIAA.tom@kednos.com>    >-----Original Message----- A >From: briggs@encompasserve.org [mailto:briggs@encompasserve.org]l) >Sent: Tuesday, November 25, 2003 7:57 AM  >To: Info-VAX@Mvb.Saic.Com! >Subject: RE: Backwards File Dump  >h >s? >In article <CIEJLCMNHNNDLLOOGNJIMEJDIIAA.tom@kednos.com>, "Tomi! >Linden" <tom@kednos.com> writes:rJ >> The fact that left shift multiplies and right shift divides establishes@ >> the (human) association most significant being left and least
 >right.  ThisyJ >> is what was implied by my assertion that once it is in a register it is >> all big endian. >rE >That makes your notion of register endian-ness an illusion.  It sits-6 >between your ears rather than inside the CPU cabinet. >gJ >> 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., >oB >Yep.  That's fine.  First = left in that presentation convention. >mG >And it's a perfectly sensible convention.  But it's neither big-endian / >nor little-endian.  It's a display convention.s >sK >> Strings are therefore stored in a Big endian fashion, provided you agreetK >> to call the leftmost bit the most significant, and this is the generallyt >> accepted view.  >cE >No.  It is not.  Bits within strings do not have significance.  TheyrC >have positions.  Bits within integers do not have positions.  Theyi >have significance.   J John, you are like a pit bull, you just don't let go.  For the majority of mankindnK when _VIEWING_ a bit string representation of an integer, the left most bita isJ generally  regarded as the most significant.  Bit strings are stored, from this@ perspective, as big endian, which implies a reversal for integer interpretation. L That is not subject to debate.  If you wish to employ semantics to justify aB prejudice, fine, I accept that.  Now I am done with this nonsense.   >tD >When you treat a bit string as an integer, you have essentially twoE >ways to map significance to position.  Big endian and little endian.( > H >Note also that with respect to character strings, there are two obviousG >choices for the first bit in the string:  The MSB of the first byte orwG >the LSB of the first byte.  On little-endian systems, implementing bitiF >strings on byte arrays, you will likely take the low order bit of theC >first byte as the first bit in the string.  On big-endian systems,rG >implementing bit strings on byte arrays, you will likely take the high1< >order bit of the first byte as the first bit in the string. >yB >It is interesting that you claim that the most signifant bit in aD >VAX character string the least significant bit in the first byte of
 >that string.o >t? >> Strings can not be practically stored any other way, varying-- >> strings, for example have a length prefix.o >eA >So what you are saying is that, for strings, the first characterwE >in the string goes in the first byte in memory order.  Yes, I agree.  >aC >But that convention is not what is meant by the term "big-endian".. >>
 >	John Briggsg >e >---' >Incoming mail is certified Virus Free.o; >Checked by AVG anti-virus system (http://www.grisoft.com). B >Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003 >a ---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/2003b   ------------------------------  # Date: Tue, 25 Nov 2003 17:52:45 GMT   From: Rob Brown <nworb@gmcl.com>  Subject: RE: Backwards File DumpL Message-ID: <Pine.LNX.4.44.0311251049410.12225-100000@localhost.localdomain>  & On Tue, 25 Nov 2003, Tom Linden wrote:  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);t > put skip list(fb);
 > end endian;8 > HERMES> run endian >  >         4g >    On the other hand:   $ create endian.for          implicit nonet         integer*2 word"         word = '0010000000000000'b         type *, word         stop         endn  Exita $ fortran endian
 $ link endian, $ run endian   8192) $ write sys$output f$getsyi ("arch_name")  Alphah     -- n  ' Rob Brown                        brown@hA G. Michaels Consulting Ltd.      (866)438-2101 (voice) toll free! 6 Edmonton                         (780)438-9343 (voice)4                                  (780)437-3367 (FAX)1                                  http://gmcl.com/o   ------------------------------  % Date: Tue, 25 Nov 2003 19:59:31 +0100x* From: Paul Sture <nospam@sture.homeip.net>  Subject: Re: Backwards File Dump0 Message-ID: <3FC3B4A3.5150452F@sture.homeip.net>   briggs@encompasserve.org wrote:i > a > In article <CIEJLCMNHNNDLLOOGNJIGEIEIIAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes:aC > > The fact of the matter is that if I overlay a 16 bit integer onyC > > the the bit string '0000000000000010'B  on a Big endian machinelC > > it displays as 2.  If I do it on a little endian it displays ast	 > > 2**14e > >eE > > It is customary to associate left with most significant and rightyD > > with least.  Little is contrary to this association and therfore' > > appears unnatural, in this context.) > >0E > > Now if you store the string 'DEADBEEF'B4 on say a VAX in locationc. > > byte n  this is what will appear in memory > 5 > If you don't use PL/I, you won't have this problem.i > C > If you don't try to alias bit strings as integers, you won't haved > this problem.l >   D This also crops up when using integer fields as part of of segmented keys in an RMS file.  E In order to get the index in the correct order, you need to byte swapsH the integer elements before storing the record. Or use packed decimal or  a string representation instead.  G In my experience, COBOL shops used to use packed decimals for this, butd! FORTRAN shops used byte swapping.x   -- s
 Paul Sture   ------------------------------  % Date: Tue, 25 Nov 2003 11:21:52 -05004< From: "Peter Weaver" <WeaverConsultingServices@sympatico.ca>6 Subject: Re: Building a cluster using HP's SBW program: Message-ID: <bpvvj1$1t4adr$1@ID-141708.news.uni-berlin.de>   David J. Dachtera wrote: >..d: > At teh rsik of sounding like a smart-ass, follow-up with
 them ("Any9 > news yet?"). It's a good bet you've "fallen through the  cracks".  = Did that Friday before I posted here, no reply yet. But it isI< not a critical issue now so I will ask them again in another month or so.   --   Peter Weaver Weaver Consulting Services Inc.t Canadian VAR for CHARON-VAXd www.weaverconsulting.ca    ------------------------------  % Date: Tue, 25 Nov 2003 19:27:34 +0100i* From: Paul Sture <nospam@sture.homeip.net>A Subject: Re: DCL Enhancements: Error messages for OPEN and DEFINEw0 Message-ID: <3FC3AD26.719C170E@sture.homeip.net>   Alan E. Feldman wrote:   ,snipped for brevity>    > Paul Sture wroteI > > > > I've known about it for at least 20 years, and even used it to myy; > > > > advantage on occasions (usually for DCL debugging).  > > >  > > > Can you tell us how? > >yH > > OK, here's a little bit of DCL I write on any new site where I might' > > want to do edits on multiple files.b > >d% > > $! EDIT.COM - edit multiple fileso > > $!" > > $       open /read in edit.dat
 > > $loop:! > > $       read/end=exit in data1= > > $       version = f$parse(data,,,"VERSION","SYNTAX_ONLY")  > > $!      show sym version! > > $       data = data - versioni* > > $       def/user sys$input sys$command- > > $       edit/edt 'data' /command=edit.edt6 > > $       goto loopr
 > > $exit: > > $       close in > >  > [...]:L > > While debugging or enhancing EDIT.INI (and it can get quite complex), atJ > > present I can ^Y out of EDIT.COM, change my EDIT.EDT, and then pick up5 > > from where I left off, using the next input file.w > > F > > OK, nowadays I have a workstation where I could do that editing inK > > another DECterm session, but when I was tied to a single VT, I found it5  > > a productive way of working. > = > But how would this example break? OPEN is only called once.D >0  C Sorry I should have mentioned that when restricted to a single VT I@C would CTRL-Y out of the procedure, do my edits, then resume with @.c  F Since no close is executed, the record pointers are left as they were,( and you can carry on where you left off.  sM > > > > I'm arguing that it's too late now to change the _default_ behaviour.  > > > >iL > > > > Far easier to document it as a "feature", and as suggested elsewhereO > > > > have a logical or appropriate SET command to enable enhanced OPEN errorh" > > > > checking (off by default). > > >lK > > > Additionally you could add a step to the upgrade procedure that wouldiK > > > ask the upgrader about which OPEN he wants (correct, or incorrect :-)dF > > > and force him to answer the question or the upgrade fails. OK, IL > > > wouldn't phrase it that way. Maybe it should just say "new or old". OrI > > > it could go into a nearly full screen explanation of the issue, and 3 > > > after the answer is given ask "Are you sure?"g > > >c > >lK > > OK, but I'd answer OLD at any time I'm not imtimately familiar with theyK > > DCL lurking on the target machine. You might answer NEW, and that wouldmG > > be fine on your own system(s), but would you feel happy doing so one > > someone else's system? > 1 > It depends how familiar I was with said system.t >    Which is my point.  F > > > And there is, as always, the "Be careful what you wish for" bit. > > >a > >uK > > In that one short sentence you have summed up my argument better than If > > could have wished for :-)  > >iE > > Sincere thanks for prompting me to explain my POV in more detail.o >  > Your welcome.  >    --  
 Paul Sture   ------------------------------  % Date: Tue, 25 Nov 2003 06:38:22 -0800.1 From: "Wolf, Gerald J" <gerald.j.wolf@boeing.com>dF Subject: DCL procedure to monitor disk space and purge or delete filesR Message-ID: <3BFEACE361F5BF429DD1DA593E3A7C090178DF02@xch-nw-28.nw.nos.boeing.com>   All,  H Is there a DCL procedure out there that will monitor disk space? If thatE disk space reaches a certain percentage full it will start purging oro1 deleting selected file types, or specified files?c   Please advise.   Warmest Regards,=20e =20e Gerald(Gerry) Wolf=20y  Systems Administrator,=20#  HP3000 & HP Unix; Tooling Serviceso9  VAX/Alpha OpenVMS Dev/Prod Systems; SMARTS & Finish Cell    ------------------------------  % Date: Tue, 25 Nov 2003 10:29:57 -0600o( From: brandon@dalsemi.com (John Brandon)J Subject: Re: DCL procedure to monitor disk space and purge or delete files1 Message-ID: <03112510295739@dscis6-0.dalsemi.com>    > All, > J > Is there a DCL procedure out there that will monitor disk space? If thatG > disk space reaches a certain percentage full it will start purging ors3 > deleting selected file types, or specified files?U >  > Please advise. >  > Warmest Regards, t >  t > Gerald(Gerry) Wolf e >  Systems Administrator, % >  HP3000 & HP Unix; Tooling Services.; >  VAX/Alpha OpenVMS Dev/Prod Systems; SMARTS & Finish Cellm  6 Create your own, using the LEXICAL functions F$GETDVI.     Drill through these sites:  5 http://h71000.www7.hp.com/openvms/freeware/index.htmls http://www.madgoat.com/3     J*o*h*n B*r*a*n*d*o*ns VMS Systems Administratorp* firstname.lastname.spam.me.not@dalsemi.com   ------------------------------    Date: 25 Nov 2003 17:21:59 +0100' From: huber@mppmu.mpg.de (Joseph Huber)HJ Subject: Re: DCL procedure to monitor disk space and purge or delete files+ Message-ID: <hTtBNWCD$G9g@vms.mppmu.mpg.de>t   In article <3BFEACE361F5BF429DD1DA593E3A7C090178DF02@xch-nw-28.nw.nos.boeing.com>, "Wolf, Gerald J" <gerald.j.wolf@boeing.com> writes:J > Is there a DCL procedure out there that will monitor disk space? If thatG > disk space reaches a certain percentage full it will start purging ore3 > deleting selected file types, or specified files?o  =  http://dcl.openvms.org/ : diskspace.com does the first part.i)  Customize to make it do what You want...>  t -- s>    Joseph "Sepp" Huber, Muenchen   http://www.huber-joseph.de/   ------------------------------  % Date: Tue, 25 Nov 2003 09:30:41 +0000d* From: Nic Clews <sendspamhere@[127.0.0.1]>I Subject: Re: Dell drops call centers in India - HP thinks it is a winner!t' Message-ID: <bpv7em$p6v$1@lore.csc.com>    Bob Ceculski wrote:m > H > HP thinks it will be wonderful ... I guess some people never learn ... > b > http://seattlepi.nwsource.com/business/aptech_story.asp?category=1700&slug=Dell%20Call%20Centers  H There was a TV programme a few weeks ago (The Money Programme) in the UK about call centres.$  B It was interesting, they gave the call centre staff training in UKE culture, gave them live weather reports and english names, and one oreC two of the call centre staff interviewed lied about where they werehH calling from, and they got paid around 40% of UK call centre staff wagesC (working late into their evening, most with degrees or other higherB education).   H However, in defence, we recently had an "interesting" issue with ABS and< we got Engineering support (HP) from India to "dial in", andF observe/diagnose. It was early hours of west coast USA, and, midday toF the support staff in India (with UK co-ordinating) so its not all bad.   -- o? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer SciencesB nclews at csc dot com    ------------------------------  # Date: Tue, 25 Nov 2003 18:22:14 GMT 9 From: Hein van den Heuvel <hein_netscape@eps.zko.dec.com>I' Subject: Re: Disk cluster size questionF/ Message-ID: <3FC39CC8.37B9EF99@eps.zko.dec.com>y   Daryl Jones wrote:  ] > Drew Shelton <DREW@SEMATECH.Org> wrote in message news:<01L3AQMZ4VB2005RHZ@SEMATECH.Org>...lI > > I'm planning an upgrade from VMS 7.1-2 to 7.3-1, and I'd like to takenM > > advantage of smaller disk cluster sizes to conserve disk space.  Is thereeU > > any reason (such as performance) not to have the smallest cluster size  possible?e > : G > I had a similar discussion on this topic around March 11, 2003 with ab= > Mr. Hein Vandenheuvel of HP. The discussion went like this:o   Thanks for remembering!T] Just for grins.... Here is a perl script to parse DFU output to help guestimate the effect of2 cluster size on wasted space.mV It also reports teh number of files that woudl be mapped with a single cluster, making# fragmentation impossible for those.d_ Note: the script does NOT deal with 'overallocated' files, that is files which have more than atA single cluster between the registred eof and the allocated space.    Sample output:     $ perl CLUSTER_SIZE.P < dfu.tmpt  : 6168 (6168) Files with 6168 headers 2918870/3293460 11.37%  ' Cluster ____Waste ______ Single_Clusterm' ------- --------- ------ -------- -----o&       1         0  0.00%   1430 23.18%&       2      3470  0.11%   1892 30.67%&       3      7414  0.23%   2257 36.59%&       4     10814  0.33%   2777 45.02%&       5     14975  0.45%   3053 49.50%&       6     18664  0.57%   3290 53.34%&       7     22607  0.69%   3485 56.50%&       8     27258  0.83%   3614 58.59%&       9     31357  0.95%   3726 60.41%&      10     36180  1.10%   3851 62.44%       :    :&      99    508510 15.44%   5511 89.35%&     100    513330 15.59%   5514 89.40%    9 # This perl script will process an DFU search output fileiA # to analyze the effect of cluster size on wasted allocaed space. E # use a PIPE or: defi/user sys$output dfu.tmp, and DFU SEARCH disk00:e # 5 # system$disk00:[directory]filename,ext;vers      1/9s #Primary headers : 6168e+ #Files found : 6168, Size : 2918870/32934602 while (<>) {   if (/(\d+)\/(\d+)$/) {     $end=$1;     $all=$2;      if (/Files found : (\d+)/) {B       print "\n$1 ($files) Files with $headers headers $end/$all";2       printf (" %5.2f%%\n", ($all-$end)*100/$all);       } else {       $files++;e       $file{$end}++;       }a     } '   $headers = $1 if (/headers : (\d+)/);b   }r  - #foreach $end (sort {$a <=> $b} keys %file) {s* #  printf ("%6d %d\n", $file{$end}, $end); #  }  2 print "\nCluster ____Waste ______ Single_Cluster";4 print "\n------- --------- ------ -------- -----\n"; while ($c++ < 100) {
   $waste = 0;a   $singles = 0;e   foreach $end (keys %file) {a      $count = $file{$end};(      $singles += $count if ($end <= $c);.      $w = $c * int(($end +$c -1) / $c) - $end;      $waste += $count * $w; - #     print "$c, $count, $end, $w, $waste\n";       }*   printf ("%7d %9d %5.2f%% %6d %5.2f%%\n",@     $c, $waste, $waste*100/$all, $singles, 100*$singles/$files);   }n    	 Comments?n Hein.e   ------------------------------  % Date: Tue, 25 Nov 2003 10:45:18 +0100e? From: Roland Mainz <roland.mainz@informatik.med.uni-giessen.de>n5 Subject: Re: Fonts for printing from a decwindows appo= Message-ID: <3FC324AE.E8A79778@informatik.med.uni-giessen.de>n   Fred Kleinsorge wrote:N > > > > > Yep.  And it is about to get worse with the Alpha version getting an > > > upgrade, > > > > > but not the VAX one. > > > >>C > > > > Uhm... why ? Forcing user to switch over to Alpha or what ?  > > >cN > > > JF just likes to spout off.  The Alpha X11 bits (Xlib/Xt/transport) wereF > > > brought up to X11R6.6 and things like kerberos were added to the > transport.K > > > Why?  New things like JAVA and eBusiness needed some of the features.c > >nD > > Does the upgrade include the libXp.so (X print extension) shared > > library, too ? >  > I don't think it is.   ;-(t  6 ... who can be contacted to at it to the next update ?   ----   Bye, Roland   -- c   __ .  . __8  (o.\ \/ /.o) Roland.Mainz@informatik.med.uni-giessen.de<   \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer5   /O /==\ O\  TEL +49 2426 901568 FAX +49 2426 901569i
  (;O/ \/ \O;)s   ------------------------------  % Date: Tue, 25 Nov 2003 11:02:41 +0100n? From: Roland Mainz <roland.mainz@informatik.med.uni-giessen.de>h5 Subject: Re: Fonts for printing from a decwindows appd= Message-ID: <3FC328C1.455FA059@informatik.med.uni-giessen.de>y   JF Mezei wrote:t  K > > Just curious: Would it be possible to port it (I guess we would need ane@ > > assember hacker for the XPConnect stuff and a decent ISO C++ > > compiler...) ? > M > VAX has the C++ and C compilers. and it has the Xwindows software (just the ' > older one, Motif 1.2-5 for instance).a  E Not every C++ compiler can compile Mozilla successfully (or KDE/Qt oroF OpenOffice) ... the requirements for C++ standard-compilance are quite high...   K > > The Xprint server side is only a piece of software which translates the J > > X11 drawing instructions to the matching PDL (for example: PostScript)I > > and sends those print jobs to the spooler if the application finishesIH > > it's print job. No special hardware is needed... it's only software. > C > Is it possible to have it run on the X-client side of things (thebO > "mainframe").  Since the job would be spooled by the mainframe, it would makea) > sense to have the file generated there.-  H Well, you can run the Xprint server on the same machine as the client... no problem with that... :)  G > > of images is implemented, don't worry. You can grab images from the-L > > video Xserver and print them on the print Xserver without blowing-up the? > > amount of data send to the printer (that would be stupid :)l > N > But sometimes much simpler to accomplish since you let the printer do the up > or down sampling of image :-)a  G ... but the quality isn't as good as an image which uses vector drawingoE instructions or uses a bitmap which matches the resolution (or has at:F least an even scaling factor (for example 150DPI image on 600DPI paper5 looks better than a 160DPI image on 600DPI... :)) ..."   ----   Bye, Roland   -- E   __ .  . __8  (o.\ \/ /.o) Roland.Mainz@informatik.med.uni-giessen.de<   \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer5   /O /==\ O\  TEL +49 2426 901568 FAX +49 2426 901569$
  (;O/ \/ \O;)N   ------------------------------  % Date: Tue, 25 Nov 2003 10:02:21 -0800V1 From: "Paul Hodson" <paul.hodson@gems7.gov.bc.ca>  Subject: Ghostscript+ Message-ID: <3fc39906$1@obsidian.gov.bc.ca>T   Hi,T  K Does anyone have experience with using ghostscript on openvms to convert psE to pdf?_   Thanks,    --K Disclaimer:  Any comments made are personal and do not reflect the thoughts  or policies of this company.   ------------------------------  % Date: Tue, 25 Nov 2003 14:05:15 +0800L, From: Paul Repacholi <prep@prep.synonet.com>2 Subject: Re: Hobbyist license and layered products- Message-ID: <87wu9pnftw.fsf@prep.synonet.com>-  $ Didier Morandi <no@spam.com> writes:  C > The login data from the last quarter's "Cover Letter" can be used D > for access. That login data will not expire until you receive thisF > quarter's "Cover Letter", which provides an overlap period into next
 > quarter.  F So if the SPL goes walkabout in the mail, and you NEED access, you canF be stuck without the current access info when the old is canned due to the new having been `recieved'.-  ( I think this could be improved somewhat.   -- s< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.i@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------    Date: 25 Nov 2003 06:34:53 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) 2 Subject: Re: Hobbyist license and layered products3 Message-ID: <KZWp+umzrgmo@eisner.encompasserve.org>n  \ In article <87wu9pnftw.fsf@prep.synonet.com>, Paul Repacholi <prep@prep.synonet.com> writes:& > Didier Morandi <no@spam.com> writes: > D >> The login data from the last quarter's "Cover Letter" can be usedE >> for access. That login data will not expire until you receive thisrG >> quarter's "Cover Letter", which provides an overlap period into next> >> quarter.n > H > So if the SPL goes walkabout in the mail, and you NEED access, you canH > be stuck without the current access info when the old is canned due to! > the new having been `recieved'.t  8 Somehow this seems not to be about the hobbyist program.  B It would be good to change the title so people have a better guide regarding what posts to read.f   ------------------------------    Date: 25 Nov 2003 07:59:08 -0800& From: denny_rich@ameritech.net (Denny)8 Subject: Re: Hobbyist license and layered products - SLS= Message-ID: <2a9d9498.0311250759.12091a13@posting.google.com>u  ] hoff@hp.nospam (Hoff Hoffman) wrote in message news:<_Tswb.9601$nj5.1216@news.cpqcorp.net>... h > In article <2a9d9498.0311241015.608f15cb@posting.google.com>, denny_rich@ameritech.net (Denny) writes:A > :> Montagar CD? Specifically I'm interested in COBOL and Notes.h > , >   Notes is on Freeware V6.0, with license. > I > :Is there an Alpha hobbyist license for SLS (Storage Library System)?  dF > :I've got the CD, but I didn't see a license in the email that came  > :from Montagar.J > J >   SLS is an older product and (AFAIK) isn't a product offered to OpenVMSL >   hobbyists.  SLS is assumed of interest only to our commercial customers,, >   in other words, and not to hobbyists.    > J >   FWIW, a basic remote BACKUP procedure is available in the OpenVMS FAQ. >  > P >  ---------------------------- #include <rtfaq.h> -----------------------------M >     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faqsP >  --------------------------- pure personal opinion ---------------------------G >         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.comt  B The reason i ask, is that last week, I came across a TZ88 that wasA being discarded (yes, you heard that right).  I asked for and wasoE given permission to carry it out to the dumpster.  So now I have this F thing plugged into my BA356, and I can run backups. I thought it would* be fun to use SLS to maintain the catalog.  C This all assumes my Sandpiper doesn't croak. And I guess a hobbyist D with an almost current DLT is a bit unusual. But then 3 months ago ID 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!  > Is there anyone I can talk to about getting a SLS-MGR license?   thanks   denny=   ------------------------------  % Date: Tue, 25 Nov 2003 17:21:55 +0100h" From: Didier Morandi <no@spam.com>Y Subject: HPember VAX/VMS to Itanium Migration Newsletter: table of contents (fyi) (fyi)(f=3 Message-ID: <3fc381ca$0$2373$626a54ce@news.free.fr>=  0 Please find below fyi the toc of the next issue:  R o My VAX/VMS business critical software is not ported by HP to OpenVMS on Itanium.P o The publisher of my VAX/VMS business critical software does not exist anymore.Q o The publisher of my VAX/VMS business critical software dropped the product ten e
 years ago.I o Is double binary translation (VEST/AEST) a production-quality solution? 9 o When VAX computers are EOL, what will occur to VAX/VMS?T& o Are second hand systems a gold mine? o Resources todayC" o The Experts Corner (interviews) o Advertising (FutureVAX)m   I think/hope you will like it.P It will be available on the 1st of December 2003, exactely twenty years since I  joined DEC in the Paris TSC.   D.   ------------------------------  # Date: Tue, 25 Nov 2003 14:40:22 GMT>& From: jlsue <jefflsxxxz@sbcglobal.net> Subject: Re: IA64 TPC results>8 Message-ID: <p5q6svc728bis2euqtlt9ar2qpnlmjr47q@4ax.com>  E On Mon, 24 Nov 2003 15:51:14 +0000, Andrew Harrison SUNUK Consultancy>. <Andrew_No.Harrison_No@nospamn.sun.com> wrote:     >r9 >I have always been a bit suprised by Jeffs choice of notf9 >to use an offical HP username/job title etc. Kerry Mainei: >who mines a similar vein of marketing BS thinly disguised9 >as technical advice for HP at least seems happy to admitd' >to working for HP whats Jeffs problem.  >r  J I have no problem, do you?  I choose how I wish to use the Internet and it just differs from your method.  H Since I don't (and can't) speak in any capacity or authority of anythingK happening internal to HP, it makes perfect sense for me to provide my views 0 as just as much an outsider as anyone else here.  K I don't hide my employment from anyone, but only wish to make it clear that H I have no inside knowledge and no connection to the business end of thisI stuff.  Also, since my organization does consulting for many different HPiK products, OpenVMS is only a part of my business nowadays - meaning that I'mo7 not so vested in it that it colors my view of things.  u  D Other than personal preference for the OS (and, of course, some veryG detailed technical & business experience with it), it's absolute healthtI does not impact my day-to-day business dealings.  I'd prefer that it were=< more prominent, but most customers today are multi-platform.   --- jlsr0 The preceding message was personal opinion only.6 I do not speak in any authorized capacity for anyone,  and certainly not my employer.- (get rid of the xxxz in my address to e-mail)=   ------------------------------  % Date: Tue, 25 Nov 2003 09:16:59 -0500e& From: "Island" <dbturner@islandco.com>6 Subject: Low Cost maintenance contracts USA and Europe/ Message-ID: <vs6p4qt13ib1fa@news.supernews.com>s  J We are now offering low cost parts replacement contracts for the following systems:   Alphaserver DS10L  Alphaserver DS10 Alphaserver DS20 Alphaserver DS20ea Alphaserver ES40 Alphaserver GS60/GS60e Alphaserver GS140/8400 Alpha XP1000 Alpha Personal Workstationsi Alphaserver 800-  J We stock parts down to fan assemblies, switches, cpu boards power supplies  * Warranty periods from 12 months to 5 years0 Prices will include Federal Express P1 shipping.  < If interested, you may call or email us at sales-at-hpaq.netD Due to heavy spamming, we have changed the email address accordingly please replace -at- with "@"     Island Computers US Corporationl 2700 Gregory St., Suite 180e Savannah GA 31404. Tel: 912 447 6622  Fax: 912 201 0402v http://www.hpaq.netM   ------------------------------  # Date: Tue, 25 Nov 2003 14:59:25 GMTh& From: jlsue <jefflsxxxz@sbcglobal.net>> Subject: Re: New maynagement software Nimbus also for OpenVMS?8 Message-ID: <cjr6svoqcg9r8j5k6sutvne36gecdov23v@4ax.com>  E On Mon, 24 Nov 2003 14:28:04 +0000, Andrew Harrison SUNUK Consultancy . <Andrew_No.Harrison_No@nospamn.sun.com> wrote:  
 >jlsue wrote:DH >> On Mon, 24 Nov 2003 12:31:37 +0000, Andrew Harrison SUNUK Consultancy1 >> <Andrew_No.Harrison_No@nospamn.sun.com> wrote:  >> n >> , >>>Rudolf Wingert wrote: >>> 
 >>>>Hello, >>>>S >>>>today I red, that HP will produce a new management software called Nimbus. This,P >>>>software should function on Windows, Linux und HP-UX. I did not red anythingR >>>>about OpenVMS. But the mention should be: one managment software, one look and$ >>>>feel for it on all OS platforms. >>>> >>>e? >>>You have to admire a company that names a management producte1 >>>after a broomstick used by a fictional wizard.s >>>e >> 1 >> 3E >> Hey Andrew, try a google search of Nimbus.  You might get a littleA
 >> education.y >> ( >p" >Hey Jeff try reading Harry Potter >2  ) As if I could avoid seeing it everywhere.2K But your implied assumption is that Harry Potter is the only source of thath name.  It's not...   --- jlss0 The preceding message was personal opinion only.6 I do not speak in any authorized capacity for anyone,  and certainly not my employer.- (get rid of the xxxz in my address to e-mail)r   ------------------------------  % Date: Tue, 25 Nov 2003 11:58:52 -06007( From: brandon@dalsemi.com (John Brandon)J Subject: Re: odd SMTP e-mail when sending to page.metrocall.com (RESOLVED)1 Message-ID: <03112511585285@dscis6-0.dalsemi.com>e  O > I would try modifying my scripts to send the pager mails to one of my systemsrO > instead of page.metrocall.com.  Then I would look at the three mail files and ; > compare them to see what was different between A and B/C.s > + > Here are a couple of ideas to check on.  e > M > Maybe the From address used in A will resolve but the From address used in  M > B/C can't DNS resolve within metrocall.  Some mailers will drop mail where  # > the From address doesn't resolve.n > A > Maybe the text sent by B/C is mime encoded and A is plain text.r >  > Latert >  > Mark Hittinger
 > bugs@pu.nete  ; Thanks Mark.  I did as you suggested.  Used the SFF utilitymK (sys$system:tcpip$smtp_sff.exe) to verify any oddities between sending mailrI from the three different servers.  Nothing.  This did help me in pointing ( squarely at the source of the problem...  O We found the resolution in another area.  Hopefully this will help someone elset down the road...  L The outbound e-mail from the VMS servers were being properly relayed through0 the MS Exchange server (acting as smtp gateway).  . However MetroCall was rejecting those e-mails.  K Since we do not use aliases for the VMS accounts the rejected messages wereoM going in the bit bucket.  It was not until the NT group got into the trackings0 log files that they were able to determine this.  L Then the gotcha.  Our ISP did not have an MX Record for the two servers thatM were failing in sending e-mail pages.  However, the ISP did have an MX Recordi= for the server that was sucessfully sending the e-mail pages.f  # Problem solved.  Thanks again Mark!m         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 15:02:54 GMTn& From: jlsue <jefflsxxxz@sbcglobal.net> Subject: Re: ODS2 file headert8 Message-ID: <3pr6svsnpeugpg7np0tve96vsq1avfap8l@4ax.com>  F On Mon, 24 Nov 2003 19:25:57 GMT, hoff@hp.nospam (Hoff Hoffman) wrote:  g >In article <2a9d9498.0311241057.2b259718@posting.google.com>, denny_rich@ameritech.net (Denny) writes: p >:denny.rich@swagelok.com (Denny Rich) wrote in message news:<d28306e.0311191237.4bd4791e@posting.google.com>... >..r >:What am I doing?   >:A >:In 1986, i got a copy of Mark Oakley's (Battelle Inst.) Macro32tD >:program that surveys a disk for files larger than 'n', or owned byH >:'[uic]'.  I have used this to provide a "hog list" function everywhereG >:I've worked since 1986. Neat program.  He scans the index file bitmap B >:for set bits, then retrieves the indicated header block. He then> >:traverses the back-links to come up with the directory spec. >tD >  Um, are you familiar with the DCL commands such as the following? >  >    dir/sele=size=min=100 >    dir/by_owner=uic  >e  E Sure, but doesn't the DIRECTORY command traverse the entire directory,J structure on the disk?  Run-time is greatly increased because of this (and  sometimes impact on XQP caches).  E >  For other related processing, please also see DFU on the Freeware.t >r  ! Good tool.  I use it lots myself.b --- jlsr0 The preceding message was personal opinion only.6 I do not speak in any authorized capacity for anyone,  and certainly not my employer.- (get rid of the xxxz in my address to e-mail)a   ------------------------------  % Date: Tue, 25 Nov 2003 07:04:13 -0800s# From: "Tom Linden" <tom@kednos.com>t Subject: OT: Quotest9 Message-ID: <CIEJLCMNHNNDLLOOGNJIIEJGIIAA.tom@kednos.com>a  ; "I think there is a world market for maybe five computers."A& (Thomas Watson, chairman of IBM, 1943)  I "There is no reason for any individual to have a computer in their home."nG (Ken Olsen, president, chairman and founder of Digital Equipment Corp.,  1977)e  H "The telephone has too many shortcomings to be seriously considered as aD means of communication. The device is inherently of no value to us."# (Western Union internal memo, 1876)    ---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/2003h   ------------------------------  % Date: Tue, 25 Nov 2003 16:59:30 +0100 " From: Didier Morandi <no@spam.com> Subject: Re: OT: Quotes 3 Message-ID: <3fc37c8e$0$2353$626a54ce@news.free.fr>h   Tom Linden wrote:l  = > "I think there is a world market for maybe five computers."f( > (Thomas Watson, chairman of IBM, 1943) > K > "There is no reason for any individual to have a computer in their home." I > (Ken Olsen, president, chairman and founder of Digital Equipment Corp.,p > 1977)a > J > "The telephone has too many shortcomings to be seriously considered as aF > means of communication. The device is inherently of no value to us."% > (Western Union internal memo, 1876)  >  > ---t( > Outgoing 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/2003i  + "The Cinematographe has no business future"eO (Louis Lumire to Georges Mlis, explaining why in 1895 he did not patent his h invention).aO Guess who/where/how I would be if I was refunded one cent each time all of you s" go to the cinema since 1895... :-)   D.   ------------------------------    Date: 25 Nov 2003 02:04:17 -0800- From: denis.fayaud@netspace.mc (Denis Fayaud)h Subject: Qio ?= Message-ID: <93820504.0311250204.1c7e6ec9@posting.google.com>y  
 Hi there !; I use to interface a serial line device using set host/dte.eD This device is sending ASCII messages when a new event is happening.+ So I use a DecTerm to display the messages.g  G I'd like to display those messages in a color box to see their severity 3 (i.e. green message means OK, red is bad and so on).  > I know how to do the box using some extras DecWindows widgets.' I know how to get the message with QIO.   0 But I DON'T know how to manage those two loops ! any ideas ?/ thanx in advance   ------------------------------  % Date: Tue, 25 Nov 2003 06:11:53 -0500-* From: JF Mezei <jfmezei.spamnot@istop.com> Subject: Re: Qio ?) Message-ID: <3FC338C0.75D5DA38@istop.com>c   Denis Fayaud wrote:u@ > I know how to do the box using some extras DecWindows widgets.) > I know how to get the message with QIO.L > 2 > But I DON'T know how to manage those two loops !  L There was some discussion about ASTs in X programs a while ago. Typically, aJ display is updated only when an event has been received. Bu you can't callM Xlib routines from inside an AST because while your AST is executing, anothert7 Xlib routine is executing  (the one waiting for events)i   The solution is documented at:A http://h71000.www7.hp.com/doc/73final/5639/5639motifpro_005.html     look for XtAppAddInput  L (there was a discussion about this last january, I updated the link to point to current location).   L The routine is XtAppAddInput() it is OS sepecific. You use an event flag.  AL callback routine you specified in the XtAddInput is called whenever the flag is set.L  D However, read the doc completely since you can't use any event flag.   ------------------------------  % Date: Tue, 25 Nov 2003 09:59:31 +0100(> From: "Winfried Bergmann" <winfried.bergmannNosPAM@empuron.de>/ Subject: Re: Required reading for HP executives0: Message-ID: <bpv5io$1tfv40$1@ID-170759.news.uni-berlin.de>  = "JF Mezei" <jfmezei.spamnot@istop.com> schrieb im Newsbeitrag5# news:3FC287F0.158BF59B@istop.com...aK > re: article about applications not performaming correctly being one cause. of > the blackout.o >eJ > The use of the term "warm reboot" implies an IBM mainframe. So it is far moreH > likely that Carly would be proposing a HP-UX on IA64 solution complete with$ > billions of dollars of consulting.  7 As far as I know, GE Harris XA21 is running on IBM AIX.u     > K > The interesting portion of the article was the issue of a process failings overC > with such an exact copy that the same problem continued to exist.c >eJ > Perhaps this is where true clusters make a difference since the "backup"H > process can not only participate in normal operations, but is also not such an,' > exact copy since it has its own life.y >dL > However, the danger is in RTR type of software in front of the cluster. If a K > transaction causes process 1 to stall, the RTR type of software will theni sendJ > that transaction to the second process which will also stall since it is thesL > same software, and then RTR will send it to the next node and so on and so forth.  I Usually, EMS communication servers are running as "hot stand by". In thiscI mode, two redundant servers receive the same information from the processeH (RTUs or other equipment, connected to electric equipment like switches,L circuit breakers, transfomers, generators a.o.). So, if one server fails dueJ to software errors in the EMS systems, the second usually follows, becauseD it's running the same software! Those problems are seldom related to/ computer hardware or operating system concepts.h   ------------------------------  % Date: Tue, 25 Nov 2003 04:48:24 -0500r* From: JF Mezei <jfmezei.spamnot@istop.com>/ Subject: Re: Required reading for HP executivese' Message-ID: <3FC32534.75A2F7@istop.com>    Winfried Bergmann wrote:K > mode, two redundant servers receive the same information from the processeJ > (RTUs or other equipment, connected to electric equipment like switches,N > circuit breakers, transfomers, generators a.o.). So, if one server fails dueL > to software errors in the EMS systems, the second usually follows, because! > it's running the same software!e    N While this appears very stupid on the surface, it is a serious problem. havingL two totally different programs running as a mirror of each other costs a lotI of money. While it may reduce the odds that a bad packet would bring both ? down, It probably causes a lot of system management nightmares.e    L The Ohio utility may have been the root cause of this summer's blackout, butH the REAL problem was in all the utilities who didn't have automatic loadR shedding as soon as the ohio stopped exporting its power, causing a power deficit.  N In qubec, we had a similar even in the mid/late 1980s when aurora borealis upN north induced additional current into the power lines from the james bay hydroJ plants. Breakers tripped because of that, but the rest of the Hydro QubecK network didn't react to the sudden loss of a major power feed and the wholep thing went down.  L Hydro Qubec quickly rewrote its software after that very visible black eye.J How come other utilities didn't include automated load shedding into theirL systems after the Hydro Qubec "event" ? They had something like 10-15 yearsF to implement this, with full knowledge of the hydro qubec experience.   ------------------------------  % Date: Tue, 25 Nov 2003 11:34:14 +0100 > From: "Winfried Bergmann" <winfried.bergmannNosPAM@empuron.de>/ Subject: Re: Required reading for HP executives : Message-ID: <bpvb4b$1t38qt$1@ID-170759.news.uni-berlin.de>  = "JF Mezei" <jfmezei.spamnot@istop.com> schrieb im Newsbeitragn! news:3FC32534.75A2F7@istop.com...' > Winfried Bergmann wrote:E > > mode, two redundant servers receive the same information from thet processtL > > (RTUs or other equipment, connected to electric equipment like switches,L > > circuit breakers, transfomers, generators a.o.). So, if one server fails duetF > > to software errors in the EMS systems, the second usually follows, because # > > it's running the same software!w >h >EI > While this appears very stupid on the surface, it is a serious problem.u havingJ > two totally different programs running as a mirror of each other costs a lotsK > of money. While it may reduce the odds that a bad packet would bring bothoA > down, It probably causes a lot of system management nightmares.s  H In hot stand by configurations, the stand by server usually doesn't stopK because of failures, only in very severe situations. Even core dumps shouldeG not bring those system down. The cored programs continue to run and thef9 server stays up, but possibly with incorrect information.t   >n >hJ > The Ohio utility may have been the root cause of this summer's blackout, but J > the REAL problem was in all the utilities who didn't have automatic loadK > shedding as soon as the ohio stopped exporting its power, causing a powero deficit. >eD > In qubec, we had a similar even in the mid/late 1980s when aurora borealis upaJ > north induced additional current into the power lines from the james bay hydro-L > plants. Breakers tripped because of that, but the rest of the Hydro QubecG > network didn't react to the sudden loss of a major power feed and theo wholee > thing went down. >FI > Hydro Qubec quickly rewrote its software after that very visible black  eye.L > How come other utilities didn't include automated load shedding into theirH > systems after the Hydro Qubec "event" ? They had something like 10-15 years H > to implement this, with full knowledge of the hydro qubec experience.  D Btw: HQ switched to a new EMS a few years ago, but this "new" systemH included load schedding (and outage management), also running on IBM/AIX
 platforms!   ------------------------------  % Date: Tue, 25 Nov 2003 06:31:21 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>/ Subject: Re: Required reading for HP executivesd) Message-ID: <3FC33D4F.CEFC007F@istop.com>1   Winfried Bergmann wrote:J > In hot stand by configurations, the stand by server usually doesn't stopM > because of failures, only in very severe situations. Even core dumps shouldpI > not bring those system down. The cored programs continue to run and thea; > server stays up, but possibly with incorrect information.o  L There are situations where this would not be tolerated. I would think that aK power utility should be seen as a life critical service where such failuresi should not be tolerated.  K Power utilities no longer just keep lights and TVs going. When you considerrI the impact of a power failure on city traffic and how ambulances and fireMH trucks can't reach their destination if trffic is jammed because trafficN lights are gone, when you consider people stuck in elevators, subways etc. You+ can't afford to put everything on a UPS :-)p  K And when you have nuclear power plants that automatically shutdown and then$N take forever to restart,  it means that such an outage is truly very important and very costly.  F > Btw: HQ switched to a new EMS a few years ago, but this "new" systemJ > included load schedding (and outage management), also running on IBM/AIX > platforms!  " Was it previously running on VMS ?   ------------------------------  % Date: Tue, 25 Nov 2003 13:34:48 +0100/> From: "Winfried Bergmann" <winfried.bergmannNosPAM@empuron.de>/ Subject: Re: Required reading for HP executivesJ: Message-ID: <bpvi6c$1sa4po$1@ID-170759.news.uni-berlin.de>  = "JF Mezei" <jfmezei.spamnot@istop.com> schrieb im Newsbeitrag4# news:3FC33D4F.CEFC007F@istop.com...r > Winfried Bergmann wrote:L > > In hot stand by configurations, the stand by server usually doesn't stopH > > because of failures, only in very severe situations. Even core dumps shouldK > > not bring those system down. The cored programs continue to run and thec= > > server stays up, but possibly with incorrect information.2 >nL > There are situations where this would not be tolerated. I would think that a D > power utility should be seen as a life critical service where such failures > should not be tolerated. >lD > Power utilities no longer just keep lights and TVs going. When you considerK > the impact of a power failure on city traffic and how ambulances and fireuJ > trucks can't reach their destination if trffic is jammed because trafficL > lights are gone, when you consider people stuck in elevators, subways etc. Youd- > can't afford to put everything on a UPS :-)g >e  L If a server stays up with incorrect information depends on the importance ofK the information. This is a very complex subject in an EMS, but if importantoJ values are no longer guaranteed to be correct, the server will go down, soH don't be afraid, too much ;-) (information in an EMS is sanity checked!)      H > And when you have nuclear power plants that automatically shutdown and thenF > take forever to restart,  it means that such an outage is truly very	 important  > and very costly. >zH > > Btw: HQ switched to a new EMS a few years ago, but this "new" systemL > > included load schedding (and outage management), also running on IBM/AIX > > platforms! >7$ > Was it previously running on VMS ?  G I don't know the previous system of HQ (but I know cases, where VMS/VAXr. systems have been replaced by Solaris systems)   ------------------------------    Date: 25 Nov 2003 09:03:35 -0600+ From: young_r@encompasserve.org (Rob Young)w/ Subject: Re: Required reading for HP executivess3 Message-ID: <c7$zJdqCJOs5@eisner.encompasserve.org>t  o In article <aeuwb.21246$X2W1.15540@news04.bloor.is.net.cable.rogers.com>, "John Smith" <a@nonymous.com> writes:sM > If HP corporate execs and OpenVMS executives can't figure out how to marketcL > VMS and VMS clusters from this .......then bring back the good old days of > Stalinist purges.c >    > < > I've previously mentioned application assurance tools like> > those from TeaLeaf Technology Inc. At eWEEK Labs, we've also> > seen significant improvement of late in application security> > analysis products like Sanctum Inc.'s AppScan. The tools are > there. > : > (Site security and uptime demand a sniper's precision in > picking off the problems) > > http://eletters.eweek.com/zd1/cts?d=79-331-6-7-71952-39716-1- > (Read eWEEK Labs' review of AppScan 4.0 QA)0> > http://eletters.eweek.com/zd1/cts?d=79-331-6-7-71952-39719-1 > 8 > What's also needed, though, as the East Coast blackout: > report clearly shows, is a culture of responsibility for7 > making sure that the system is meeting the enterprise  > need--and not just "working."5 >   9 	Nice post John.  Sometimes you gain the wrong opinion of  	anonymous ghosts.  ? 	It appears as if they are too cheap.  I guarantee with Tivoli uH 	Monitoring, they could have created a custom monitor for their mission E 	critical systems (if the vendor doesn't supply a plug-in) that this	n? 	would have been caught.  Oh - before anyone chimes in , Tivoli6= 	Monitoring (ITM) has heartbeat - if it doesn't hear from the$) 	node being monitored, that is a problem.F  > 	There are cheaper monitors, home grown and freeware.  In factC 	being cheap is no excuse, they surely could be running Big Brother/> 	http://bb4.com/ and create scripts to do essentially the same 	thing.   = 	What it appears to boil down to - (outside looking in) is a hC 	department that isn't well run.  Letting mission critical systems $D 	that potentially lose large amounts of money, risk lives when they " 	are down, to be casually managed.   				Rob-   ------------------------------  # Date: Tue, 25 Nov 2003 14:00:10 GMTc# From: "John Smith" <a@nonymous.com> - Subject: Re: Routable Protocol for Clustering<E Message-ID: <KfJwb.1000$zJq.578@news01.bloor.is.net.cable.rogers.com>$   David Froble wrote:n > Bob Koehler wrote: >$
 >> In article L >> <92EFB80E551BD511B39500D0B7B0CDCC11053206@ohms.electric.ci.austin.tx.us>,4 >> "Stuart, Ed" <Ed.Stuart@austinenergy.com> writes: >>C >>> This message is in MIME format. Since your mail reader does not:B >>> understand this format, some or all of this message may not be >>> legible. >>>:+ >>> ------_=_NextPart_001_01C3B055.165F29F0o >>> Content-Type: text/plain >>>fE >>> We keep getting pressure from our networking group to consolidate E >>> our multi-site VMS cluster.  They want this consolidation so theypF >>> do not have to worry about network configurations that support theA >>> non-routable LAVC protocol.  Are there any plans to make LAVCs" >>> routable or tunnel LAVC in IP? >>>  >>> Ed >>>s >>@ >>    Making LAVC routable just doesn't make sense, neither doesF >>    tunneling it.  When you've got your systems linked at the kernel/ >>    you need a quick, tight network protocol.t >> >> >iC > If you have a multi-site cluster for disaster tolerance, then you B > need to approach the networking group with a 2x4 and pink slips. >oF > Another case of the networking people no longer providing a service,E > but rather dictating what you can and can't do.  Do you really needs > these clowns?A    K Been there, done that....Y2K readiness efforts with a large stock brokerage(. firm ....how large...about as big as they get.  G We had MQ channels set up over a circuit to a securities depository foriE testing of a new application. This circuit and channels were setup indD anticipation of testing begining in Sept. 1999 but due to additionalH requirements by the customer, we ultimately expected to begin testing inJ late-October (all this was past the customer's own self-imposed cutoff forJ new application development and implementation leading up to Y2K)...we hadH to get special dispensation from the gods in order to do this project asK their 'hard' cutoff for new development that year was June 30th. Anyway, welG get to the point where we are going to start bi-directional testing andl) boom.....no MQ channels...no circuit.....s  K We start digging and find out that the head of the networking group decidednI unilaterally and without informing anyone that the circuit, which he knewsG existed because he co-ordinated its setup with the depository, had beenjJ removed along with the AIX box that it ran on....because he didn't want toH support an AIX box (they were mostly a Solaris shop). Why AIX for MQ? ItL matched the version at the depository, so we and the local IBM MQ specialistK figured that we'd run less risk that way - the latest Solaris version of MQmK needed a release of Solaris that was higher than the customer was currentlypI running and they weren't going to change their production/backup machines 
 ahead of Y2K.h  L Blood-curdling screams and much arm waving and threats later, we got a *new*F AIX box (the original one had already been disposed of), the telephoneL company worked like fiends to re-establish the circuit, IBM was called in toL ensure that MQ and AIX and the circuit were correctly setup, and we began toL test in the last week of November. This little fiasco cost an extimated $50kI in people-time and money paid out the door to the telephone company, IBM, # and compensation to the depository.   F The network guy....he gets a big bonus at bonus time in January. I get1 stiffed for $80k for being 'late' on the project.e   ------------------------------  % Date: Tue, 25 Nov 2003 11:58:25 +0100A" From: Didier Morandi <no@spam.com>$ Subject: SimH: no cluster connection3 Message-ID: <3fc335f7$0$2365$626a54ce@news.free.fr>s  Q I have built a VMS Cluster and tried to have my SimH node join it (VAX/VMS 6.2). iP I successfully created the SimH node as a Cluster member with LAN commectivity, Q but when it boots, the Connection Manager does not find my cluster (same number, a same pwd, same LAN).  	 Any idea?t   Thanks,r   D.   ------------------------------    Date: 25 Nov 2003 07:22:49 -0800. From: fabiopenvms@yahoo.com.br (Fabio Cardoso)( Subject: Re: SimH: no cluster connection< Message-ID: <f30679fb.0311250722.665e3fa@posting.google.com>  ] Didier Morandi <no@spam.com> wrote in message news:<3fc335f7$0$2365$626a54ce@news.free.fr>...aS > I have built a VMS Cluster and tried to have my SimH node join it (VAX/VMS 6.2). iR > I successfully created the SimH node as a Cluster member with LAN commectivity, S > but when it boots, the Connection Manager does not find my cluster (same number, y > same pwd, same LAN). >  > Any idea?s > 	 > Thanks,  >  > D.  4 Any idea about putting this SimH  under Pocket PC ? % May be we can have it in the future !s  ( What about WiFi OpenVMS clustering ? ;-)  @ Or may be we can run several instances of SimH under Itanium-VMS$ to run VAX/VAM, AXP/VMS or MPE ! :-)  J It remembers me Suns Wabi ! When I tried to run Corel Draw under it ! :-0   Regardso   FC   ------------------------------    Date: 25 Nov 2003 02:55:56 -08003 From: paul.j.whapshott@lineone.net (Paul Whapshott)-" Subject: Re: SQLSRV V7.1-5 Problem= Message-ID: <51f54c31.0311250255.1c8cf8bc@posting.google.com>    The previous version was 7.0     "Barratt, Chris (FMC)" <Chris.Barratt@fmc.sa.gov.au> wrote in message news:<E829CF9B8F94014887EBC61E1951B0CE9E75C9@sagemshs001.fmc.sa.gov.au>...H > > Under the previous version of SQL this was the same with only errorsF > > going to the logfile. Now it appears as is all activity is logged. > N > I have seen this behaviour under SQL Services 7.0 and now 7.1. I don't thinkL > we used transaction reusable services under 6.1, so I am not sure what the > situation was there. > * > What version was your previous version ?   ------------------------------    Date: 25 Nov 2003 02:55:56 -08003 From: paul.j.whapshott@lineone.net (Paul Whapshott)n" Subject: Re: SQLSRV V7.1-5 Problem= Message-ID: <51f54c31.0311250255.4230c5fb@posting.google.com>r   The previous version was 7.0 e   "Barratt, Chris (FMC)" <Chris.Barratt@fmc.sa.gov.au> wrote in message news:<E829CF9B8F94014887EBC61E1951B0CE9E75C9@sagemshs001.fmc.sa.gov.au>...H > > Under the previous version of SQL this was the same with only errorsF > > going to the logfile. Now it appears as is all activity is logged. > N > I have seen this behaviour under SQL Services 7.0 and now 7.1. I don't thinkL > we used transaction reusable services under 6.1, so I am not sure what the > situation was there. > * > What version was your previous version ?   ------------------------------  % Date: Tue, 25 Nov 2003 10:36:36 +0000oO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>eB Subject: Re: Sun to use AMD Opteron - announcement expected Monday0 Message-ID: <bpvbbk$mpg$1@new-usenet.uk.sun.com>   Bill Todd wrote:: > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:eQVWdFd4i26P@eisner.encompasserve.org...  >  > = >>>If you are Sun/IBM or AMD with under half the power budgetnA >>>and at least in the case of Sun plans that will result in this>C >>>improving not getting worse, then life is less of a struggle andOB >>>you don't necessarely need to hope that an entirely new processC >>>which may arrive sometime in the latter half of this decade willf >>>save you. >> >>D >>Since high-k runs much cooler, certainly they could create largishD >>(300-400 mm2) CPUs that contain 96 MByte on-chip cache and consume+ >>far less power, generate a lot less heat.m >  > L > I believe that Andrew's observation was that it will be the latter portionL > of this decade before this begins to help.  You're back to selling futures< > again, and this time even more distant futures than usual. >   < My point exactly the new process Rob refers to is not due to produce anything until 2007.  ; As always with Rob futures have a way of weaving themselves"9 into the present to produce what appears to be a seamlesse> proposition that in reality requires a working time machine to exploit.   regardsn Andrew Harrison-   ------------------------------  % Date: Tue, 25 Nov 2003 10:32:59 +0000MO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>aB Subject: Re: Sun to use AMD Opteron - announcement expected Monday0 Message-ID: <bpvb4s$mo4$1@new-usenet.uk.sun.com>   Rob Young wrote: > In article <bpt91g$1u3$1@new-usenet.uk.sun.com>, Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes: >  >>Rob Young wrote: >>b >>>In article <OYqdneghAMvtqCeiRVn-hA@metrocast.net>, "Bill Todd" <billtodd@metrocast.net> writes: >>>s >>>lN >>>>With both Sun and IBM legitimizing AMD64, Itanic looks an awfully lot lessO >>>>invincible than many would have one believe, and IBM's and Sun's *existing*nJ >>>>proprietary platforms continue to look like mature viable alternativesO >>>>rather than 'legacy' hardware.  Why would Sun instead choose to become justDG >>>>another me-too Itanic vendor struggling to overcome HP's sweetheart. >>>>relationship with Intel? >>>> >>>  >>>eC >>>	But Intel has some recent surprises in store.  Industry chattere@ >>>	has been about high-k over the years.  Intel surprised folksB >>>	and announced their high-k research is complete after 5 years  >>>	of development.o >>>aG >>>http://www.intel.com/labs/features/si11031.htm?iid=labs+si11031.htm&a >>>eI >>>The entire semiconductor industry is struggling with the heat of chipsbP >>>increasing exponentially as the number of transistors increase exponentially.R >>>Moving to new high-k materials that control leakage is one step of many towardsP >>>making transistors run cooler. Because high-k gate dielectrics can be severalK >>>times thicker, they reduce gate leakage by over 100 times, and thereforenR >>>devices run cooler. At the same time, Intel has engineered and is demonstratingM >>>metal gate electrodes - which sit on top of the gate dielectric - that arey' >>>compatible with high-k dielectrics. e >>>o >> >>Depends on where you sit.t >>> >>If you are Intel with a processor that currently pushes 130+9 >>watts with plans that will result in this getting worses; >>rather than better in the medium term then you are really 6 >>struggling. With 2007 looking increasingly far away. >> >  > ? > 	Which IA64 processor?  There are a number of them, they haver? > 	an IA64 processor that consumes far less than 130 Watts.  InlC > 	fact, they have an IA64 processor that consumes somewhere aroundc@ > 	62 Watts and outperforms any SPARC processor.  But why shouldA > 	power consumption be a metric for something other than densityr > 	oriented boxes? >   ? You are as always promoting a product that you cannot currentlyt: buy Deerfield and one that has very uncertain performance.  A Who knows what reducing the clock speed and the onchip cache size = will have on performance but one can only assume that it willn= not improve it leaving Deefield competing against much fastern' and cheaper IA-32 and AMD x86-64 CPU's.s     >  > < >>If you are Sun/IBM or AMD with under half the power budget@ >>and at least in the case of Sun plans that will result in thisB >>improving not getting worse, then life is less of a struggle andA >>you don't necessarely need to hope that an entirely new processnB >>which may arrive sometime in the latter half of this decade will >>save you.c >  >  > E > 	Since high-k runs much cooler, certainly they could create largishsE > 	(300-400 mm2) CPUs that contain 96 MByte on-chip cache and consumel, > 	far less power, generate a lot less heat. > > > 	If you look at their roadmap over the next 2-3 years , theyD > 	have a 9 MByte Madison, Montecito in 2005, Tanglewood in 2006 andI > 	follow-ons.  Maybe a high-k Tanglewood is little more than quadrupling0C > 	on-chip caches?  Do you think a 2006 Tanglewood won't meet poweruE > 	budget?  No.  But couldn't it run much faster and have much largeruF > 	caches if the power consumption is greatly decreased?  Sure.  MaybeH > 	clock goes from 1.5 GHz to 4 GHz and they burn 100 watts.  The high-kD > 	will give more design freedom that's for sure.  But they won't be@ > 	performance handicapped until then.  That would be the SPARC. >   C You are making the enormous and rather typical mistake (for you) ofN? assuming that the only way of building a CPU that delivers more = throughput is to clock it faster, increase its cache size and " lengthen its pipeline etc etc etc.  B DRAM speed has not kept pace with DRAM density and the gap betweenE CPU performance and main memory performance continues to increase and F relatively the stall caused by a cache miss costs more hence the clock. it faster and pump the cache size up approach.  B But this isn't the only way and thats at the root of your problem.  H Digital published some analysis of Oracle/TPC-C running on a Alphaserver> 4100 which showed that even something as relatively trivial as> TPC-C resulted in the CPU spending ~50% of its wall clock time stalled.  B Using current CPU's and memory subsystems estimates today put that stalled % as high as 75%.   B Moores Law however gives you access to more transistors to do what you will with.  B The approach that you seem to think is the only one available usesD that resource in one way CMT uses it in another way and because withC CMT L2/L3 cache misses are not so catastropic there is not the need.! to pump up the onchip cache size.d   Regardsl Andrew Harrisonp   ------------------------------  % Date: Tue, 25 Nov 2003 06:24:14 -0500c* From: JF Mezei <jfmezei.spamnot@istop.com>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday) Message-ID: <3FC33BA4.194AD3A0@istop.com>m  ( Andrew Harrison SUNUK Consultancy wrote:= > As always with Rob futures have a way of weaving themselvese; > into the present to produce what appears to be a seamlessl@ > proposition that in reality requires a working time machine to
 > exploit.  I In fairness though, doesn't IA64 currently have more "mainframe" featureseL allowing IA64 based machines to be built with many more processors ? Doesn't- it have features that  Opteron doesn't have ?e  K Doesn't IA64 have lockstep installed right now ? (or is that also somethingc& that will happen only in the future ?)  I So in that sense, Opteron for enterprise is also something that is in the N future. The difference is that Opteron is usable today for smaller servers andL workstations with tons of existing software, whereas IA64 is restricted to a7 very small niche market and has lacklustre performance.e   ------------------------------  # Date: Tue, 25 Nov 2003 14:49:37 GMTw& From: jlsue <jefflsxxxz@sbcglobal.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday8 Message-ID: <skq6svkgbtk9gn7a4740scb8eks2jenp0s@4ax.com>  E On Mon, 24 Nov 2003 15:27:19 +0000, Andrew Harrison SUNUK Consultancye. <Andrew_No.Harrison_No@nospamn.sun.com> wrote:  
 >jlsue wrote:eK >> On Thu, 20 Nov 2003 02:34:38 -0500, "Bill Todd" <billtodd@metrocast.net> 	 >> wrote:h >>   >> a >>  O >>>Nope.  It's because while SPARC performance satisfies a goodly percentage ofbN >>>Sun's customers (and SPARC64 will satisfy even more), it does not offer theB >>>leading-edge performance that *some* Sun customers may require. >> - >> -H >> I'm curious, why was it OKAY for Sun to allow SPARC to drop behind inK >> performance because it "satisfies a goodly percentage of" customers, but7; >> somehow it's not valid for HP to do the same with Alpha?G >> o >h7 >Well assuming the first part of your statement is true3% >Namely that SPARC has dropped behindd< >You still need to show that Sun has allowed that to happen. >o? >Since you can't show that, the whole basis if your argument is@C >somewhat flawed, but then you must be bright enough to know that !g  I In this instance, my argument doesn't hinge on the absolute fact of Sun'saD performance.  Note that I am responding to Mr. Todd.  I am trying toK understand the logic behind two different opinions I've seen come from him,eJ namely:  a) DEC/CPQ/HPQ is bad because they decided to not invest in alphaI to allow it to keep up, and b) Sun is not bad, even though it has decided " not to invest in Sparc to keep up.  F The context is all within that scope of discussion, and not meant as aA presentation of my own analyisis of absolutely Sparc performance.'   Understand?   J If you disagree with Mr. Todd's analysis of SPARC performance, start a new' discussion with him over that analysis.e   >> mE >> One problem, though, is that to date there are no mid- to high-endeN >> AMD-based systems.  There is no track record for these systems to determineL >> how they perform in the real world.  There's nothing to really compare to< >> except workstation and hypothetical server-class systems. >>   > 9 >So explain how AMD differs from Itanium in this respect.-  J Well, that's not entirely true of IA64 systems now is it?  And the vendorsJ involved with the Intel CPU have a track record of high-end systems (e.g.,J PA-RISC and Alpha from an HP perspective).  At least some of these vendorsH are known for providing excellent chipsets for servers using Intel chipsA that allow those CPUs to be utilized in higher-end systems today.,   >rK >> And, to date, it's not clear how well Opteron will be able to perform inoK >> the multi-processor space that competes with other server class systems.hK >> I'm not saying that it will fail, but there's no way to discuss relative6K >> capabilities because they don't much exist today.  They may have to make J >> trade-offs in the system design that inhibit it's competing well in the; >> over-4-processor market.  We just really don't know yet.  >>   >,9 >So explain how AMD differs from Itanium in this respect.. >>  J Superdome.  It may not be the top performer, but it's a real-world system,> high-end, and to date AMD does not have anthing to counter it.   --- jlsv0 The preceding message was personal opinion only.6 I do not speak in any authorized capacity for anyone,  and certainly not my employer.- (get rid of the xxxz in my address to e-mail)    ------------------------------  # Date: Tue, 25 Nov 2003 17:05:28 GMT # From: "John Smith" <a@nonymous.com>eB Subject: Re: Sun to use AMD Opteron - announcement expected MondayI Message-ID: <sZLwb.48149$X2W1.15737@news04.bloor.is.net.cable.rogers.com>m   jlsue wrote:G > On Mon, 24 Nov 2003 15:27:19 +0000, Andrew Harrison SUNUK Consultancy.0 > <Andrew_No.Harrison_No@nospamn.sun.com> wrote: >D >> jlsue wrote: 3 >>> On Thu, 20 Nov 2003 02:34:38 -0500, "Bill Todd"s# >>> <billtodd@metrocast.net> wrote:g >>>i >>>5 >>>iC >>>> Nope.  It's because while SPARC performance satisfies a goodly A >>>> percentage of Sun's customers (and SPARC64 will satisfy eveneF >>>> more), it does not offer the leading-edge performance that *some* >>>> Sun customers may require.a >>>t >>>.F >>> I'm curious, why was it OKAY for Sun to allow SPARC to drop behind@ >>> in performance because it "satisfies a goodly percentage of"D >>> customers, but somehow it's not valid for HP to do the same with
 >>> Alpha? >>>e >>9 >> Well assuming the first part of your statement is trueg' >> Namely that SPARC has dropped behind > >> You still need to show that Sun has allowed that to happen. >>A >> Since you can't show that, the whole basis if your argument isDE >> somewhat flawed, but then you must be bright enough to know that !O > E > In this instance, my argument doesn't hinge on the absolute fact of B > Sun's performance.  Note that I am responding to Mr. Todd.  I amC > trying to understand the logic behind two different opinions I've A > seen come from him, namely:  a) DEC/CPQ/HPQ is bad because they F > decided to not invest in alpha to allow it to keep up, and b) Sun isH > not bad, even though it has decided not to invest in Sparc to keep up. >oH > The context is all within that scope of discussion, and not meant as aC > presentation of my own analyisis of absolutely Sparc performance.r >i
 > Understand?'  <snip>l    & The crux of the matter as I see it is:I a) in June 2001 Compaq said to its customers, 'Everything we/Digital toldnL you about Alpha is wrong. It isn't a leading cpu, it isn't capable of havingK any life beyond the next couple years, it does not and can't have a 25-yearsL life span. My god, what were we thinking? Our cpu designers aren't up to theK challenge. Intel can do anything we do better - even if they don't steal it L from us. That we don't do much if anything to market Alpha has nothing to doK with our decision. Oh, and BTW, were going to screw our partner - Samsung -u while we're at it.'   J b) Sun continues to invest in upcoming versions of Sparc both on their ownK (perhaps one can hold up the EV7 model (post-June 2001 as an analog) and iniE partnership with Fujitsu. They are investing in building systems withnE another chip design (AMD) not of their own creation for some of their  product line (at this point).B  J c) What Sun has not said is that they are killing Sparc. They are spendingK money on three parallel tracks ( Sparc/Sun, Sparc/Sun/Fujitsu, AMD/Sun) ando? seeing which way their customers and the technology steer them.a    K The biggest difference seems to be that Sun appears to be commited to doinglL what its customers think is best. Compaq was dressing itself and carrying onL like a slut hoping to get picked up by sugar daddy/momma: 'Sure Honey - I'llK do whatever you want. Just give me that golden parachute because it sure iseB easier to take that than to market our products and make informed, intelligent decisions.    L And before you take this personally, I have nothing against VMS and Alpha orL IA64 engineers/designers or system builders. My issues start with the peopleE who run advertising/marketing and to levels of decision making in theo0 executive positions above and laterally thereto.   ------------------------------    Date: 25 Nov 2003 11:03:41 -0600+ From: young_r@encompasserve.org (Rob Young)eB Subject: Re: Sun to use AMD Opteron - announcement expected Monday3 Message-ID: <GndLTSmqlLxw@eisner.encompasserve.org>a   In article <bpvb4s$mo4$1@new-usenet.uk.sun.com>, Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes: > Rob Young wrote:   >> c@ >> 	Which IA64 processor?  There are a number of them, they have@ >> 	an IA64 processor that consumes far less than 130 Watts.  InD >> 	fact, they have an IA64 processor that consumes somewhere aroundA >> 	62 Watts and outperforms any SPARC processor.  But why shouldoB >> 	power consumption be a metric for something other than density >> 	oriented boxes?m >> M > A > You are as always promoting a product that you cannot currentlye< > buy Deerfield and one that has very uncertain performance. >   < 	You can buy it.  Dell is selling it.  Is there a SPARC that< 	outpeforms it?  There might be a metric, but we'll probably 	never know.  C > Who knows what reducing the clock speed and the onchip cache sizer? > will have on performance but one can only assume that it will ? > not improve it leaving Deefield competing against much fastert) > and cheaper IA-32 and AMD x86-64 CPU's.v  : 	Now we turn our attention to x86.  I certainly didn't sayA 	it outperforms an x86.  But now we see the not so subtle spinolasE 	from the spin champion.  While highlighting sucky SPARC performance,b; 	quick as a bunny we are attempting to steer the discussionn$ 	in a much more palatable direction.  = >>>If you are Sun/IBM or AMD with under half the power budgetEA >>>and at least in the case of Sun plans that will result in this C >>>improving not getting worse, then life is less of a struggle andoB >>>you don't necessarely need to hope that an entirely new processC >>>which may arrive sometime in the latter half of this decade will  >>>save you. >> e >> s >> hF >> 	Since high-k runs much cooler, certainly they could create largishF >> 	(300-400 mm2) CPUs that contain 96 MByte on-chip cache and consume- >> 	far less power, generate a lot less heat.c >> k? >> 	If you look at their roadmap over the next 2-3 years , theyoE >> 	have a 9 MByte Madison, Montecito in 2005, Tanglewood in 2006 andyJ >> 	follow-ons.  Maybe a high-k Tanglewood is little more than quadruplingD >> 	on-chip caches?  Do you think a 2006 Tanglewood won't meet powerF >> 	budget?  No.  But couldn't it run much faster and have much largerG >> 	caches if the power consumption is greatly decreased?  Sure.  MaybejI >> 	clock goes from 1.5 GHz to 4 GHz and they burn 100 watts.  The high-kIE >> 	will give more design freedom that's for sure.  But they won't besA >> 	performance handicapped until then.  That would be the SPARC.i >> r > E > You are making the enormous and rather typical mistake (for you) offA > assuming that the only way of building a CPU that delivers moret? > throughput is to clock it faster, increase its cache size andg$ > lengthen its pipeline etc etc etc.  ? 	I'm not talking throughput - whatever that vacuous term means,a= 	but I guess we are heading towards Sun marketing terminologyhH 	and direction - "throughput computing."  I'm talking about performance.> 	Noted industry standard metrics as a guage.  SPECint, SPECfp,) 	tpcc, tpcd, SAP and a handful of others.y  D > DRAM speed has not kept pace with DRAM density and the gap betweenG > CPU performance and main memory performance continues to increase andsH > relatively the stall caused by a cache miss costs more hence the clock0 > it faster and pump the cache size up approach. > D > But this isn't the only way and thats at the root of your problem. >   9 	Not a problem, a steerage on your part.  I don't care toi  	discuss "throughput computing."   > Digital published    	[snip]s  D > The approach that you seem to think is the only one available usesF > that resource in one way CMT uses it in another way and because withE > CMT L2/L3 cache misses are not so catastropic there is not the need,# > to pump up the onchip cache size.e    < 	There are other methods and approaches.  SMT comes to mind. 	Keep the execution units busy.j  : 	But where very large on-chip caches make sense is if they: 	can be shared point-to-point.  The "puny" 1.5 MByte L3 of: 	EV7 should become a 24, 48, 96 MByte L3 on IA64.  Turn it; 	point-to-point and worst case 2-hop latency (8-way server)rD 	shouldn't be more than 30-40 nanoseconds access for a cache line.  F 	An 8-way with that much fast L3 ( 8 * 96 = 768 MBytes) should perform? 	admirably.  Seems obvious to me that the EV7 network will makepC 	its way into IA64 and industry speculation runs along those lines.t  A 	That much - that fast - L3 will break most benchmarks even thosenF 	coming down the pike.  Will be interesting to  see if that is how it @ 	comes to pass.   Cache misses?  Can't be much of an effect with" 	aggregate 500-800 MByte L3 cache.   				Robp   ------------------------------  % Date: Tue, 25 Nov 2003 10:00:54 +0100-" From: Didier Morandi <no@spam.com>Y Subject: The DCL minute of the day (was: DCL Enhancements: Error messages for OPEN and DEo3 Message-ID: <3fc31a6c$0$2362$626a54ce@news.free.fr>e   Paul Sture wrote:e  F > OK, here's a little bit of DCL I write on any new site where I might% > want to do edits on multiple files.t > # > $! EDIT.COM - edit multiple files  > $!  > $       open /read in edit.dat > $loop: > $       read/end=exit in data ; > $       version = f$parse(data,,,"VERSION","SYNTAX_ONLY")f > $!      show sym version > $       data = data - versione( > $       def/user sys$input sys$command+ > $       edit/edt 'data' /command=edit.edtc > $       goto loopm > $exit: > $       close in   and here is mine:a   $ v=f$ver(0) $!+m $! ED2_UTIL.COMc $!D $! This procedure may replace your favourite call to the EDT editor.' $! It provides the following additions:  $!F $! 1. files list editing session, with wildcards. example: $ ed2 *.com $! 2. ^Y interrupt handlingtI $! 3. journalling files management. If it finds a .JOU lurking around, itc+ $!    asks you what you want to do with it.eC $! 4. access conflict warning if another user is editing your file.t $!
 $! <input>, $! file name specification or wild card list $! $! <output>n $! modified file $! $! <side effects>-
 $! none knownu $! $! Revision history0 $!( $! Version Date        Author     actionP $! ------- ----------- ---------- ----------------------------------------------P $! V1.0-0         1984 DTL        posted in the DEC Software Tools Clearinghouse+ $! V2.0-0  21-feb-2001 D. Morandi rewritten3L $! V2.0-1  21-apr-2001 DMo        fix bug causing procedure to exit when theL $!                                SET PROCESS/NAME fails (if duplicate name) $!I $! This procedure is a NothingWare production from www.didiermorandi.com. 9 $! It may be freely distributed without any restrictions.  $!-v $ on warning then goto EXITh $ esc[0,8] = 27a $ set control=(T,Y)r< $ if p1 .eqs. "" then inq p1 "_File(s) (wild cards allowed)" $ if p1 .eqs. "" then goto EXITb $ file = p1i $ say = "write sys$output"$ $ if f$locate(".",p1) .eq. f$len(p1) $ then $    say "Invalid syntax: ",p1 $    goto EXIT $ endifg $ name = f$element(0,".",p1)0 $ if f$locate("*",name) .eq. f$len(name) .and. -A       f$locate("%",name) .eq. f$len(name)  then goto NO_WILDCARDSc, $ files_list = "sys$scratch:files_list.temp"P $ dire_/col=1/notrail/nohead/out='files_list' 'p1'.     !the "." is mandatory!!! $ close/nolog ch $ open/read   ch 'files_list'  $LOOP: $ read/end=EOF ch file $ gosub DO_EDITe $ goto LOOPf $! $EOF:m $ close/nolog chA $ if f$search("''files_list'") .nes. "" then dele_ 'files_list';*g $EXIT: $ v=f$ver(v) $ exit $! $NO_WILDCARDS: $ gosub DO_EDITa
 $ goto EOF $!	 $DO_EDIT:a
 $ set noon+ $ journal = f$parse(file,,,"name") + ".jou"h $ if f$search(journal) .nes. ""o $ then $    recover = ""n$ $    jnl_dat = f$file(journal,"CDT")# $    fil_dat = "[file not created]"mA $    if f$search(file) .nes. "" then fil_dat = f$file(file,"CDT")  $    say ""gN $    say "^G^G^G        WARNING A journal file for your EDT session was found" $    say ""n- $    say "      The file you edit is : ",filel0 $    say "      JOU creation date is : ",jnl_dat $    if f$search(file) .eqs. ""r	 $    then  $       say ""L $       say "   Your file was NOT created during your last editing session!"L $       say "   RECOVER is strongly recommended or you will loose your data" $       say "" $       def_choice = "[YES/no]"-	 $    elseq0 $       say "   Your file was created: ",fil_dat $       def_choice = "[yes/NO]".
 $    endif1 $    say "      The current date/time: ",f$time()s $    say ""p $    inq choice -nB    "Do you want to recover this journalling session ''def_choice'"M $    if choice .eqs. "" .and. def_choice .eqs. "[YES/no]" then choice = "YES" L $    if choice .eqs. "" .and. def_choice .eqs. "[yes/NO]" then choice = "NO". $    if f$extract(0,1,choice) .eqs. "Y" .or. -@          f$extract(0,1,choice) .eqs. "y" then recover="/recover". $    if f$extract(0,1,choice) .eqs. "N" .or. -(          f$extract(0,1,choice) .eqs. "n"	 $    theny& $       if def_choice .eqs. "[YES/no]" $       then $          recover = "/recover"t $          say ""tI $          say "You have decided NOT to recover this journalling session"0O $  say "If you answer NO to the following question, no recover will take place"sC $          inq ok "You do not want to recover? [YES/NO/no default]"  $          say ""pJ $          if f$extract(0,1,ok) .eqs. "N" .or. f$extract(0,1,ok) .eqs. "n" $          thent $             recover = "" $          endif
 $       endifw
 $    endif $    if recover .eqs. ""	 $    thenr $       save = "N"7 $       inq save "Do you wish to save the file [YES/No]l, $    if f$extract(0,1,save) .eqs. "Y" .or. -6          f$extract(0,1,save) .eqs. "y" then save = "Y"0 $    if save .eqs. "N" then dele_/log 'journal'.
 $    endif $ endife $ on warning then goto EXITI
 $ cde = ""5 $ if f$search("sys$login:edtini.edt") .nes. "" then -o+       cde = "/command=sys$login:edtini.edt"r! $ prc_name = f$getjpi(0,"prcnam") 
 $ set noonO $ set proc/name="''f$extract(0,15,f$parse(file,,,""name""))'"           !for ^To $ on warning then goto EXITs" $ on control_Y then gosub ASK_USER# $ assign/user sys$command sys$inputd  $ edit_/edt'recover''cde' 'file'
 $ set noon $ set proc/name="''prc_name'"c $ on warning then goto EXITl $ set control=Yn $ return $!
 $ASK_USER: $ ty/pa nl:e $HUH:t $ say esc,"[m"A $ inq action "Do you want to Spawn DCL, Continue or Exit [S/C/E]"2" $ action = f$edit(action,"upcase")) $ if action .eqs. "S" then goto SPAWN_DCLu $ if action .eqs. "C"t $ then $    say ""K
 $    say -O       "Going back to the ",esc,"[1mnext file ",esc,"[mof your editing session."e $    say "" + $    inq dummy "Press <RETURN> to continue"7 $    return6 $ endifcN $ if action .eqs. "E" then goto EXIT                    !journal file is saved
 $ goto HUH $! $SPAWN_DCL:  $ say "" $ say "Spawning DCL."e= $ say "Type LOGOUT to go back to the ",esc,"[1mnext file ", - (         esc,"[mof your editing session." $ say ""( $ inq dummy "Press <RETURN> to continue"# $ assign/user sys$command sys$inputn $ spawne $ return  L Main useful usage is .JOU processing, DCL spawn ability and list processing. Example:   DTL02> ed2 == "@dcl$:ED_UTIL"o DTL02> ed2 *.com  >          WARNING A journal file for your EDT session was found  ;          The file you edit is : DKA100:[MORANDI.DCL]A.COM;1V7          JOU creation date is : 25-NOV-2003 09:43:28.05b7          Your file was created:  2-JAN-2003 17:21:23.47 7          The current date/time: 25-NOV-2003 09:56:00.05>  ; Do you want to recover this journalling session [yes/NO]: nf& Do you wish to save the file [YES/No]: etc.   Enjoy. D.  M PS: we do DCL programming and procedures documentation on demand. Please ask.n   ------------------------------  % Date: Tue, 25 Nov 2003 09:45:40 +0000a* From: Nic Clews <sendspamhere@[127.0.0.1]>; Subject: Re: VMS could save the world ! (asteroid research)a' Message-ID: <bpv8ao$pjl$1@lore.csc.com>t   JF Mezei wrote:m > U > another side note: other obvious computers seen during those documentary were Macs.  > / > proof that smart people don't use windows :-)i  F Well, JF, I would have thought that would have been obvious, I mean ifE you're tracking big lumps of rock flying all over the place, the last = thing you need to be looking at those is through is a window!h  @ For things astronomic, this is a good site, and lists Near Earth Objects:   http://spaceweather.com/ i   -- o? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciencesr nclews at csc dot com    ------------------------------    Date: 25 Nov 2003 06:39:10 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)s; Subject: Re: VMS could save the world ! (asteroid research)o3 Message-ID: <zBmJjP98s2LC@eisner.encompasserve.org>t  V In article <3FC2D82A.95758ADA@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes:  M > What is good is that the MPC's website has no problems mentioning that theyp& > run a large cluster of VMS machines.  A The fellow in charge of that cluster participates in comp.os.vms.X  A Although as I understand it, the worldwide scientific effort justhB deals with _tracking_ those heavenly bodies.  Bruce Willis is only a movie actor :-)u   ------------------------------    Date: 25 Nov 2003 07:49:48 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)l; Subject: Re: VMS could save the world ! (asteroid research)/3 Message-ID: <QBZC$uMBe6xg@eisner.encompasserve.org>r  V In article <3FC2D82A.95758ADA@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes:  J > (one a more scary note, PBS last week had a documentary warning that theP > earth's magnetic field was weakening, which was not only very dangerous for usM > (protects from radiation), but also a sign that the poles may change withiniN > 1000 years (north pole woudl become south pole from magnetic point of view).  B    According to the documentary it's not all that dangerous to ourF    health.  Although the magnetic field is a shield from some forms ofD    radiation the cancer rate increase due to increased radiation was    predicted to be small.u   ------------------------------  % Date: Tue, 25 Nov 2003 10:53:04 +0000:O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>sF Subject: Re: [OT] - pot calls kettle black (Was: Re: IA64 TPC results)0 Message-ID: <bpvcag$n48$1@new-usenet.uk.sun.com>   Bradford J. Hamilton wrote:  > In article <bpstgc$r5v$1@new-usenet.uk.sun.com>, Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes:	 > !snip!	r > !.6 > !Rob as you know perfectly well I started posting to6 > !this group because of your attempts to FUD Sun over > !eBays reliability issues. > !e > N > I was getting curious about this statement, so I checked Google Groups.  TheP > first comp.os.vms posting by Andrew (actually a cross-post from c.o.d.) was onQ > October 29th, 1997.  The subject was, "Alpha is dead!", and Andrew's reply intoSO > the "thread" had to do with speculation on IA64 and HP PA-RISC.  History willmL > judge if Andrew's "analysis" was cogent, but at the time, it smacked of... >  > FUD.  ' Sorry but what total and utter rubbish.d  7 This is what I posted (crossposed as you do point out).i  H "Its more the lateness of Merced than the unwillingness of HP-PA to die C that has forced HP to add extensions to the HP-PA roadmap, that andsD analysts pointing out that a straight cut over was not going to be a+ great idea for most HP-PA/HP-UX customers."      FirstlyD? There is no Alpha FUD in this whatsoever remember in 1997 Alpha-@ was still very much a current processor with a 25 year projected life.n   Secondly6 The posting was entirely accurate, it was what Gartner6 and various other analysts at the time were saying and5 the cuttover issue was one reason why HP extended the" PA roadmap.t  2 The only thing that you can really accuse me of is posting an uncomfortable truth.0  9 Now if thats FUD in your book then how unfortunate ......h for you.   Regardso Andrew Harrisono7 > !This is a matter of record and I doubt that even youl > !would try to dispute this.b > !snip!
 > !Regards > !Andrew Harrison > !d > L > __________________________________________________________________________C > Bradford J. Hamilton                    "All opinions are my own"vM > bMradAhamiPltSon-at-coMmcAast.nPeSt     "Lose the MAPS, and replace '-at-'  2 >                                          with @"   ------------------------------  % Date: Tue, 25 Nov 2003 15:14:51 +0100c" From: Didier Morandi <no@spam.com> Subject: [OT] For David CATHEY3 Message-ID: <3fc36402$0$2390$626a54ce@news.free.fr>i   David, How can I write to Montagar? Thanks.E  5 > This is the SMTP Server program at host wanadoo.fr.s > ; > I'm sorry to have to inform you that the message returnedt; > below could not be delivered to one or more destinations.  > : > For further assistance, please send mail to <postmaster> > ; > If you do so, please include this problem report. You can,7 > delete your own text from the message returned below.  >  > 			The SMTP Server program > M > <webmaster@montagar.com>: host pelican.montagar.com[209.39.152.5] said: 554 0 >     Message rejected as spam. Have a nice day.      " -------- Original Message -------- Subject: Your Hobbyist Licensesn% Date: Fri, 17 Oct 2003 08:26:10 -0500v From: hobbyist@montagar.como To: didier.morandi@free.fr ../..g   ------------------------------  % Date: Tue, 25 Nov 2003 08:03:23 -0700e+ From: "Barry Treahy, Jr." <Treahy@MMaz.com>u" Subject: Re: [OT] For David CATHEY' Message-ID: <3FC36F3B.4010502@MMaz.com>f   Didier Morandi wrote:l   > David, > How can I write to Montagar?	 > Thanks.s >sE Perhaps sign up for a temporary Hotmail or Yahoo account, but we too iD block a lot of Wanadoo because they simply will not respond to SPAM H complaints...  If your ISP has been RBL'd, you should pound on your ISP 2 for being a poor net-citizen, or find another ISP.   Barry    --    > Barry Treahy, Jr                       E-mail: Treahy@MMaz.com> Midwest Microwave                          Phone: 480/314-1320> Vice President & CIO                         FAX: 480/661-7028                        e   ------------------------------  % Date: Tue, 25 Nov 2003 11:36:02 +0100t" From: Didier Morandi <no@spam.com>B Subject: [SURVEY] Do you use VAX/VMS SW not ported to OpenVMS i64?3 Message-ID: <3fc330b9$0$2363$626a54ce@news.free.fr>i  P Well, I'm closing the next issue of the VAX/VMS to Itanium Migration Newsletter  and I'm missing some more data.r  M If you are concerned, could you please answer these three new questions? (in -A here or via mail to: firstnamelastname a t n e r i m d o t n e t)w  L Q1. Do you use VAX/VMS SW not ported to OpenVMS i64 because of an HP choice? [Y/N]t (please list products)  F Q2. If you do, would it be interesting for you to make pressure on HP? [Y/N]  (please comment)  M Q3. If it is a Publisher choice, would you support pressure on the Publisher?< [Y/N]N (please comment)  5 Thanks for helping the Community of the OpenVMS Ring.r   D. -- nN     Read the latest VAX/VMS to Itanium Migration News  | mirrors   | downloadsJ   www.openvms.org/dmorandi/vaxvms2itanium_200311en.pdf   en USA        n/aI www.didiermorandi.com/vms/vaxvms2itanium_200311en.pdf   en Europe    2660aI www.didiermorandi.com/vms/vaxvms2itanium_200311fr.pdf   fr Europe     532eI www.didiermorandi.com/vms/vaxvms2itanium_200310en.pdf   en Europe     377tI www.didiermorandi.com/vms/vaxvms2itanium_200310fr.pdf   fr Europe     145o  ;                   Discover the FutureVAX: www.futurevax.com>;                   (number of visits, en : 2483 - fr : 2347)I  I    didier morandi  ~ sarl au capital de 8 000 euros ~  Revendeur agr HPfE        Expertise en environnement DIGITAL ~ Formation ~ Programmation I    Offshore ~ 5 av. A. Durand 31700 Blagnac France. Tl: 33(0)5 6131 6287.F      SIRET 448 694 851 00016 RCS Toulouse http://www.didiermorandi.com   ------------------------------  % Date: Tue, 25 Nov 2003 06:16:26 -0500m* From: JF Mezei <jfmezei.spamnot@istop.com>F Subject: Re: [SURVEY] Do you use VAX/VMS SW not ported to OpenVMS i64?) Message-ID: <3FC339D0.2483D25B@istop.com>r   Didier Morandi wrote:lN > Q1. Do you use VAX/VMS SW not ported to OpenVMS i64 because of an HP choice? > [Y/N]  > (please list products)   ALL-IN-1 Message Router1 DECPrint Utility for Postcript to Sixel printing.g  H > Q2. If you do, would it be interesting for you to make pressure on HP?  M Lost cause. Microsoft is too powerful to overturn those decisions. And in the>I case of Message Router, it is sort of superceded by the less capable SMTPpN product, so it would be preferable to see big improvements in the SMTP productL shipped with TCPIP Services which would allow direct hookup to applications. (mail enabled apps).    K (as far as the decprint utility, I use it to print postcript to an LA75 forrF labels etc.) Of the above products, only ALL-In-1 was ported to Alpha.   ------------------------------   End of INFO-VAX 2003.654 ************************r.  But why shouldA > 	power consumption be a metric for something other than densityr > 	oriented boxes? >   ? You are as always promoting a product that you cannot currentlyt: buy Deerfield and one that has very uncertain performance.  A Who knows what reducing the clock speed and the onchip cache size = will have on perCU_7>v93jj-NmaB5Q4\{CT{Q)p9[-wI 7U{{?naRpG_yRtq$n.uȱ~[M/h=(	s0EIA|r,fpC'*fU}3<*vfm
T  BWSG
jpٍ"V˙UPhWjdZ#oiTQd;
gg_)4'ǖ=}ڶQ.}?S-%$6#[<5t\몫.G~X|2fdd8(
DYdX,~	 Ũcx{!,<-~G/z1j
;1ɗUMS%ǥ,c(=1A''H.oLWjs(ڌD>ıqmmmk?rb}RCX4bV4a>0d-7ṀݮS",bݟL#\LWی):T0y}1J_Zei)
>}WP<)NZqs	j-|{1uyDoKF9x47F3`+}o#O]=J}O|5<2$g2u~ѐRnN܆2@pl:ޜMGUrJWܣqU'$a#
oDJ'
rVW[?H~5k"A
ډgk!3ܕ.~
.Z)(5{eu].ۇF%w+όЌs$BOv0[\]2:^!E[)ɱgMbYoQ$<m~ѳ)z	}ԡ)"~7*|GN̼t`Һrwd5@8OP3[ \$fs
%1r xŠm٩==O59V)g#G軍^<	({tqJcʚczUݥܪ5|ݧJ:^/_ ^SF1uz0ZGИfx	9J@y8qH4|=\-x&4W>%9ݩO!GZ?,VP8C`-}lrz5}fdiAlAwJz(ѷϭ"E۶+	
ئ9hx>(r?yoqUW_E=(Y^yXR<ћ:P<dt|b!qۦ-*\H۽|qA=pιjؽ'&:)0
<īE{Xt}xZL~f5lu_^8超mƒsKJn3f쪩'
a7i