0 INFO-VAX	Sat, 18 Jan 2003	Volume 2003 : Issue 35      Contents:5 RE: (OT) lots of spam in vmsnet.sdk.openvms.fieldtest 5 RE: (OT) lots of spam in vmsnet.sdk.openvms.fieldtest 5 RE: (OT) lots of spam in vmsnet.sdk.openvms.fieldtest * Re: *** DANGER, Will Robinson! DANGER! **** Re: *** DANGER, Will Robinson! DANGER! **** Re: *** DANGER, Will Robinson! DANGER! *** Re: Alpha 3000 ...2 Re: Alpha, Itanic and Opteron benchmark comparison2 Re: Alpha, Itanic and Opteron benchmark comparison2 Re: Alpha, Itanic and Opteron benchmark comparison2 Re: Alpha, Itanic and Opteron benchmark comparison2 Re: Alpha, Itanic and Opteron benchmark comparison2 Re: Alpha, Itanic and Opteron benchmark comparison2 Re: Alpha, Itanic and Opteron benchmark comparison2 Re: Alpha, Itanic and Opteron benchmark comparison2 Re: Alpha, Itanic and Opteron benchmark comparison> Re: Function keys no longer work after TCPware upgrade to 5.6., Re: How to flash VAXstation 4000/90 FEPROMS?, Re: How to flash VAXstation 4000/90 FEPROMS?4 Re: How to make a harddisk accessible via NFS on VMS4 Re: How to make a harddisk accessible via NFS on VMS; Re: HP's Alpha Marvel arrives on Tuesday (says The Inq....) ; Re: HP's Alpha Marvel arrives on Tuesday (says The Inq....) ; Re: HP's Alpha Marvel arrives on Tuesday (says The Inq....)  HSZ-70 transfer rate question." Re: HSZ-70 transfer rate question." Re: HSZ-70 transfer rate question." Re: HSZ-70 transfer rate question. KDA50 in BA123# MicroVAX upgrade (to Alpha, maybe?) ' Re: MicroVAX upgrade (to Alpha, maybe?) ' Re: MicroVAX upgrade (to Alpha, maybe?)  Re: Montecito slips to 2005  Re: Montecito slips to 2005 . Re: Most common OpenVMS versions in use today?. RE: Network Time Protocol (NTP) for OpenVMS ??. RE: Network Time Protocol (NTP) for OpenVMS ??. Re: Network Time Protocol (NTP) for OpenVMS ??. RE: Network Time Protocol (NTP) for OpenVMS ??. Re: Network Time Protocol (NTP) for OpenVMS ??. Re: Network Time Protocol (NTP) for OpenVMS ??. Re: Network Time Protocol (NTP) for OpenVMS ??. RE: Network Time Protocol (NTP) for OpenVMS ??. Re: Network Time Protocol (NTP) for OpenVMS ?? Re: NT on Alpha  Re: NT on Alpha  RE: NT on Alpha  Re: NT on Alpha  Re: NT on Alpha + RE: Oracle LMON and LMDO buffered I/O usage / Re: Recovering from deleted .PCSI$DATABASE file / Re: Recovering from deleted .PCSI$DATABASE file / Re: Recovering from deleted .PCSI$DATABASE file / Re: Recovering from deleted .PCSI$DATABASE file / Re: Recovering from deleted .PCSI$DATABASE file / RE: Recovering from deleted .PCSI$DATABASE file / Re: Recovering from deleted .PCSI$DATABASE file / Re: Recovering from deleted .PCSI$DATABASE file  Re: THREADCP problem Re: vax6k.openecs.org rebirth  Re: vax6k.openecs.org rebirth  Re: vax6k.openecs.org rebirth  Vaxstation 3100/30 still works! # Re: Vaxstation 3100/30 still works! # Re: Vaxstation 3100/30 still works! 5 Re: [OT] lots of spam in vmsnet.sdk.openvms.fieldtest 5 RE: [OT] lots of spam in vmsnet.sdk.openvms.fieldtest 5 Re: [OT] lots of spam in vmsnet.sdk.openvms.fieldtest   F ----------------------------------------------------------------------  % Date: Fri, 17 Jan 2003 15:21:56 -0500 ! From: VAXVMS <bounce@notmail.com> > Subject: RE: (OT) lots of spam in vmsnet.sdk.openvms.fieldtestK Message-ID: <BA52530E3149734A9BAABDBBFA808E4903027BBE@rlghncst964.usps.gov>    Shane S. said:  F  Somebody send me a copy of this, complete with mail headers, and I'll?  see what I can do. I've been getting into spammer-hunting as a   bloodsport recently.     Shane  
 Bloodsport?   	 Spammers?    I *like* the sound of that...   4 After *you're* finished, I say we collect donations / from the newsgroup for  the services of a good  5 taxidermist, and then put the photos of the finished  % work online as an example for others.  :^)    ========================  William W. Webb / DSSC/RLM, USPS OpenVMS Support Services& 4924 Green Road Raleigh, NC 27616-2800: 919.874.3043 <FirstInitialDotLastNameAtEmailDotUSPSDotGov>   ------------------------------  % Date: Fri, 17 Jan 2003 13:59:10 -0800 $ From: Shane Smith <ssmith@icius.com>> Subject: RE: (OT) lots of spam in vmsnet.sdk.openvms.fieldtest0 Message-ID: <01C2BE30.A213CEF0@sulfer.icius.com>  H I've been sent a copy of the mail in question offline (thanks) and firedF off a little flurry of complaints. I /think/ I've id'd the ISP hostingF the culprits as ic2net.net. No abuse account registered, so abuse@ andB postmaster@ have been informed. I've also fired of a quickie to anD unidentified node in the chain 207.218.223.39. For good measure I'veG also contacted the admin of the company who owns the apparent culprit's  IP address, admin@ev1.net.  F I've requested they take appropriate action, and suggested that spikedH baseball bats and a hungry doberman would seem completely appropriate in my opinion.   A Incidentally, William, taxidermy may not be involved, but there's A already an electronic "severed heads" page for usenet abusers who @ tangled with the alt.gothic "special forces". Have a chuckle at:+ http://thingy.apana.org.au/~fun/agsf/heads/   G I love the quote on that page: "And lo, the LART did come down from the E heavens trailing fire and brimstone. Yea verily, the LART did implant H itself in yon bozo's forehead, its mighty blade cleaving his thick skullH in twain and exposing the empty spaces therein for all the world to gaze3 upon with much mirth and frivolity" - Camille Klein    Shane   G P.S., No, I'm not a goth. You've got to love their attitude to spammers  though.    -----Original Message-----( From: VAXVMS [mailto:bounce@notmail.com]' Sent: Friday, January 17, 2003 12:22 PM  To: Info-VAX@Mvb.Saic.Com > Subject: RE: (OT) lots of spam in vmsnet.sdk.openvms.fieldtest       Shane S. said:  F  Somebody send me a copy of this, complete with mail headers, and I'll?  see what I can do. I've been getting into spammer-hunting as a   bloodsport recently.     Shane  
 Bloodsport?   	 Spammers?    I *like* the sound of that...   4 After *you're* finished, I say we collect donations / from the newsgroup for  the services of a good  5 taxidermist, and then put the photos of the finished  % work online as an example for others.  :^)    ========================  William W. Webb / DSSC/RLM, USPS OpenVMS Support Services& 4924 Green Road Raleigh, NC 27616-2800: 919.874.3043 <FirstInitialDotLastNameAtEmailDotUSPSDotGov>   ------------------------------  % Date: Fri, 17 Jan 2003 16:35:28 -0800 $ From: Shane Smith <ssmith@icius.com>> Subject: RE: (OT) lots of spam in vmsnet.sdk.openvms.fieldtest0 Message-ID: <01C2BE46.85281560@sulfer.icius.com>   Update:   ? It's not spam from a company, it's a community generating those H postings. What's happening is that the Spanish anime* community is usingC that newsgroup to share DIVX movies, apparently unaware that it was F being used for serious work. I have been contacted by the webmaster ofG one of their websites, apologising and promising to put the word around F to please go elsewhere. He can't promise, but apparently no malice wasC intended so maybe they'll just show some manners and you'll get the  group back.    Shane   C * Japanese animation; Akira, Ghost in the Shell, Urotsukidoji, etc.    -----Original Message----- From: Shane Smith & Sent: Friday, January 17, 2003 1:59 PM To: Info-VAX@Mvb.Saic.Com > Subject: RE: (OT) lots of spam in vmsnet.sdk.openvms.fieldtest    H I've been sent a copy of the mail in question offline (thanks) and firedF off a little flurry of complaints. I /think/ I've id'd the ISP hostingF the culprits as ic2net.net. No abuse account registered, so abuse@ andB postmaster@ have been informed. I've also fired of a quickie to anD unidentified node in the chain 207.218.223.39. For good measure I'veG also contacted the admin of the company who owns the apparent culprit's  IP address, admin@ev1.net.  F I've requested they take appropriate action, and suggested that spikedH baseball bats and a hungry doberman would seem completely appropriate in my opinion.   A Incidentally, William, taxidermy may not be involved, but there's A already an electronic "severed heads" page for usenet abusers who @ tangled with the alt.gothic "special forces". Have a chuckle at:+ http://thingy.apana.org.au/~fun/agsf/heads/   G I love the quote on that page: "And lo, the LART did come down from the E heavens trailing fire and brimstone. Yea verily, the LART did implant H itself in yon bozo's forehead, its mighty blade cleaving his thick skullH in twain and exposing the empty spaces therein for all the world to gaze3 upon with much mirth and frivolity" - Camille Klein    Shane   G P.S., No, I'm not a goth. You've got to love their attitude to spammers  though.    -----Original Message-----( From: VAXVMS [mailto:bounce@notmail.com]' Sent: Friday, January 17, 2003 12:22 PM  To: Info-VAX@Mvb.Saic.Com > Subject: RE: (OT) lots of spam in vmsnet.sdk.openvms.fieldtest       Shane S. said:  F  Somebody send me a copy of this, complete with mail headers, and I'll?  see what I can do. I've been getting into spammer-hunting as a   bloodsport recently.     Shane  
 Bloodsport?   	 Spammers?    I *like* the sound of that...   4 After *you're* finished, I say we collect donations / from the newsgroup for  the services of a good  5 taxidermist, and then put the photos of the finished  % work online as an example for others.  :^)    ========================  William W. Webb / DSSC/RLM, USPS OpenVMS Support Services& 4924 Green Road Raleigh, NC 27616-2800: 919.874.3043 <FirstInitialDotLastNameAtEmailDotUSPSDotGov>   ------------------------------  % Date: Fri, 17 Jan 2003 14:02:48 -0500  From: norm.raphael@metso.com3 Subject: Re: *** DANGER, Will Robinson! DANGER! *** ? Message-ID: <OF980B512F.B0993827-ON85256CB1.00689BCF@metso.com>    Sorry,= I was running the current incarnation of DSNlink at the time. : but the accvio was spontaneous while sitting at the prompt/ >    Press RETURN to continue, q RETURN to quit  -Norm   D From:  "David J. Dachtera" <djesys.nospam@earthlink.spamfree.net> on        01/16/2003 08:34 PM  % Please respond to "David J. Dachtera" -        <djesys.nospam@earthlink.spamfree.net>    To:    Info-VAX@Mvb.Saic.Com cc:   6 Subject:    Re: *** DANGER, Will Robinson! DANGER! ***     norm.raphael@metso.com wrote:  > % > Has anyone an explanation for this:  > / >    Press RETURN to continue, q RETURN to quit , > ***     DANGER, Will Robinson! DANGER! ***; >         operator new failure: insufficient virtual memory 8 > %SYSTEM-F-OPCCUS, opcode reserved to customer fault at PC=FFFFFFFF80A3E434,
 > PS=0000001B  > 4 >   Improperly handled condition, image exit forced. >  > [OpenVMS V7.2-2]   ..and the image is ... ?   -- David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------    Date: 17 Jan 2003 13:30:46 -0600 From: briggs@encompasserve.org3 Subject: Re: *** DANGER, Will Robinson! DANGER! *** 3 Message-ID: <FpPvdEK$50pF@eisner.encompasserve.org>   ^ In article <OF980B512F.B0993827-ON85256CB1.00689BCF@metso.com>, norm.raphael@metso.com writes: >  > Sorry,? > I was running the current incarnation of DSNlink at the time. < > but the accvio was spontaneous while sitting at the prompt    0 >>    Press RETURN to continue, q RETURN to quit- >> ***     DANGER, Will Robinson! DANGER! *** < >>         operator new failure: insufficient virtual memory9 >> %SYSTEM-F-OPCCUS, opcode reserved to customer fault at  > PC=FFFFFFFF80A3E434, >> PS=0000001B >>5 >>   Improperly handled condition, image exit forced.  >> >> [OpenVMS V7.2-2]   $ Clearly a bug in the DSNlink client.  9 Judging from the initial error message, a subroutine call G associated with "operator new" failed with an SS$_INSVIRMEM diagnostic. ; The programmer was paranoid enough to check the status, and = considered a failure either unlikely enough or recovery to be ; sufficiently problematic to warrant a rather bizzarre error  message.  ; The %SYSTEM-F-OPCCUS presumably resulted from attempting to 9 invoke exit handlers or condition handlers in a situation A where stack expansion had become impossible due to virtual memory @ exhaustion.  It is not easy to handle that situation gracefully,A especially in a high level language.  Speculating without much in ; the way of evidence, there may be a memory leak in DSNlink. > Or, it is possible that your page file quota or virtualpagecnt parameter is inadequate.   	John Briggs   ------------------------------   Date: 18 Jan 2003 03:50:15 GMT) From: rankin@pactechdata.com (Pat Rankin) 3 Subject: Re: *** DANGER, Will Robinson! DANGER! *** / Message-ID: <17JAN200319471533@pactechdata.com>   4 In article <FpPvdEK$50pF@eisner.encompasserve.org>,\#  briggs@encompasserve.org writes...  [...] = > The %SYSTEM-F-OPCCUS presumably resulted from attempting to ; > invoke exit handlers or condition handlers in a situation C > where stack expansion had become impossible due to virtual memory  > exhaustion.  [...]  A      The `abort()' routine in the C run-time library deliberately D triggers an OPCCUS fault (or more likely it just signals SS$_OPCCUS;A I don't recall which).  `operator new' suggests C++; it's support + library is bound to use a similar approach.   4                 Pat Rankin, <rankin@pactechdata.com>   ------------------------------  % Date: Fri, 17 Jan 2003 21:27:02 -0600 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>  Subject: Re: Alpha 3000 ... ' Message-ID: <3E28C986.9FFCAEBE@fsi.net>    Tim Smith wrote: > [snip]F > Cool, thanks for the replies to all.  I'm located in Canada so apart0 > from being a little cold up I should be ok :-)  = I should think you'd be equally cold when flaccid, as well...    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Fri, 17 Jan 2003 14:25:20 -0500 * From: "Bill Todd" <billtodd@metrocast.net>; Subject: Re: Alpha, Itanic and Opteron benchmark comparison 2 Message-ID: <EDOdna17v5ozxbWjXTWcqQ@metrocast.net>  0 "Arne Vajhj" <arne@vajhoej.dk> wrote in message# news:3E283E78.1050507@vajhoej.dk...  > Bill Gunshannon wrote:5 >  > In article <01C2BD52.CCA02350@sulfer.icius.com>, + >  > Shane Smith <ssmith@icius.com> writes: ' >  >>It's labeled SAP SD @ tier, 4 way:  >  >> $ >  >>HPServer rx5670 Itanium 2   470$ >  >>Alpha Server ES45           426$ >  >>Proliant DL590 Itanium      206$ >  >>IBM xSeries 440             330$ >  >>AMD Opteron 1.6ghz        ca600 > 6 >  >                  In any case, even at only 500 it >  > beat all the competitors. >  > No.  > ? > A chip that will be in systems that will ship sometime in the ; > future was faster than some systems that started shipping  > 1-2 years ago. > ; > If that ES45 was a 1000 MHz then I would call the Opteron  > result a total failure.   F Well, I would call that assessment incompetent:  one can *call* things anything one likes.   J Exactly *why* would you call the Opteron result, which was over 25% higherI than the next-best result even though running at only 1.6 GHz rather than I the 2 GHz planned for launch, a 'total failure'?  And would you therefore ; characterize the Itanic2 result as an even greater failure?   H As for myself, I'd say the Opteron result looks far better than anythingH else either present or planned for the near future except EV7 (and givenH that Opteron will be increasing its clock speed right through the end ofK this year while EV7 won't budge until it gets its 130 nm shrink a year from I now - when Opteron will be getting its own shrink to 90 nm - I'm not sure I that even EV7 will be able to catch it, let alone stay ahead).  Of course F we're not likely to see EV7 results for this or many other benchmarks,J because it would make Itanic look even more like the second-class pig that it is.   - bill   ------------------------------  % Date: Fri, 17 Jan 2003 21:07:22 +0100 6 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>; Subject: Re: Alpha, Itanic and Opteron benchmark comparison ) Message-ID: <3E28627A.8090700@vajhoej.dk>    Bill Todd wrote:2 > "Arne Vajhj" <arne@vajhoej.dk> wrote in message% > news:3E283E78.1050507@vajhoej.dk... ? >>A chip that will be in systems that will ship sometime in the ; >>future was faster than some systems that started shipping  >>1-2 years ago. >>; >>If that ES45 was a 1000 MHz then I would call the Opteron  >>result a total failure.  > H > Well, I would call that assessment incompetent:  one can *call* things > anything one likes.  > L > Exactly *why* would you call the Opteron result, which was over 25% higherK > than the next-best result even though running at only 1.6 GHz rather than 2 > the 2 GHz planned for launch, a 'total failure'?  7 Let us assume that Opteron 1.6 GHz system will actually 
 ship in 2003.    The ES45 1000 MHz is from 2001.   8 A 2003 system that is only 25% faster than a 2001 system is in my eyes a total failure.   It should be 100-150% faster.    Arne   ------------------------------    Date: 17 Jan 2003 14:24:36 -0600+ From: young_r@encompasserve.org (Rob Young) ; Subject: Re: Alpha, Itanic and Opteron benchmark comparison 3 Message-ID: <l8lDRt6QrLI7@eisner.encompasserve.org>   b In article <3E2836DD.9080301@vajhoej.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes: > Bill Gunshannon wrote:H >> But you accept the Itanium results even though you "never thougth theE >> first Itanic's ever hit the streets" and then discount the Opteron I >> for exactly that reason. You were wrong about the first and apparently  >> the second as well  >  > ???? > 8 > If you try and read what is written, then you will see > that: ' >    - I thougth the Proliant was a x86 1 >    - Shane told me that it was an early Itanium = >    - I noted that and wondered why it was there since AFAIK 9 >      they never sold any of those (it is a valid system < >      to test since it has been for sale, but a poor choice+ >      because very few were actually sold)  > = > So the Itanic I accepted was not the one that did not sell. ; > And I think the Itanic that did not seel should have been : > excluded from an entirely different reason than Opteron. > . > So I can not find any meaning in your post ! > 7 > The difference between systems and chips are a common 2 > recognized one. It is simply not fair to compare# > systems for sale with prototypes.  >   = 	Right.  Did anyone else catch the matter of fact method that 9 	Opterons will be selling in systems in July?  I saw that F 	after I saw another one that stated matter of factly that March/April= 	was not Opteron system time.  Was this always the case or is B 	this a slip?  If always the case, anyone got a reference?  I must 	be slipping if so.    				Rob    ------------------------------  % Date: Fri, 17 Jan 2003 14:38:39 -0500 * From: "Bill Todd" <billtodd@metrocast.net>; Subject: Re: Alpha, Itanic and Opteron benchmark comparison 2 Message-ID: <avqcnfu_iJJRxrWjXTWcqA@metrocast.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in message , news:EDOdna17v5ozxbWjXTWcqQ@metrocast.net...   ...   L > Exactly *why* would you call the Opteron result, which was over 25% higherK > than the next-best result even though running at only 1.6 GHz rather than K > the 2 GHz planned for launch, a 'total failure'?  And would you therefore = > characterize the Itanic2 result as an even greater failure?   H Whoops - while the planned top launch speed for Opteron is indeed 2 GHz,J that may well not apply to MP configurations immediately (1.6 GHz for themL seems consistent with what I remember), though it seems reasonable to expectE their clock rates to climb during the course of this year just as the H single-processor configurations are planned to.  So while the rest of myL comments stand, the lead in this particular 4-way benchmark may be less than0 would be the case for a single-processor system.   - bill   ------------------------------  % Date: Fri, 17 Jan 2003 15:36:58 -0500 * From: "Bill Todd" <billtodd@metrocast.net>; Subject: Re: Alpha, Itanic and Opteron benchmark comparison 2 Message-ID: <bHWdnZ-AuNvl9LWjXTWcog@metrocast.net>  0 "Arne Vajhj" <arne@vajhoej.dk> wrote in message# news:3E28627A.8090700@vajhoej.dk...  > Bill Todd wrote:4 > > "Arne Vajhj" <arne@vajhoej.dk> wrote in message' > > news:3E283E78.1050507@vajhoej.dk... A > >>A chip that will be in systems that will ship sometime in the = > >>future was faster than some systems that started shipping  > >>1-2 years ago. > >>= > >>If that ES45 was a 1000 MHz then I would call the Opteron  > >>result a total failure.  > > J > > Well, I would call that assessment incompetent:  one can *call* things > > anything one likes.  > > G > > Exactly *why* would you call the Opteron result, which was over 25%  higherH > > than the next-best result even though running at only 1.6 GHz rather than4 > > the 2 GHz planned for launch, a 'total failure'? > 9 > Let us assume that Opteron 1.6 GHz system will actually  > ship in 2003.   L Since 4-way Opteron systems at at least 1.6 GHz are scheduled to ship in Q2,K that seems a reasonable assumption.  Since Opterons are planned to increase K their speed by 600 MHz before year's end, expecting 2+ GHz 4-way systems in  2003 also seems reasonable.    > ! > The ES45 1000 MHz is from 2001.  > : > A 2003 system that is only 25% faster than a 2001 system  > is in my eyes a total failure.  I I think you need to brush up on your math skills.  Since the Alpha scored 7 426 and the Opteron about 600, that's about 40% faster.   J Of course, the 2002/2003 Itanic2 system was only about 10% faster than the Alpha.  J The more significant point, of course, is that systems don't improve theirL performance linearly with time, so basing your assessment on that assumptionJ (as you seem to above) is incompetent.  The real issue is how Opteron willL compare with its contemporaries (which may or may not be dramatically fasterL than the best systems of 2001, but that's just the way of the world), and inE that respect it looks like it will be the leader for single-processor K configurations (except for FP-style code) and at least an equal (to Madison I and EV7) in MP configurations (which, considering it's a far lower-power, K smaller processor that can be produced at significantly lower cost and runs 3 IA32 code like a bat out of hell, is no mean feat).    >  > It should be 100-150% faster.   H And you should be 100 - 150% smarter.  But life doesn't always work that way.   - bill   ------------------------------  % Date: Fri, 17 Jan 2003 15:40:33 -0500 * From: "Bill Todd" <billtodd@metrocast.net>; Subject: Re: Alpha, Itanic and Opteron benchmark comparison 2 Message-ID: <K9mdnZgEI7LS97WjXTWcqw@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:l8lDRt6QrLI7@eisner.encompasserve.org...    ...   6   Did anyone else catch the matter of fact method that: > Opterons will be selling in systems in July?  I saw thatG > after I saw another one that stated matter of factly that March/April > > was not Opteron system time.  Was this always the case or isC > this a slip?  If always the case, anyone got a reference?  I must  > be slipping if so.  L Opterons are scheduled to ship in April as of an AMD announcement within theG past couple of days (if not March, which may still happen).  MP Opteron G systems are scheduled to ship at least in Q2, though whether they'll be E there at the very beginning in March/April I don't recall having seen  explicitly stated.   - bill   ------------------------------    Date: 17 Jan 2003 15:02:47 -0600+ From: young_r@encompasserve.org (Rob Young) ; Subject: Re: Alpha, Itanic and Opteron benchmark comparison 3 Message-ID: <g475SczHIspA@eisner.encompasserve.org>   _ In article <K9mdnZgEI7LS97WjXTWcqw@metrocast.net>, "Bill Todd" <billtodd@metrocast.net> writes:  > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:l8lDRt6QrLI7@eisner.encompasserve.org...  >  > ...  > 8 >   Did anyone else catch the matter of fact method that; >> Opterons will be selling in systems in July?  I saw that H >> after I saw another one that stated matter of factly that March/April? >> was not Opteron system time.  Was this always the case or is D >> this a slip?  If always the case, anyone got a reference?  I must >> be slipping if so.  > N > Opterons are scheduled to ship in April as of an AMD announcement within theI > past couple of days (if not March, which may still happen).  MP Opteron I > systems are scheduled to ship at least in Q2, though whether they'll be G > there at the very beginning in March/April I don't recall having seen  > explicitly stated. >   5 http://www.informationweek.com/story/IWK20030116S0021   2 AMD Posts Huge Loss, Despite Positive Predictions 
 Jan. 16, 2003   M AMD's challenge is to cut costs in preparation for the upcoming launch of its H Opteron 64-bit processor by July. Last week AMD said it would soon beginI working with IBM to develop microchip technologies at IBM's Semiconductor K Research and Development Center in East Fishkill, N.Y. An objective of that F alliance is to produce 65-nanometer chips for commercial use by 2005.   ? 	That sentence isn't well written.  AMD isn't launching Opteron 2 	in July.  It hopes to cut costs by July.  Sheesh.  B 	By the way, AMD is fast approaching irrelevance as seen elsewhere 	in that article:   O For all of 2002, AMD's losses amounted to $1.3 billion, compared with a loss of F $60.6 million for 2001. Revenue dropped 31% in 2002, to $2.7 billion.    				Rob    ------------------------------  % Date: Fri, 17 Jan 2003 23:01:14 +0100 6 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>; Subject: Re: Alpha, Itanic and Opteron benchmark comparison ) Message-ID: <3E287D2A.9000206@vajhoej.dk>    Bill Todd wrote:2 > "Arne Vajhj" <arne@vajhoej.dk> wrote in message% > news:3E28627A.8090700@vajhoej.dk...  >>Bill Todd wrote:3 >>>"Arne Vajhj" <arne@vajhoej.dk> wrote in message & >>>news:3E283E78.1050507@vajhoej.dk...A >>>>A chip that will be in systems that will ship sometime in the = >>>>future was faster than some systems that started shipping  >>>>1-2 years ago.= >>>>If that ES45 was a 1000 MHz then I would call the Opteron  >>>>result a total failure. I >>>Well, I would call that assessment incompetent:  one can *call* things  >>>anything one likes. >>> M >>>Exactly *why* would you call the Opteron result, which was over 25% higher L >>>than the next-best result even though running at only 1.6 GHz rather than3 >>>the 2 GHz planned for launch, a 'total failure'?     ! >>The ES45 1000 MHz is from 2001.  >>: >>A 2003 system that is only 25% faster than a 2001 system  >>is in my eyes a total failure. > K > I think you need to brush up on your math skills.  Since the Alpha scored 9 > 426 and the Opteron about 600, that's about 40% faster.    And ? 25 and 40% both sucks !   L > Of course, the 2002/2003 Itanic2 system was only about 10% faster than the > Alpha. > L > The more significant point, of course, is that systems don't improve theirN > performance linearly with time, so basing your assessment on that assumption( > (as you seem to above) is incompetent.  A If you bothered taking a math course for approx. 14 year olds you ? will learn that things growing at constant percentage is called  exponential not linear.   D And it is generally accepted that CPU performance grow exponetially.  7 I belive in that. So do most other people. You may not.   J >                                       The real issue is how Opteron will! > compare with its contemporaries    True.   N >                                 (which may or may not be dramatically fasterF > than the best systems of 2001, but that's just the way of the world)   They are faster.   >>It should be 100-150% faster.  > J > And you should be 100 - 150% smarter.  But life doesn't always work that > way.  9 Sorry my brain can not grow at the 100-150% per two year.    But the power of CPU can and do    Arne   ------------------------------  % Date: Fri, 17 Jan 2003 21:25:24 -0600 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> ; Subject: Re: Alpha, Itanic and Opteron benchmark comparison ' Message-ID: <3E28C924.382B5B2E@fsi.net>    Arne Vajhj wrote: >  > Paul Repacholi wrote: * >  > Arne Vajhj <arne@vajhoej.dk> writes:? >  >>(Opteron is just a chip not a system I can go out and buy)  > ? >  > Better cross out Alpha as well then Arne. You can't buy an  >  > ES45 with Windowz either! >  > ???? > * > I think that I can buy an Alpha system !  H ...but not with WhineBloze installed on it - I think that was his point.   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Fri, 17 Jan 2003 21:31:24 -0600 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> G Subject: Re: Function keys no longer work after TCPware upgrade to 5.6. ' Message-ID: <3E28CA8C.A4E64626@fsi.net>    Steve Spires wrote:  > ' > Has anybody seen this problem before?  > B > We carried out an upgrade of both VMS and TCPware, so we are nowC > sitting at VMS 7.3 and TCPware 5.6 [on Alpha in case this makes a F > difference] but since doing the upgrade function keys [F1 to F14] noG > longer work correctly - it looks like the escape sequences might have   > changed, I'm not sure exactly. > F > If you've done a similar upgrade and have had a similar problem, any > help would be appreciated.   ????  @ O.k., first guess time is that you're talking about the keyboard7 connected as the UI side of the Graphics head, correct?   B Have you tried, for example, EDT to see if you can trap the escape# sequences being issued by the keys?   E I had a sort of similar problem on my 486 Linux box. X always had the  SHIFT key state inverted.    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------    Date: 17 Jan 2003 18:31:42 -0800/ From: chris@applied-synergy.com (Chris Scheers) 5 Subject: Re: How to flash VAXstation 4000/90 FEPROMS? = Message-ID: <754a27c1.0301171831.66a5d33f@posting.google.com>   l baby_p_nut@yahoo.com (Baby Peanut) wrote in message news:<c5cf6e8.0301160711.78023012@posting.google.com>...V > rivie@RIvie.no.domain wrote in message news:<slrnb29pcu.6t.rivie@RIvie.no.domain>...S > > In article <c5cf6e8.0301141455.3077d976@posting.google.com>, Baby Peanut wrote: 	 > > > Hi,  > > > I > > > I have a VAXstation 4000/90 with bad code in the FEPROMS.  Is there + > > > any way to reload the original image?  > > G > > The one time I've done it, I pulled the EPROMs and blasted 'em on a H > > ROM burner. Had to put sockets in because the power connector is tooG > > close to the EPROMs; you can get to the pins on the power connector B > > side through the top of a socket, but you can't go through theF > > top of an EPROM. Got in trouble when Field Circus saw the sockets. > > G > > You might check with the NetBSD folks. There was some discussion on F > > the problem a while ago; I think someone was talking about writingJ > > a flashing utility, but I don't know if that ever happened. Of course,H > > that's only useful if the ROMs work well enough to bring the VAX up.D > > If the VAX can't come up at all, you're gonna have to pull them. > > E > > In my case, I was fiddling with the I/O routines for a bare-metal D > > FORTH system and forgot to take the 4000/60 console I/O routinesF > > out. The 4000/60 console lives at the same address as some 4000/90J > > flash, and I accidentally erased one of the chips. So I had no choice;3 > > if I wanted to fix it, I had to pull the flash.  > D > I'd be upset too if I was a field service engineer with a firmwareG > upgrade kit and I found someone unsoldered the chips to fix a problem 8 > which can be corrected by using MOP to boot a utility. > E > That being said someone was nice enough to give me a copy and since G > NetBSD has trashed so many VAXstations I'm going to share it with the  > world: > 1 > http://hermes.tubas.net/vs4000-90A_firmware.zip     > The included readme.txt file refers to further instructions at5 http://prosic.cxo.dec.com/PUBS/BLITZES/TD001620.HTML.   E Unfortunately, that site does not appear to be available anymore.  Is * this information available somewhere else?  B Also, is the update for the -90 and -96 as well as the -90A.  (The readme.txt implies so.)n   Thanx!   ------------------------------  % Date: Sat, 18 Jan 2003 00:13:15 -0500n3 From: "Homer J. Simpson" <hsimpson@burnsenergy.com>p5 Subject: Re: How to flash VAXstation 4000/90 FEPROMS?p4 Message-ID: <I65W9.6987$F_3.3222@news.bellsouth.net>  G Prosic is an internal only site.  Never could be accessed from outside.b    < "Chris Scheers" <chris@applied-synergy.com> wrote in message7 news:754a27c1.0301171831.66a5d33f@posting.google.com...e5 > baby_p_nut@yahoo.com (Baby Peanut) wrote in messagem8 news:<c5cf6e8.0301160711.78023012@posting.google.com>...* > > rivie@RIvie.no.domain wrote in message- news:<slrnb29pcu.6t.rivie@RIvie.no.domain>... G > > > In article <c5cf6e8.0301141455.3077d976@posting.google.com>, Baby 
 Peanut wrote:i > > > > Hi,  > > > > K > > > > I have a VAXstation 4000/90 with bad code in the FEPROMS.  Is therek- > > > > any way to reload the original image?. > > >oI > > > The one time I've done it, I pulled the EPROMs and blasted 'em on a J > > > ROM burner. Had to put sockets in because the power connector is tooI > > > close to the EPROMs; you can get to the pins on the power connectorTD > > > side through the top of a socket, but you can't go through theH > > > top of an EPROM. Got in trouble when Field Circus saw the sockets. > > > I > > > You might check with the NetBSD folks. There was some discussion on-H > > > the problem a while ago; I think someone was talking about writingL > > > a flashing utility, but I don't know if that ever happened. Of course,J > > > that's only useful if the ROMs work well enough to bring the VAX up.F > > > If the VAX can't come up at all, you're gonna have to pull them. > > >?G > > > In my case, I was fiddling with the I/O routines for a bare-metaloF > > > FORTH system and forgot to take the 4000/60 console I/O routinesH > > > out. The 4000/60 console lives at the same address as some 4000/90L > > > flash, and I accidentally erased one of the chips. So I had no choice;5 > > > if I wanted to fix it, I had to pull the flash.e > >oF > > I'd be upset too if I was a field service engineer with a firmwareI > > upgrade kit and I found someone unsoldered the chips to fix a probleme: > > which can be corrected by using MOP to boot a utility. > > G > > That being said someone was nice enough to give me a copy and since I > > NetBSD has trashed so many VAXstations I'm going to share it with the 
 > > world: > >e3 > > http://hermes.tubas.net/vs4000-90A_firmware.zipe >P >$@ > The included readme.txt file refers to further instructions at7 > http://prosic.cxo.dec.com/PUBS/BLITZES/TD001620.HTML.o >iG > Unfortunately, that site does not appear to be available anymore.  Isn, > this information available somewhere else? > D > Also, is the update for the -90 and -96 as well as the -90A.  (The > readme.txt implies so.)r >  > Thanx!   ------------------------------  # Date: Fri, 17 Jan 2003 18:56:36 GMT.9 From: Alan Adams <alan.adams@orchard-way.freeserve.co.uk>l= Subject: Re: How to make a harddisk accessible via NFS on VMS ? Message-ID: <486759b64b.Alan.Adams@orchard-way.freeserve.co.uk>-  2 In message <qvB9ZD+xH3iZ@eisner.encompasserve.org>F           koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:  i > In article <3e2564ab@uni-wuerzburg.de>, "Franz-Jrgen Tollmann" <tollmann@vim.uni-wuerzburg.de> writes: N > > We want to make a harddisc on a alpha which runs VMS accessible to Windows > > and Linux clients by NFS.e > > Is this complicated? >  >    No.  L In this case you seem to want an NFS server on VMS, and clients on Linux andH Windows. That is probably the simplest way to do it. (You could have theK server on any of the three, with the other two as clients. It affects where J the file really is, and where it gets backed up from, and how the security is set up.)=  J Getting the server running is simple - run SYS$MANAGER:TCPIP$CONFIG (OR IS5 IT CONFIGURE?) choose server section, and enable NFS.i  J The security is where it will get a little complicated. You need to defineH mappings between Windows and Linux users and equivalent VMS users. TheseL mappings control file access. It is done using the UCX (TCPIP for VMS) proxy; file. (I do't know how the alternative TCPIP stacks do it.)t   > O > > Is there an instruction with a detailed discription how to make a device orh! > > directory accessible via VMS.  > H >    Choose 1 of DECnet, NFS, or Pathworks.  The follow the installationF >    instructions.  THere's no market for a "Dummies" book because the  >    instrucitons are that good. >   J The proxy section is not as simply explained as I think it could be. After8 reading it half a dozen times, you should get it sorted.   -- a
 Alan Adams& alan.adams@orchard-way.freeserve.co.uk http://www.nckc.org.uk/d   ------------------------------    Date: 17 Jan 2003 19:13:35 -0800, From: JimStrehlow@data911.com (Jim Strehlow)= Subject: Re: How to make a harddisk accessible via NFS on VMSe= Message-ID: <4b6ec350.0301171913.74b4dece@posting.google.com>   l "Franz-J rgen Tollmann" <tollmann@vim.uni-wuerzburg.de> wrote in message news:<3e2564ab@uni-wuerzburg.de>...L > We want to make a harddisc on a alpha which runs VMS accessible to Windows > and Linux clients by NFS.f > Is this complicated?M > Is there an instruction with a detailed discription how to make a device orc > directory accessible via VMS.a >  > Cheers, Franzr  1 I thought I would give you a "real life example".   @ We have an Oracle on Windows 2000 application (stored procedure) write to a Windows foldere/ shared using Hummingbird's NFS Maestro product.o  B The following OpenVMS DCL (for "UCX" (TCP/IP services for OpenVMS)2 is called by our SYstartup_VMS.COM so that OpenVMS$ applications may find the directory.  E $TCPIP MOUNT DNFS5: XXX XXX /GID="0"/UID="0"/SYSTEM /USER= username - 5  /HOST= "dnsHostName" /PATH="drive:\folderPathName" -i.  /BACKGROUND=(DEL:00:01:00,RET:20)/RETRIES=4 --  /CACHE_TIMEOUT=(DIRECTORY:00:00:01,READ_DIR)o   $DIRECTORY DNFS5:[000000]f   $ sho dev dw  P Device                  Device           Error    Volume         Free  Trans MntP  Name                   Status           Count     Label        Blocks Count Cnt ... P DNFS5:                  Mounted              0  DNLD         235469760     1   1 ...s  ; It does work! (minimum OpenVMS v7.2-1 and Oracle 8.1.6.0.0)i' Jim Strehlow, Data911, Alameda, CA, USA-M (opinions are my own. I am not endorsing any particular software or vendors.)h   ------------------------------  # Date: Fri, 17 Jan 2003 22:51:35 GMTk. From: peter@langstoeger.at (Peter LANGSTOEGER)D Subject: Re: HP's Alpha Marvel arrives on Tuesday (says The Inq....)2 Message-ID: <XN%V9.31244$TY.304009@news.chello.at>  c In article <3E21D637.1B664C7D@aaa.com>, Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> writes:n) >http://www.theinquirer.net/?article=7161w  & What will be launched on 14-Jan-2003 ?9 The MARVELs are in the offical price book since Nov-2002.u+ But, they are ES47 and GS1280 and not GS47.eL Is the first EV7 ECO the said launch ? (prod. 8,9-Jan, ann. some days later)< The press release is as Mike wrote still "coming very soon".  # btw What has happened to the ES80 ?   J So, unfortunately I enjoyed the MARVELs but not the delay nor this article   -- t Peter "EPLAN" LANGSTOEGER1% Network and OpenVMS system specialistj E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Fri, 17 Jan 2003 23:08:47 -0500h2 From: rdeininger@mindspring.com (Robert Deininger)D Subject: Re: HP's Alpha Marvel arrives on Tuesday (says The Inq....)L Message-ID: <rdeininger-1701032308480001@user-2ive125.dialup.mindspring.com>  N In article <XN%V9.31244$TY.304009@news.chello.at>, peter@langstoeger.at wrote:  1 >In article <3E21D637.1B664C7D@aaa.com>, Jan-Erikv2 =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> writes:* >>http://www.theinquirer.net/?article=7161 > ' >What will be launched on 14-Jan-2003 ?p   Nothing, apparently.  : >The MARVELs are in the offical price book since Nov-2002., >But, they are ES47 and GS1280 and not GS47.  F There is no GS47 in the roadmap.  I think the name was considered long4 ago, but it won't be used for this batch of systems.  I ES47 comes in 2P and 4P flavors.  GS1280 starts with an 8P configuration.     = >The press release is as Mike wrote still "coming very soon".e   I expect so.  $ >btw What has happened to the ES80 ?  ) I think it will be announced a bit later.n   ------------------------------  % Date: Sat, 18 Jan 2003 00:49:19 -0500 > From: "Ray Fusci" <rxfxuxsxcxix(at)xcxhxaxrxtxexrx(dot)xnxext>D Subject: Re: HP's Alpha Marvel arrives on Tuesday (says The Inq....)/ Message-ID: <v2hqe7d52tjb07@corp.supernews.com>[  K I've been told the official announcement, previously scheduled for Tuesday,VK has been moved up to Monday. This does seem strange, as many people here ine( the US observe this Monday as a holiday.  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in message F news:rdeininger-1701032308480001@user-2ive125.dialup.mindspring.com...I > In article <XN%V9.31244$TY.304009@news.chello.at>, peter@langstoeger.att wrote: >e3 > >In article <3E21D637.1B664C7D@aaa.com>, Jan-Erikm4 > =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> writes:, > >>http://www.theinquirer.net/?article=7161 > >k) > >What will be launched on 14-Jan-2003 ?  >= > Nothing, apparently. >a< > >The MARVELs are in the offical price book since Nov-2002.. > >But, they are ES47 and GS1280 and not GS47. >IH > There is no GS47 in the roadmap.  I think the name was considered long6 > ago, but it won't be used for this batch of systems. >lK > ES47 comes in 2P and 4P flavors.  GS1280 starts with an 8P configuration.  >9 >5? > >The press release is as Mike wrote still "coming very soon".n >  > I expect so. >t& > >btw What has happened to the ES80 ? >o+ > I think it will be announced a bit later.    ------------------------------  % Date: Fri, 17 Jan 2003 17:44:56 -0600.0 From: "Sam Rozenfeld" <rozenfeld@nospam.dls.net>' Subject: HSZ-70 transfer rate question.r, Message-ID: <Re6cnStyLI5BCLWjXTWcoQ@dls.net>   Hello,  I We are running 4-node SCSI Alpha VMS cluster with single HSZ-70, KZPBA-CBeK controllers and DS-RZ1FB-VW 36.4G drives. I do not have a lot of experience H with the HSZ controllers but my understanding is that HSZ-70 can supportK transfer rate of 40Mhz with  these drives. However from the display below I J see that I am getting 20Mhz rate negotiated. Does that mean that I have my HSZ misconfigured ?o   HSZ> show disk20200FE Name          Type                      Port Targ  Lun        Used by L ---------------------------------------------------------------------------- --  B DISK20200     disk                         2    2    0        D202(           COMPAQ   BA03611C9B       3B07         Switches:            TRANSPORTABLE-L           TRANSFER_RATE_REQUESTED = 20MHZ (synchronous 20.00 MHZ negotiated)         Size: 71132000 blockss   ------------------------------  % Date: Fri, 17 Jan 2003 21:42:18 -0600n1 From: "David J. Dachtera" <djesys.nospam@fsi.net>e+ Subject: Re: HSZ-70 transfer rate question. & Message-ID: <3E28CD1A.B29E3D1@fsi.net>   Sam Rozenfeld wrote: >  > Hello, > K > We are running 4-node SCSI Alpha VMS cluster with single HSZ-70, KZPBA-CBNM > controllers and DS-RZ1FB-VW 36.4G drives. I do not have a lot of experience J > with the HSZ controllers but my understanding is that HSZ-70 can support3 > transfer rate of 40Mhz with  these drives. [snip]F  ) Is that based on the HSZ70 documentation?o  F Seems to me the HSZ70s pre-date SCSI-3 by a bit, but I could be wrong.  ' HSZ80, maybe... HS_G_80, very likely...g  + ...and might the shelf impose a limitation?e  H (I'm a DLS customer, by the way. Carol Stream. Still hoping for wireless
 broadband...)a   -- s David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/r   ------------------------------    Date: 17 Jan 2003 21:02:55 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)e+ Subject: Re: HSZ-70 transfer rate question.r- Message-ID: <LARFj5l1+k90@malvm7.mala.bc.ca.>v  - In article <Re6cnStyLI5BCLWjXTWcoQ@dls.net>, n5    "Sam Rozenfeld" <rozenfeld@nospam.dls.net> writes:v > K > We are running 4-node SCSI Alpha VMS cluster with single HSZ-70, KZPBA-CBeM > controllers and DS-RZ1FB-VW 36.4G drives. I do not have a lot of experiencepJ > with the HSZ controllers but my understanding is that HSZ-70 can support, > transfer rate of 40Mhz with  these drives.  E     I understood it to be 40MB/sec, not 40MHz ( ie 20MHz x 16 bits ).i  P     IIRC the host connection of the HSZ70 is only 10MHz ( x 16bits ), so runningF the disks faster is of limited benefit. When I did some simple minded J throughput tests on a HSZ-70 I couldn't get it to transfer more than aboutJ 16MB/sec to the host ( whereas an HSG80 tops out around 50MB/sec using the same test ).   ------------------------------  % Date: Sat, 18 Jan 2003 00:16:40 -0600T) From: "Sam Rozenfeld" <rozenfeld@dls.net>a+ Subject: Re: HSZ-70 transfer rate question.r, Message-ID: <4JCdncH2qrA2bbWjXTWc3Q@dls.net>  L But I should still be able to run drives at 40Mhz, right ? Why are my drives running at 20Mhz then ?h  > "Malcolm Dunnett" <nothome@spammers.are.scum> wrote in message' news:LARFj5l1+k90@malvm7.mala.bc.ca....1. > In article <Re6cnStyLI5BCLWjXTWcoQ@dls.net>,7 >    "Sam Rozenfeld" <rozenfeld@nospam.dls.net> writes:. > >eD > > We are running 4-node SCSI Alpha VMS cluster with single HSZ-70, KZPBA-CBD > > controllers and DS-RZ1FB-VW 36.4G drives. I do not have a lot of
 experienceL > > with the HSZ controllers but my understanding is that HSZ-70 can support. > > transfer rate of 40Mhz with  these drives. >JG >     I understood it to be 40MB/sec, not 40MHz ( ie 20MHz x 16 bits ).P >:J >     IIRC the host connection of the HSZ70 is only 10MHz ( x 16bits ), so running G > the disks faster is of limited benefit. When I did some simple mindedjL > throughput tests on a HSZ-70 I couldn't get it to transfer more than aboutL > 16MB/sec to the host ( whereas an HSG80 tops out around 50MB/sec using the > same test ). >.   ------------------------------    Date: 17 Jan 2003 20:08:38 -0800/ From: chris@applied-synergy.com (Chris Scheers)i Subject: KDA50 in BA123t= Message-ID: <754a27c1.0301172008.54b687c6@posting.google.com>S  A I have a client running a KA650 (MV III) in a BA123 with VMS 4.7.   : They are using a Dilog ESDI controller with a 760MB drive.  B (I will wait while you finish laughing.  When you have caught your& breath, please read on and advise me.)  F They have been having problems with data corruptions.  It appears that3 the Dilog controller is not handling forced errors.f  E I was thinking (dangerous, I know) that it might be a good idea (???)fC to replace the Dilog/ESDI setup with a KDA50 and an RA72.  At leasttC good quality RA72s can still be found.  The ESDI drives have prettye much dried up.  B The KDA50 is supported in a BA123, but does anyone know if VMS 4.7E supported it?  (Are the old SPDs available somewhere?)  Since it is a E MSCP controller, I assume that it should work at least as well as thet Dilog.  ? The KDA50-Q User Guide (EK-DKA5Q-UG-002) only shows wiring to asC bulkhead for connections to external drives.  Was there an internall) cable harness (ala MV3500) for the BA123?e  F Finally, can the RA72 operate without an external switch panel or will7 I need to devise one?  Or better yet, did DEC make one?n   Thanx!   ------------------------------  % Date: Fri, 17 Jan 2003 18:56:03 -0500o# From: Tom Rymes <tomnews@rymes.net>o, Subject: MicroVAX upgrade (to Alpha, maybe?)E Message-ID: <tomnews-39F4DC.18560317012003@news.comcast.giganews.com>   C Hi folks, I posted this to comp.sys.vms, but this group seems more sF active. If this is a FAQ, please point me in the right direction as I 4 haven't been able to locate adequate answers online.  C We currently run a MicroVAX 3100-95 under VMS 5.5-2. We're hitting jB performance limits on processor and RAM usage, and are looking to B upgrade. Our software vendor wants a ton of money for their newer E version, which runs on SCO Unix. The upgrade would allow performance 3B improvements by switching from VAX to Intel Architectures, but no " substantial feature improvements.   F For this reason, I want to explore my options for keeping our current A software and licenses, but moving them to a new machine. Now the >
 questions:  D 1.) What machines in the VAX line would allow us to do this? (4000, D 3100-98, etc...) and what issue with licensing, reinstallation, etc  might we run into?  C 2.) What is the likelihood that we could move to an Alpha platform oE instead? Licensing issues? Would our software run on Alpha, or would hC there be recompilation, tweaking, and who knows what else involved?l  H Basically, if we can locate a refurbed VAX or MicroVAX and/or Alpha and I limit our expenditure, then we'd be happy. Of course, I don't want to be rG penny-wise and pound-foolish, either. I just figure we'll save the big -F bucks for when we are ready to upgrade to a new version that provides  significant feature upgrades.p  $ Thanks for any help you can provide,   Tome   ------------------------------  # Date: Sat, 18 Jan 2003 02:02:30 GMTD# From: "John Smith" <a@nonymous.com>A0 Subject: Re: MicroVAX upgrade (to Alpha, maybe?)G Message-ID: <WA2W9.89288$pDv.8967@news04.bloor.is.net.cable.rogers.com>n  0 "Tom Rymes" <tomnews@rymes.net> wrote in message? news:tomnews-39F4DC.18560317012003@news.comcast.giganews.com... D > Hi folks, I posted this to comp.sys.vms, but this group seems moreE > active. If this is a FAQ, please point me in the right direction ass I 6 > haven't been able to locate adequate answers online. >SD > We currently run a MicroVAX 3100-95 under VMS 5.5-2. We're hittingC > performance limits on processor and RAM usage, and are looking tohC > upgrade. Our software vendor wants a ton of money for their newer,F > version, which runs on SCO Unix. The upgrade would allow performanceC > improvements by switching from VAX to Intel Architectures, but no # > substantial feature improvements.o > ? > For this reason, I want to explore my options for keeping oure current B > software and licenses, but moving them to a new machine. Now the > questions: >aE > 1.) What machines in the VAX line would allow us to do this? (4000,aE > 3100-98, etc...) and what issue with licensing, reinstallation, etce > might we run into? > D > 2.) What is the likelihood that we could move to an Alpha platformF > instead? Licensing issues? Would our software run on Alpha, or wouldE > there be recompilation, tweaking, and who knows what else involved?i > E > Basically, if we can locate a refurbed VAX or MicroVAX and/or Alphag andoD > limit our expenditure, then we'd be happy. Of course, I don't want to be:D > penny-wise and pound-foolish, either. I just figure we'll save the biga> > bucks for when we are ready to upgrade to a new version that provides > significant feature upgrades.d    D Do you have the source code for the application as it exists on your
 VAX today?   ------------------------------  % Date: Sat, 18 Jan 2003 00:19:12 -0400s0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>0 Subject: Re: MicroVAX upgrade (to Alpha, maybe?)/ Message-ID: <3E28D5BC.8107CDD2@vl.videotron.ca>n  E > > upgrade. Our software vendor wants a ton of money for their newertH > > version, which runs on SCO Unix. The upgrade would allow performanceE > > improvements by switching from VAX to Intel Architectures, but noy% > > substantial feature improvements.t  ( You have to ask yourself many questions.  1 How dependant are you on your software vendor ?  oL If they decide to pull new features from VAX-VMS, will this be a problem for your organisation ?oL Has your vendor made a commitment to VMS, or have they done the opposite and  promoted migrations to non-VMS ?    I Here are some charts on the digital/compaq/hp web site which may help you1 choose an upgrade:? http://h18002.www1.hp.com/alphaserver/performance/perf_tps.htmlA   or to get to the vax directly:G http://h18002.www1.hp.com/alphaserver/performance/perf_by_perf_dec.html     9 By the way, there are still some pages with text such as:0 ##I  After 22 successful years, Compaq decided to phase out the VAX platform. N Compaq is now fully committed to enhancing Alpha system products and providing, an upgrade path for our loyal VAX customers. ##  N Do you have a long term plan for this application ? If you upgrade to a biggerB vax now, how long will this last before you need another upgrade ?  F If you upgrade to an Alpha, how will your software vendor react ? (newE licences, or will they provide Alpha executables for low cost/free ?)x  F Do you have other applications on that vax ? If you migrate to another( platform, will you still need the vax ?   N Upgrading your vax is the easiest solution. However bear in mind the potentialI need to also upograde VMS to support a newer VAX model (5.5-2 is about 10  years old).3  G If you stay on VAX this time, it make let you just wait out the current L uncertainty on processors and then in a few years, you can then decide whereI you want to go ( 8086, Hammer (64 bit 8086), Sparc, Power or that Itaniums thing if it survives).   ------------------------------  % Date: Fri, 17 Jan 2003 14:52:10 -0500e* From: "Bill Todd" <billtodd@metrocast.net>$ Subject: Re: Montecito slips to 20052 Message-ID: <41idnR8teoBqw7WjXTWc3Q@metrocast.net>  4 "David Svensson" <icerq4a@spray.se> wrote in message7 news:734da31c.0301171003.5f0be2c5@posting.google.com...i7 > "Bill Todd" <billtodd@metrocast.net> wrote in messageh. news:<dFydnagSI9UjCLqjXTWcog@metrocast.net>...A > > "JF Mezei" <jfmezei.spamnot@vl.videotron.ca> wrote in message - > > news:3E277586.B43C15C4@vl.videotron.ca...m > > > Bill Todd wrote: > > > >e1 > > > > http://news.com.com/2100-1001-980898.htmle > > >eH > > > Interesting. The heading says Intel is moving Montecito ahead from 2007 totL > > > 2005. But later in the article, it is written Montecito was originally > >  planned@ > > > for 2004. So in the end, they have delayed it by one year. > > >aK > > > While, in the end, performance is what counts, I am puzzled as to whyt IA64L > > > needs so much cache to achieve its performance. Is IA64 so flawed that thetJ > > > only way to achieve palatable performance to load the chip up with a hugeG > > > about of fast cache memory ? Or do other processors have the same  amount > >  ofr > > > cache memory ? > >-K > > No, they have from considerably less to a hell of a lot less:  EV68 had  128 J > > KB on chip (though up to 16 MB off chip, which is supposedly over half thecL > > speed of the new EV7 on-chip L2), EV7 has 1.75 MB on chip, POWER4 and 4+I > > have about 1.5 MB on chip, Athlons have 384 KB on chip, Pentiums havem 256rL > > KB - 512 KB on chip, Xeons have 512 KB - 2 MB on chip, Hammers will have 384e6 > > KB - 1 MB on chip, PA-RISC has 1.5 MB on chip, ... > > L > > I've heard it said that one reason Itanic requires so much fast cache isG > > because it's an in-order processor, which means that any cache missw stallsD > > the processor entirely while it waits for main memory (unlike anF > > out-of-order processor which can often keep crunching ahead in theL > > instruction stream executing independent instructions that don't requireK > > uncached data while the request to main memory completes).  That soundstI > > reasonable, at any rate.  SPARC is an in-order processor as well, ands only6 > > recently got a decent-sized on-chip cache (1 MB?). > >2
 > > - bill >6E > The high-performance Alphas (those who are benchmarked) have prettytF > large caches. DS20/DS25 have 8Mb Level 2 cache, DS20L have 4Mb, ES45* > have 8-16Mb, GS80-360 have 16Mb cache...  J Indeed they do, but JF's comment was about *on-chip* cache.  And of courseL the EV68 off-chip caches are noticeably slower than EV7's on-chip cache - atG least I've seen EV68 cache access latencies reported to be 15 - 19 ns.,aJ which is excellent for an off-chip cache (though uses a good deal of powerH and expensive SRAM to achieve this) but can't match the 10 ns. for EV7's on-chip L2.h  K Since you mention benchmarks, by the way, it was interesting to see a 4-wayiK 1.25 GHz Alpha system benchmarked (I think for TPC-C) recently with only 16gL MB of off-chip L2 (rather than 16 MB per processor).  That's one good way toI make Itanic2 look good (since it had its full 3 MB of fast, on-chip cache) for each of its 4 processors).   - bill   ------------------------------   Date: 17 Jan 2003 23:26:21 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)$ Subject: Re: Montecito slips to 20050 Message-ID: <b0a3et$6b8$1@pegasus.csx.cam.ac.uk>  / In article <3E277586.B43C15C4@vl.videotron.ca>,r2 JF Mezei  <jfmezei.spamnot@vl.videotron.ca> wrote: >Bill Todd wrote:a >> f, >> http://news.com.com/2100-1001-980898.html >oK >Interesting. The heading says Intel is moving Montecito ahead from 2007 toeO >2005. But later in the article, it is written Montecito was originally plannedn; >for 2004. So in the end, they have delayed it by one year.   @ 2007 probably refers to the Chivano - the "Alpha Inside" Itanic.? It was originally hyped for 2005, but was more plausibly 2006+.u@ Whether this means that the 'new' Montecito is somewhere between< the old Montecito and the Chivano or the reporter simply got confused, I can't tell you.D     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 3346791   ------------------------------  % Date: Fri, 17 Jan 2003 21:18:59 -0600R1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 7 Subject: Re: Most common OpenVMS versions in use today?r' Message-ID: <3E28C7A3.DFFD8D43@fsi.net>r   JF Mezei wrote:e >  > Jan-Erik Sderholm wrote: @ > > Far more users have a PDF reader then a PS viewer on the PC. > 2 > Very few have a PDF viewer on their workstation. > O > TRhe problem with using your PV/MAC to view documentation is that it isn't onhN > the same screen as on your VMS workstation. And you can't copy/paste betweenA > the PDF document and your edit session on your VMS workstation.u > @ > With proper bookmarks, PDF can be about as good as bookreader.  D ...or even better since the current bookreader for PC doesn't print.   -- p David J. Dachtera  dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/d   ------------------------------  % Date: Fri, 17 Jan 2003 14:04:42 -0500># From: "Dan Allen" <dallen@nist.gov>s7 Subject: RE: Network Time Protocol (NTP) for OpenVMS ?? : Message-ID: <JFEPKAPBPMDFDBOIANGDEEEFCJAA.dallen@nist.gov>   > -----Original Message-----, > From: Arne Vajhoj [mailto:arne@vajhoej.dk]9 > Subject: Re: Network Time Protocol (NTP) for OpenVMS ??0 >  >  > Dave Baxter wrote:J >  >         I am interested in finding out if anyone uses NTP for keeping  >  > their system time accurate?D >  >         If so, do you use an HP/Compaq product or a third party
 >  > product?iK >  >         Is an Agent/Client required, and how do I go about getting it?  >  > UCX has NTP. > - > You can either get from a system you trust.  > 7 > Or better buy a GPS based appliance to get time from.n  / 	Why, we're free and reasonably trustworthy ;-)w   >  > Arne >  >    	Dan   ------------------------------  % Date: Fri, 17 Jan 2003 14:11:26 -0500 # From: "Dan Allen" <dallen@nist.gov>e7 Subject: RE: Network Time Protocol (NTP) for OpenVMS ?? : Message-ID: <JFEPKAPBPMDFDBOIANGDIEEFCJAA.dallen@nist.gov>   > -----Original Message-----9 > From: JF Mezei [mailto:jfmezei.spamnot@vl.videotron.ca] ) > Sent: Friday, January 17, 2003 12:27 PM0 > To: Info-VAX@Mvb.Saic.Comu9 > Subject: Re: Network Time Protocol (NTP) for OpenVMS ??t >  >  > Dave Baxter wrote: > >  > > Hi Guys,I > >         I am interested in finding out if anyone uses NTP for keeping- > > their system time accurate?r > J > An NTP client comes with TCPIP Services on VMS (and I assume other TCPIP > network stacks). > I > One question though: how does one go about finding NTP servers that cani > provide the time ?  4 http://www.boulder.nist.gov/timefreq/service/its.htm   ------------------------------  # Date: Fri, 17 Jan 2003 19:16:10 GMT 7 From: brad@.homeportal.2wire.net (Bradford J. Hamilton) 7 Subject: Re: Network Time Protocol (NTP) for OpenVMS ??e? Message-ID: <ZDYV9.594808$GR5.381805@rwcrnsc51.ops.asp.att.net>   b In article <3E283CFE.CED0E8CC@vl.videotron.ca>, JF Mezei <jfmezei.spamnot@vl.videotron.ca> writes: >Dave Baxter wrote:p >> w >> Hi Guys, H >>         I am interested in finding out if anyone uses NTP for keeping >> their system time accurate? >-I >An NTP client comes with TCPIP Services on VMS (and I assume other TCPIPy >network stacks).  >jH >One question though: how does one go about finding NTP servers that can >provide the time ?6  # Here are two references that I use:   L http://www.eecis.udel.edu/~mills/ntp/clock1a.html (public stratum 1 servers)  C http://www.eecis.udel.edu/~mills/ntp/clock2a.html ( " stratum 2 " )5      A _________________________________________________________________r0 Bradford J. Hamilton			"All opinions are my own"/ bMradAhamiPltSon@atMtAbi.cPoSm		"Lose the MAPS"t   ------------------------------  % Date: Fri, 17 Jan 2003 13:35:02 -0600g, From: "Art Beane" <art.beane@mindspring.com>7 Subject: RE: Network Time Protocol (NTP) for OpenVMS ??e1 Message-ID: <026d01c2be5f$883524f0$a77ba8c0@artb>e  
 My favorites:o   tick.usno.navy.mil tock.usno.navy.mil     > -----Original Message-----9 > From: JF Mezei [mailto:jfmezei.spamnot@vl.videotron.ca]s) > Sent: Friday, January 17, 2003 12:27 PM  > To: Info-VAX@Mvb.Saic.Comh9 > Subject: Re: Network Time Protocol (NTP) for OpenVMS ??  >  >  > Dave Baxter wrote: > >  > > Hi Guys,B > >         I am interested in finding out if anyone uses NTP for ' > > keeping their system time accurate?e > E > An NTP client comes with TCPIP Services on VMS (and I assume other s > TCPIP network stacks). > F > One question though: how does one go about finding NTP servers that  > can provide the time ?   ------------------------------  % Date: Fri, 17 Jan 2003 14:40:59 -040070 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>7 Subject: Re: Network Time Protocol (NTP) for OpenVMS ??./ Message-ID: <3E284E33.ACCA3FBB@vl.videotron.ca>7   Dan Allen wrote:6 > http://www.boulder.nist.gov/timefreq/service/its.htm  B many thanks. Aren't there time servers in other countries though ?   ------------------------------  # Date: Fri, 17 Jan 2003 19:59:12 GMTo7 From: brad@.homeportal.2wire.net (Bradford J. Hamilton) 7 Subject: Re: Network Time Protocol (NTP) for OpenVMS ?? / Message-ID: <kgZV9.716244$WL3.730425@rwcrnsc54>h  b In article <3E284E33.ACCA3FBB@vl.videotron.ca>, JF Mezei <jfmezei.spamnot@vl.videotron.ca> writes: >Dan Allen wrote:G7 >> http://www.boulder.nist.gov/timefreq/service/its.htm  >oC >many thanks. Aren't there time servers in other countries though ?    The other links provided t  1 http://www.eecis.udel.edu/~mills/ntp/clock1a.htmlg1 http://www.eecis.udel.edu/~mills/ntp/clock2a.htmlf  5 show a number of servers in CA, and around the world.o  A _________________________________________________________________ 0 Bradford J. Hamilton			"All opinions are my own"/ bMradAhamiPltSon@atMtAbi.cPoSm		"Lose the MAPS"a   ------------------------------    Date: 17 Jan 2003 14:34:26 -0600+ From: young_r@encompasserve.org (Rob Young) 7 Subject: Re: Network Time Protocol (NTP) for OpenVMS ??l3 Message-ID: <mH6MGEkTtxla@eisner.encompasserve.org>f  p In article <a3c44af1.0301170843.5e64fb2f@posting.google.com>, dave.baxter@bannerhealth.com (Dave Baxter) writes:
 > Hi Guys,G >         I am interested in finding out if anyone uses NTP for keepingc > their system time accurate? A >         If so, do you use an HP/Compaq product or a third partyo
 > product?H >         Is an Agent/Client required, and how do I go about getting it? >   > 	Yes.  As Bart and Bradford concur, I too use NTP to synch up. 	It is cool.  : 	You can spend time in the FAQ as Bradford mentions and do$ 	Google searches to become familiar.  > 	I use Multinet, so setup is probably different from HP/TCPIP.: 	I have found about 8 decent public Stratum 2 servers.  I ' 	have two NTP servers setup internally.h   				Rob9   ------------------------------    Date: 17 Jan 2003 14:41:08 -0600+ From: young_r@encompasserve.org (Rob Young) 7 Subject: RE: Network Time Protocol (NTP) for OpenVMS ??s3 Message-ID: <AVbhZCMe3DBG@eisner.encompasserve.org>a  ` In article <026d01c2be5f$883524f0$a77ba8c0@artb>, "Art Beane" <art.beane@mindspring.com> writes: > My favorites:e >  > tick.usno.navy.mil > tock.usno.navy.mil >   @ 	Those are often unreachable due to congestion and traffic.  NTP@ 	is built to have more than 1 time source.  I've found 4 Stratum 	2 sources is a good number.@ 	Above that is silliness, below that and if more than 1 drop offC 	for a while you are down to 1 and sanity checks are not happening.o   	My 2 cents.   				Robc   ------------------------------    Date: 17 Jan 2003 16:24:17 -0800( From: bob@instantwhip.com (Bob Ceculski)7 Subject: Re: Network Time Protocol (NTP) for OpenVMS ?? = Message-ID: <d7791aa1.0301171624.7f3ce160@posting.google.com>   u dave.baxter@bannerhealth.com (Dave Baxter) wrote in message news:<a3c44af1.0301170843.5e64fb2f@posting.google.com>...s
 > Hi Guys,G >         I am interested in finding out if anyone uses NTP for keepingh > their system time accurate?tA >         If so, do you use an HP/Compaq product or a third party 
 > product?H >         Is an Agent/Client required, and how do I go about getting it? >  > Thanks in advance, >  > Dave.s >   6 TCPware has it ... we use it ... only IP stack for VMS5 based on the VMS kernel which means it flies comparedi3 to the others ... also has more of a vms feel than ,3 the others ... easier to configure and maintain ...g   ------------------------------  % Date: Fri, 17 Jan 2003 15:00:02 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca> Subject: Re: NT on Alpha/ Message-ID: <3E2852A9.4621773A@vl.videotron.ca>f   Dirk Munk wrote:D > bit for the Alpha, so that the Alpha could play out its advantagesD > over the x86 architecture. Again Compaq was cheated, and so CompaqG > pulled the plug on NT instead of paying enormous amounts of money ford@ > the development of NT on Alpha, and getting nothing in return.    N I think it was a mutual agreement. Compaq was not interested in pushing Alpha.M Microsoft was not interested in a chip which was not going to grow to capturel4 a large enoughj volume to make it a worthy platform.  M Had Comapq made it very clear that it would push Alpha and re-instate it as aiM scalable chip (not just high end servers) and removed the "alpha workstations9L must be more expensive than intel ones" rule, then I suspect Microsoft would: have neen ore interested in helping promote Alpha/Windows.  L But if Microsoft saw through Compaq's real intentiosn to kill Alpha within aM couple of years, do you seriously think that Microsoft would be stupid enought/ to continue sinking money in a dying platform ?   L I despise, distrust Microsoft. But on this issue, the culpability rests with/ Palmer/Compaq for deciding not to market Alpha.a   ------------------------------  % Date: Fri, 17 Jan 2003 15:09:33 -0500r* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: NT on Alpha2 Message-ID: <Ux-cnWwYsoOX_rWjXTWc3g@metrocast.net>  + "Dirk Munk" <munk@home.nl> wrote in messagee2 news:4umg2vsbr0mid5a65ttnutv58n2o99auft@4ax.com...   ...   9  But the reason was a bit more complex then that. DigitalnB > and Compaq were cheated by M$ like no one else. M$ stole the VMS! > memory management from Digital,c  G Well, they stole most of the NT kernel from VMS and MICA.  But that was?? settled (perhaps incompetently by DEC, but still settled to itsV/ satisfaction) long before Compaq purchased DEC.o  $  and they they cheated them with the > cluster software.o  L The only Microsoft involvement with clusters that I'm aware of was to acceptI Compaq's donation of the combined NT/VMS cluster file system work DEC had.G done and then just put it on the shelf.  While that could be considered L incompetent use of a valuable asset, Compaq gave away the software by choiceL (part of its "We don't create technology:  we just use it" attitude) and was in no way cheated.  2  M$ promised Digital / Compaq that NT5 would be 64D > bit for the Alpha, so that the Alpha could play out its advantages6 > over the x86 architecture. Again Compaq was cheated,  I Wrong.  Microsoft was still moving ahead with Win64 on Alpha at the pointeJ where Compaq killed Win32 on Alpha.  There was some waffling about whetherH the Alpha release would be separate or would occur concurrently with theJ Itanic1 release (which was supposedly imminent at the time, though in factG would not occur for another 21 months), but the Microsoft commitment todK Win64 on Alpha remained clear and it's rather unlikely that they would have E refused to enter the 64-bit market for nearly another two years while.L waiting for Itanic (which of course was a complete dud when it finally *did*K appear, so they would have had to have waited nearly *3* years for a reallys) usable 64-bit platform other than Alpha).4    and so CompaqG > pulled the plug on NT instead of paying enormous amounts of money forn@ > the development of NT on Alpha, and getting nothing in return.  I The 'enormous amounts of money' was peanuts compared with the damage thatoF killing NT on Alpha did to the perception of Alpha's future (and henceL sales).  Of course, Curly was starting to decide back then that Alpha didn'tK have any future, but suggesting that either decision made any kind of sensee
 is absurd.  I As for 'nothing in return', NT systems constituted 15% of Alpha (I assumerE unit) sales before Compaq acquired DEC, and gave Alpha an entree intotK situations where it otherwise would not have been considered ("Well, if youcK don't like VMS, you can always decide to run NT on the systems.").  KillingeI NT on Alpha on the very eve of the appearance of Win64 (which Alpha wouldmD have had to itself for well over 2 years until Itanic2 appeared) was unbelievably stupid.   - bill   ------------------------------  % Date: Fri, 17 Jan 2003 15:25:14 -0500[# From: "Dan Allen" <dallen@nist.gov>  Subject: RE: NT on Alpha: Message-ID: <JFEPKAPBPMDFDBOIANGDOEEICJAA.dallen@nist.gov>   > -----Original Message-----9 > From: JF Mezei [mailto:jfmezei.spamnot@vl.videotron.ca] ( > Sent: Friday, January 17, 2003 2:00 PM > To: Info-VAX@Mvb.Saic.Com  > Subject: Re: NT on Alpha >  >  > Dirk Munk wrote:F > > bit for the Alpha, so that the Alpha could play out its advantagesF > > over the x86 architecture. Again Compaq was cheated, and so CompaqI > > pulled the plug on NT instead of paying enormous amounts of money fortB > > the development of NT on Alpha, and getting nothing in return. >  > P > I think it was a mutual agreement. Compaq was not interested in pushing Alpha.O > Microsoft was not interested in a chip which was not going to grow to capturea6 > a large enoughj volume to make it a worthy platform. > O > Had Comapq made it very clear that it would push Alpha and re-instate it as aoO > scalable chip (not just high end servers) and removed the "alpha workstations7N > must be more expensive than intel ones" rule, then I suspect Microsoft would< > have neen ore interested in helping promote Alpha/Windows. > N > But if Microsoft saw through Compaq's real intentiosn to kill Alpha within aO > couple of years, do you seriously think that Microsoft would be stupid enoughe1 > to continue sinking money in a dying platform ?N  M 	IIRC the discussions at the time centered around Microsoft's insistence that-N 	Compaq foot the ENTIRE bill - something they were unwilling to do for reasonsN 	of their own. Wound up in a pissing match between CPQ and MS with MS dropping$ 	support for Alpha across the board. > N > I despise, distrust Microsoft. But on this issue, the culpability rests with1 > Palmer/Compaq for deciding not to market Alpha.:   ------------------------------  % Date: Fri, 17 Jan 2003 14:44:12 -0500d* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: NT on Alpha2 Message-ID: <39WcnUoEPq-EwLWjXTWc3A@metrocast.net>  2 "Dean Woodward" <deanw@rdrop.com> wrote in message" news:3E284CFD.2000601@rdrop.com... > Dirk Munk wrote:   ...a  G > > There should have been a 64 bit Windows 2000 (=NT5) version for theiI > > Alpha, as promised by M$. However they did not fulfill their promise,mF > > and only wanted to sell a 32 bit Alpha version. Now who would have: > > guessed that, Micro$oft not fulfilling its promise ??? > G > Compaq killed Windows on Alpha, not Microsoft.  MS's only role was in C > being indifferent- if a CPU maker (other than Intel) wanted an NT F > port, they had to do the work and pay the costs involved.  Q decided. > supporting NT on AXP wasn't worth the costs.  F Well, you're both right, but the real blame seems to attach to Compaq.  D Compaq killed (removed funding for) 32-bit Windows (Win2K) on Alpha.K Microsoft then retaliated by deciding not to release 64-bit Windows (Win2K)tJ on Alpha either, though kept using it internally for their own developmentL purposes.  Definitely a boneheaded decision for Compaq; given that MicrosoftK could have been selling full-blown 64-bit Windows environments on Alpha forV, several years now, perhaps for them as well.   - bill   ------------------------------  % Date: Fri, 17 Jan 2003 20:45:59 +0100- From: Dirk Munk <munk@home.nl> Subject: Re: NT on Alpha8 Message-ID: <4umg2vsbr0mid5a65ttnutv58n2o99auft@4ax.com>  C On Fri, 17 Jan 2003 10:35:41 -0800, Dean Woodward <deanw@rdrop.com>s wrote:   >Dirk Munk wrote:k6 >> On Thu, 16 Jan 2003 17:23:28 -0600, arturo saavedraF >> No, that is not what it does. Windooz is 32 bit on Intel and Alpha.G >> What FX32! does is translating 32bit Intel Windows programs to 32bitl >  >1) FX!32, not FX32! >2) From the whitepaper at h5 >http://www.support.compaq.com/amt/fx32/fx-white.html  >M1 >    The background optimizer produces high-speedt9 >    native Alpha code from x86 code by using informationh7 >    that is gathered into profiles by the runtime. The-8 >    native Alpha code is subsequently made available to8 >    the runtime and executed the next time the image is7 >    run. It is this coordinated process that adds high56 >    performance to the transparency of execution, and' >    truly distinguishes DIGITAL FX!32., >PF >> There should have been a 64 bit Windows 2000 (=NT5) version for theH >> Alpha, as promised by M$. However they did not fulfill their promise,E >> and only wanted to sell a 32 bit Alpha version. Now who would haveh9 >> guessed that, Micro$oft not fulfilling its promise ???a >.G >Compaq killed Windows on Alpha, not Microsoft.  MS's only role was in 0C >being indifferent- if a CPU maker (other than Intel) wanted an NT dF >port, they had to do the work and pay the costs involved.  Q decided - >supporting NT on AXP wasn't worth the costs.   C Very true. But the reason was a bit more complex then that. Digital @ and Compaq were cheated by M$ like no one else. M$ stole the VMSC memory management from Digital, and they they cheated them with the C cluster software. M$ promised Digital / Compaq that NT5 would be 64 B bit for the Alpha, so that the Alpha could play out its advantagesB over the x86 architecture. Again Compaq was cheated, and so CompaqE pulled the plug on NT instead of paying enormous amounts of money for,? the development of NT on Alpha, and getting nothing in return. H   >,   ------------------------------  % Date: Fri, 17 Jan 2003 19:37:21 -0500 ' From: "Main, Kerry" <Kerry.Main@hp.com>s4 Subject: RE: Oracle LMON and LMDO buffered I/O usageT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4023D9B99@kaoexc01.americas.cpqcorp.net>   Bill,   E Both the OpenVMS version and Oracle versions are quite old. I seem to G remember this was fixed some time ago, but I don't remember if it was as VMS fix or an Oracle one.D  H As a suggestion, you might want to upgrade to V7.2-2 + latest P1 patchesF + latest TCPIP stack and patches as well (I seem to remember TCPIP was7 somehow involved, but its going back quite awhile ..=20w  F I noticed yours was a home system, and may not be able to upgrade, but@ there has been approx 5 additional Oracle releases past 8.1.6 on OpenVMS.   :-):   Regardsn  
 Kerry Main Senior Consultant  Hewlett-Packard (Canada) Co.! Consulting & Integration Servicesj Voice: 613-592-4660  Fax   : 613-591-4477 Email: kerryDOTmain@hpDOTcom-     (remove the DOT's and replace with "."'s)u     -----Original Message-----6 From: Bill McLaughlin [mailto:mcbill20@hotmail.com]=20 Sent: January 17, 2003 12:19 PMh To: Info-VAX@Mvb.Saic.Com 0 Subject: Oracle LMON and LMDO buffered I/O usage    D I am running Oracle Enterprise Server version 8.1.6.0.0 on Alpha VMS< 7.2. This is on a home system (AlphaStation 500 with 256MB).  G Oracle works OK but there are two processes that eat up huge amounts ofrG buffered I/O's, even on a totally idle database. The processes are LMONoD and LMDO. When I do a MONITOR SYSTEM, the buffered I/O total sits atH about 1030 and the top users alternate between the LMDO and LMON, at 512B or 513 each. After three days of uptime (with no process accessingE Oracle for the first two), the LMON has done 6133499390 I/O's and theZC LMDO has done 6133587962 I/O's. Here's the output form SHOW SYSTEM:.  F 2020012E ORA_V8160000000 LEF      6      194   0 00:00:00.22       277    263F 20200130 ORA_CALLS1_PMON HIB      6      117   0 00:00:04.60       895   1079F 20200131 ORA_CALLS1_LMON HIB      6133499390   0 00:00:06.45      1551   1340F 20200132 ORA_CALLS1_LMD0 HIB      6133587962   0 00:00:06.13       908    909F 20200133 ORA_CALLS1_DBW0 HIB      6      168   0 00:00:00.41       939   1010F 20200134 ORA_CALLS1_LGWR HIB      6      250   0 00:00:00.39       906   1056F 20200135 ORA_CALLS1_CKPT HIB      5   169118   0 00:01:45.14       770   1115F 20200136 ORA_CALLS1_SMON HIB      4      200   0 00:00:09.84      1634   1267F 20200137 ORA_CALLS1_RECO HIB      4      103   0 00:00:00.96      1103   1381F 20200138 ORA_LISTENER907 HIB      5   260834   0 00:00:10.93       793    596F 20200199 ORA_CALLS1B4824 LEF      6      191   0 00:00:00.35      2835   1022      
 Any ideas?   Thanks in advance.   Bill McLaughlin    ------------------------------  % Date: Fri, 17 Jan 2003 21:12:07 +0100 6 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>8 Subject: Re: Recovering from deleted .PCSI$DATABASE file) Message-ID: <3E286397.3090100@vajhoej.dk>    JF Mezei wrote: O > On VAX, there is an undelete utility. No garantees, but it has saved me a fewAD > times. If you're on a busy system though, your odds would be less.  ) How can an UNDELETE utility be VAX only ?t  - (same file system if the Alpha disk is ODS-2)    Arne   ------------------------------  # Date: Fri, 17 Jan 2003 20:27:21 GMTtA From: "Colin Butcher" <colin_DOT.butcher_AT@xdelta_DOT.co_DOT.uk>a8 Subject: Re: Recovering from deleted .PCSI$DATABASE file= Message-ID: <JGZV9.7706$M67.60673246@news-text.cableinet.net>D  J If you want to try the UNDELETE then best bet is DFU from the freeware CD,G Beware that it temporarily write locks INDEXF.SYS though, so it's not aoL great idea to do this with the system busy. Also, if the disc is a busy discL with not much free space you've probably lost the header and the data by now anyway.r  L You may not have an explicit backup of the file, but don't you have a recentJ system disc backup at all? If so then you can recover the file from there.H You may find that a restore, plus a few manual PRODUCT REGISTER commandsL (disembowel the PCSI kits and VMSINSTAL kits you have for the details) mightH work out. If you don't have a system disc backup then that's going to beF difficult, but I'd still try hacking it by disembowelling the PCSI andL VMSINSTAL kits, probably guided by the SYS$HELP:*.RELEASE_NOTES files to see% what you've installed over the years.c  
 Good luck.   -- Hope this helps. Cheers, Colin..' (colinDOT.butcherAT@xdeltaDOT.coDOT.uk)i    = "JF Mezei" <jfmezei.spamnot@vl.videotron.ca> wrote in message ) news:3E284D0B.7AC82F82@vl.videotron.ca...s > Jack Trachtman wrote:rJ > > I inadvertantly deleted a .PCSI$DATABASE product file and don't have a backup > > copy of it., >dK > On VAX, there is an undelete utility. No garantees, but it has saved me a  few D > times. If you're on a busy system though, your odds would be less.   ------------------------------  % Date: Fri, 17 Jan 2003 14:36:02 -0400s0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>8 Subject: Re: Recovering from deleted .PCSI$DATABASE file/ Message-ID: <3E284D0B.7AC82F82@vl.videotron.ca>h   Jack Trachtman wrote::O > I inadvertantly deleted a .PCSI$DATABASE product file and don't have a backup, > copy of it.   M On VAX, there is an undelete utility. No garantees, but it has saved me a fewhB times. If you're on a busy system though, your odds would be less.   ------------------------------    Date: 17 Jan 2003 14:40:53 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) 8 Subject: Re: Recovering from deleted .PCSI$DATABASE file3 Message-ID: <IQst2S8bAy7j@eisner.encompasserve.org>t  b In article <3E286397.3090100@vajhoej.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes: > JF Mezei wrote:gP >> On VAX, there is an undelete utility. No garantees, but it has saved me a fewE >> times. If you're on a busy system though, your odds would be less.e > + > How can an UNDELETE utility be VAX only ?1  ; If it runs in inner mode it would be impossible to VEST it.    ------------------------------  % Date: Fri, 17 Jan 2003 22:49:22 +0100p6 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>8 Subject: Re: Recovering from deleted .PCSI$DATABASE file) Message-ID: <3E287A62.8080906@vajhoej.dk>c   Larry Kilgallen wrote:d > In article <3E286397.3090100@vajhoej.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes: >>JF Mezei wrote:sP >>>On VAX, there is an undelete utility. No garantees, but it has saved me a fewE >>>times. If you're on a busy system though, your odds would be less.i  + >>How can an UNDELETE utility be VAX only ?t  = > If it runs in inner mode it would be impossible to VEST it.   6 OK - true, but why should it go into priviliged mode ?  . This is on disk data structures not in memory.   Arne   ------------------------------  % Date: Fri, 17 Jan 2003 17:05:32 -0500 ! From: VAXVMS <bounce@notmail.com>e8 Subject: RE: Recovering from deleted .PCSI$DATABASE fileK Message-ID: <BA52530E3149734A9BAABDBBFA808E4903027BBF@rlghncst964.usps.gov>t  A I think the VAX-only "undelete" utility that's being recalled was9G named FLORIAN, and as I recall one's chances of success with undeletinge were directly proportional to:  8 1) how quickly after deleting one tried to undelete; and  G 2) how much write activity occurred on the disk drive on which the filee formerly resided.a   WWWn  
 =============eJ If you want to try the UNDELETE then best bet is DFU from the freeware CD,G Beware that it temporarily write locks INDEXF.SYS though, so it's not arL great idea to do this with the system busy. Also, if the disc is a busy discL with not much free space you've probably lost the header and the data by now anyway.   L You may not have an explicit backup of the file, but don't you have a recentJ system disc backup at all? If so then you can recover the file from there.H You may find that a restore, plus a few manual PRODUCT REGISTER commandsL (disembowel the PCSI kits and VMSINSTAL kits you have for the details) mightH work out. If you don't have a system disc backup then that's going to beF difficult, but I'd still try hacking it by disembowelling the PCSI andL VMSINSTAL kits, probably guided by the SYS$HELP:*.RELEASE_NOTES files to see% what you've installed over the years.n  
 Good luck.   -- Hope this helps. Cheers, Colin.e' (colinDOT.butcherAT@xdeltaDOT.coDOT.uk)e    = "JF Mezei" <jfmezei.spamnot@vl.videotron.ca> wrote in messagel) news:3E284D0B.7AC82F82@vl.videotron.ca...p > Jack Trachtman wrote:tJ > > I inadvertantly deleted a .PCSI$DATABASE product file and don't have a backup > > copy of it.i > K > On VAX, there is an undelete utility. No garantees, but it has saved me ah fewh > times. If you're on    ========================  William W. Webb / DSSC/RLM, USPS OpenVMS Support Services& 4924 Green Road Raleigh, NC 27616-2800: 919.874.3043 <FirstInitialDotLastNameAtEmailDotUSPSDotGov>   ------------------------------  % Date: Fri, 17 Jan 2003 23:16:04 +0100s6 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>8 Subject: Re: Recovering from deleted .PCSI$DATABASE file) Message-ID: <3E2880A4.2070800@vajhoej.dk>o  
 VAXVMS wrote:uC > I think the VAX-only "undelete" utility that's being recalled wasf > named FLORIAN    May be.   * But to queue from Hunter Goatleys archive:   #Package FLORIAN #y #florian.zip1 #    Description: An UNDELETE utility for OpenVMSw! #    Version: V1.3-1, 21-DEC-1993p1 #    Author: Michael Gsandter <gsa@magwien.gv.at>  #    Architecture: VAX,AXP #    Size: 73 blocks #    Language: C   VAX *and* AXP.  C >        , and as I recall one's chances of success with undeletinge  > were directly proportional to: > : > 1) how quickly after deleting one tried to undelete; and > I > 2) how much write activity occurred on the disk drive on which the file  > formerly resided.i  ? True for all VMS undelete utilities. True for undelete utiltiese) for almost all operating systems I think.6   Arne   ------------------------------    Date: 17 Jan 2003 15:35:40 -0800. From: Jack.Trachtman@vmmc.org (Jack Trachtman)8 Subject: Re: Recovering from deleted .PCSI$DATABASE file< Message-ID: <69d784c4.0301171535.92b2887@posting.google.com>  = I remembered that DFU has an UNDELETE function and it worked.   Q I'm still interested in any insight into how to recover from my original problem.b   ------------------------------   Date: 18 Jan 2003 06:27:45 GMT- From: djweath@attglobal.net (Dave Weatherall)p Subject: Re: THREADCP problem 5 Message-ID: <DTiotGxQ0bj6-pn2-O02dgLNidHLT@localhost>m  1 On Thu, 16 Jan 2003 14:24:48 UTC, David Butenhof w <David.Butenhof@hp.com> wrote:   > Robert TRAWISKI wrote:T >  > > Hi,y > > N > > I develop program that should have kernel thread disabled (OpenVMS v.7.2-1/ > > and OpenVMS v.7.3-1). I use THREADCP tools:a > > C > > $ THREADCP/DISABLE=(MULITPE_KERNEL_THREADS,UPCALLS) PROGRAM.EXE  > > M > > But the program link few shared libraries. Shuold I do the same for those4 > > libraries ? For example: > > C > > $ THREADCP/DISABLE=(MULITPE_KERNEL_THREADS,UPCALLS) LIB1SHR.EXEc > N > Only the value for the MAIN image counts. The linker completely ignores any % > setting in loaded shared libraries.e  ? Which is probably just as well or those users who want Upcalls hB operating with their threaded app's might be less than chuffed :-)   --   Cheers - Dave.   ------------------------------    Date: 17 Jan 2003 13:18:04 -08003 From: Eric Smith <eric-no-spam-for-me@brouhaha.com>i& Subject: Re: vax6k.openecs.org rebirth0 Message-ID: <qh65snh3w3.fsf@ruckus.brouhaha.com>  > SkyWriter <skywriter@mrnutty.com> writes about memory for KL10 processors:lF > core memory never was 'swung out' oh the MF20  nmos (i think) memoryO > it was on the back cabinet door, with the power supplies directly beneath it. I > on MH20 core memory is was a stand alone cabinet, and the backplane wast > fixed to the cabinet.n  F There wasn't an MH20.  You must be thinking of an MH10 core box or the like.h  F Some KL10 variants could support external memory boxes (core from DEC,B semiconductor from Ampex and other vendors) using the DMA20 memoryL adapter.  This interfaced the KL10 S bus [*] to the KI-style external memoryG bus.  All DECsystem-1080 and -1090 systems were supplied this way.  Thet* DMA20 was optional on the -1091 and -1095.  H However, the KL10 variants used in the DECSYSTEM-2040, -2050, -2060, andF -2065 generally had internal memory.  MA20 and MB20 were internal coreF memory, and MF20 and MG20 were internal MOS memory.  All of these wereE normally mounted inside the KL10.  I'm not sure whether the DMA20 was8% a supported option on any of the 20s.t  F The interface to the MF20 and MG20 MOS memory was the X bus, which hadF the same functions and timing as the S bus but at different electrical? levels.  This required different translator modules in the mainh processor card cage.  E The KL10 cabinets were supposed to have stabilizer feet regardless ofw! whether they had internal memory.a   Eric    C [*] Not to be confused with the Sun Sbus which appeared more than a 
 decade later.L   ------------------------------  # Date: Sat, 18 Jan 2003 00:10:50 GMT2' From: SkyWriter <skywriter@mrnutty.com> & Subject: Re: vax6k.openecs.org rebirth+ Message-ID: <3E28C507.4BADC181@mrnutty.com>-   Eric Smith wrote:7  @ > SkyWriter <skywriter@mrnutty.com> writes about memory for KL10
 > processors:eH > > core memory never was 'swung out' oh the MF20  nmos (i think) memoryQ > > it was on the back cabinet door, with the power supplies directly beneath it.tK > > on MH20 core memory is was a stand alone cabinet, and the backplane was0 > > fixed to the cabinet.  > H > There wasn't an MH20.  You must be thinking of an MH10 core box or the > like.  >i  4 yup, i realized my mistake after i read it. oh well.   >0H > Some KL10 variants could support external memory boxes (core from DEC,D > semiconductor from Ampex and other vendors) using the DMA20 memoryN > adapter.  This interfaced the KL10 S bus [*] to the KI-style external memoryI > bus.  All DECsystem-1080 and -1090 systems were supplied this way.  Ther, > DMA20 was optional on the -1091 and -1095. >   H yes, i remember seeing ampex boxes too. also the DX20 for RP20 (IBM 3370 FBA I think)   >eJ > However, the KL10 variants used in the DECSYSTEM-2040, -2050, -2060, andH > -2065 generally had internal memory.  MA20 and MB20 were internal coreH > memory, and MF20 and MG20 were internal MOS memory.  All of these wereG > normally mounted inside the KL10.  I'm not sure whether the DMA20 was ' > a supported option on any of the 20s.  >F  J i believe the DMA20 was available, but i can't remember the modules cards.D it sat between the DTE m8552,53,54, and the memory M8560,61,58 (x8).0 but i'm pretty sure the quicklatches were there.   >oH > The interface to the MF20 and MG20 MOS memory was the X bus, which hadH > the same functions and timing as the S bus but at different electricalA > levels.  This required different translator modules in the maino > processor card cage.  ' either the m8516's or 19's, forgot.....n     > G > The KL10 cabinets were supposed to have stabilizer feet regardless oft# > whether they had internal memory.e  P sure, but it was really only imporant for the H761, and the MF20 & power supply.5 I dont' think the unibus cages were gonna tip a 20 :)a   > Eric >4E > [*] Not to be confused with the Sun Sbus which appeared more than am > decade later.f   ------------------------------    Date: 17 Jan 2003 18:50:53 -08003 From: Eric Smith <eric-no-spam-for-me@brouhaha.com>j& Subject: Re: vax6k.openecs.org rebirth0 Message-ID: <qhiswnkw6q.fsf@ruckus.brouhaha.com>   I wrote:K >> I'm not sure whether the DMA20 was a supported option on any of the 20s.N  ) SkyWriter <skywriter@mrnutty.com> writes:tL > i believe the DMA20 was available, but i can't remember the modules cards.F > it sat between the DTE m8552,53,54, and the memory M8560,61,58 (x8).2 > but i'm pretty sure the quicklatches were there.  D The DMA20 memory bus adapter consists of the M8560, M8563, and eightB M8558 modules.  Those modules were not normally present in systemsC originally manufactured to use internal memory.  In most KL10-based-F DECSYSTEM-20 models the backplane doesn't even have slots for them, so it's not even an option.  G I *think* all KL10s had backplane slots for the DIA20/DIB20 adapter forAG the KI-style I/O bus (two M8550 and one M8551).  Those were standard onMC the 1080 and 1090, and optional on other systems including the 20s.r  I >> The interface to the MF20 and MG20 MOS memory was the X bus, which hadmI >> the same functions and timing as the S bus but at different electricaliB >> levels.  This required different translator modules in the main >> processor card cage.   ) > either the m8516's or 19's, forgot.....o  J Two M8519 Memory Bus Translator modules converted the processor's internalI ECL signals to the memory bus, which then went to the DMA20 or MA20/MB20.aJ For systems with internal MOS memory (MF20/MG20), one or both of the M8519: modules were replaced by M8580 or M8581 X bus translators.   Eric   ------------------------------  % Date: Fri, 17 Jan 2003 11:48:10 -0800c2 From: "Randy Park" <rjpark@mindspring.nospaam.com>( Subject: Vaxstation 3100/30 still works!2 Message-ID: <b09mmd$g9p$1@slb5.atl.mindspring.net>  2 I hadn't used my old Vaxstation 3100/30 since last1 July.  I booted it up last night.  It still worksH3 just fine after 14 years.  It thought it was Augustf/ 5th.  I guess those battery weren't intended toe3 last for this long. It's running VMS 6.1.  A littlec/ bit slow in bring up a DecTerm window, but oncea it was up the speed was fine.h  6 The Alpha 3000/300LX was also booted (VMS 6.2).  Still- feels faster than my Pentium PC with Windoze.t  6 Maybe I'll try the MicroVax 2000 sitting in the corner later today.  4 I wish all computers were as reliable as the old DEC systems and VMS.   ------------------------------  % Date: Fri, 17 Jan 2003 21:37:31 +0100_" From: "Hans Vlems" <hvlems@iae.nl>, Subject: Re: Vaxstation 3100/30 still works!5 Message-ID: <b09pij$nm0qd$1@ID-143435.news.dfncis.de>-  ? "Randy Park" <rjpark@mindspring.nospaam.com> schreef in berichte, news:b09mmd$g9p$1@slb5.atl.mindspring.net...4 > I hadn't used my old Vaxstation 3100/30 since last3 > July.  I booted it up last night.  It still workss5 > just fine after 14 years.  It thought it was August-1 > 5th.  I guess those battery weren't intended tom5 > last for this long. It's running VMS 6.1.  A little 1 > bit slow in bring up a DecTerm window, but once  > it was up the speed was fine.l >T8 > The Alpha 3000/300LX was also booted (VMS 6.2).  Still/ > feels faster than my Pentium PC with Windoze.g >t8 > Maybe I'll try the MicroVax 2000 sitting in the corner > later today. >N6 > I wish all computers were as reliable as the old DEC > systems and VMS. >rI Ah, Digital build quality. My microVAX  2000 is from 1988 and still runs;r diskless that is+ because the RD54 went south late last year.-H In 2002 I picked up two VAXstations 4000-90A. They had been sitting in aI computer room since 1998 doing nothing: they were powered off. Re-seatingVD the video controllers and the memory stacks worked wonders and these machines ran fine ever since.sJ At work we had a VAXserver 6310. It was not used for 4 years but we neededH it to run Millenium tests on. The machine was powered on and ran without	 problems.1  L They don't build them like that these days; now where did I hear that before :-)N  
 Hans Vlems   ------------------------------  % Date: Fri, 17 Jan 2003 18:55:41 -05004, From: "Richard Tomkins" <tomkinsr@istop.com>, Subject: Re: Vaxstation 3100/30 still works!: Message-ID: <FJ0W9.8188$357.1108040@news20.bellglobal.com>  ' They don't build them that way anymore.h  I That's the whole problem folks, when Mr. PC arrived on the scene, all youkG fine customers went off buying so-called cheap PC's, and stopped buying/K Mini-Computers. Someone said your cost of ownership was going to be better,AF boy did you fall for it. We could not build our level of quality at PCJ prices and without buying customers to sustain us, we had to sell the firm and it's assets.  K Just think though, if at your office, you could take all the CPU chips, the2I memory simms and dimms and all the hard drives and put them in one systemRI box, or two, you'd have one heck of a computer. We could hvae been there,iC and it would be running top quality applications like DECWrite, andpI DECPresent on DECWindows, and you'd onlyhave one machine with one copy ofiA software to maintain, heck even one little guy could maintain it.   I Right now, everyone in your office is front-line PC maintenance, then youHK have the help desk people and then the guys that come to your deks and thenrD the special support people and then the experts when all else fails.  6 If you ask me, what ails America / The World today ...   rttc   ------------------------------  % Date: Fri, 17 Jan 2003 14:03:08 -0500e- From: "Peter Weaver" <peter.weaver@stelco.ca>p> Subject: Re: [OT] lots of spam in vmsnet.sdk.openvms.fieldtest5 Message-ID: <b09k1k$nabv1$1@ID-141708.news.dfncis.de>u   Larry Kilgallen wrote:H > A Usenet spammer seems to be doing file storage or distribution in the/ > newsgroup vmsnet.sdk.openvms.fieldtest today.c >RF > The headers indicate a complaint address for the relevant ISP, and IH > would urge those who want vmsnet.sdk.openvms.fieldtest to be availableE > for its designated purpose in the future to check it out and send aeC > complaint (including full headers from the newsgroup) to the ISP.t >uH > They will probably pay more attention if it is not just one person who > is complaining.'  L Good luck, when I first sent complaints to them they responded that the userG was not one of their users. I kept complaining for a few weeks but thatn4 effort was ignored. Judging by comments I've seen in< news.admin.net-abuse.email that is about par for that group.   -- Peter WeaverD Opinions are my own, and do not reflect the opinions of my employer,A nor the company that it sub-contracts to, nor the company that ito sub-contracts to.    ------------------------------  % Date: Fri, 17 Jan 2003 11:04:04 -08001$ From: Shane Smith <ssmith@icius.com>> Subject: RE: [OT] lots of spam in vmsnet.sdk.openvms.fieldtest0 Message-ID: <01C2BE18.2F43A4D0@sulfer.icius.com>  E Somebody send me a copy of this, complete with mail headers, and I'lla> see what I can do. I've been getting into spammer-hunting as a bloodsport recently.   Shane    -----Original Message-----2 From: Peter Weaver [mailto:peter.weaver@stelco.ca]' Sent: Friday, January 17, 2003 11:03 AMh To: Info-VAX@Mvb.Saic.Comi> Subject: Re: [OT] lots of spam in vmsnet.sdk.openvms.fieldtest     Larry Kilgallen wrote:H > A Usenet spammer seems to be doing file storage or distribution in the/ > newsgroup vmsnet.sdk.openvms.fieldtest today.o >lF > The headers indicate a complaint address for the relevant ISP, and IH > would urge those who want vmsnet.sdk.openvms.fieldtest to be availableE > for its designated purpose in the future to check it out and send aCC > complaint (including full headers from the newsgroup) to the ISP.p >nH > They will probably pay more attention if it is not just one person who > is complaining.t  G Good luck, when I first sent complaints to them they responded that theu userG was not one of their users. I kept complaining for a few weeks but thatw4 effort was ignored. Judging by comments I've seen in< news.admin.net-abuse.email that is about par for that group.   -- Peter WeaverD Opinions are my own, and do not reflect the opinions of my employer,A nor the company that it sub-contracts to, nor the company that ite sub-contracts to.c   ------------------------------  % Date: Fri, 17 Jan 2003 19:19:41 -0600 + From: Shael Richmond <ksrich@bellsouth.net>t> Subject: Re: [OT] lots of spam in vmsnet.sdk.openvms.fieldtest- Message-ID: <3E28ABAD.F33EB4F4@bellsouth.net>    Larry Kilgallen wrote: > H > A Usenet spammer seems to be doing file storage or distribution in the/ > newsgroup vmsnet.sdk.openvms.fieldtest today.i > F > The headers indicate a complaint address for the relevant ISP, and IH > would urge those who want vmsnet.sdk.openvms.fieldtest to be availableE > for its designated purpose in the future to check it out and send a>C > complaint (including full headers from the newsgroup) to the ISP.a > H > They will probably pay more attention if it is not just one person who > is complaining.a  F It's not the only one.  Several of the VMSNET newgroups are being used% that way.  It does make them useless.l   Shaelo   ------------------------------   End of INFO-VAX 2003.035 ************************