1 INFO-VAX	Thu, 27 Jun 2002	Volume 2002 : Issue 350       Contents:! Re: $CRMPSC and memory management  7.3-1 new backplane controller" Re: 7.3-1 new backplane controller; Re: A possible shift in the status of VMS ar HP ???? ERRATA ; Re: A possible shift in the status of VMS ar HP ???? ERRATA ; Re: A possible shift in the status of VMS ar HP ???? ERRATA ; Re: A possible shift in the status of VMS ar HP ???? ERRATA ; Re: A possible shift in the status of VMS ar HP ???? ERRATA ; Re: A possible shift in the status of VMS ar HP ???? ERRATA ; Re: A possible shift in the status of VMS ar HP ???? ERRATA ; Re: A possible shift in the status of VMS ar HP ???? ERRATA 8 Re: Amdrew wants numbers, here they are!  Blow out baby!8 Re: Amdrew wants numbers, here they are!  Blow out baby!8 Re: Amdrew wants numbers, here they are!  Blow out baby!G Re: BACKUP/INCREMENTAL not parsing directories properly during restores 9 Re: Call or email hp ... they will answer your questions! 4 Re: can VMS mail block e-mail from certian address'?4 Re: can VMS mail block e-mail from certian address'?$ Has SMTP RBL list worked for anyone?- How detect all Batch queues in a VMS system ? - how detect all batch queues in a VMS system ? 1 Re: how detect all batch queues in a VMS system ? # How detect Batch queues in Pascal ? ' Re: How detect Batch queues in Pascal ? + Re: howto create self-extracting zip files?  Re: IPSEC ? , Re: My conversation with Linus about VMS ..., Re: My conversation with Linus about VMS ..., Re: My conversation with Linus about VMS ...< Re: NSA: Security in current mainstream operating systems vs< Re: NSA: Security in current mainstream operating systems vs Re: Open Letter to HP  Re: Open Letter to HP  Re: Open Letter to HP  Re: Open Letter to HP  Quorum discussion/questions  Re: Quorum discussion/questions  RE: Quorum discussion/questions  Re: Quorum discussion/questions 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 RE: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III 3 Re: Reuters test - Itanium II blows away Sparky III % RMS : preserving a RAB across $OPEN ? ) Re: RMS : preserving a RAB across $OPEN ? ) Re: RMS : preserving a RAB across $OPEN ?  Re: size of exe  Sun benchmarketeering campaign
 Re: TCO study 
 Re: TCO study 
 Re: TCO study 
 RE: TCO study  Re: Trouble with BACKUP/RECORD Re: Trouble with Samba 2.0.3 Worldcom MCI and VMS Re: XFC Status??  F ----------------------------------------------------------------------  # Date: Wed, 26 Jun 2002 23:06:50 GMT % From: Robert Davis <res057y3@gte.net> * Subject: Re: $CRMPSC and memory management' Message-ID: <3D1A47CD.39CC6B81@gte.net>   B Thanks for the reply. That makes sense that VIRTUALPAGECNT doesn'tA affect the address range for P0, only how many pages can be used.   F But, now I'm confused as to why we're getting VASFULL errors trying toE map sections at x50000000 on VAX (when it seems to work OK on Alpha). E Are there other params that affect the P0 range? Any idea why I would F get a VASFULL error when trying to map a section at any address higher' than x10000000 on a VAX system? Thanks.    Rob    danco@pebble.org wrote:  > C > So far as I know, VIRTUALPAGECNT has no bearing on where P0 ends, B > at least not in the normal OpenVMS user mode program.  P0 beginsA > at 0 and ends at 4FFFFFFF.  You can map to any address range in F > P0 that isn't already being used for something else.  VIRTUALPAGECNTD > is just the limit on the total number of process virtual pages youF > can have.  Some process pages may be mapped and some may not.  A bigC > jig-saw puzzle with holes.  The number of pages that are actually C > mapped must be less than or equal to VIRTUALPAGECNT.  If you very A > badly fragement P0 virtual address space, you can run out of P0 A > virtual address space before you run out of VIRTUALPAGECNT.  If B > expreg sections are allocated after the highest currently mappedE > virtual addresses (don't recall if they are or not), then combining C > expreg sections with sections at high fixed addresses could cause  > a problem like that. > G > Then there is PROCSECTCNT that limits how many sections you can have. C > The default limit of 32 sections is rather low.  If you use a lot @ > of shareable images that are not well consolidated into as few@ > image sections as possible, or you have a lot of data sectionsE > mapped through $CRMPSC and friends in your program, you can easilly 
 > go over 32.    ------------------------------  % Date: Wed, 26 Jun 2002 14:13:07 -0500 1 From: "Dave Gudewicz" <david.gudewicz@abbott.com> ' Subject: 7.3-1 new backplane controller 1 Message-ID: <afd3rj$gd6$1@fizban.pprd.abbott.com>   E VMS web page mentions support of a new backplane controller in 7.3-1.   G Anyone know what new backplane controller.  No model or part number was  given.   Dave...    ------------------------------  % Date: Wed, 26 Jun 2002 17:01:34 -0400 6 From: "John.Malmberg" <Malmberg@dskwld.zko.dec.compaq>+ Subject: Re: 7.3-1 new backplane controller 4 Message-ID: <3D1A2BAE.2090401@dskwld.zko.dec.compaq>   Dave Gudewicz wrote:G > VMS web page mentions support of a new backplane controller in 7.3-1.  > I > Anyone know what new backplane controller.  No model or part number was  > given.  H It is from the "Smart Array" line of Backplane controllers according to 
 the web page.   H For those not familiar with the "Smart Array" line, here is the general  link.   R http://www.compaq.com/products/servers/proliantstorage/arraycontrollers/index.html   -John ! malmberg@dskwld.zko.dec.compaq.hp  Personal Opinion Only    ------------------------------  % Date: Wed, 26 Jun 2002 22:03:07 +0200  From: Dirk Munk <munk@home.nl>D Subject: Re: A possible shift in the status of VMS ar HP ???? ERRATA& Message-ID: <3D1A1DFB.7040706@home.nl>   David Froble wrote:  > John Smith wrote:  > ? >> "Terry C. Shannon" <terryshannon@attbi.com> wrote in message < >> news:rg3S8.176145$6m5.147186@rwcrnsc51.ops.asp.att.net... >> >>> terry s $ >>> Shot in Foot With Own Gun, Again >> >  > 5 > When it's the foot, it's usually your own gun.  :-)  >  >>>  >>F >> At the risk of starting a 'war', perhaps it's time for gun control? >  >  > I > I agree completely.  Let's keep them out of the hands of criminals and  @ > such, and in the hands of honest citizens.  Great gun control! >  > Dave >   E OK, since we er now completely off topic, I will add my contribution.   Q A couple of days ago I saw a TV program about Kevlar and its use in bullet proof  K vests. In the program was that famous scene of two LA bankrobbers who were  Q shooting at the police with AK47's. The police was totaly outgunned, because the  P bankrobbers wore bullet proof vests, and the police weapons could not penetrate Q those. It looked kind of funny seeing those bankrobbers strolling along casually  ; over the parking lot, spraying the whole area with bullets.   M The police had to act of course, and they went to the friendly local gunshop  L (where else). There they borrowed some military assault rifles to match the F armament of bankrobbers (seems the shop was out of anti-tank guns and G howitzers). And the whole thing came to a good end (=dead bankrobbers).   P Of course now it was time for the politicians to act, and they did. First every J police car got its own set of military assault rifles. Then came the next O logical step. No, no, not what everyone else would do. They drew up a law that  O forbids people with a criminal record to wear bullet proof vests !! That makes  O sense of course. There is nothing in the US constitution that guarantees every  P citizen the right to wear a bullet proof vest. This is a tremendous blow to the K criminals. Shooting and killing police men and civilians is one thing, but  P getting arrested later and beeing charged with illegally wearing a bullet proof N vest is something totaly different !! And having to explain in court why they K would not give the police the opportunity to shoot and kill them is almost   impossible.   G Can someone please tell me when the Monthy Pyton team took over the US  @ government ? Or is George W. also a member of ........ Oh dear !   ------------------------------  # Date: Wed, 26 Jun 2002 20:18:50 GMT 8 From: hammond@not@peek.ppb.cpqcorp.net (Charlie Hammond)D Subject: Re: A possible shift in the status of VMS ar HP ???? ERRATA2 Message-ID: <KkpS8.50$Dt6.941092@news.cpqcorp.net>  ' In article <3D1A1DFB.7040706@home.nl>,    Dirk Munk <munk@home.nl> writes: ..H >Can someone please tell me when the Monthy Pyton team took over the US  >government? ...  > One could make a life's work of responding to this question -- and never finish.    --  K     Charlie Hammond -- Compaq Computer Corporation -- Pompano Beach  FL USA 8                        Compaq is now part of the New HP!H        (hammond@not@peek.ppb.cpqcorp.net -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------  % Date: Wed, 26 Jun 2002 15:37:01 -0500 ( From: David Harrold <DHarrold@wi.rr.com>D Subject: Re: A possible shift in the status of VMS ar HP ???? ERRATA8 Message-ID: <ne9khu074lhnu3i6bda5oh66431fgl8g44@4ax.com>  F On Tue, 25 Jun 2002 21:21:49 GMT, "John Smith" <a@nonymous.com> wrote:   > = >"Terry C. Shannon" <terryshannon@attbi.com> wrote in message : >news:rg3S8.176145$6m5.147186@rwcrnsc51.ops.asp.att.net... >>
 >> terry s# >> Shot in Foot With Own Gun, Again  > D >At the risk of starting a 'war', perhaps it's time for gun control? >   : Reminds me, haven't been to the range in a week or so.....      N ..............................................................................N David Harrold                              E-Mail: David_Harrold at aurora.orgI Sr. Software Systems Engineer              Phone:          (414) 647-6204 I                                            Pager:          (414) 941-4634 G Aurora Health Care                         Fax:          (414) 647-4999  3031 W. Montana Street Milwaukee, WI 53215    ------------------------------  % Date: Wed, 26 Jun 2002 17:31:43 -0400 ( From: David Froble <davef@tsoft-inc.com>D Subject: Re: A possible shift in the status of VMS ar HP ???? ERRATA, Message-ID: <3D1A32BF.1000701@tsoft-inc.com>   John Smith wrote:   > > "Terry C. Shannon" <terryshannon@attbi.com> wrote in message; > news:rg3S8.176145$6m5.147186@rwcrnsc51.ops.asp.att.net...  > 	 >>terry s " >>Shot in Foot With Own Gun, Again >> > E > At the risk of starting a 'war', perhaps it's time for gun control?      Yeah, I can be slow.  O One would think that starting such a war would be a real risk for you.  If you  L practice what you appear to preach, then you won't have any guns, and those R you'd be at war with would.  Rather precarious situation for you, don't you think?  Q One of the stories that I really liked was the Washington DC newspaper columnist  P who was pro gun control.  Right up til the time someone broke into his house or M some such and he broke out HIS gun and shot the guy.  See, HE was allowed to  K have a gun, but nobody else had the same choice, at least as far as he was  
 concerned.  Q So, maybe you won't be in such trouble, if you preach gun control to others, but    feel free to keep your own guns?   On the topic of hyprocrisy:   O Woman is on the picket lines at abortion clinic.  A real pro-life person.  The  O next week she's IN the abortion clinic with her daughter, who was inconviently  L pregnant, saying "I can't believe I'm doing this, but I can't see any other L choice (sic)".  Now, the abortion clinic has rules which safeguard patients Q privacy.  Too bad!  A week later, this same woman, who decided that SHE needed a  O choice, was back on the picket line protesting others rights to a choice.  The  M clinic people were really upset that their rules guranteeing patient privacy  @ wouldn't allow them to publicize the activities of the hypocrit.    Y While the road to hell may be paved with 'good intentions', it was built by 'do gooders'.      Dave   ------------------------------  # Date: Wed, 26 Jun 2002 23:04:27 GMT - From: "John E. Malmberg" <wb8tyw@qsl.network> D Subject: Re: A possible shift in the status of VMS ar HP ???? ERRATA* Message-ID: <3D1A4476.2090407@qsl.network>   John Smith wrote: I > In the on-line newspaper world, its the latest news that's free and the N > archives that cost money. For Terry, it's the inverse. It costs money to flyI > to these places, and the man has to eat.....how else does Terry pay for  > that?   K Well Terry keeps refering being an ex-employee of some intelligence agency.   G According to the movies and the tv shows in the U.S., ex-employee's of  F intelligence services have stashes of cash and "defensive" weapons in D safehouses all over the globe.  But of course they only use them in  defense of the free world. :-)   -John  wb8tyw@qsl.network Personal Opinion Only    ------------------------------  # Date: Wed, 26 Jun 2002 23:49:29 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com> D Subject: Re: A possible shift in the status of VMS ar HP ???? ERRATA. Message-ID: <dqsS8.317884$352.34840@sccrnsc02>  8 "John E. Malmberg" <wb8tyw@qsl.network> wrote in message$ news:3D1A4476.2090407@qsl.network... > John Smith wrote: K > > In the on-line newspaper world, its the latest news that's free and the L > > archives that cost money. For Terry, it's the inverse. It costs money to fly K > > to these places, and the man has to eat.....how else does Terry pay for 	 > > that?  > E > Well Terry keeps refering being an ex-employee of some intelligence  agency.   J 509th RRG USASA 70-72. USASA being a military subsidiary of a better-known agency.    > H > According to the movies and the tv shows in the U.S., ex-employee's ofG > intelligence services have stashes of cash and "defensive" weapons in E > safehouses all over the globe.  But of course they only use them in   > defense of the free world. :-)  J Would that this was the case. Truth is, us lowly enlisted types didn't getL much when we mustered out. I got a steak dinner, travel pay, and accumulatedI leave when I departed sunny Southeast Asia and stopped defending the free J world (or whatever the heck the reason was that we got ourselves into Viet Nam). That was it.  I As for paying for travel and eating dinners these days, I have to rely on H SKHPC and such consulting work as might rear its head from time to time.   ------------------------------  # Date: Thu, 27 Jun 2002 00:06:17 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> D Subject: Re: A possible shift in the status of VMS ar HP ???? ERRATA' Message-ID: <3D1A5AFD.D693088D@fsi.net>    Dirk Munk wrote: > H > Can someone please tell me when the Monthy Pyton team took over the US > government ?    A When they inherited it from (the estate of) Curly, Moe and Larry.    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Thu, 27 Jun 2002 05:28:41 GMT * From: "Bill Todd" <billtodd@metrocast.net>D Subject: Re: A possible shift in the status of VMS ar HP ???? ERRATAB Message-ID: <doxS8.143866$_j6.7979561@bin3.nnrp.aus1.giganews.com>  5 "David Froble" <davef@tsoft-inc.com> wrote in message & news:3D1A32BF.1000701@tsoft-inc.com...   ...   L > One would think that starting such a war would be a real risk for you.  If you G > practice what you appear to preach, then you won't have any guns, and  those I > you'd be at war with would.  Rather precarious situation for you, don't 
 you think? > H > One of the stories that I really liked was the Washington DC newspaper	 columnist H > who was pro gun control.  Right up til the time someone broke into his house orK > some such and he broke out HIS gun and shot the guy.  See, HE was allowedN toL > have a gun, but nobody else had the same choice, at least as far as he was > concerned.  J Do you have any evidence whatsoever that either John and the columnist youH refer to believe that nobody should be allowed to have a gun, or is thisK just the paranoid extreme gun nuts seem prone to jump to whenever they heart the phrase 'gun control'?    - bill   ------------------------------  # Date: Wed, 26 Jun 2002 17:44:25 GMTt1 From: "Terry C. Shannon" <terryshannon@attbi.com>sA Subject: Re: Amdrew wants numbers, here they are!  Blow out baby!s. Message-ID: <Z3nS8.325379$cQ3.19602@sccrnsc01>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:ay$VIouPV10A@eisner.encompasserve.org...o7 > In article <3D19F13D.69DD33C8@videotron.ca>, JF Mezeio& <jfmezei.spamnot@videotron.ca> writes: > > Rudolf Wingert wrote: G > >> If I see this right, the UltraSparc with 1.05GHz will not have the H > >> performance of the 1.0GHz Alpha (EV68). If the Marvel is out (EV7),3 > >> then you will see a new one performance boost.a > >oC > > I have only heard of EV7 for Wildfire/Marvel type systems being?
 deployed. ArelJ > > there plans to deploy EV7 chips in ES and the DS systems ? I was under the L > > impression that the mnimum requirements for the chip would not bode well with! > > smaller systems (memory etc).n > >a >  > Yes.  Check this out:x >c; > http://www.compaq.com/hps/announce/alphaserver_image.htmls >oB > While details are lacking (I can't find them ... feel free) thatI > box out front is obviously fairly small... guess is it is a 2 processor  > (no less than 2) box.   G Yep. 2P is the minimum increment and there will be (actually, there areoK today) 2P boxes. The 2P box is a building block for 2-8P DS and ES systems. K Also an 8P building block (composed of a stack of four 2Ps) that'll be useds in larger GS systems.  >rJ > > If a significant number of alpha systems will continue to be sold with EV6x4 > > CPUs, then EV7 may not benefit that many people. >eA > Demarcation line in performance.  Buy it if you need it.  Don'tI > if you don't.w  H EV7 won't do much for the uniprocessor workstation marketplace, but EV69J should help address this audience. The bad news about EV7 is pricey RAMBUSJ memory, the good news is that price and performance should scale much moreJ linearly than on current GS-systems. (No more QBBs and FireBoxes to create. big price bumps at the 9P and 17P level, etc).   ------------------------------  # Date: Wed, 26 Jun 2002 20:46:04 GMTO# From: "John Smith" <a@nonymous.com>rA Subject: Re: Amdrew wants numbers, here they are!  Blow out baby!oH Message-ID: <gKpS8.40855$71t1.8998@news01.bloor.is.net.cable.rogers.com>  K Depends if you are the customer trying to get work done, or a member of theS; vendor's marketing department looking for a year-end bonus.-    : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3D19F6E4.7F9A9BFA@videotron.ca... > Bob Ceculski wrote:0H > > it's called rounding Bill, something Sun drastically does with their- > > numbers to make them look competitive ...p > K > In the end, what counts most ? The actual performance of a system, or the,: > number of systems sold because you have good marketing ?   ------------------------------  % Date: Thu, 27 Jun 2002 01:10:49 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)A Subject: Re: Amdrew wants numbers, here they are!  Blow out baby!eL Message-ID: <rdeininger-2706020110500001@11cust138.tnt2.nashua.nh.da.uu.net>  3 In article <ay$VIouPV10A@eisner.encompasserve.org>,e, young_r@encompasserve.org (Rob Young) wrote:  6 >In article <3D19F13D.69DD33C8@videotron.ca>, JF Mezei& <jfmezei.spamnot@videotron.ca> writes: >> Rudolf Wingert wrote:F >>> If I see this right, the UltraSparc with 1.05GHz will not have theG >>> performance of the 1.0GHz Alpha (EV68). If the Marvel is out (EV7), 2 >>> then you will see a new one performance boost. >> aP >> I have only heard of EV7 for Wildfire/Marvel type systems being deployed. AreM >> there plans to deploy EV7 chips in ES and the DS systems ? I was under theoP >> impression that the mnimum requirements for the chip would not bode well with  >> smaller systems (memory etc). >> d >s >        Yes.  Check this out: >A: >http://www.compaq.com/hps/announce/alphaserver_image.html >sI >        While details are lacking (I can't find them ... feel free) thattP >        box out front is obviously fairly small... guess is it is a 2 processor >        (no less than 2) box.  A Your guess is correct.  The little system on the pedestal is a 2PeD configuration.  The tall rack at the right contains 4 more of the 2P systems.  J The second and third tall racks (counting from the left) each contain 4 8P systems.  ? All of the preview material I have seen names the entire familyf@ GS-whatever.  I haven't seen any plans to continue the DS and ESJ designations in the EV7 line.  The systems will start at 2P, and the namesE will start with GS.  Unless the marketing folks change their minds, Ie suppose.   ------------------------------    Date: 26 Jun 2002 12:38:19 -0700. From: SPAMSINK2001@YAHOO.COM (Alan E. Feldman)P Subject: Re: BACKUP/INCREMENTAL not parsing directories properly during restores= Message-ID: <343f30ae.0206261138.1179f251@posting.google.com>a  g skulker@easynews.com.yourpants (skulker) wrote in message news:<3d19b8ff.55246228@news.easynews.com>...7 > Greetings! > B > I have encountered a problem with the BACKUP/INCREMENTAL command& > during a disk restore. (VMS 7.2-1H1) >  > My comand (example): > : > $ BACKUP/INCREMENTAL/DENS=TK87 $9$MKA80:saveset.bak/SAVE > $1$DUA400:/LOG  d  E Why are you using the /DENSITY qualifier for a restore? I would thinkBA it to be not needed. The /SAVE is unnecesary because MK is a tape > device, but should do no harm. The /LOG qualifier is a commandF qualifier and should be placed between BACKUP and the input specifier.E BACKUP is in some circumstances very fussy about qualifier placement,l8 though I never had a problem with /LOG being at the end.    F > This results in a delete pass prior to the restore pass. All is wellF > with files - but NOT directories. It seems BACKUP is not parsing the > directory syntax properly. >  > An error message (example):w > @ > %BACKUP-E-INCDELERROR, error deleting $1$DUA400:[a.b.c]c.dir;1$ > -SYSTEM-W-NOSUCHFILE, no such file > D > That's a true statement because the directory is $1$DUA400:[a.b.c], > making the filespec $1$DUA400:[a.b]c.dir;1    F Well, it seems to me that as long as you don't have any extra non-.DIR? files leftover, you could live with extra empty directories. OfeF course, that depends on just exactly what your apps do. Unfortunately,E I don't have experience with this version of BACKUP, but it does looke like a bug.i  @ I assume you are not modifying anything on the disk ($1$DUA400:) between BACK/INCR operations.     < > Sooooo - I can use  [*...] in the output spec and drop theH > /INCREMENTAL but I may fill up the disk device and I need to create anH > "exact" copy of the source disk that was originally backed up to tape.E > I'm actually cloning a remote system and  don't want/need the extrae3 > baggage (files/directories) that no longer exist.     3 Yeah, I wouldn't want to replace /incr with [*...].l    F > Am I missing something, doing something wrong, or just "stoopid"? IsF > there a patch/release/fix from COMPAQ (part of the new HP)? Am I out
 > of luck?    ? In your second post you mention that you are doing differentialsF backups. The BACKUP/INCR command assumes incremental backups, so maybeD that has something to do with it, though I think BACK/INCR should be able to handle it anyway.o  @ Another poster mentioned order of tapes. I'm pretty sure this isC irrelevant except that doing the tapes in the wrong order increaseshE the chances of filling up the disk. Other than that, order should nott@ matter as far as success goes. At least that's what the VMS v6.2B manual says. Doing the tapes in reverse chronological order is theB most efficient way to go, but is not necessary for success. (It isF most efficient because in that case, the first incremental will deleteA all directory entries for files that should not be present in thehB final outcome and that gives BACKUP/INCR the clues it needs duringC subseuqnet incremental restore operations to not restore files thatiA were ultimately deleted by the time of the final incremental savemA operation -- and at least some of those files would be needlessly B restored and deleted if the incrementals were applied in any other order.)     G > Oh yeah - I have a call into Compaq but I thought I might get a headsM > up here...    C In the FAQ it says to make sure you have installed *all* the latesth
 BACKUP ECO's.u  6 Sorry I can't be of more help. I'm on VMS 6.1 and 6.2.     Disclaimer: JMHO Alan E. FeldmanA afeldman gfigroup com    ------------------------------  # Date: Thu, 27 Jun 2002 00:01:51 GMTt1 From: "David J. Dachtera" <djesys.nospam@fsi.net>?B Subject: Re: Call or email hp ... they will answer your questions!' Message-ID: <3D1A59F3.29F3B547@fsi.net>i   John Smith wrote:o >  > ooops....n" > the conclusion should read...... > I > In my view, a) is probably likely, while b) is NOT a certainty - if thec > conditions mentioned are met.r > 0 > "John Smith" <a@nonymous.com> wrote in messageA > news:Oc2S8.9589$mi.4283@news01.bloor.is.net.cable.rogers.com...  > > @ > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message$ > > news:3D17DE9B.398A550@fsi.net... > > >e1 > > > d) HP can do nothing about VMS and survive.h > > >uE > > > Note, however, that a distinction is made between "succeed" andh > > > "survive". > >m > >t, > > HP can do nothing about VMS and survive. > >oM > > a) Hmmmm, do you mean that, HP will survive if they do nothing about VMS?. > or > >rF > > b) Did you mean that VMS will survive if HP does nothing about it? > >a > >eK > > In my view, a) is probably likely, while b) is a NOT certainty - if the ! > > conditions mentioned are met..  ' Agreed ... and yes, that was my intent..   -- . David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------   Date: 26 Jun 2002 20:27:43 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)= Subject: Re: can VMS mail block e-mail from certian address'? * Message-ID: <afd83v$1ct$1@web1.cup.hp.com>  f In article <02061812365835@esonic.e-sonic.com>, wpg_michael@esonic.e-sonic.com (Michael Young) writes:  K :Can someone walk me through setting up my e-mail acct to block e-mail fromRJ :certian e-mail address'?  I'm using the MAIL program that comes with VMS.  K   I am aware of no direct spam filtering capabilities available within the 6H   OpenVMS MAIL utility nor within the MAIL callable API available withinL   OpenVMS -- there have been a few discussions in this area over the years, +   but I am aware of no available solutions.s  I   There is no equivalent of the spam filter that is available within the .&   Outlook client, among other clients.  aI   I've seen references to folks integrating a tool known as Spam AssassinRL   into their MAIL utility, but this has not been made available for OpenVMS.  K   One hack-around would involve the use of a tool such as DELIVER (part of oJ   the Freeware) to process the spam once it arrives on the target system, !   and (in this case) delete it.     K   The usual approach to this problem involves processing (filtering) on an ,G   SMTP firewall -- once the spam has gotten all the way to the host andhJ   a tool such as DELIVER or Spam Assassin can be brought to bear, much of B   the corporate network load-related damage has already been done.  I   You might well convince your system or IP network adminstrator to look NI   into this problem.  Of course, getting the spammer to stop sending spamaK   is probably futile.  (If you know who is originating the mail, there may )>   or may not be some form of legal recourse available to you.)  J   If this is internally-routed mail arriving from a unique DECnet source,    there are other options.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Thu, 27 Jun 2002 00:18:27 GMT 0 From: "brad.madison" <brad.madison@mail.tds.net>= Subject: Re: can VMS mail block e-mail from certian address'?e, Message-ID: <3D1A59D2.93D2280A@mail.tds.net>   Hoff Hoffman wrote:t > h > In article <02061812365835@esonic.e-sonic.com>, wpg_michael@esonic.e-sonic.com (Michael Young) writes: > M > :Can someone walk me through setting up my e-mail acct to block e-mail from.L > :certian e-mail address'?  I'm using the MAIL program that comes with VMS. > L >   I am aware of no direct spam filtering capabilities available within theJ >   OpenVMS MAIL utility nor within the MAIL callable API available withinM >   OpenVMS -- there have been a few discussions in this area over the years, - >   but I am aware of no available solutions.l >    D I wouldn't say it is pretty but I have done spam filtering on a PMDFH queue.  What I actually filter for is relay spam but the basic idea - doC a string search, give special treatment to the files that match thetE string - could be used to filter at the system level for email from a@ particular source.    D You can also create a batch job that will remove all messages from a+ particular address from the NEWMAIL folder:t   $ MAIL
   SEL NEWMAILd1   DIR/from="badguy@microsoft.com" (as an example)h   DELETE/ALL  F Crude, yes.  It doesn't block the email but it destroys it.  ObviouslyG you can do other things, like move it to a particular folder or extracttF it to a file: any standard mail command, once you've selected the ones you want to treat. --> "Our problems are mostly behind us.  What we have to do now is. fight the solutions."  ---Stult's Report (from" http://www.reznor.com/~aj/quotes/)  > See: http://fightrelayspam.homestead.com/ for my honeypot page Stop relay spam in Julya   ------------------------------  + Date: Wed, 26 Jun 2002 20:13:21 +0000 (UTC)t* From: bleau@umtof.umd.edu (Lawrence Bleau)- Subject: Has SMTP RBL list worked for anyone?t0 Message-ID: <afd791$n8v$1@grapevine.wam.umd.edu>  E I haven't received much help on my previous post, so I'm changing thes question and bit.n  = If you are running TCPIP V5.1 (AXP) and you are using the RBLeF (realtime blockhole list) feature, have you ever seen evidence that it works?  9 Evidence would be something in TCPIP$SMTP_RECV_RUN.LOG ornF TCPIP$SMTP_LOGFILE.LOG that says a given host name (or client, as it'sD also called) was found on one of the RBL sites you specified and wasF therefore rejected.  A lack of such a log entry would not be evidence.  C If you have such evidence, what RBL site are you using?  I am usingiE bl.spamcop.net, and we still receive email from IP addresses that areoD listed on spamcop.  I don't know if the problem is at spamcop or the@ SMTP software or something else.  If anyone can give me positiveE evidence that the RBL feature works, that eliminates one source of myfB problem.  Also, please save the log file, it may help me.  Thanks.  4 P.S. You may have to set the log level (logical nameC TCPIP$SMTP_LOG_LEVEL) to 2 or more to get the required detail levelA	 recorded.h   Lawrence Bleau University of Maryland" Physics Dept., Space Physics Group 301-405-6223 bleau@umtof.umd.edu    ------------------------------    Date: 26 Jun 2002 17:03:28 -0700- From: contracer11@uol.com.br (Shiva MahaDeva) 6 Subject: How detect all Batch queues in a VMS system ?= Message-ID: <ddf392ea.0206261603.66cbd8a7@posting.google.com>w  H Im looking for a Pascal program to detect and show me all Batch queues  in a VMSsystem.  How can I make this task ? Thanks in advance...   ------------------------------    Date: 26 Jun 2002 17:06:02 -0700- From: contracer11@uol.com.br (Shiva MahaDeva) 6 Subject: how detect all batch queues in a VMS system ?= Message-ID: <ddf392ea.0206261605.5289bbad@posting.google.com>a  H Im looking for a Pascal program to detect and show me all Batch queues  in a VMSsystem.  How can I make this task ? Thanks in advance...   ------------------------------  % Date: Wed, 26 Jun 2002 21:04:56 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>u: Subject: Re: how detect all batch queues in a VMS system ?, Message-ID: <3D1A64B8.C0FC7913@videotron.ca>   Shiva MahaDeva wrote:e > I > Im looking for a Pascal program to detect and show me all Batch queuess > in a VMSsystem.e > How can I make this task ?  O The SYS$GETQUI system service will do this for you, callable from any language.y  , HELP SYSTEM $GETQUI will give you more info.   ------------------------------    Date: 26 Jun 2002 16:58:02 -0700- From: contracer11@uol.com.br (Shiva MahaDeva)t, Subject: How detect Batch queues in Pascal ?< Message-ID: <ddf392ea.0206261558.7e55f4a@posting.google.com>  I Im looking for a Pascal program to detect all Batch queues in my system.i How can I make this ?    ------------------------------  % Date: Wed, 26 Jun 2002 20:09:44 -0400E1 From: Michael Austin <maustin@firstdbasource.com>d0 Subject: Re: How detect Batch queues in Pascal ?2 Message-ID: <3D1A57C8.E8FFBD32@firstdbasource.com>   Shiva MahaDeva wrote:e > K > Im looking for a Pascal program to detect all Batch queues in my system.  > How can I make this ?h  C look at the docs on systems service calls and the proper method form making those calls.l  . www.openvms.compaq.com  look for documentation --   Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163i7 Sr. Consultant            http://www.firstdbasource.com2E                           http://www.firstdbasource.com/donation.htmll/ 704-947-1089 (Office)     704-236-4377 (Mobile)o   ------------------------------   Date: 26 Jun 2002 21:41:24 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)4 Subject: Re: howto create self-extracting zip files?* Message-ID: <afdce4$1ct$4@web1.cup.hp.com>  /   Re: "howto create self-extracting zip files?"u  I   Please see the Zip and Unzip areas in the OpenVMS Freeware V5.0 area.  uG   In particular, please read the documentation included in those areas.eB   Specifically, please learn about the SFX portion of the toolset.  U In article <3D139FC7.7EE3ED85@hp.com>, Wayne Morrison <Wayne.Morrison@hp.com> writes:a :  :Nic Clews wrote:t :>   :> Wayne Morrison wrote: :> > :> ...G :> > VAX.  It's primarily a matter of needing to choose where you spend"L :> > finite engineering resources.  Between the Itanium port and significantH :> > new functionality (yes, mostly on Alpha), we're keeping rather busy :> > here in OpenVMS.y) :>                  ^^^^^^^^^^^^^^^^^^^^^, :>  K :> Surely this is incorrect. It is both Alpha and Itanium as they share the I :> code base, so this new functionality will also be on Itanium releases.E  J   Why would code for the new AlphaServer GS-series be in OpenVMS on IA-64?I   Why would boot support for EFI be in OpenVMS on Alpha?  There's a chunkoI   of here work that is and will be platform-specific, and even processor-aK   or widget-specific -- this is a common misconception, I might add.  FolkseJ   tend to discount the amount of work involved in adding support for a newM   Alpha platform.  And there is certainly a chunk of wholely new work in the  H   IA-64 port, not the least of which includes the bootstrap and ensuing F   system configuration processing.  (I'm in FAT city, myself. :-)  TheI   higher-level operating system code will be common, and the source code rH   pool is common.  (The source system itself is also seeing changes and :   enhancements to provide support for multiple platforms.)  J :You are correct that this new functionality will be on Itanium as well asN :Alpha.  However, since iVMS isn't ready quite yet, the development (and firstN :availability) is still on Alpha today.  We're getting head start, though, viaN :cross-compilers, so once the core O/S is ready, the rest will quickly follow.  I   As the bootstrap work proceeds, developers here in OpenVMS Engineering uH   will be cross-compiling and then native-compiling their code.  But theI   folks working on porting OpenVMS onto IA-64 have to have something for mH   the other OpenVMS developers to port their code onto first...  Once weH   have the system bootstrapped (and the contest closed), then we'll haveG   more and more developers working on both IA-64 and Alpha in parallel.n  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Wed, 26 Jun 2002 14:50:51 -0400i* From: "Leo Demers" <leo_dot_demers@HP.COM> Subject: Re: IPSEC ?* Message-ID: <afd2gl$t5u$2@web1.cup.hp.com>  	 Hi Larry,mL   The engineering TCP/IP team is busy working on that now. They will have anF IPSEC Early Adopter Kit (EAK)/Field test available near the end of theJ calendar year/beginning of next.  They are currently working on an SSH EAKG (It's what most folks want to see first)  that should be available thise fall.yL Hopefully these offerings will be able to share the cryptographic code (it'sJ the same stuff from the same vendor) and that should speed up the delivery on the IPSEC EAK.u  H    In the meantime we are making a port of OpenSSL 0.9.6b available withG 7.3-1 we also have a port of Stunnel done that ships on the Open Source K Tools CD.  So folks will be able to secure telnet, ftp(control channel onlytL no data encryption), RCP, POP etc. without the applications being rewritten.G  OpenVMS engineering is feeding back the changes to the respective open $ source teams for these two projects.  H The IPSEC and SSH EAKs will be available for TCP/IP services for OpenVMSC 5.3, the currently shipping version.  Long term plans is that these K integrate into the main product offering probably tied to the next release.f   - Leot --
 Leo Demers "Are we having fun yet?"  OpenVMS Security Product Manager  : "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message- news:ATmZqQj1A+9I@eisner.encompasserve.org...rB > Current versions of TCP/IP Services for OpenVMS seem to have theE > IPV6 support available at the flip of a parameter (he says, without1; > actually trying the steps outlined in the documentation).s >u > But what about IPSEC ? >RJ > Can anyone share any information (with probability factors :-) regardingL > when there might be an accompanying IPSEC implementation to go with TCP/IP > Services for OpenVMS ? >f
 > ===========  >sH > No, I am not interested in SSH, etc. at this time.  The customer wants* > IPSEC, and the customer is always right.   ------------------------------  % Date: Wed, 26 Jun 2002 20:34:06 -0500C. From: Lyndon Bartels <lbartels@pressenter.com>5 Subject: Re: My conversation with Linus about VMS ...h. Message-ID: <3D1A253E.51998369@pressenter.com>  H It's been my experience, it seems that many people are biggotted towardsA whatever operating system they "grew up on". Same seems to go foroD vehicles (Ford, versus Chevy, versus Dodge, versus whatever.) PeopleH build an emotional bond with it, and there's nothing that can be said or done to disuade them.   H I remember I posted a thread about "you must learn to think in Russian."  A In it I said that people have to adjust their thinking to what OSbE they're working on. Not try to make one OS behave like some other OS./C And be willing to let go of preconceived ideas. If you're not trulydE ready to except the good of others, and the negatives of your own....t@ Then you're not ready for an intelligent, unemotional, unbiased, objective comparison.a  D VMS has it's strengths, and weaknesses. As does any other OS anybodyG would care to mention. All of us can come up with examples. Here's one:e  @ I was talking to one of my co-workers the other day as they wereH rebuilding the system disk because the motherboard had died and they had# to move the info to another system.e  G I said that no matter what, as long as it's alpha, I can take my systemNG disk and move it from one box to another, and it'll work. I may have too; retune, but I can get a basic OS running with no changes...   7 The person's response.... "Wow,  that's *REALLY* nice."o  G Of course, VMS doesn't have a mail command named after the programmer'sn dog either.l   Just my 2 cents.   Lyndon     -- aG My opinions are mine and mine alone. They seldom align with those of myr	 employer.n    H The only good thing about putting the cart before the horse is you don't have to look at the horse's butt.   ------------------------------  % Date: Thu, 27 Jun 2002 01:16:39 -0400n- From: JF Mezei <jfmezei.spamnot@videotron.ca>-5 Subject: Re: My conversation with Linus about VMS ...J, Message-ID: <3D1A9FB7.E5DC497A@videotron.ca>   Lyndon Bartels wrote: I > Of course, VMS doesn't have a mail command named after the programmer's 
 > dog either.o  O How do you know that no VMS engineer named his dog "mail" or "all-in-1" ???????    ------------------------------  % Date: Thu, 27 Jun 2002 07:43:12 +0200n' From: Brass Christof <welcome@spam.not>o5 Subject: Re: My conversation with Linus about VMS ...s( Message-ID: <3D1AA5EF.AC8B80D6@spam.not>   Lyndon Bartels wrote:  > J > It's been my experience, it seems that many people are biggotted towardsC > whatever operating system they "grew up on". Same seems to go for F > vehicles (Ford, versus Chevy, versus Dodge, versus whatever.) PeopleJ > build an emotional bond with it, and there's nothing that can be said or > done to disuade them.m  @ This is not my personal experience. VMS was my fourth OS and it  *convinced* me.m  J > I remember I posted a thread about "you must learn to think in Russian." > C > In it I said that people have to adjust their thinking to what OSoG > they're working on. Not try to make one OS behave like some other OS. E > And be willing to let go of preconceived ideas. If you're not truly G > ready to except the good of others, and the negatives of your own.... B > Then you're not ready for an intelligent, unemotional, unbiased, > objective comparison.o > F > VMS has it's strengths, and weaknesses. As does any other OS anybodyI > would care to mention. All of us can come up with examples. Here's one:2   Anything goes?  G Boy, that's too easy. Try VMS for a moment and forget UNIX - you don't CA need it, you won't need it anymore and you won't like it anymore.l  B > I was talking to one of my co-workers the other day as they wereJ > rebuilding the system disk because the motherboard had died and they had% > to move the info to another system.y > I > I said that no matter what, as long as it's alpha, I can take my systemnI > disk and move it from one box to another, and it'll work. I may have toa= > retune, but I can get a basic OS running with no changes...e > 9 > The person's response.... "Wow,  that's *REALLY* nice."   " Isn't that an objective criterium?  I > Of course, VMS doesn't have a mail command named after the programmer's,
 > dog either.o   -- m? According to the Quality Assurance Institute C/C++/ObjC, PERL,  @ UNIX (incl. Linux) and Windows/XY are regarded as harmful. Java 0 is slow and the class library is badly designed.7 moc dot slupofni at ssarb - please reverse the sequencea   ------------------------------   Date: 26 Jun 2002 21:08:28 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)E Subject: Re: NSA: Security in current mainstream operating systems vst* Message-ID: <afdagc$1ct$2@web1.cup.hp.com>  c In article <LEnBUnAlzQ8B@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:rn :In article <9059bf6b.0206191158.755b208b@posting.google.com>, jodonnell@hrblock.com (Jason O'Donnell) writes: :> Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> wrote in message news:<01KJ4CII230O96WTPR@sysdev.deutsche-boerse.com>...t/ :>> > d|i|g|i|t|a|l had a bolt-on called SEVMS.q :>> >e? :>> > Properly configured, it moved things up to the "B" level.- :>> >i> :>> > One of the many things that HP ought to resurrect, IMHO.     Please elaborate.e    F :>> I think Hoff mentioned here a while back that VERY few folks were < :>> interested in buying this.  Lack of marketing?  Maybe.    9   Few people need and even fewer want mandatory security.   D :>> On the other hand, how many folks need SEVMS instead of VMS and # :>> are willing to pay the premium?i    J   SEVMS provides NCSC Class B1 security.  No one really wants to use this J   level of security, even the folks that are told to, want to and/or have L   to use it.  Why?  Because Class B1 security is deliberately an impediment L   to passing around any information without particular thought, an activity I   that most folks are quite accustomed to doing.  This includes draconian I   limits on copying disk files around, on making tapes, on sending MAIL, gI   etc.  A correctly configured NCSC Class B1 system means that no single  I   user can alter the protections on files or other objects, and it means sH   that it is very difficult to reduce the classification of information F   on a system either accidently or through nefarious activity.  And asJ   mentioned earlier, this security also means that importing or exporting I   information to/from the Class B1 system via removable media or via mail A   or otherwise is very deliberately a fully privileged operation.r  H   If you really want mandatory security and you want to manage a system H   and you want to train your users on a system that provides NCSC Class H   B1 equivalence (and/or equivalence with the higher-security levels of H   the common criteria security model, for instance) OpenVMS Engineering G   can potentially provide something for you.  For those folks that are uG   interested in this security, contact me off-line and I can pass your 'D   request along to the OpenVMS Engineering security product manager.  H :> It is my understanding that the DOD COE version 7.2-???? would be the :> same thing.  F   DII COE is quite different from NCSC Class B1 security.  DII COE is G   at its core an operating system interface specification, and less of -C   a security specification.  But yes, there are definitely security@*   components to the DII COE specification.  F   I would expect that DII COE systems would operate "system high" whenE   used in a high-security environment -- NCSC Class B1 and other suchcF   multi-level security systems can be used here, but various customersD   will also choose to use multiple "system high" systems rather than   fewer multi-level systems.  > :If you mean "technically equivalent to SEVMS", you are wrong.  2   Correct.  DII COE differs from SEVMS.  Markedly.  < :If you mean "just as popular as SEVMS", you might be wrong.  G   SEVMS and DII COE can have overlapping -- but different -- audiences. F   Various folks here I expect are interested in at least some portionsG   of the features that are provided within operating systems supportingPG   the DII COE standards.  Comparatively fewer folks want NCSC Class B1.a  G :> It is also my understanding that the plan is to merge those securityo* :> enhancements back into mainstream OVMS.  E   Correct.  These enhancements are for support of such constructs as iC   the UID/GID security mechanisms seen on UNIX platforms; these arelG   part of DII COE.  Some of these enhancements are integrated back intotF   OpenVMS in V7.3-1, other integrations will follow in later releases.  G :I don't know what antecedent you intended for "security enhancements",-5 :but I do not feel it applies to the DII-COE support.7  I   NCSC Class B1 security is largely inapplicable here; few folks want or aI   need it.  Few folks outside the security community know what mandatory tF   access controls (non-discretionary) security really means, and fewerF   folks have used such an environment.  (You can't even send MAIL to a+   lower-classification user, for instance.)-  I   That said, folks at the US National Security Agency (NSA) mentioned in  G   the original subject line, for instance, likely do know about and aregG   likely quite familiar with non-discretionary security.  (I would not oE   be surprised to learn that NSA has multi-level security and varioust)   "system high" security systems in use.)   H   The vast majority of folks are appropriately served with discretionaryI   security as described in NCSC Class C2, and if you want to know how to wI   set up OpenVMS security to provide the equivalent of NCSC Class C2 (or,vI   on specific and evaluated OpenVMS releases, to provide actual evaluatedr:   NCSC Class C2 security), please see the security manual.      N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   Date: 26 Jun 2002 21:38:44 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)E Subject: Re: NSA: Security in current mainstream operating systems vs-0 Message-ID: <afdc94$e6e$1@pegasus.csx.cam.ac.uk>  * In article <afdagc$1ct$2@web1.cup.hp.com>,3 Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> wrote:ud >In article <LEnBUnAlzQ8B@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: >oG >:>> I think Hoff mentioned here a while back that VERY few folks were o= >:>> interested in buying this.  Lack of marketing?  Maybe.  l >n: >  Few people need and even fewer want mandatory security.  > Most serious sites want, and all serious sites need, mandatory= security.  Few people need and even fewer want military-style 	 security.i  D The point is that traditional military security is about informationA leakage first and other aspects secondarily.  Commercial and eveno= academic security is about data integrity first, availabilitye% second, and information leakage last.      Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679t   ------------------------------  % Date: Wed, 26 Jun 2002 15:45:17 -0400 ( From: David Froble <davef@tsoft-inc.com> Subject: Re: Open Letter to HP, Message-ID: <3D1A19CD.7080001@tsoft-inc.com>   John Smith wrote:p  B > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message. > news:m1kS8.30$xi6.427156@news.cpqcorp.net... >  >>J >>System platform vendors will have to differentiate on more than just the >> > CPUa > K >>chip.  Price is obviously one aspect.  But in the server space especiallyeL >>there are many, many ways to add value.  Nor is performance purely the CPUA >>chip.  The core logic chipset also will determine memory and IO  >> > performance. >  > D > Sounds to me like we are coming full circle, only this time with aN > low-volume, pricey IA-64 vs. a low-volume, pricey Alpha. At least with Alpha0 > we had confidence that the chip would perform.    L Same old mistake, all over again.  But I'm not talking about the mistake of + killing Alpha.  It's a much bigger mistake.h  O DEC: We want the margins, so we won't make and sell the best low end system we pM can at competitive prices, and we'll force everyone to buy our high end high uQ margin systems.  The cost of a cluster license will be kept high enough that low t$ end clusters just aren't reasonable.  : Wrong, if you won't do what's possible, someone else will!  O HP/Compaq: We'll kill Alpha and eceryone will HAVE to buy the IA-64 systems we  
 want them to.e  N Wrong, Alpha and others proved that there's better, and if you don't let them / build it, they'll go elsewhere (AMD) and do so.s  P Intel's greed pulled them into this morass, but, when they see where things are 6 going, look for them to jump ship and look out for #1.   Dave   ------------------------------   Date: 26 Jun 2002 20:30:11 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: Open Letter to HP0 Message-ID: <afd88j$auj$1@pegasus.csx.cam.ac.uk>  , In article <3D19F66F.7B72731D@videotron.ca>,/ JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:e >Nick Maclaren wrote:EA >> I would expect that 95% of the IA-64 port work could be reusedhB >> if the target were changed to any other design, whether x86-64,. >> SPARC, PA-RISC, POWER4, MIPS or even ARM.   >eO >I am not so sure about that. Consider Tandem that needs lockstep. I wonder how(O >enthousiastic Tandem ISVs are with regards to the port to IA64. Until they getoL >functional Tandem IA64 machines available to ISVs, not much native softwareM >could be written for it. So they are lucky in the sense that ISVs won't haveVN >wasted much money porting their tandem software IF HP decides to do the right2 >thing and abandon IA64 a few years down the road.   All right - drop ARM :-)  D All of the others are designed for SMP at least as much as IA-64 is.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679n   ------------------------------   Date: 26 Jun 2002 20:40:17 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: Open Letter to HP0 Message-ID: <afd8rh$bd5$1@pegasus.csx.cam.ac.uk>  , In article <3D19FCAF.5EBE9D38@videotron.ca>,/ JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:l >Nick Maclaren wrote:rB >> over doubled their software committments.  There is no way thatC >> HP has the resources to take over IA-64 if Intel and the rest ofi >> the industry drops it.O >SK >My fear is that the rest of the industry drops it (or never adopts it) andsJ >Intel and HP are stuck with it. Then, IA64 will be just as proprietary asK >Alpha and then the same logic used to justify the murder of Alpha could bea >used for IA64.t  D Yes, except that the arguments might have more of a technical basis.E IA-64 is not going to be a cheap architecture to develop for, becausew of its complexity.  M >In the end, wouldn't it be interesting if VMS is ported to a 64bit 8086 oncen< >HP realises IA64 is a proprietary dud that won't catch on ? >lN >Wouldn't it be the biggest irony if even Tandem migrated to a 64 bit 8086, anI >architecture that started off as 16 bit on 8 bit bus as a glorified gamen
 >controller ?s   Yes, indeed.  L >You have to give Intel recognition for the fact that they were able to takeM >the 8086 and over the course of perhaps 15 years, turn it into a respectableh- >CPU, fast enough to make marketing claims ofuL >the fastest CPU in the world. (granted they got "inspiration" from Alpha at2 >that time, so the work isn't all "Intel inside").  ! Yes.  Credit where credit is due.a  N >The big question now is where will Intel get the inspiration to give IA64 theL >same type of boost that Alpha gave to the 8086/Pentium. How much of Alpha's >inspiration applies to EPIC ? >sN >If very few of the alpha knowledge and technologies apply to IA64, then IntelL >will just have paid to have Alpha murdered (no longer a competitor) without- >reaping much benefits from its technologies.e  A I doubt that statement is fair.  I don't think that Intel did payc> to have the Alpha murdered.  I think that Capellas (and I mean? Capellas, not Compaq) said to Intel "If I murder the Alpha, how(? much will you give me for parts of the corpse?"  Intel were not ? interested in the demise of the Alpha (no competition) but werer! interested in the people and IPR.b  J >On the other hand, since the 8086 has already adopted Alpha technologies,O >isbn't it more likely that the Alpha knowledge and engineers might be far more H >productive incorporating the lastest alpha knowledge/idea into the 8086 >instead of IA64 ? >fN >If Intel decides to produce a 64 bit 8086 to compete against Hammer, wouldn'tG >it be logical for Intel to put the ex-Digit engineers on that project,eK >complete with all the alpha IP that was gained when Compaq donated Alpha's  >remains to Intel ?  >lN >I think it is more likely to see "Alpha inside" on the 8086 than on the IA64.  F Perhaps.  I have my doubts, though, and it is not what my sources tell me is going on.e  C >> Intel has been trying to outspend and outprice AMD over the pastt# >> few years, and has got nowhere. s >nK >Intel is very aware of its near monopoly status. They need AMD to be largehL >enough to keep the FTC away. If IA64 were to become wildly succesful, IntelI >may have monopoly problems if it remains the only one making IA64 chips..  C That didn't worry it in 1994.  With George Bush in the White House,m! they have less to fear than then.e       Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679r   ------------------------------  # Date: Thu, 27 Jun 2002 05:18:59 GMT:* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Open Letter to HPB Message-ID: <7fxS8.143551$_j6.7975180@bin3.nnrp.aus1.giganews.com>  5 "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message,* news:afd88j$auj$1@pegasus.csx.cam.ac.uk.... > In article <3D19F66F.7B72731D@videotron.ca>,1 > JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:" > >Nick Maclaren wrote:-C > >> I would expect that 95% of the IA-64 port work could be reused D > >> if the target were changed to any other design, whether x86-64,. > >> SPARC, PA-RISC, POWER4, MIPS or even ARM. > >BF > >I am not so sure about that. Consider Tandem that needs lockstep. I
 wonder howH > >enthousiastic Tandem ISVs are with regards to the port to IA64. Until they getE > >functional Tandem IA64 machines available to ISVs, not much nativee softwareJ > >could be written for it. So they are lucky in the sense that ISVs won't haveJ > >wasted much money porting their tandem software IF HP decides to do the rightf4 > >thing and abandon IA64 a few years down the road. >e > All right - drop ARM :-) >nF > All of the others are designed for SMP at least as much as IA-64 is.  G That's true for the other platforms, but not for Tandem (which requiresvK special lock-step operation between two coupled processors that both ItanicyI and Alpha had to be enhanced to provide) - which seemed to be JF's point.f   - bill   ------------------------------  % Date: Wed, 26 Jun 2002 20:16:32 -0500 . From: Lyndon Bartels <lbartels@pressenter.com>$ Subject: Quorum discussion/questions. Message-ID: <3D1A2120.2E8AE1F0@pressenter.com>  D I have some questions about possibly changing my quorum config on my cluster.   Here's the current config:  ' Two ES40s (currently v7.2-1, soon v7.3)n- The system disk and quroum disk are CI based.   D Both ES40s are voting members. So with ES40s and Qdisk, I have three expected votes.s  H I'm probably going to be adding an ES45 (after v7.3) that will also be a voting member.  - The way I see it I have two possible options:i  G 1. I can remove the quorom disk from the config, and leave the expectedr votes at three (3).a  E 2. I can retain the quorum disk, add the ES45 as a voting member, ande6 increase the expected votes from three (3) to four (4)      E With these two possibilities... Could somebody care to comment on thevG positives, negatives, gotchas, or even "You've gotta be nuts!" of thesec approaches?e    H What about in short term...? Would it be good/bad/indifferent to add theG ES45 as a voting member (and have 4 votes) when the other two ES40s aredH still configured for three (3)? Then, after a time, change the config onA the existing ES40s, to bring the votes and/or qdisk config to ther correct config.a     Thanks in advance,   Lyndon   -- RG My opinions are mine and mine alone. They seldom align with those of my 3 employer. And even if they did, it wouldn't matter.l    H The only good thing about putting the cart before the horse is you don't have to look at the horse's butt.   ------------------------------    Date: 26 Jun 2002 21:59:54 -0600+ From: young_r@encompasserve.org (Rob Young)e( Subject: Re: Quorum discussion/questions3 Message-ID: <JX6gsNZbDdpc@eisner.encompasserve.org>>  _ In article <3D1A2120.2E8AE1F0@pressenter.com>, Lyndon Bartels <lbartels@pressenter.com> writes:uF > I have some questions about possibly changing my quorum config on my
 > cluster. >  > Here's the current config: > ) > Two ES40s (currently v7.2-1, soon v7.3)k/ > The system disk and quroum disk are CI based.i > F > Both ES40s are voting members. So with ES40s and Qdisk, I have three > expected votes.i > J > I'm probably going to be adding an ES45 (after v7.3) that will also be a > voting member. > / > The way I see it I have two possible options:s > I > 1. I can remove the quorom disk from the config, and leave the expected  > votes at three (3).t > G > 2. I can retain the quorum disk, add the ES45 as a voting member, and 8 > increase the expected votes from three (3) to four (4) >  >  > G > With these two possibilities... Could somebody care to comment on the I > positives, negatives, gotchas, or even "You've gotta be nuts!" of theset
 > approaches?g >   ; 	Eliminate the quorum disk.  Set EV=3. It does make cluster A 	transitions quick as a bunny.  Since you are on CI, nice privaterA 	network there.  Also, you can bring up one node at a time.. here  	is an old trick:n  Z http://groups.google.com/groups?selm=n06s81AfYsaF%40eisner.encompasserve.org&output=gplain  A 	I spent a lot of time before I realized the math won't make muchn? 	difference.  As Jan mentioned, if you have more than 2 nodes am? 	Quorum disk makes little sense.  As he mentioned, "what is thea@ 	scenario?  First one node crashes and then another?"  Odds are > 	very high what caused the other two to go down will drag downC 	the third (probably empirical evidence to support that somewhere).   = 	The trick of course is getting started.. a quorum disk helpsdB 	a great deal there and prevents you from screwing something major: 	up and as mentioned, you can trick things up.. by jackingC 	QDSKVOTES to a number to get it rolling with Expected Votes a safe 	 	setting.e  7 	But here is arguably a better way I learned at a site.m  + 	1)  All nodes except satellites get 1 vote?D 	2)  No quorom disk, not needed!  Helps speed the transitions up for 		one thing!3 	3)  Expected Votes = all voting nodes totalled up.e  @ 	Working with a cluster with 6 nodes, we would on the FIRST node	 	to boot:   B 	>>> boot -fl 1,N  $n$DGA|DUA.a.b.c.d      ! Alpha booting SYSBOOT 	SYSBOOT>  SET WRITESYSPARAMS 0  	SYSBOOT>  SET EXPECTED_VOTES 1  	SYSBOOT>  CONTINUE    	Where N = that node's root.  F 	Since EV = 1, this node comes up.  Let it finish mounting or startingC 	up all the way... I definitely let all disks mount before startingm 	another node.  $ 	On the next or SECOND node to boot:  B 	>>> boot -fl 1,O  $n$DGA|DUA.a.b.c.d      ! Alpha booting SYSBOOT 	SYSBOOT>  SET WRITESYSPARAMS 0SB 	SYSBOOT>  SET EXPECTED_VOTES 2    <=====  Two ... it must see the% 						other node or it won't come up.  						Remember, all these nodes  						"normal" EV is 6.  	SYSBOOT>  CONTINUEr  # 	On the next or THIRD node to boot:   B 	>>> boot -fl 1,P  $n$DGA|DUA.a.b.c.d      ! Alpha booting SYSBOOT 	SYSBOOT>  SET WRITESYSPARAMS 0p6 	SYSBOOT>  SET EXPECTED_VOTES 3	<=====  See a pattern? 	SYSBOOT>  CONTINUEt    = 	etc. until all nodes are up.  Then of course double check to @ 	make sure you didn't forget to type WRITESYSPARAMS or something 	else equally bizarre:  
 	$ mcr sysmane 	SYSMAN> SET E/CC 	SYSMAN> PARAM SHOW EXPECTED_VOTES       !  Should be 6 if 6 voters A 	SYSMAN> EXIT   ! If incorrect, set and then write active/currenti   	More on EXPECTED_VOTES here:r  L http://www.rcnp.osaka-u.ac.jp/Divisions/CN/computer/vms/faq/vms_faq_0070.txt  ; 	So.. what does this do for you?  It gets you away from the = 	Quorum Disk addiction.  One of the first things I did was tos? 	kick the Quorum Disk out of a cluster that had 7 or 8 members.kB 	They were amazed at how fast it came up after fiddling with otherE 	things and booting the Quorum Disk.  "lost contact with Quorum Disk,cB 	regained contact, continuing."  I gained gray and lost other hair  	reading those loopy messages!!! ---o   > J > What about in short term...? Would it be good/bad/indifferent to add theI > ES45 as a voting member (and have 4 votes) when the other two ES40s areoJ > still configured for three (3)? Then, after a time, change the config onC > the existing ES40s, to bring the votes and/or qdisk config to the  > correct config.r >   > 	I'm assuming you aren't reconfiguring the cluster as you have4 	to remove QDISK from SYSGEN and it isn't dynamic.    C 	Not sure what you are asking.  I would configure the ES45 like thelD 	others and adjust expected votes across the cluster.  When you have? 	downtime go back and remove the quorum disk.  See the FAQ linkuD 	above for more on EXPECTED_VOTES and VOTES and cluster transitions, 	quorum disk, etc.   				Rob    ------------------------------  % Date: Wed, 26 Jun 2002 23:00:43 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com>n( Subject: RE: Quorum discussion/questionsT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4026607CC@kaoexc01.americas.cpqcorp.net>   Lyndon,-  D I recommend option 1 - when ES45 is added, plan to get rid of quorum: disk (timing depends on when you can do a cluster reboot).  E Quorum disks add some complications (e.g. can not shadow quorum disk,u> adds additional IO's) that are not needed in a 3 node cluster.  
 Kerry Main Senior Consultanto Hewlett-Packard Canada! Consulting & Integration ServicesK Voice: 613-592-4660( Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----8 From: Lyndon Bartels [mailto:lbartels@pressenter.com]=20 Sent: June 26, 2002 9:17 PM  To: Info-VAX@Mvb.Saic.Come$ Subject: Quorum discussion/questions    D I have some questions about possibly changing my quorum config on my cluster.   Here's the current config:  ' Two ES40s (currently v7.2-1, soon v7.3)a- The system disk and quroum disk are CI based.a  D Both ES40s are voting members. So with ES40s and Qdisk, I have three expected votes.t  H I'm probably going to be adding an ES45 (after v7.3) that will also be a voting member.  - The way I see it I have two possible options:   G 1. I can remove the quorom disk from the config, and leave the expectedn votes at three (3).c  E 2. I can retain the quorum disk, add the ES45 as a voting member, and-6 increase the expected votes from three (3) to four (4)      E With these two possibilities... Could somebody care to comment on thePG positives, negatives, gotchas, or even "You've gotta be nuts!" of these  approaches?r    H What about in short term...? Would it be good/bad/indifferent to add theG ES45 as a voting member (and have 4 votes) when the other two ES40s areeH still configured for three (3)? Then, after a time, change the config onA the existing ES40s, to bring the votes and/or qdisk config to they correct config.d     Thanks in advance,   Lyndon   --=20 G My opinions are mine and mine alone. They seldom align with those of my 3 employer. And even if they did, it wouldn't matter.n    H The only good thing about putting the cart before the horse is you don't! have to look at the horse's butt.p   ------------------------------  # Date: Thu, 27 Jun 2002 04:29:30 GMTe0 From: prune@ZAnkh-Morpork.mv.com (Paul Winalski)( Subject: Re: Quorum discussion/questions9 Message-ID: <3d1a9449.1570446162@proxy.news.easynews.com>e  A The concept of a quorum disk was invented for the special case ofdA two-node clusters.  In such a configuration, if the two CPUs loseT: communication with each other, there has to be some way ofB breaking the tie and deciding which continues to operate and whichA suspends operation waiting for communication to be reestablished. > So another resource, a disk to which both CPUs have access, is0 given a third, tie-breaking vote in the cluster.  < With 3 or more CPUs, you don't need a quorum disk and you're  probably better off without one.  2 On Wed, 26 Jun 2002 20:16:32 -0500, Lyndon Bartels  <lbartels@pressenter.com> wrote:  E >I have some questions about possibly changing my quorum config on my-	 >cluster.  >e >Here's the current config:r > ( >Two ES40s (currently v7.2-1, soon v7.3). >The system disk and quroum disk are CI based. >@E >Both ES40s are voting members. So with ES40s and Qdisk, I have three  >expected votes. >aI >I'm probably going to be adding an ES45 (after v7.3) that will also be a9 >voting member.o >w. >The way I see it I have two possible options: > H >1. I can remove the quorom disk from the config, and leave the expected >votes at three (3). > F >2. I can retain the quorum disk, add the ES45 as a voting member, and7 >increase the expected votes from three (3) to four (4)o >6 >U >lF >With these two possibilities... Could somebody care to comment on theH >positives, negatives, gotchas, or even "You've gotta be nuts!" of these >approaches? >h >VI >What about in short term...? Would it be good/bad/indifferent to add therH >ES45 as a voting member (and have 4 votes) when the other two ES40s areI >still configured for three (3)? Then, after a time, change the config on-B >the existing ES40s, to bring the votes and/or qdisk config to the >correct config. >e >  >Thanks in advance,, >m >Lyndon2 >H >-- H >My opinions are mine and mine alone. They seldom align with those of my4 >employer. And even if they did, it wouldn't matter. >0 >0I >The only good thing about putting the cart before the horse is you don'tt >haveP >to look at the horse's butt.a  
 ---------- Remove 'Z' to reply by email.B   ------------------------------  % Date: Wed, 26 Jun 2002 18:55:38 +0100cU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com> < Subject: Re: Reuters test - Itanium II blows away Sparky III0 Message-ID: <afcv51$h0t$1@new-usenet.uk.sun.com>   JF Mezei wrote:t  * > Andrew Harrison SUNUK Consultancy wrote: > G >>Its replacement was WildFire, it is slower, it has less I/O bandwidth E >>supports less CPU's less memory, has longer local and remote memorydI >>latency and a lower bisectional (and local now most are NUMA) bandwidth % >>and worse RAS than its competition.t >> > N > Had wildwires been launched on time (under Digital, before merger), wouldn'tO > they have been much more competitive with their peers of the day ? Delaying a6O > system/chip while your competitors are still advancing theirs will cause thatnG > delay to make your systems appear slower than originally anticipated.d >     ? Of course being late didn't help but its worth remembering thati; the SGI Origin 2000 came out well before even the origionala> WildFire target dates broadcasted by Mr prognosticator himselfA Rob the seer Young. WildFire was marginally worse than the Origin @ 2000 on memory latency. And despite the white papers the average9 latency of the WildFire is for most workloads longer thans= something like a Sun E10000 which again predated by some time   WildFires origional target data.    M > And as far as Digital having adverttised Alpha as the fastest system in the O > world, this claim was not credible because they never sued Apple or Intel for M > making claims that their own systems were the fastest in the world. BecauselA > everyone is allowed to make that claim, the claim is worthless.t >     ; Fastest Server, a bit more specific and not ever justified.s   Regards  Andrew Harrisoni   ------------------------------  # Date: Wed, 26 Jun 2002 18:58:28 GMTs* From: "Bill Todd" <billtodd@metrocast.net>< Subject: Re: Reuters test - Itanium II blows away Sparky IIIB Message-ID: <o9oS8.404260$Gs.30146537@bin5.nnrp.aus1.giganews.com>  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message, news:ekjS8.23$jb6.213061@news.cpqcorp.net...   ...y  J > But it doesn't suprise me to see you attempt to throw the FUD, after all younL > have wagered a significant amount of what reputation you might have on the- > proposition that IA64 will never be viable.   K Wrong yet again, Fred.  The point I have made, with unwavering consistency, J is that IA64 would never have had a chance in hell of competing with AlphaG on a performance or cost/performance basis had development continued on  both.i  L Ancillary points have highlighted the gall and blatant lies spread by CompaqL management in attempting to convince people otherwise, plus their unilateralJ trashing of unequivocal, repeated, public, and *very* specific commitmentsG made right up to the day they broke them without any hint of apology orI= shame.  The people you work for (several levels up) are scum.o  F But as for Itanic's viability, I've never questioned Intel's potentialK ability to muscle its way into the market with a mediocre product, and have F admitted on multiple occasions that while Merced really does merit theJ characterization 'unviable' McKinley and its shrunk clones rise to a levelB of mediocrity which may allow them to survive despite their markedK inferiority until 2005, when the transplanted EV8 team may or may not start+I pulling rabbits out of their hats to rescue its misbegotten architecture.   F Of course, might does not always prevail, and the fact that POWER4 andK Hammer - and on the low end IA32, and at least for a while EV7 - will still8K be around to make it clear that Itanic offers best-of-breed capabilities iniH no market segment whatsoever may yet cause it to flounder into the graveI that even HP's engineers recognized it belonged in years ago.  We'll justo have to wait and see.w  K Perhaps you'd be better off sticking to technical areas where you (at least < I would hope) have more of a clue what you're talking about.   - bill   ------------------------------  # Date: Wed, 26 Jun 2002 19:34:26 GMTu5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>h< Subject: Re: Reuters test - Itanium II blows away Sparky III2 Message-ID: <6HoS8.49$Bn6.663686@news.cpqcorp.net>  H Bill read your own posts.  Ignoring Alpha (which is the real bee in yourH bonnet), you have consistantly predicted the failure of IA64.  But as isJ highlighted in your frothing at the mouth reply, the core of your issue isD that you want IA64 (and in fact VMS)  to fail as validation that the' retirement of Alpha was a bad decision.e  L Should IA64 not fail, and VMS to successfuly move forward to an IA64 base, IB expect fully that you will be the last to acknowledge your lack of infallibility.  K So keep shouting at the top of your lungs, and attack anyone who disagrees.wL The sorry thing is that it's driven you into the loving embrace of Andy-Boy.  D So why don't you stick to ruminations about file system performance.   _Fred.   Bill Todd wrote in message ... >tA >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message - >news:ekjS8.23$jb6.213061@news.cpqcorp.net...f >o >... >sK >> But it doesn't suprise me to see you attempt to throw the FUD, after alln >youI >> have wagered a significant amount of what reputation you might have on. thei. >> proposition that IA64 will never be viable. > L >Wrong yet again, Fred.  The point I have made, with unwavering consistency,K >is that IA64 would never have had a chance in hell of competing with AlphamH >on a performance or cost/performance basis had development continued on >both. > F >Ancillary points have highlighted the gall and blatant lies spread by CompaqB >management in attempting to convince people otherwise, plus their
 unilateralK >trashing of unequivocal, repeated, public, and *very* specific commitmentsoH >made right up to the day they broke them without any hint of apology or> >shame.  The people you work for (several levels up) are scum. > G >But as for Itanic's viability, I've never questioned Intel's potentialoL >ability to muscle its way into the market with a mediocre product, and haveG >admitted on multiple occasions that while Merced really does merit the K >characterization 'unviable' McKinley and its shrunk clones rise to a level.C >of mediocrity which may allow them to survive despite their marked L >inferiority until 2005, when the transplanted EV8 team may or may not startJ >pulling rabbits out of their hats to rescue its misbegotten architecture. >-G >Of course, might does not always prevail, and the fact that POWER4 andvL >Hammer - and on the low end IA32, and at least for a while EV7 - will stillL >be around to make it clear that Itanic offers best-of-breed capabilities inI >no market segment whatsoever may yet cause it to flounder into the graveuJ >that even HP's engineers recognized it belonged in years ago.  We'll just >have to wait and see. > L >Perhaps you'd be better off sticking to technical areas where you (at least= >I would hope) have more of a clue what you're talking about.E >s >- billk >  >e >r   ------------------------------  % Date: Wed, 26 Jun 2002 15:45:08 -0400r- From: JF Mezei <jfmezei.spamnot@videotron.ca> < Subject: Re: Reuters test - Itanium II blows away Sparky III, Message-ID: <3D1A19B9.3099075B@videotron.ca>   Bill Todd wrote:H > Of course, might does not always prevail, and the fact that POWER4 andM > Hammer - and on the low end IA32, and at least for a while EV7 - will still M > be around to make it clear that Itanic offers best-of-breed capabilities incJ > no market segment whatsoever may yet cause it to flounder into the grave  K As long as Wall Street Casino Analysts don't question Intel's IA64 spending M with no revenus, then Intel will continue to have much staying power and willr continue to improve the chip.y  L The Analysts only seem interested in volumes of chips sold, not R&D spending or large investments by Intel.  L Where IA64 may start to come into play is when HP starts to flounder becauseD of its decision to put all its eggs into IA64 and IA64 makes HP less@ competitive and it loses market share and profits never recover.  L Hopefully Carly can really complete the merger very quickly and rebuild fromN there. If the merger drags on, when profits don't improve, analysts will focusN on HP and that would be bad news because the non-performance of IA64 will then be noticed.e  C It is bad enough HP-UX will be a big mess with its move to IA64 ANDv incorporation of Tru64 gadgets.m   ------------------------------  % Date: Wed, 26 Jun 2002 12:42:30 -0700S& From: Greg Cagle <gregc@gregcagle.com>< Subject: Re: Reuters test - Itanium II blows away Sparky III, Message-ID: <3D1A1926.3080309@gregcagle.com>   Bill Todd wrote:  H > Of course, might does not always prevail, and the fact that POWER4 andM > Hammer - and on the low end IA32, and at least for a while EV7 - will stillrM > be around to make it clear that Itanic offers best-of-breed capabilities in>J > no market segment whatsoever may yet cause it to flounder into the graveK > that even HP's engineers recognized it belonged in years ago.  We'll just  > have to wait and see.r  F Do you have a citation about this last point regarding HP's engineers?   -- u
 Greg Cagle gregc at gregcagle dot com   ------------------------------   Date: 26 Jun 2002 20:42:11 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)< Subject: Re: Reuters test - Itanium II blows away Sparky III0 Message-ID: <afd8v3$bec$1@pegasus.csx.cam.ac.uk>  , In article <3D1A19B9.3099075B@videotron.ca>,/ JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:s >Bill Todd wrote:rI >> Of course, might does not always prevail, and the fact that POWER4 and N >> Hammer - and on the low end IA32, and at least for a while EV7 - will stillN >> be around to make it clear that Itanic offers best-of-breed capabilities inK >> no market segment whatsoever may yet cause it to flounder into the graveb >cL >As long as Wall Street Casino Analysts don't question Intel's IA64 spendingN >with no revenus, then Intel will continue to have much staying power and will >continue to improve the chip. >fM >The Analysts only seem interested in volumes of chips sold, not R&D spending  >or large investments by Intel.   > The first cracks appeared a year ago - i.e. the first negative> reports in the Wall Street Journal.  If the McKinley flops, in, any visible way, expect them to take notice.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679o   ------------------------------   Date: 26 Jun 2002 20:44:11 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)< Subject: Re: Reuters test - Itanium II blows away Sparky III0 Message-ID: <afd92r$bmv$1@pegasus.csx.cam.ac.uk>  , In article <3D1A1926.3080309@gregcagle.com>,( Greg Cagle  <gregc@gregcagle.com> wrote: >Bill Todd wrote:  >eI >> Of course, might does not always prevail, and the fact that POWER4 anddN >> Hammer - and on the low end IA32, and at least for a while EV7 - will stillN >> be around to make it clear that Itanic offers best-of-breed capabilities inK >> no market segment whatsoever may yet cause it to flounder into the gravehL >> that even HP's engineers recognized it belonged in years ago.  We'll just >> have to wait and see. >qG >Do you have a citation about this last point regarding HP's engineers?E  @ I do, but am not posting - it was private Email.  I would phrase? it as "SOME of HP's engineers", perhaps even "MOST of ...", but 3 wouldn't go as far as saying just "HP's engineers".R     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679i   ------------------------------  # Date: Wed, 26 Jun 2002 21:03:02 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>d< Subject: Re: Reuters test - Itanium II blows away Sparky III* Message-ID: <a_pS8.3973$Uu2.295@sccrnsc03>  5 "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message6* news:afd8v3$bec$1@pegasus.csx.cam.ac.uk.... > In article <3D1A19B9.3099075B@videotron.ca>,1 > JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:c > >Bill Todd wrote:,K > >> Of course, might does not always prevail, and the fact that POWER4 andoJ > >> Hammer - and on the low end IA32, and at least for a while EV7 - will stille@ > >> be around to make it clear that Itanic offers best-of-breed capabilities inyG > >> no market segment whatsoever may yet cause it to flounder into the. graveh > >sE > >As long as Wall Street Casino Analysts don't question Intel's IA64a spendingK > >with no revenus, then Intel will continue to have much staying power andv will  > >continue to improve the chip. > >hF > >The Analysts only seem interested in volumes of chips sold, not R&D spending! > >or large investments by Intel.t >E@ > The first cracks appeared a year ago - i.e. the first negative@ > reports in the Wall Street Journal.  If the McKinley flops, in. > any visible way, expect them to take notice. >s  K Yep, especially in light of INTC's performance in the stock market over theoJ past three weeks. Ah well, we should have more info on McKinley within the next three weeks.h   ------------------------------  % Date: Wed, 26 Jun 2002 20:01:30 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> < Subject: RE: Reuters test - Itanium II blows away Sparky IIIT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4026607CA@kaoexc01.americas.cpqcorp.net>   Andrew, Andrew ..e  ) >>> Of course being late didn't help ..<<n  + Now, now, remember those in glass houses ..h  @ Yes, the GS Series was late, but remember the original SPARC III9 announcement date with systems up to 1000+ processors?=20-  F Here is the Oct '97 announcement from Sun: (and this is now considered "new" technology from Sun)  A http://www.sun.com/smi/Press/sunflash/9710/sunflash.971006.1.html0B "Sun Unveils Third Generation UltraSPARC-III Microprocessor Family  G Family To Enable 1000+ Processor Systems And Up To 3X Performance Boostt  C SAN JOSE, Calif. -- October 6, 1997 -- Sun Microsystems, Inc. today D unveiled the third generation of the high-performance UltraSPARC(tm)B product line, the 64-bit UltraSPARC-III(tm) microprocessor family.D Initially at 600MHz, the UltraSPARC-III with the VIS(tm) InstructionE Set, is highly scalable enabling systems using up to 1000+ processorso@ while maintaining complete Solaris(tm) operating system (OS) and% application software compatibility. "   F Now, here is a good question for you - when did the SPARC III actually ship ?   :-)s  
 Kerry Main Senior Consultantm Hewlett-Packard Canada! Consulting & Integration Servicesr Voice: 613-592-4660r Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----' From: Andrew Harrison SUNUK Consultancy07 [mailto:andrew_nospam.harrison_remove_this@sun#.com]=20o Sent: June 26, 2002 1:56 PMS To: Info-VAX@Mvb.Saic.Coml< Subject: Re: Reuters test - Itanium II blows away Sparky III         JF Mezei wrote:   * > Andrew Harrison SUNUK Consultancy wrote: >=20J >>Its replacement was WildFire, it is slower, it has less I/O bandwidth=20H >>supports less CPU's less memory, has longer local and remote memory=20B >>latency and a lower bisectional (and local now most are NUMA)=20/ >>bandwidth and worse RAS than its competition.s >> >=20H > Had wildwires been launched on time (under Digital, before merger),=20J > wouldn't they have been much more competitive with their peers of the=20B > day ? Delaying a system/chip while your competitors are still=20G > advancing theirs will cause that delay to make your systems appear=20o% > slower than originally anticipated.  >=20    G Of course being late didn't help but its worth remembering that the SGI,C Origin 2000 came out well before even the origional WildFire targetsB dates broadcasted by Mr prognosticator himself Rob the seer Young.E WildFire was marginally worse than the Origin 2000 on memory latency.oG And despite the white papers the average latency of the WildFire is for-B most workloads longer than something like a Sun E10000 which again6 predated by some time WildFires origional target data.    I > And as far as Digital having adverttised Alpha as the fastest system=20 F > in the world, this claim was not credible because they never sued=20E > Apple or Intel for making claims that their own systems were the=20HJ > fastest in the world. Because everyone is allowed to make that claim,=20 > the claim is worthless.d >=20    ; Fastest Server, a bit more specific and not ever justified.m   Regardsa Andrew Harrison    ------------------------------  % Date: Wed, 26 Jun 2002 20:56:57 -0400i1 From: Michael Austin <maustin@firstdbasource.com>c< Subject: Re: Reuters test - Itanium II blows away Sparky III2 Message-ID: <3D1A62D9.5486EAF9@firstdbasource.com>   "Main, Kerry" wrote: >  > Andrew, Andrew ..m > + > >>> Of course being late didn't help ..<<a > - > Now, now, remember those in glass houses ..  > B > Yes, the GS Series was late, but remember the original SPARC III8 > announcement date with systems up to 1000+ processors? > H > Here is the Oct '97 announcement from Sun: (and this is now considered > "new" technology from Sun) > C > http://www.sun.com/smi/Press/sunflash/9710/sunflash.971006.1.htmltD > "Sun Unveils Third Generation UltraSPARC-III Microprocessor Family > I > Family To Enable 1000+ Processor Systems And Up To 3X Performance Boostr    @ Hmmmm, now that is real funny... 1000+ processors with only a 3X performance boost.   -- t Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163 7 Sr. Consultant            http://www.firstdbasource.comtE                           http://www.firstdbasource.com/donation.html / 704-947-1089 (Office)     704-236-4377 (Mobile)e   ------------------------------  # Date: Thu, 27 Jun 2002 03:59:48 GMT-* From: "Bill Todd" <billtodd@metrocast.net>< Subject: Re: Reuters test - Itanium II blows away Sparky IIIB Message-ID: <U4wS8.142032$_j6.7925645@bin3.nnrp.aus1.giganews.com>  3 "Greg Cagle" <gregc@gregcagle.com> wrote in messagen& news:3D1A1926.3080309@gregcagle.com... > Bill Todd wrote: >tJ > > Of course, might does not always prevail, and the fact that POWER4 andI > > Hammer - and on the low end IA32, and at least for a while EV7 - will  stillwL > > be around to make it clear that Itanic offers best-of-breed capabilities inL > > no market segment whatsoever may yet cause it to flounder into the graveH > > that even HP's engineers recognized it belonged in years ago.  We'll just > > have to wait and see.A >aH > Do you have a citation about this last point regarding HP's engineers?  L Unfortunately, no.  I first encountered the assertion in (I think) comp.archJ quite a while ago, and it has surfaced recently here as well (when I askedC the author, he said he believed he had read it in an HP newsgroup).cI However, since it's an eminently sensible conclusion to have come to, and I since I still have a fair amount of respect for HP engineering, I find itmD entirely credible - though probably should have said '... reportedly recognized ...'.   - bill   ------------------------------  % Date: Wed, 26 Jun 2002 16:02:30 -0400p- From: JF Mezei <jfmezei.spamnot@videotron.ca>t. Subject: RMS : preserving a RAB across $OPEN ?, Message-ID: <3D1A1DCA.D21F3E6B@videotron.ca>  	 Scenario:lC I have multiple streams accessing a file that was opened read-only.n  D A new stream is created but it needs read-write access to that file.  L Can I $CLOSE the file, then $OPEN it with read-write without having to "tear8 down" all the existing RABs and rebuilding  them later ?   I.E. $OPEN (read only) 	$CONNECT with RAB1e 	$GET with RAB1 by key   	$CLOSEk+ 	$OPEN (read-write, same FAB block address)aH 	$GET with RAB1 sequentially (continuing from the previous read by key).  M If I $CONNECT RAB1 back to the FAB after the second $OPEN, does this wipe out'7 the context and current position contained in the RAB ?e  M It would be VERY NICE if I could reopen the file allowing me to add a new rabfL for read write without affecting the existing RABs and whatever they were in! the process of doing at the time.    ------------------------------  # Date: Wed, 26 Jun 2002 20:29:09 GMT: From: danco@pebble.org2 Subject: Re: RMS : preserving a RAB across $OPEN ?- Message-ID: <slrnahka01.du4.danco@pebble.org>p  < In article <3D1A1DCA.D21F3E6B@videotron.ca>, JF Mezei wrote:  O > If I $CONNECT RAB1 back to the FAB after the second $OPEN, does this wipe out 9 > the context and current position contained in the RAB ?t  ? Well, even if it didn't wipe out context in the "external" RAB,eA I doubt the context in the "internal" RAB would be the same after > a close->open.  In real life the record context can be complex@ enough that just saving the RFA of the current record before the? close and doing a FIND by RFA after the open isn't good enough.o? But perhaps might your application be simple enough for that tot
 work for you?c  5 (Have you seen the undocumented SYS$MODIFY trick thatb7 LIB$FIND_IMAGE_SYMBOL uses to position by RFA and start 9 reading the symbol table within an image file in variable. length record access mode?)n   - Dan.   ------------------------------  % Date: Wed, 26 Jun 2002 14:23:33 -0700 + From: "xenman" <xenman@sprynet.nospaam.com> 2 Subject: Re: RMS : preserving a RAB across $OPEN ?2 Message-ID: <afdbd9$620$1@slb2.atl.mindspring.net>  6 While you probably don't need to deallocate the memory8 used by the RABs and FABs, assuming you allocated memory( for them, you should reninitialize them.  6 Based upon the limited information that you provide, I8 would consider opening the file read/write to start with7 but not lock the records when you read them and/or read % them regardless of any existing lock.m  8 JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message& news:3D1A1DCA.D21F3E6B@videotron.ca... > Scenario:cE > I have multiple streams accessing a file that was opened read-only.e >eF > A new stream is created but it needs read-write access to that file. > H > Can I $CLOSE the file, then $OPEN it with read-write without having to "tearn: > down" all the existing RABs and rebuilding  them later ? >t > I.E. $OPEN (read only) > $CONNECT with RAB1 > $GET with RAB1 by keye >r > $CLOSE, > $OPEN (read-write, same FAB block address)I > $GET with RAB1 sequentially (continuing from the previous read by key).a >wK > If I $CONNECT RAB1 back to the FAB after the second $OPEN, does this wipen outt9 > the context and current position contained in the RAB ?h > K > It would be VERY NICE if I could reopen the file allowing me to add a newa rab K > for read write without affecting the existing RABs and whatever they wered in# > the process of doing at the time.b   ------------------------------  % Date: Wed, 26 Jun 2002 16:00:03 -0500 4 From: Arlen Williams <arlen.williams@remove.eds.com> Subject: Re: size of exe- Message-ID: <3D1A2B53.6050603@remove.eds.com>    wing wrote:l   > Hi,h > @ > I have use the same set of sources to compile binaries but the. > binaries compiled are having different size. > G > Is it possible for the same compiler in a machine to compile binaries  > with different size? > ! > The binary that I am using are 0, > Compaq C++ V6.3-020 for OpenVMS Alpha V7.3 >  > Wing >   F If the compiler version, VMS version, source and build procedures are C the same, maybe you are looking at the allocated size and the disk d cluster size is different?   ------------------------------    Date: 26 Jun 2002 13:27:53 -0600+ From: young_r@encompasserve.org (Rob Young)n' Subject: Sun benchmarketeering campaignt3 Message-ID: <Cuz2OHjBRSrQ@eisner.encompasserve.org>o  A         There are several issues here.  Sun in a real sense needstB         to abandon benchmarks altogether and highlight application         availability.l  D         We have learned recently that Sun has essentially abandondedL         TPC-C, abandoning SPEC2000 or in the process thereof.  That decisionJ         appears to be because senior management in part doesn't understandH         how the benchmark works and why it is one of the best benchmarks         there is.n  N         How long before they abandon SPECjbb?  How long before TPC-H suddenly F         isn't of great importance?  What do they do if large customers5         formulate RFPs that require these benchmarks?t  K         Cases in point.  First, David Yen, VP for the processor and networktI         products at Sun, makes the following claims about SPECfp/SPECint:X    2 http://www.eweek.com/article2/0,3959,277705,00.asp  N "In our opinion, many of the processor-oriented benchmarks are being outmoded"O by new chip designs, and therefore don't accurately reflect system performance,t2 Yen said.  [The CPU is part of the system Mr. Yen]  N He cited two popular benchmarks as "misleading," SPECfp and SPECint, which areF used to measure floating point and integer performance, respectively.   L The problem, he said, is that the larger on-die memory caches on some chips,N such as Itanium 2's 3MB cache, skew the results since they can accommodate theJ entire benchmark program, and thus don't have to off-die to access memory, which is unrealistic."   ---a  H         Specint/Specfp are not "misleading", quite revealing actually.  N         Perhaps Mr. Yen isn't very "technical" or doesn't understand "techie"          issues?-  F         Cache can accomadate the entire benchmark program?  Don't have*         to off-die access memory?  Sheesh.I         Really a shame there.  He obviously hasn't a clue about Spec2000.@@         Perhaps someone could shoot the following Mr. Yen's way:  5 http://www.specbench.org/osg/cpu2000/analysis/memory/B  O The SPEC CPU2000 benchmarks are intended to exercise the CPU itself, the memoryWC hierarcy, and the compilers. How much memory do they actually use? l  O The data collected here show that SPEC met its goals for memory footprint: mostcN benchmarks are larger than common cache sizes, many are larger than 100MB, and none are larger than 200MB.   K It is useful to have benchmarks that are larger than common caches, becausenN SPEC would like to differentiate its benchmarks from "toy benchmarks" that are, too easy to run or that simply reflect MHz. J It is useful to keep the benchmarks under 200MB so that the suite leaves aJ reasonable margin on a 256MB machine. The other 56MB are available for theN operating system, graphics system, network daemons, etc, without using 'singleN user mode' on Unix systems, or killing processes on NT systems. (Such measuresA may not be representative of how most people use their systems.) r   ---2  @         Secondly, we read about SPECjbb and how StarCat fares at2         that benchmark in comparison to SuperDome:  2 http://www.eweek.com/article2/0,3959,278481,00.asp  D In the Java application space, the new Superdome scored 594,161 JavaN operations-per-second on the SPECjbb2000 benchmark, a result 75 percent higherM than IBM's 32-way p690 server, code-named Regatta, and 37 percent better thanlE Sun Microsystems Inc.'s 72-way Sun Fire 15K server, known as Starcat.e  H         Perhaps they could trumpet the fact that if you bought a StarCatG         with 104 processors (versus SuperDome's 64) the end-user can doe?         1.4% more jbbs than a SuperDome (602270 versus 594161).            Thirdly...  5 http://www.tpc.org/tpch/results/tpch_perf_results.aspn  2 http://www.eweek.com/article2/0,3959,278481,00.asp  L For example, in testing targeted at measuring data warehousing, the upgradedN Superdome running Oracle 9i Database Release 2 set a world-record one terabyteO benchmark result of 25,805 queries-per-hour, according to HP, a mark that bestssD all single-system or cluster servers on the market at one terabyte.   O         TPC-H at 1000 GB?  HP has better Price/QphH and 37% better performance r/         than StarCat.  25805 QphH versus 18802.e  G         Yeah... you can see Sun's benchmarketeers have a great campaign-L         ahead of them.  Hoping no one notices must be part of that campaign.  #                                 Robs   ------------------------------  % Date: Wed, 26 Jun 2002 18:38:42 +0100cU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>e Subject: Re: TCO study0 Message-ID: <afcu58$gn1$1@new-usenet.uk.sun.com>   Main, Kerry wrote:   > Andrew, Andrew - > J > Now, now - first you ask for industry benchmark data, then I give it and4 > then you state "yeah, but that does not matter .." > H > The reality here is that everyone in this newsgroup realizes benchmarkD > results are a snapshot in time that will always be beat by someone > faster over time.  >     9 Of course they will, but to customers buying your systemsg8 now its what they are capable of now thats important and9 that is where as you know the current GS series drops offt
 the radar.  9 It would be nice to say that there was a time maybee soon : after GS series introduction when this wasn't the case but8 then as you also know without re-writing history this is( also not a subject you want to dig into.  6 Your posting characterises many in this group who seem: to espouse a jam tommorow approach, never mind the current9 boxes/CPU's/Operating System/Marketing campaign there mayo' be something better arround the corner.o  = I on the other hand steer clear of prognostications (BS aboutMB the future) and predicitions about how great the next Sun will be.> Perhaps if you realised that people don't actually buy futures3 because you can't revenue them you would do better.     H > The GS320 systems have very respectable TPC benchmark numbers (not theB > top, but Sun has none) and numerous Customers with very high endI > application requirements who are very happy with the performance levelss > they have.    D No they don't sorry, the GS320's numbers are quite frankly terrible.@ Worse than Fujitsu and more expensive, worse than IBM (P690) andC more expensive, worse than SuperDome and more expensive, almost thee> same as a IBM P680 and more expensive. 4th or 5th (last in the= big SMP stakes) isn't good its terrible. And thats before youA= realise that to get to last you had to do OPS in a box akkkk.r  ; Only a total idiot would describe being last in the current 6 generation of large SMP server numbers as respectable.  6 Just as a question, excluding Sun for a moment you are6 focusing on TPC-C well fine its the best of a terrible8 bunch, so how on the basis of your best benchmark result8 do you justify clasifying the GS320 in the same category- as say the IBM P690 for you TCO "study" ?????l  7 I cannot understand why you keep banging on about TPC-Cd- it only makes the GS320 look more inadequate.,   Regardsg Andrew Harrisony   ------------------------------  # Date: Wed, 26 Jun 2002 17:58:08 GMTr1 From: "Terry C. Shannon" <terryshannon@attbi.com>I Subject: Re: TCO study. Message-ID: <QgnS8.325493$cQ3.18919@sccrnsc01>  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message, news:wbkS8.34$Wi6.433260@news.cpqcorp.net...L > Andrew, as others have pointed out, it seems to be you that seem to switchH > to benchmark dejur if the one you  were touting yesterday is no longerI > looking good today.  From what I can tell, Sun is now discounting Spec,: and0E > TPC-C benchmarks (because you look pretty bad).  They are touting at LINPACKuL > benchmark for Fujitsu (even though the high-end space there is pretty well > Alpha dominated).o > L > Pretty soon, I expect you to come out with a full suite of benchmarks thatI > will only run on Solaris.  Then your world will be a nice tidy package.e  D Umm, isn't that where we were 15 years ago or so with RAMP-C and IBM "Mainframe MIPS"? ;-}    ------------------------------  % Date: Wed, 26 Jun 2002 14:21:08 -0400h1 From: Michael Austin <maustin@firstdbasource.com>e Subject: Re: TCO study2 Message-ID: <3D1A0613.236B6A63@firstdbasource.com>  ( Andrew Harrison SUNUK Consultancy wrote: >  > Michael Austin wrote:o > , > > Andrew Harrison SUNUK Consultancy wrote: > >e > >>Main, Kerry wrote: > >> > >> > >>>Gerard, > >>>o  > >>>Re: TCO Study .. Check out:J > >>>http://www.openvms.compaq.com/openvms/whitepapers/enterprise_tco.html > >>>e > >>>yG > >>Sorry its horribly flawed and you know it, putting the GS320 in the J > >>same class as a bunch of servers that at a minium have 2x its capacity4 > >>is hardly going to generate like for like costs. > >>D > >>Bang the GS320 back into the mid-range section where it belongs,@ > >>re-do the study and hey presto you find that the TCO numbers, > >>don't look any thing like as attractive. > >> > >> > >r > >iL > > So what you are saying is that while the GS320 has half the capacity, itK > > does the same amount of work and has better TCO than Sun with twice ther; > > capacity?  Hmmm. I guess buying Sun is better... NOT!!!  > >2 > >5 > 1 > No by capacity I mean its ability to do usefullc( > work, what else did you think I ment ?  D Let' see: a "mid-range" Alpha GS320 that does the equivilant of yourD "high-end" system and yours is better??? what planet do you live on?  B Give it a rest Andrew.  Sun still cannot do a true cluster, is notE scalable, takes a lot  more boxes to accomplish the equivilant of oner 8400/GS system!   H Every site I have personally seen replace OpenVMS 82/8400/GS Series withC Sun, Not one but many (15-20+) boxes to do the work of one 8-10 CPUeH Alpha. And this makes sense to you. TCO increases exponentially the moreH systems you have because now you need more Systems, Network and DatabaseD Admins to keep those systems running not to mention license fees and+ support contracts for all of those servers.   @ A few of the sites the 82/8400/GS systems may have been a 2 nodeH cluster, but still...  One pharma business I was at recently replaced anH application running on a single-node 8400 (4*500Mhz/2GB Mem) OpenVMS andC Rdb and replaced it with (IIRC) 20+ Sun 3500 8*850 boxes. And still / could not get it to do the same amount of work.0  H I live in the real world. These are examples I have personally witnessedE as both the Vendors (DEC and Oracle) and as a consultant for the pastdF 6.5 years.  Anytime OpenVMS on any hardware platform was replaced, TCOA skyrocketed because of the shear volume of systems that had to bewG purchased, licensed and maintained to do the same (not more ) amount of1H work as the OpenVMS system.  Not to mention that if it was replaced with2 M$ how often it was hacked, crashed or rebooted...  @ I still have an OpenVMS/Rdb database that has been opened and in; operation for 456 days and counting at a F-500 company in ac< manufacturing area. I almost dare you to find one Sun/OracleH installation that can claim the same thing...  It might exist - but then again I doubt it.e  	 > Regards  > Andrew Harrisonl     --   Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163 7 Sr. Consultant            http://www.firstdbasource.com E VMS Marketing Volunteer   http://www.firstdbasource.com/donation.htmlk/ 704-947-1089 (Office)     704-236-4377 (Mobile)t   ------------------------------  % Date: Wed, 26 Jun 2002 14:38:38 -0400n' From: "Main, Kerry" <Kerry.Main@hp.com>e Subject: RE: TCO studyT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4026607C9@kaoexc01.americas.cpqcorp.net>  E >>> Of course they will, but to customers buying your systems now its-1 what they are capable of now thats important ..<<m  3 Yep, and that's why Customers continue to buy them.S  H >>> No they don't sorry, the GS320's numbers are quite frankly terrible.E Worse than Fujitsu and more expensive, worse than IBM (P690) and morepH expensive, worse than SuperDome and more expensive, almost the same as a IBM P680 and more expensive.<<<e  = Yada, yada, yada - let me know when Sun does a TPC benchmark.n  H As I stated before - Both new and existing Customers are buying Alpha GS@ Series servers (OpenVMS AND Tru64 UNIX) and are happy with their performance.=20a  % Imho, that is the ultimate benchmark.e   :-)l   Regardsi  
 Kerry Main Senior Consultant. Hewlett-Packard Canada! Consulting & Integration ServicesE Voice: 613-592-4660' Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----' From: Andrew Harrison SUNUK Consultancye7 [mailto:andrew_nospam.harrison_remove_this@sun#.com]=20e Sent: June 26, 2002 1:39 PMy To: Info-VAX@Mvb.Saic.Comi Subject: Re: TCO study         Main, Kerry wrote:   > Andrew, Andrew - >=20I > Now, now - first you ask for industry benchmark data, then I give it=20o8 > and then you state "yeah, but that does not matter .." >=20H > The reality here is that everyone in this newsgroup realizes benchmark  G > results are a snapshot in time that will always be beat by someone=20  > faster over time.o >=20    9 Of course they will, but to customers buying your systemsn8 now its what they are capable of now thats important and9 that is where as you know the current GS series drops offr
 the radar.  9 It would be nice to say that there was a time maybee soonF: after GS series introduction when this wasn't the case but8 then as you also know without re-writing history this is( also not a subject you want to dig into.  6 Your posting characterises many in this group who seem: to espouse a jam tommorow approach, never mind the currentF boxes/CPU's/Operating System/Marketing campaign there may be something better arround the corner.  A I on the other hand steer clear of prognostications (BS about the2F future) and predicitions about how great the next Sun will be. PerhapsH if you realised that people don't actually buy futures because you can't! revenue them you would do better.h    H > The GS320 systems have very respectable TPC benchmark numbers (not the  E > top, but Sun has none) and numerous Customers with very high end=20.E > application requirements who are very happy with the performance=20d > levels they have.e    D No they don't sorry, the GS320's numbers are quite frankly terrible.E Worse than Fujitsu and more expensive, worse than IBM (P690) and moremH expensive, worse than SuperDome and more expensive, almost the same as aD IBM P680 and more expensive. 4th or 5th (last in the big SMP stakes)D isn't good its terrible. And thats before you realise that to get to& last you had to do OPS in a box akkkk.  F Only a total idiot would describe being last in the current generation+ of large SMP server numbers as respectable.m  6 Just as a question, excluding Sun for a moment you are6 focusing on TPC-C well fine its the best of a terrible8 bunch, so how on the basis of your best benchmark result8 do you justify clasifying the GS320 in the same category- as say the IBM P690 for you TCO "study" ?????c  7 I cannot understand why you keep banging on about TPC-C - it only makes the GS320 look more inadequate.d   RegardsC Andrew Harrisone   ------------------------------   Date: 26 Jun 2002 23:25:24 GMT4 From: "Jim Strehlow" <JimStrehlowNoSpam@data911.com>' Subject: Re: Trouble with BACKUP/RECORD 0 Message-ID: <afdih4$s8f@dispatch.concentric.net>  D I ran a quick check and had no problems on both versions of OpenVMS.> Does your v7.3 computer have the DEC-AXPVMS-VMS73_BACKUP-V0100* patch applied?  ($ PRODUCT  SHOW  HISTORY)  & Jim Strehlow, Data911, www.data911.com Alameda, CA, USA    8 "Roland Barmettler" <rob@bbp.ch.remove> wrote in message1 news:20020626114748.759b164d.rob@bbp.ch.remove... 	 > Hi Guysb >r> > I have a problem with BACKUP/RECORD or rather /SINCE=BACKUP. >0 > If I do a:+ > $ BACKUP/RECORD/LOG *.TXT;* TEST.BCK/SAVE  > C > and have a look at the backup date in the file header afterwards,r( > it's correctly recorded (as expected). >l > But if I then do a:k2 > $ BACKUP/LOG *.TXT;*/SINCE=BACKUP TEST1.BCK/SAVE >-> > I still get all the files backed-up. /SINCE=yesterday works,7 > /SINCE=<timestamp> works, only /SINCE=BACKUP doesn't.g >m  > This happens on 7.2-1 and 7.3. > What am I missing ?g >  > Thanks a lot.r > Greetings, Roland. >uH > --------------- bbp - Biveroni Batschelet Partners AG ----------------< >              Bahnhofstrasse 28, CH-5401 Baden, SwitzerlandH > ----------------------------------------------------------------------   ------------------------------  # Date: Thu, 27 Jun 2002 03:00:03 GMT - From: "John E. Malmberg" <wb8tyw@qsl.network> % Subject: Re: Trouble with Samba 2.0.3o* Message-ID: <3D1A7BA8.3060100@qsl.network>  + Stephen Eickhoff (remove dash below) wrote: I > I've managed to get the client part working, but what i really need is eG > the smbd. When I run smbd_setup_tcpip.com, it starts up the service. sJ > However, only a few seconds later the service terminates. The log looks  > like this:  E I am guessing at the version of OpenVMS, and what TCP/IP product and m stack you are using:  I See the SAMBA-VMS FAQ, posted on Encompasserve, also available searching , http://www.google.como   [Url is wrapped]& http://eisner.encompasserve.org/htbin/R dnqindexform?TEXT=R30328472-30368736-dra4%3A%5Bdecuserve_extracts%5Dvms.full%3B415     SAMBA22.  8 SAMBA will not start and I am running Compaq TCP/IP 5.1.  E   The following fix needs to be added to the SMBD_SETUP_TCPIP.COM andi'       possibly the SMBD_SETUP_TCPIP.COM           $ tcpip set service smbd -        /protocol=TCP -        /port=139 -3        /flags=listen -   ! This is the change <<<<<c        /user=SYSTEM -i        /process=SMBD -/        /file=SAMBA_ROOT:[BIN]SMBD_STARTUP.COM -h9        /log=(FILE:SAMBA_ROOT:[VAR]SMBD_STARTUP.LOG,ALL) -n        /limit=100i   -Johni wb8tyw@qsl.network Personal Opinion Only'   ------------------------------  % Date: Thu, 27 Jun 2002 01:22:16 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>r Subject: Worldcom MCI and VMSo, Message-ID: <3D1AA107.5F954BB8@videotron.ca>  M Some years ago, there was a prominent and knowledgeable poster to comp.os.vmseG who worked for MCI and contrary to many, felt very confident about VMS,o@ especially at his shop where attempts to replace VMS had failed.  M Since then, MCI was purchased by the .COM Worldcom which has made the news inm recent days.  J Does anyone know whether MCI still has much VMS ? Has MCI's infrastructure3 spread to other parts of Worldcome or the reverse ?n   ------------------------------   Date: 26 Jun 2002 21:17:40 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: XFC Status??a* Message-ID: <afdb1k$1ct$3@web1.cup.hp.com>  h In article <mu06dLFoFWl9@eisner.encompasserve.org>, newton_l@encompasserve.org (Lawrence Newton) writes:F :Is there any word on extended file cache (XFC) in VMS V7.3 or V7.3-1./ :The patch was still on hold earlier this week.e  F   V7.3 XFC V2.0 ECO kit release is expected circa 12-Jul-2002.  Maybe G   earlier.  OpenVMS Alpha V7.3-1 has XFC enabled; the XFC ECO for V7.3 s2   is a back-port of the OpenVMS V7.3-1 XFC work.    E   Prior to the installation of the XFC V2.0 ECO on OpenVMS Alpha V7.3yB   systems (only), please use the VCC/VIOC caching mechanisms.  YouE   can select VCC/VIOC by setting the system parameter VCC_FLAGS to 1.9  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   End of INFO-VAX 2002.350 ************************