1 INFO-VAX	Fri, 31 Aug 2001	Volume 2001 : Issue 484       Contents:@ Re: A wishlist of one thing... (Re: My VMS Wish List (features)) Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64 Re: alpha - ia64' Re: Alpha ECU - Does it work from a CD? ' Re: Alpha ECU - Does it work from a CD?  Alpha/VMS V Sun/Solaris  Re: Alpha/VMS V Sun/Solaris  Re: Alpha/VMS V Sun/Solaris  Re: Alpha/VMS V Sun/Solaris E Re: Anyone notice old EDU licenses? I can't get them for beyond 2001.  ASN compiler Re: ASN compiler+ CA Masterpiece for VMS v3.0 --- please help ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update ) Re: Conference: CETS-2001 Detailed Update  Re: EV7 will never ship? Re: EV7 will never ship? Re: EV7 will never ship? FW: Alpha Parts For Sale% Help with backup needed, in a bind... ) Re: Help with backup needed, in a bind...  Re: I hate Compaq  Re: I hate Compaq  Re: I hate Compaq  Re: I hate Compaq  Re: I hate Compaq  Re: I hate Compaq  Re: I hate Compaq  Re: I hate Compaq . Intel announces IA-64 "HyperThreading" in 20022 Re: Intel announces IA-64 "HyperThreading" in 20022 RE: Intel announces IA-64 "HyperThreading" in 2002? Intel has released Hyper-threading for it's next gen processors C Re: Intel has released Hyper-threading for it's next gen processors E Re: Is there a VMS command to check if I have cache memory installed? E Re: Is there a VMS command to check if I have cache memory installed? E Re: Is there a VMS command to check if I have cache memory installed?  RE: Mark Twain Promo RE: Mark Twain Promo Re: More Alpha rubbish in print  Re: My VMS Wish List (features) 9 Re: Nits in Slides (was: Re: The Final Knell Has Sounded) 
 OPCOM in VMS.  Re: OPCOM in VMS. I Re: OpenVMS on Fault Tolerant IPF Hardware (was Re: EV7 will never ship?) I Re: OpenVMS on Fault Tolerant IPF Hardware (was Re: EV7 will never ship?) I Re: OpenVMS on Fault Tolerant IPF Hardware (was Re: EV7 will never ship?)  Re: PRINT /que=filename  Re: PRINT /que=filename ) RMU /SET AFTER_IMAGE_JOURNALING  --- HELP # Re: Setting up Remote Printer Queue # Re: Setting up Remote Printer Queue  Re: Some postive points I hope. * Re: still can't get my UCX licensed???????" Re: Storageworks retirement letter Sun has a go at Itanium # RE: Tape Parity Error: How to Read? # RE: Tape Parity Error: How to Read? # Re: Tape Parity Error: How to Read? # Re: Tape Parity Error: How to Read? $ Re: Terry Shannon Tech Talk on Tru64 Re: Tunneling DECnet over IP Re: Tunneling DECnet over IP Re: Tunneling DECnet over IP Re: Tunneling DECnet over IP Re: Understanding ast ?  Re: Wailing and Moaning.... 4 Re: Wailing at Eunuchs (was: Wailing and Moaning...)P Re: What are the exact steps in order to add a user account with VAX-VMS v6.0 v6' Re: Why continue with OpenVMS / Compaq?   F ----------------------------------------------------------------------  # Date: Fri, 31 Aug 2001 17:45:00 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)I Subject: Re: A wishlist of one thing... (Re: My VMS Wish List (features)) 3 Message-ID: <w2Qj7.1068$bB1.46026@news.cpqcorp.net>   ^ In article <3B8F0B57.D53E38BF@mailbag.com>, William Barnett-Lewis <wlewis@mailbag.com> writes:G :All I want is a copy of Dec Lisp (or MacLisp or any of the others that G :have run on the various DEC systems.) and it's source. All the rest is " :nice, but nowhere near necessary.  D   RuleWorks (though not the source code) is already on the Freeware.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------    Date: 31 Aug 2001 09:03:42 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>  Subject: Re: alpha - ia64 H Message-ID: <y4vgj4d835.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  8 Christian Bau <christian.bau@isltd.insignia.com> writes:  H > > I wonder if that chip was the same core design as currently shippingH > > models - they have some "double-pumped" circuits, right? I make that= > > 7GHz. I guess they're the kings of the overclocking hill! D > If you count that way, you should also tell us the cycle count forH > shift, integer multiply, fscale (I almost fell off my chair when I saw  > that one) after doubling them.  K You just have to accept the fact that there is no one single frequency that I describes a processor's properties any more, and it has been that way for H quite some time. It just so happens that there is one number which stillD dominates, or possibly better has a high correlation with, processorI performance (within a a family of processors, obviously), but if you are  @ interested in the details, you need to know a lot of parameters.   	Jan   ------------------------------    Date: 31 Aug 2001 09:07:17 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>  Subject: Re: alpha - ia64 H Message-ID: <y4sne8d7x6.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  0 "aaron spink" <aaronspink@earthlink.net> writes:  L > Over the past 7 years, Alpha was in the top spot for SpecIntXXX except forL > about 6 non contiguous months, for SpecFpXXX the number is pretty much the1 > same.  Kind of an interesting graph to look at.    Cute.   J IIRC, a lot of times these 'lapses in leadership' were the result of DEC'sH or Compaq's marketing efforts, i.e., not announcing a given processor orJ upgrade until they thought the time was ripe - with more delays than usual in the market.   	Jan   ------------------------------  % Date: Fri, 31 Aug 2001 14:16:28 +0200 B From: Christian Simmendinger <christian.simmendinger@debis-sfr.de> Subject: Re: alpha - ia64 + Message-ID: <3B8F801C.2020402@debis-sfr.de>    Robert Harley wrote:, > nmm1@cus.cam.ac.uk (Nick Maclaren) writes: > D >>The current information about McKinley is interesting, too.  IntelB >>have said that it will appear at 1 GHz and be c. 70% faster thanA >>the Itanic on SpecInt - which will make it comparable to only a  >>2 GHz Pentium 4  >> > H > Hi Nick.  You must be basing this on the 404 "preliminary" figure usedE > in marketing material a few months ago.  However the SPECint figure H > finally reported for Itanium is 314.  Add 70% and you're at 534.  ThisJ > would make McKinley slower than a 1.33 GHz Athlon or a 1.5 GHz Pentium 4( > (or an 833 MHz Alpha for that matter).  / And quite a bit slower than a 3.5 Ghz Pentium 4 < Presumably shipping Q3 2002. Including SMT 'Hyper threading'  ! McKinley is supposed ship Q2 2002    Uh    	 Christian    ------------------------------   Date: 31 Aug 2001 12:04:50 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: alpha - ia64 0 Message-ID: <9mnuh2$860$1@pegasus.csx.cam.ac.uk>  + In article <3B8F801C.2020402@debis-sfr.de>, D Christian Simmendinger <christian.simmendinger@debis-sfr.de> writes: |> Robert Harley wrote: / |> > nmm1@cus.cam.ac.uk (Nick Maclaren) writes:  |> >  G |> >>The current information about McKinley is interesting, too.  Intel E |> >>have said that it will appear at 1 GHz and be c. 70% faster than D |> >>the Itanic on SpecInt - which will make it comparable to only a |> >>2 GHz Pentium 4 |> >  K |> > Hi Nick.  You must be basing this on the 404 "preliminary" figure used H |> > in marketing material a few months ago.  However the SPECint figureK |> > finally reported for Itanium is 314.  Add 70% and you're at 534.  This M |> > would make McKinley slower than a 1.33 GHz Athlon or a 1.5 GHz Pentium 4 + |> > (or an 833 MHz Alpha for that matter).   @ Not quite.  I was basing it on the 370 "first announced" figure.< However, I notice that it hasn't got into the official list,< and had not heard that it has dropped to 314 - that would be> almost as much of a climbdown as Sun's fiasco!  But you may be> right, as that would explain WHY it hasn't been submitted ....  2 |> And quite a bit slower than a 3.5 Ghz Pentium 4? |> Presumably shipping Q3 2002. Including SMT 'Hyper threading'    A.k.a. "The Flying Pig".  $ |> McKinley is supposed ship Q2 2002  - Vaguely.  Breath holding is contra-indicated.      Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679    ------------------------------  % Date: Fri, 31 Aug 2001 13:30:32 +0100 0 From: andrew harrison <andrew.nospam@uk.sun.com> Subject: Re: alpha - ia64 * Message-ID: <3B8F8368.D76A57DF@uk.sun.com>   aaron spink wrote: > ? > "andrew harrison" <andrew.nospam@uk.sun.com> wrote in message & > news:3B8E281F.27767847@uk.sun.com...7 > > I always thought that the Alpha was a well designed 7 > > high performance CPU, depending on timing sometimes - > > the highest performing CPU sometimes not.  > > N > As a side note, we were a little bored at work on day recently, so one of myN > co-workers grabbed and munged all the available spec.org data for Spec95 and	 > Spec2k.  > L > Over the past 7 years, Alpha was in the top spot for SpecIntXXX except forL > about 6 non contiguous months, for SpecFpXXX the number is pretty much the1 > same.  Kind of an interesting graph to look at.  >   7 You have just proved my point. Go back and do the same  5 analysis but ignore SPECint/SPECfp and concentrate on 7 standard benchmarks that stress the rest of the system, 9 OS, Memory, I/O etc and you will find a totally different  story.    2 TPC-C Initial 8400 numbers better than anyone else3       then a gap until the very recent OPS in a box        result.	3 TPC-D First 100 GB result submitted (lead) have not        lead since. " TPC-H Never had a performance lead" TPC-W Never had a performance lead# SAP R3 Never had a performance lead # SAP R4 Never had a performance lead ' Notesbench Never had a performance lead & SPECsfs97 Never had a performance lead( Oracle apps Never had a performance lead= SPECweb96 Lead for 3 months in 96, lead for 3 months in Q4 98 ' SPECweb99 Never had a performance lead.   , All tell a different story and make equally * interesting but much less pleasant graphs.   regards  Andrew Harrison  Enterprise IT Architect    ------------------------------  % Date: Fri, 31 Aug 2001 13:33:28 +0100 0 From: andrew harrison <andrew.nospam@uk.sun.com> Subject: Re: alpha - ia64 * Message-ID: <3B8F8418.6D00FC76@uk.sun.com>   Bill Todd wrote: > < > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message/ > news:DmfJGVf$FU$u@eisner.encompasserve.org... > > > In article <3B8CECB0.735057C8@uk.sun.com>, andrew harrison$ > <andrew.nospam@uk.sun.com> writes: > > >  > > > Bill Todd wrote: > > >>8 > > >> "Smitty" <someone@microsoft.com> wrote in messageA > > >> news:yRXi7.159620$Xr6.898841@news-server.bigpond.net.au...  > > >>
 > > >> ... > > >>L > > >> > The EPIC technology used in the IA-64 Itanium's is superior to RISC > > >> > architechure. > > >>K > > >> Thanks:  it's really a relief to have an authoritative source put an  > end to > > >> all this speculation. > > >> > > > C > > > Now we know where Compaqs assertion that IA64 would be better > > > > than Alpha comes from. What a relief, everyone can sleepB > > > easily and you can stop asking Compaq to explain themselves. > > C > > Has anyone else noticed what an Alpha fan Andrew has become now + > > that Compaq says their future is IA64 ?  > M > Yup - glad there's finally a point we can agree on.  Too bad he didn't heed M > my suggestion back at the beginning of all this that this might be a family M > squabble he should stay out of:  I wouldn't object to a lot of his comments 0 > if they weren't so transparently self-serving. >   / I did heed your suggestion for a while but the  2 as the level of squatulence from the Compaq choir $ increased I found myself drawn back.  2 I think the final straw was Rob Young turning into an Intel booster.    Regards  Andrew Harrison  Enterprise IT Architect    ------------------------------  % Date: Fri, 31 Aug 2001 16:21:03 +0200 B From: Christian Simmendinger <christian.simmendinger@debis-sfr.de> Subject: Re: alpha - ia64 + Message-ID: <3B8F9D4F.7080804@debis-sfr.de>    Nick Maclaren wrote: > 4 > |> And quite a bit slower than a 3.5 Ghz Pentium 4A > |> Presumably shipping Q3 2002. Including SMT 'Hyper threading'  >  > A.k.a. "The Flying Pig". >    Hehe$ What's the flyping pig aspect here ? 3.5 Ghz ? SMT ? Q3 2000 ? 4 http://www.heise.de/newsticker/data/cp-28.08.01-000/, Sounds credible ... and it's not april too !  	 Christian    ------------------------------  % Date: Fri, 31 Aug 2001 15:48:59 +0100 ( From: Nic Clews <sendspamhere@127.0.0.1> Subject: Re: alpha - ia64 ) Message-ID: <3B8FA3DB.180E656B@127.0.0.1>    Bill Todd wrote: >   > > Ignore the witless comments. > M > Well, when one makes witless assertions, IMO one *should* be prepared for a + > certain lack of respect in the responses.   H As in "I don't agree with your point of view, so I'll disagree and throw* in a bit of abuse for good measure". Hmmm.   G > > The only 'research' I have been pointed to really are Paul DeMone's D > > articles, who hates Intel with a vengance (opinion), not exactly
 > > balanced.  > L > Certainly as balanced as your own opinions appear to be, I'd say.  But theL > main reason Paul's articles have been referred to is that they're the mostL > readily-accessible information available:  you've had ample opportunity toN > research other sources of information that might be more to your liking, and > have yet to present any.  D There is precious little, Paul DeMones articles are good and will beH missed. However if the contributor starting this thread was genuine, anyH hope of them offering any technical input has been wiped out by childish< comments and a refusal to accept an alternate point of view.   H > (Oh, by the way, you've also been pointed to a Compaq white paper thatL > explained the relative disadvantages of EPIC in great detail:  forget that > one?)   G Read that too, but you cannot say that was written with an unbiased pen G either. I can't really see an article being written saying "This is our E Alpha chip, and oh look, these are the advantages of a competing chip G over ours". I'm not claiming to be unbiased either, but I'm open minded   and I have my own reasons to be.   > >  Can you provide references, either web or other material. IJ > > have an open mind, and I'd also appreciate you posting here, perhaps aA > > summary of what you feel the strengths of EPIC are over RISC.  > F > Such references would be welcomed even by those of us who are highlyL > skeptical of EPIC's performance potential, since Intel has been remarkablyL > chary about providing any details of why EPIC's long-term future should beG > expected to be much more impressive than its present (especially when M > compared with the kinds of future features and the performance potential of + > each that the Alpha road maps presented).   G Exactly. The Intel roadmap details are as covert as the rest of Intel's F planned chip details. I didn't say I agreed with that though, its just the way it is right now.  G This is the opposite of our experience with Alpha, details of up to two G generations of chips start to become public as current generations just C start to hit the streets. Even Paul DeMone makes reference to Intel  withdrawing information.  * > > (Please also wear flameproof clothes). > K > They'll only be necessary if that summary of perceived strengths is *not* D > accompanied by supporting evidence of a more authoritative nature.  H Compaq and Intel are opposites. One fails to properly market yet is freeF with technical information, the other markets very well, and hides theF future designs. As I know fully by my personal experience in a totallyG unrelated field, that the apparent lack of evidence, does not mean thato there isn't any.   --  ( Regards, Nic Clews CSC Computer Sciences nclews at csc dot comt   ------------------------------  % Date: Fri, 31 Aug 2001 10:27:50 +0100h( From: Nic Clews <sendspamhere@127.0.0.1>0 Subject: Re: Alpha ECU - Does it work from a CD?) Message-ID: <3B8F5896.A4C07CDC@127.0.0.1>C   John Malmberg wrote: > ? > > ...after the floppy light pulses. So it appears that a:\ ish > > hard-coded in CF.EXE > A > IIRC: a: is not hardcoded in the ARC menu, it is an environmente> > variable that can be set through the ARC menu item to update > the environment variables.  G John, I'm grateful to you and also Fred K for the original information,26 we'll carry on hacking around for a while longer then.  G The 'hard-coding' I was referring to was the appearance at one point of2C the combination of "A:" and at another point "\serial.TXT". I would F imagine in the code, the CFG files are pulled in a using a list, but I> am guessing, and the appearance of such could well be fluke or co-incidence and irrelevant.  : >A supported configuration is probably better than a hack.  A Agreed, but we're also doing this out of interest. I'll post moree 'discoveries' here.   
 Thank you. --  ( Regards, Nic Clews CSC Computer Sciences nclews at csc dot come   ------------------------------  % Date: Fri, 31 Aug 2001 09:04:46 -0400 4 From: John Malmberg <Malmberg@dskwld.zko.dec.compaq>0 Subject: Re: Alpha ECU - Does it work from a CD?4 Message-ID: <3B8F8B6E.2010207@dskwld.zko.dec.compaq>   Nic Clews wrote: > John Malmberg wrote: > > >>>...after the floppy light pulses. So it appears that a:\ is >>>hard-coded in CF.EXEa >>>cA >>IIRC: a: is not hardcoded in the ARC menu, it is an environmentV> >>variable that can be set through the ARC menu item to update >>the environment variables. >>@ > The 'hard-coding' I was referring to was the appearance at one7 > point of the combination of "A:" and at another point  > "\serial.TXT".  < And what I am referring to is that with the ARC console, the: specific drive that is known as A: IIRC: is an environment* variable.  Erase it, and no more A: drive.  9 You could redefine it to point to any other drive that isi visible to the console.n  : There is also a CD environment variable so that you do not9 need to type in that long path for accessing files on theM CDROM.  : I do not currently have a system with an ARC menu handy to; refresh my memories, and can not find an obvious equivalenti? for the Alpha-Bios Console.  There may be something documented,e2 but so far I have been to lazy to RTFM about this.   -JohnE malmberg@dskwld.zko.dec.compaq Personal Opinion Onlyo   ------------------------------  % Date: Fri, 31 Aug 2001 08:48:47 +0100o/ From: "Gary" <gary.mcdonald@uk.thalesgroup.com>T  Subject: Alpha/VMS V Sun/Solaris% Message-ID: <9mnfhu$ck4$1@rdel.co.uk>n   Hi,E  L Does anyone have any performance information on this subject with respect to' web server loading and hardware spec's?s  # All assistance greatly appreciated.t   Regards,   Gary.i   ------------------------------    Date: 31 Aug 2001 11:18:18 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>-$ Subject: Re: Alpha/VMS V Sun/SolarisH Message-ID: <y466b4d1ut.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  1 "Gary" <gary.mcdonald@uk.thalesgroup.com> writes:M  N > Does anyone have any performance information on this subject with respect to) > web server loading and hardware spec's?   7 Have a look at the SPEC web benchmarks at www.spec.org.w   	Jan   ------------------------------    Date: 31 Aug 2001 07:56:31 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) $ Subject: Re: Alpha/VMS V Sun/Solaris3 Message-ID: <2QLYc8USpxe7@eisner.encompasserve.org>)  W In article <9mnfhu$ck4$1@rdel.co.uk>, "Gary" <gary.mcdonald@uk.thalesgroup.com> writes:- > Hi,- > N > Does anyone have any performance information on this subject with respect to) > web server loading and hardware spec's?e > % > All assistance greatly appreciated.    Well if _that's_ the case...  G I understand that the OSU web server is the most performant one on VMS.-  C Some years ago a prominent Macintosh web server developer had heavyhC criticism for something called WebSpec or SpecWeb because it merely A opened connections and did not use them, an unrealistic scenario.m   ------------------------------   Date: 31 Aug 2001 15:15:59 GMT3 From: gartmann@immunbio.mpg.de (Christoph Gartmann) $ Subject: Re: Alpha/VMS V Sun/Solaris0 Message-ID: <9mo9nf$e35$1@n.ruf.uni-freiburg.de>  c In article <2QLYc8USpxe7@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:lX >In article <9mnfhu$ck4$1@rdel.co.uk>, "Gary" <gary.mcdonald@uk.thalesgroup.com> writes: >> Hi, >> IO >> Does anyone have any performance information on this subject with respect toh* >> web server loading and hardware spec's? >>  & >> All assistance greatly appreciated. >  >Well if _that's_ the case...t >.H >I understand that the OSU web server is the most performant one on VMS. >bD >Some years ago a prominent Macintosh web server developer had heavyD >criticism for something called WebSpec or SpecWeb because it merelyB >opened connections and did not use them, an unrealistic scenario.  H And just in case: a web-server under VMS is extremely secure and stable.J I noticed a 10 fold increase in hits to our web-server due to the code-red< worm. Until now I didn't notice a decrease in response time.   Regards,    Christoph Gartmanni  H -- --------------------------------------------------------------------+H | Max-Planck-Institut fuer      Phone   : +49-761-5108-464   Fax: -452 |H | Immunbiologie                                                        |H | Postfach 1169                 Internet: gartmann@immunbio.mpg.de     |H | D-79011  Freiburg, FRG                                               |H +--------- http://www.immunbio.mpg.de/home/english/menue.html ---------+   ------------------------------  % Date: Fri, 31 Aug 2001 13:20:24 -0400-# From: Jim Agnew <agnew@hsc.vcu.edu>3N Subject: Re: Anyone notice old EDU licenses? I can't get them for beyond 2001.+ Message-ID: <3B8FC758.D22CF358@hsc.vcu.edu>e   Problem solved... was using last year's site code to get licenses.  apparently they generate the dates based on the site code...   for what it's worth.   jimn   Jim Agnew wrote: > G > Anyone notice old EDU licenses? I can't get them for beyond Aug 2001.  >  > Jim Agnew    ------------------------------  % Date: Fri, 31 Aug 2001 16:20:00 +0400i4 From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU> Subject: ASN compilerr0 Message-ID: <3B8F80F0.12B2AC42@SMTP.DeltaTel.RU>   Hi All! A 	I looking for an "ASN.1 compiler" for OVMS. Is there something ?.   --   Cheers,aF +OpenVMS [Sys|Net] HardWorker........................................+E  Russia,Delta Telecom Inc,                    Cel:  +7 (901) 971-3222 E  191119,St.Petersburg,Transportny per. 3                     116-3222dF +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm +   ------------------------------    Date: 31 Aug 2001 08:01:27 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)a Subject: Re: ASN compiler93 Message-ID: <j$s4a4pJ+zsn@eisner.encompasserve.org>F  g In article <3B8F80F0.12B2AC42@SMTP.DeltaTel.RU>, "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU> writes:r  C > 	I looking for an "ASN.1 compiler" for OVMS. Is there something ?>  G The folks at www.oss.com sell one for various systems to emit C source.  It is probably portable to VMS.e   ------------------------------  % Date: Fri, 31 Aug 2001 20:06:35 +1200w. From: Nivlesh Chandra <NChandra001@itc.gov.fj>4 Subject: CA Masterpiece for VMS v3.0 --- please helpM Message-ID: <084681714A1BD511970B0002A560015F2D774F@exchange01.govnet.gov.fj>    Helloe) we are using CA Masterpiece for VMS v3.0 eI There is a file called unp.dat that contains a record of all the journalscH that are processed. Also it contains entries for journals that have beenI deleted. This file (as I have been told by CA) needs to be analysed every"L month or so so that the deleted entries (which are useless ) are removed andL only the posted journal entries are kept. I am not too knowledgeable in thisK . thus if someone could explain this to me I would really appreciate it ...dH also if you could point out the utility to use ... it would be very much appreciated.   Nivlesh>   ------------------------------  % Date: Fri, 31 Aug 2001 12:45:24 +0100h0 From: andrew harrison <andrew.nospam@uk.sun.com>2 Subject: Re: Conference: CETS-2001 Detailed Update* Message-ID: <3B8F78D4.BCD3712B@uk.sun.com>   Jan C Vorbrueggen wrote: > * > "Jeff Killeen" <Jeff@IDM-IO.com> writes: > M > > I am firm believer that Compaq's (Digital's) most painful wounds are self2M > > inflicted.  I do not claim to be expert on other platforms an but haven't L > > both IBM and SUN put their customers through major hardware and software0 > > changes that forced source level recompiles? > H > The SunOS->Solaris was pretty bad in many respects. Some old user-modeI > executables refused to run, others had abominable performance. And thatt( > was a transition on the same hardware. >   A The initial SunOS compatibility support in Solaris was very poor,f? Sun seriously underestimated how many SunOS apps would not movet? immediately to Solaris and we didn't do a good job of providingb a SunOS runtime environment.  ? Sun did make a number of changes to this and by I think Solarise< 2.3 it had improved dramatically. I still run two SunOS appsB one of which I cannot be bothered to port (lost the source for 1) 6 on Solaris, neither ran on the first Solaris releases.  & But you are right it sucked initially.I > IBM's OS/390 upgrades are, AFAIK, all about compatibility at the binaryoH > level. When you recompile to the new models, you will uncover a lot ofE > the dirty programming tricks that were used. But then, what is new?a > 
 >         Jane   -- a Andrew Harrison  Enterprise IT Architect    ------------------------------  # Date: Fri, 31 Aug 2001 12:25:42 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update8 Message-ID: <anLj7.1361$cJ1.247928@typhoon1.gnilink.net>  / "- bill" <billtodd@foo.mv.com> wrote in messager7 news:841e9c22.0108301720.52039f3b@posting.google.com...c> > To refresh your memory:  Compaq broke the written, explicit,H > unequivocal commitments to Alpha's future expressed in the 'commitmentB > to Alpha' letter from Jesse Lipcon and Bill Heil that was postedA > prominently on Compaq's Web site until well after the June 25thoH > announcement.  In case you never saw that letter during the 2 years orD > so it was there, you can find a copy that I posted to comp.arch onG > August 19th under the "I hate Compaq" thread (a thread not started by.G > me, by the way), since some people there seemed to be unfamiliar withnG > the letter and it had finally disappeared from the Web site.  Similar G > commitments were made to many individual customers as well, of courseoE > - right up to June 25th (see an August 27th post from Alan Greig in>F > the same thread for just one example among many).  Compaq broke them3 > all without any hint of apology, let alone shame.>  G You have repeatedly claimed Compaq "lied".  At the time that letter wasmK posted it was truthful.  Jesse retired from Compaq in October 2000 and BillrL retired in January 2001.  Neither party was involved in the decision.  I seeK nothing in this that proves Compaq engaged in telling customers informationh it knew to be false.  L The fact is was posted after June 25th does not mean someone knew the 2 yearF old letter was there and intentionally left it posted.  Who knows if IE search Compaq's web site I might find an old page talking about theirm commitment to the PDP-11.6  L You set the standard that Compaq "lied" (known falsehoods) and you failed to  meet the standard with this one.  D > Compaq attempted to justify the decision by asserting that Alpha'sH > engineers had told it that Alpha would have difficulty keeping up withH > IA64's performance.  One Alpha architect has stated publicly that thisE > was an outright double-lie (i.e., no such statement was made by the B > Alpha engineers, nor do they concur with its content:  Alpha wasB > chugging right along the path laid out for it years ago, with noE > unexpected recent hiccups - until Compaq pulled out the rug on Junea> > 25th), and other Alpha architects (plus one high-level AlphaH > development manager) have privately agreed with him.  Not one has come& > forward to support Compaq's version.  K You will have to point me to where one of these Alpha architect said this -mI forgive if I don't have blind faith in your statements.  Also I need your I reference to where Compaq said it would have trouble "keeping up" because?D from day one I heard it as Compaq would have trouble maintaining itsI performance edge over IPF three generations out.  What I was told is very D different than what you claim Compaq said - there is a major betweenL "keeping up" and "maintaining its performance edge".  It was never expressed> to me as Alpha falling behind but instead IPF closing the gap.  J My understanding of what drove the decision was more than pure chip speed.J I was told upfront that it was at the system performance level that becameJ the issue.  Remember Alpha's performance advantage was both its chip speedH and the fact that it was 64 bit.  What the team saw who was building theG follow-on to the Wildfire was the IPF systems would close in on Alpha'shJ systems in the future - it was never ever expressed to me as Alpha systems  would have trouble "keeping up".  J I seriously disagree with your statement as to what Compaq claimed - I see- no lie here. Plus the article you quote belowdE (http://www.eetimes.com/story/OEG20010625S0105 ) backs up what I said  above...  :     "This is a very bold move for us," said Rich Marcello,3     vice president and general manager for Compaq'su0     performance systems group. He noted that the3     Alpha road map extended for several more years,t6     but that starting around 2004, when the chip would7     have competed head-to-head against Intel's Itanium,rA     its performance advantage would begin to erode significantly.,8     "When we looked at our road map and overlaid it with7     Intel's road map, we found there was no substantiala<     performance benefit," he said. "Basically, we are saying?     that we couldn't differentiate ourselves at the CPU level."s  K ... he did not say that there was a problem with "keeping up" he said theree/ was a problem with maintaining the "advantage".r  E > Inconsistently, Compaq also, via employee newsgroup posts and via aaC > discussion Mark Gorham and VMS engineers had with 'Alphaman' (seee? > c.o.v. posts the week of the announcement), stated that AlphacE > technology would be used to 'rescue' the failing IA64 architecture,nG > resulting in technology equivalent to what Alpha otherwise would havenH > been - and in a time-frame that would benefit the VMS port by the time? > it was completed.  This lie was so incompetent (and likely soeF > unwelcome when Intel heard about it) that it died out very quickly -@ > but it nonetheless happened, and Compaq is accountable for it.  J Internal newsgroup postings - give me a break.  Compaq (not individuals inL newsgroups) has never publically said, that I have seen, that the Alpha teamL would "rescue" IPF.  Compaq  has said that they will improve IPF by infusing7 Alpha technology - but they never said it was a rescue.i  L This one I am interested in seeing the details of because I remain skeptical0 as to how much of Alpha can be leveraged by IPF.  I I would want to see the exact Mark Gorham statement.  As far as what mosteI employees (not Compaq but employees) said the week of the announcement it J should be ignored.  The number of Compaq people who had detailed knowledgeG of what drove the decision was a very small number.  There were lots of.4 rumors and speculation floating around at that time.  E > And Compaq presented Alpha development costs as being unsupportableyG > (see a June 27th eWeek interview with Winkler, plus additional drivelr? > from Terry and others - including you).  I responded to theseiH > assertions in a July 19th posting in the c.o.v. "Alpha:  an invitationC > to communicate" thread, plus other smaller supporting posts since-A > then, and, again, no one has stepped forward with contradictory F > evidence to suggest that this was not yet another Compaq lie (thoughD > an EETimes story - http://www.eetimes.com/story/OEG20010625S0105 -C > suggests that Winkler's statement that Alpha's annual developmenthC > costs were $300 million was yet another lie, and the R&D spendingCA > projections in Compaq's own annual reports tend to support thate
 > suspicion).t  J My understanding is the costs came from all of Alpha _systems_ developmentF and NOT just the cost of pure chip development.  For example each timeA Compaq needed to burn a new set of ASIC's for the Wildfire duringeI development the cost was about one million dollars per batch - those cost"H start to add up very quickly.  It is not just the chip - it is the totalB cost of maintaining the server development effort unique to Alpha.  I Did Winkler say "Alpha's annual development costs" or did he say "Alpha'siK annual _chip_ development costs".  There is a big difference there.  Pleaset, point me to the source of the Winkler quote.   > Clear enough for you now?c  K All that is clear Bill is that your conclusions are based upon the spin you-G have attached to Compaq's actions and not what Compaq has actually beenlD saying.  You haven't backup up your case that Compaq "lied" (willfulH misrepresentation) and several statements you made above are contrary toJ what I heard from Compaq.  They only claim above you have that holds water/ is that Compaq's commitment to Alpha changed...a   ------------------------------    Date: 31 Aug 2001 15:21:27 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>h2 Subject: Re: Conference: CETS-2001 Detailed UpdateH Message-ID: <y4g0a8mkko.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ( "Jeff Killeen" <Jeff@IDM-IO.com> writes:  I > You have repeatedly claimed Compaq "lied".  At the time that letter wasiM > posted it was truthful.  Jesse retired from Compaq in October 2000 and BilleN > retired in January 2001.  Neither party was involved in the decision.  I seeM > nothing in this that proves Compaq engaged in telling customers informationt > it knew to be false. > N > The fact is was posted after June 25th does not mean someone knew the 2 yearH > old letter was there and intentionally left it posted.  Who knows if IG > search Compaq's web site I might find an old page talking about theird > commitment to the PDP-11.   L Irrelevant. The letter in question was linked to at a high-profile position,G and was pointed to as _the_ evidence for Compaq's committment after the:K original authors retired from Compaq, right up to the 25 June announcement.aL It was, for instance, frequently referenced to this purpose in presentationsL on various subjects from the VMS team, up to and including Marcello. If thatJ isn't "lying", I will never have to read anything published by any companyJ again, because there is no way I could rely on any of its contents for any	 purpose. 0  M > You will have to point me to where one of these Alpha architect said this -c; > forgive if I don't have blind faith in your statements.  a  7 Brannon Batson said so here, or in comp.arch (or both).m  L > [...] from day one I heard it as Compaq would have trouble maintaining its4 > performance edge over IPF three generations out.    F So Compaq stops competing now, because their performance edge _may_ beC eroding three generations out - i.e., at least five years from now?A  L > My understanding of what drove the decision was more than pure chip speed.  M That's not what was said or implied in publich statements, and in fact from a): technical point of view, is even more unlikely. See below.  L > I was told upfront that it was at the system performance level that becameL > the issue.  Remember Alpha's performance advantage was both its chip speedJ > and the fact that it was 64 bit.  What the team saw who was building theI > follow-on to the Wildfire was the IPF systems would close in on Alpha'snL > systems in the future - it was never ever expressed to me as Alpha systems" > would have trouble "keeping up".  F From a systems' point of view this is complete nonsense. The EV7, thenG recently completed, has features that make building large-scale systemseH much easier than with any other processor on the market or the roadmaps.H Thus, building large IPF systems will take much more effort in designingH and building the systems interconnect than building large Alpha (EV7 andF follow-on) systems. There is nothing disclosed about IPF or any futureM implementation of the IA64 architecture that makes it even remotely plausible> this claim could be true.   < >     "This is a very bold move for us," said Rich Marcello,5 >     vice president and general manager for Compaq'ss2 >     performance systems group. He noted that the5 >     Alpha road map extended for several more years,s8 >     but that starting around 2004, when the chip would9 >     have competed head-to-head against Intel's Itanium,mC >     its performance advantage would begin to erode significantly.o: >     "When we looked at our road map and overlaid it with9 >     Intel's road map, we found there was no substantiale> >     performance benefit," he said. "Basically, we are sayingA >     that we couldn't differentiate ourselves at the CPU level."e  H See above. To render such statements believable would require a detailedM disclosure of in-depth technical information and analysis; all other evidenceuK pointing to the contrary, one has to assume this is post-hoc drivel to make , bad management decisions publicly plausible.  I > For example each time Compaq needed to burn a new set of ASIC's for the-N > Wildfire during development the cost was about one million dollars per batch  L 'scuse me? One iteration of a custom processor in 0.18 um at a certain well-K known German semiconductor company was about DM 150-200k, according to the aK person out of whose account that money was coming. You are talking 10 timest as much.  + > It is not just the chip - it is the totalvD > cost of maintaining the server development effort unique to Alpha.  M And Compaq has publicly said that everything but the Alpha _chip_ developmenttK is continuing, e.g., Marvel et al., because future servers, both with Alphas8 and IPF processors, will be based on a common platform.   K > Did Winkler say "Alpha's annual development costs" or did he say "Alpha'srM > annual _chip_ development costs".  There is a big difference there.  Pleases. > point me to the source of the Winkler quote.  D IIRC, the source is an analysts conference early this year (March orD thereabouts), and the $300M was total development costs. Estimate anC engineer on a design team to cost about $300k per year. That means  H Winkler's figure is 1000 engineers in total. I don't think a chip designD team runs to 500 engineers each, and still produce good results (cf. the Itanium design).  N But Bill's central point is that, even taking Winkler's figures at face value,I the decision as conveyed on 25 June in all likelihood does more damage togI Compaq's bottom line than would have any other way of proceeding forward,AI including an announcement of the OS ports to IA64 (which are quite cheap,sG compared to other activities) while maintaining Alpha development. From>J this point follows a prediction that can be verified on the basis of, say,G the 1CQ2002 results of the company. Are you willing to bet with Bill ona+ specific numbers, and be held to that bet? i   > > Clear enough for you now?v   	Jan   ------------------------------  # Date: Fri, 31 Aug 2001 13:42:40 GMT4& From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update8 Message-ID: <kvMj7.1398$cJ1.270367@typhoon1.gnilink.net>  L "Jan Vorbrueggen" <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote inJ message news:y4g0a8mkko.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de...K > > For example each time Compaq needed to burn a new set of ASIC's for thehJ > > Wildfire during development the cost was about one million dollars per batcht >kH > 'scuse me? One iteration of a custom processor in 0.18 um at a certain well-pL > known German semiconductor company was about DM 150-200k, according to theG > person out of whose account that money was coming. You are talking 10  times 
 > as much.  I Dave Fenwick - Project leader for the Wildfire - Each special developmentc) batch of ASIC cost about $1 million each.e  C This is very indicative of the pure speculation is going on here...:   ------------------------------  # Date: Fri, 31 Aug 2001 13:46:37 GMTv& From: "Jeff Killeen" <Jeff@IDM-IO.com>2 Subject: Re: Conference: CETS-2001 Detailed Update8 Message-ID: <1zMj7.1831$pU4.583415@typhoon2.gnilink.net>  L "Jan Vorbrueggen" <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote inJ message news:y4g0a8mkko.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de...  I > But Bill's central point is that, even taking Winkler's figures at faceh value,K > the decision as conveyed on 25 June in all likelihood does more damage to K > Compaq's bottom line than would have any other way of proceeding forward,uK > including an announcement of the OS ports to IA64 (which are quite cheap,sI > compared to other activities) while maintaining Alpha development. From L > this point follows a prediction that can be verified on the basis of, say,I > the 1CQ2002 results of the company. Are you willing to bet with Bill onb, > specific numbers, and be held to that bet?  C I fully expect Compaq is going to take a noticeable hit for several J quarters.  No surprise there.  They made this decision thinking 5-10 years out...   ------------------------------    Date: 31 Aug 2001 17:55:51 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>,2 Subject: Re: Conference: CETS-2001 Detailed UpdateH Message-ID: <y4heuoz0jc.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ( "Jeff Killeen" <Jeff@IDM-IO.com> writes:  E > I fully expect Compaq is going to take a noticeable hit for severaleL > quarters.  No surprise there.  They made this decision thinking 5-10 years > out...  L Alternate routes with much less impact on customers and a much more positiveJ PR effect have been proposed if they were indeed addressing such long-termF issues - indeed I mentioned it in the post you are replying to. If theF "noticeable hit" is more than $50-75M per quarter, the alternate routeG would have been better. So there's a measure of performance you can pute to this decision.n   	Jan   ------------------------------    Date: 31 Aug 2001 17:53:38 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>q2 Subject: Re: Conference: CETS-2001 Detailed UpdateH Message-ID: <y4k7zkz0n1.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ( "Jeff Killeen" <Jeff@IDM-IO.com> writes:  K > Dave Fenwick - Project leader for the Wildfire - Each special developmentc+ > batch of ASIC cost about $1 million each.u  J It just might fit if they're turning around 10 or more ASICs. On the otherM hand, I have no reason to believe they would need multiple turns for each and> every chip in the design.i  E > This is very indicative of the pure speculation is going on here...   M Blech. Do you think an iteration of an ASIC 2-4 years back in the US cost teneI times more than a turn of a state-of-the-art custom design in Germany twoe years back?g   	Jan   ------------------------------  # Date: Fri, 31 Aug 2001 17:18:24 GMTt4 From: "Terry C. Shannon" <terryshannon@mediaone.net>2 Subject: Re: Conference: CETS-2001 Detailed Update< Message-ID: <AFPj7.1585$%e5.4250482@typhoon.ne.mediaone.net>  L "Jan Vorbrueggen" <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote inJ message news:y4g0a8mkko.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de...* > "Jeff Killeen" <Jeff@IDM-IO.com> writes: >tK > > You have repeatedly claimed Compaq "lied".  At the time that letter wasaJ > > posted it was truthful.  Jesse retired from Compaq in October 2000 and BillL > > retired in January 2001.  Neither party was involved in the decision.  I seenC > > nothing in this that proves Compaq engaged in telling customersn informationw > > it knew to be false.  D Yep. The usual USENET Horseshit. But what elsw would you expect from here????   > >pK > > The fact is was posted after June 25th does not mean someone knew the 2h yearJ > > old letter was there and intentionally left it posted.  Who knows if II > > search Compaq's web site I might find an old page talking about theiro > > commitment to the PDP-11.t > D > Irrelevant. The letter in question was linked to at a high-profile	 position,dI > and was pointed to as _the_ evidence for Compaq's committment after thee? > original authors retired from Compaq, right up to the 25 Junet
 announcement.f@ > It was, for instance, frequently referenced to this purpose in
 presentations I > on various subjects from the VMS team, up to and including Marcello. Ifd thatL > isn't "lying", I will never have to read anything published by any companyL > again, because there is no way I could rely on any of its contents for any
 > purpose. >oH > > You will have to point me to where one of these Alpha architect said this -; > > forgive if I don't have blind faith in your statements.a >n9 > Brannon Batson said so here, or in comp.arch (or both).i > J > > [...] from day one I heard it as Compaq would have trouble maintaining itst4 > > performance edge over IPF three generations out. >tH > So Compaq stops competing now, because their performance edge _may_ beE > eroding three generations out - i.e., at least five years from now?c >mG > > My understanding of what drove the decision was more than pure chipe speed. >tH > That's not what was said or implied in publich statements, and in fact from a< > technical point of view, is even more unlikely. See below. >lG > > I was told upfront that it was at the system performance level that  becameH > > the issue.  Remember Alpha's performance advantage was both its chip speedwL > > and the fact that it was 64 bit.  What the team saw who was building theK > > follow-on to the Wildfire was the IPF systems would close in on Alpha's F > > systems in the future - it was never ever expressed to me as Alpha systemse$ > > would have trouble "keeping up". >eH > From a systems' point of view this is complete nonsense. The EV7, thenI > recently completed, has features that make building large-scale systemsrJ > much easier than with any other processor on the market or the roadmaps.J > Thus, building large IPF systems will take much more effort in designingJ > and building the systems interconnect than building large Alpha (EV7 andH > follow-on) systems. There is nothing disclosed about IPF or any futureE > implementation of the IA64 architecture that makes it even remotely 	 plausiblen > this claim could be true.t >p> > >     "This is a very bold move for us," said Rich Marcello,7 > >     vice president and general manager for Compaq'sT4 > >     performance systems group. He noted that the7 > >     Alpha road map extended for several more years,y: > >     but that starting around 2004, when the chip would; > >     have competed head-to-head against Intel's Itanium,oE > >     its performance advantage would begin to erode significantly. < > >     "When we looked at our road map and overlaid it with; > >     Intel's road map, we found there was no substantialo@ > >     performance benefit," he said. "Basically, we are sayingC > >     that we couldn't differentiate ourselves at the CPU level."u >oJ > See above. To render such statements believable would require a detailedF > disclosure of in-depth technical information and analysis; all other evidenceH > pointing to the contrary, one has to assume this is post-hoc drivel to make. > bad management decisions publicly plausible. >nK > > For example each time Compaq needed to burn a new set of ASIC's for thenJ > > Wildfire during development the cost was about one million dollars per batchn >pH > 'scuse me? One iteration of a custom processor in 0.18 um at a certain well-rL > known German semiconductor company was about DM 150-200k, according to theG > person out of whose account that money was coming. You are talking 10u times 
 > as much. >h- > > It is not just the chip - it is the total,F > > cost of maintaining the server development effort unique to Alpha. >sC > And Compaq has publicly said that everything but the Alpha _chip_y development.G > is continuing, e.g., Marvel et al., because future servers, both with  Alphap9 > and IPF processors, will be based on a common platform.  >tD > > Did Winkler say "Alpha's annual development costs" or did he say "Alpha'sG > > annual _chip_ development costs".  There is a big difference there.f Please0 > > point me to the source of the Winkler quote. > F > IIRC, the source is an analysts conference early this year (March orF > thereabouts), and the $300M was total development costs. Estimate anD > engineer on a design team to cost about $300k per year. That meansJ > Winkler's figure is 1000 engineers in total. I don't think a chip designF > team runs to 500 engineers each, and still produce good results (cf. > the Itanium design). >oI > But Bill's central point is that, even taking Winkler's figures at facei value,K > the decision as conveyed on 25 June in all likelihood does more damage touK > Compaq's bottom line than would have any other way of proceeding forward, K > including an announcement of the OS ports to IA64 (which are quite cheap, I > compared to other activities) while maintaining Alpha development. From L > this point follows a prediction that can be verified on the basis of, say,I > the 1CQ2002 results of the company. Are you willing to bet with Bill onw, > specific numbers, and be held to that bet? >d > > > Clear enough for you now?- >- > Jane   ------------------------------  # Date: Fri, 31 Aug 2001 17:24:35 GMTf4 From: "Terry C. Shannon" <terryshannon@mediaone.net>2 Subject: Re: Conference: CETS-2001 Detailed Update< Message-ID: <nLPj7.1587$%e5.4252766@typhoon.ne.mediaone.net>  K Ahgaoin. the usual Usenet Horseshit. Wan t the facts, buy my newsletter. Or $ continue to suck up this codswallop!? "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messageB6 news:AFPj7.1585$%e5.4250482@typhoon.ne.mediaone.net... >dK > "Jan Vorbrueggen" <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrotel inL > message news:y4g0a8mkko.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de..., > > "Jeff Killeen" <Jeff@IDM-IO.com> writes: > >rI > > > You have repeatedly claimed Compaq "lied".  At the time that letter  wasrL > > > posted it was truthful.  Jesse retired from Compaq in October 2000 and > BillK > > > retired in January 2001.  Neither party was involved in the decision.i Ip > see,E > > > nothing in this that proves Compaq engaged in telling customersh
 > informationt > > > it knew to be false. > F > Yep. The usual USENET Horseshit. But what elsw would you expect from
 > here???? >u > > >nK > > > The fact is was posted after June 25th does not mean someone knew ther 2l > yearL > > > old letter was there and intentionally left it posted.  Who knows if IK > > > search Compaq's web site I might find an old page talking about their  > > > commitment to the PDP-11.p > >mF > > Irrelevant. The letter in question was linked to at a high-profile > position, K > > and was pointed to as _the_ evidence for Compaq's committment after the(A > > original authors retired from Compaq, right up to the 25 Junet > announcement.gB > > It was, for instance, frequently referenced to this purpose in > presentationsnK > > on various subjects from the VMS team, up to and including Marcello. If  > thatF > > isn't "lying", I will never have to read anything published by any companyaJ > > again, because there is no way I could rely on any of its contents for anya > > purpose. > >tJ > > > You will have to point me to where one of these Alpha architect said > this -= > > > forgive if I don't have blind faith in your statements.  > > ; > > Brannon Batson said so here, or in comp.arch (or both).h > >eL > > > [...] from day one I heard it as Compaq would have trouble maintaining > itsl6 > > > performance edge over IPF three generations out. > >lJ > > So Compaq stops competing now, because their performance edge _may_ beG > > eroding three generations out - i.e., at least five years from now?v > >hI > > > My understanding of what drove the decision was more than pure chipa > speed. > > J > > That's not what was said or implied in publich statements, and in fact > from a> > > technical point of view, is even more unlikely. See below. > > I > > > I was told upfront that it was at the system performance level thath > becameJ > > > the issue.  Remember Alpha's performance advantage was both its chip > speediJ > > > and the fact that it was 64 bit.  What the team saw who was building theuE > > > follow-on to the Wildfire was the IPF systems would close in one Alpha's H > > > systems in the future - it was never ever expressed to me as Alpha	 > systemsH& > > > would have trouble "keeping up". > >eJ > > From a systems' point of view this is complete nonsense. The EV7, thenK > > recently completed, has features that make building large-scale systemstL > > much easier than with any other processor on the market or the roadmaps.L > > Thus, building large IPF systems will take much more effort in designingL > > and building the systems interconnect than building large Alpha (EV7 andJ > > follow-on) systems. There is nothing disclosed about IPF or any futureG > > implementation of the IA64 architecture that makes it even remotelya > plausibleu > > this claim could be true.a > >a@ > > >     "This is a very bold move for us," said Rich Marcello,9 > > >     vice president and general manager for Compaq'st6 > > >     performance systems group. He noted that the9 > > >     Alpha road map extended for several more years,d< > > >     but that starting around 2004, when the chip would= > > >     have competed head-to-head against Intel's Itanium, G > > >     its performance advantage would begin to erode significantly.D> > > >     "When we looked at our road map and overlaid it with= > > >     Intel's road map, we found there was no substantialiB > > >     performance benefit," he said. "Basically, we are sayingE > > >     that we couldn't differentiate ourselves at the CPU level."d > > L > > See above. To render such statements believable would require a detailedH > > disclosure of in-depth technical information and analysis; all other
 > evidenceJ > > pointing to the contrary, one has to assume this is post-hoc drivel to > make0 > > bad management decisions publicly plausible. > >eI > > > For example each time Compaq needed to burn a new set of ASIC's fore thetL > > > Wildfire during development the cost was about one million dollars per > batch) > > J > > 'scuse me? One iteration of a custom processor in 0.18 um at a certain > well- J > > known German semiconductor company was about DM 150-200k, according to theII > > person out of whose account that money was coming. You are talking 10u > timese > > as much. > >n/ > > > It is not just the chip - it is the total H > > > cost of maintaining the server development effort unique to Alpha. > >nE > > And Compaq has publicly said that everything but the Alpha _chip_l
 > developmentrI > > is continuing, e.g., Marvel et al., because future servers, both withI > Alphah; > > and IPF processors, will be based on a common platform.a > > F > > > Did Winkler say "Alpha's annual development costs" or did he say
 > "Alpha'sI > > > annual _chip_ development costs".  There is a big difference there.t > Please2 > > > point me to the source of the Winkler quote. > > H > > IIRC, the source is an analysts conference early this year (March orH > > thereabouts), and the $300M was total development costs. Estimate anF > > engineer on a design team to cost about $300k per year. That meansL > > Winkler's figure is 1000 engineers in total. I don't think a chip designH > > team runs to 500 engineers each, and still produce good results (cf. > > the Itanium design). > >oK > > But Bill's central point is that, even taking Winkler's figures at face' > value,J > > the decision as conveyed on 25 June in all likelihood does more damage toD > > Compaq's bottom line than would have any other way of proceeding forward,F > > including an announcement of the OS ports to IA64 (which are quite cheap,K > > compared to other activities) while maintaining Alpha development. FromgI > > this point follows a prediction that can be verified on the basis of,- say,K > > the 1CQ2002 results of the company. Are you willing to bet with Bill one. > > specific numbers, and be held to that bet? > >e! > > > > Clear enough for you now?- > >  > > Jan, >  >    ------------------------------  # Date: Fri, 31 Aug 2001 07:46:28 GMTC4 From: "Terry C. Shannon" <terryshannon@mediaone.net>! Subject: Re: EV7 will never ship?.< Message-ID: <ohHj7.1520$%e5.4073009@typhoon.ne.mediaone.net>  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message- news:hZuj7.1012$bB1.45495@news.cpqcorp.net...c! > Are we haveing a bad day Terry?i >eI > It's a nice day to golf.  Hop in the car and head to Overlook (althoughl theyE > have problems with their greens) or maybe up past me to Amherst CC.h  L No, we're having a great day with CPQ at $12.65. And a great marketing team, too!   >aB > Or maybe just head over to Silver Lake (make sure your shots are
 up-to-date > ;-). >  >  >s' > Terry C. Shannon wrote in message ...e > >dC > >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message 0 > >news:Scuj7.1003$bB1.45307@news.cpqcorp.net...B > >> JF Mezei wrote in message <3B8D263B.CEA96993@videotron.ca>... > >> >Alan Greig wrote:aB > >> >> have Galaxy support features according to current customer > >presentations.  > >> The slides-B > >> >> show one system running Windows-64, VMS, Linux, and Tru64. > >> >G > >> >I was under the impression that currently, Galaxy only *supports*: > >multiplet > >> >instances of VMS.  > >uI > >What folks fail to understand is that comp.os.vms is a Romper Room fore > >whiners!> > >e > >  > >u >  >e   ------------------------------    Date: 31 Aug 2001 10:32:17 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>.! Subject: Re: EV7 will never ship? H Message-ID: <y4bskwd3zi.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  / JF Mezei <jfmezei.spamnot@videotron.ca> writes:u  J > The minute the charging of higher insurance for users of Windows becomesK > important enough, you can bet that Microsoft will sue the hilt out of the L > insurance companies and prove that its OS is secure when well managed and L > when the system managers check the microsoft web site at regular intervals2 > for available patches. (interval = each hour :-)  H They can't do that. Or do you think Ford could sue a used-car vendor forK lowering prices on those Ford SUVs with the tire problem because they have,f3 in the eyes of the buying public, a safety problem?k  M > However, it is also possible that Microsoft will simply pay those insuranceoL > companies under the table to stop such a practice since going public wouldN > only attract the attention to the fact that NT isn't high enough quality yetO > and that customers should not install Nt in true enterprise applications evenv) > though MS and Compaq would want you to..  @ They can't do that either - the FTC would strangle both of them.   	Jan   ------------------------------    Date: 31 Aug 2001 10:53:47 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> ! Subject: Re: EV7 will never ship?tH Message-ID: <y48zg0d2zo.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>    Dirk Munk <munk@home.nl> writes:  N > > I don't agree that the HW is a problem.  You might not like the robustnessN > > of Windows, but it is seldom a hardware problem.  It is a software problem> > > compounded by unreliable third party software and drivers.N > I'm afraid I can't agree with you on this point. Hardware can most certainlyL > be a problem. Look at Intels track record of processors with problems and  > chipsets with problems.0  L Intel doesn't seem to have any more (or less) problems than other players inG the industry. They _do_ get more publicity, and they have made some, in O restrospect, wrong decisions publicity-wise with regard to recalling processorss with severe bugs.w  F With regard to IDE, SCSI, USB etc devices - you get what you pay for.    	Jan   ------------------------------  % Date: Fri, 31 Aug 2001 08:08:05 -0700n# From: "Tom Linden" <tom@kednos.com>f! Subject: FW: Alpha Parts For Salem9 Message-ID: <CIEJLCMNHNNDLLOOGNJIGEICDDAA.tom@kednos.com>t  ; Saw this and thought somebody might find it useful.  I known nothing about them.i   -----Original Message-----D From: axp-list-admin@redhat.com [mailto:axp-list-admin@redhat.com]On) Behalf Of charles@triadcommunications.com % Sent: Friday, August 31, 2001 7:56 AM  To: axp-list@redhat.comr Subject: Alpha Parts For Saler    > We have Alpha chips and RAM for sale since we are going out of) business.  If interested please e-mail at,& charles.meyer@wetcementproductions.com      / _______________________________________________I Axp-list mailing listt Axp-list@redhat.com 4 https://listman.redhat.com/mailman/listinfo/axp-list   ------------------------------    Date: 31 Aug 2001 08:43:33 -0500( From: jkclausen@yahoo.com (John Clausen). Subject: Help with backup needed, in a bind..., Message-ID: <3b8f9485_3@corp.newsgroups.com>  I I know this is a easy one, but I am in a bind and can't seem to find the   information on the net....  M I have a MicroVAX I running MicroVMS 5.5 ro 4.4 (Can't remember) anyhow, the n hard drive is failing...  2 I have to bump the hard drive to get it spinning.. It also has a TK50...t  G How do I create a bootable TK50 tape that I can restore the drive from?d  F I don't want to turn this thing on again until I can make this backup.   Thanks in advance for the help,    John Clausen      > -----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----A http://www.newsfeeds.com - The #1 Newsgroup Service in the World!b> -----==  Over 80,000 Newsgroups - 16 Different Servers! =-----   ------------------------------  % Date: Fri, 31 Aug 2001 10:15:55 -0400P2 From: rdeininger@mindspring.com (Robert Deininger)2 Subject: Re: Help with backup needed, in a bind...L Message-ID: <rdeininger-3108011015560001@user-2ivec4v.dialup.mindspring.com>  F In article <3b8f9485_3@corp.newsgroups.com>, jkclausen@yahoo.com (John Clausen) wrote:a  K > I know this is a easy one, but I am in a bind and can't seem to find the o > information on the net.... > O > I have a MicroVAX I running MicroVMS 5.5 ro 4.4 (Can't remember) anyhow, the   > hard drive is failing... > 4 > I have to bump the hard drive to get it spinning.. > It also has a TK50...s > I > How do I create a bootable TK50 tape that I can restore the drive from?m   Use SYS$UPDATE:STABACKIT.COM.n  I This procedure makes a bootable standalone backup on a disk or tape.  You"A can put standalone backup on a TK50, then boot the TK50, then user: standalone backup to back up the disk to a different TK50.   Booting a TK50 takes a while.n  I You can also put standalone backup on an alternate root on a system disk, I and boot from there.  But I would not recommend writing to a disk that is / failing, so TK50 is probably best in this case.o   -- i Robert Deininger rdeininger@mindspring.coma   ------------------------------    Date: 31 Aug 2001 09:21:46 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>  Subject: Re: I hate CompaqH Message-ID: <y4n14gd791.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  1 mccalpin@gmp246.austin.ibm.com (McCalpin) writes:a  D > I can only hope that this stupidity (DMCA) is overturned soon, andD > that the law would place its focus on violations of copyright law,@ > rather than on mechanisms that could conceivably enable one to0 > violate copyright law if one were so inclined.  N DMCA wants, among other things, to mandate by fiat copy protection for digitalI data in an unsecure environement - something that, IMNSHO, is on the same 0 level as mandating propulsion faster than light.   	Jan   ------------------------------    Date: 31 Aug 2001 09:23:51 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>u Subject: Re: I hate CompaqH Message-ID: <y4k7zkd75k.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  * nmm1@cus.cam.ac.uk (Nick Maclaren) writes:  ? > But I agree that it is a less likely scenario than a completepB > meltdown of the Alpha line (i.e. an inability to get the EV7 out9 > and working in a realistic timescale, with no fallback)b  K I've heard from multiple sources that there are working EV7 processors thatmL have booted all of Compaq's OSes some time ago, so the above inability wouldH have to apply to systems, not the processor. Of course, given WIldfire's' history, that isn't totally impossible.    	Jan   ------------------------------  % Date: Fri, 31 Aug 2001 18:42:50 +0010 % From: paddy.o'brien@zzz.tg.nsw.gov.au  Subject: Re: I hate Compaq5 Message-ID: <01K7SLA5N8IQ004L6A@tgmail.tg.nsw.gov.au>u   Jan Vorbrueggen wrote:  2 >mccalpin@gmp246.austin.ibm.com (McCalpin) writes: >nE >> I can only hope that this stupidity (DMCA) is overturned soon, and E >> that the law would place its focus on violations of copyright law,tA >> rather than on mechanisms that could conceivably enable one toh1 >> violate copyright law if one were so inclined.a >oH >DMCA wants, among other things, to mandate by fiat copy protection for  digitalOJ >data in an unsecure environement - something that, IMNSHO, is on the same1 >level as mandating propulsion faster than light.i  . Read comp.risks 17/08/2001 Risks Digest 21.61.   Regards, Paddy   ------------------------------   Date: 31 Aug 2001 10:34:18 GMT7 From: woodacre@scala.reading.sgi.com (Michael Woodacre)  Subject: Re: I hate Compaq. Message-ID: <9mnp7a$fk38f$1@fido.engr.sgi.com>   In article <y4k7zkd75k.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>, Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:- |> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:m |> nB |> > But I agree that it is a less likely scenario than a completeE |> > meltdown of the Alpha line (i.e. an inability to get the EV7 outn< |> > and working in a realistic timescale, with no fallback) |> $N |> I've heard from multiple sources that there are working EV7 processors thatO |> have booted all of Compaq's OSes some time ago, so the above inability wouldoK |> have to apply to systems, not the processor. Of course, given WIldfire's>* |> history, that isn't totally impossible. |>     Booting an OS != stable system  H It's obviously a big achievement to boot an OS on a processor but anyoneN who has been through processor and system bringup knows it takes a lot of work. to get a system/processor combination stable.   N As an example, when we got the first silicon for the R4400, the IC process wasN still a bit flakey and so the caches had problems. We still got the OS to bootD after some furious hacking from the OS guys to make it run uncached.  N With the level of integration of EV7 (memory control and cache coherence logicO on chip etc), I'd expect to see at least a few tweaks to the silicon before it  P would run stressful multiprocessor applications cleanly. Making it to market in R less than a year from first silicon would indeed be a great acheivement, but givenN the god-like heroes who work on alpha, I'm sure it will happen, but the CompaqQ marketting folks will step in and hold back shipments just to raise Bill's blood o pressure   Cheers,s Mike     |> 	Janq   -- r    Michael S. Woodacre   woodacre@sgi.com     Phone: +44 118 925 7846r   ------------------------------    Date: 31 Aug 2001 13:04:13 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>  Subject: Re: I hate CompaqH Message-ID: <y48zg05w42.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ' paddy.o'brien@zzz.tg.nsw.gov.au writes:o  0 > Read comp.risks 17/08/2001 Risks Digest 21.61.  J Of course I have. I thought comp.risks were required reading for every one in the field!?   	Jan   ------------------------------   Date: 31 Aug 2001 12:15:34 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: I hate Compaq0 Message-ID: <9mnv56$8lv$1@pegasus.csx.cam.ac.uk>  H In article <y4k7zkd75k.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>,I Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:d- |> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:t |> uB |> > But I agree that it is a less likely scenario than a completeE |> > meltdown of the Alpha line (i.e. an inability to get the EV7 out,< |> > and working in a realistic timescale, with no fallback) |> tN |> I've heard from multiple sources that there are working EV7 processors thatO |> have booted all of Compaq's OSes some time ago, so the above inability wouldaK |> have to apply to systems, not the processor. Of course, given WIldfire'sw* |> history, that isn't totally impossible.  = Yes, indeed, and it was those aspects that I was thinking of.v  ? It isn't just Compaq's record, but that of every single companyb@ that has ever got into serious levels of SMP and non-predictable> instruction execution - getting the interrupt handling, memory> management and related areas to work correctly and efficiently< is FAR harder than even the most realistic manager will have< scheduled for.  And what is apparently a simple or unrelated7 change may have immense and unpredictable consequences.   : Even now, IRIX 6.5 on the Origin 2000 has a fair number of? obscure problems that occasionally bite, and that is by far andi= away the most mature SMP system around.  Rumours are that Sunu' and Compaq are still a long way behind.   @ Also, do you remember how often Intel has had to de-announce SMP= support for its chips at a very late stage?  And stating that > the limit is 2 processors is a form of this, as the numbers go0 1, 2, many as far as SMP problems are concerned.  ; I hope that Compaq DOES pull off the EV7, as even temporary > competition is always good, and think that it is probably more> likely than not.  But it is by no means a foregone conclusion.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679    ------------------------------    Date: 31 Aug 2001 13:45:45 +0100( From: womack@ox.compsoc.net (Tom Womack) Subject: Re: I hate Compaq0 Message-ID: <9mo0tp$l4f$1@spiffy.ox.compsoc.net>  / In article <3B8A3F12.2030801@brussels.sgi.com>,n, Alexis Cousein  <al@brussels.sgi.com> wrote: >Alan Greig wrote:G >> On 24 Aug 2001 10:56:02 -0500, young_r@encompasserve.org (Rob Young)o	 >> wrote:a >> m >> pC >>>	True.  With an option... an option that apparently escaped yourn >>>	attention: >>>tG >>>"The DOE also has options to upgrade to future generations of Alpha eA >>> processors (EV7 and EV8) which would result in a 100 TeraOPS   >>> configuration by 2004."m >yC >For the benefit of the readers that are saying that nobody "knows"c/ >anything about this, the 30 TeraOPs RFP is at:  >i% >http://www.acl.lanl.gov/30TeraOpRFP/o  E Isn't the interesting feature of that RFP that it requires either thed@ 30Tflop machine to be in place by 30 June this year, or a 10- toD 13-Tflop machine to be in place by the end of last year and a 35- to  40-Tflop one by April 30th 2002?  F Does anyone know what's arrived at LANL so far? The requirement is forC loads of 16+-way SMPs; I suppose it's an installment of big GS320s.s  E [the proposal also gives a useful summary of the DoD requirements for @ disposal of classified-data-holding media, but that's by the by]  E >You'll see that it's much more than just a MFLOPS race...and while IoH >do agree that LANL would be just as satisfied with fast little gremlinsA >as processors, there's enough in that tender to make one believee3 >more than the current *platforms* would be needed t  G Indeed -- end-to-end MPI latency of 15us between any two systems soundsi= a quite impressively low requirement, though I don't see thate  B "an SMP aggregate bandwidth of no less that 0.05 bytes/second/peak OP/second/SMP"  C requires EV7 -- for a 32-processor dual-FPU gigahertz system that'sa "only" 3.2GB per second.  ( Interesting document to read, certainly.   Tomt   ------------------------------  % Date: Fri, 31 Aug 2001 09:04:37 -0400n5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>i Subject: Re: I hate Compaq3 Message-ID: <TXLj7.1042$bB1.45773@news.cpqcorp.net>.  F Nick Maclaren wrote in message <9mnv56$8lv$1@pegasus.csx.cam.ac.uk>... >   @ >It isn't just Compaq's record, but that of every single companyA >that has ever got into serious levels of SMP and non-predictable?? >instruction execution - getting the interrupt handling, memory ? >management and related areas to work correctly and efficiently6= >is FAR harder than even the most realistic manager will have = >scheduled for.  And what is apparently a simple or unrelated.8 >change may have immense and unpredictable consequences. >o    I The good news is that IMHO the 3 best people in the world at what they donD are in charge of the EV7, the system platform, and the IO subsystem.   ------------------------------  % Date: Fri, 31 Aug 2001 16:57:51 -0000 - From: wspencer@ap.nospam.org (Warren Spencer)s7 Subject: Intel announces IA-64 "HyperThreading" in 2002.7 Message-ID: <910E8AA4Ewarrenspencer1977@207.126.101.97>    Hi,e  L On TechTV last night, I caught the tail end of a report that said Intel has J announced their "HyperThreading" technology, to be delivered in 2002.  It J seemed remarkably similar to SMT.  An Intel rep also said something along J the lines of <we'll have to change the way we write software, but it will 
 be worth it>.G  L I took this to mean that the existing instruction set for IA-64, or perhaps ? it's architecture, will need to change to support this feature.u  C It's my opinion that this announcement is  essentially Alpha's SMT  F resurfacing as an Intel technology.  Anyone else see this, or have an  alternate interpretation?    ws   -- a   Warren Spencer' Senior Software Engineer (not a writer)  The Associated Press  L ** My employer does not necessarily agree with my statements - neither do I  **   ------------------------------  % Date: Fri, 31 Aug 2001 10:29:12 -0700.% From: Dean Woodward <deanw@rdrop.com>e; Subject: Re: Intel announces IA-64 "HyperThreading" in 2002o) Message-ID: <3B8FC968.12B52E98@rdrop.com>t   Warren Spencer wrote:  > M > On TechTV last night, I caught the tail end of a report that said Intel hasnK > announced their "HyperThreading" technology, to be delivered in 2002.  ItoK > seemed remarkably similar to SMT.  An Intel rep also said something alongsK > the lines of <we'll have to change the way we write software, but it willl > be worth it>.v > M > I took this to mean that the existing instruction set for IA-64, or perhaps A > it's architecture, will need to change to support this feature.m  = Hyperthreading, as implemented, exists in the Pentium 4 line.p; It's a weak second to SMT.  With HT, as I understood it, ifl> a processor happens to have a floating point op and an integer< op on hand at the same time, it can run both of 'em at once,; instead of sequentially.  That's the limit to the HT magic. * It can't do two FP or integer ops at once.  1 http://news.cnet.com/news/0-1003-200-6991462.html    ------------------------------  % Date: Fri, 31 Aug 2001 10:41:17 -0700a# From: "Tom Linden" <tom@kednos.com>-; Subject: RE: Intel announces IA-64 "HyperThreading" in 2002r9 Message-ID: <CIEJLCMNHNNDLLOOGNJIKEIHDDAA.tom@kednos.com>b  C Just to put things in an historical perspective the CDC 6000 series.= designed by Seymour Cray around 1965 also had this capabilitym   > -----Original Message-----. > From: Dean Woodward [mailto:deanw@rdrop.com]( > Sent: Friday, August 31, 2001 10:29 AM > To: Info-VAX@Mvb.Saic.Comb= > Subject: Re: Intel announces IA-64 "HyperThreading" in 2002i >  >  > Warren Spencer wrote:  > > A > > On TechTV last night, I caught the tail end of a report that n > said Intel hasD > > announced their "HyperThreading" technology, to be delivered in  > 2002.  Itb> > > seemed remarkably similar to SMT.  An Intel rep also said  > something along B > > the lines of <we'll have to change the way we write software, 
 > but it willo > > be worth it>.o > > > > > I took this to mean that the existing instruction set for  > IA-64, or perhapsoC > > it's architecture, will need to change to support this feature.- > ? > Hyperthreading, as implemented, exists in the Pentium 4 line.n= > It's a weak second to SMT.  With HT, as I understood it, ifs@ > a processor happens to have a floating point op and an integer> > op on hand at the same time, it can run both of 'em at once,= > instead of sequentially.  That's the limit to the HT magic. , > It can't do two FP or integer ops at once. > 3 > http://news.cnet.com/news/0-1003-200-6991462.htmlo >    ------------------------------    Date: 30 Aug 2001 23:54:13 -0700. From: mistdragon@zdnetonebox.com (mist dragon)H Subject: Intel has released Hyper-threading for it's next gen processors< Message-ID: <7500353b.0108302254.4a90a86@posting.google.com>   Look at   = http://www.zdnet.com/zdnn/stories/news/0,4586,2809007,00.htmlx  C While not exactly the same as SMT planned for future gens of Alpha,t still quite close isn't it ?   ------------------------------  % Date: Fri, 31 Aug 2001 09:54:39 +0100l( From: Nic Clews <sendspamhere@127.0.0.1>L Subject: Re: Intel has released Hyper-threading for it's next gen processors) Message-ID: <3B8F50CF.E5EE41A0@127.0.0.1>m   mist dragon wrote: > 	 > Look att > ? > http://www.zdnet.com/zdnn/stories/news/0,4586,2809007,00.htmle > E > While not exactly the same as SMT planned for future gens of Alpha,  > still quite close isn't it ?   Now thats a surprise isn't it.  H It is a pity that Paul DeMone is not going to be writing more because as@ technical details emerge I'd be interested to read his analysis.   --  ( Regards, Nic Clews CSC Computer Sciences nclews at csc dot com.   ------------------------------  % Date: Fri, 31 Aug 2001 14:07:35 +0200r From: Dirk Munk <munk@home.nl>N Subject: Re: Is there a VMS command to check if I have cache memory installed?' Message-ID: <3B8F7E06.B004D56F@home.nl>:   David Spencer wrote:  I > I have a PWS 600au running VMS 7.2-1. I've recently become aware of thedI > fact that I might be able to get better performance if I installed somepE > cache memory. The problem is, I'm not sure if I _already_ have somes > cache in there.  >uH > The machine is in production at a remote location. I'm reluctant to goF > there, shut it down and open the box just to check for it if there's@ > some DCL command or somesuch that I could enter to just let me > know.e > D > Is there indeed any VMS command to display the status of any cache	 > memory?a > 	 > Thanks,  >  > -- Dave Spencero  I Not that I know of. But AFAIK you can not run VMS on a PWS if there is noKF cache memory installed. However you still have to find out how much is0 installed, because there were 2 sizes available.   ------------------------------  % Date: Fri, 31 Aug 2001 08:25:54 -0400a2 From: rdeininger@mindspring.com (Robert Deininger)N Subject: Re: Is there a VMS command to check if I have cache memory installed?L Message-ID: <rdeininger-3108010825540001@user-2ivec4v.dialup.mindspring.com>  G In article <3B8F7E06.B004D56F@home.nl>, Dirk Munk <munk@home.nl> wrote:i    K > Not that I know of. But AFAIK you can not run VMS on a PWS if there is no2H > cache memory installed. However you still have to find out how much is2 > installed, because there were 2 sizes available.  I Well, you could buy them, with VMS, with no cache.  There's no reason VMS4J wouldn't run, that I can think of.  It would be slower than cold molasses, but it would run.n   -- , Robert Deininger rdeininger@mindspring.com    ------------------------------    Date: 31 Aug 2001 08:56:25 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)fN Subject: Re: Is there a VMS command to check if I have cache memory installed?, Message-ID: <Yxk7mm2v8qNI@malvm5.mala.bc.ca>  ( In article <3B8F7E06.B004D56F@home.nl>, #    Dirk Munk <munk@home.nl> writes:s > K > Not that I know of. But AFAIK you can not run VMS on a PWS if there is no2 > cache memory installed.a  F      I've done so with no problems ( other than it being a bit slow ).   ------------------------------  % Date: Fri, 31 Aug 2001 10:26:50 +0100h8 From: John Macallister <J.Macallister1@physics.ox.ac.uk> Subject: RE: Mark Twain PromosN Message-ID: <35666012DF4CD411BE940090279FA240010BF01D@ppnt41.physics.ox.ac.uk>  E I enjoyed the book but this mailshot was clearly targeted at existinghJ customers to reassure them that VMS is alive and well. When I first openedI the package my initial reaction was that the contents were binder insertsaG for a new manual set of some sort and that there must be another largerrJ package of manuals awaiting collection in stores. When I actually read theJ "binder inserts" and then dicovered the Mark Twain book I realised that it was another "junk" mailshot. a  F I guess you could use the "binder inserts" as bookmarks for continuing reassurance...   John  B Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.ukH Post: Nuclear and Astrophysics Laboratory, Keble Road, Oxford OX1 3RH,UKA Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax)l   ------------------------------    Date: 31 Aug 2001 07:57:47 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)l Subject: RE: Mark Twain Promoo3 Message-ID: <HXq95AHUP4CD@eisner.encompasserve.org>    In article <35666012DF4CD411BE940090279FA240010BF01D@ppnt41.physics.ox.ac.uk>, John Macallister <J.Macallister1@physics.ox.ac.uk> writes:eG > I enjoyed the book but this mailshot was clearly targeted at existing-8 > customers to reassure them that VMS is alive and well.  H From reading this newsgroup, it is clear that is where the problem lies.   ------------------------------  % Date: Fri, 31 Aug 2001 12:29:31 +010070 From: andrew harrison <andrew.nospam@uk.sun.com>( Subject: Re: More Alpha rubbish in print* Message-ID: <3B8F751B.9E68CC91@uk.sun.com>   Arne Vajh=F8j wrote: > =r   > andrew harrison wrote:= > > According to the latest windows survey StarOffice now has>9 > > 15% of the Office market ahead of Corel and Lotus butV > > behind MS Office.g > =    > URL please ? > =t    - It was a poll done by Windows 2000 magazine =o    H http://www.win2000mag.com/Poll/Index.cfm?QID=3D198&Action=3DPreviousPoll  C Obviously it is only based on their magazine/web readers responses.t   regardsn Andrew Harrison  Enterprise IT Architect'   ------------------------------    Date: 31 Aug 2001 07:45:24 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)e( Subject: Re: My VMS Wish List (features)3 Message-ID: <kiA2D+XdGZPB@eisner.encompasserve.org>   [ In article <3B8EFAF3.5EB5C742@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:w > Larry Kilgallen wrote: >> r^ >> In article <3B8DAE36.15F3721E@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes: >> > Larry Kilgallen wrote:r >> >>c >> >> That is a good list. >> >>nG >> >> My only concern is with encouraging people to write things in DCLcG >> >> that would better be done in compiled languages.  Still there are J >> >> times when the steps that require dealing with any of the 6 floatingH >> >> point types are minimal and the Real goal is to run Sort.  In that8 >> >> case switching to a compiled language is overkill. >> >9 >> > Of course, the problems with compiled languages are:  >> > >> > o they're compiledn& >> > o unless you write Macro32, $$$$$ >> o >> Don't forget Bliss. >  > Hhmmm... Good point. >  > Supported?  9 No, but your criterion seemed to be "no additional cost". : Bliss is much better than macro in terms of avoiding bugs.H On the other hand, Ada is worlds better than both.  And it is supported.	 TANSTAAFLj   ------------------------------    Date: 31 Aug 2001 07:36:07 -00004 From: Doc.Cypher <Use-Author-Address-Header@[127.1]>B Subject: Re: Nits in Slides (was: Re: The Final Knell Has Sounded)6 Message-ID: <20010831073607.22992.qmail@nym.alias.net>  " -----BEGIN PGP SIGNED MESSAGE-----  K On Thu, 30 Aug 2001, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote:rC >andrew harrison wrote in message <3B8E1FDF.7B677D1A@uk.sun.com>...e  9 >>> >> Give us the readers digest version of your resume.< >>> >>B >>> >> I've shared mine here when *you* challenged my credentials.  . >>> >Actually yet again you have got it wrong. >>> >s- >>> >I havn't challenged your credentials yets- >>> >so I have yet to see your CV, which I amk >>> >sure is very impressive.>  M >>> I'm sure you'll find it in deja from the last time we had this go around.r* >>> And again you've avoided the question.   >>Why not produce the posting. >> >o >e9 >Can't find it offhand, but someone with the dersire can.d     TryoM http://groups.google.com/groups?selm=hFwh7.750%24bB1.32352%40news.cpqcorp.nety  2 That's more than we've seen about Andrew's career.     Doc. - -- t6 The bigger the humbug, the better people will like it.K ~ Phineas Taylor Barnum.                              http://vmsbox.cjb.neta   -----BEGIN PGP SIGNATURE-----h Version: 2.6.2  @ iQEVAwUBO47FcsriC3SGiziTAQGljQf/S4NIns42JDRtcGnrOlDLXTdSQblZQS8T@ KnHB906n5ZpR3+1Fn7bh1/UbwT43oR2wfWnw2xeKyhUh31brGAY1lKNgfpcOw1hH@ uH6DxxbkNQk4UZuFw0XvIHIZ81gEt4NHX30BZU4oCVDZ4XbIAbUeIjX+Yh2O5x+F@ /2e/rlYAA33LbxYXSGDaqSyTReld3jeyEMGY9y+PUCJg6ZMv8zNOfeW3FDWWKe6+@ X3C3HWCqLOz1QTnU3nnZ1/Ev5x1C0XIu+pLQhDrGGMV37vBpH0QQ8Z8cAC5CZp3X8 sCq0cxz78BZF3XJjT1V4TRTZspJErDB14xXrjAoSBwBh9plyCKE/Ng== =RtJe  -----END PGP SIGNATURE-----b   ------------------------------    Date: 31 Aug 2001 09:31:45 -0700% From: scada@cyberunlimited.org (Jeff)a Subject: OPCOM in VMS.< Message-ID: <39ac55d0.0108310831.204ce45@posting.google.com>  K I received the following message from OPCOM from VMS 7.1. Can anyone pleased explain it to me.   8 %%%%%%%%%%%  OPCOM  30-AUG-2001 18:29:31.45  %%%%%%%%%%%  ! Message from user SYSTEM on CVHQA   O Event: Unavailable User Buffer from: Node LOCAL:.CVHQA CSMA-CD Station SMACD-0,t-         at: 2001-08-30-19:29:31.253-04:00Iinfl  7         eventUid   F3FD5B47-9D74-11D5-A38C-435648514120c  7         entityUid  3C71E91F-7C55-11D5-8002-AA0004000000b  7         streamUid  45497161-7C55-11D5-8002-AA0004000000,  L My Alpha Systems loses response time and slows down, and these messages keep! filling up the Operator.log File.-  / If you have any ideas please Email me directly.+   Thanks,  Jeff - scada@cyberunlimited.org)   ------------------------------  % Date: Fri, 31 Aug 2001 12:39:46 -0400e- From: "John Eisenschmidt" <jeisensc@aaas.org>. Subject: Re: OPCOM in VMS.# Message-ID: <sb8f85b7.027@aaas.org>   C CSMA-CD is/has to do with Ethernet. What is your CHANNELCNT set at?bH We had a slightly similar problem almost three years ago, and a Compaq =J Engineer made us up our CHANNELCNT (which, I'm told, are used by UCX for =  dev sockets and memory buffers).  > >>> Jeff <scada@cyberunlimited.org> 08/31/2001 12:31:45 PM >>>F I received the following message from OPCOM from VMS 7.1. Can anyone = please explain it to me.   8 %%%%%%%%%%%  OPCOM  30-AUG-2001 18:29:31.45  %%%%%%%%%%%  ! Message from user SYSTEM on CVHQAg  H Event: Unavailable User Buffer from: Node LOCAL:.CVHQA CSMA-CD Station = SMACD-0,-         at: 2001-08-30-19:29:31.253-04:00Iinf   7         eventUid   F3FD5B47-9D74-11D5-A38C-435648514120t  7         entityUid  3C71E91F-7C55-11D5-8002-AA0004000000h  7         streamUid  45497161-7C55-11D5-8002-AA0004000000h  I My Alpha Systems loses response time and slows down, and these messages =  keep! filling up the Operator.log File.a  / If you have any ideas please Email me directly.s   Thanks,i Jeff - scada@cyberunlimited.org'   ------------------------------  # Date: Fri, 31 Aug 2001 07:49:55 GMT.4 From: "Terry C. Shannon" <terryshannon@mediaone.net>R Subject: Re: OpenVMS on Fault Tolerant IPF Hardware (was Re: EV7 will never ship?)< Message-ID: <DkHj7.1522$%e5.4073583@typhoon.ne.mediaone.net>  ? "Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in messageo- news:3Lwj7.1017$bB1.45514@news.cpqcorp.net...i? > In article <dba3451e.0108292000.15878a8a@posting.google.com>,f3 keithparris_nospam@yahoo.com (Keith Parris) writes:  >e< > :VMS once had this sort of capability with VAXft hardware. >aJ >   And with the Fault Tolerant System Services package, the software thatI >   permitted OpenVMS VAX to utilize the features of the VAXft platforms.0 > 
 > :Given thatiI > :the Tandem folks will have to continue to make significant investments-G > :to provide fault-tolerant IA-64 hardware platforms, it would seem tosI > :make sense to spread that cost beyond the Tandem base alone and in the C > :process give VMS customers a fault-tolerant hardware option oncei	 > :again.o >ME >   Yes, it would.  That said, we (OpenVMS Engineering) are presentlyhI >   primarily interested in booting OpenVMS on IPF, and in the associatediI >   porting of products.  It is simply far too early to be discussing theh0 >   target platform(s) in any particular detail.  F Tru64 UNIX will be fault tolerant long before VMS. Can you say processC pairing and process mirroring? Sure you can, if you work for Tru64!h   ------------------------------    Date: 31 Aug 2001 09:52:26 -07001 From: jason_odonnell@erinet.com (Jason O'Donnell)rR Subject: Re: OpenVMS on Fault Tolerant IPF Hardware (was Re: EV7 will never ship?)= Message-ID: <5c8ffd05.0108310852.4357e172@posting.google.com>D  x "Terry C. Shannon" <terryshannon@mediaone.net> wrote in message news:<DkHj7.1522$%e5.4073583@typhoon.ne.mediaone.net>...A > "Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in messagev/ > news:3Lwj7.1017$bB1.45514@news.cpqcorp.net...SA > > In article <dba3451e.0108292000.15878a8a@posting.google.com>,a6 >  keithparris_nospam@yahoo.com (Keith Parris) writes: > >h> > > :VMS once had this sort of capability with VAXft hardware. > >AL > >   And with the Fault Tolerant System Services package, the software thatK > >   permitted OpenVMS VAX to utilize the features of the VAXft platforms.  > >f > > :Given that K > > :the Tandem folks will have to continue to make significant investments I > > :to provide fault-tolerant IA-64 hardware platforms, it would seem to K > > :make sense to spread that cost beyond the Tandem base alone and in thenE > > :process give VMS customers a fault-tolerant hardware option once3 > > :again.: > > G > >   Yes, it would.  That said, we (OpenVMS Engineering) are presentlycK > >   primarily interested in booting OpenVMS on IPF, and in the associatedtK > >   porting of products.  It is simply far too early to be discussing the 2 > >   target platform(s) in any particular detail. > H > Tru64 UNIX will be fault tolerant long before VMS. Can you say processE > pairing and process mirroring? Sure you can, if you work for Tru64!     So Tru64 is better than OpenVMS?   ------------------------------  # Date: Fri, 31 Aug 2001 17:21:43 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>R Subject: Re: OpenVMS on Fault Tolerant IPF Hardware (was Re: EV7 will never ship?)< Message-ID: <HIPj7.1586$%e5.4251804@typhoon.ne.mediaone.net>  > "Jason O'Donnell" <jason_odonnell@erinet.com> wrote in message7 news:5c8ffd05.0108310852.4357e172@posting.google.com... A > "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messages8 news:<DkHj7.1522$%e5.4073583@typhoon.ne.mediaone.net>...C > > "Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in message31 > > news:3Lwj7.1017$bB1.45514@news.cpqcorp.net...-C > > > In article <dba3451e.0108292000.15878a8a@posting.google.com>,e8 > >  keithparris_nospam@yahoo.com (Keith Parris) writes: > > >n@ > > > :VMS once had this sort of capability with VAXft hardware. > > >tI > > >   And with the Fault Tolerant System Services package, the softwareb thatB > > >   permitted OpenVMS VAX to utilize the features of the VAXft
 platforms. > > >  > > > :Given thattA > > > :the Tandem folks will have to continue to make significant  investmentsSK > > > :to provide fault-tolerant IA-64 hardware platforms, it would seem to I > > > :make sense to spread that cost beyond the Tandem base alone and int thenG > > > :process give VMS customers a fault-tolerant hardware option oncen
 > > > :again.t > > >lI > > >   Yes, it would.  That said, we (OpenVMS Engineering) are presentlyeB > > >   primarily interested in booting OpenVMS on IPF, and in the
 associatedI > > >   porting of products.  It is simply far too early to be discussingt theo4 > > >   target platform(s) in any particular detail. > >eJ > > Tru64 UNIX will be fault tolerant long before VMS. Can you say processG > > pairing and process mirroring? Sure you can, if you work for Tru64!  >sL > So Tru64 is better than OpenVMS???? Did I saay that? Silly, me. Details in  my nooseletter at $395 per year.   ------------------------------  % Date: Fri, 31 Aug 2001 08:02:56 +0200 < From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@home.com>  Subject: Re: PRINT /que=filename( Message-ID: <3B8F2890.52B82B3A@home.com>  . Hi. On Hunter Goatley's site with VMS freeware you can find :  
 execsymb.zip 2A   Description:  A VMS symbiont for execution queues (do whatever) #   Version:      V3.6.1, 15-JUL-1994e0   Author:       John Osudar <OSUDAR@CMT.ANL.GOV>   Architecture: VAX,AXP6   Size:         610 blocks!   Language:     Fortran, MACRO-32t  ? In short, you set up an COM file as the "target" for the queue. ? This COM file will be called whenever something is "printed" tot> the queue. This COM file can, of course, do anything with this0 file, such as just storing it somewhere on disk.   Jan-Erik Sderholm.t   frank brown wrote: > J > Is there a way to create a print queue which sends the output to a file?E > Maybe some special symbiont for this purpose?  I'm using VMS 5.5-2.n   ------------------------------    Date: 31 Aug 2001 08:17:05 -0500 From: briggs@encompasserve.org  Subject: Re: PRINT /que=filename3 Message-ID: <votYpT94fndv@eisner.encompasserve.org>   f In article <sRzj7.272$5u1.939@news-west.eli.net>, "frank brown" <frank.brown@ci.seattle.wa.us> writes:J > Is there a way to create a print queue which sends the output to a file?E > Maybe some special symbiont for this purpose?  I'm using VMS 5.5-2.,  A It would be a pretty trivial PSM$ symbiont modification.  Replace:> the main output routine.  We're talking about something in theB neighborhood of 20 lines of code.  You could do one file per print> job or one file per queue start/stop.  You could take the fileC name from the /ON= queue parameter or from the print job /PARAMETERaC list.  Or you could just hard code it.  There are security concernseE if you allow the submitter to specify a file name and do not have the A symbiont validate it aggressively.  (Print to SYSUAF.DAT anyone?)   C Consider initializing the queue with /NORECORD_BLOCKING to preservem0 input file record boundaries in the output file.  I A different alternative is EXECSYMB (sp?)  That's a freeware package thatyI allows you to have a print symbiont that executes DCL command procedures.o< Lots of very fancy stuff becomes trivial using that package.  . 	John Briggs			briggs@eisner.encompasserve.org   ------------------------------  % Date: Fri, 31 Aug 2001 18:32:11 +1200-. From: Nivlesh Chandra <NChandra001@itc.gov.fj>2 Subject: RMU /SET AFTER_IMAGE_JOURNALING  --- HELPM Message-ID: <084681714A1BD511970B0002A560015F2D774E@exchange01.govnet.gov.fj>c  J I have a database with a active AIJ file. Since the disk where the AIJ wasD located was getting full and I did not know which files to delete, IJ disabled AIJ option on the database since this was causing problems when I was opening the database.    This I did using  ' rmu/set after /disable <root_file_name>d  J Now that I have cleared space on the disk I want to reenable the aij.. butJ all I can find is ways to overwrite the old one ... but I want to just addE the old aij file back to the database.. without overwriting it .. canu someone please help me..K the only command that I found that could attach a disabled aij to the db is-    rmu/set after /enable /overwrite     Nivo   ------------------------------    Date: 31 Aug 2001 07:15:40 -0700! From: apuscas@msn.com (Ana-Maria)m, Subject: Re: Setting up Remote Printer Queue= Message-ID: <5b91db83.0108310615.79970d0d@posting.google.com>   _ WILLIAM WEBB <WWEBB1@email.usps.gov> wrote in message news:<0033000033822502000002L022*@MHS>...S$ > What kind of "line printer" is it? > : > What interface does it use to connect to the VMS system? >      Sorry!  D The office will be connected to our office here via frame relay, butE I'm not sure yet of the printer.  It is either an HP or a Digital dot: matrix type printer.   ------------------------------    Date: 31 Aug 2001 07:31:48 -0700 From: fctoma@yahoo.com (Frank), Subject: Re: Setting up Remote Printer Queue= Message-ID: <d8be2b1f.0108310631.5b8413ae@posting.google.com>W   Hi John,  = I know RPM can do what you are asking. I think the address iseF http://lpd.brooksnet.com  Not sure on the exact page but search for it# and you'll find it at brooksnet.coms   Best,    Terry Bairdt  p John Malmberg <Malmberg@dskwld.zko.dec.compaq> wrote in message news:<3B8E3F74.8070801@dskwld.zko.dec.compaq>... > Ana-Maria wrote: > > Greetings! > > E > > I was hoping someone could give me some advice on how to set up a D > > remote print queue under VMS.  We have two VMS systems here that4 > > coexist with our NT network, all running TCP/IP. > > < > > I am a beginner with VMS, so please excuse the question! > 9 > Welcome to OpenVMS, and the question is appropriate for ) > this newsgroup, so no excuse is needed.g > < > I would first refer you to the OpenVMS FAQ and then to the? > "Ask the Wizard" web pages, as what you want to do is common.t8 > Both are available from http://www.openvms.compaq.com/ >  > 9 > A lot depends on how your printers are connected to ther
 > network. > ; > If they are directly connected to the network, then it isn; > much better for OpenVMS to print directly to the printers ( > instead of going though the NT system. > = > The simplest way to do this is to use DCPS, otherwise known ; > as DECPrint Supervisor, if the printers are ones that areo8 > supported by it.  The right to use the current DCPS is% > included with your OpenVMS license.8 > ; > If you are using the Compaq TCP/IP as your TCP/IP programo; > on your OpenVMS system, and you can not use DCPS for somec9 > reason, your next best option would be to use TELNETSYM : > to the printer, or LPR.  Instructions for this is in the9 > TCP/IP documentation also available at the URL I listed > > above.  There is more detail available in the Ask The Wizard > that will be useful. > 6 > If you can not use DCPS to do the printing, you will? > probably need to set up a device control library as described-< > in Ask The Wizard.  Topic 1020 is the best starting point. > 9 > You need a device control library to make sure that theM< > special print formatting from a previous job does not stay8 > in effect for the new print job you are sending to the
 > printer. > < > Device Control libraries are a good idea to use generally,; > but in the case of sharing a printer with Windows NT theyD< > are usually required.  OpenVMS print jobs generally expect; > the printer margins and page size to be set to the commony" > factory defaults of the printer. > 7 > For some models of printers, Windows NT changes these 7 > margins persistently with each print job.  I have notn > found a way to disable this. > 8 > DCPS comes with prebuilt device control libraries that7 > will normally save you the work of building your own.i >  > 9 > Printing through LPR to Windows NT should be avoided ifr= > you have other than extremely simple printing requirements.i > ; > The LPD receiver in Windows NT is documented by Microsofte; > to only accept one print file per print job.  OpenVMS can * > send multiple files with each print job. >  > 8 > It is possible to use the Pathworks or Advanced Server; > product on OpenVMS to allow NT systems to print to queues  > on the OpenVMS systems.j > 6 > Other options are to use SAMBA on OpenVMS, but it is7 > unsupported freeware, and usually requires a bit more1 > experience to set up.  >  > -Johns  > malmberg@dskwld.zko.dec.compaq > Personal Opinion Only3   ------------------------------  % Date: Fri, 31 Aug 2001 09:31:46 +0200T% From: "Fred Zwarts" <F.Zwarts@KVI.nl>i( Subject: Re: Some postive points I hope.. Message-ID: <9mneh5$i2a$1@info.service.rug.nl>  G "Jan C Vorbrueggen" <vorbrjz6@sunu513.rz.ruhr-uni-bochum.de> wrote in = = message news:6vbvgj7m959.fsf@sunu513.rz.ruhr-uni-bochum.de...r- > John Johnstone <jj_usenet@mail.com> writes:g >=20I > > Don't forget that even with VMS Backup, although it does a good job =a ofH > > keeping the tape fully occupied during a restore, a restore pretty = much hasI > > to take longer than the backup since there's much more overhead, on =  VMSeG > > especially, to create a new file on disk compared to backing up a =n file tot	 > > tape.u >=20H > Why would that be the case? For the restore, you know how many files = you will@ > restore (if /IMAGE), so you allocate the volume's index file = appropriately.=20.F > Then all you have to do is copy files from tape to contiguous disk =
 areas, andE > update the index file once in a while. For anything but a totally =  defragmented0 > disk, this should be _faster_ than the backup. >=20 > Janl  ? My experience is opposite, in particular for multi-volume sets.RF Backing up a multi-volume set of 5 disks of 2 Gb each costed about 3 = hours.E I started a restoration, but gave up after 3 hours when it had only =z restored 5% of the data.1   ------------------------------    Date: 31 Aug 2001 07:47:39 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) 3 Subject: Re: still can't get my UCX licensed???????-3 Message-ID: <561exgOk1+vp@eisner.encompasserve.org>   Z In article <3B8F0403.CE7F3EB@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:  D > You're quite right, of course. The TCP/IP topic comes up so often,I > though, and not having it be part of the system (i.e., a SIP instead of J > a normal part of the basic installation) seems to be the confusing part.- > At least that much seems worthy of mention.A  G That would certainly be an attack on the notion of third party vendors.0   ------------------------------  # Date: Tue, 28 Aug 2001 08:28:06 GMT  From: Dirk Munk <munk@home.nl>+ Subject: Re: Storageworks retirement letter4' Message-ID: <3B8F2ED9.218C7AA0@home.nl>A   Dave Gudewicz wrote:  N > Interesting to note that the HSZ80, while not on the retirement list, is not > on the migration list. >l	 > Dave...m >i  O The reason is simple. The HSZ80 is going to be retired at the end of this month- ......     Regards,   Dirk         >0; > "Alan Greig" <alan.greig@intl.fmcti.com> wrote in message:4 > news:8iffnt8178nrckh0p20hc18b8u9rg52ntl@4ax.com... > > H > > I've scanned in the letter from Compaq and OCRd it. Here is the textG > > of the letter. I can email a physical scanned image if anyone needsi > > one. > > 
 > > ====== > >h > > Compaq Computer LimitedX > > Worton Grange Imperial Way > > Reading Berkshire RG2 OTEe > >m > >o > > Telephone 0118 986 8711> > > Fax 01189867969o > > www.compaq.co.uk > >m > >7 > >a > >o > >  > > ALAN GREIG > > .... > > Address ommitted > > .... > >8 > > 21st June 2001 > > # > > Dear Software Service Customer,  > >:H > > Compaq Computer Limited, Customer Services UK and Ireland, wishes to> > > inform you that we have begun a retirement process for theG > > distribution and services for the software of the following storageE > > hardware items:0 > >0I > > HS1CP, HSD3O, HSD5O, HSJ3O, HSJ4O, HSJ5O, HSZ4O, HSZ5O, HSZ7O, RA41O,aH > > AA450, RA3000 wfth HSZ22 (for NT/Alpha, Novell Netware, Sun Solaris, > > HP-UX, IBM-AIX)o > > H > > As a result of this retirement, Compaq SOFTWARE Services (ie licenseD > > subscription, software update distribution services and softwareI > > telephone support) will no longer be available for the above items asmG > > of 30th Jan 2002. Note hardware maintenance continues for the above:
 > > items. > >hJ > > In addition software services for the RA3000 with HSZ22 (for NT/Intel,I > > VMS/Alpha, Unix/Alpha) will end on 31st July 2003. Again the hardware$ > > maintenance will continue. > >aI > > A migration path is offered with 50% off the storage controller pricepJ > > (le HSG8O and HSJ8Os). We can also offer leasing options for those whoD > > would prefer to lease the new storage controllers and associated > > equipment. > >eF > > The suggested migration paths for those who wish to upgrade are as > > follows: > >  > > HSDxx migrate to HSG8O# > > HSJxx migrate to HSG8O or HSJ8Om > > HSZxx migrate to HSG8O$ > > HS1 CP migrate to HSG8O or HSJ8O# > > RA41O migrate to HSG8O or HSJ8O # > > RA450 migrate to HSG8O or HSJ8Oo& > > RA3000 with HSZ22 migrate to HSG8O > >e6 > > The options currently available are the following:B > > i) Continue with your current storage hardware and continue to2 > > receive hardware maintenance support services.F > > ii) Migrate to the relevant HSx8O option and related storage under > > a leasing arrangement.D > > iii) Migrate to the relevant HSx8O option as a straight purchase > > arrangement. > > H > > For further information on migration and leasing options please callI > > our Glasgow call centre on 0845 270 4114 quoting campaign code 01 SML- > >- > > Yours faithfully,  > >: > >7 > >r > >a > > Trish Sandys > > Compaq Computer Ltd  > > Compaq Customer Services3 > > Registered Office: Hotharn House 1 Heron Square > > > Richmond Surrey TW9 IEJRegistered n England number 1792087 > >r > >  > > -- > > Alan   ------------------------------  + Date: Fri, 31 Aug 2001 10:53:53 +0000 (UTC)o' From: david20@alpha2.mdx.ac.uk (D.Webb)l  Subject: Sun has a go at Itanium+ Message-ID: <9mnqc1$b6b$1@aquila.mdx.ac.uk>n  + Just seen this on http://silicon.com/p469477   "p0       Sun and Intel go head-to-head over Itanium  ,    What good's a mechanic without a toolkit?  H    Sun Microsystems has dismissed Intel's Itanium strategy, claiming theB    processor has no proven development tools to back it up, making9    investment in the architecture highly risky for users.f  E    Matthew Keep, product manager for servers at Sun, told silicon.comuB    that Sun's Sparc 64-bit processor technology is the only viableF    alternative, justifying its lonely stance as the only vendor not to    adopt Itanium.T  C    Almost the entire industry is lining up to endorse Itanium, withoC    Compaq, Dell, HP and IBM all planning to introduce Itanium-based.E    servers, even though they may have to recompile software to handlen*    future phases of Itanium's development.      Silicon Says I    A bright future for Itanium? Perhaps brighter than that we painted for     the P4, a few months back.aD    Keep claimed Compaq's move to discontinue its AlphaServer line toH    introduce Itanium-based servers had caused unrest among some users of    Compaq's systems.  E    However, Compaq said its strategy to move to Itanium is a bold one I    which its customers firmly support. The company's plan is to integratenG    Itanium over a seven to eight year period, during which time it willR,    gradually phase out its AlphaServer line.  G    Tom Yates, director of high performance systems EMEA at Compaq, saidlI    this is an attempt by Sun to create uncertainty, doubt and mischief inoD    the market place to catch some business, because it is "unable to0    articulate any movement in its own business".  E    He said Sun will be forced to adopt Itanium in two to three years'o.    time, as it will dominate 64-bit computing.  I    In addition, Yates said Sun is trying to cover up its lack of opennessoD    with its own customers. "They do not know how to communicate with    customers," said Yates.I    However, Andrew Butler, VP at Gartner Dataquest sympathised with Sun'sFI    stance given that its strategy is built around the long-term future ofeC    the Sparc architecture. "Sun has little choice but to attack the D    viability of Itanium. I would be doing the same thing if I was in     Sun's position," said Butler.  G    However, Butler said in five years time it will become difficult for )    Sun to fend off the growth of Itanium.o  I    He claimed that adopting it would be hypocritical, but not adopting ita:    could put that division of the company out of business.  B    "It will become difficult for Sun to keep Sun Sparc alive as an4    alternative to Itanium in 10 years," said Butler.  D    Intel flatly denied Sun's claims. Chris Hogg, enterprise businessF    manager for EMEA at Intel, told silicon.com: "There's a plethora ofC    applications and tools and operating systems" for Itanium chips.o "b    
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  % Date: Fri, 31 Aug 2001 10:14:51 +0100?8 From: John Macallister <J.Macallister1@physics.ox.ac.uk>, Subject: RE: Tape Parity Error: How to Read?N Message-ID: <35666012DF4CD411BE940090279FA240010BF01C@ppnt41.physics.ox.ac.uk>  K It's often possible to skip past errors on tapes. Continue reading block by8, block until sensible data can be seen again.   John  B Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.ukH Post: Nuclear and Astrophysics Laboratory, Keble Road, Oxford OX1 3RH,UKA Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax)    ------------------------------  % Date: Fri, 31 Aug 2001 10:45:23 +0100a8 From: John Macallister <J.Macallister1@physics.ox.ac.uk>, Subject: RE: Tape Parity Error: How to Read?N Message-ID: <35666012DF4CD411BE940090279FA240010BF01E@ppnt41.physics.ox.ac.uk>  3 > Obviously, the tape wasn't written by VMS BACKUP i  L It would have been a crazy option for 9track tapes but they could have optedJ not to use redundancy blocks by specifying /GROUP=0 when making the backup ..   John    B Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.ukH Post: Nuclear and Astrophysics Laboratory, Keble Road, Oxford OX1 3RH,UKA Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax)@   ------------------------------   Date: 31 Aug 2001 07:19 CDTw' From: carl@gerg.tamu.edu (Carl Perkins)c, Subject: Re: Tape Parity Error: How to Read?- Message-ID: <31AUG200107190692@gerg.tamu.edu>a  ( Mikec@netins.net (Mike Czizek) writes...M }We have an Alpha server running OpenVMS version 7.1.  We received a 9 track tN }magnetic tape the other day which has a tape parity error about 80% into the J }file.  We were able to retrieve the 80% but do not know how or if we can 0 }retrieve the information past the parity error. } N }I realize that there will be some loss of data but is it possible to somehow = }retrieve the bulk of that 20% of data past the parity error?n }  }--  }Mike Czizek  - You didn't say how you were reading the tape.   I In some cases you can just keep reading and after the bad section it willoF manage to read data again. It may even be possible using COPY from theG command line - I've managed it a few times on foreign mounted tapes, atsI least, where I get a parity error and then just enter COPY MKA0: TAPE.DATtH a few more times and managed to recover more data pas the bad spot (whenF you hit a fatal controller error instead of a parity error you are out	 of luck).o  F Have you checked the tape drive's head to see if it needs cleaning (orH read anything successfully since the error)? A dirty head can cause thisJ type of error, and cleaning it can allow the tape to be read successfully.  I You might also try writing a program (or getting one from somewhere) thateG uses QIOs to read the tape and manage the returned errors. Retrying badtE reads can, sometimes, get you the data if it is a borderline case (orcG you can wear the magnetic particles of the tape and dirty the read headdI if you retry to many times). It can also be posisble to just keep readinga3 after the error happens, which will sometimes work.t  F The solution can also depend on the tape drive. Many years ago (aroundG early 1983) I was working at a place that had a tape drive go insane. AuG couple of times, before it was fixed, it physically stretched tapes badcG enough that the tapes caused the (repaired) tape drive to loose vaccuumiE and stop (you could see the tape get visibly narrower at the affected0F location).  The solution in that case was offered by a feature of thatE specific model of tape drive: it could read the tape backwards. So inmG that case, the solution was to read until it failed, then manually wind0F the tape past the bad part, then use a program that issued the propperG QIOs to fast forward to the end of the tape and then issue the "reverse!F read" commands to read records from the tape backwards until it failedD again. The data loss was the contents of a few inches of tape. It isH unlikely that your tape drive has such a "revrese read" option - but not impossible.8   --- Carl   ------------------------------   Date: 31 Aug 2001 13:15:41 GMT$ From: Mikec@netins.net (Mike Czizek), Subject: Re: Tape Parity Error: How to Read?+ Message-ID: <9mo2lt$4f0$1@ins21.netins.net>k  O Thank you Dick.  Using your recommendation of "set magtape /skip ..." resolved oM the problem.  We were able to recover nearly all of the missing data. Thanks l again.  A In article <3B8E9A64.3BC8B31F@ohio.edu>, piccard@ohio.edu says...1 >kP >The original hasn't reached my news server yet, so I am going only on the part  Dave
 >quoted... >eH >If it really is a 9-track tape, then you probably do have some hope of  recovering theE >unmangled data after the error;  your magic commands will start with  >  >$ HELP SET MAGTAPE /SKIP  >pL >There are also data recovery services, who may well be able to recover the 	 data more O >completely than you could, or quicker, but at a cost.  Can you put a value on e theV >missing data? >t$ >                                RDP >  >  >David Jones wrote:t > N >> In message <9mls5p$avm$1@ins21.netins.net>, Mikec@netins.net (Mike Czizek)  writes:uO >> >We have an Alpha server running OpenVMS version 7.1.  We received a 9 trackdM >> >magnetic tape the other day which has a tape parity error about 80% into e thetL >> >file.  We were able to retrieve the 80% but do not know how or if we can3 >> >retrieve the information past the parity error.u >>J >> Obviously, the tape wasn't written by VMS BACKUP or your question wouldL >> be concerning what a message about 'data recovered from redundancy block'K >> meant :-)  BACKUP traditionally had no trouble reading past media errors F >> on 9 track tapes.  On some more 'modern' tape formats you aren't soM >> lucky - the controller hardware freaks out and continuation is impossible.t >>I >> >I realize that there will be some loss of data but is it possible to   somehowe@ >> >retrieve the bulk of that 20% of data past the parity error? >>N >> Probably, but not if the answer you are looking for is some magic qualifierG >> on the COPY command.  You'll have to write a special purpose program G >> that knows how to read the tape labels and interpret the error codes F >> from the magnetic tape driver.  I seem to recall once writing a DCLN >> procedure to solve a similar problem to yours, but the data on the tape wasD >> written with 80-byte blocks (small enough for DCL's record length >> restrictions).g >>? >> David L. Jones               |      Phone:    (614) 292-6929i0 >> Ohio State University        |      Internet:O >> 140 W. 19th St. Rm. 231a     |               jonesd@er6s1.eng.ohio-state.eduo= >> Columbus, OH 43210           |               vman+@osu.edu  >>4 >> Disclaimer: I'm looking for marbles all day long. >  >--sC >==================================================================hC >Dick Piccard                           Academic Technology Manager C >piccard@ohio.edu                                 Computer ServiceseC >http://oak.cats.ohiou.edu/~piccard/                Ohio Universitye >v >i   -- w Mike Czizeke   Iowa Network Services, Inc.c   mikec@netins.com   ------------------------------  # Date: Fri, 31 Aug 2001 07:42:29 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>- Subject: Re: Terry Shannon Tech Talk on Tru64s< Message-ID: <FdHj7.1518$%e5.4071868@typhoon.ne.mediaone.net>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3B8EFD93.D419CFD2@fsi.net...b > "Terry C. Shannon" wrote:  > > D > > "Newbie JrSysAdmin" <utlonghornsrule@yahoo.com> wrote in message: > > news:2de05464.0108200901.ed637c2@posting.google.com...- > > > eccm <eccm@swbell.net> wrote in messaget* > > news:<3B81C141.62F3ECF2@swbell.net>...I > > > > Haha! a bletcherous personal flame, born of /dev/null and drooledg fromF > > > > the lips of a known entity, perched upon a pinnacle of its own cruft,E > > > > er.. from a yahoo-over-goolge account! What are we coming to?m > > > >gJ > > > > Shannon's on the user society board of directors, so maybe he gets toJ > > > > go for free, so what if he does?. There was a time not so long agoG > > > > when that was not the case. Shannon Knows Anaheim Hotel Prices,e yes..aA > > > > but that's immaterial. Those that are of any knowledge ine professionalH > > > > matters don't compute "shannon" with "lackey", as they are aware that: > > > > the two are not same type variable. get knowledge. > > > > F > > > > BTW- there aren't really any good hotel rooms in Anaheim, just > > > > overpriced ones. > > > >o > > >uG > > > for the record, i apologized to terry for my missive. he's just ahL > > > smart guy making a living, and you guys have freely created the market > > > for him. > > > J > > > but, some of you need to buy a dictionary. you are misusing words ofI > > > as few as two syllables, words i hope my own son will master aroundrH > > > the 7th grade. pardon my noting the non-coincidence of the "compaqA > > > enterprise unix" crowd and this basic cognitive deficiency.g > > >7H > > > and, some of you compaq cheerleaders should respond to some of theK > > > compaq folks who are in here critical in name. they "deserve" to havecG > > > their posts addressed, and they have called compaq far worse thant > > > "lackey."a > > >e" > > > but, i won't hold my breath. > >uD > > Nor will I because I don't want to look like a Smurf. Compaq has problemsJ > > aplenty. The aquisition of an aggressive and competitive marketing and( > > strategy staff damn sure would help! >a > Terry, >sH > Meet me at Rich Marcello's office on Monday after CETS. No appointmentJ > necessary - we'll just walk in and announce that we're the new marketingC > people. They'll scoff at us at first, until we bring in the first:I > thousand or so new customers. Then, they'll be laughing up their sleeve , > and we'll be laughing all the way to bank. >hF > We can talk about it, demand that they do it, or we can go do it for > 'em. I say we do the latter. >  > What say ye? .h I'd say it couldn't hurt!r   ------------------------------  % Date: Fri, 31 Aug 2001 04:26:51 -0400A  From: John Santos <JOHN@egh.com>% Subject: Re: Tunneling DECnet over IP76 Message-ID: <1010831041237.38017A-100000@Ives.egh.com>  - On Thu, 30 Aug 2001, Barry Treahy, Jr. wrote:i   > "Zane H. Healy" wrote: > H > > What I'm looking for is some sort of tunneling software that runs onL > > OpenVMS, and negates the need for having a UNIX box.  Is anyone aware of > > such software? > N > Though HECnet might be nice, you are mistaken here, at least with regards toQ > TCPware.  TCPware has the ability to tunnel DECnet between two VMS systems overiO > TCP/IP and maintain the native DECnet interface.  The obvious benefit is thatrQ > you can have two area networks thousands of miles apart, only connected via the R > Internet hopefully with a VPN, and still interact with all combined DECnet nodes7 > in this network as if they were all physically local.  > M > I presume that Multinet can do the same thing, but if you need this I would Q > encourage you to contact Process Software.  We use their products and also betaa: > test, and I have no complaints, they are a solid vendor. >  > Best regards,W >  > Barry(  F Both TCPWare and Multinet are available under hobbyist licenses.  TheyD both have a "DECnet-over-IP" driver, that allows an IP connection toA appear as a virtual DECnet line & circuit (phase IV terminology).n  B A DECnet end node can use this as its (only) connection to anotherE DECnet node.  A DECnet routing node can support multiple connections,wC including other "DECnet-over-IP" connections and traditional DECnetcA circuits (Ethernet, DDCMP, Asynch serial, etc.) and route betweeno them.n  @ Things I don't know:  1) If it works with Phase V or only Ph IV.B 2) If the TCPWare and Multinet implementations are compatible with< each other.  3) Whether the specs are published or if uses a@ "standard" (to the extent such things exist), so that compatible+ 3rd party implementations could be written.S  ? If 3) is true, then perhaps this protocol could be used instead = of VTUN, eliminating the need for a Unix box at any site that8? has a VAX or Alpha, which could act as a local DECnet router toi> HECnet.  (Or is there a VTUN implementation for VMS that could= be hooked into a pseudo terminal, which VMS DECNet could thene use as an asynch DECnet line?)   -- m John Santosp Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Fri, 31 Aug 2001 08:47:43 -0400g2 From: rdeininger@mindspring.com (Robert Deininger)% Subject: Re: Tunneling DECnet over IPuL Message-ID: <rdeininger-3108010847430001@user-2ivec4v.dialup.mindspring.com>  F In article <twDj7.297$_I.534633@e3500-chi1.usenetserver.com>, "Zane H.* Healy" <healyzh@shell1.aracnet.com> wrote:  H > Oddly enough there is currently a hobbyist project underway to setup a' > global Hobbyist DECnet (aka HECnet). S  G Hooray!  The world hasn't been as fun since HEPnet started to rot away.r  I Is anyone managing the HECnet address space?  Since parts of HEPnet stilluJ exist (but are mostly not connected anymore) it would perhaps be useful toH avoid collisions with existing HEPnet nodes where possible.  Some HEPnet" nodes might want to join HECnet...  & > It will have hosts running more thanK > just OpenVMS, in fact the first couple hosts seem to be PDP-11's (and I'd D > also like to see PDP-10's eventually, though they'd most likely beH > emulated).  The solution so far is to stick UNIX boxes running VTUN[1]L > between the remote DECnet segments to tunnel the DECnet over the Internet. > M > I've been looking at the DECnet over IP information in the TCPIP and DECnetoN > manuals, and as far as I can tell, all it really does is allow you to use IPM > addresses and such with your DECnet aware apps to connect to remove systemsr
 > over TCPIP.t  F I can't point to a specific part, but I don't like your description ofI DECnet over IP.  Once you configure it, it looks like DECnet to users andfJ apps, and it can run over tcpip behind the scenes.  Nobody ever has to seeJ the tcpip addresses, except the administrator.  It just looks like DECnet.  F > What I'm looking for is some sort of tunneling software that runs onJ > OpenVMS, and negates the need for having a UNIX box.  Is anyone aware of > such software?  I A DECnet-plus routing node can connect phase-IV only networks to phase-V, D DECnet-over-tcpip networks.  So a VMS machine can do the tunnelling.C Phase-IV nodes are restricted to the small DECnet-IV address space.t  G DECnet-plus can do decnet-over-tcpip with any tcpip stack that supportseI the PWIP (pathworks) driver.  That includes UCX, TCPIP, and Multinet thatmD I know of.  I think TCPware as well, but I've no experience with it.  I Multinet also has it's own DECnet-over-tcpip tunnelling, which works withu@ DECnet-IV, but only between multinet (and maybe tcpware?) nodes.  * Now I'll go take a look at this VPN thing.   -- t Robert Deininger rdeininger@mindspring.com-   ------------------------------  % Date: Fri, 31 Aug 2001 15:08:40 +0200l< From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@home.com>% Subject: Re: Tunneling DECnet over IP"( Message-ID: <3B8F8C58.677C6889@home.com>  9 Check NG : vmsnet.pdp-11 for more info on this project...e   Jan-Erik Sderholm.b  J > > Oddly enough there is currently a hobbyist project underway to setup a( > > global Hobbyist DECnet (aka HECnet).   ------------------------------  # Date: Fri, 31 Aug 2001 17:43:58 GMTo2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)% Subject: Re: Tunneling DECnet over IP 3 Message-ID: <y1Qj7.1067$bB1.46061@news.cpqcorp.net>   r In article <twDj7.297$_I.534633@e3500-chi1.usenetserver.com>, "Zane H. Healy" <healyzh@shell1.aracnet.com> writes:  > :...The solution so far is to stick UNIX boxes running VTUN[1]M :between the remote DECnet segments to tunnel the DECnet over the Internet...l :aL :I've been looking at the DECnet over IP information in the TCPIP and DECnetM :manuals, and as far as I can tell, all it really does is allow you to use IPnL :addresses and such with your DECnet aware apps to connect to remove systems :over TCPIP.    H   Correct.  This mechanism does not particularly attempt to encapsulate $   DECnet, it uses IP as a transport.  E   Also, DECnet Phase IV hosts can PMR (poor man's routing) over an IP 0   link through an intermediate DECnet-Plus host.  E :What I'm looking for is some sort of tunneling software that runs on I :OpenVMS, and negates the need for having a UNIX box.  Is anyone aware of  :such software?.  E   The two approaches I've seen used are DECnet-Plus over IP, and the aF   DECnet Phase IV connection into IP that Process Multinet (IIRC) had.   	--   I   And before the request is again passed along to me -- this thread will -J   likely trigger the request -- access into the Compaq ECO (patch) server H   area will available be via IP.  I have been informed that DECnet-Plus ?   access (via IP) into the ECO area will not be made available.0  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------    Date: 31 Aug 2001 01:42:45 -0700+ From: andreas.kanon@home.se (Andreas Kanon)   Subject: Re: Understanding ast ?= Message-ID: <dbbc6dc6.0108310042.5277bbd3@posting.google.com>D  m hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) wrote in message news:<UNuj7.1010$bB1.45370@news.cpqcorp.net>...1m > In article <dbbc6dc6.0108300504.230f8b27@posting.google.com>, andreas.kanon@home.se (Andreas Kanon) writes:v > B > :I have a number of detached processes and they are started withG > :$CREPRC and are started with a user other than the system user. DoesrI > :that mean that the limititation of ast:s are the number defined in UAFa: > :(ASTlm) for that user or is there more to it than that. > J >   Detached process quotas get what you set via the $creprc quota array, E >   or (if not specified or specified below the system minimums) the hE >   process get the system defaults and will get at least the system nC >   minimums.  (IIRC, the authorization file is not involved in theaI >   detached process quota settings, even if you specify the AUTH flag --wG >   to get the SYS$SCRATCH and SYS$LOGIN logical names defined based onn' >   the target user profile in SYSUAF.)  > K >   When presented with a quota argument on an OpenVMS system service, you  H >   will always want to explicitly use it.  Why?  Because if you don't, H >   your application will function (or not function) at the whim of the  >   system-wide quota settings.t > J >   In SYSGEN/SYSMAN, you can view the system-wide process quota settings 8 >   and process quota minimums via the SHOW/PQL command. >  > P >  ---------------------------- #include <rtfaq.h> -----------------------------P >       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    P >  --------------------------- pure personal opinion ---------------------------N >    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com      3 Thanks for the replies , helped out a great deal :)i  D Not beeing a developer makes it a bit tricky to understand , but i'm% slowly starting to get ahold of this.    /Andreas   ------------------------------   Date: 31 Aug 2001 16:23:25 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)a$ Subject: Re: Wailing and Moaning...., Message-ID: <9modlt$2mjf$1@info.cs.uofs.edu>  L In article <rdeininger-2108012311200001@user-2ivealm.dialup.mindspring.com>,5  rdeininger@mindspring.com (Robert Deininger) writes:d> |> In article <3B8313B3.CC9F36A4@fsi.net>, "David J. Dachtera"! |> <djesys.nospam@fsi.net> wrote:i |> fL |> > Now, go back and see how many are also demanding everything from NT and+ |> > Oracle to DEC-C, Beckman LIMS and OOP.  |> nJ |> But that's a fantasy skill set.  They can't realistically expect to get |> all that in one person. |> a  G Reality has little to do with hiring practices.  I once interviewed for I a local job here just out of curiosity.  They wanted a MS in Comp Sci ANDmE at least 9 years experience.  At the interview it was stated that thegF starting salary was $18,000.  But then, that's this area.  They seltedG for an in-progress under-grad, which was more realistic.  But then, ourtG undergrads all start at a lot higher than that by leaving the area. :-).   bill   -- hJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 31 Aug 2001 16:42:21 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)l= Subject: Re: Wailing at Eunuchs (was: Wailing and Moaning...) , Message-ID: <9moepd$2mjf$2@info.cs.uofs.edu>  3 In article <0GpP9nB9JWRH@eisner.encompasserve.org>,e.  young_r@encompasserve.org (Rob Young) writes:P |> In article <3B833DE9.66425070@home.com>, unixguys <unixguys@home.com> writes: |> > Rob Young wrote:  |> >> \ |> >> In article <3B82E029.BE2ACB0E@bigfoot.com>, Hamlyn Mootoo <univms@bigfoot.com> writes: |> >> A |> >> > And even though from time to time here, the ardent VMSerspC |> >> > criticize Unix for certain shortcoming they perceive exist,e |> >> ; |> >>         Not perceive.  They do exist.  vi sucks.  The  |> > e@ |> > So don't use vi, use the dozens of other editors out there. |> > t |> f |> i? |> 	Yep.  The Unix answer.  Buy a product and tailor it to suitt |> 	your needs.  r  E Buy???   There are more than a dozen free editors available for Unix.eB Surely one of them would prove acceptable??  Unless, of course you/ believe, "If it ain't LSE it ain't an editor!!"   H |>                   Backup?  We don't want to force that on you either.  7 And how exactly does VMS "force" one to do a backup??  t   |> > |> eN |> >>         Unix hiearchial filesystem is *always* a big disaster waiting toU |> >>         happen.  Two skilled Unix "persons" making a mistake in a shell script.tP |> >>         Two high profile clients dead in the water for a day or two.  Why? |> >> - |> >>         # rm -r ${variable_goes_here}/*t |> > w< |> > Couldn't have been too "skilled" to make that mistake ! |> >   |> aH |> 	Absolutely skilled.  One of the people is a 15 year veteran, admin, E |> 	system configurator... one of the brighter guys you would know.  t  G And VMS people never make mistakes??  No VMS Admin or Operator has evernK accidently mounted the wrong tape with a write-ring installed??  On another>G note, I can restore my Unix system and all User files in about 3 hours.1I Last week the datacenter (running VMS on Alphas) lost a disk.  4 hours to1K replace the disk, 3 days to restore the file system.  I kid you not!!!  AndrK this on the latter half of the last week before school started, when people=9 were trying to pay their tuition and get their schedules.    No OS is perfect!!   |> a |> 	Trust me... bad design.    Trust me, matter of opinion.   |> iL |> > If indeed they were running AIX they should have been up in a couple ofJ |> > hours even if the drives weren't mirrored, get rid of above mentionedJ |> > "skilled unix persons", put in your previous nights bootable tape setM |> > the machine to service mode, boot it and you are back up and running ...n0 |> > no tape you say, well see my first comment. |> > 6 |> hJ |> 	Yep.  You just did the OS restore.  But with the hiearchial filesystemE |> 	you also wiped out the db's.  12 years of databases that take thee= |> 	better part of 2 days (maybe 3, can't recall) to restore.r  C 2 to 3 days??  I can restore 20GB an hour. How big are these db's??.  C But then, we have heard all this drivel before.  Everything isn't a6D nail and there are more tools than just a hammer.  The hammer makers6 guild may not like it or believe it, but it is a fact.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   d   ------------------------------  % Date: Fri, 31 Aug 2001 13:53:21 +0200 , From: Didier Morandi <Didier.Morandi@gmx.ch>Y Subject: Re: What are the exact steps in order to add a user account with VAX-VMS v6.0 v6a& Message-ID: <3B8F7AB1.83F3F69F@gmx.ch>   Didier Morandi wrote:h > L > $ if f$search("sys$manager:adduser.com) .nes. "" then @sys$manager:adduser  ! Well, it's in sys$help:[examples]e Sorry.   D.   ------------------------------    Date: 31 Aug 2001 07:07:56 -0700- From: afeldman@gfigroup.com (Alan E. Feldman)e0 Subject: Re: Why continue with OpenVMS / Compaq?< Message-ID: <af1e4ce6.0108310607.6859745@posting.google.com>  a JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3B8F1D2B.B73D79AA@videotron.ca>...l > "Alan E. Feldman" wrote:J > > Well, if you hadn't posted, you'd still be able to quit Compaq without > > starting a run on the bank.p > O > How quickly people forget. The run on the bank started in the early 1990s, inu > a previous millenium.l  9 I respectfully disagree. From Webster's online dictionaryc# (www.webster.com) under run (noun):v  ? f : persistent and heavy demands from depositors, creditors, orr customers <a run on a bank>   E I'd hardly call the 90's a "run on the bank". Yes, many organizationsdE switched from VMS to other OSes, but it was not a panic and there wasaB no immediate concern of total bankruptcy. There were other reasonsE that people switched. And many did not switch, of course. And no "runc on the bank" last 10 years!   P > Compaq was given a long chance to prove to customers that it was serious aboutO > VMS and turn things around. And things were looking up last year when VMS was:G > given a token marketing budget. But that was a false hope once again.v   True.   P > VMS isn't being ported to IA64 to improve VMS's fortunes. It is ported to IA64P > because Compaq pulled the plug on Alpha in exchange for an irresistible wad ofK > money from Intel.  The port is just a necessary chore that is part of ther) > cleanup to make the Alpha murder clean.S  ' The port also means it ain't dead yet. g  L > The port to IA64 has not changed Compaq's attitudes towards VMS. And whileP > Compaq isn't actively trying to kill VMS, they have repeatedly shown that theyD > are indifferent to VMS since it isn't part of their core strategy.  B True, but things can change over time. But if posters start a trueE panic of organizations leaving VMS, then there is no hope at all. AndsF the fewer people left running on VMS, the easier it will be for Compaq to pull the plug.b  > The original poster's post recommended an IMMEDIATE (his caps)D withdrawal from VMS. *That's* asking for a run on the bank which, if# it happens, means all hope is lost.l  5 I'm running MicroVAXes here and no one is panicking. d  D I feel there is certainly reason to be concerned, but not to panic.    Things can change in 3 years.   " Disclaimer: JMHO, not gfigroup's.  Alan E. Feldmant afeldman@gfigroup.coml   ------------------------------   End of INFO-VAX 2001.484 ************************