1 INFO-VAX	Tue, 25 Nov 2003	Volume 2003 : Issue 653       Contents:+ Also FOR SALE: digital BC29G-09 video cable  Re: Backwards File Dump  RE: Backwards File Dump  Re: Backwards File Dump  RE: Backwards File Dump  Re: bin Laden  strikes again!  Re: BUG IN AUTOGEN.COM!!!!!!8 Re: DCL Enhancements: Error messages for OPEN and DEFINE< Dell drops call centers in India - HP thinks it is a winner!" FOR SALE: digital VRM17-HA monitor) Re: Hobbyist license and layered products / Re: Hobbyist license and layered products - SLS 0 ircII EPIC for OpenVMS Alpha 1.0.1 PR #5 release2 odd SMTP e-mail when sending to page.metrocall.com6 Re: odd SMTP e-mail when sending to page.metrocall.com Re: ODS2 file header Re: ODS2 file header@ Remote rename causes error? RMS-E-CRE, ACP -SYSTEM-F-UNREACHABLE" Required reading for HP executives& Re: Required reading for HP executives 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 . VMS could save the world ! (asteroid research)2 Re: VMS could save the world ! (asteroid research)9 [OT] - pot calls kettle black (Was: Re: IA64 TPC results)   F ----------------------------------------------------------------------  % Date: Tue, 25 Nov 2003 00:16:59 -0500 % From: VMS User <vmsuser@internet.com> 4 Subject: Also FOR SALE: digital BC29G-09 video cable8 Message-ID: <5dp5svoc4pufq38si0urmb1j71ldf982dl@4ax.com>  > FOR SALE: digital BC29G-09 video cable - very good condition -D Philadelphia area - make offer - reply to ... the7car(at)comcast.net   ------------------------------  % Date: Mon, 24 Nov 2003 16:29:48 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>  Subject: Re: Backwards File Dump) Message-ID: <3FC27847.375F8696@istop.com>    briggs@encompasserve.org wrote: J >     Registers do not generally even have an endian-ness.  In the absenceF > of instructions to access individual bits or individual bytes withinG > a register, there is no sense in which bits going to or coming from a ( > register can be said to be "reversed".  L But consider compiler functionality such as shifting bits left or right. TheK general assumption in higher level languages is that the value is stored in ( big-endian. (shift left multiplies by 2)  J Consider a longword (4 bytes) located at address 10. From the programmer'sI point of view in a language higher up the food chain than assembler, this J number is seen as 4 bytes of 8 bits, with the byte at address 10 being theO most significant, and the leftmost bit of that byte being the most significant.   F The compiler shields the programmer from most of those intricacies andJ presents to the programmer a big endian view of memory, no matter what theG underlying machine is. And unless you are exchanging binary data with a I "foreign" machine, the compiler succeeds 100% in sheltering you from this  machine's endianness.   H However my feeling is that once you go into DUMP (or a memory dump), theN 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)   J 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]  N Whether in VAX or standard formats, you will really need to count your offsetsM and then extract the 2 or 4 bytes you need, especially from a data file where # longword alignment isn't garanteed. M So what this means is that the VAX format doesn't really help for binary, but % makes it harder for textual contents.    ------------------------------  % Date: Mon, 24 Nov 2003 17:18:24 -0800 # From: "Tom Linden" <tom@kednos.com>   Subject: RE: Backwards File Dump9 Message-ID: <CIEJLCMNHNNDLLOOGNJIGEIEIIAA.tom@kednos.com>   ? The fact of the matter is that if I overlay a 16 bit integer on ? the the bit string '0000000000000010'B  on a Big endian machine ? it displays as 2.  If I do it on a little endian it displays as  2**14   A It is customary to associate left with most significant and right @ with least.  Little is contrary to this association and therfore# appears unnatural, in this context.   A 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    J which as you can see retains the big endian ordering, in the sense of left% to right, but with the bytes reversed      >-----Original Message----- A >From: briggs@encompasserve.org [mailto:briggs@encompasserve.org] ( >Sent: Monday, November 24, 2003 6:58 AM >To: Info-VAX@Mvb.Saic.Com! >Subject: RE: Backwards File Dump  >  > ? >In article <CIEJLCMNHNNDLLOOGNJIEEENIIAA.tom@kednos.com>, "Tom ! >Linden" <tom@kednos.com> writes: A >> I think you miss the point.  When, for example a an integer is  >loaded intoA >> a register its most significant value is in position 15, 31 0r 
 >63 depending > >> in the size but when it is in memory it is backward.  In my >previous posting L >> I gave an example, to illustrate that bit strings can ONLY be stored in a >> big= >> endian manner and if you hope to have those represent, for  >example, integersB >> then on a little endian machine you will need to swap the order
 >of the bits.  >  >Bob Koehler had it right. > I >    Registers do not generally even have an endian-ness.  In the absence E >of instructions to access individual bits or individual bytes within F >a register, there is no sense in which bits going to or coming from a' >register can be said to be "reversed".  > E >    Hint:  In the absence of such instructions, bit numbering within B >registers is a feature of the documentation, not of the hardware.D >It is tough to sustain a claim that documentation can reverse bits. > C >    Hint:  In the presence of such instructions, as Bob indicated, B >most architectures treat in-register values very much the same as< >in-memory values and no reversal can be said to take place. > D >    For most architectures and most storage choices, bit strings doD >not have a byte-level endian-ness.  You'll generally find the firstD >bits in the string at the first machine word in memory order.  That$ >has nothing to do with endian-ness. > F >    For most architectures and most storage choices, bit strings haveB >a very obvious bit endian-ness.  For little-endian architectures,E >the first bit will tend to be the low order bit in the first machine C >word.  For big-endian architectures, the first bit will tend to be F >the high order bit in the first machine word.  This choice means thatD >the choice of word size within an architecture is irrelevant to theK >memory order of bit strings.  8 bytes, 4 words, 2 longwords or 1 quadword. E >You still get the same bits in the same place in memory.  (Hence the 	 >choice).  > H >    This does mean that if you have a bit string externally representedE >as '01000000...000' (64 bits) with an intended reading order of left @ >to right and if you place this bit string in memory on a 64 bitA >little-endian machine and if you then interpret that memory cell ; >as a 64 bit integer, you will get a value that displays as ! >'0000...10' (64 bits) in base 2.  > G >    The bit reversal, if there is one, is in the display routines, not  >in the memory architecture. > 
 >	John Briggs  >  >---' >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: Mon, 24 Nov 2003 20:46:05 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>  Subject: Re: Backwards File Dump) Message-ID: <3FC2B447.CD74EA0E@istop.com>    Tom Linden wrote: C > 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 ;   J The first one will be stored in the same order as you typed it in. For theR second one, the compiler  will reverse the constant and store it as little endian.    G if you then  use memcpy (&myint, &mystring, 4), then myint will contain L "deadbeef" in the big endian order because the code in memcpy copies byte by& byte without any endianness knowledge.   ------------------------------  % Date: Mon, 24 Nov 2003 18:17:59 -0800 # From: "Tom Linden" <tom@kednos.com>   Subject: RE: Backwards File Dump9 Message-ID: <CIEJLCMNHNNDLLOOGNJIMEIFIIAA.tom@kednos.com>   , C doesn't have strings that is a char array.     >-----Original Message----- 2 >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 Dump  >  >  >Tom Linden wrote:D >> 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 ; > K >The first one will be stored in the same order as you typed it in. For the B >second one, the compiler  will reverse the constant and store it  >as little endian. >  > H >if you then  use memcpy (&myint, &mystring, 4), then myint will contain? >"deadbeef" in the big endian order because the code in memcpy   >copies byte by ' >byte without any endianness knowledge.  >  >---' >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: Mon, 24 Nov 2003 18:53:45 -0500 * From: "Bill Todd" <billtodd@metrocast.net>& Subject: Re: bin Laden  strikes again!2 Message-ID: <Ne-dnbgKE4-UB1-i4p2dnA@metrocast.net>  = "Gary L. Dare" <gld_nospam@nospam.ripco.com> wrote in message ) news:3FC18F7F.5020902@nospam.ripco.com...    ...   K > Actually, the difference is that the Allies never left the War on Terror, 0 > it's just that Iraq is not seen as part of it.  K That's certainly a large part of the problem that Bush has created, but far D from all of it.  His attitude toward waging war in Iraq mirrored hisH attitudes about things like the Kyoto treaty:  we'll go our way, and the) rest of the world can like it or lump it.    - bill   ------------------------------  % Date: Mon, 24 Nov 2003 16:23:55 -0500 & From: David M Smith <dsmit115@csc.com>% Subject: Re: BUG IN AUTOGEN.COM!!!!!! 8 Message-ID: <0gt4svc3kdh1aqt9d6b6c9o45mmdeamin9@4ax.com>  I On Sun, 23 Nov 2003 00:59:48 +0000 (UTC), helbig@astro.multiCLOTHESvax.de 1 (Phillip Helbig---remove CLOTHES to reply) wrote:   H >I think I have found the problem.  Fortunately, it was obvious that it H >was coming from SYSMAN and SYSMAN is not used that much within AUTOGEN. >AUTOGEN.COM contains: >  >   $SYSMAN = "$SYSMAN"  >   $DEFINE/USER sysmanini nl: >   $SYSMAN IO autoconfigure > I >Now, it's rather obvious what this is supposed to do.  In particular, it H >is trying to ignore SYSMANI.  One new thing I DID introduce recently isA >SYS$LOGIN:SYSMANINI.INI in the account from which I was invoking I >AUTOGEN.  I DO NOT HAVE A SYSMANINI LOGICAL DEFINED.  In this case, the  @ >documented behaviour is to look for SYSMANINI.INI in SYS$LOGIN.  I >However, I think it is rather obvious that this is a bug in AUTOGEN.COM. G >I like having the file named SYSMANINI.INI; it would be bad to change  G >that.  It would be bad to change the documented behaviour of SYSMAN.   H >Obviously, AUTOGEN wants to ignore this file and doesn't put in enough A >effort.  Perhaps DEFINE/USER_MODE SYS$LOGIN NL: would be enough.   O AUTOGEN.COM in OpenVMS Alpha V7.3-1 has the following code in the corresponding  section:   $SYSMAN = "$SYSMAN"  $DEFINE/USER sysmanini nl: $DEFINE/USER sys$error nl: $DEFINE/USER sys$output nl:  $SYSMAN IO autoconfigure  N The DEFINE/USER SYSMANINI NL: should be sufficient (it seems to me) to preventM your file from being executed -- the logical name SYSMANINI should "override" < the existence of your file. I'm not sure what I'm missing...I ------------------------------------------------------------------------- I David M. Smith 302.391.8533                       dsmit115 at csc dot com I Computer Sciences Corporation     (Opinions are those of the writer only) I -------------------------------------------------------------------------    ------------------------------    Date: 24 Nov 2003 12:27:38 -0800. From: spamsink2001@yahoo.com (Alan E. Feldman)A Subject: Re: DCL Enhancements: Error messages for OPEN and DEFINE = Message-ID: <b096a4ee.0311241227.101db6dc@posting.google.com>   b Paul Sture <nospam@sture.homeip.net> wrote in message news:<3FC084AB.6674C637@sture.homeip.net>... > Alan E. Feldman wrote: > > f > > Paul Sture <nospam@sture.homeip.net> wrote in message news:<3FBDC130.3A2617AE@sture.homeip.net>... > > > jlsue wrote: > > > > P > > > > On Wed, 19 Nov 2003 19:24:24 +0100, Paul Sture <nospam@sture.homeip.net> > > > > wrote: > > > > 	 > > > > > ? > > > > >It _has_ to be compatible with current behaviour IMHO. 	 > > > > > & > > > > >Let's look at HELP OPEN/ERROR	 > > > > > , > > > > >     If the /ERROR qualifier is notB > > > > >     specified, the current ON condition action is taken.	 > > > > > Q > > > > >Oh dear, currently working procedures could suddenly do a silent jump in O > > > > >the code if the default were changed. There's simply too much code out  > > > > >there...  > > > > Q > > > > But how is that different than the change that required a "$" on each DCL  > > > > command line?  > > >  > > > IIRC that was not silent.  > > ? > > Is this in reference to the change made, c. 1985-1989, that J > > continuation lines had to NOT start with a dollar sign? Or a post v6.2 > > change?  > I > Memory fails as to which version precisely, but I think you've probably  > got the timescale right. > H > I _can_ remember however that in the timeframe I was using 6.1 or 6.2,F > we had an ex-Unix newbie who wrote a bit of code without the leadingI > dollar sign (which surprisingly worked). We told him to change it as it  > was officially unsupported.  > I > He refused. When we told him it might break in a future version of VMS, , > he said "Well, we'll fix it if it breaks". > I > He got overruled on that one, but it serves to illustrate that there is ) > probably a lot of dodgy code out there.    OK.    I > A real life example from about 5 years ago. A largely Unix shop sold us J > some multi-platform software which sounded great in presentations and on$ > paper. It had something like this: >   > $ open /write  logfile out.log > $ logname = f$trnlnm(logfile)  > $ close logfile   > $ open/write logfile 'logname' > J > Needless to say, it fell over and had obviously never been tested. But IG > still do not understand to this day why on earth the author wanted to $ > close the file in the first place.  B OK, another example of "dodgy code", but "fixing" OPEN won't break this as it is already broken.   1 I, too, cannot see any reason to close the file.      [...] I > > I understand your point. And the last thing I want is to scare people J > > off of VMS (as Larry Kilgallen warned in another post in this thread).G > > However, this would only affect places doing upgrades to what would G > > soon be the latest version. It would only immediately affect places F > > doing upgrades to that soon-to-be latest version. Such places mostE > > likely routinely upgrade and if they can do the upgrades they can G > > probably deal with the new OPEN behavior. And the new OPEN behavior D > > would only affect command procedures that actually used the OPENF > > command "incorrectly". I don't think there'd be that many of them.I > > You'd have to code a self-correcting OPEN statement bug for your code G > > to work anyway. I mean if you OPEN a file, but you already OPENed a G > > different file with the same logical name, then I think it would be J > > rather unlikely that your code would work because the file you thoughtG > > you OPENed is not the one that is actually opened. How could such a J > > code work correctly? In which case just how much code could break with, > > this change in OPEN? I'd guess not much. > >  > F > I'm pretty sure I always treated this one with caution, but I'm also > prettyG > sure that I saw some code from DEC which used this (might have been a H > layered product rather than VMS itself), which I took as a green light > that it was normal behaviour.  >  > IIRC it was something like:  >   > $ if error then call log_error >  > ...  >  > $log_error: subroutine$ > $ open/write logfile 'logfilename' > ...  > 
 > $ return > D > Lazy coding I'll grant you, but under the present regime it works.; > If the subroutine is never called, no logfile is created.   D Well, one could skip making OPEN make an error in the case where theA same logical name is used with the same file-spec. But is there a E close statement upon final exit? If not, then this routine is leaving A a file open in which case it should be fixed anyway. The case I'm F concerned about is when you use the OPEN statement to open a differentA file from the one that is already open via the same logical name. D Actually, come to think of it, any change with the same logical nameD would need to be flagged, like changing what qualifiers and keywordsC are used. But here it is the same exact statement being repeated in D which case I don't ask for any error message, maybe an informationalA one, but the wording of the text would have to be done carefully.   F > > So I don't think it would cause too much pain and it would make itE > > easier for beginning DCL coders and it would correctly display an H > > error message when needed. And it would make it easier for all of usJ > > to catch such OPEN errors. And good error messages are one of the many > > great things about VMS.  > >  > : > Granted, but I have a gut feeling it _would_ cause pain.   OK.   G > At this point I really have to ask why CLOSE/NOLOG (as recommended by B > Hoff and others) doesn't throw an error if the file is not open. > ! > Let's be consistent please. :-)  >  >   G > > > I've known about it for at least 20 years, and even used it to my 9 > > > advantage on occasions (usually for DCL debugging).  > >  > > Can you tell us how? > 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.  > # > $! EDIT.COM - edit multiple files  > $!  > $       open /read in edit.dat > $loop: > $       read/end=exit in data ; > $       version = f$parse(data,,,"VERSION","SYNTAX_ONLY")  > $!      show sym version > $       data = data - version ( > $       def/user sys$input sys$command+ > $       edit/edt 'data' /command=edit.edt  > $       goto loop  > $exit: > $       close in >  [...] J > While debugging or enhancing EDIT.INI (and it can get quite complex), atH > present I can ^Y out of EDIT.COM, change my EDIT.EDT, and then pick up3 > from where I left off, using the next input file.  > D > OK, nowadays I have a workstation where I could do that editing inI > another DECterm session, but when I was tied to a single VT, I found it  > a productive way of working.  ; But how would this example break? OPEN is only called once.   K > > > I'm arguing that it's too late now to change the _default_ behaviour.  > > > J > > > Far easier to document it as a "feature", and as suggested elsewhereM > > > have a logical or appropriate SET command to enable enhanced OPEN error   > > > checking (off by default). > > I > > Additionally you could add a step to the upgrade procedure that would I > > ask the upgrader about which OPEN he wants (correct, or incorrect :-) D > > and force him to answer the question or the upgrade fails. OK, IJ > > wouldn't phrase it that way. Maybe it should just say "new or old". OrG > > it could go into a nearly full screen explanation of the issue, and 1 > > after the answer is given ask "Are you sure?"  > >  > I > OK, but I'd answer OLD at any time I'm not imtimately familiar with the I > DCL lurking on the target machine. You might answer NEW, and that would E > be fine on your own system(s), but would you feel happy doing so on  > someone else's system?  0 It depends how familiar I was with said system.   D > > And there is, as always, the "Be careful what you wish for" bit. > >  > I > In that one short sentence you have summed up my argument better than I  > could have wished for :-)  > C > Sincere thanks for prompting me to explain my POV in more detail.   
 Your welcome.    Disclaimer: JMHO Alan E. Feldman    ------------------------------    Date: 24 Nov 2003 16:19:02 -0800( From: bob@instantwhip.com (Bob Ceculski)E Subject: Dell drops call centers in India - HP thinks it is a winner! = Message-ID: <d7791aa1.0311241619.7d48a999@posting.google.com>   F HP thinks it will be wonderful ... I guess some people never learn ...  ` http://seattlepi.nwsource.com/business/aptech_story.asp?category=1700&slug=Dell%20Call%20Centers   ------------------------------  % Date: Tue, 25 Nov 2003 00:00:40 -0500 % From: VMS User <vmsuser@internet.com> + Subject: FOR SALE: digital VRM17-HA monitor 8 Message-ID: <1eo5svk7gufqogadaeod6lu2tumbso14da@4ax.com>  B FOR SALE: digital VRM17-HA monitor - good condition - Philadelphia7 area - make offer - reply to ... the7car(at)comcast.net    ------------------------------  % Date: Mon, 24 Nov 2003 13:02:17 -0800 * From: "Alder" <MUNDDGNTDYTV@spammotel.com>2 Subject: Re: Hobbyist license and layered products+ Message-ID: <3fc271d9$1@obsidian.gov.bc.ca>   D Thanks, D., I'll try to contain my enthusiasm until the Q4(?) letter arrives.   Alder   / "Didier Morandi" <no@spam.com> wrote in message . news:3fc2113d$0$28627$636a55ce@news.free.fr... > Andreas Davour wrote:  > ? > > ue191@vtn1.victoria.tc.ca (T.L. (Terry) Branscombe) writes:  > >  > >  > >>sms, > >>L > >>Did you get any response from HP after registering on the page suggested > >>by Didier Morandi? > >>H > >>I tried filling out the two required fields, but have not heard back from > >>HP now in 4 days.  > >  > >  > > It's the same for me.  >  > Dear SPL E-mail subscriber,  > 5 > The new quarter's Software Products Library for the 5 > Operating System you registered for, OpenVMS Alpha, @ > is now available on the SPL web site:  http://www1.aclabs.com.C > See: "Downloads - Step by Step" for specifics on how to download.  > 7 > The login data from the last quarter's "Cover Letter" 9 > can be used for access. That login data will not expire 8 > until you receive this quarter's "Cover Letter", which/ > provides an overlap period into next quarter.  > 
 > Regards, > The SPL Team > J > ***** Kindly DO NOT REPLY to this email, unless to unsubscribe from this e-mail > list.  > G > If you have any questions relating to the SPL, refer to the SPL email  account: >          ODLCDROM@hp.com >            Thank you. *****  >    ------------------------------  # Date: Mon, 24 Nov 2003 19:22:34 GMT # From: hoff@hp.nospam (Hoff Hoffman) 8 Subject: Re: Hobbyist license and layered products - SLS2 Message-ID: <_Tswb.9601$nj5.1216@news.cpqcorp.net>  f In article <2a9d9498.0311241015.608f15cb@posting.google.com>, denny_rich@ameritech.net (Denny) writes:? :> Montagar CD? Specifically I'm interested in COBOL and Notes.   *   Notes is on Freeware V6.0, with license.  G :Is there an Alpha hobbyist license for SLS (Storage Library System)?   D :I've got the CD, but I didn't see a license in the email that came  :from Montagar.   H   SLS is an older product and (AFAIK) isn't a product offered to OpenVMSJ   hobbyists.  SLS is assumed of interest only to our commercial customers,*   in other words, and not to hobbyists.     H   FWIW, a basic remote BACKUP procedure is available in the OpenVMS FAQ.    N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------E         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com    ------------------------------  % Date: Tue, 25 Nov 2003 02:03:00 +0000 & From: Edward Brocklesby <ejb@goth.net>9 Subject: ircII EPIC for OpenVMS Alpha 1.0.1 PR #5 release 4 Message-ID: <pan.2003.11.25.02.03.00.28679@goth.net>  D ircII-EPIC is an IRC (Internet Relay Chat network -- think massivelyB multi-user PHONE) client for Unix systems, which also runs on VMS.  F I don't normally post these announcements here, but I'm sure there areJ more people who would be interesting in ircII than are currently using it,F and since PR5 is approaching a 'stable' release, I'd be interesting in some wider testing.   F The following announcement was posted to the EPIC mailing list earlier today:  * From:     Edward Brocklesby <ejb@goth.net> To:       vms-epic@epicsol.org Cc:       list@epicsol.orgJ Subject:  [EPIC]EPIC4 1.0.1 (VMS Edition) Preview Release #5 now available  
 Good evening,   F A new version of EPIC4 1.0.1 (VMS Edition) is now available.  DownloadH and installation instructions for this and previous releases, as well as$ other informations, may be found at:  &         <http://www.2mbit.com/~larne/>  F This release includes the following changes from the previous release, PR #4:  ?         - Possibly fix a panic when reading input under certain            conditions. #         - Add /set VMS_PATH_SYNTAX. 7         - Fix /HELP and add help files to distribution.          - No other changes.   F Any feedback on the installation or use of the client, particularly onB systems other than the testing system (VMS V7.3-1) is appreciated.  C Please direct followups to the author, or the VMS EPIC mailing list  <mailto:vms-epic@epicsol.org>.   Regards, Edward.    ------------------------------  % Date: Mon, 24 Nov 2003 18:01:43 -0600 ( From: brandon@dalsemi.com (John Brandon); Subject: odd SMTP e-mail when sending to page.metrocall.com 1 Message-ID: <03112418014310@dscis6-0.dalsemi.com>   K I am using SMTP e-mail to send pages to MetroCall alphanumeric pager users.   6 Using this script below from any of three VMS servers:   $ mail send$ smtp%"xxxxxxxxxx@page.metrocall.com" Test SubjectH Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit: Test Message $!  $ Server A works and page is received.< Server B works however page is not received by MetroCall ***< Server C works however page is not received by MetroCall ***  > *** Sending to other pager services (ATT, Verizon, ...) works!  8 All three servers use MS Exchange as the SMTP Mail Host., All three servers have the same SMTP config.( All three servers share the hosts. file.    , Has anyone see this type of behavior before?  + Any ideas of what is wrong?  Where to look?   ; Is it possible that MetroCall is blocking the page as SPAM?   K Is it possible that MS Exchange is doing goofy things to the e-mail (need I  ask..)       J*o*h*n B*r*a*n*d*o*n  VMS Systems Administrator * firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  # Date: Tue, 25 Nov 2003 01:45:51 GMT " From: bugs@pu.net (Mark Hittinger)? Subject: Re: odd SMTP e-mail when sending to page.metrocall.com . Message-ID: <jvywb.97556$Dw6.484398@attbi_s02>  * brandon@dalsemi.com (John Brandon) writes:- >Has anyone see this type of behavior before? , >Any ideas of what is wrong?  Where to look?  M I would try modifying my scripts to send the pager mails to one of my systems M instead of page.metrocall.com.  Then I would look at the three mail files and 9 compare them to see what was different between A and B/C.   ) Here are a couple of ideas to check on.     K Maybe the From address used in A will resolve but the From address used in  K B/C can't DNS resolve within metrocall.  Some mailers will drop mail where  ! the From address doesn't resolve.   ? Maybe the text sent by B/C is mime encoded and A is plain text.    Later    Mark Hittinger bugs@pu.net    ------------------------------  # Date: Mon, 24 Nov 2003 19:25:57 GMT # From: hoff@hp.nospam (Hoff Hoffman)  Subject: Re: ODS2 file header 2 Message-ID: <9Xswb.9602$nj5.4814@news.cpqcorp.net>  f In article <2a9d9498.0311241057.2b259718@posting.google.com>, denny_rich@ameritech.net (Denny) writes:o :denny.rich@swagelok.com (Denny Rich) wrote in message news:<d28306e.0311191237.4bd4791e@posting.google.com>...  .. :What am I doing?    : @ :In 1986, i got a copy of Mark Oakley's (Battelle Inst.) Macro32C :program that surveys a disk for files larger than 'n', or owned by G :'[uic]'.  I have used this to provide a "hog list" function everywhere F :I've worked since 1986. Neat program.  He scans the index file bitmapA :for set bits, then retrieves the indicated header block. He then = :traverses the back-links to come up with the directory spec.   C   Um, are you familiar with the DCL commands such as the following?        dir/sele=size=min=100      dir/by_owner=uic  D   For other related processing, please also see DFU on the Freeware.    N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------E         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com    ------------------------------    Date: 24 Nov 2003 19:54:19 -0800* From: denny.rich@swagelok.com (Denny Rich) Subject: Re: ODS2 file header < Message-ID: <d28306e.0311241954.7a2f38b2@posting.google.com>  ] hoff@hp.nospam (Hoff Hoffman) wrote in message news:<9Xswb.9602$nj5.4814@news.cpqcorp.net>... h > In article <2a9d9498.0311241057.2b259718@posting.google.com>, denny_rich@ameritech.net (Denny) writes:q > :denny.rich@swagelok.com (Denny Rich) wrote in message news:<d28306e.0311191237.4bd4791e@posting.google.com>...  >  ..  > :What am I doing?    > : B > :In 1986, i got a copy of Mark Oakley's (Battelle Inst.) Macro32E > :program that surveys a disk for files larger than 'n', or owned by I > :'[uic]'.  I have used this to provide a "hog list" function everywhere H > :I've worked since 1986. Neat program.  He scans the index file bitmapC > :for set bits, then retrieves the indicated header block. He then ? > :traverses the back-links to come up with the directory spec.  > E >   Um, are you familiar with the DCL commands such as the following?  >  >     dir/sele=size=min=100  >     dir/by_owner=uic > F >   For other related processing, please also see DFU on the Freeware. >  > P >  ---------------------------- #include <rtfaq.h> -----------------------------M >     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq P >  --------------------------- pure personal opinion ---------------------------G >         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com   C Sure, I know about those commands. But where's the fun in that?  :) @ This was a great program in 1986 in Macro32. I've really enjoyedB resurrecting it in C, in 2003. And doing it on my Sandpiper on theD dining room table was the most fun of all.  ( hey....its what I do!)   happy thanksgiving.    ------------------------------  % Date: Mon, 24 Nov 2003 16:32:04 -0500 # From: "Hal Kuff" <kuff@comcast.net> I Subject: Remote rename causes error? RMS-E-CRE, ACP -SYSTEM-F-UNREACHABLE - Message-ID: <bpttb7$hm7@library1.airnews.net>   J When we do a remote rename we sometimes get this message... I've seen someI traffic on remote deletes via wildcards... but this is a rename that does " not make liberal use of wildcards.  H No other errors on these two nodes, no telnet, set host, or LAT sessionsJ dropping... We are running 7.3-1 with all patches in as of last weekend...   ------------------------------  # Date: Mon, 24 Nov 2003 20:54:30 GMT # From: "John Smith" <a@nonymous.com>S+ Subject: Required reading for HP executivesaI Message-ID: <aeuwb.21246$X2W1.15540@news04.bloor.is.net.cable.rogers.com>k  K If HP corporate execs and OpenVMS executives can't figure out how to market J VMS and VMS clusters from this .......then bring back the good old days of Stalinist purges.    ---------------------O     Blackouts Begin at Homet  - Lack of application-level protection cripplese mission-critical systems.r   By Peter Coffee   : No, I did not get an advance copy of the Interim Report of8 the U.S.-Canada Power System Outage Task Force, released9 last week. Any resemblance between its conclusions and my ; newsletter column of two weeks ago is pure coincidence--andA; I'm more worried than gratified by this prompt confirmation   of the problem that I described.  7 (Get the full story on what blacked out the East Coast)n< http://eletters.eweek.com/zd1/cts?d=79-331-6-7-71952-39707-12 (I hate it when applications only pretend to work)< http://eletters.eweek.com/zd1/cts?d=79-331-6-7-71952-39710-1  : The task force report found three groups of causes for the8 August 14th blackout.  Assuming that the pruning of tree8 limbs near wires doesn't need to be on your Web services< agenda, the first and third groups still have high relevance4 for application developers as they move into broadly8 distributed systems with high-availability requirements.  9 (Read about last week's troubling data on availability of  enterprise Java applications) < http://eletters.eweek.com/zd1/cts?d=79-331-6-7-71952-39713-1  1 The blackout report labels Cause 1 as "Inadequatec6 Situational Awareness," and Cause 3 as "Failure of the: interconnected grid's reliability organizations to provide: effective diagnostic support." The crucial event under the3 Cause 1 heading was the failure of an alarm system:R  8 "...[A]larm and logging software failed sometime shortly1 after 14:14 EDT... operators were working under ae< significant handicap without these tools. However, they were< in further jeopardy because they did not know that they were operating without alarms..."  5 As I said above, it's pure coincidence that two weeks - earlier, I had written that "the scene is setu; for...catastrophe when something appears to be working--ando isn't."T  9 But wait, there's more. "At 14:41 EDT, the primary serverv7 hosting the [Energy Management System] alarm processing ; application failed, due either to the stalling of the alarmo7 application, 'queuing' to the remote terminals, or some / combination of the two. Following preprogrammede< instructions, the alarm system application and all other EMS2 software running on the first server automatically4 transferred ('failed-over') onto the back-up server.  < However, because the alarm application moved intact onto the6 backup while still stalled and ineffective, the backup: server failed 13 minutes later, at 14:54 EDT. Accordingly,8 all of the EMS applications on these two servers stopped	 running."n  9 In short words: a fail-over mechanism only made provision 5 for a failure of the application platform; it did notu; correctly deal with failure at the level of the applicationa9 itself, but instead merely duplicated that failure on they backup server.  ; Even with both servers down, the system did not suffer hard)< failure; it did, however, slow down to the point that screen8 updates took almost a minute instead of the usual 1 to 3: seconds. Ordinary movements from one top-level screen to a: lower-level detail screen, and back again, took minutes to9 perform. The report does not state this conclusion, but Ih6 will: interactive speed is part of correct application9 performance, and anything that slows application responsew5 needs to be treated as a form of failure--not just anl
 annoyance.  9 The servers' failures triggered pager alerts to IT staff,-9 who rebooted them. "At 15:08 EDT, IT staffers completed a 6 'warm reboot' (restart) of the primary server. Startup: diagnostics monitored during that reboot verified that the1 computer and all expected processes were running;i9 accordingly, IT staff believed that they had successfully08 restarted the node and all the processes it was hosting.< However, although the server and its applications were again- running, the alarm system remained frozen andc< non-functional, even on the restarted computer. The IT staff7 did not confirm that the alarm system was again working * properly with the control room operators."  6 As with the initial fail-over, the problem here was an5 ineffective definition of what it means to be "up and 6 running." The process was running, but the application1 represented by that process was not doing what it 5 should--and it was not part of the problem resolution-! procedure to confirm that it was.   : 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.  8 (Site security and uptime demand a sniper's precision in picking off the problems)s< http://eletters.eweek.com/zd1/cts?d=79-331-6-7-71952-39716-1+ (Read eWEEK Labs' review of AppScan 4.0 QA)m< http://eletters.eweek.com/zd1/cts?d=79-331-6-7-71952-39719-1  6 What's also needed, though, as the East Coast blackout8 report clearly shows, is a culture of responsibility for5 making sure that the system is meeting the enterprisel need--and not just "working."e   ------------------------------  % Date: Mon, 24 Nov 2003 17:36:40 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>/ Subject: Re: Required reading for HP executives ) Message-ID: <3FC287F0.158BF59B@istop.com>w  L re: article about applications not performaming correctly being one cause of
 the blackout.e  M The use of the term "warm reboot" implies an IBM mainframe. So it is far moretK likely that Carly would be proposing a HP-UX on IA64 solution complete withh" billions of dollars of consulting.  N The interesting portion of the article was the issue of a process failing overA with such an exact copy that the same problem continued to exist.g  H Perhaps this is where true clusters make a difference since the "backup"N process can not only participate in normal operations, but is also not such an% exact copy since it has its own life.e  L However, the danger is in RTR type of software in front of the cluster. If aN transaction causes process 1 to stall, the RTR type of software will then sendL that transaction to the second process which will also stall since it is theQ same software, and then RTR will send it to the next node and so on and so forth.d   ------------------------------  % Date: Tue, 25 Nov 2003 09:23:02 +1030i: From: "Barratt, Chris (FMC)" <Chris.Barratt@fmc.sa.gov.au>" Subject: RE: SQLSRV V7.1-5 ProblemN Message-ID: <E829CF9B8F94014887EBC61E1951B0CE9E75C9@sagemshs001.fmc.sa.gov.au>  F > Under the previous version of SQL this was the same with only errorsD > going to the logfile. Now it appears as is all activity is logged.  L I have seen this behaviour under SQL Services 7.0 and now 7.1. I don't thinkJ we used transaction reusable services under 6.1, so I am not sure what the situation was there.  ) What version was your previous version ? e   ------------------------------    Date: 24 Nov 2003 12:12:46 -0600+ From: young_r@encompasserve.org (Rob Young)lB Subject: Re: Sun to use AMD Opteron - announcement expected Monday3 Message-ID: <eQVWdFd4i26P@eisner.encompasserve.org>    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: >>  M >>>With both Sun and IBM legitimizing AMD64, Itanic looks an awfully lot less(N >>>invincible than many would have one believe, and IBM's and Sun's *existing*I >>>proprietary platforms continue to look like mature viable alternatives:N >>>rather than 'legacy' hardware.  Why would Sun instead choose to become justF >>>another me-too Itanic vendor struggling to overcome HP's sweetheart >>>relationship with Intel?s >>>  >> B >> 4C >> 	But Intel has some recent surprises in store.  Industry chattero@ >> 	has been about high-k over the years.  Intel surprised folksB >> 	and announced their high-k research is complete after 5 years  >> 	of development.0 >> BG >> http://www.intel.com/labs/features/si11031.htm?iid=labs+si11031.htm&i >> rI >> The entire semiconductor industry is struggling with the heat of chipsiP >> 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 thereforeuR >> 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 area' >> compatible with high-k dielectrics. . >> o >  > Depends on where you sit.m > > > If you are Intel with a processor that currently pushes 130+9 > watts with plans that will result in this getting worse ; > rather than better in the medium term then you are reallyt6 > struggling. With 2007 looking increasingly far away. >   = 	Which IA64 processor?  There are a number of them, they haveo= 	an IA64 processor that consumes far less than 130 Watts.  InlA 	fact, they have an IA64 processor that consumes somewhere arounds> 	62 Watts and outperforms any SPARC processor.  But why should? 	power consumption be a metric for something other than density  	oriented boxes?    < > 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 processsB > which may arrive sometime in the latter half of this decade will > save you.s    C 	Since high-k runs much cooler, certainly they could create largishcC 	(300-400 mm2) CPUs that contain 96 MByte on-chip cache and consume5* 	far less power, generate a lot less heat.  < 	If you look at their roadmap over the next 2-3 years , theyB 	have a 9 MByte Madison, Montecito in 2005, Tanglewood in 2006 andG 	follow-ons.  Maybe a high-k Tanglewood is little more than quadrupling@A 	on-chip caches?  Do you think a 2006 Tanglewood won't meet powereC 	budget?  No.  But couldn't it run much faster and have much larger D 	caches if the power consumption is greatly decreased?  Sure.  MaybeF 	clock goes from 1.5 GHz to 4 GHz and they burn 100 watts.  The high-kB 	will give more design freedom that's for sure.  But they won't be> 	performance handicapped until then.  That would be the SPARC.   				Rob    ------------------------------  % Date: Mon, 24 Nov 2003 17:24:27 +0000 O 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: <bptesc$40i$1@new-usenet.uk.sun.com>   Rob Young wrote:X > In article <3FBBC990.1ABCE690@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes: >  >>Rob Young wrote: >>P >>>        Again, as we both know Itanium is doing good from a sales standpoint.; >>>        The Itanic moniker is getting funnier every day.S >>F >>Has IA64 surpassed combined sales of Alpha and PA-Risc systems yet ? >  > D > 	Why should it?  Those CPUs are still being manufactured and sold.E > 	Tell us your thinking.  How or why should it exceed PA-RISC today?dF > 	Here's a gurarantee - In 4 years time, Itanium will be selling 100 C > 	times more in numbers than PA-RISC and Alpha will be - combined.m > H > 	By your reasoning Sun won't judge Opteron a success until it outsellsD > 	SPARC.  But we know long before that day , Sun will be trumpetingB > 	Opteron - otherwise they won't speed adoption.  So to say a CPU> > 	isn't a success until the former goes away, holds no water. >  > O >>If not, wake me up when it does. Until this happens, IA64 is just a prototypehL >>baby chip that exists only because a 2 million pound gorilla says it must  >>exist. >  > + > 	Actually it exists because Intel decidedND > 	to occupy the same space that the other 64-bit chips occupy.  YouJ > 	can bet in 3 years there will be far fewer 64-bit chips around to buildF > 	a server line for.  I'm willing to wager that at least 3 will have G > 	announced shutdown or will be shutdown and one of those three won't b > 	be Itanium. >   3 Is this one of your now famous predictions Rob ????t  > If so its good news for everyone except HP and Intel, you have* never been knowingly correct yet have you.   Regards- Andrew Harrison-   ------------------------------  % Date: Mon, 24 Nov 2003 19:14:20 -0500 * From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday2 Message-ID: <28ydnYv7o6hBA1-iRVn-vw@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:eQVWdFd4i26P@eisner.encompasserve.org... H > In article <bpt91g$1u3$1@new-usenet.uk.sun.com>, Andrew Harrison SUNUK; Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes:1   ...1  @ > > If you are Intel with a processor that currently pushes 130+; > > watts with plans that will result in this getting worse.= > > rather than better in the medium term then you are reallyh8 > > struggling. With 2007 looking increasingly far away. > >p >t > Which IA64 processor?   K It's appropriate to question that:  the highest TDP figure I've seen is forhJ the 1.5 GHz Madison, at 107W.  Next-highest was for the 1 GHz McKinley, atG 100W.  The oft-quoted 130W figure appears to be Intel's maximum for thetK entire family (a figure that allows OEMs to create boards that will support K that entire family, including members that may not yet exist:  if Madison's L clock rate increases about 10% next year as planned its TDP should be aroundI 120W, and the dual-core Montecito in 2005 will likely run out of the 130WhH power envelope headroom long before it runs out of steam - assuming thatL Intel gets its 90 nm. process better under control than it currently appears to be).   '   There are a number of them, they havet> > an IA64 processor that consumes far less than 130 Watts.  InB > fact, they have an IA64 processor that consumes somewhere around? > 62 Watts and outperforms any SPARC processor.  But why should @ > power consumption be a metric for something other than density > oriented boxes?v  I Density applies not only to racks but to rooms and buildings.  If using awL bunch of new Itanic workstations will force you to upgrade your building A/C8 system, you might think twice about using AMD64 instead.   >p >t> > > If you are Sun/IBM or AMD with under half the power budgetB > > and at least in the case of Sun plans that will result in thisD > > improving not getting worse, then life is less of a struggle andC > > you don't necessarely need to hope that an entirely new process D > > which may arrive sometime in the latter half of this decade will
 > > save you.p >f > 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.   J I believe that Andrew's observation was that it will be the latter portionJ of this decade before this begins to help.  You're back to selling futures: again, and this time even more distant futures than usual.   >c= > If you look at their roadmap over the next 2-3 years , theyn? > have a 9 MByte Madison, Montecito in 2005, Tanglewood in 2006y  L The time estimate that I've been seeing since Tanglewood was first mentionedE by name is 2006 *or* 2007.  Whether the hedging relates to product orn% process uncertainty I couldn't guess..   - bill   ------------------------------    Date: 24 Nov 2003 15:50:26 -0600+ From: young_r@encompasserve.org (Rob Young)eB Subject: Re: Sun to use AMD Opteron - announcement expected Monday3 Message-ID: <9um0Y04u9a45@eisner.encompasserve.org>a   In article <bptesc$40i$1@new-usenet.uk.sun.com>, Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes: > Rob Young wrote:Y >> In article <3FBBC990.1ABCE690@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes:t >>   >>>Rob Young wrote:a >>> Q >>>>        Again, as we both know Itanium is doing good from a sales standpoint.n< >>>>        The Itanic moniker is getting funnier every day. >>>wG >>>Has IA64 surpassed combined sales of Alpha and PA-Risc systems yet ?  >> y >> oE >> 	Why should it?  Those CPUs are still being manufactured and sold.nF >> 	Tell us your thinking.  How or why should it exceed PA-RISC today?G >> 	Here's a gurarantee - In 4 years time, Itanium will be selling 100 ?D >> 	times more in numbers than PA-RISC and Alpha will be - combined. >>  I >> 	By your reasoning Sun won't judge Opteron a success until it outsellswE >> 	SPARC.  But we know long before that day , Sun will be trumpetingtC >> 	Opteron - otherwise they won't speed adoption.  So to say a CPU ? >> 	isn't a success until the former goes away, holds no water.l >> r >>  P >>>If not, wake me up when it does. Until this happens, IA64 is just a prototypeM >>>baby chip that exists only because a 2 million pound gorilla says it must i	 >>>exist.. >> f >> s, >> 	Actually it exists because Intel decidedE >> 	to occupy the same space that the other 64-bit chips occupy.  YoueK >> 	can bet in 3 years there will be far fewer 64-bit chips around to buildsG >> 	a server line for.  I'm willing to wager that at least 3 will have eH >> 	announced shutdown or will be shutdown and one of those three won't  >> 	be Itanium.s >>   > 5 > Is this one of your now famous predictions Rob ????i >   = 	But that is an easy one Andrew - think about it.  Answers onf 	a postcard please.t  @ > If so its good news for everyone except HP and Intel, you have, > never been knowingly correct yet have you.  E 	Actually, you would be wrong - but what is new?  Since you do littler: 	but spout puffery and spin, you have little to go back to? 	substantiate a claim.  This same tired subject has been beatenn* 	about a few times, a good thread is here:  c http://groups.google.com/groups?selm=JNbGG0GqtEoe%40eisner.encompasserve.org&oe=UTF-8&output=gplaing  + From: young_r@encompasserve.org (Rob Young)a Newsgroups: comp.os.vmsc" Subject: Re: The Gauntlet is Cast!  Date: 10 Sep 2002 12:36:37 -0600    B 	Server margins will follow PC margins and there is ample evidence 	that is so.  > 	In August 2001 Sun was trading near $20 a share.  Since then, 	it is at $3 and change.  % 	Once again, in your attempt to spin:t  : > Namely that low end PC's will squeeze Sun out of the low
 > end market.   ? 	I haven't promoted that.  I've promoted in general that server A 	margins will slide and it will impact the big players most.  And A 	Sun much more than others as Sun is basically a one-trick pony, e 	hardware.     ---e   	That prediction came true.  u  ' 	We still see Sun shedding market sharelC 	(declining revenues and total market share).  And we will continue 6 	to see Sun slide.  How's that for another prediction?   				RobS   ------------------------------  % Date: Mon, 24 Nov 2003 19:33:28 -0500e* From: JF Mezei <jfmezei.spamnot@istop.com>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday) Message-ID: <3FC2A348.F3E02FA1@istop.com>.   Bill Todd wrote:K > Density applies not only to racks but to rooms and buildings.  If using aYN > bunch of new Itanic workstations will force you to upgrade your building A/C: > system, you might think twice about using AMD64 instead.  J Or move to the arctic where you won't have to worry about air conditioningH costs, and may be able to sell surplus heat to the rest of the town. TheL problem is that those towns run on diesel generators, so the new power plantI capable of powering your IA64 things will cost a lot to build and run :-(    ------------------------------  % Date: Mon, 24 Nov 2003 23:19:19 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>7 Subject: VMS could save the world ! (asteroid research)d) Message-ID: <3FC2D82A.95758ADA@istop.com>a  I The CBC (Canadian Broadcasting Corporation) aired a 2 hour documentary oniU asteroids which would possibly destroy civilisation. ( Asteroid ! The Doomsday Rock).o  K They mention various efforts by scientists to track known objects, convincesM politicians of the need to do something about it and find a way to change itsf/ orbit should they calculate a collision course.s  N The body in charge of collecting all observations and calculating their orbits6 is the Minor Planet Center, headed by Brian Marsden. (J http://cfa-www.harvard.edu/iau/mpc.html ) While being interviewed for thisI documentary, one can quickly peek at some of the screen output. While thenN monitor is very generic in look, the stuff being displayed included the famousM words "DECTERM" as well as a all too familiar directory display that ended upv with number of blocks :-)t  4 Confirmation that this wasn't just a token VMS box: 8 http://cfa-www.harvard.edu/iau/Ack/TamkinFoundation.html  M The documentary does mention the need for large computing capacity to receive-. and process up to 80,000 observations per day.  K What is good is that the MPC's website has no problems mentioning that theyi$ run a large cluster of VMS machines.   ##P                            The Tamkin Computer Network consists of the followingO                              machines. All the machines are running the OpenVMSeL                            operating system. The Alpha machines are arranged as an-Q                              OpenVMS Cluster, allowing all machines to share disktH                            storage, execution and batch queues and other resources. 6 ##    9 (the ____VMS word has a hotlink to www.____vms.compaq.com   N Ok, so VMS wasn't mentioned specifically in the documentary. But it is good to9 see that there are still some important VMS sites around.3    H (one a more scary note, PBS last week had a documentary warning that theN earth's magnetic field was weakening, which was not only very dangerous for usK (protects from radiation), but also a sign that the poles may change withiniL 1000 years (north pole woudl become south pole from magnetic point of view).   ------------------------------  % Date: Mon, 24 Nov 2003 23:27:00 -05009* From: JF Mezei <jfmezei.spamnot@istop.com>; Subject: Re: VMS could save the world ! (asteroid research) ) Message-ID: <3FC2D9F6.177ED56C@istop.com>a  S another side note: other obvious computers seen during those documentary were Macs.e  - proof that smart people don't use windows :-)    ------------------------------  # Date: Mon, 24 Nov 2003 18:22:24 GMTu4 From: brad@.gateway.2wire.net (Bradford J. Hamilton)B Subject: [OT] - pot calls kettle black (Was: Re: IA64 TPC results)/ Message-ID: <A%rwb.293521$Tr4.927118@attbi_s03>t   In article <bpstgc$r5v$1@new-usenet.uk.sun.com>, Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes: !snip!	  !t4 !Rob as you know perfectly well I started posting to4 !this group because of your attempts to FUD Sun over !eBays reliability issues. !v  L I was getting curious about this statement, so I checked Google Groups.  TheN first comp.os.vms posting by Andrew (actually a cross-post from c.o.d.) was onO October 29th, 1997.  The subject was, "Alpha is dead!", and Andrew's reply into M the "thread" had to do with speculation on IA64 and HP PA-RISC.  History will-J judge if Andrew's "analysis" was cogent, but at the time, it smacked of...   FUD.  5 !This is a matter of record and I doubt that even youa !would try to dispute this.- !snip! !Regards !Andrew Harrison !e  J __________________________________________________________________________A Bradford J. Hamilton                    "All opinions are my own"tK bMradAhamiPltSon-at-coMmcAast.nPeSt     "Lose the MAPS, and replace '-at-'  0                                          with @"   ------------------------------   End of INFO-VAX 2003.653 ************************