1 INFO-VAX	Thu, 04 Mar 2004	Volume 2004 : Issue 127       Contents:+ Re: Best Backup Blocksize for 110SDLT Tape? + Re: Best Backup Blocksize for 110SDLT Tape? + Re: Best Backup Blocksize for 110SDLT Tape? + Re: Best Backup Blocksize for 110SDLT Tape? ; Re: Destroying CDR media (Was: Support of USB Memory stick)   Re: GTECH, Lotteries and OpenVMS  Re: GTECH, Lotteries and OpenVMS+ Re: Intel Article in Business Week Magazine  Re: Intel releases 64bit Xeon  Re: Intel releases 64bit Xeon : Re: It is almost certain now, INTEL will have 64bit x86 !!: Re: It is almost certain now, INTEL will have 64bit x86 !!: Re: It is almost certain now, INTEL will have 64bit x86 !! Re: It's all about perception!!  Re: It's all about perception!!  Re: It's all about perception!!  Re: It's all about perception!! # Re: Market for Alphastation 500/266 
 MX routing# Re: Not meaning to feed Andrew.....  Re: OpenVMS Feelings Re: OpenVMS Feelings Re: OpenVMS Feelings Re: OpenVMS FeelingsG Re: OpenVMS virus proof while other disks get zapped by latest viruses! & Re: Pathworks-32 and Windaube XPrience& Re: Pathworks-32 and Windaube XPrience Re: Recursive COPY Re: Recursive COPY Re: Recursive COPY Re: Recursive COPY Re: Sun On The Run?  Re: Sun On The Run?  Re: Sun On The Run?  Re: Support of USB Memory stick  Re: Support of USB Memory stick  Re: Support of USB Memory stick  Re: Support of USB Memory stick  Re: Support of USB Memory stick - Re: Uninterruptable Power Supplies for Alphas  upgrade path to Alpha 7.3...  Re: upgrade path to Alpha 7.3...+ Re: VMS Hobbyist License program abolished? + RE: VMS Hobbyist License program abolished? 2 Re: Why does smtp mail between local systems fail?2 Re: Why does smtp mail between local systems fail?2 Re: Why does smtp mail between local systems fail? Re: Zip/update Issue Re: Zip/update Issue3 Re: [GAME] you've been appointed VMS Mkt Mgr, so...  Re: [TCPIP V5.4] More rants   F ----------------------------------------------------------------------   Date: 3 Mar 2004 05:21:54 -0800 # From: axica_nopub@yahoo.com (Safir) 4 Subject: Re: Best Backup Blocksize for 110SDLT Tape?= Message-ID: <2b49c9e0.0403030521.1df12a08@posting.google.com>    > H > I have been told by more than a couple System Manager that the maximumF > backup block size should be the same as the default backup blocksizeE > when you are backing up from disk to disk which is 32256. Any block F > size other greater than 32256 will cause the backup restore to fail.B > Thus makeing the backup useless. This isn't theory because thoseH > System Managers actually tested the backup and restores with different > blocksize for proof. >   > I think you mean the $ copy will fail with block size > 32256.  ( The restore vith backup should succeed :  N [OpenVMS] Copying Save Set From Tape To Disk Fails With OPENIN And IRC Errors L Copyright (c) 1987, 2000. Compaq Computer Corporation.  All rights reserved.  . PRODUCT:    Compaq OpenVMS Alpha, All Versions,             Compaq OpenVMS VAX, All Versions   COMPONENT:  BACKUP  ' SOURCE:     Compaq Computer Corporation      SYMPTOM:  B Commands similar to the following were used to successfully copy a? Backup save set (using the DCL COPY command) from disk to tape:   5      $ MOUNT/BLOCK=32768/RECORD=32768/OVER=ID $TAPE1:       $ COPY/LOG $TAPE1:*.* *  B However, when you attempt to copy that same save set from the tape/ back to disk, you receive the following errors:   F      %COPY-E-OPENIN, error opening $TAPE1:[]save_set_name.bck as inputC      -RMS-F-IRC, illegal record encountered, VBN or record number=0   :      Note: This error also occurs for tape to tape copies.    	 SOLUTION:   F When you intend to use the DCL command "COPY" to move Backup save sets? to and from tape, make sure the Backup command that creates the G save set specifies a block size of 32256 or less.  You can then use the G block size value that you specify, or that Backup rounds up to, in your 8 MOUNT command to successfully copy to and from the tape.    	 ANALYSIS:   ? When copying from tape, Record Management Services (RMS) uses a E maximum record size of 32767.  Because the size of the records on the B tape save set are larger than the maximum record size allowed when9 copying from tape to disk, the save set cannot be copied.   8 Note: This limitation also exists for tape to tape copy.  E When the Backup save set was originally created on disk, the /BLOCK=n @ qualifier was specified.  The value for the /BLOCK qualifier was@ either 32768 or a number greater than 32256 and less than 32768.E Backup will round up the block size specified in the /BLOCK qualifier = to the next highest multiple of 512 if not already on a block A boundary.  This behavior is documented in the "VMS Backup Utility 0 Manual", April 1988, (AA-LA35A-TE), page BCK-32.  J Note: Utilities that may be helpful in tape to tape (or disk to tape) copyJ       regardless of the block size can be found at the following web-site:         http://www.decus.org   ------------------------------  % Date: Thu, 04 Mar 2004 13:10:18 +0100 * From: Paul Sture <nospam@sture.homeip.net>4 Subject: Re: Best Backup Blocksize for 110SDLT Tape?0 Message-ID: <40472ABA.39AD29E1@sture.homeip.net>   Daryl Jones wrote: >  > Dear Paul Sture: > D > This has been reported to me from the 1990s to 1998 (VMS 5.5-2h toC > 7.0?)where my last discussion took place. These are restores from E > BACKUP savesets by BACKUP and not by COPY. The single extraction of F > files may be successful, however, the full restoration appears to beH > the problem when multiple tapes are used. With the DLT Tape systems, aF > whole disk can be backup on one tape and therfore, this may not be aG > problem? The problem appears when the backup saveset starts on volume A > one and continues to volume 2. Again, this is my understanding.  >   @ I've never seen that problem, although I must say that since theG mid-1990s I have adopted the practice of using 32256 as the block size, ! so that a COPY to disk will work.    That has 2 advantages:  C 1. It is a lot faster and easier to perfom multiple file selections <    from a saveset on disk - no tape rewinds to contend with.  A 2. On a few occasions I have managed to restore a saveset to disk =    using COPY, when BACKUP was failing with too many retries.    --  
 Paul Sture   ------------------------------  % Date: Thu, 04 Mar 2004 15:30:11 +0100 * From: Paul Sture <nospam@sture.homeip.net>4 Subject: Re: Best Backup Blocksize for 110SDLT Tape?0 Message-ID: <40474B83.56839306@sture.homeip.net>   John Laird wrote:  > J > On Thu, 04 Mar 2004 13:10:18 +0100, Paul Sture <nospam@sture.homeip.net> > wrote: >  > >Daryl Jones wrote:  > >> > >> Dear Paul Sture:  > >>G > >> This has been reported to me from the 1990s to 1998 (VMS 5.5-2h to F > >> 7.0?)where my last discussion took place. These are restores fromH > >> BACKUP savesets by BACKUP and not by COPY. The single extraction ofI > >> files may be successful, however, the full restoration appears to be K > >> the problem when multiple tapes are used. With the DLT Tape systems, a I > >> whole disk can be backup on one tape and therfore, this may not be a J > >> problem? The problem appears when the backup saveset starts on volumeD > >> one and continues to volume 2. Again, this is my understanding. > >> > > C > >I've never seen that problem, although I must say that since the J > >mid-1990s I have adopted the practice of using 32256 as the block size,$ > >so that a COPY to disk will work. > >  > >That has 2 advantages:  > > F > >1. It is a lot faster and easier to perfom multiple file selections? > >   from a saveset on disk - no tape rewinds to contend with.  > > D > >2. On a few occasions I have managed to restore a saveset to disk@ > >   using COPY, when BACKUP was failing with too many retries. > K > Everything Paul said.  The notion of vanilla BACKUP failing simply due to K > the use of large but supported blocksizes is completely new to me.  (It's L > had other nasty bugs after rewrites, but nothing fundamentally broken like2 > this.)  I too always advocate 32256-byte blocks. > N > On the second point, I think COPY is a bit sensitive to errors and may stallM > or may carry on and then subsequent on-disk BACKUP operations can deal with L > erroneous blocks using CRC and redundancy group information.  I had a playN > with creating ODS-2 structures on CDRs, holding various backup savesets, andL > then found my (crappy) PC CD burner was creating disks with parity errors.M > I thought I was snookered (COPY just completely stalled) until I discovered J > that BACKUP knows a bit more about ODS-2 than it lets on and was in factH > quite happy to dig into [named-dir] looking for named.fil even on a CD( > mounted /foreign !  The little minx... >   F Interesting snippet thanks. About 20 years ago I had a disk which lostH or gained a bit in one of the main MFD filenames (I don't remember which one).   F I decided to rename it back to what it should be (again don't remember' how, but I was probably being devious).   , Disaster - I'd lost the directory structure!  A But BACKUP did manage to get the files off disk, although not the E directories to which each file belonged. I managed to reconstruct the A disk as it should be using a mixture of file ownership and backup G journals. I was pretty impressed by BACKUP's ability to recover in that 
 situation.   --  
 Paul Sture   ------------------------------   Date: 4 Mar 2004 10:47:35 -0800 7 From: jones.computer.srv@worldnet.att.net (Daryl Jones) 4 Subject: Re: Best Backup Blocksize for 110SDLT Tape?< Message-ID: <8a646952.0403041047.66ba2e3@posting.google.com>   Dear John Santos:   E The issue is not that it may pertain to 9 track tapes only. The issue A raised was that is or was a problem with tape backup and restores @ using block size greater than 32256 and nobody had a solution or; understanding of the problem. That by itself is worry some.   D What you are sugggesting is the problem doesn't exist because of theB hardware performance is much better. On small sites where multipleD savesets can be stored on one tape. I'll buy in to it. However, whatF about multi-volume savesets with a large block size? I don't know manyF System Managers or DBAs using VMS and Backup that had to rebuild theirD site from tape except for maybe the WTC?  Maybe the problem isn't or% wasn't cause by Multi-volume saveset?      Regards, Daryl Jones       ^ John Santos <JOHN@egh.com> wrote in message news:<1040303234647.15727A-100000@Ives.egh.com>...( > On Thu, 4 Mar 2004, Tom Simpson wrote: > O > > One factor (especially with older tape drives and lower bit densities) that O > > could be a problem is the physical length of tape it takes to write a large K > > block of data.  Last time I checked, the standard distance from the EOT P > > marker to the physical end-of-tape is roughly 15-20 feet.  If 20 feet is notN > > enough space to fit a data block, then the backup could fail.  The typicalP > > symptom would be the tape runs off the end of the reel (on 9 track tapes for
 > > example).  > > N > > The way a tape drive works (at least the way they used to work...I'm goingO > > way back here...) is that they attempt to finish writing the block they are L > > currently on, even if it is past the EOT marker.  If there is not enough? > > physical tape left to complete the block, the party's over.  > > J > > With the MUCH higher bit densities of today's tape drives, I think theL > > likelihood of that happening is very small, if it could happen at all...K > > This is, of course, speculation on my part triggered by first-hand (and K > > out-of-date) tape drive technology knowledge...  Even at 6250BPI, a 64K 4 > > block of data would take a lot of tape to write.O > > That would be roughly ((64000blocks * 512 bytes per block) / 6250 bpi) / 12  > > = 436 ft. ?? > F > A 64K block contains 64000 (or 65536 bytes, if "K" means 1024).  YouF > are multiplying by 512 unnecessarily.  So on a 6250bpi tape, this isC > 10.24 inches.  Should easily fit before the physical end-of-tape. C > (It also requires a tape mark, some EOV labels, and a couple more E > tape marks.  IIRC, 9-track tape marks are 1/2 inch, irrespective of  > density.)  > G > At 800bpi, the record is 80 inches, (6'8"), so this is getting really  > iffy.  > D > In either case, if there is a bad spot on the tape, the drive willE > space forward looking for good tape and with records this long, you A > could be in "reel" trouble :-)  Everyone should have the fun of F > reloading a 9-track tape from the end by hand, at some time in their > life!  > @ > But this thread was about SDLT, not 9-track, and 32256 is onlyA > relevent to disk save-sets, not tape save-sets, so we're really  > getting off-track here.  >  >  > >  > > Regards, > > Tom  > > H > > "Daryl Jones" <jones.computer.srv@worldnet.att.net> wrote in message: > > news:8a646952.0403022253.69a3161@posting.google.com... > > > Dear David J. Dachtera:  > > > L > > > I have been told by more than a couple System Manager that the maximumJ > > > backup block size should be the same as the default backup blocksizeI > > > when you are backing up from disk to disk which is 32256. Any block J > > > size other greater than 32256 will cause the backup restore to fail.F > > > Thus makeing the backup useless. This isn't theory because thoseL > > > System Managers actually tested the backup and restores with different > > > blocksize for proof. > > > D > > > Could you further explain to me or provide a reference on your, > > > recommendation that you have provided. > > > 
 > > > Thanks,  > > > Daryl Jones  > > >  > > > I > > > "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in = >  message news:<40453492.27B758CE@NeOaSrPtAhMlNiOnWk.net>...  > > > > Hal Kuff wrote: 	 > > > > > J > > > > >     In search of best blocksize for SDLT tape at 110GB.... using
 >  MSL5026M > > > > > tape library over 1gb Fibre Channel to OpenVMS ES40 type systems on  >  1gbE > > > > > Fibre Channel...... Have not seen the 50-60% improvement in  >  performance we . > > > > > expected over DLT8000/DLTIV Tape....	 > > > > > O > > > > >    Can anyone reccomend an init, mount, and backup command that works  >  for > > > > > your site... > > > > L > > > > Before you go digging that deep, check that your NSRs are configuredP > > > > correctly. Make sure that the SCSI cards are in the high-numbered slots,P > > > > not the low. That will approximately double your throughput if they were > > > > wrong before.  > > > > M > > > > Otherwise, the usual rules still apply: us ethe largest blocksize you M > > > > can live with: 65024 if you don't need to read the savesets with RMS, " > > > > less than 32767 if you do. > >  > >  > >  > >    ------------------------------   Date: 4 Mar 2004 09:24:51 -0800 . From: alexdaniels@themail.co.uk (Alex Daniels)D Subject: Re: Destroying CDR media (Was: Support of USB Memory stick)= Message-ID: <9f7f13a8.0403040924.5fddfcba@posting.google.com>   j Chris Scheers <chris@applied-synergy.com> wrote in message news:<40464CF9.66638A33@applied-synergy.com>... > Nic Clews wrote: > L > > Yes. [In a certain case] the current proposal is a tape solution to moveK > > relatively (less than 100 meg) small amounts of data from one system to H > > another. CDR was investigated, but due to the nature of the data add/ > > complications to destroying the used media.  > 3 > I thought that was what microwave ovens were for.  > A > And the associated light show is an entertaining bonus.  <grin>   C The light show is most entertaining, although one ex-girlfriend did D seem to have her objections me using her microwave for this purpose.  B As for it being an effective means of erasing the data, I'm not soC sure.. the CD is thin bit of metal foil attached to a polycarbonate A disc. The microwave munches up the foil into lots of tiny pieces.   F I would imagine one could with enough time and effort, take these tinyF bits and with the right equipment read a small amount of data off each= one. Depends how important truly erasing the data is I guess.    ------------------------------  $ Date: Wed, 3 Mar 2004 14:16:12 +0100  From: "Dr. Dweeb" <dr@dweeb.com>) Subject: Re: GTECH, Lotteries and OpenVMS - Message-ID: <c24lr6$14op$1@news.cybercity.dk>    Fabio Cardoso wrote:? > The GTECH company from USA is involved in some fraudulent and 6 > corrupt actions in the brazilian Lotteries controled > by the State.  > A > Checking it I discovered this company in HP sites as an OpenVMS 
 > partner. > 8 > http://h71000.www7.hp.com/solutions/finance/gtech.html > G > The same company is involved with some strange facts when George Bush C > was the Texas Governor.  He cancelled all the other lotteries and D > gave them to GTECH. The president of GTEC Ben Barnes helped George! > Bush to leave the Vietnam war !  > 	 > Regards  >  > FC  I IIRC this company is the largest lottery systems software provider in the G world with a 50%+ market share world wide.  A great many of the lottery K systems providers use OpenVMS usually with Rdb for the back office systems.   	 Dr. Dweeb    ------------------------------  $ Date: Thu, 4 Mar 2004 07:46:10 -0600( From: Wayne Sewell <wayne@tachysoft.com>) Subject: Re: GTECH, Lotteries and OpenVMS / Message-ID: <00A2E545.39382B09.3@tachysoft.com>   ) >          Thu, 4 Mar 2004 03:47:38 -0600 ! >From: "Dr. Dweeb" <dr@dweeb.com>  >X-Newsgroups: comp.os.vms* >Subject: Re: GTECH, Lotteries and OpenVMS% >Date: Wed, 3 Mar 2004 14:16:12 +0100  >Organization: Cybercity   >  >Fabio Cardoso wrote: @ >> The GTECH company from USA is involved in some fraudulent and7 >> corrupt actions in the brazilian Lotteries controled  >> by the State. >>B >> Checking it I discovered this company in HP sites as an OpenVMS >> partner.  >>9 >> http://h71000.www7.hp.com/solutions/finance/gtech.html  >>H >> The same company is involved with some strange facts when George BushD >> was the Texas Governor.  He cancelled all the other lotteries andE >> gave them to GTECH. The president of GTEC Ben Barnes helped George " >> Bush to leave the Vietnam war ! >> > J >IIRC this company is the largest lottery systems software provider in theH >world with a 50%+ market share world wide.  A great many of the lotteryL >systems providers use OpenVMS usually with Rdb for the back office systems. >     N Back in the mid nineties, they used SYBASE (back when there *was* a sybase forO vms).  While lotteries are their main gag, I did some contract work for them on H a non-lottery project (the Texas Lone Star Card, which was an electronic benefits transfer system).   Wayne O =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html    O =============================================================================== B Jed Clampett, checking into hotel: "This place got a cement pond?", 	Ellie May: "And do yuh let critters in it?"   ------------------------------  # Date: Wed, 03 Mar 2004 17:25:33 GMT 9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> 4 Subject: Re: Intel Article in Business Week Magazine/ Message-ID: <hyo1c.106$Vn2.68@news.cpqcorp.net>   6 "Bill Johnson" <res0xcil@verizon.net> wrote in message2 news:w2d1c.32998$C65.28358@nwrddc01.gnilink.net...H > So the question is - with alpha now dead and at end of life, and IntelI > scrapping the Itanium in favor of it 32 bit chip with 64bit extensions, D > where does VMS run and have real longevity on a processor platform	 customers  > can count on?  >   L Intel isn't scrapping Itanium.  Alpha isn't yet at EOL either - plenty being built and sold every day.    ------------------------------  # Date: Wed, 03 Mar 2004 18:57:21 GMT & From: Rick Jones <foo@bar.baz.invalid>& Subject: Re: Intel releases 64bit Xeon. Message-ID: <lUp1c.118$nk2.6@news.cpqcorp.net>  P Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote: > Rick Jones wrote:   F >> I don't believe the LV requires the Intel E8870 chipset.  It can beF >> run in the zx1 chipset just fine.  I don't have numbers for the zx1 >> chipset vs the Intel E8870.  / > Feel free to publish them when you have them.   D I hope to connect my trusty P3 International P4400 power meter to anC rx1600 one of these days. That won't give me the power draw for the , chipset itself, but the system as a whole.    D BTW, speaking of CPU power draw, a slight drift with which you might8 be able to help me - in looking at the power figures forE UltraSPARC-III CU compared with UltraSPARC IIIi, the 1 GHz IIIi seems E to be at 59 where the Cu appears to be at 53 (some references say 53, C some say 50, I'm not sure if the 53 is supposed to be the 1.2 GHz).   E I've assumed that the IIIi's power draw was higher because it had the F 1MB on chip cache. What I'm not so sure of is whether or not the powerB consumption figures for the Cu include the 8MB off-chip cache.  Do? Sun's published power consumption figures for the III Cu (and I 8 suppose by extension the IV) include the external cache?  C > Incedentally the prices for the LV Itanium 2 based rx2600 are now B > available. A 2 CPU, 2 GB 2 disk config costs $6410, compare this( > with a faster (int) Sun V20z at $4245.  9 Bully for Sun :)   I guess I'll have to go price a DL145.   < > And since your benchmark du jour seems to be SPECweb99_sslC > Sun just published a 2 CPU v20z (248) Opteron result running Zeus    > 		SPECweb99_SSL	 > Sun v20z	2340  > HP rx1600	1278		  ' Yep - saw that.  Makes a nice target :)    rick   --  = denial, anger, bargaining, depression, acceptance, rebirth... C                                      where do you want to be today? F these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...    ------------------------------  % Date: Wed, 03 Mar 2004 17:25:22 +0000 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> & Subject: Re: Intel releases 64bit Xeon0 Message-ID: <c254e2$hff$1@new-usenet.uk.sun.com>   Rick Jones wrote: R > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote: >  > ? >>The LV Itanium consumes 62 watts and requires the Intel E8870 
 >>chipset. >  > E > I don't believe the LV requires the Intel E8870 chipset.  It can be E > run in the zx1 chipset just fine.  I don't have numbers for the zx1  > chipset vs the Intel E8870.  >   - Feel free to publish them when you have them.   2 Incedentally the prices for the LV Itanium 2 based. rx2600 are now available. A 2 CPU, 2 GB 2 disk4 config costs $6410, compare this with a faster (int) Sun V20z at $4245.  : And since your benchmark du jour seems to be SPECweb99_sslA Sun just published a 2 CPU v20z (248) Opteron result running Zeus    		SPECweb99_SSL	
 Sun v20z	2340  HP rx1600	1278		     Regards  Andrew Harrison    ------------------------------  % Date: Wed, 03 Mar 2004 16:46:30 +0000 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> C Subject: Re: It is almost certain now, INTEL will have 64bit x86 !! 0 Message-ID: <c25257$gmo$1@new-usenet.uk.sun.com>   Rick Jones wrote: R > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote: >  >>Rick Jones wrote:  >>S >>>Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote:  >  > B >>What exactly don't you understand ? the MAXCPU configs on F15K'sB >>or the differences between this and the configuration of a 8400. >  > D >>Discussions about trading the 17 I/O slots (you need 1) for MAXCPUH >>cards in F15K's are irrelevent in a discussion about the configuration& >>restrictions of an AlphaServer 8400. >  > G > Tell you what - you can pick first - which would you like to be?  The + > pot? Or the Kettle?  I'll take the other.  > @ > I didn't say the tradeoffs were identical, I said they soundedF > similar.  They are similar in that if you want the maximum CPU countF > on the 15K, you have to have the minimum I/O count.  If you want theE > maximum I/O, you could not have the maximum CPUs on the 15K.  I see & > that as similar, perhaps you do not. >   D However since this discussion was about a 64bit OS to support a DBMS= being able to open very large amounts of memory the fact that @ you can do this on a F15K with a very large number of CPU's (72)D a very large amount of memory (576 GB) and a very high I/O bandwidth3 tends to rather destroy the point of your argument.   D The problem with the 8400 was that if you wanted say 12GB of RAM youA had to make choices about the number of CPU's and I/O controllers  to configured into the system.  ; Perhaps a better understanding of the 8400 architecture and 8 its limittations would have stopped you entering what is0 a rather ridiculous rat hole of your own making.    F >>Unlike HP who just count the maximum bandwidth of the CELL board I/O* >>bridge x 16 ! sounds just as scientific. >  > C > It is at least self-consistent as each of the up to 192 PCI-X I/O E > Slots is its own PCI-X bus and so there is at least the theoretical  > prospect of getting there. > E > "There are 192 I/O cards in the system, each with its own dedicated F > I/O bus" from "Meet the HP Integrity Superdome servers A white paper > from Hewlett-Packard Company"  >  > F >>Or claiming a maximum backplane bandwidth on the Integrity SuperDomeF >>and SuperDome of 64 GB/s despite only managing less than 1/2 of that >>on a non MPI Streams result. >  > I >>>Perhaps I make a math mistake somewhere, but can you tell me how it is G >>>possible to have up to 21.5 GB/s of sustained I/O rate when the peak G >>>marketing bandwidth of the I/O busses on the system aren't much more  >>>than 1/2 that?  >>>  >  > & >>Because your maths isn't that good ! >  > F > Very well, please correct it - how many distinct PCI busses, of what, > frequency and width are there in the F25K? >   < A fully configured F25K has 54 x 66Mhz 64 bit PCI busses and 18 x 33 Mhz 64 bit PCI busses.  8 The peak bandwidth of a 33 Mhz 64bit PCI bus is 264 MB/s8 The peak bandwidth of a 66 Mhz 64bit PCI bus is 528 MB/s  9 At this point you should have realised that your maths is : duff but I since your contribution to this thread has been( dubious I will do the math to rub it in.   18 x 264 = 4752 MB/s 54 x 528 = 28512 MB/s    28512 + 4752 = 33264 MB/s   C Rather more than we claim as the sustained thoughput of the system.   < To be fair I usually use 200 MB/s for 33 and 400 MB/s for 66; which gives a number of 25200 MB/s still more than we claim  > H >>>>So what sort of I/O rate can you sustain through an Oracle DBMS on a >>>>SuperDome ?  >>>  >>> B >>>No idea.  I suppose that if someone were to poke around variousC >>>benchmark disclsoures some guesstimates of I/O rates for _those_ G >>>workloads could be made.  To my knowledge, HP haven't done "just" an I >>>"Oracle table scan" and published numbers.  BTW, I would be curious to C >>>know more of the details of that table scan, if you would please 6 >>>provide a URL with the details that would be great. >>>  >  > H >>>The "if you want the RAM you have to have the CPUs" tradeoff seems to >>>remain from the 15K.  >  > @ >>Sorry but again this is incorrect the tradeoff only existed in >>your imagination.  >  > > >>A F4900-F25K system board supports 4 CPU's and 32 GB of RAM.= >>A F4800-F15K system board supports 4 CPU's and 32 GB of RAM  >  > H > I don't think the tradeoff was imaginary - what I claimed what that if2 > you wanted the RAM, you _have_ to have the CPUs. >   9 A sort of reverse tradeoff, in the context of this thread 1 its an irrelevant point but feel free to make it.   C > So, specific question time again - Is it possible to have an F25K F > system board with what Sun calls one CPU and access RAM in _all_ the" > DIMM slots on that system board? >   = No, but does this have any relevance to the discussion ??????      > rick jones > D > BTW, I'm still waiting for you to give the URL with the details ofD > that Oracle table scan number you referenced.  Stuff like how manyF > HBA's, number and type of storage, number and type of CPUs, quantityD > of RAM, size of the table, size of the caches on the storage, that > sort of stuff. >   * Full details are only available under NDA.  F Basic config details 188 T3B arrays with a total of 3384 x 72 GB 10000< RPM drives. All storage protected either RAID 0+1 or RAID 5.  - F15K with 72 x 900 Mhz UltraIIIcu processors. * 18 x I/O assemblies 71 x Sun 2G FC PCI HBA  % 12.3 GB/s sustained sequential reads.    Regards  Andrew Harrison    ------------------------------  # Date: Wed, 03 Mar 2004 18:35:05 GMT & From: Rick Jones <foo@bar.baz.invalid>C Subject: Re: It is almost certain now, INTEL will have 64bit x86 !! / Message-ID: <tzp1c.114$nk2.85@news.cpqcorp.net>   ' >>>Because your maths isn't that good !  >>   >>  G >> Very well, please correct it - how many distinct PCI busses, of what - >> frequency and width are there in the F25K?  >>    > > A fully configured F25K has 54 x 66Mhz 64 bit PCI busses and  > 18 x 33 Mhz 64 bit PCI busses.  : > The peak bandwidth of a 33 Mhz 64bit PCI bus is 264 MB/s: > The peak bandwidth of a 66 Mhz 64bit PCI bus is 528 MB/s  $ where M == 1000^2 rather than 1024^2  ; > At this point you should have realised that your maths is < > duff but I since your contribution to this thread has been* > dubious I will do the math to rub it in.  @ Given that the only concrete description I could find on the SunF website of an I/O board was for the 15K that said there was one 66 MHzE bus and one 33 MHz bus and this appears to be the first time you have ? asserted a bus count for the newer I/O boards, just how was one , supposed to know how many busses there were?   > 18 x 264 = 4752 MB/s > 54 x 528 = 28512 MB/s    > 28512 + 4752 = 33264 MB/s   E > Rather more than we claim as the sustained thoughput of the system.   L Good then to see that the mistake make on the 15K description was corrected.  > > To be fair I usually use 200 MB/s for 33 and 400 MB/s for 66= > which gives a number of 25200 MB/s still more than we claim   G Could you provide a URL to the document describing there being three 66 ) MHz busses on the new I/O board?  Thanks.   , > Full details are only available under NDA.  
 Convenient :)   B > Basic config details 188 T3B arrays with a total of 3384 x 72 GBD > 10000 RPM drives. All storage protected either RAID 0+1 or RAID 5.  / > F15K with 72 x 900 Mhz UltraIIIcu processors. , > 18 x I/O assemblies 71 x Sun 2G FC PCI HBA  ' > 12.3 GB/s sustained sequential reads.   ? I take it the table size and memory size of the system are only  allowed under NDA?  
 rick jones --  = portable adj, code that compiles under more than one compiler F these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...    ------------------------------  % Date: Wed, 03 Mar 2004 19:42:55 +0100  From: Dirk Munk <munk@home.nl>C Subject: Re: It is almost certain now, INTEL will have 64bit x86 !! 2 Message-ID: <c25a06$p39$1@news2.tilbu1.nb.home.nl>  ( Andrew Harrison SUNUK Consultancy wrote: > Rick Jones wrote:  > % >> Andrew Harrison SUNUK Consultancy  1 >> <Andrew_No.Harrison_No@nospamn.sun.com> wrote:  >> >>> Rick Jones wrote:  >>> ' >>>> Andrew Harrison SUNUK Consultancy  3 >>>> <Andrew_No.Harrison_No@nospamn.sun.com> wrote:  >> >> >>D >>> What exactly don't you understand ? the MAXCPU configs on F15K'sD >>> or the differences between this and the configuration of a 8400. >> >> >>F >>> Discussions about trading the 17 I/O slots (you need 1) for MAXCPUJ >>> cards in F15K's are irrelevent in a discussion about the configuration( >>> restrictions of an AlphaServer 8400. >> >> >>H >> Tell you what - you can pick first - which would you like to be?  The, >> pot? Or the Kettle?  I'll take the other. >>A >> I didn't say the tradeoffs were identical, I said they sounded G >> similar.  They are similar in that if you want the maximum CPU count G >> on the 15K, you have to have the minimum I/O count.  If you want the F >> maximum I/O, you could not have the maximum CPUs on the 15K.  I see' >> that as similar, perhaps you do not.  >> > F > However since this discussion was about a 64bit OS to support a DBMS? > being able to open very large amounts of memory the fact that B > you can do this on a F15K with a very large number of CPU's (72)F > a very large amount of memory (576 GB) and a very high I/O bandwidth5 > tends to rather destroy the point of your argument.t  O Was there a F15K when the 8400 was on the market? By the way the 8400 max. I/O  M configuration was 12 hoses with 12 PCI slots each, or 144 PCI slots in total.i    O You can get a GS1280 with 64 cpu's, or (on special request) one with 128 cpu's.MM I don't know how may PCI slots it will support, but even a ES80 with 8 cpu's t1 will support 64 PCI/PCI-X slots and 64 GB memory.!   > F > The problem with the 8400 was that if you wanted say 12GB of RAM youC > had to make choices about the number of CPU's and I/O controllerst  > to configured into the system.  O What is the purpose of writing about the ancient 8400? Most of those will have k1 been scrapped by now. We did over the past years.e  I The point was that a 64 bit *architecture* was developed on which 64 bit pO operating systems could run that were capable of addressing lots of memory. It eO was all about *vision*, about future directions, and setting up a path to that kQ future. At the time the Alpha appeared, memory was still very expensive, about a OP 100 times more expensive then now. I doubt if anyone could have build a working * computer with let's say 128GB at the time.   > = > Perhaps a better understanding of the 8400 architecture and : > its limittations would have stopped you entering what is2 > a rather ridiculous rat hole of your own making. >  > H >>> Unlike HP who just count the maximum bandwidth of the CELL board I/O, >>> bridge x 16 ! sounds just as scientific. >> >> >>D >> It is at least self-consistent as each of the up to 192 PCI-X I/OF >> Slots is its own PCI-X bus and so there is at least the theoretical >> prospect of getting there.e >>F >> "There are 192 I/O cards in the system, each with its own dedicatedG >> I/O bus" from "Meet the HP Integrity Superdome servers A white paper-  >> from Hewlett-Packard Company" >> >>H >>> Or claiming a maximum backplane bandwidth on the Integrity SuperDomeH >>> and SuperDome of 64 GB/s despite only managing less than 1/2 of that  >>> on a non MPI Streams result. >> >> >>K >>>> Perhaps I make a math mistake somewhere, but can you tell me how it ismI >>>> possible to have up to 21.5 GB/s of sustained I/O rate when the peakiI >>>> marketing bandwidth of the I/O busses on the system aren't much more  >>>> than 1/2 that?t >>>> >> >>( >>> Because your maths isn't that good ! >> >> >>G >> Very well, please correct it - how many distinct PCI busses, of whatl- >> frequency and width are there in the F25K?t >> > > > A fully configured F25K has 54 x 66Mhz 64 bit PCI busses and  > 18 x 33 Mhz 64 bit PCI busses.  P Busses or slots? How many slots in a bus ? A standard PC for instance has 1 PCI D bus, with 5 slots. All slots have to share the bandwidth of the bus.   > : > The peak bandwidth of a 33 Mhz 64bit PCI bus is 264 MB/s: > The peak bandwidth of a 66 Mhz 64bit PCI bus is 528 MB/s > ; > At this point you should have realised that your maths isp< > duff but I since your contribution to this thread has been* > dubious I will do the math to rub it in. >  > 18 x 264 = 4752 MB/s > 54 x 528 = 28512 MB/s  >  > 28512 + 4752 = 33264 MB/s= > E > Rather more than we claim as the sustained thoughput of the system.t > > > To be fair I usually use 200 MB/s for 33 and 400 MB/s for 66= > which gives a number of 25200 MB/s still more than we claimi >  >>J >>>>> So what sort of I/O rate can you sustain through an Oracle DBMS on a >>>>> SuperDome ?e >>>> >>>> >>>>D >>>> No idea.  I suppose that if someone were to poke around variousE >>>> benchmark disclsoures some guesstimates of I/O rates for _those_oI >>>> workloads could be made.  To my knowledge, HP haven't done "just" aneK >>>> "Oracle table scan" and published numbers.  BTW, I would be curious toeE >>>> know more of the details of that table scan, if you would please 8 >>>> provide a URL with the details that would be great. >>>> >> >>J >>>> The "if you want the RAM you have to have the CPUs" tradeoff seems to >>>> remain from the 15K.  >> >> >>B >>> Sorry but again this is incorrect the tradeoff only existed in >>> your imagination.m >> >> >>@ >>> A F4900-F25K system board supports 4 CPU's and 32 GB of RAM.? >>> A F4800-F15K system board supports 4 CPU's and 32 GB of RAMi >> >> >>I >> I don't think the tradeoff was imaginary - what I claimed what that ifK3 >> you wanted the RAM, you _have_ to have the CPUs.  >> > ; > A sort of reverse tradeoff, in the context of this threadf3 > its an irrelevant point but feel free to make it.t > D >> So, specific question time again - Is it possible to have an F25KG >> system board with what Sun calls one CPU and access RAM in _all_ thee# >> DIMM slots on that system board?b >> > ? > No, but does this have any relevance to the discussion ??????  >  > 
 >> rick jones  >>E >> BTW, I'm still waiting for you to give the URL with the details of-E >> that Oracle table scan number you referenced.  Stuff like how manyuG >> HBA's, number and type of storage, number and type of CPUs, quantityDE >> of RAM, size of the table, size of the caches on the storage, thate >> sort of stuff.r >> > , > Full details are only available under NDA. > H > Basic config details 188 T3B arrays with a total of 3384 x 72 GB 10000> > RPM drives. All storage protected either RAID 0+1 or RAID 5. > / > F15K with 72 x 900 Mhz UltraIIIcu processors.e, > 18 x I/O assemblies 71 x Sun 2G FC PCI HBA > ' > 12.3 GB/s sustained sequential reads.s  M Not very impressive if you need 3384 disks to do it. One 10000 rpm 72GB disk f2 should be able to spit out 100MB/sec (sequential).   > 	 > Regardsp > Andrew Harrisonv    P By the way, you accused me of having the facts wrong on the E4900. I showed you O where the information came from (the SUN web site), and since then it was very o) quiet, I haven't seen any reply from you.c   ------------------------------  # Date: Wed, 03 Mar 2004 11:35:12 GMT # From: "John Smith" <a@nonymous.com>e( Subject: Re: It's all about perception!!I Message-ID: <Qpj1c.81614$ah.8304@twister01.bloor.is.net.cable.rogers.com>    Dirk Munk wrote: > Bill Gunshannon wrote:B >> I would suggest those who still have doubts about how the world@ >> percieves VMS should read the latest copy of The Risks Digest" >> (also available as comp.risks). >> >> billm >> > This is what you mean? : >s" > Re: Buffer overflows and Multics) > <Michael LeVine <mlevine@redshift.com>>i! > Thu, 26 Feb 2004 09:01:59 -0800  >TA > IIRC the late VAX/VMS systems also had built in buffer overflow>B > prevention features, probably a lesson learned from Multics. TheF > hardware had protections that could be set on memory segments to be:D > Execute/No execute and read only/write only/read-write, and the OSC > system calls requiring buffers also had to have the length of thee > buffers specified. >s >y# > ---------------------------------t >tA > I agree, it does show that Carly's statement that "OpenVMS is aWG > strategic product for HP" has reached the IT industry load and clear.n  F No message leaves the lips of the chairperson of a major multinationalJ corporation that they don't want the world to hear. And when a chairpersonH makes statements like that they always back it up with action.....unless they are lying.y    L Strategic....doesn't that mean 'leading with your best'?  In HP's case, thatE must mean leading with hardware build by others in China and ThailanddD running an operating system designed and built by another company inK Seattle, supported by an outsourced call center person making 70 rupees per  day.   ------------------------------  $ Date: Wed, 3 Mar 2004 13:19:12 -0000* From: "Richard Brodie" <R.Brodie@rl.ac.uk>( Subject: Re: It's all about perception!!, Message-ID: <c24m0g$1a50@newton.cc.rl.ac.uk>  H "Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message- news:y2my+Psb9Ms4@eisner.encompasserve.org...t  C >    Too bad that's technically inacurate.  Nothing in VAX hardwareaG >    prevents the exectution of a NOEXE PSECT, it's just a linker hint.s >    Alpha, too.  2 and write for an access mode implies read too, no?   ------------------------------   Date: 3 Mar 2004 12:57:20 -0600u From: briggs@encompasserve.org( Subject: Re: It's all about perception!!3 Message-ID: <As+3fe6fQeJO@eisner.encompasserve.org>s  q In article <xdXARG+w6tI1@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:C[ > In article <c24m0g$1a50@newton.cc.rl.ac.uk>, "Richard Brodie" <R.Brodie@rl.ac.uk> writes:t >> tK >> "Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in messagea0 >> news:y2my+Psb9Ms4@eisner.encompasserve.org... >> mE >>>    Too bad that's technically inacurate.  Nothing in VAX hardwaresI >>>    prevents the exectution of a NOEXE PSECT, it's just a linker hint.e >>>    Alpha, too. >> e5 >> and write for an access mode implies read too, no?' > E >    Yep.  Only NOWRT is realy enforced by VAX hardware, and the four ) >    levels at which access is controled.m  ! This appears slightly misleading.o  3 As I recall, for VAX there are 15 levels of access:I  	 No Accesse KR KW ER ERKW EW SR SRKW SREW SW UR URKW UREW URSW UW  D Write access at a particular acmode implies read and write access at that mode and all inner modes.  = Read access at a particular acmode implies read access at all  inner modes.  B So you have five possibilities on which acmodes (if any) can read.= And for each of those possibilities you have one through five82 possibilities of which acmodes (if any) can write.   1 + 2 + 3 + 4 + 5 = 15  + Which conveniently fits into a 4 bit field.    	John Briggs   ------------------------------   Date: 4 Mar 2004 07:31:00 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ( Subject: Re: It's all about perception!!3 Message-ID: <v6O7QiWbtdSC@eisner.encompasserve.org>   T In article <As+3fe6fQeJO@eisner.encompasserve.org>, briggs@encompasserve.org writes:s > In article <xdXARG+w6tI1@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:t >> hF >>    Yep.  Only NOWRT is realy enforced by VAX hardware, and the four* >>    levels at which access is controled. > # > This appears slightly misleading.b >   B    I was simplifying:  all combinations of four levels of read and=    four levels of write except more-privileded read with lesss9    priviledged write, comes out to the list you provided.n   ------------------------------   Date: 3 Mar 2004 23:54:28 -0800w, From: mcbill20@hotmail.com (Bill McLaughlin), Subject: Re: Market for Alphastation 500/266= Message-ID: <e9cbc4f2.0403032354.7ec68e13@posting.google.com>   F Thanks for the info. As for the licenses, theoretically they should beA transferable but I am not totally sure. Back in January of 1998 I B purchased a few of these at the company I worked for. In March the= company went out of business and sold most physical assets to B employees for 33 cents on the dollar. I bought this machine, alongF with the VMS, cluster, UCX, DFG and C compiler licenses. (At the time,< I didn't realize that only the VMS and cluster licenses were transferable.)  F Unfortunately, I never went through the whole transfer process, but itF was my signature on the P.O. for these machines so I would think it is still possible.i   Bill  k "Richard B. Gilbert" <rgilbert88@comcast.net> wrote in message news:<Z-2dnVy1KYSTlNndRVn-iQ@comcast.com>...pC > Your hardware should bring $300-$400 on e-Bay.  The licenses, if dB > legitimately transferable, are worth a great deal more than the K > hardware.    You could try searching "Complete items" to see if anything  C > similar has sold in the last 90 days and, if so, what it brought.) > H > I'd offer to buy it myself but my wife would want to know if I REALLY " > needed four Alphas. . . . <sigh> >  >  > Bill McLaughlin wrote: > I > >Hello all. I am retiring an Alphastation 500/266. My electric bill has C > >been steadily rising so I am going to try and get by on a single F > >machine rather than a cluster. I was planning on selling it on EbayG > >but to be honest, I have no idea what to price it at and I am afraid8I > >that if I do a "no reserve" auction, I may find that it sells for $20.e: > >Does anyone here have any suggestions? Here's the info: > >w > >- AS500/266 P/N PB540-A9 
 > >- 256MB > >- 2GB SCSI disk (x2)  > >- SCSI CDROMbE > >- graphics adapter (the "standard" one, works with VMS; don't knowo > >model offhand)a > >- VMS base license " > >- VMS additional 4 user license > >- VMS full cluster license6 > >nE > >I also have an older condist from 1995 or so and possibly one from  > >1999.( > >Any suggestions would be appreciated. > > 
 > >Thanks. > >Bill McLaughlin > >  c > >e   ------------------------------  % Date: Thu, 04 Mar 2004 16:14:43 +000010 From: Chris Sharman <chris.sharman@sorry.nospam> Subject: MX routing 4 Message-ID: <c27klj$360$1$8300dec7@news.demon.co.uk>  * We're taking over mail for another domain.4 This is fairly easily handled in MX with a rule like  > def rewrite <{user}@elsewhere.com> <{user}.elsewhere@here.com> OR7 def rewrite <{user}@elsewhere.com> <elsewhere@here.com>   . I need some combination of these two, however.H Some reasonable number of users remain, and the rest I'd like routed to  a 'postmaster'.d  G I could put in rewrite rules for each retained account (ie fred, john, oI pete, etc), followed by a catch-all for the rest, but I'm concerned that nH this will result in quite a lot of rewrite rules, with implications for & maintainability & runtime performance.  F If I just route {user} to {user}.elsewhere then that will be fine for I all the remaining users, but I can't see how to have a catch-all for the  B rest, to stop them bouncing when there isn't a specific receiving  account set up.6  < Is there a way to say I want {user}@elsewhere.com routed to , {user}.elsewhere@here.com if it exists, and K postmaster.elsewhere@here.com otherwise (without bouncing back to sender) ?    Thanks,d ChrisL   ------------------------------  % Date: Wed, 03 Mar 2004 17:27:45 +0000,O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> , Subject: Re: Not meaning to feed Andrew.....0 Message-ID: <c254ih$hff$2@new-usenet.uk.sun.com>   JF Mezei wrote:  > John Smith wrote:  > J >>Maybe Sun should offer to buy OpenVMS from HP. At least it would be wellB >>marketed and would finally give you guys something good to sell. >  > J > Oh ! I'd love to see that. We could write a book about Digital employeesP > opinions. Show their opinions about IA64 prior to and after June 25 2001, thenB > show their opinions of Sparc prior to and after the move to Sun.  A Noooooooooo what a horrible idea Rob Young a SPARC cheerleader iti# really doesn't bear thinking about.D   regardsD Andrew HArrisonp   ------------------------------  % Date: Wed, 03 Mar 2004 08:41:25 -0600.2 From: "-Andy-" <see2go4me@spamdelicious.yahoo.com> Subject: Re: OpenVMS Feelings46 Message-ID: <Xns94A162947AB75see2go4me@216.196.97.132>  8 bill@cs.uofs.edu (Bill Gunshannon) enlightened us with:    > In article5 > <5ee1d1b7.0403020743.5a343d7e@posting.google.com>, n6 >      phillip_thayer@hotmail.com (PhilThayer) writes: >> a6 >> I think VMS is VERY affordable for Universities and >> Colleges.  Refer to:s   Yes.  2 >> http://h71000.www7.hp.com/openvmsedu/index.html  & But this isn't the only way to get it.  s( > This has been done to death before now   But not for a few months :-)...o   7 >> I have worked at several educational institutes bothi5 >> in the US and internationally and this program wasn >> used extensively.     > I can't imagine how, u   I'm on the "how?" also?m      5 >> people may not realize that it is actually runningu& >> the back-end of all the processing.    7 > I'm afraid I don't get this part.  Surely you are not,4 > saying that you know schools who are using the edu0 > license to cover their administrative systems?  5 Educational institutions (in the US anyway) have had -1 access to low pricing for licenses for their VMS 4 systems for years now. D  2 "We" still have quite a few (relatively speaking) 2 schools running one of "our" software packages on / OpenVMS systems and I can't imagine any of themn doing that kind of thing.   / See: Campuswide Software License Grant (CSLG) -i  7  http://government.hp.com/programs_detail.asp?progid=49  &agencyid=136&am=0&p=1  6 [And yes, I already know about the objections to this 6 since it doesn't include base licenses and was priced 5 on a "per-CPU" basis... and isn't perfect ... unless e that's changed recently.]    -Andy- -- a4 You can get anything you want, at Alice's Restaurant -- Excepting Alice   ------------------------------   Date: 4 Mar 2004 07:35:32 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)l Subject: Re: OpenVMS Feelingsr3 Message-ID: <iFk9L1PKOgAn@eisner.encompasserve.org>   c In article <20040303161827.25804.00000799@mb-m01.aol.com>, jealousxmp@aol.com (jealous xmp) writes:s > P > Our school used Mac and Sun heavily for workstations (10 years ago though).  IQ > didn't even see windows in a lab until 2nd year.  I'd imagine many liberal artspL > schools use windows heavily today, I wonder what the tech schools use (forJ > workstations / desktops)?  Linux would certainly be the right price, andK > possibly Solaris on edu discounts.  Both Sparc and PPC hardware is pricey0; > though, so Windows / x86, linux / x86 wins on that point.r >   H    Most of the "tech schools" around here grind out MCSE's, so they haveC    to be using Windows.  The colleges teaching CS and doing sciencetC    and engineering keep selling off old Alphas loaded with Red Hat,OG    which is nice when you're truing to put together a hobbyist cluster.g$    (Pick 'em up cheap and load VMS!)   ------------------------------   Date: 4 Mar 2004 08:30:01 -0800G- From: phillip_thayer@hotmail.com (PhilThayer)a Subject: Re: OpenVMS Feelingsp= Message-ID: <5ee1d1b7.0403040830.6b80d591@posting.google.com>e   > A > What exactly is a "backend machine" in an academic environment?  >   ? That would be spmething like an RDBMS server, Web server, EmailA Server, etc...   > C > You seem to think we are unique.  VMS lost most of the edu marketfC > long ago.  Sadly, even with the efforts of many people here therekG > seems little real interest in getting it back.  Every day the chances, > get slimmer. >   D I did not work in Universities on the "Academic" side.  I was on theB Administrative support side and that is where the VMS was used theB most.  What I did see was one university that assigned one project@ from the administrative side of the house to a 4th year class toC complete each year (A complete functional project, not some made upnF project.)  That was experience on VMS for the students.  Maybe if moreB of that was done then VMS would get more exposure to the students.   PT   ------------------------------  $ Date: Thu, 4 Mar 2004 08:31:42 -0800' From: David Mathog <mathog@caltech.edu>  Subject: Re: OpenVMS Feelings 8 Message-ID: <20040304083142.22cf3a99.mathog@caltech.edu>   On 3 Mar 2004 06:31:15 -0800. phillip_thayer@hotmail.com (PhilThayer) wrote:  C > Also, as far as licenses and S/W goes, the CSLG license agreement ! > costs a minimal amount per year.   Bzzzzt.  Wrong answer, please play again.  The price was in the multiple hundreds of dollars per machine per year when I dropped out and rising fast (due to the decreasing number of machines in the system.)  That may seem "minimal" for a business but its a lot of money at a school.  Moreover, if you stop paying it, your VMS machines turn into large  expensive paperweights.-  ! > can be purchased for the entire D > university and new systems "added" to the license agreement.  ThenC > each year (it may be quarter, I can't rightly remember) you get a6G > distribution (about 10 or 20 CD's) of all S/W and a nifty little .COMoD > file that willl load ALL the licenses on your systems and activate > them.   E Right.  And in all that software the only programs which did anythingu. useful were the OS itself and the compilers.     > G > It is very handy for universities to have.  Many of them do already.  = > I'm sure if you work at a university and could  tell the ITrH > management, hey, we can get the H/W at a 40% discount and the licenses7 > and S/W for a minimal charge, a few heads might turn.s  G Yes, and they'd be pointing too.  And jumping up and down and laughing.h Then they'd replace you with somebody who'd go out and buy a commodity PC and load linux on it - which would cost less to buy, less to maintain, and run faster and do more than the VMS system you were trying to buy.f  A (Unless of course we're talking about big iron for financials, inim which case VMS makes as much sense in academia as elsewhere - but most campuses have very few such machines.)p   Regards,   David Mathog mathog@caltech.edu> Manager, Sequence Analysis Facility, Biology Division, Caltech   ------------------------------  $ Date: Thu, 4 Mar 2004 09:51:48 -0500* From: "Syltrem" <syltremzulu@videotron.ca>P Subject: Re: OpenVMS virus proof while other disks get zapped by latest viruses!2 Message-ID: <KmH1c.719$Xy3.2800@tor-nn1.netcom.ca>  ? "rob kas" <rob@paychoice.com.noSPAM> a crit dans le message dea* news:104eebok3ks8jd4@corp.supernews.com... >    Bob >e& > What do you run on your VMS systems? >U >                       Robn >g  L Lots of things including Oracle, and Pathworks which makes OpenVMS part of aI Windows domain but NOT vulnerable to virus. All the software the businessd& relies on to survive, runs on OpenVMS.  L So... most applications have a front-end on peecees running windoze, some ofI the peecees get hit by the virus and die. The application goes on running, for the remaining users.K You can always rebuild a peecee in a few minutes with a ghost copy and have 3 the users running again, but what a waste of time !s  E Peecees are only really used so that "it looks cute" and users can goaI click-click-click because that's all they know. And windows should not ben< used for anything else than that in a corporate environment.   -- o Syltrems   OpenVMS 7.3-1 + Oracle 8.1.7.4H http://pages.infinit.net/syltrem (OpenVMS related web site, en franais)% ---zulu is not in my email address---              >p7 > "Bob Ceculski" <bob@instantwhip.com> wrote in messaged9 > news:d7791aa1.0403031720.341f83d3@posting.google.com...0= > >I don't know if anyone has noticed, but a lot of companiese: > > are getting creamed by the latest round of viruses ...; > > My boss has 4 friends from other companies who have allr= > > lost servers ... but our "unhackable" virus proof OpenVMSr; > > servers just keep humming along 24X7 ... isn't it greath > > to be on OpenVMS?  :)o >e >t   ------------------------------  % Date: Thu, 04 Mar 2004 13:49:43 +0100e0 From: Andre Hoffmann <hoffmann@fz-rossendorf.de>/ Subject: Re: Pathworks-32 and Windaube XPrience / Message-ID: <404725E7.8020807@fz-rossendorf.de>_   Didier Morandi schrieb:cJ > Who succeeded to have PCSA and XP work together fine? Mainly the DECnet  > stuff. >   D I tried it and it works fine, i use NFT(graphic frontend) sometimes.  Client: PW32 V7.3 on WinXP Prof.
 Server: 7.3-1a   -- c friendly yours Andre Hoffmanno   ------------------------------  $ Date: Thu, 4 Mar 2004 09:24:29 -0500$ From: "PEN" <paul.nuneznosp@mhp.com>/ Subject: Re: Pathworks-32 and Windaube XPrienceo, Message-ID: <c27e72$cjj$1@hplms2.hpl.hp.com>  C "Peter 'EPLAN' LANGSTOEGER" <peter@langstoeger.at> wrote in message + news:newscache$26v0uh$rqz1$1@news.sil.at... E > In article <404591da$0$24945$626a14ce@news.free.fr>, Didier Morandit <no@spam.com> writes:vJ > >Who succeeded to have PCSA and XP work together fine? Mainly the DECnet stuff. >h > I haven't tried.7 > But PATHWORKS-32 V7.3 supports XP, so it should work.e > And PW32 V7.4 is now current.s >d- > http://www.openvms.digital.com/pathworks32/  >t > -- x > Peter "EPLAN" LANGSTOEGER ' > Network and OpenVMS system specialistI > E-mail  peter@langstoeger.atH > A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   Hi All,u   FYI...  L PATHWORKS32 v7.3 supports Windows 95/98, Windows NT (WS and Server), Windows% 2000 (WS and Server), and Windows XP.m  J PATHWORKS32 v7.4 (just released) adds support for Windows Server 2003, butJ DROPS support for Windows 95/98.   It continues support for Windows NT (WS: and Server), Windows 2000 (WS and Server), and Windows XP.   Paul   ------------------------------  $ Date: Thu, 4 Mar 2004 16:37:48 +0100- From: "Martin Vorlaender" <mv@pdv-systeme.de>l Subject: Re: Recursive COPYs9 Message-ID: <c27igj$1q5ft1$1@ID-56200.news.uni-berlin.de>e   Michael D. Ober wrote:C > Does anyone have a DCL script that takes a source and destinationoB > directory and recursively copies the source to the destination. 9 > Similar to the DOS XCOPY /S or the Unix cp -r commands.   	 How about.  ) $ DEFINE /TRANS=CONC SRC srcdev:[srcdir.] ) $ DEFINE /TRANS=CONC DST dstdev:[dstdir.]s' $ BACKUP SRC:[000000]*.*;* DST:[000000]s# $ BACKUP SRC:[*...]*.*;* DST:[*...]t   ?h   cu,    Martin -- 1@   OpenVMS:                | Martin Vorlaender  |  OpenVMS rules!3    The operating system   | work: mv@pdv-systeme.deiF    God runs the           |   http://www.pdv-systeme.de/users/martinv/:    earth simulation on.   | home: martin@radiogaga.harz.de   ------------------------------  % Date: Thu, 04 Mar 2004 15:42:54 +0000M From: Roy Omond <Roy@Omond.net>r Subject: Re: Recursive COPYm4 Message-ID: <c27ipu$9r5$1$8302bc10@news.demon.co.uk>   Michael D. Ober wrote:  M > Does anyone have a DCL script that takes a source and destination directory K > and recursively copies the source to the destination.  Similar to the DOSt& > XCOPY /S or the Unix cp -r commands.   Why not just use BACKUP ?n  5 Or is there more to the question than meets the eye ?   	 Roy OmondF Blue Bubble Ltd.   ------------------------------  $ Date: Thu, 4 Mar 2004 09:04:47 -07008 From: "Michael D. Ober" <obermd-.@.-alum-mit-edu-nospam> Subject: Re: Recursive COPYw0 Message-ID: <DsI1c.18$8l1.30837@news.uswest.net>  J Thanks, BACKUP src:[tree...]*.* dest:[tree...] does the trick.  Neither my< boss (he's our VMS expert) nor I even thought to use backup.   Mike.     , "Roy Omond" <Roy@Omond.net> wrote in message. news:c27ipu$9r5$1$8302bc10@news.demon.co.uk... > Michael D. Ober wrote: >nE > > Does anyone have a DCL script that takes a source and destination3	 directory/I > > and recursively copies the source to the destination.  Similar to the  DOSo( > > XCOPY /S or the Unix cp -r commands. >h > Why not just use BACKUP ?e >m7 > Or is there more to the question than meets the eye ?w >  > Roy Omondd > Blue Bubble Ltd.   ------------------------------  % Date: Thu, 04 Mar 2004 17:01:26 +0100u4 From: Per =?ISO-8859-1?Q?Schr=F6der?= <per@mimer.se> Subject: Re: Recursive COPYd2 Message-ID: <c27jg7$818$1@yggdrasil.glocalnet.com>   Michael D. Ober wrote:  C > Does anyone have a DCL script that takes a source and destinationa > directorydK > and recursively copies the source to the destination.  Similar to the DOSU& > XCOPY /S or the Unix cp -r commands. > 	 > Thanks,  > Mike.u  6 $ COPY DISK1:[SOMEWHERE...]*.* DISK2:[ANOTHERPLACE...]  
 Use "..."!   /Per http://developer.mimer.com   ------------------------------   Date: 4 Mar 2004 06:03:40 -0800 ( From: bob@instantwhip.com (Bob Ceculski) Subject: Re: Sun On The Run?< Message-ID: <d7791aa1.0403040603.8a28fd2@posting.google.com>  d nospam <x@wedontwantyourspam.com> wrote in message news:<BC6CFCCD.252A1%x@wedontwantyourspam.com>...K > in article 8a646952.0403031500.7cf9b7f@posting.google.com, Daryl Jones ati@ > jones.computer.srv@worldnet.att.net wrote on 04/03/2004 10:00: > 
 > > Linux  > > Sun On The Run? & > > Daniel Lyons, 03.03.04, 9:52 AM ET >  .. E > > company in New York, is ripping out hundreds of Sun servers in 16 G > > locations and replacing them with inexpensive servers running Intel 2 > > processors and Linux, a free operating system. > >  > > For more of this article:B > > R > > http://www.forbes.com/technology/2004/03/03/cz_dl_0303linux.html?partner=newsc > > om > M > That's a loss for SUN but that same pressure is against VMS also, and everylL > other UNIX that costs money. When you can get you OS for free and price isN > your decider. Then Intel x86 boxes can be the cheapest solution. Having saidM > that people use that to convince them selves that's the way too go and thennL > start spending similar money because they don't buy "put together yourselfM > clones" and buy SAN storage and SDLT or other tape solutions and everythingML > else you really need in a production bet you business solution. It ends up > costing about the same.x > M >  Box sellers like HP and SUN make way too much margin on things like memorysJ > and controllers but they also provide some degree of certainty. I know IL > sound like I'm contradicting myself and a little confused but then I thinkM > that's how the market is around this stuff, a lot of double think going on.  >  4 > N >  Since Linux and other free UNIX like OS's went multi-CPU the world changed.N >  Microsoft feels the biggest threat since they don't sell hardware they sell > and expensive OS.t >   L >   I don't see anything about VMS, or happening in the world to reverse theN > stakes for VMS. It took too much damage in the last 6-10years too much bloodI > has move off and nothings is replacing that. The next generations of IT L > people are either Microsoft kiddies or UNIX kiddies. Its not time yet, butL > its coming, VMS will be dead. Its really a race to see which will go first > SUN or VMS ;)O  A OpenVMS will not be going anywhere for a long time ... businessesr> that want low TCO and security and uptime depend on it ... and@ look at the latest virus rampage wiping out server after server,A but not VMS servers ... we will be on VMS as long as it is around ? because not even a free garbage linux server can offer what VMSl can, and TCO proves it ...   ------------------------------  $ Date: Thu, 4 Mar 2004 08:49:17 -0800' From: David Mathog <mathog@caltech.edu>c Subject: Re: Sun On The Run?8 Message-ID: <20040304084917.4e285ec6.mathog@caltech.edu>  " On Thu, 04 Mar 2004 15:33:33 +1100( nospam <x@wedontwantyourspam.com> wrote:  ? >Then Intel x86 boxes can be the cheapest solution. Having saidvM > that people use that to convince them selves that's the way too go and thenzL > start spending similar money because they don't buy "put together yourselfM > clones" and buy SAN storage and SDLT or other tape solutions and everythingeB > else you really need in a production bet you business solution.   m There was no problem at all attaching a Quantum SDLT 320 to our Linux server.  I don't understand your point.t     David Mathog mathog@caltech.edu> Manager, Sequence Analysis Facility, Biology Division, Caltech   ------------------------------  # Date: Thu, 04 Mar 2004 17:42:25 GMTM  From: CJT <abujlehc@prodigy.net> Subject: Re: Sun On The Run?* Message-ID: <40476AB1.1050604@prodigy.net>   Bob Ceculski wrote:.   <snip>C > OpenVMS will not be going anywhere for a long time ... businesses @ > that want low TCO and security and uptime depend on it ... andB > look at the latest virus rampage wiping out server after server,C > but not VMS servers ... we will be on VMS as long as it is around.A > because not even a free garbage linux server can offer what VMS  > can, and TCO proves it ...   That sounds a lot like Wang.   -- nG After being targeted with gigabytes of trash by the "SWEN" worm, I have F concluded we must conceal our e-mail address.  Our true address is theF mirror image of what you see before the "@" symbol.  It's a shame such( steps are necessary.          ...Charlie   ------------------------------  # Date: Wed, 03 Mar 2004 11:42:24 GMTe# From: "John Smith" <a@nonymous.com>>( Subject: Re: Support of USB Memory stickJ Message-ID: <Awj1c.81618$ah.70050@twister01.bloor.is.net.cable.rogers.com>   Nic Clews wrote: > Fred Kleinsorge wrote: >>% >> Do you have a requirement for one?  >>E >> We have some code, but it isn't shipping or supported.  By lettingeF >> us know that there are real customer requirements, we can determine9 >> if it is worth qualifying the logic and supporting it.  >eE > Yes. [In a certain case] the current proposal is a tape solution to D > move relatively (less than 100 meg) small amounts of data from oneG > system to another. CDR was investigated, but due to the nature of thet6 > data add complications to destroying the used media.    I A small propane fueled soldering torch isn't good enough to destroy a CDR J completely?  Oh...I guess it isn't a great idea to use one of those in the* computer room or the Tempest facility.....   ------------------------------   Date: 3 Mar 2004 10:21:13 GMTs< From: gartmann@non.immunbio.mpg.de.sens (Christoph Gartmann)( Subject: Re: Support of USB Memory stick0 Message-ID: <c24bip$35d$1@n.ruf.uni-freiburg.de>  i In article <2o71c.47$GG1.7@news.cpqcorp.net>, "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> writes:e# >Do you have a requirement for one?i  K We do have some requirement. The USB-sticks are a means to interchange dataeL between various platforms. It is a lot simpler to transfer such a stick thanL to establish a network connection with passwords, protections, firewalls andO the like. Currently our memory sticks work under Windows 98 (with some driver),aG Win 2000, Win XP, Linux and MacOS (all without any driver). It would beeL helpful to have VMS on the list as well. In cases where there is no network,K either because of design or because of a failure, we have to use CD-ROMs ortN SCSI disks in order to exchange files. CD-ROMs require burning, something thatJ is definitely more complicated compared to an USB-stick. In addition it isG one-way. Imagine some bogus config file on a system. You burn it on CD,tM transfer the CD to some system where you would like to modify it; you'll haves@ to burn a second CD there in order bring the modified file back.  F These sticks are the real replacement of the former floppy disk. EveryI platform supports it, the file format is simple, usage it simple. Tell me 2 what is better for the purpose of exchanging data.   Regards,    Christoph Gartmann    -- tE  Max-Planck-Institut fuer      Phone   : +49-761-5108-464   Fax: -452>  ImmunbiologieI  Postfach 1169                 Internet: gartmann@immunbio dot mpg dot dee  D-79011  Freiburg, Germany 9                http://www.immunbio.mpg.de/home/menue.htmls   ------------------------------  $ Date: Wed, 3 Mar 2004 12:02:40 -0500+ From: Lord Isildur <isildur@andrew.cmu.edu>p( Subject: Re: Support of USB Memory stickH Message-ID: <Pine.LNX.4.58-035.0403031201330.4319@unix44.andrew.cmu.edu>   how about a network?  J > Yes. [In a certain case] the current proposal is a tape solution to moveI > relatively (less than 100 meg) small amounts of data from one system to>F > another. CDR was investigated, but due to the nature of the data add- > complications to destroying the used media.    ------------------------------  % Date: Wed, 03 Mar 2004 10:11:00 -0800?3 From: Alan Frisbie <Usenet01REMOVE@Flying-Disk.com>l( Subject: Re: Support of USB Memory stick. Message-ID: <40461FB4.3070400@Flying-Disk.com>   Fred Kleinsorge wrote:$ > Do you have a requirement for one? > L > We have some code, but it isn't shipping or supported.  By letting us knowL > that there are real customer requirements, we can determine if it is worth) > qualifying the logic and supporting it.   = I would dearly love to have this work (note that I didn't say7= "supported").   A couple times a week I need to take softwaren; updates to a client's site.   Currently, I use TLZ09 tapes,27 even though the updates generally total less than 10MB.r; It would sure be nice if I could use a USB memory stick fora this.o   Alan   ------------------------------  % Date: Wed, 03 Mar 2004 17:52:02 +0000>O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>>( Subject: Re: Support of USB Memory stick0 Message-ID: <c25602$htm$2@new-usenet.uk.sun.com>   Michael Unger wrote:2 > On 2004-03-03 11:21, "Christoph Gartmann" wrote: >  >  >>[...]n >>H >>These sticks are the real replacement of the former floppy disk. EveryK >>platform supports it, the file format is simple, usage it simple. Tell med4 >>what is better for the purpose of exchanging data. >  >  > CD-RW? >   > Almost everything nowdays from servers to laptops has a memory; card interface including Palms etc not everything has CD-RWe9 hence the usefullness of USB flash card readers. They ares also dirt cheap.   Regardsa Andrew Harrison    ------------------------------  $ Date: Thu, 4 Mar 2004 08:42:48 -0800' From: David Mathog <mathog@caltech.edu>g6 Subject: Re: Uninterruptable Power Supplies for Alphas8 Message-ID: <20040304084248.4b1a0c8b.mathog@caltech.edu>   On 2 Mar 2004 09:09:15 -0800& tadamsmar@yahoo.com (Tom Adams) wrote:   > I > I would need a way to do an orderly shutdown before the UPS shuts down.s* > I see a number of approaches to do this:  F I had a TrippLite UPS on our VMS DS10.  Controlled it through a serial port with this software:  =   ftp://saf.bio.caltech.edu/pub/software/openvms/tcontrol.zip   @ One tricky thing about serial line control is that some machinesB wiggle those lines uncontrollably at boot and that can be bad with some UPS models.  We have a Sun V880 now attached to a high end TrippLite and early in the boot sequence the V880 kills the UPS -t before OpenBoot is even in control.  So we have to unplug the serial line to boot, and then plug it back in later.  (Which isn't9 as bad as it sounds since this machine doesn't need to be ; able to reboot itself, and it does shut down correctly when 4 the power fails.)  I never had that problem with the- Omnismart power supplies and VMS on the DS10.C  = The other tricky thing is that one usually has to muck aroundy@ with eeprom settings to configure the serial line appropriately,D which usually means telling the OS not to touch the port in question% so that your software can control it.y  H I wrote tcontrol - it's free.  It isn't fancy, but you're free to modify& the DCL to do anything you want it to.   Regards,   David Mathog mathog@caltech.edu> Manager, Sequence Analysis Facility, Biology Division, Caltech   ------------------------------  $ Date: Wed, 3 Mar 2004 09:33:58 -0500  From: "smitty" <andrew@sp32.com>% Subject: upgrade path to Alpha 7.3...40 Message-ID: <104br6g83g3csc5@corp.supernews.com>  K Can anyone tell me if upgrading a 7.1-2 alpha to 7.3 alpha is a valid path?i   The 7.3 documentation notes:J "Upgrades are supported from Version 6.1, 6.2-xxx, 7.0, 7.1, or 7.2-xxx of+ the COmpaq OpenVMS Alpha operating system.">   Does this include 7.1-2?   andrew Software Partners, Inc.l andrew@sp32.comL www.softwarepartners.com 978-887-6409   ------------------------------  $ Date: Wed, 3 Mar 2004 10:09:19 -0500  From: "smitty" <andrew@sp32.com>) Subject: Re: upgrade path to Alpha 7.3...o0 Message-ID: <104bt8pl2sq9s35@corp.supernews.com>  L Thanks Charlie, that's what I thought.  I need to use 7.3 as it is necessary% for our software testing environment.l  
 Thanks again!e   andrew   -- v Software Partners, Inc.u tech_support@sp32.comy www.softwarepartners.com 978-887-6409  @ "Charlie Hammond" <hammond@not@peek.ssr.hp.com> wrote in message( news:_mm1c.95$7d2.77@news.cpqcorp.net...; > In article <104br6g83g3csc5@corp.supernews.com>, "smitty"i <andrew@sp32.com> writes:mH > >Can anyone tell me if upgrading a 7.1-2 alpha to 7.3 alpha is a valid path?a > >r > >The 7.3 documentation notes:tJ > >"Upgrades are supported from Version 6.1, 6.2-xxx, 7.0, 7.1, or 7.2-xxx of. > >the COmpaq OpenVMS Alpha operating system." > >' > >Does this include 7.1-2?n >i > Obviously not. >oF > That does NOT mean it won't work, only that OpenVMS Engineeering has: > not tested that upgrade path.  Will V7.1-2 -> V7.3 work?' > I don't know -- one way or the other.e > B > The tested path (from memory) would be V7.1-2 -> V7.2.2 -> V7.3. >2E > I also suggest you consider upgrading to V7.3-2 or at least V7.3-1.l >bF > As always, be sure you have a good backup of your system disk before > you begin any upgrade. >m > -- aL >       Charlie Hammond -- Hewlett-Packard Company -- Ft Lauderdale  FL  USAH >           (hammond@not@peek.ssr.hp.com -- remove "@not" when replying)L >       All opinions expressed are my own and not necessarily my employer's. >a   ------------------------------  $ Date: Thu, 4 Mar 2004 08:19:16 -0800' From: David Mathog <mathog@caltech.edu>14 Subject: Re: VMS Hobbyist License program abolished?8 Message-ID: <20040304081916.3a1d9397.mathog@caltech.edu>    On Tue, 02 Mar 2004 19:17:42 GMT1 glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:o   > D > Are used Alphas really cheaper than a comparable off-brand PC with$ > the previous generation processor?  G Maybe but probably not.  Replacement parts for the Alpha will be harderiB to find and more expensive to purchase.  Memory upgrades will cost) orders of magnitude more than for the PC.   C Beyond the idiocy of the educational licenses the 800 lb gorilla is the complete lack of native software.  Sure, if the source code is available you can port most things with enough effort but why bother when Linux is more than good enough for scientific and engineering computing?  Moreover, it isn't like you're taking a performance hit; relative to an old Alpha. Our Athlon 2200 beowulf nodes runtC everything I've tested faster than did the DS10 nodes they replacedRE (mostly integer math here, it might not be true for floating point.) lD The one nice thing about the DS10s was that they were quiet, whereas the rack of PCs is very noisy. a   You can all stop beating this dead horse.  There is no compelling reason for academics to move back to VMS on the OS's own merits, and even less of a reason to do so if one also factors in the tepid "support" ofs the vendor for the OS.   Regards,   David Mathog mathog@caltech.edu> Manager, Sequence Analysis Facility, Biology Division, Caltech   ------------------------------  $ Date: Thu, 4 Mar 2004 11:30:41 -0500' From: "Main, Kerry" <kerry.main@hp.com>:4 Subject: RE: VMS Hobbyist License program abolished?R Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB2794E0@tayexc19.americas.cpqcorp.net>   > -----Original Message-----3 > From: David Mathog [mailto:mathog@caltech.edu]=20. > Sent: March 4, 2004 11:19 AM > To: Info-VAX@Mvb.Saic.Comr6 > Subject: Re: VMS Hobbyist License program abolished? >=20" > On Tue, 02 Mar 2004 19:17:42 GMT3 > glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:i >=20 > >=20A > > Are used Alphas really cheaper than a comparable off-brand=20o > PC with the=20" > > previous generation processor? >=20B > Maybe but probably not.  Replacement parts for the Alpha will=20> > be harder to find and more expensive to purchase.  Memory=20> > upgrades will cost orders of magnitude more than for the PC. >=20= > Beyond the idiocy of the educational licenses the 800 lb=203? > gorilla is the complete lack of native software.  Sure, if=20 ? > the source code is available you can port most things with=20 > > enough effort but why bother when Linux is more than good=20@ > enough for scientific and engineering computing?  Moreover,=20A > it isn't like you're taking a performance hit relative to an=20nA > old Alpha. Our Athlon 2200 beowulf nodes run everything I've=20e@ > tested faster than did the DS10 nodes they replaced (mostly=20A > integer math here, it might not be true for floating point.)=20nA > The one nice thing about the DS10s was that they were quiet,=20t+ > whereas the rack of PCs is very noisy.=20i >=20; > You can all stop beating this dead horse.  There is no=20 ? > compelling reason for academics to move back to VMS on the=20K? > OS's own merits, and even less of a reason to do so if one=20-? > also factors in the tepid "support" of the vendor for the OS.a >=20
 > Regards, >=20 > David Mathog > mathog@caltech.edu@ > Manager, Sequence Analysis Facility, Biology Division, Caltech >=20     David,  ; What version of the many Linux's available are you running?i  F If Red Hat's latest V3 version, you likely already knew this, but hereE is list of security patches on their web site for this latest releasem only.n  : https://rhn.redhat.com/errata/rhel3as-errata-security.html  6 Here is list of all the Red Hat V2.1 security patches:9 https://rhn.redhat.com/errata/rh21as-errata-security.html      Regards    ------------------------------  $ Date: Wed, 3 Mar 2004 12:37:53 -0000* From: "Richard Brodie" <R.Brodie@rl.ac.uk>; Subject: Re: Why does smtp mail between local systems fail?g, Message-ID: <c24jj2$16mu@newton.cc.rl.ac.uk>  b "Lawrence Bleau" <bleau@umtof.umd.edu> wrote in message news:c22nva$jkd$1@grapevine.wam.umd.edu...  I > Here's some other points to consider.  There are some Mac systems in my J > group that run anti-spam s/w by doing rbl lookups to the same rbl sites,4 > and they respond within 2 secs, while VMS doesn't.  F I'm guessing that they both timeout. Have you tried manual DNS queries to the RBL sites?.   ------------------------------  $ Date: Thu, 4 Mar 2004 11:07:54 -0000* From: "Richard Brodie" <R.Brodie@rl.ac.uk>; Subject: Re: Why does smtp mail between local systems fail?n+ Message-ID: <c272mb$h1q@newton.cc.rl.ac.uk>e  b "Lawrence Bleau" <bleau@umtof.umd.edu> wrote in message news:c257ov$mln$1@grapevine.wam.umd.edu...  L > When I tried to telnet/port=25 from umace into umtof, however, there was aL > delay of 32 secs before I received the 220 HELO message. (Btw, umace's IP#= > is 129.2.163.195, the one used in the nslookup test above.)e  M Assuming that it is DNS related it some way still, I would trace DNS requestse> (with a monitor, or TCPTRACE/PORT=LOCAL=53) on umtof. See what0 happens on the wire when you connect from umace.  J Several times when I've been hunting down specific network slowdowns, someA completely unexpected dialog has been going on behind the scenes.    ------------------------------  % Date: Thu, 04 Mar 2004 12:45:55 +0100s* From: Paul Sture <nospam@sture.homeip.net>; Subject: Re: Why does smtp mail between local systems fail?e0 Message-ID: <40472503.24D3B748@sture.homeip.net>    Peter 'EPLAN' LANGSTOEGER wrote: > _ > In article <4045DA3A.43A98523@sture.homeip.net>, Paul Sture <nospam@sture.homeip.net> writes:w > >Lawrence Bleau wrote:* > >> RBLs: bl.spamcop.net, dnsbl.sorbs.net > >-J > >I'm using the following RBLs here (don't ask how I decided on these, it > >was a long time ago): > >H= > >RBLs: rbl.maps.vix.com, dul.maps.vix.com, relays.orbs.org,A > >mr-out.imrss.orgD > Q > MAPS.VIX.COM is dead since years (was MAIL-ABUSE.ORG later, but isn't free now)># > RELAYS.ORBS.ORG is also dead now.  >  > You might tryw >  >     CBL.ABUSEAT.ORGd >     LIST.DSBL.ORGo >     MULTIHOP.DSBL.ORGs >     MR-OUT.IMRSS.ORG >     COMBINED.NJABL.ORG >     DNSBL.NJABL.ORGg >     DYNABLOCK.NJABL.ORG  >     RELAYS.ORDB.ORGu >     DIALUP.ORDB.ORGe >     BLACKHOLES.ORDB.ORGw >     BL.SPAMCOP.NET >     SBL.SPAMHAUS.ORG >     SBL-XBL.SPAMHAUS.ORG >     XBL.SPAMHAUS.ORG >     L1.SPEWS.DNSBL.SORBS.NET >     L2.SPEWS.DNSBL.SORBS.NET > < > See also the other concept of Domain-Based Blacklist-ZonesE > (versus IP-Address-Based Blacklist-Zones) like DSN.RFC-IGNORANT.ORGm" > which is not yet there in TCPIP. >    Thanks Peter. Well caught.     -- 1
 Paul Sture   ------------------------------  # Date: Wed, 03 Mar 2004 18:33:03 GMTu& From: Don Sykes <paladin@mydomain.com> Subject: Re: Zip/update Issuee< Message-ID: <zxp1c.5545$Ud3.3867@newssvr27.news.prodigy.com>   Jan-Erik Sderholm wrote:E   > Don Sykes wrote: > F >>Yes. That IS it. Once the SEzip files have been unzipped onto my VMSG >>server they are ready to be distributed (downloaded to customers),...  >  > 8 > Should that have been "ftp'ed" instead of "unzipped" ? >  > Jan-Erik.I  C No. They are a group of SEzip files that have to be unzipped on my iG server, because only one is shipped to a customer at a time. So I wind  F up with a group of 4 SEzip files. A customer requests only 1 of the 4 G and that's the one that has to be upgraded with the valid license file.    -- '   Have VMS, Will Travel  Wire paladin, San Francisco    (paladinATalphaseDOTcom)   ------------------------------  # Date: Wed, 03 Mar 2004 19:22:24 GMT & From: Don Sykes <paladin@mydomain.com> Subject: Re: Zip/update Issue < Message-ID: <Qfq1c.5557$qu3.3458@newssvr27.news.prodigy.com>   Brian Tillman wrote:   > Don Sykes wrote: >  > A >>I have a Self-extracting zip file I use to distribute software.m8 >>It is created on an NT4.0 and copied to my VMS server.= >>I'd like to update one file in this file dynamically, on myt
 >>VMS server;h? >>but when I do and download it back to my NT and run it, I getA> >>"zip file is damaged, truncated or has been changed since it >>was created..."  >  > B > Perhaps this question is better asked at info-zip@lists.wku.edu.  , I emailed that group abd got this response :( Your mail to 'Info-ZIP' with the subject        Zip/update Issueg  B Is being held until the list moderator can review it for approval.   The reason it is being held:  .      Post by non-member to a members-only list  C Either the message will get posted to the list, or you will receive ) notification of the moderator's decision.9      ? My question is, where do I go to see this "members-only list" ?    -- u   Have VMS, Will Travelo Wire paladin, San Franciscot   (paladinATalphaseDOTcom)   ------------------------------   Date: 4 Mar 2004 03:43:49 -0800 . From: alexdaniels@themail.co.uk (Alex Daniels)< Subject: Re: [GAME] you've been appointed VMS Mkt Mgr, so...= Message-ID: <9f7f13a8.0403040343.5b8ab00b@posting.google.com>   l Tim Llewellyn <tim.llewellyn@blueyonder.co.uk> wrote in message news:<4046635E.7F455069@blueyonder.co.uk>... > Didier Morandi wrote:e > >  > > Thomas Dzubin wrote: > > M > > > (I originally wrote this response SEVEN YEARS AGO...use www.deja.com tonK > > > find my original Usenet response ...please substitute "HP" for "DEC")t > > >wN > > > Subject:      Re: Why can't Digital market? (Was Re: DEC vs Sun & PPro?): > > > From:         Thomas Dzubin <no.email.for@me.please> > > > Date:         1997/02/046 > > > Message-ID:   <5d8589$2vs@fountain.mindlink.net>C > > > Newsgroups:   comp.os.vms,alt.folklore.computers,comp.sys.dec9	 > > ../..o > > , > > You're giving me an idea (yes, again...) > > T > > Maybe we could set up a virtual VMS Marketing Community (isn't it already here?)R > > and start "selling" VMS to Customers worldwide. Then, when the PO is ready forS > > signature, we go to HP and ask how much they will pay us for that new Customer.h > >  > > Waddya think?  > L > How do you expect to be taken seriously by the potential customers without > positive actions from HP?h > G > What response do you expect from potential customers when you turn uprJ > and start trying to tell them their existing systems are crap and should( > be replaced by an OS born in the 80's?  E The OpenVMS 7.3-2 startup seems to indicate 1976, however I think youn; will find unix was 'born' somewhat earlier on VAX hardware.i   ------------------------------  # Date: Thu, 04 Mar 2004 17:19:58 GMTo2 From: "Robert Rappaport" <Robert.Rappaport@hp.com>$ Subject: Re: [TCPIP V5.4] More rants0 Message-ID: <2zJ1c.212$Mq3.100@news.cpqcorp.net>  B I will respond to just two of the complaints in this message and IA will attempt (if possible) to get others more knowledgeable other-! topics to resond to those issues.h  > Complaint #2 reports that while looking at a dump in SDA where: the TCP/IP Scalable Kernel is running we see messages that> inform us that "this is NOT a valid version of TCPIP".  I mustC admit that this is an annoyance for me too.  However, the statementtA is false and the problem arises because SDA has read in the wrongyD symbol table.  That is, the defining of the TCPIP$STARTUP_CPU_IMAGES= logical, before TCP/IP was started caused OpenVMS to load theeD images associated with the Scaling Kernel into memory.  These images> are TCPIP$BGDRIVER_PERF.EXE, TCPIP$INTERNET_SERVICES_PERF.EXE, and TCPIP$TNDRIVER_PERF.EXE).   G However, SDA incorrectly reads in the Classic Kernel symbol table filesb< (i.e. TCPIP$BGDRIVER.STB, TCPIP$INTERNET_SERVICES.STB, etc.)K and then gets confused when trying to determine if the version of TCP/IP isiL valid because it looks in the wrong place (due to the wrong symbol table) to  find the validation information.  I I am sorry about this and I am not sure if we will be able to fix this ine the G near future because of other more urgent matters that must be addressedeK and because this will fix itself in future versions when the Scaling KerneloH becomes the only TCP/IP Kernel in the kit and reverts back to the simpleB names.  For now, to get around this problem what I do when runningI SDA on a crash (or live system) that has the Scaling Kernel loaded, is to-G have copies of the various XXX_PERF.STB files in a side directory whererH I have also renamed these files.  That is, in my side directory I have a copy3 of SYS$SYSTEM:TCPIP$BGDRIVER_PERF.STB whose name ismF [side-dir]TCPIP$BGDRIVER.STB.  Also I have renamed copies of the otherD STB files with the "_PERF" removed.  Then in SDA, after invoking theD TCPIP command I read the renamed STB files are needed.  For example:  5 SDA> read/image [side-dir]TCPIP$INTERNET_SERVICES.STB5, SDA> read/image [side-dir]TCPIP$BGDRIVER.STB   Also I would add::  / SDA> read sys$system:TCPIP$NET_GLOBALS_PERF.STBy  ? to get the proper structure definitions for the Scaling Kernel.>  / If I am looking at TNDRIVER pieces I would add:n  , SDA> read/image [side-dir]TCPIP$TNDRIVER.STB  0 Finally, if I am looking at the INETACP process:  + SDA> read sys$system:TCPIP$INETACP_PERF.STBn  > Complaint # 4 deals with PWIPDRIVER problems in SDA.  Here theE problem arises due to the constraint that we name our TCPIP$PWIDRIVER B simply PWIPDRIVER as far as OpenVMS is concerned.  This is so thatF we remain compatible with the other providers of OpenVMS TCP/IP stacksC and with PathWorks and DECnet.  That is, because there are multiple A possible TCP/IP products that one might use on OpenVMS, all these @ products must use a common name for PWIPDRIVER so that PathWorksE and DECnet can find whichever one is running on a system.  This meanstE that a similar naming problem arises in SDA such as the problem abovelA with the "_PERF" differences.  For the PWIPDRIVER problem, what I : do is to have a copy of TCPIP$PWIPDRIVER.STB whose name isF PWIPDRIVER.STB.  I would either put this copy into SYS$COMMON:[SYSLIB]? or into my [side-dir].  If it is in SYS$COMMON:[SYSLIB] then it H will be read automatically and SDA will not complain when performing theE READ/EXEC command.  If it is in my [side-dir] then after invoking thet	 READ/EXECy command I would:  ( SDA> read/image [side-dir]PWIPDRIVER.STB  ; I hope these suggestions relieve some of your frustrations.d   Robert Rappaport   ------------------------------   End of INFO-VAX 2004.127 ************************