1 INFO-VAX	Sat, 15 Jul 2000	Volume 2000 : Issue 393       Contents: Re: Alpha PWS500a(u) Re: Alpha PWS500a(u) Re: Alpha PWS500a(u)3 Re: Alpha PWS500a(u) - Which machines will run VMS? " Re: Boot-problem with VAX 4000-200 DEC BASIC rounding problem?  Re: DEC BASIC rounding problem?  Re: Decwrite: where to get? 4 Re: got to remember to STOP trying to use OpenVMS...4 Re: got to remember to STOP trying to use OpenVMS...C Re: I/O caching and UNIX evaluations (was: Re: got to remember ...) C Re: I/O caching and UNIX evaluations (was: Re: got to remember ...) C Re: I/O caching and UNIX evaluations (was: Re: got to remember ...) ' Re: Mac-Decnet via Webster Multiport LT  Re: Multi Tape restore problem.  Re: Problem with UCX FTP Re: Problem with UCX FTP Re: Problem with UCX FTPK Re: Switching from VXT (x/motif) clients to PC(java 2) clients (a question) " The URL that Compaq forgot to send& Re: The URL that Compaq forgot to send& Re: The URL that Compaq forgot to send Re: VMS Pascal question  Re: VMS Pascal question   F ----------------------------------------------------------------------   Date: 15 Jul 2000 09:28:44 CDT= From: wayne@tachysoft.xxx.293778.killspam.0223 (Wayne Sewell)  Subject: Re: Alpha PWS500a(u) . Message-ID: <FPyG76WpR16g@tachxxsoftxxconsult>  _ In article <smvem3qgnd6104@corp.supernews.com>, "Island Computers" <sales@islandco.com> writes:   > Get em whilst they're hot !!!! >  > Ebay Item# > C >  http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=382645921  >  > -- > ! > Island Computers US Corporation  > 2700 Gregory Street  > Savannah GA 31404  > Tel: 912 447 6622  > Fax:912 201 0096 > sales@islandco.com >  >   I Sorry, I ignore all auctions by Island Computer, even if I want the item.      --  O =============================================================================== M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxx : http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-) O =============================================================================== O Otter, on dining with Bluto:"It's perfectly safe if you keep your arms and legs  			away from his mouth."   ------------------------------   Date: 15 Jul 2000 10:35:12 CDT= From: wayne@tachysoft.xxx.293778.killspam.0223 (Wayne Sewell)  Subject: Re: Alpha PWS500a(u) . Message-ID: <jXaJFFe5Vka8@tachxxsoftxxconsult>   In article <rdeininger-1407002302450001@user-2ivebgl.dialup.mindspring.com>, rdeininger@mindspring.com (Robert Deininger) writes: ` > In article <smvem3qgnd6104@corp.supernews.com>, "Island Computers" <sales@islandco.com> wrote: > ! >> Get em whilst they're hot !!!!  >>  
 >> Ebay Item#  >>  D >>  http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=382645921 >> >  > David, > G >   Maybe I'm just slow this evening, but if the price is firm at $1495 H > each, why bother to put them in an auction?  And why start the bidding > at $1?    J It took me a while to figure out the whole concept of a ebay reserve priceL auction.  At first glance, it seems pointless.  What's the point of having aO low starting bid if no one can actually get the product until the reserve price N is met?  Most reserve auctions don't tell you the actual reserve price as thisN one does; you have to keep bidding until you hit it by accident.  If the priceL is actually fixed, why not make that the starting price?  Or as you say, why bother with an auction at all?  O As I see it, the reason for a reserve auction is that people are put off if the L starting bid is high.  If it's already high, you know it will be higher whenO people start bidding.  You rarely see anyone bid on auctions with high starting ; bids.  Many of those run to completion with no bids at all.     L A low starting bid suckers people into bidding on the product.  Since peopleN don't usually know the reserve price, they have to keep probing upward to findI it.  Once people get into a bidding frenzy, this is much more likely than I bidding on an auction where the starting bid is known to be high.  People L usually have an idea what they are willing to pay for a particular item.  IfM the price is *already* above that, why would anyone ever bid?  With a reserve N price auction, you don't know.  You can go ahead and bid and you don't have toH worry about being committed to buy the item unless you meet the reserve.  J Before ebay instituted the auction watching mechanism, I worked out my ownN mechanism for watching.  I simply put in the minimum bid for any auction I wasM even remotely interested in.  If it was a regular auction, I did this only if K the price was low, since I would be committed if I accidently wound up high N bidder and no one else bid after that.  For reserve auctions, I went ahead andI did it no matter what the price was, as long as the reserve was not met.  N Either way, the bid caused the auction to appear on my display so that I couldL track it, and I was not committed to actually buy anything.  After the probeM bid, I wouldn't bid any more until near the end of the auction.  I would then N decide, based on the current bid and whether reserve had been reached, what my final bid would be, if any.   6 Bid watching eliminated the need for such antics.  :-)    J Of course, as you say, what's the point of having an auction at all if theE price is fixed?  The only thing I can guess here is that there is the J possibility, however slight, that you can get more than that.  The reserveO price is a minimum, and people could get carried away and go far above it.  The N flip side is that you might not sell the product at all, either because nobodyL bid on it (high starting price) or the reserve was not met.  You have to payB the fee for the auction whether you actually sold anything or not.  N The only advantage of a failed reserve auction over a failed high-starting-bidM auction is that you now have an idea of what people are willing to pay, based L on the highest bid, and can adjust your reserve price accordingly if you areO willing to take less.  With a high starting bid, nothing at all happens and you L have no idea what people are willing to pay, other than it is less than what you asked for.    M Many people simply avoid all reserve price auctions because of the additional 
 annoyance.   --  O =============================================================================== M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxx : http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-) O =============================================================================== O Otter, on dining with Bluto:"It's perfectly safe if you keep your arms and legs  			away from his mouth."   ------------------------------  % Date: Sat, 15 Jul 2000 11:59:02 -0400 2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: Alpha PWS500a(u) L Message-ID: <rdeininger-1507001159020001@user-2ivebf7.dialup.mindspring.com>   > L > It took me a while to figure out the whole concept of a ebay reserve price > auction.  
   <<chop>>O > Many people simply avoid all reserve price auctions because of the additional  > annoyance.  ; Things get complicated when you try to read people's minds!    Another reason for low starting bids may be to generate enough bidding noise to get on one of the "hot items" lists, or whatever they are called now.  Many sellers look for some gimmick to stampede the sheeple into a bidding frenzy.  H I've just about given up on ebay.  First, it's more and more filled withY garbage foisted by junk-pedlars.  It's just too hard to find the wheat among the chaff.     Second, it generally crashes just when I'm trying to make a bid.  For all the money they rake in, they could invest in some competent programmers and non-junk equipment.  Even in the early days, when they could have fixed the disaster relatively easily, they were more interested in making excuses than fixing problems.  I remember long discussions in one of the feedback forums at ebay, where arrogant support people shouted at disgruntled customers.  The customer was always WRONG.  Nice folks at ebay.   --   Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Sat, 15 Jul 2000 12:42:08 -0400 % From: JM <vmswiz@geonospamcities.com> < Subject: Re: Alpha PWS500a(u) - Which machines will run VMS?O Message-ID: <DDFA32BEAB3E9753.370D45BB45DD0A26.FE143E924981BC82@lp.airnews.net>   G I always watch the auctions for cheap, underpriced Alphas to replace my  alphastation 200 4/233.   ? I'm looking for a $250 300-500mhz "circa 1998" dream machine :)   ; Anyone have a list of the "Originally intended for NT only" G Alphastations that will run Hobbyist VMS? I expect all the NT people to H start dumping them since they are terrified that support is running out.  C PW 333XL looks like a good cheap upgrade, but probably won't work.    A PWS 500A's, I'm confused whether they will all run VMS or if only 9 certain serial number ranges or if they SRM upgradeable.    G PWS 600A came after the PWS 500A's so they are probably a safe bet, but  too pricey this year.     G Then there are all the "off-brand", non-DEC machines. Probably a better ' deal if I knew which ones were useful.    H If anyone has started a list, or can let me know which ones they've been< successful with so far, I'd be happy to put it up on my VMS ) page at www.geocities.com/vmswiz/vms.html    Thanks.    			*JM*    ------------------------------  % Date: Sat, 15 Jul 2000 18:43:09 +1000 - From: David B Sneddon <dbsneddon@bigpond.com> + Subject: Re: Boot-problem with VAX 4000-200 0 Message-ID: <08430946834664@domain2.bigpond.com>  1 At 06:50 PM 14-07-2000 +0200, Rainer Terpe wrote:  >Hi VAX-specialists,E >a few days ago I got an old VAX 4000-200. Now I have a boot problem.  > ? >Starting the boot process my screen shows the following lines:  >  >Performing normal system test! >95..94..93..92..91..90..89..88..  > ; >?49 2 1D FF 0000 0000 01 ; SUBTEST_49_1D, DE_MS650_FDM.LIS  > 0 >Now I see the registers with their actual value >  >The Systemtest continues till5 >15..14..13..12..11..10..09..08..07..06..05..04..03..  >Normal operation not possible >>>>  @ I also have a VAX 4000-200 that does exactly this but have never> gotten around to capturing the text and posting this question.= I am assuming that the reference to MS650 above is to do with  memory.   ( >The status-indicator shows the digit 8. > H >With sh dev I see all devices. When I try to boot with b DIA0 (my first >disk) the following messages  >appear: >  >(BOOT/R5:0 DIA0)  >-A$DIA0 >?42 NOSUCHFILE, DIA0 
 >?06 HLT INST  >       PC=00000D42  > < >Does anyone know a description of the error and a solution?  @ Fortunately for me, mine boots.  Even with the "Normal operationA not possible" message.  (My VMS must be running abnormally then.) ? The ?42 NOSUCHFILE means it can't find the required boot files. < I get the above message if I try to boot from a non-existent root on one of my drives. > Try booting from another disk, or try different roots on DIA0.  # >BTW, I unfortunately have no docs.  >  >Rainer      Regards, Dave. I ------------------------------------------------------------------------- I David B Sneddon (dbs)  OpenVMS Systems Programmer   dbsneddon@bigpond.com F DBS software is at http://www.users.bigpond.com/dbsneddon/software.htmI "Life is what happens to you while you're busy making other plans" Lennon    ------------------------------  # Date: Sat, 15 Jul 2000 16:33:16 GMT / From: "Tom Simpson" <simpsont@xxx.mediaone.net> $ Subject: DEC BASIC rounding problem?F Message-ID: <gn0c5.46987$Fe4.307032@typhoon.jacksonville.mediaone.net>  K Here is a screen shot of a Basic program that we are having a problem with. F It seems that the INT function is returning an incorrect (or certainly? unexpected) result.  Can someone tell me what is going on here?   < As you can see, the result of line 4786 is  32638.0000000000G When you take the INT of that result (4787) it returns 32637.0000000000 E Why is it whacking the last significant digit?  All the variables are  declared Double.   4 Environment is OpenVMS/Alpha V7.1-2, DEC BASIC V1.3.   Regards, Tom   
 * SRC: module B REM_SND_ABCDMERCH$MAIN -scroll-source*****************************5   4784:         n.total = pay_amt * ( net.pct/100.0 ) D   4785: !       net.amt = int( ((pay_amt * (net.pct/100.0))  + .5) )&   4786:         n.total = n.total + .5(   4787:         net.amt = int( n.total )   4788: K ->4789:         dmerch::commission_pct = cvt_2_overpunch(commis.pct*100, 4)    4790: =   4791:         IF mid$( mpy::batch.type, 3%, 1% ) = "R" THEN 8   4792:             dmerch::description = "RECEIVED NSF"I   4793:             dmerch::fin_trans_amt = cvt_2_overpunch(-pay_amt, 10) G   4794:             dmerch::net_pmt_amt = cvt_2_overpunch(-net.amt, 10)  * L OUT -output***************************************************************** **0 REM_SND_ABCDMERCH$MAIN\N.TOTAL: 32637.5000000000, stepped to REM_SND_ABCDMERCH$MAIN\%LINE 47870 REM_SND_ABCDMERCH$MAIN\N.TOTAL: 32638.0000000000, stepped to REM_SND_ABCDMERCH$MAIN\%LINE 47890 REM_SND_ABCDMERCH$MAIN\NET.AMT: 32637.0000000000 * L PROMPT -error-program-prompt************************************************ **	 DBG> Step  DBG> exa n.total	 DBG> Step    ------------------------------  % Date: Sat, 15 Jul 2000 10:30:18 -0700 2 From: "Randy Park" <rjpark@mindspring.com.nospaam>( Subject: Re: DEC BASIC rounding problem?3 Message-ID: <8kq740$l0j$1@nntp9.atl.mindspring.net>   < This issue comes up from time to time.  As someone with over@ 20 years of experience with BASIC-Plus, VAX Basic, and DEC Basic? I learned along time about about inexact computations involving  floating point operations.  = Floating point operations, by their very nature, are inexact. ? Back on the PDP-11, you had no choice but to use floating point < for numeric operations.  When VAX Basic arrived, the DECIMAL< data type was added, which performed exact operations.  When; writing new applications DECIMAL is the data type of choice < for operations involving money.  But let's face it, a lot of> Basic applications were originally written for the PDP-11, and@ rewriting or changing the data types is not always an acceptable? choice.  The problem then becomes, "How do you round numbers so = that you get the result you want?"  The solution is to adjust C your rounding.  Instead of using 0.5, use 0.500000001 as a rounding @ factor, assuming you need no more than 5 places past the decimal9 point.  To undestand why you need to do this, you have to 6 understand the internal format of floating point data.  ? As a side bar, if your applicationn was in VAX Basic but in now A in DEC Basic on Alpha, but you have kept the D-Floating data type ? instead of converting to the G-Floating data type and your have 9 compiled with a default floating type of D-Float, you can E experience a similar problem and need to force your D-Float variables A and constants through the REAL(,) function before using an equals B (=) or a not-equals (<>) comparison, because only the bit patterns! get compared not the data values.     8 Tom Simpson <simpsont@xxx.mediaone.net> wrote in message@ news:gn0c5.46987$Fe4.307032@typhoon.jacksonville.mediaone.net...G > Here is a screen shot of a Basic program that we are having a problem  with. H > It seems that the INT function is returning an incorrect (or certainlyA > unexpected) result.  Can someone tell me what is going on here?  > > > As you can see, the result of line 4786 is  32638.0000000000I > When you take the INT of that result (4787) it returns 32637.0000000000 G > Why is it whacking the last significant digit?  All the variables are 
 > declared	 > Double.  > 6 > Environment is OpenVMS/Alpha V7.1-2, DEC BASIC V1.3. > 
 > Regards, > Tom  >  > * SRC: module D > REM_SND_ABCDMERCH$MAIN -scroll-source*****************************7 >   4784:         n.total = pay_amt * ( net.pct/100.0 ) F >   4785: !       net.amt = int( ((pay_amt * (net.pct/100.0))  + .5) )( >   4786:         n.total = n.total + .5* >   4787:         net.amt = int( n.total )	 >   4788: J > ->4789:         dmerch::commission_pct = cvt_2_overpunch(commis.pct*100, 4)	 >   4790:5? >   4791:         IF mid$( mpy::batch.type, 3%, 1% ) = "R" THEN5: >   4792:             dmerch::description = "RECEIVED NSF"K >   4793:             dmerch::fin_trans_amt = cvt_2_overpunch(-pay_amt, 10) I >   4794:             dmerch::net_pmt_amt = cvt_2_overpunch(-net.amt, 10)p > *. > L OUT -output***************************************************************** > **2 > REM_SND_ABCDMERCH$MAIN\N.TOTAL: 32637.5000000000. > stepped to REM_SND_ABCDMERCH$MAIN\%LINE 47872 > REM_SND_ABCDMERCH$MAIN\N.TOTAL: 32638.0000000000. > stepped to REM_SND_ABCDMERCH$MAIN\%LINE 47892 > REM_SND_ABCDMERCH$MAIN\NET.AMT: 32637.0000000000 > *e >rL PROMPT -error-program-prompt************************************************ > ** > DBG> Step/ > DBG> exa n.total > DBG> Stepn >( >u >i   ------------------------------   Date: 15 Jul 2000 17:39:38 GMT. From: smith_j@removeit.cqm.co.uk (James Smith)$ Subject: Re: Decwrite: where to get?7 Message-ID: <8F72BB1A9smithjremoveitcqmcou@212.41.43.3>-  H >You can't download it.  In order to get it you'll need to find a CD-ROMG >with the kit on it.  Unfortunatly most of the layered products coveredpE >by the hobbyist program aren't on the Hobbyist CD.  There is only sotH >much you can fit on one CD and they had to pick and choose the productsI >that they felt would be the most desired.  An entire Condist set of CD's 0 >is something like 16 CD's for one architecture. >e >               Zane >  bummer - cheers anyway   James S    ------------------------------  # Date: Sat, 15 Jul 2000 12:41:42 GMTa= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) = Subject: Re: got to remember to STOP trying to use OpenVMS... 0 Message-ID: <009ED1C0.F686A18E@SendSpamHere.ORG>  D In article <8kolbh$fsb$1@nnrp1.deja.com>, jordan@my-deja.com writes:1 >In article <009ED103.80E619D6@SendSpamHere.ORG>,/! >  system@SendSpamHere.ORG wrote: . >> In article <Q+ev0EZj+N24@eisner.decus.org>,< >Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:0 >> >In article <8kl7ki$dfa@gap.cco.caltech.edu>,5 >mathog@seqaxp.bio.caltech.edu (David Mathog) writes:f >> >G >> >> We all know that for platforms which don't support autoconf etc.,- >most-? >> >> notably OpenVMS, it is a PITA to deal with these sorts ofh >packages.  ButkC >> >> what are you going to do - that's the way the Unix guys build-	 >packagese >> >> these days.o >> >G >> >Don't they have source files ?  I thought "the VMS way" for dealinggF >> >with arbitrary source files was to run them through MMS asking MMSC >> >to generate a dependency graph and the corresponding .MMS file.a >>	 >> Larry,: >>G >> The GNU stuff is psycho!  Think of the most logical and sound way top< >> make a software product and then do the compete opposite! >>G >> Most of the psychosis in a GNU make is the brain-damage incorporatediF >> to determine what include files and runt-time features exist on theF >> particular platform.  Some early GNU developer "fries shy of a com-G >> plete Happy Meal", developed this brain-damaged way to do things and G >> many of the other products seemed to adopt it.  It's crazy...  Make-aE >> file beget C files which are preprocessed to beget more makefiles,  >> rinse, lather, repeat...c >l0 >I think you're referring to autoconf/configure. >d? >I'm not sure what your criticism is _exactly_.  Without such ae= >facility, you have to support makefiles and headers for eacho@ >flavor of Unix, and the various environmental features of thoseA >flavors of Unix are moving targets.  Autoconf/configure supportshB >a framework where the various attributes of the environments, allC >the subtle semantics of run-time environments, include files, etc. F >are discovered and customized makefiles (and include files) are built' >that should work on the target system.g  C ... and if you had a half-way decent and robust make facility, you hB wouldn't need the psychosis.  Sorry but this autoconf is psycho no+ matter which side of the fence you view it.    --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMa   ------------------------------  # Date: Sat, 15 Jul 2000 12:48:28 GMTr= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) = Subject: Re: got to remember to STOP trying to use OpenVMS...b0 Message-ID: <009ED1C1.E902AB54@SendSpamHere.ORG>  D In article <8kolbh$fsb$1@nnrp1.deja.com>, jordan@my-deja.com writes:1 >In article <009ED103.80E619D6@SendSpamHere.ORG>,o! >  system@SendSpamHere.ORG wrote:l. >> In article <Q+ev0EZj+N24@eisner.decus.org>,< >Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:0 >> >In article <8kl7ki$dfa@gap.cco.caltech.edu>,5 >mathog@seqaxp.bio.caltech.edu (David Mathog) writes:d >> >G >> >> We all know that for platforms which don't support autoconf etc.,  >mostw? >> >> notably OpenVMS, it is a PITA to deal with these sorts ofw >packages.  ButdC >> >> what are you going to do - that's the way the Unix guys build 	 >packagesm >> >> these days.u >> >G >> >Don't they have source files ?  I thought "the VMS way" for dealingfF >> >with arbitrary source files was to run them through MMS asking MMSC >> >to generate a dependency graph and the corresponding .MMS file.  >>	 >> Larry,i >>G >> The GNU stuff is psycho!  Think of the most logical and sound way to < >> make a software product and then do the compete opposite! >>G >> Most of the psychosis in a GNU make is the brain-damage incorporatedhF >> to determine what include files and runt-time features exist on theF >> particular platform.  Some early GNU developer "fries shy of a com-G >> plete Happy Meal", developed this brain-damaged way to do things andnG >> many of the other products seemed to adopt it.  It's crazy...  Make-hE >> file beget C files which are preprocessed to beget more makefiles,  >> rinse, lather, repeat...s >e0 >I think you're referring to autoconf/configure. >t? >I'm not sure what your criticism is _exactly_.  Without such a = >facility, you have to support makefiles and headers for eachn@ >flavor of Unix, and the various environmental features of those  I That's another sore spot.  Is it time for a list of applicable oxymorons?oF Methinks so.  Try these for a start: "Standard Unix" and "Portable C".   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM=   ------------------------------    Date: 15 Jul 2000 03:56:42 -0500* From: young_r@eisner.decus.org (Rob Young)L Subject: Re: I/O caching and UNIX evaluations (was: Re: got to remember ...)+ Message-ID: <4TJKWGFHp569@eisner.decus.org>a  X In article <xvQY9bP$ffhA@eisner.decus.org>, young_r@eisner.decus.org (Rob Young) writes:m > In article <8knjrk$32v$1@mailint03.im.hou.compaq.com>, hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes:r >  > Steve, >  >> r >> sA >>   [Discussions of various favored UNIX flavours expurgated...]0 >> 9H >>   If y'all (customers) wish fast(er) and correspondingly potentially J >>   increasingly "unreliable" I/O (the term "unreliable" is here used to I >>   indicate increased use of caching and coorespondingly less frequent cI >>   disk updates, and is not intended in a derogatory context), then we pF >>   will look to provide y'all with access to this or to similar I/O C >>   caching support.   Of course, if caching or other related I/O  I >>   performance tweaks do get implemented, then the support will likely iL >>   have control knobs to permit tuning or to permit it to be specifically  >>   disabled or enabled.i >>   >  > 	Along these lines:o > L > http://www.openvms.digital.com:8000/72final/6520/6520pro_004.html#params_h > = > 	You have VCC_WRITEBEHIND and VCC_WRITEDELAY... enough ropet > 	to hang ourselves with.   > ? > 	How about some method to exclude files from being cached OR  > > 	prioritizing files to be cached at file or directory level? > H > 	I'm assuming caching is getting down to block level and all available> > 	memory ala the Unices.. maybe the above isn't necessary but? > 	would be a shame to have users flushing our caches for those = > 	with tight memory systems because they are pecking at somer= > 	worthless files (Mail?) when that cache could be much mores? > 	effective caching what it can of a hot database.  So in thisi; > 	case the appropriate SYSGEN flag is set and VMS looks to-1 > 	system logicals for inclusion/exclusion lists.m >    	Adding to this..   8 	Granularity such WRITE_BEHIND and WRITE_DELAY behaviour@ 	could be very finely tuned.  Such that you could wildcard *.tmp@ 	files and say they are always write_behind files... WRITE_DELAY> 	could have granularity not unlike Shadow Merge delay.  System 	wide or disk specific.3  @ 	Also, very nice statictics that would be easy to interpret withA 	utilities to run against such that a novice system manager couldo 	understand.     				Robe   ------------------------------  % Date: Sat, 15 Jul 2000 03:10:24 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>dL Subject: Re: I/O caching and UNIX evaluations (was: Re: got to remember ...)( Message-ID: <8kp2ko$7it$1@pyrite.mv.net>  8 IanPercival <IanPercival@email.msn.com> wrote in message# news:edrFJ#e7$GA.278@cpmsnbbsa07...yJ > > But given how badly VMS file caching performance sucks compared to the > restC > > of the world, your statement above seems inexcusably arrogant -h
 especiallyG > > in its implication (reinforced by your statements below) that otherh	 > designs - > > necessarily entail losses in reliability.u > >mL > > It seems reasonable to infer that either VMS engineering doesn't know inL > > real detail how to cache better (and maintain reliability), or knows butG > > doesn't consider it important (which in my experience suggests thath their0L > > knowledge may be at least somewhat superficial, since it's not perceived > asF > > being an area worthy of real study), or knows but doesn't have the > resources0I > > to do anything (which is at least something one can sympathize with).n AndsJ > > even you seem to be aware that VMS engineering doesn't know how people > want< > > to *use* caching to achieve differing trade-offs between up-to-the-secondB > > persistence and performance, which likely implies that certain > possibilitiesl2 > > have not received the analysis they may merit. > - > The above is a highly misleading statement.o >vK > As Steve Hoff says, it's hardly a revelation to many of the VMS engineersu > thatE > variants of UNIX (and even may I say NT) have a different file dataS caching 	 > scheme.tL > Writeback caching is always going to outperform writethrough caching as is
 > the current > > VMS cache implementation FOR WRITES on low to medium volume. >a9 > There is also a VERY strong presence in VMS EngineeringCD > of real world talent who have been at the front end of performance problems > for many yearsL > (though of course there are some die hards who need to be educated still -  > as in any large organisation).H > We are working with some very large customers on some very interestingL > issues.  The statement that we in VMS Engineering don't know how customersJ > want to use caching is quite frankly,grossly incorrect (though of courseL > thats open to interpretation - I'm sure that there are SOME individuals inE > Engineering, who have nothing to do with the file system, cache, or- > performance who don't know).  I You should note that that statement simply reflected my interpretation ofoL Hoff's:  "If y'all (customers) wish fast(er) and correspondingly potentiallyD increasingly "unreliable" I/O (the term "unreliable" is here used toH indicate increased use of caching and coorespondingly less frequent diskK updates, and is not intended in a derogatory context), then we will look todE provide y'all with access to this or to similar I/O caching support",mK coupled with "One of the OpenVMS engineers has brought up a Linux Alpha box K to see just what I/O caching scheme features are used there, and to comparec- it to XFC and to OpenVMS caching in general."   I Note the conditional ("*If* y'all... wish...") and the future tense ("...3K then we *will* look to..."):  both suggest rather directly that this is not0K a situation that has obtained since time immemorial, and in fact may be onerJ still undergoing evaluation (as does the second quote).  So if you wish toE take issue with the statement, the person you should address is Hoff.s  H And it's important to understand that talking in depth with existing VMSL customers is only part of what needs to occur in this pursuit.  In fact, VMSC has always paid attention to its customers in such areas and done amJ reasonable job satisfying them:  where it has traditionally fallen down isK in understanding what the rest of the world (which might consider using VMS.L if it satisfied *their* needs) wants - and somewhat patronizing responses toJ the effect that everything's under control in this respect (when it has soK transparently *not* been true for so long) are not particularly satisfying.0   > J > It is  true that VMS was remiss in ignoring the implementation of a more
 > powerfulL > data caching architecture in the past.  This was for a variety of  reasons > and I7I > don't want to open old wounds as that is fruitless.  This has been goneC over5 > time and time again in the newsgroup and elsewhere..  J I've only been involved in this recent go-around on this issue (plus a fewE isolated comments now and then), so it's certainly possible that I've-K trodden on sensibilities I wasn't aware of.  But the other side of the coinyL is that knowledge of this history should help VMS developers understand thatI a simple pat on the head with the statement 'we know what we're doing' iss not likely to be adequate.  J You've provided more than that here, and may not understand how refreshing( it is to see something more substantive.   >cL > Some time ago in V5.x days I personally made a lot of money by co-writing,H > writing and selling a more powerful set of caching products (I was notI > working for Digital/Compaq - and yes - I was as frustrated as many thatiC > Digital would not enhance, merge or otherwise modify its existingn	 product -rI > find some old copies of Digital Review to see how semi-real independentiJ > testing showed true performance differences between caches).     Some of thewI > more vociferous members of this conference have NOT written any cachingaG > product anywhere.  Nonetheless they are self styled experts.  YES VMSmK > currently has performance problems and YES we've been slow to react.  YESr weI > are now doing something and SORRY it cannot be INSTANTANEOUS!!!!  We DOiC > believe in testing stuff and making it as robust as we can beforea	 releasingn< > it.  Of necessity this means things happen a bit slower...  D Now, now:  that's starting to sound a bit like the false 'quality or performance' dichotomy again.c  A I don't recall major complaints about development *speed* in thisnI discussion, just concern that development *direction* might not be taking J fully into account the needs that have been so neglected in the past.  VMSL has long been good at incremental improvement to existing features, and longK been deficient in addressing areas that "don't fit" with the VMS philosophyiH (a situation that dates back to VMS's creation, when in retrospect a bitI more influence from the TOPS and RSTS sides of the corporation might havekK created a product that would never have left an excuse for developing a DECa Unix in the first place).   J So in the absence of specific indications that such 'furrin-looking' areasB of development are being included (and in the presence of frequentG sentiments here from VMS stalwarts that "We don't need no stinkin' UnixyK behavior!"), you should realize that the concern is justified (and does notiJ necessarily reflect poorly on what you are in fact developing - as long as# it takes such issues into account).V   >pL > Compaq has now committed to move forward on its data caching architecture.F > There will be a LOT of work done over the next few years - with everH > increasing performance yields for different situations.    XFC V1.0 is VERYL > competitive for read I/o caching - and that is BEFORE the performance passL > that will be done on the product before final ship in December.  WritebackL > caching is coming along very shortly afterwards, and it too will be highlyL > competitive methinks - but of course I won't say until the code is frozen.K > Other things will be coming along too - which DO NOT EXIST IN UNIX/LINUX.:H > Gosh - what will some of the naysayers do then?  Lots I'm sure!!!! :-)  G Speaking only for myself, I seldom find it necessary to spring to VMS's*B defense in this particular forum.  But I've been known to do so inI environments equally biased in the opposite direction (don't get too muchC9 appreciation there, either:  people *like* their biases).2     The0L > author of the top paragraphs is very aware of the fact that there is a newD > cache.    Nonetheless it is easy to trash what is there currently.
 > Repeatedly.*  H Only until such time as sufficient details of the new development revealI that concern is no longer necessary.  Actually, even simple acceptance of7J input (unaccompanied by the suggestion that of course VMS doesn't need it) might do the trick.   L It's hard not to be a bit defensive when you're working your tail off to fixH what people are worried about.  But you really can't expect them to stopL worrying (at least given the history involved) without being given something more than platitudes.    >TL > I want to say that up to the present point, I have not heard ONE idea from> > any of the members of this conference on a new way to cache.  ; Could lack of encouragement have something to do with this?c  I *We don't know* what you're doing unless you tell us (in enough detail to L address the things we're talking about).  The DEC I once was associated withI was pretty open about such things, and given appropriate disclaimers it'stF not clear why that couldn't still be true.  By definition, none of theJ concerns expressed about comparative Unix-style performance involve patentL issues (well, the specific means of addressing them could, but the fact thatI you're planning to doesn't), and any information you might be giving awaygK about future VMS plans to the competition seems likely to be far outweighedcF by the positive effects of demonstrating commitment to vigorous futureL development in this area (and hopefully others as well) - not to mention theA possibility that you might learn something useful in the process.   J Some such insights could be in the area of uses, others in approaches.  InJ the latter context, one issue worth pointing out is the narrowness of yourH definition of caching, a narrowness forced upon you by the separation ofF facilities into file system on the one hand and RMS on the other.  TheJ inability to integrate page- and record-level caching eliminates an entireH range of possibilities such as those explored over the past few years byI Barbara Liskov's Thor project at MIT in the context of distributed object!J management (and earlier at U Wisconsin and elsewhere).  I don't completelyJ buy into their approach as far as record-level caching goes (I think thereL are other ways to achieve potentially competitive results), but I definitelyL think their (and others') integration of page- and object-level *locking* isK valuable, and it definitely applies to the distributed caching approach you F appear to be pursuing (and should not be incompatible with the currentK division of labor between the file system and RMS, though it doesn't appearm@ to fit well with the VMS lock manager as currently constituted).  L And there are associated issues like deferred allocation.  That's a combinedI cache/ACP issue:  does that mean it's not on the table for cache-specifica( improvements?  *I* certainly don't know.  I The point is, you're not likely to get input if you don't participate andeJ indicate that you're receptive to it.  There's of course no guarantee thatH such participation will result in anything useful to you, but if nothingL else it's excellent public relations.  And if this isn't the right forum for/ such external discussion, I don't know what is.      The statementsF > seems to be made over and over again that we should look at the Unix modelsJ > as examples of how things should be done.  Maybe some of you should chat toJ > a maintainer or designer of a Unix cache.  I have.  Things are certainly notHH > as golden as many  would have us believe in terms of data reliability. ItstL > incredibly arrogant of some people here to think that VMS engineers cannotJ > figure out such concepts as writeback caching,  temp files never hitting
 > oxide, etc..  H I suppose it would be, but, again, I've not seen any indication of this.L The main concern I've had (and seen) is that VMS engineers cannot figure out? that such features are *important* to provide in a reliable andeF easily-accessible manner (a concern legitimized by their long-standing	 absence).o  E It's easy to put such concerns to rest.  Possibly you just have - ando2 certainly what you've said has at least helped to.  ;    Still, I understand the requirement to be visible too!!!   , That may be the same thing I've been saying.   > J > We anticipate applying for several patents in the V2.0 XFC product, that inK > itself should indicate to some that VMS does not intend to follow, but toS > lead.g >rI > Sorry for a slight flame on - but VMS really is actually moving on this> nowTI > ( YES I know this isn't the total solution but its an indicator that wekL > are,and have been doing things for quite some time, yes we've been slow toI > react - but we really will deliver something in the next few releases).t  H No need to apologize:  as I said, a specific indication of commitment isH refreshing, as is a touch of passion in the presentation.  I hope you'llL reassess this discussion as an indication that people outside really do careK about what you're doing rather than an indication that they're unhappy withr. it (how could we be without knowing details?).   - bill   >.F > Please lets move on - or at leat wait to trash XFC when it's finallyA > released! These discussions will become far more relevant then!y >h > Ian Percival > XFC Project Leader >e > ian.percival@compaq.comt >v >o >e >r >e2 > Bill Todd <billtodd@foo.mv.com> wrote in message$ > news:8knsbt$i4f$1@pyrite.mv.net... > >oA > > Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> wrote in messaget4 > > news:8knpm4$4vp$1@mailint03.im.hou.compaq.com... > > >-: > > > In article <8knoba$ckh$1@pyrite.mv.net>, "Bill Todd" > <billtodd@foo.mv.com>2 > > writes:- > > > :mH > > > :...Your previous statement that "One of the OpenVMS engineers has	 > brought  > > up aL > > > :Linux Alpha box to see just what I/O caching scheme features are used
 > > there"H > > > :suggests that you're looking for ideas, which is a good start.... > > >eA > > >   Please see the earlier discussions around I/O performance. comparisons. > > > I > > >   As for "looking for ideas", caching and cache implementations andd > cachev; > > >   designs are well-known among folks here in OpenVMS.s > > J > > Y'know, I'm inclined to give the folks in VMS engineering a great deal ofL > > benefit of the doubt, considering how thoroughly they've been bludgeoned > byJ > > corporate politics and plain mis-management over the past decade-plus. > >eJ > > But given how badly VMS file caching performance sucks compared to the > restC > > of the world, your statement above seems inexcusably arrogant -O
 especiallyG > > in its implication (reinforced by your statements below) that otherh	 > designs - > > necessarily entail losses in reliability.e > >aL > > It seems reasonable to infer that either VMS engineering doesn't know inL > > real detail how to cache better (and maintain reliability), or knows butG > > doesn't consider it important (which in my experience suggests thato theirsL > > knowledge may be at least somewhat superficial, since it's not perceived > asF > > being an area worthy of real study), or knows but doesn't have the > resourcesnI > > to do anything (which is at least something one can sympathize with).s AndyJ > > even you seem to be aware that VMS engineering doesn't know how people > want< > > to *use* caching to achieve differing trade-offs between up-to-the-secondB > > persistence and performance, which likely implies that certain > possibilitiesw2 > > have not received the analysis they may merit. > >pF > > The bottom line is that if you're not looking for ideas (including > technicalu > > ones), you should be.  > >i
 > > - bill > >i > >   Some of the keydB > > >   factors in the research involve the trade-offs between the performancedD > > >   gains and the corresponding risks to the data integrity, the relativeE > > >   differences in the I/O performance seen, complexity, resource  > > consumption,J > > >   and various implementation-related factors.  Very standard caching
 > > stuff, > > >   in other words.  > > > I > > >   What makes this whole task particularly interesting (to me and toe someI > > >   of the other engineers) is not so much the technical aspects, butj > ratherF > > >   involves the differing comfort levels that I expect individual
 > customerJ > > >   sites will have with various current and various potential cachingL > > >   enhancements.  Some customers undoubtedly want "extreme" caching andH > > >   its (hopefully :-) associated performance improvements, and some will9 > > >   undoubtly prefer data integrity over performance.i > > >iK > > >   And as mentioned earlier, please see the earlier discussions aroundeL > > >   the various I/O performance comparisons folks have been pointing to. > > >i0 > > >  --------------------------- pure personal' > > opinion ---------------------------i5 > > >    Hoff (Stephen) Hoffman   OpenVMS Engineeringn > > hoffman#xdelta.zko.dec.com > > >h > >i > >  >n >e   ------------------------------  % Date: Sat, 15 Jul 2000 11:31:36 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)L Subject: Re: I/O caching and UNIX evaluations (was: Re: got to remember ...)L Message-ID: <rdeininger-1507001131360001@user-2ivebf7.dialup.mindspring.com>  W In article <4TJKWGFHp569@eisner.decus.org>, young_r@eisner.decus.org (Rob Young) wrote:f   >         Adding to this..   > A >         Granularity such WRITE_BEHIND and WRITE_DELAY behavioursI >         could be very finely tuned.  Such that you could wildcard *.tmpbI >         files and say they are always write_behind files... WRITE_DELAYlG >         could have granularity not unlike Shadow Merge delay.  System(  >         wide or disk specific. > I >         Also, very nice statictics that would be easy to interpret withoJ >         utilities to run against such that a novice system manager could >         understand.     H And to repeat an obvious statement that's appeared in this group before:F Any new or improved management/measuring/reporting utility MUST behave nicely with /INTERFACE=CHARACTER_CELL on a VMS machine.  X windows interfaces are fine as an additional (not only) option.  Even a billy-box interface is ok AS AN OPTION.  We don't need any more evil VMS utilities that REQUIRE a billy-box.t   When I read that the new GS-series machines REQUIRE a billy-box as a system console, I almost fell out of my chair.  24x7x365, or until your console goes BSOD.  Good Grief!   -- e Robert Deininger rdeininger@mindspring.com    ------------------------------  # Date: Sat, 15 Jul 2000 17:21:41 GMTn- From: bashyal@earthlink.net (Pradeep Bashyal)p0 Subject: Re: Mac-Decnet via Webster Multiport LT; Message-ID: <1edt8h2.10wowlc1k6sk5gN%bashyal@earthlink.net>y  1 Zane H. Healy <healyzh@shell1.aracnet.com> wrote:"  B > Geoff Roberts <geoffrobx@stmarksx.ppx.catholicx.edux.aux> wrote:G > > Hmm, don't know what version of pathworks/when it was around by anyt > > chance?l > G > I know MSA V1.3A is provides Appletalk to VMS.  As for the version ofrG > Pathworks, I believe there was a Mac specific version of Pathworks.  l > 7 > I think MSA was still on the condist in mid-late '98.e > 5 > >> turn  to IP, which may be the way to go for you.i > ? > > Yeah, I can do it with IP if necessary.  Just a thought....e > J > Depends on what you're trying to do...  Finding a NFS clinet for the MacD > isn't easy at this time, though I think it is possible once again. >   >                           Zane  F MacNFS can be obtained from http://www.thursby.com/products/macnfs.htm   Pt   ------------------------------  % Date: Sat, 15 Jul 2000 08:55:05 -0700a* From: "Jack Peacock" <peacock@simconv.com>( Subject: Re: Multi Tape restore problem.> Message-ID: <FP%b5.21166$MT.617893@news-west.usenetserver.com>  < "Terry Marosites" <TMarosites@unitedad.com> wrote in messageG news:1137A4A23A51D311B2D600105A1D5213026FDE73@seantexch.unitedad.com...dG >   After restoring the first tape it just stops, and will not continuef to theE > next tape and no opcom is received, it looks like it just completed  > normally.v >tF Is there more than one saveset on the tape?  When you say it stops, do you get a DCL prompt?)    Jack Peacocka   ------------------------------   Date: 15 Jul 2000 07:14:42 GMT) From: leslie@clio.rice.edu (Jerry Leslie) ! Subject: Re: Problem with UCX FTPp' Message-ID: <8kp312$3cg$1@joe.rice.edu>   ) Jack Peacock (peacock@simconv.com) wrote:tG : I seem to be having a problem configuring the UCX version of FTP (VMSeA : 7.1, UCX 4.2, AlphaStation 255/300).  When I try to establish atG : connection to it from another node (over internet) I get the message: 1 : TCPIP-E-FTP_NETERR, I/O error on network devicei6 : -SYSTEM-F-REJECT, connect to network object rejected    A Check to make sure that the ownership of SYS$MANAGER:SYLOGIN.COM,rD and any DCL scripts invoked by SYLOGIN.COM, are WORLD:READ,EXECUTE.   E Having the WORLD protection set for 'no access' can cause that error, A as shown in the following example (the DCL prompt has been set tot the node name):t      <SCCVXG> ftp sccvxg-    %FTP-E-NETERR, I/O error on network device 7    -SYSTEM-F-REJECT, connect to network object rejected   4    <SCCVXG> dir/protection sys$manager:sylogin.com;0       Directory SYS$COMMON:[SYSMGR](    SYLOGIN.COM;12       (RWED,RWED,RWE,)    Total of 1 file.   >    <SCCVXG> set file/protection=w:re sys$manager:sylogin.com;0  4    <SCCVXG> dir/protection sys$manager:sylogin.com;0       Directory SYS$COMMON:[SYSMGR]*    SYLOGIN.COM;12       (RWED,RWED,RWE,RE)    Total of 1 file.i      <SCCVXG> ftp sccvxgM    220-Warning: your access is being logged - trespassers will be violated  !.?    220 209-16-45-102.insync.net FTP Server (Version 4.2) Ready.e)    Connected to 209-16-45-102.insync.net. *    Name (209-16-45-102.insync.net:leslie):      <SCCVXG> ucx show version  A      Digital TCP/IP Services for OpenVMS VAX Version V4.2 - ECO 3t1      on a VAXstation 4000-96 running OpenVMS V7.1e    4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------  % Date: Sat, 15 Jul 2000 08:20:23 -0700c* From: "Jack Peacock" <peacock@simconv.com>! Subject: Re: Problem with UCX FTPe> Message-ID: <7j%b5.21130$MT.600153@news-west.usenetserver.com>  6 "Jerry Leslie" <leslie@clio.rice.edu> wrote in message! news:8kp312$3cg$1@joe.rice.edu...vC > Check to make sure that the ownership of SYS$MANAGER:SYLOGIN.COM,eE > and any DCL scripts invoked by SYLOGIN.COM, are WORLD:READ,EXECUTE.a >t5 No such luck, SYLOGIN.COM and LOGIN.COM are both W:REn   Jack Peacock   ------------------------------   Date: 15 Jul 2000 17:11:21 GMT) From: leslie@clio.rice.edu (Jerry Leslie)l! Subject: Re: Problem with UCX FTPc' Message-ID: <8kq5vp$qja$1@joe.rice.edu>i  ) Jack Peacock (peacock@simconv.com) wrote:d8 : "Jerry Leslie" <leslie@clio.rice.edu> wrote in message# : news:8kp312$3cg$1@joe.rice.edu...rE : > Check to make sure that the ownership of SYS$MANAGER:SYLOGIN.COM,zG : > and any DCL scripts invoked by SYLOGIN.COM, are WORLD:READ,EXECUTE.y : >h7 : No such luck, SYLOGIN.COM and LOGIN.COM are both W:RE   G And they don't invoke any other DCL files ? Does LOGIN.COM contain any  E requests for terminal input or unconditional "SET TERMINAL/INQUIRE" ?    :   Jack Peacock  H The only other time I've seen this problem was when the file protection E of UCX$FTPD.EXE didn't include W:RE. This was on a client's system in D Hungary, and we never tracked down what changed the file protection.    4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------   Date: 15 Jul 2000 12:04 CSTe' From: carl@gerg.tamu.edu (Carl Perkins)tT Subject: Re: Switching from VXT (x/motif) clients to PC(java 2) clients (a question)- Message-ID: <15JUL200012040761@gerg.tamu.edu>a  + Mickey Stein <yekkim@pacbell.net> writes...g2 }I've got a project that was coded originally in C2 }on VMS. and a GUI-builder "de jour" (teleuse) was2 }used to generate the front-end templates that are2 }in x/motif format. A decision was made to convert3 }the front-end clients to PC's running java 2. I'vea2 }done some initial legwork and verified that there+ }seems to be no significant problems on the / }front-end by coding up a number of prototypes, 3 }attaching to a socket-server that I built into thei1 }Server code on VMS and doing transactions. Also,e2 }the server application can basically have the old3 }GUI "gutted" and be run as a background app serverh }sitting at a/some socket(s).  } / }Yet another summary: We're going from a systemo+ }where each client used a VXT, started witho1 }decw$login and executed it's code in the context 2 }of a typical VMS loginout process. We're going to1 }a system where it's not so clear how the contextg1 }is handled. Of course, it's not difficult to usea3 }the Java front end to send requests to the server,a3 }request authorization on the old accounts by usinge1 }$hash_password, $getuai, etc.. What seems reallyg2 }problematic to me is that there's no longer a VMS. }context for each client because I'm not using2 }loginout in any way (because it's not clear to me2 }how to do such a thing). Recoding the Server code- }is beyond the scope of the project and usinge- }something like xcursion(x-server) won't work 1 }either because the GUI no longer is supported sos/ }it's got to go. If I haven't mentioned it, thec3 }Server is a 4100 Alpha-cluster running VMS 7.2 and 1 }the Server(s) is written in DEC C. I ported thisa1 }project vax to alpha a few years ago so the code  }is quite "old" (86' or so). } 1 }Q: If anyone can give any ideas as to how 50-100g3 }clients can use VMS loginout (or something similarm. }using system services?) thus having their own2 }context (well, a process to execute in) and still1 }be using the java front end, I'd sure appreciate 3 }hearing them. Really, the other big factor here ise. }obviously that each client will wind up being0 }serialized without it's own context, thread, or1 }process. I don't know that the old code will runn3 }without breaking any number of decthreads rules. Ii/ }also don't know that decthreads is any sort ofh- }viable answer to the context/login situationr/ }because any number of ancillary routines (likes0 }..com files) are used to manage processes which, }wouldn't do much good if there were no user }process<g>) }  }      tia,d } Mick  ) The solution is to create user processes.e  A Instead of having a single server that sits on a port and handlesoH all the connections, you need to have your IP stack create a new processF for each incoming connection much the way that Telnet, FTP, POP, IMAP,F SAMBA etc. do it (depending on your IP software, some of these may notG work that way - they all do with Multinet). Then each user is running anH separateinstance of the server in the context of a process running underI their own username. This requires somewhere from a bit more to a lot moreeF resources then a single-server type operation, but that shouldn't be aG problem. It is what you used to do and it won't use more resources thanoF it used to, probably somewhat less - you are dropping X-windows acrossH a network (and X is not known for being light on the resource usage) for, comparatively simple network communications.  E A single server (or fixed pool of servers) solution probably requiresaJ modifying the server to, at the very least, use the Persona system sevicesH to change its context to that of the user who's request it is working on at the time.   --- Carl   ------------------------------  % Date: Sat, 15 Jul 2000 12:13:09 +0100 B From: Andrew Harrison SUNUK Consultancy <andrew.nospam@uk.sun.com>+ Subject: The URL that Compaq forgot to sendo* Message-ID: <39704744.FE0536BD@uk.sun.com>  @ I was trawling through www.tpc.org (as one does) today and to my: suprise I noticed that Compaq has posted TPC-C results for; the GS160 and GS320, my suprise being that the results were > posted on the 11th and today is the 15th and yet I can find no: mention of them posted by any of the usual OpenVMS backing
 vocalists.  4 Then I read the results and everything became clear.  2 To be fair to Compq this is only TPC-C and you can9 read too much into what is a relatively simple benchmark,r6 however it does somewhat damage Compaqs claims to have" the fastest system one the planet.  4 The 32 CPU GS320 result was slower than a 24 CPU IBM7 S80 and just ~5% faster than the E10000 number which is : a year older than the GS320 number using old Sun CPU's and6 a version of Oracle 2 major releases behind the Compaq number.n  4 The 16 CPU GS160 number was marginally faster than a4 smaller Sun E4500 and a Smaller HP N4000 while being6 slower than a smaller IBM M80. Not good and again both8 the Sun and the HP numbers are quite a lot older and the0 systems have improved in perfromance since then.  
 The URL is  http://www.tpc.org/whatsnew.html  9 What was the estimate posted to the group by one esteemeds5 Compaq watcher for the GS160, I remember 75,000 beingl touted arround.m  = I guess this is an early and unwelcome lesson in the vagaries ; of forcasting NUMA systems performance charicteristics thati6 Sequent learn't to their cost with the NUMA-Q systems.   Regardst   Andrew Harrisonn Enterprise IT Architectu   ------------------------------  % Date: Sat, 15 Jul 2000 12:30:17 -0400t' From: "Bill Todd" <billtodd@foo.mv.com>b/ Subject: Re: The URL that Compaq forgot to sendl( Message-ID: <8kq3ef$j3m$1@pyrite.mv.net>  E Andrew Harrison SUNUK Consultancy <andrew.nospam@uk.sun.com> wrote ino, message news:39704744.FE0536BD@uk.sun.com... >j > B > I was trawling through www.tpc.org (as one does) today and to my< > suprise I noticed that Compaq has posted TPC-C results for= > the GS160 and GS320, my suprise being that the results wered@ > posted on the 11th and today is the 15th and yet I can find no< > mention of them posted by any of the usual OpenVMS backing > vocalists. >T6 > Then I read the results and everything became clear. > 4 > To be fair to Compq this is only TPC-C and you can; > read too much into what is a relatively simple benchmark,t8 > however it does somewhat damage Compaqs claims to have$ > the fastest system one the planet.  K All right, you've had your moment of sarcastic triumph - and to some degreeiK you deserve it, since people who brag prematurely have a right to be called"H to account.  Hope you'll find that sufficient and get back to reasonable; discussion (which you've been doing fairly well at lately).    > 6 > The 32 CPU GS320 result was slower than a 24 CPU IBM9 > S80 and just ~5% faster than the E10000 number which iso< > a year older than the GS320 number using old Sun CPU's and8 > a version of Oracle 2 major releases behind the Compaq	 > number.u  E Yes, it was disappointing compared with the 150K number that had beeneJ bandied about.  20% under may not constitute a disaster, but it was enoughL to leave the S80 at the top of the heap (if one ignores the apparently bogusG Wintel number Compaq obtained with with a cluster-style configuration).   K I hope someone can come up with an explanation for the deficiency:  I don't C see one at first glance, though it has been suggested that L2 cacheb) performance could bear part of the blame.h   >y6 > The 16 CPU GS160 number was marginally faster than a6 > smaller Sun E4500 and a Smaller HP N4000 while being8 > slower than a smaller IBM M80. Not good and again both: > the Sun and the HP numbers are quite a lot older and the2 > systems have improved in perfromance since then.  F The GS160 number is relatively worse, but potentially explainable as aK configuration imbalance.  It had only 271 disks, vs. the M80's 416 (and the H HP's 248 + 14, but those were 10K rpm drives vs. the Wildfire's 7200 rpmG drives, so if the Wildfire was indeed disk-limited then the HP could be  expected to perform better).  F Such a bottleneck (if it indeed was the problem) is of course Compaq'sJ fault, but does not reflect poorly on the hardware, which all things beingL equal should have at least attained half the performance of the GS320 (whichJ had close to 3 times the number of disks used in the GS160 configuration -L hmmm).  And with more disks but less memory and fewer processors, the $/tpmC$ numbers would have improved as well.   - bill   >l > The URL is" > http://www.tpc.org/whatsnew.html > ; > What was the estimate posted to the group by one esteemeda7 > Compaq watcher for the GS160, I remember 75,000 being  > touted arround.e > ? > I guess this is an early and unwelcome lesson in the vagarieso= > of forcasting NUMA systems performance charicteristics thatu8 > Sequent learn't to their cost with the NUMA-Q systems. >o	 > Regardsl >c > Andrew Harrisonc > Enterprise IT Architecto >e >  >t   ------------------------------  % Date: Sat, 15 Jul 2000 13:25:36 -0400m- From: JF Mezei <jfmezei.spamnot@videotron.ca>r/ Subject: Re: The URL that Compaq forgot to send , Message-ID: <39709E8D.8C99AD1B@videotron.ca>   Bill Todd wrote:M > All right, you've had your moment of sarcastic triumph - and to some degreeiM > you deserve it, since people who brag prematurely have a right to be called-J > to account.  Hope you'll find that sufficient and get back to reasonable= > discussion (which you've been doing fairly well at lately).     M What I have a problem understanding is that the long brandied revolution withmN Wildfire, something which I had been lead to beleive that would truly have theK power to be the world's fastest computer, unrivalled by anyone else, with a1N revolutionary architecture unmatched by anyone else, seems to have materialiseM into just another "fast mini computer" whose speed is in the same ballpark as  other existing computers.n   So I have to ask this:  M If one were to consider Wildfire a failure since it hasn't revolutionised thecN performance of computers, would the Wildfire architecture be at fault, or justK the fact that the Alpha chip did not progress as fast as had originaly beenl6 predicted when Wildfire started to be brandied about ?  L In other words, If an alpha chip at 1ghz were available to day, would such aI wildfire machine not break all sorts of records ? Or would IBM mainframes 0 still be considered faster than those GS boxes ?   ------------------------------   Date: 15 Jul 2000 08:24:17 CDT= From: wayne@tachysoft.xxx.293778.killspam.0223 (Wayne Sewell)T  Subject: Re: VMS Pascal question. Message-ID: <4BYuMN2WwauR@tachxxsoftxxconsult>  y In article <418E68E524A8D311ACCE00508B78866A7680C1@exchange.t-netix.com>, Lorin Ricker <Lorin.Ricker@t-netix.com> writes:I6 >> And that's why the good old TeX on the VMS platform0 >> translates WEB into Pascal and not into C ... >  >> Ralfo >> --=20H >>   Ralf G=E4rtner                gaertner@cthulhu.westfalen.de (home & > preferred): >>   =D6tztalerstr. 5b             gaertner@decus.decus.deG >>   D - 81373 M=FCnchen           rgaertne@dbmail.debis.de      (work)P >>   FRGC >>          System/Network Manager & DECUS TeX Developer/Maintainer G >>     ~~~  Too old to Rock 'n Roll - too young to die (Jethro Tull)  =h > ~~~. >  > K > Bravo, Ralf!  I'm also a big TeX fan and user too, which tells you what =r > kindH > of an old, obsolete anachronism I'm getting to be!  ;-)  Sometimes I =	 > get the I > sense that today's vanguard of programmers is interested primarily in =r > makingG > pretty colored rectangles on screens, not programs that actually *do* - > anything useful, like compute something!...' > G > Actually, as I recall, Don Knuth wrote original versions of TeX *in =h
 > Pascal*,  N Well, yes and no.  As mentioned above, it is actually written in WEB (predatesI and is unrelated to the world wide web), which is a higher-level languagegK including code *and* documentation for the program.  A WEB program includes K both Pascal and TeX source.  You run the WEAVE processor against the source I file to get a TeX document, which becomes the documentation.  You run the N TANGLE processor against the same source file to get a Pascal source, which isM then compiled to be the executable code.  It is the one system where the codeM7 and documentation are *guaranteed* to be in synch.  :-)s    8 > with full intentions of multi-platform portability...   M A lot of that is actually provided by WEB rather than Pascal.  WEB contains a N mechanism called "change files", which contain implementation-specific stuff. K A change file basically says "replace particular chunks of code in the maintK file with these other chunks".  Both WEAVE and TANGLE merge the change file-H into the main file on the fly, so you can create implementation-specificN executables.  You would basically have a vms change file, a linux change file, etc.      M I would say see my book on the topic (Weaving a Program: Literate ProgrammingoK in WEB), but it's been out of print for a few years and is a little hard to.
 come by.  :-)    Wayne  --  O ===============================================================================-M Wayne Sewell, Tachyon Software Consulting  (281)812-0738  wayne@tachysoft.xxxk: http://www.tachysoft.xxx/www/tachyon.html and wayne.html  K change .xxx to .com in addresses above, assuming you are not a spambot  :-) O =============================================================================== O Otter, on dining with Bluto:"It's perfectly safe if you keep your arms and legs  			away from his mouth."   ------------------------------  % Date: Sat, 15 Jul 2000 11:42:26 -0400M2 From: rdeininger@mindspring.com (Robert Deininger)  Subject: Re: VMS Pascal questionL Message-ID: <rdeininger-1507001142270001@user-2ivebf7.dialup.mindspring.com>  m In article <4BYuMN2WwauR@tachxxsoftxxconsult>, wayne@tachysoft.xxx.293778.killspam.0223 (Wayne Sewell) wrote:C    P > Well, yes and no.  As mentioned above, it is actually written in WEB (predatesK > and is unrelated to the world wide web), which is a higher-level language M > including code *and* documentation for the program.  A WEB program includesiM > both Pascal and TeX source.  You run the WEAVE processor against the source K > file to get a TeX document, which becomes the documentation.  You run theeP > TANGLE processor against the same source file to get a Pascal source, which isO > then compiled to be the executable code.  It is the one system where the code 9 > and documentation are *guaranteed* to be in synch.  :-)- >  > : > > with full intentions of multi-platform portability...  > O > A lot of that is actually provided by WEB rather than Pascal.  WEB contains aeP > mechanism called "change files", which contain implementation-specific stuff. M > A change file basically says "replace particular chunks of code in the maincM > file with these other chunks".  Both WEAVE and TANGLE merge the change filecJ > into the main file on the fly, so you can create implementation-specificP > executables.  You would basically have a vms change file, a linux change file, > etc. >  >  > O > I would say see my book on the topic (Weaving a Program: Literate ProgrammingoM > in WEB), but it's been out of print for a few years and is a little hard toe > come by.  :-))  [ I never heard of this book.  Was it promoted by the old Digital stealth marketing division?e   What's the status of WEB these days?  Could I find a VMS version somewhere?  Are there dialects available that work with languages other than Pascal?  Ada perhaps?  Fortran?  I _like_ WEB, but I've never had it available!    I've often wondered why WEB did not catch on.  I sadly conclued that too many programmers are just too lazy.  The growth of c, oonix, and microsoft-certified quality has only reinforced my opinion.  Writing Knuth-quality code is hard [ work, and most folks can't be bothered.  (Many exceptions reading this newsgroup, I trust!)    TeX: The Program should be required study in CS programs.  Instead, kids are getting CS degress these days without reading (or writing) many programs longer than 2 pages.  . Sigh.  What happened to the Good Old Days? :-)   -- c Robert Deininger rdeininger@mindspring.com    ------------------------------   End of INFO-VAX 2000.393 ************************