1 INFO-VAX	Sat, 13 Jul 2002	Volume 2002 : Issue 383       Contents:- Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...)  Re: DS10 shutting down Re: HP Itanium2 benchmarks Re: HP Itanium2 benchmarks( RE: Intel Wall Street Journal Itanium Ad( Re: Intel Wall Street Journal Itanium Ad( RE: Intel Wall Street Journal Itanium Ad! Re: Itanium II Another Shoe Drops ! Re: Itanium II Another Shoe Drops ! Re: Itanium II Another Shoe Drops ! Re: Itanium II Another Shoe Drops ! Re: Itanium II Another Shoe Drops ! Re: Itanium II Another Shoe Drops ! Re: Itanium II Another Shoe Drops ! Re: Itanium II Another Shoe Drops ! Re: Itanium II Another Shoe Drops ! Re: Itanium II Another Shoe Drops  Re: McKinley Cometh... Re: McKinley Cometh...+ Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts . Re: OpenSSL and certificates concept questions. Re: OpenSSL and certificates concept questionsA Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!) A Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!) A Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!) A Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!) A Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!) A Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!) A Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!)  Re: Oracle RDB on VMS ( Re: oracleRDb on Open VMS install errors( Re: oracleRDb on Open VMS install errors( Re: oracleRDb on Open VMS install errors Re: RECALL suggestion 7 TSM (Terminal Server Manager) on DECnet IV and DECnet V ; Re: TSM (Terminal Server Manager) on DECnet IV and DECnet V  Re: un-INITing a tape? Re: un-INITing a tape?9 VS3100/38: Infinitely looping bugchecks at boot (VMS 552)   F ----------------------------------------------------------------------   Date: 13 Jul 02 08:54:40 +0200) From: p_sture@elias.decus.ch (Paul Sture) 6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)) Message-ID: <xdZsBOTJmfyn@elias.decus.ch>   E In article <1026417901.734555@nnrp2.phx1.gblx.net>, "Dennis O'Connor"  <dmoc@primenet.com> writes:   ; Perhaps some reasoned argument, but I honestly do not care.   1 The man has a history of being an anti-VMS troll.   K This posted simply because of the venom he has posted to comp.os.vms in the  past. Be warned folks.   __
 Paul Sture   ------------------------------   Date: 13 Jul 2002 07:37:24 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)/ Message-ID: <agolbk$41$1@pegasus.csx.cam.ac.uk>   9 In article <igb-F17AAF.18294112072002@netnews.attbi.com>, " Iain Bason  <igb@attbi.com> wrote:1 >In article <agl00k$q2b$1@pegasus.csx.cam.ac.uk>, + > nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:  > D >> And your point about the memory operations being similar to thoseB >> needed for communication is one that is sadly missed by most of >> the current HPC people :-(  > @ >I don't know that it's missed (seems pretty obvious to me), butB >it does take extra hardware to do a memory to memory move at fullE >speed while letting the CPU continue to execute unrelated operations E >out of cache.  The question is, are there enough circumstances where 8 >that's feasible to justify the expense of the hardware? > " >I don't claim to know the answer.  D That is a good point!  But it wasn't actually the one I was thinking of :-)  B I was thinking of the interlocking issues in SMP systems, and whenC implementing high-performance I/O.  These have the basic concept of B "I am about to do something to bytes A-B; keep your sticky fingersB off them until I have finished."  I won't replicate another thread= here, but the fact that this concept doesn't usually exist in $ hardware adds a LOT of difficulties.  D Which doesn't mean that I think that the hardware SHOULD include it,B but that ALL levels of software and hardware should use consistent models.  Currently, they don't.      Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679    ------------------------------  % Date: Fri, 12 Jul 2002 23:41:41 +0200 3 From: Terje Mathisen <terje.mathisen@hda.hydro.com> 6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)- Message-ID: <3D2F4D15.863C42B5@hda.hydro.com>    Nick Maclaren wrote: > / > In article <3D2E919F.8A6CB291@hda.hydro.com>, 7 > Terje Mathisen <terje.mathisen@hda.hydro.com> writes:  > |> JF Mezei wrote: > |> >S > |> > But in Unix/C, a routine such as strcpy must really look at individual bytes S > |> > to determine where the copy is to stop, so a single assembler instruction to U > |> > move large amounts of data doesn't map terribly well to C in this case and you D > |> > need a loop with a test for 0 in there and move byte by byte. > |>J > |> Good strcpy() implementations, either generated as inline code by the7 > |> compiler, or as called library code won't do that:  > |>L > |> Even on x86 most compilers have used 4-byte load/store operations, with > |> checks for any zero byte. > |>K > |> Alpha have dedicated opcodes to handle this, making it very natural to   > |> move 8 bytes per iteration. > > > It is a pity that correct code has great difficulty in using
 > them :-( > ? > In C+POSIX or C+OpenMP, it is permitted for two threads (or a A > thread and a signal handler) to access separate objects with no = > explicit synchronisation, provided that the objests are not > > aliased in the language sense.  And, because it is permitted; > to access any byte of any type of object as a char, it is = > generally essential not to access even a single byte beyond  > the end of a string. > A > It is commonly believed that this applies only for writing, but ? > that is not so.  It is permitted for one thread or handler to = > do I/O directly to an object, which is in turn permitted to @ > lock the object to that process in hardware.  You can then getA > deadly embraces in programs that conceptually should terminate.  > ? > Now, I don't know the exact specification of the Alpha codes, ? > and there are ways to get some way without falling foul of C, . > POSIX or OpenMP, but it is a nightmare area.  E Nick, I'll accept that it is possible to setup a system in such a way G that it is crucial to not even read any bytes past the terminating null  byte.   G However, IMNSHO if you actually manage to shoot yourself in the foot in < this way, you really do deserve to bleed all over the floor.  G On the platforms I know reasonably well, it is very hard to imagine any G method by which you could (even using third party DMA) modify a part of E a word that's already in cache, without the cache protocols detecting D it. Even assuming you could do it, the driver responsible would then= have to make sure that any already-cached lines were flushed.   @ What is important is to make sure that all accesses are properlyF aligned, and this can easily lead to significant slowdowns when str*()# is used on randomly aligned inputs.    Terje  --    - <Terje.Mathisen@hda.hydro.com>@ "almost all programming can be viewed as an exercise in caching"   ------------------------------  # Date: Sat, 13 Jul 2002 14:48:16 GMT + From: Anne & Lynn Wheeler <lynn@garlic.com> 6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)) Message-ID: <uy9cfu1jz.fsf@earthlink.net>   4 "Stephen Fuld" <s.fuld@PleaseRemove.att.net> writes:N > It has been far too long, but can't you use a Translate and Test instructionL > to do the equivalent (copy until a zero byte is found), at least for up to > 256 bytes per instruction?  + TRT just looked for the value ... no copy.    G tr/translate has a 256-byte table and takes an operand length up to 256 @ bytes ... it does a byte-by-byte replacement ... taking the byteC from the operand, using that value to index the table and replacing 4 the operand byte with the byte indexed in the table._ http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.96?DT=19970613131822   A translate&test has 256-byte table and an operand length up to 256 B bytes ... it tkaes an operand byte and indexes the table and stopsH if the table entry is non-zero. to search for just a zero has a 256-byte2 table that is all zeros except for the first byte._ http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.97?DT=19970613131822    neither did copies.   ! now for newer string instructions    move string _ http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.60?DT=19970613131822 f http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.3.28?SHELF=&DT=19970613131822   search string _ http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.70?DT=19970613131822 h http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.3.35.1?SHELF=&DT=19970613131822   --  H Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/    ------------------------------  % Date: Sat, 13 Jul 2002 12:18:52 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...), Message-ID: <3D3052EA.EC30BCDD@videotron.ca>   Anne & Lynn Wheeler wrote:
 > move string a > http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.60?DT=19970613131822    ##M The end of the second operand is indicated by an ending character in the last N byte position of the operand. The ending character to be used to determine theH end of the second operand is specified in bit positions 24-31 of generalN register 0. Bit positions 0-23 of general register 0 are reserved for possibleH future extensions and must contain all zeros; otherwise, a specification exception is recognized.  ##  % Ouch, I don't quite like the idea of  S 	MVST R1,R2   covertly also using R0 as source for the ending character definition.   N Also don't like the concept of a "CPU determined maximum number of bytes". YouN still have to loop that instruction while the condition code is "3" indicatingN that the operation stopped because the CPU defined maximum number of chars was, moved before the ending character was found.  I It also updates the contents of R1 to the address of the last byte moved.   J Seems to me that this instruction is very different from the basic 360/3701 architecture in terms of philosophy of arguments.    ------------------------------  # Date: Sat, 13 Jul 2002 16:44:41 GMT + From: Anne & Lynn Wheeler <lynn@garlic.com> 6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)) Message-ID: <uele7tw58.fsf@earthlink.net>   / JF Mezei <jfmezei.spamnot@videotron.ca> writes: L > Seems to me that this instruction is very different from the basic 360/3703 > architecture in terms of philosophy of arguments.   0 relatively recent "string" support instructions.   --  H Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/    ------------------------------   Date: 13 Jul 2002 17:27:38 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)0 Message-ID: <agpnua$n7k$1@pegasus.csx.cam.ac.uk>  - In article <3D2F4D15.863C42B5@hda.hydro.com>, 5 Terje Mathisen  <terje.mathisen@hda.hydro.com> wrote:  > F >Nick, I'll accept that it is possible to setup a system in such a wayH >that it is crucial to not even read any bytes past the terminating null >byte. > H >However, IMNSHO if you actually manage to shoot yourself in the foot in= >this way, you really do deserve to bleed all over the floor.   C If it were YOU doing it, then I agree.  But the problem is that you C are dealing with anything up to half a dozen organisations, each of = which has interpreted the various interface specifications in B different ways, and each of which claims that they are correct and- it is one of the others that needs to change.   D This is the reason that I don't see most of the problems that I talk? about in MY code - I write defensively.  I see them when a user C comes to me with a problem in his or (more often) third-party code.   H >On the platforms I know reasonably well, it is very hard to imagine anyH >method by which you could (even using third party DMA) modify a part ofF >a word that's already in cache, without the cache protocols detectingE >it. Even assuming you could do it, the driver responsible would then > >have to make sure that any already-cached lines were flushed.  A I think that it was PA-RISC where I was reading the specification ? of the 'do not cache this line' property and trying to work out B what, if anything, it specified about the effect one one processor? on an SMP sysytem doing it and not the others.  I could imagine ; reasonable interpretations varying from it being completely > unsupported up to it working transparently.  Now, if a libraryC implementor assumes one thing and the hardware implementor another, ' you have the problem I am referring to.   C The (modified) PA-RISC case where I did see the inconsistency ended ? up as being a simple user error, where he had written invalidly = aliased code, but my point is that it need not have been.  It A could have been one of the ambiguous parts of the C standard, and @ the problem could have been the user interpreting it one way and the compiler writer another.  A >What is important is to make sure that all accesses are properly G >aligned, and this can easily lead to significant slowdowns when str*() $ >is used on randomly aligned inputs.  " That is one important aspect, yes.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679    ------------------------------  # Date: Sat, 13 Jul 2002 17:37:27 GMT 2 From: "Stephen Fuld" <s.fuld@PleaseRemove.att.net>6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)G Message-ID: <rzZX8.99721$UT.6425978@bgtnsc05-news.ops.worldnet.att.net>   8 "Anne & Lynn Wheeler" <lynn@garlic.com> wrote in message# news:uy9cfu1jz.fsf@earthlink.net... 6 > "Stephen Fuld" <s.fuld@PleaseRemove.att.net> writes:D > > It has been far too long, but can't you use a Translate and Test instruction K > > to do the equivalent (copy until a zero byte is found), at least for up  to > > 256 bytes per instruction? > , > TRT just looked for the value ... no copy. > I > tr/translate has a 256-byte table and takes an operand length up to 256 B > bytes ... it does a byte-by-byte replacement ... taking the byteE > from the operand, using that value to index the table and replacing 6 > the operand byte with the byte indexed in the table. > L http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.9 6?DT=19970613131822  > C > translate&test has 256-byte table and an operand length up to 256 D > bytes ... it tkaes an operand byte and indexes the table and stopsJ > if the table entry is non-zero. to search for just a zero has a 256-byte4 > table that is all zeros except for the first byte. > L http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/7.5.9 7?DT=19970613131822  >  > neither did copies.    Thanks. I sit corrected!  :-)    --  - Stephen Fuld +    e-mail address disguised to prevent spam    ------------------------------  % Date: Sat, 13 Jul 2002 01:39:16 -0400 ( From: David Froble <davef@tsoft-inc.com> Subject: Re: DS10 shutting down , Message-ID: <3D2FBD04.3060906@tsoft-inc.com>  P Amusing.  But I have to wonder what ever happened to the old fashioned habit of F gathering some facts and observations before shooting off one's mouth?   Dave     Fred Kleinsorge wrote:  J > Not worth losing a job over.  But I don't think Bill uses VMS anyway, he4 > just writes about it from some sense of nostalgia. >  > G > Malcolm Dunnett wrote in message <0HYtq7yLyF3j@malvm7.mala.bc.ca.>...l > . >>In article <3D2DCCD8.45A56EA6@videotron.ca>,3 >>  JF Mezei <jfmezei.spamnot@videotron.ca> writes:. >> >>J >>>I think Bill Todd should be careful whenever he logs into a VMS system, >>>C > he > J >>>might get electrocuted by VMS :-) ( would it be a LIB$ELECTROCUTE_USER, >>>I > or a >  >>>SYS$ELECTROCUTE_USER ? )m >>> @ >>  I believe it's actually CIA$TERMINATE_WITH_EXTREME_PREJ  :-) >> >> >  >    ------------------------------  # Date: Sat, 13 Jul 2002 07:11:13 GMTr+ From: "Norbert Juffa" <juffa@earthlink.net> # Subject: Re: HP Itanium2 benchmarkstF Message-ID: <loQX8.18113$A43.1822962@newsread2.prod.itd.earthlink.net>  R "Greg Lindahl" <lindahl@pbm.com> wrote in message news:3d2f2a5f$1@news.meer.net...D > I was reading the HP Itanium2 performance whitepaper and noticed a > couple of interesting points:m >.H > In the lmbench section, page 7, they state "The zx1 hardware pre-fetchG > plays a significant role in achieving this score". If this were true,D  > then they broke the benchmark. >pH > On page 8, they say that the memory can be configured in several ways:D > direct attach, or with scalable memory expanders. Which way was itA > configured for the memory latency test? And what's the point of @ > stating the bandwidth between the memory and controller if the8 > front-side bus is incapable of taking advantage of it?  F I am not sure which white paper you are referring to. According to theJ following document, the latency of the zx1 in direct attach mode is 112ns. The expanders add another 25ns.   > http://www.hp.com/products1/itanium/chipset/analyst_report.pdf  G The stated bandwidth of the 2-way system is 8.5 GB/s, derived from foure@ PC2100-CL2 (DDR266A) channels, and stated bandwidth of the 4-wayG system is 12.8 GB/s. The description of the 4-way rx5670 server says it C also uses PC2100, but the 12.8 GB/s look more like they are derivednC from 8 channels of PC1600 to me (the zx1 4-way configuration on then? HP website shows eight memory channels, vs 4 channels for 2-wayC configuration).   A The description of the zx6000 workstation claims 78ns "open page"t memory latency.e  A http://www.hp.com/workstations/products/itanium/zx2000/specs.html-     > Finally, no STREAM numbers.   C Intel mentions STREAM bandwidth of 3.7 GB/s for their E8870 chipsetuH in their press release. The Intel press release site does not seem to be< reachable at this moment, so here is an alternative pointer:  B http://www.digitalproducer.com/2002/05_may/news/05_27/itanium2.htm  B The following presentation mentions 3.8 GB/s on STREAM Triad for a) pre-production zx1 based system (slide 3)   C http://www.emsl.pnl.gov:2080/capabs/mscf/hardware/hpcs2_results.pdfi    
 -- Norbert   ------------------------------  % Date: Sat, 13 Jul 2002 17:02:57 +0200 3 From: Terje Mathisen <terje.mathisen@hda.hydro.com>i# Subject: Re: HP Itanium2 benchmarksS- Message-ID: <3D304121.1C8AF571@hda.hydro.com>o   Greg Lindahl wrote:m > 5 > In article <usBIFBu3tckV@eisner.encompasserve.org>,t0 > Larry Kilgallen <Kilgallen@SpamCop.net> wrote:P > >In article <3d2f2a5f$1@news.meer.net>, lindahl@pbm.com (Greg Lindahl) writes:G > >> I was reading the HP Itanium2 performance whitepaper and noticed ai" > >> couple of interesting points: > >>K > >> In the lmbench section, page 7, they state "The zx1 hardware pre-fetchIJ > >> plays a significant role in achieving this score". If this were true,# > >> then they broke the benchmark.m > >oF > >But for anybody whose real program benefits, that is not a problem. > D > I am all for speeding up real programs. This benchmark is a memoryE > latency benchmark: it just happens to have been miswritten to use a G > constant negative stride. It would be wrong to report a better resulttG > because a processor has the ability to prefetch that; the right thingc0 > is to report that the benchmark is now broken.  5 If this is true, then the benchmark is indeed broken:   > It was written to measure the actual load-to-use latency of an* unpredictable pointer-chasing loop, right?  G Well, if hw prefetch detects a constant stride and starts to stream thel6 data, then obviously we need a less predictable setup.  G One obvious idea would be to require the pointer array to be a power oftF two in size, and then use all of it, except the zero'eth entry, with a5 simple LFSR random number generator to initialize it.v  E I know I have saved away a table of suitable maximum-length generator, polynomials.   Terjel   -- m  - <Terje.Mathisen@hda.hydro.com>@ "almost all programming can be viewed as an exercise in caching"   ------------------------------  % Date: Sat, 13 Jul 2002 10:38:54 -0400.' From: "Main, Kerry" <Kerry.Main@hp.com>l1 Subject: RE: Intel Wall Street Journal Itanium Ad T Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF40266083A@kaoexc01.americas.cpqcorp.net>  
 Re: WSJ ad ..r  A Well, my $.02 is that it may have been an ad submitted awhile ago  without much HP input.  D Anyway, fwiw, here is the pointer to the official press release from Intel:@ http://www.intel.com/pressroom/archive/releases/20020708comp.htm  D "The Itanium processor family is supported by more operating systemsC than any other high-end enterprise platform. Operating systems that H currently work with the Itanium 2 processor include Microsoft's Windows*@ Advanced Server, Limited Edition, and Windows XP 64-Bit Edition;H Hewlett-Packard's HP-UX*; and Linux from Caldera, MSC.Software, Red Hat,G SuSE and TurboLinux. In addition, Microsoft plans to introduce versionsnB of Windows.NET* Datacenter and Enterprise Server for the Itanium 2H processor, and HP is porting its OpenVMS* and Non Stop Kernel* operatingA systems to the Itanium processor family for future introduction."(   RegardsC  
 Kerry Main Senior Consultante Hewlett-Packard Canada! Consulting & Integration Services  Voice: 613-592-4660t Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----8 From: Alan E. Feldman [mailto:spamsink2001@yahoo.com]=20 Sent: July 12, 2002 10:58 PM To: Info-VAX@Mvb.Saic.Comt1 Subject: Re: Intel Wall Street Journal Itanium Adn    < susan_skonetski@hotmail.com (Sue Skonetski) wrote in message8 news:<857e9e41.0207121404.b885409@posting.google.com>...H > We do not have VMS on Intel YET.  And this was not even a plug for the   > boot contest.  >=20 > suer >=20 >=20= > wspencer@ap.nospam.org (Warren Spencer) wrote in message=20t3 > news:<924961471warrenspencer1977@216.168.3.30>...u6 > > terryshannon@attbi.com (Terry C. Shannon) wrote in# > > <XbmS8.1864$Uu2.240@sccrnsc03>:h > >=20 > > > @ > > >"Richard D. Piccard" <piccard@ohio.edu> wrote in message=20& > > >news:3D19AC04.B751DA4@ohio.edu... > > >>J > > >> The WSJ for Tuesday had a more-than-one-page ad for Itanium (-2,=20 > > >> as I  >  recall) that listedH > > >> all sorts of software being developed for it, including in the=20
 > > >> top3                              ^^^^^^^^^^^^^^^^^^^^^^o  7 Doesn't "porting to" count as "being developed for"?=20i     >  section, markedI > > >> operating systems, three flavors of Windows, HP-UX, two flavors=20t > > >> of Linux,    E Are all of the above OSes on Itanium yet? Just asking; I don't reallyn know.o     >  but > > >>" > > >> **** NO LISTING OF VMS **** > > >>C > > >> This is perhaps not surprising, but is certainly outrageous.t > > >sH > > >Yep. And the NonStop community no doubt is equally miffed by the=20H > > >lack of mention of NSK on Itanium. Kinda dumb on Intel's part to=20J > > >omit two ENTERPRISE-CLASS operating systems from its list. Unless,=20E > > >of course, folks up Redmond way had "input" to the collateral=20  > > >generation process. ;-}    : This is the first I've heard of a non-VMS OS being miffed!    < > > And there may be a reason for that, other that sloppy=20 > > detail-management.F > > Has anyone seen the errata sheet for the I-2 yet?  It might not be good=20o2 > > enough yet for high-availability environments.    0 But the key phrase was "being developed for".=20     Disclaimer: JMHO Alan E. Feldman  afeldman gfigroup com    ------------------------------  % Date: Sat, 13 Jul 2002 12:23:54 -0400l- From: JF Mezei <jfmezei.spamnot@videotron.ca> 1 Subject: Re: Intel Wall Street Journal Itanium Adh, Message-ID: <3D305418.7B8CD100@videotron.ca>   "Main, Kerry" wrote:C > Well, my $.02 is that it may have been an ad submitted awhile agop > without much HP input.  N If Compaq was sinsere about the port of VMS to IA64, then Intel has absolutelyL no excuse since the port of VMS and NSK and at the time Tru64 were announcedN in June of last year. I very much doubt that any ad appearing today would have" been prepared earlier than than.    K Tru64 was cancelled in early september when the Carly and Curly wedding wascL announced. So if an ad was prepared between June and September of last year, it should have included Tru64. t  J Of course, we know know that since Carly and Culry were dating even beforeJ June 25, that it was most likely that when the Alpha murder was announced,M Curly knew full well that Tru64 would not get ported to IA64 but still had to8N pretend it would otherwise folks would have wondered why Compaq wasn't portingK Tru64.  That in itself is one hell of a good reason not to Trust Compaq/HP.-   ------------------------------  % Date: Sat, 13 Jul 2002 13:13:21 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> 1 Subject: RE: Intel Wall Street Journal Itanium Ad-T Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF40266083B@kaoexc01.americas.cpqcorp.net>   JF  -o  B Mmmm.. By "awhile" ago, I meant before the merger was complete.=20  D Remember HP/Compaq clean room folks could not talk to anyone outsideH about what they were doing or what the planned directions were until the merger was complete.   Regards1  
 Kerry Main Senior Consultant  Hewlett-Packard Canada! Consulting & Integration Servicesy Voice: 613-592-4660e Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----7 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]=20r Sent: July 13, 2002 12:24 PM To: Info-VAX@Mvb.Saic.Com 1 Subject: Re: Intel Wall Street Journal Itanium Adl     "Main, Kerry" wrote:F > Well, my $.02 is that it may have been an ad submitted awhile ago=20 > without much HP input.  C If Compaq was sinsere about the port of VMS to IA64, then Intel has H absolutely no excuse since the port of VMS and NSK and at the time Tru64B were announced in June of last year. I very much doubt that any ad? appearing today would have been prepared earlier than than. =20f  G Tru64 was cancelled in early september when the Carly and Curly weddingnE was announced. So if an ad was prepared between June and September ofe, last year, it should have included Tru64.=20  C Of course, we know know that since Carly and Culry were dating evenoF before June 25, that it was most likely that when the Alpha murder wasG announced, Curly knew full well that Tru64 would not get ported to IA64jE but still had to pretend it would otherwise folks would have wonderedwF why Compaq wasn't porting Tru64.  That in itself is one hell of a good reason not to Trust Compaq/HP.   ------------------------------  % Date: Sat, 13 Jul 2002 00:55:49 -0400f( From: David Froble <davef@tsoft-inc.com>* Subject: Re: Itanium II Another Shoe Drops, Message-ID: <3D2FB2D5.2000102@tsoft-inc.com>   JF Mezei wrote:m   > John Smith wrote:- >  > J >>That's true. But it will become a relatively low-volume CPU family, justL >>like Alpha is/was, but perhaps without the design/processing advantages of >>Alpha. >> > J > I think that it is a given that IA64 has already been relegated to a lowP > volume high-cost chip to be used for serious/high margin applications. So yes,P > it could be seen as a direct reoplacement of Alpha. This is especially true ifL > only Intel produces chips running that architecture. But alpha was able toK > survive for a very long time in such a state and could have survived mucheF > longer had it not been owned by a company slave to Intel/microsoft.     N Recently there was the announcement of I-II and the release of some benchmark G numbers.  Rob was ready to serve crow.  Others acted like that changed o' everything.  Well, nothing has changed.   O DEC meant quality.  Intel means volumn.  Everything is in those two statements.   O Alpha has survived because there was plenty of software already running on it. oO There really isn't any significant software running on I-II.  Regardless, with  O the VMS port to I-II, significant customers should come along with the port to l? change the equation a bit with regard to applications and such.n  N Still nothing has changed.  Intel will not pursue such a niche market.  Their M goal was to be the volumn 64 bit CPU.  It ain't gonna happen.  Microsoft may rL have endorsed Hammer, not sure if that was ever substantiated.  But, Hammer O allows an easy migration to 64 bits, at the user's chosen pace, or not at all, fK and still is a viable CPU.  It will get the volumn.  Intel cannot let this hM happen, and will compete vigorously, but not with IA-64.  When that happens, tT IA-64 loses any chance for volumn, and without volumn, Intel will not be interested.  K So, while the recent announcement of I-II produced much noise, revising of  O opinions, servings of crow feathers, and such, it's not anything relavent, and e will change nothing.    M Note that the above is just how I see things, and unlike some I'm willing to aO acknowledge that things may go much different.  I'm sure not going to feel bad yE if IA-64 is successful, since it's currently the only future for VMS.a   Dave   ------------------------------  % Date: Sat, 13 Jul 2002 02:35:06 -0400r- From: JF Mezei <jfmezei.spamnot@videotron.ca>e* Subject: Re: Itanium II Another Shoe Drops, Message-ID: <3D2FCA02.FDECCDF1@videotron.ca>   David Froble wrote:iN > happen, and will compete vigorously, but not with IA-64.  When that happens,W > IA-64 loses any chance for volumn, and without volumn, Intel will not be interested.\t  N But as long as IA64 makes some money for intel (or has potential to break evenF soon enough), I think that Intel will continue to produce it, and alsoL consider that HP may become the owner of IA64 and just pay Intel to continue development of it.  L Just because IA64 doesn't become commodity doesn't mean that Intel will stopN producing it. Also, consider that with NSK dumping MIPS, will MIPS continue to5 generate enough volume to continue being developped ?   M Consider that IA64 will get most of the HP-UX and NSK customers. It will alsoe& get part of Tru64 and VMS customers.    J Now, if the loss of NSK from MIPS becomes a fatal blow to MIPS, then otherM MIPS usres will have to look at a new platform, and it is likely that some ofn them will choose IA64.  L If IBM chooses not to make Power widely available, wanting that chip to onlyN give IBM the edge, then system makers will have to choose between IA64, Hammer and Sparc. n  L If Intel is artificially pricing IA64 high to differentiate it from the 8086H market (just like DEC articifially priced Alpha systems so they wouldn'tM compete in the low end occupied by 8086 systems), then Intel can very quickly1M play its wildcard and start to offer commodity-priced IA64s which would start5. a mass migration from 8086 to Ia64 for Wintel.   ------------------------------   Date: 13 Jul 2002 08:14:39 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)* Subject: Re: Itanium II Another Shoe Drops0 Message-ID: <agonhf$1i6$1@pegasus.csx.cam.ac.uk>  , In article <3D2F72E2.5E6CD40F@videotron.ca>,/ JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:i >"Terry C. Shannon" wrote:D >> Yep. Without the blessing of Dell, IA64 is dead. Long live SPARC! >-L >Dell hasn't said it won't produce IA64 stuff. It just said that it wouldn'tN >produce some right away. Also, as a high end chip with high costs, the market< >niche where IA64 would works doesn't match what Dell wants. > M >What this means is that IA64 may not become "commodity" chip, but it doesn'ti> >mean it will fail just because Dell isn't selling IA64 boxes.  D I read Terry Shannon's posting as at least partly irony.  Dell isn't@ critical, but its public lack of support is noteworthy.  What isA the case is that Intel's E8870 and Bandera will fail unless Intel.B can get some high-volume OEMs to take them up.  And, if they fail,4 will Intel continue to push the IA-64 as THE future?  ? Currently, we are all guessing, but what happens this autumn isnB critical to the future of IA-64.  By the new year, we shall have a. pretty good idea of how things are developing.  @ But, to be radical, HP could perfectly well be the new Dell.  If? I were Fiorina, I would spin off the HP and Compaq PC divisions-= as a new, wholly owned company.  This would both simplify the = merger, and allow that company to use Dell's model to compete:A with Dell head-on.  And, if it flopped, it wouldn't interfere toor badly with the main company.  > Or IBM might reenter the fray as a major low-end PC vendor :-)     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679    ------------------------------    Date: 13 Jul 2002 06:59:36 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)e* Subject: Re: Itanium II Another Shoe Drops3 Message-ID: <9gw03BB8a0+G@eisner.encompasserve.org>y  W In article <3D2FB2D5.2000102@tsoft-inc.com>, David Froble <davef@tsoft-inc.com> writes:t  Q > DEC meant quality.  Intel means volumn.  Everything is in those two statements.b  K Not quite everything.  The missing part is that Intel is still in business.o   ------------------------------    Date: 13 Jul 2002 05:30:32 -0700( From: bob@instantwhip.com (Bob Ceculski)* Subject: Re: Itanium II Another Shoe Drops= Message-ID: <d7791aa1.0207130430.31e0ef1b@posting.google.com>   a JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3D2FCA02.FDECCDF1@videotron.ca>...aO > Consider that IA64 will get most of the HP-UX and NSK customers. It will alsoa' > get part of Tru64 and VMS customers. 0  1 part of VMS customers?  Try all of VMS customers!   m > L > Now, if the loss of NSK from MIPS becomes a fatal blow to MIPS, then otherO > MIPS usres will have to look at a new platform, and it is likely that some oft > them will choose IA64. > N > If IBM chooses not to make Power widely available, wanting that chip to onlyP > give IBM the edge, then system makers will have to choose between IA64, Hammer
 > and Sparc. d >   > once the Alpha goodies start making their way into IA64, which= now is starting to look like a decent chip, it will rule overi/ power, and hammer for the high end?  Forget it!t   ------------------------------  + Date: Sat, 13 Jul 2002 13:09:39 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk* Subject: Re: Itanium II Another Shoe Drops+ Message-ID: <agp8qj$ek8$1@aquila.mdx.ac.uk>o  h In article <d7791aa1.0207130430.31e0ef1b@posting.google.com>, bob@instantwhip.com (Bob Ceculski) writes:b >JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3D2FCA02.FDECCDF1@videotron.ca>...P >> Consider that IA64 will get most of the HP-UX and NSK customers. It will also( >> get part of Tru64 and VMS customers.  >e2 >part of VMS customers?  Try all of VMS customers! > J No part of VMS customers. Some will defect to other OSs and chipsets. Some1 will stick with Alpha for the foreseeable future.H   >> uM >> Now, if the loss of NSK from MIPS becomes a fatal blow to MIPS, then other P >> MIPS usres will have to look at a new platform, and it is likely that some of >> them will choose IA64.l >> aO >> If IBM chooses not to make Power widely available, wanting that chip to only Q >> give IBM the edge, then system makers will have to choose between IA64, Hammer  >> and Sparc.  >> p >a? >once the Alpha goodies start making their way into IA64, whichu> >now is starting to look like a decent chip, it will rule over0 >power, and hammer for the high end?  Forget it!  J What Alpha goodies ? Or to be more specific what Alpha goodies that can beH implemented on IA64 which are not already being implemented in Power or  Hammer ?  K Without SMT which can't easily be added to IA64 I don't really see a lot oft Alpha goodies. d  
 David Webb VMS and Unix team leader CCSS Middlesex University a   ------------------------------  # Date: Sat, 13 Jul 2002 14:29:03 GMTa# From: "John Smith" <a@nonymous.com>u* Subject: Re: Itanium II Another Shoe DropsF Message-ID: <POWX8.3156$WsS.1665@news01.bloor.is.net.cable.rogers.com>  5 "David Froble" <davef@tsoft-inc.com> wrote in messageo& news:3D2FB2D5.2000102@tsoft-inc.com... >y >tK > Note that the above is just how I see things, and unlike some I'm willing  toL > acknowledge that things may go much different.  I'm sure not going to feel bad G > if IA-64 is successful, since it's currently the only future for VMS.8  K Without a re-examination of the situation internally within HP (and for alltJ we know, that may be happening), the fact that I2 et al. is where VMS willI reside in the future. Whether VMS with grow its installed base or achieveaF some kind of renaissance remains to be seen, and that is a function of( marketing, not so much the chip it's on.  G If I were inside HP and had access to ALL the information regarding theeK details of the agreements between Compaq/HP and Intel, I might be persuadedoG that killing Alpha was a good idea. But whether it's Alpha, I2, or someiG future chip, without advertising and marketing, the VMS market will notrI grow. And that my friends, has implications for your/my job, your/my pay,d' your/my company, in one way or another.u   ------------------------------  # Date: Sat, 13 Jul 2002 14:45:22 GMT # From: "John Smith" <a@nonymous.com>n* Subject: Re: Itanium II Another Shoe DropsE Message-ID: <62XX8.3171$WsS.444@news01.bloor.is.net.cable.rogers.com>   5 "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in messages* news:agonhf$1i6$1@pegasus.csx.cam.ac.uk... >CB > But, to be radical, HP could perfectly well be the new Dell.  IfA > I were Fiorina, I would spin off the HP and Compaq PC divisions4? > as a new, wholly owned company.  This would both simplify them? > merger, and allow that company to use Dell's model to compete1C > with Dell head-on.  And, if it flopped, it wouldn't interfere too  > badly with the main company.  F That would be a good solution but it requires a considerable effort toB revamp the manufacturing process to one that is almost exclusively 'build-to-order'.h  K However, I would think that the largest impediment to this is the 'channel' F and how it will react to what would amount to the elimination of theirH livelihood. Compaq's retail distribution of the products in the PC spaceI that made any money (servers) was done primarily (but not solely) via the H channel. Compaq/HP knows far less about those server customers than DellH knows about theirs (the difference between the direct and indirect salesI model). It would be a real footrace between a spun-off HP PC division and ' Dell, and I suspect that Dell will win.g  L I thinkthe spun-off division really only makes sense to HP if it is sold viaC an IPO (burn your bridges?) rather than keeping it as a wholly-owndlK subsidiary. The profit margins on PC's will never be very good - it's a rawrK commodity market, running OS'es that they don't own (Windows, Linux). CarlyoD paid a pretty hefty premium for Compaq at a time when the market wasC somewhat more optimistic about prospects. The PC division of CompaqsJ accounted for about 1/2 the sales (if memory serves). A HP PC division IPOJ would have to raise a considerable amount of money for Carly to break-evenI on her investment. In market conditions as they exist today, or even overNG the next 6-8 months (as a guess), HP would not be able to come close toe breaking even.   ------------------------------  % Date: Sat, 13 Jul 2002 12:03:00 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>i* Subject: Re: Itanium II Another Shoe Drops, Message-ID: <3D304F34.7E3C4C8E@videotron.ca>   Bob Ceculski wrote:oQ > > Consider that IA64 will get most of the HP-UX and NSK customers. It will alsot( > > get part of Tru64 and VMS customers. > 3 > part of VMS customers?  Try all of VMS customers!c  L At this point in time, it is way too early to tell what will happen with the VMS marketplace. a  K Lets assume for a moment that HP intends to scale VMS down over the next 10 G years. If this becomes apparent before VMS on IA64 becomes commercially.N viable, then it is more likely that the remaining VMS customers will just stayN on their Alpha systems as long as possible and have migration plans to anotherM vendor over the medium/long term. The Alpha murder last year probably sparkedc quite a few such plans.   L Also consider the VAX installed base. With HP having said absolutely nothingN about VMS on VAX, and whether new versions will appear on VAX,  it is possibleM that HP intends to stop VMS on VAX ASAP so that it can start the 5 year timernN for support. Many of those customers would then be forced with a migration andP they may choose to go to a system whose future is not constantly be in question.   ------------------------------   Date: 13 Jul 2002 17:41:35 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)* Subject: Re: Itanium II Another Shoe Drops0 Message-ID: <agpoof$o1c$1@pegasus.csx.cam.ac.uk>  E In article <62XX8.3171$WsS.444@news01.bloor.is.net.cable.rogers.com>,e" John Smith <a@nonymous.com> wrote: >T6 >"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message+ >news:agonhf$1i6$1@pegasus.csx.cam.ac.uk...M >>C >> But, to be radical, HP could perfectly well be the new Dell.  IfIB >> I were Fiorina, I would spin off the HP and Compaq PC divisions@ >> as a new, wholly owned company.  This would both simplify the@ >> merger, and allow that company to use Dell's model to competeD >> with Dell head-on.  And, if it flopped, it wouldn't interfere too >> badly with the main company.i > G >That would be a good solution but it requires a considerable effort tonC >revamp the manufacturing process to one that is almost exclusively  >'build-to-order'. >aL >However, I would think that the largest impediment to this is the 'channel'G >and how it will react to what would amount to the elimination of their2 >livelihood. ... >oM >I thinkthe spun-off division really only makes sense to HP if it is sold viaiD >an IPO (burn your bridges?) rather than keeping it as a wholly-ownd >subsidiary. ...  B Oh, I agree with your points.  The advantages would be more to get@ rid of a major distraction.  HP/Compaq would then concentrate onA the 'PC sales' that are done by the hundred and include full 24x7t> support, and similar relatively high margin markets.  This is,& after all, the approach that IBM took.  B What I REALLY can't see is HP/Compaq as currently organised having1 a hope of competing with Dell in the bulk market.e     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679w   ------------------------------  + Date: Fri, 12 Jul 2002 08:02:54 +0000 (UTC) A From: "Rupert Pigott" <dark.try-eating-this.b00ng@btinternet.com>  Subject: Re: McKinley Cometh... / Message-ID: <agm2fd$hpb$1@venus.btinternet.com>t  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3D2E5C95.64BCE402@videotron.ca... > Rupert Pigott wrote:0 > > http://www.apple.com/xserve/performance.html@ > > It's also complete shite because they don't compare the sameG > > codebases and they don't provide the source so you can verify this.  >aH > That is a fair criticism. But doesn't the apple comparison represent a moreI > "real world" approach. You take the application available on platform 1g andtK > compare it with whatever application is available on platform 2 to do thes same > work ?  @ The problem you're having here is that you're bitching about theA SPEC CPU benchmark suite not being very good at measuring I/O. IfeA you think about it that is a *good* thing for a CPU benchmark. As B I've already said SPEC does offer other suites which are targetted. at specific applications which do include I/O.  A As it happens I do prefer the SPEC approach anyway because a fullIA blown application has all sorts of cruft which can get in the wayr> of a fair comparison. If you identify what you want to measure< and take the core tasks from your applications and benchmark@ those you will have less noise in the results. This is what SPEC seems to aim for.e  D > What I find significant is that Apple is starting to push its Unix servers.  A I think that was inevitable, the current MacOS X thing seems likefA the reincarnation of NeXTStep to me. Also, Apple have been makinguB computers which are pricier than UNIX workstations for a long time. now, check out the list prices for Mac II's...   Cheers,h Rupert   ------------------------------  & Date: 13 Jul 2002 16:22:39 +0100 (BST)4 From: Thomas Womack <twomack@chiark.greenend.org.uk> Subject: Re: McKinley Cometh...a3 Message-ID: <VFb*Vfbtp@news.chiark.greenend.org.uk>e  - In article <agnihr$4o8@web.eng.baileynm.com>,t' Peter da Silva <peter@abbnm.com> wrote:h8 >In article <XWDW8.13988$K_4.342777@twister1.libero.it>,( >Alberto <uapalbertobu@libero.it> wrote:L >> Outsourcing ? bad job if porpouse is frequency scaling.....Sun know that. >lH >It seemed to work for Alpha, until Compaq started putting the brakes on9 >around, oh, 2000. And it seems to be working for nVidia.g  E Haven't nVidia nearly always been limited in frequency by the fastestoF available boutique DDR memory that they can stick on the other side ofC a gratuitous four-bank crossbar controller? They're managing to getiD less than 400MHz out of a 0.15u process, albeit for more transistors% than you can easily shake a stick it.e  > I don't know whether the word "pipeline" has the same value inC "graphics pipeline" and "20-stage pipelined OOO processor"; I would-= have thought you could divide the render-a-scene process into E virtually as many stages as desired, if you want huge but meaninglessp< MHz numbers, were it not that most operations require memoryF intervention.  I'll be interested to see what happens with the DirectXA 9 chips, whose selling-point seems to be that the pixels are fullhA float[4] objects all the way through to the frame-buffer; I don'tyF think RAM is fast enough to survive easily a gratuitous quadrupling of pixel size.b  ? Transmeta suffered very greatly from TSMC being unable to scaletC frequency adequately; I don't think they've reached 1GHz *yet*, andS? I think they've lost lots of custom to Mobile P3 chips built on  Intel 0.13u lines the while.   Tomt   ------------------------------  % Date: Sat, 13 Jul 2002 01:31:21 -0400u( From: David Froble <davef@tsoft-inc.com>4 Subject: Re: McKinley tops SpecFP AND SpecInt charts* Message-ID: <3D2FBB29.80206@tsoft-inc.com>   JF Mezei wrote:    > John Smith wrote:o > K >>If indeed HP is taking a far more serious and pro-active approach to VMS,tK >>what on earth is wrong about making a top-level statement to that effect?4 >> >  > possible scenario: > M > top-level still intends to ditch VMS, or keep it low profile enough that itu( > evaporates out of existence by itself. > O > lower level grunts, realising what HP intends to do try very hard to find anynM > possible way to release marketing about VMS without upper management reallycP > taking notice, in an effort to maintain the sales and prevent its evaporation. > M > The information about the 400k systems, even if that is totally useless andcM > perhaps invalid information, is still very good for VMS because it makes iteM > much harder for upper management to announce the death of VMS to the press. I > And now, Sue has leaked that VMS has had double digit growth, but won't 
 > confirm it.s > I > As long as the grunts at the low levels can show positive signs for VMSoP > (profits, growth, new software), it makes it much harder for top management toO > implement their long term strategies. If, in the face of the Alpha murder, HP'N > merger, Stallard memo and lack of a real HP branded strategy for VMS ("we'llP > continue Compaq's plan of record" translates to "we don't know what to do withM > VMS, so for now, we continue whatever Compaq had been doing, even though wen2 > doN't have a clue what it was Compaq was doing") > N > Lets not forget that VMS was put in the "legacy" department along with Alpha. > and Tru64, neither of which have any future. > K > So I am not sure whether the VMS folks see a bigger baattle in convincingr0 > upper managenment, or in convincing customers. >     P At some time one either has to be a bit objective, or just admit that they know J all that's required, and please don't confuse them with anything relavent.  P Note that nobody could be more upset than I have been over many past actions in O the handling of VMS and Alpha.  Still, I see a difference, a small difference, rO and will recognize such.  I'm still skeptical.  That's only prudent.  I'd like ,P to see more, even much more.  That still may happen.  And things could occur as % before, raise hopes, then smash them.e  N What I cannot see, is anything constructive in trying to downplay and dismiss Q positive events related to VMS.  Such activity is destructive, and doesn't serve mM any useful purpose.  It could actually suppress any future positive actions. -3 I'm getting more than a little disgusted with such.   O JF, and a few others, if you care about VMS, why not applaud positive actions, eO and campaign for other actions that we'd like to see, but haven't occured yet? 2Q If you don't care about VMS, then why are you wasting your time, and mine, here? nF   Yeah, continue to keep HP honest, but be a bit more honest yourself.   Dave   ------------------------------  % Date: Sat, 13 Jul 2002 02:56:42 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>24 Subject: Re: McKinley tops SpecFP AND SpecInt charts, Message-ID: <3D2FCF10.A9147F77@videotron.ca>   David Froble wrote:1P > JF, and a few others, if you care about VMS, why not applaud positive actions,P > and campaign for other actions that we'd like to see, but haven't occured yet?  J Because a change was not confirmed by upper management, I think it is veryN likely that the recent efforts are the result of the low level people mounting> a quiet internal "war" to try to counter high-level management@ strategies/mentalities that would see VMS wither away over time.  J In other words, as long as high level HP folks do not convince me directlyJ that VMS will be grown/expanded, I will continue to see a need for the lowN level people to fight to keep VMS alive and in such a state, I feel that it isL better to keep the pressure on HP than to just play dead and make high level< management feel happy and comfortable with their strategies.  F If the low level people need to constantly fight to counter high-levelG decisions/policies, then low level people must also constantly be given E ammunition. If customers are happy and do not comment, then low leveleB management have far less ammunition to bring to upper management.   L Considering that high level people do not seem to have any expectations thatI VMS can grow and acquire new customers, then the only real ammunition low2J level people can have is the threat of the loss of serious revenus/profits	 from VMS.s  M While it is good to mention to Sue that we notice some of the press releases,cJ it is not clear whether those are the result of Sue,s efforts despite HP'sV wishes to silence VMS, or whether those are HP efforts to give VMS greater visibility.   ------------------------------    Date: 13 Jul 2002 05:41:09 -0700( From: bob@instantwhip.com (Bob Ceculski)4 Subject: Re: McKinley tops SpecFP AND SpecInt charts= Message-ID: <d7791aa1.0207130441.6df5ba6d@posting.google.com>o  a JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3D2FCF10.A9147F77@videotron.ca>...s > David Froble wrote:tR > > JF, and a few others, if you care about VMS, why not applaud positive actions,R > > and campaign for other actions that we'd like to see, but haven't occured yet? > L > Because a change was not confirmed by upper management, I think it is veryP > likely that the recent efforts are the result of the low level people mounting@ > a quiet internal "war" to try to counter high-level managementB > strategies/mentalities that would see VMS wither away over time. > L > In other words, as long as high level HP folks do not convince me directlyL > that VMS will be grown/expanded, I will continue to see a need for the lowP > level people to fight to keep VMS alive and in such a state, I feel that it isN > better to keep the pressure on HP than to just play dead and make high level> > management feel happy and comfortable with their strategies. > H > If the low level people need to constantly fight to counter high-levelI > decisions/policies, then low level people must also constantly be givenmG > ammunition. If customers are happy and do not comment, then low levellD > management have far less ammunition to bring to upper management.  > N > Considering that high level people do not seem to have any expectations thatK > VMS can grow and acquire new customers, then the only real ammunition lowtL > level people can have is the threat of the loss of serious revenus/profits > from VMS.e >   E I think you are underestimating Carly ... she is a former MIT studentIE which many ex-DEC techs were, and she understands the DEC superiorityeF and Ken Olson philosophy, unlike Capellas/Palmer bean counters ... she may just suprise you!w   ------------------------------  # Date: Sat, 13 Jul 2002 14:18:02 GMTt# From: "John Smith" <a@nonymous.com>a4 Subject: Re: McKinley tops SpecFP AND SpecInt chartsF Message-ID: <uEWX8.3147$WsS.1537@news01.bloor.is.net.cable.rogers.com>  5 "Bob Ceculski" <bob@instantwhip.com> wrote in message 7 news:d7791aa1.0207130441.6df5ba6d@posting.google.com...m > G > I think you are underestimating Carly ... she is a former MIT student4G > which many ex-DEC techs were, and she understands the DEC superiority.H > and Ken Olson philosophy, unlike Capellas/Palmer bean counters ... she > may just suprise you!c  K Bob, in the end you may well be correct. However you cannot make a sweepingeJ statement that simply because somebody went to MIT has the same philosophyK of others who also went to MIT, nor that she understands 'DEC superiority'.oJ That kind of statement simply hold no water.  Beta is superior to VHS, butF VHS owns the market - go to Best Buy and try to get a Beta VCR. If youJ really want one, you'll probably have to go groveling to Sony and ask themH to search their warehouse for one. Evern Sony doesn't advertise them any" longer. What is this analogous to?   ------------------------------  % Date: Sat, 13 Jul 2002 11:34:04 -0400t2 From: rdeininger@mindspring.com (Robert Deininger)4 Subject: Re: McKinley tops SpecFP AND SpecInt chartsJ Message-ID: <rdeininger-1307021134040001@1cust26.tnt2.nashua.nh.da.uu.net>  5 In article <3D2F0879.4DC6F820@videotron.ca>, JF Mezein% <jfmezei.spamnot@videotron.ca> wrote:n    M >Lets not forget that VMS was put in the "legacy" department along with Alphao- >and Tru64, neither of which have any future.t  D To be more accurate, you should say that VMS was already in the sameF organization as Alpha and Tru64.  VMS wasn't "put" there by HP, it was left there.l  G Feel free to continue to seek the most malignant interpretation you cani for every event.   ------------------------------  % Date: Sat, 13 Jul 2002 12:05:36 -0400d- From: JF Mezei <jfmezei.spamnot@videotron.ca>e4 Subject: Re: McKinley tops SpecFP AND SpecInt charts+ Message-ID: <3D304FD0.80125BB@videotron.ca>o   Bob Ceculski wrote:iG > I think you are underestimating Carly ... she is a former MIT studenteG > which many ex-DEC techs were, and she understands the DEC superioritynH > and Ken Olson philosophy, unlike Capellas/Palmer bean counters ... she > may just suprise you!t  K If that is the case, why did she appars to be so "compatible" in phisosophy,M with Curly, Winkler and others who believe that Windows will rule the world ?uM If sufficient number of bad Compaq people made it to the HP hiearchy, it willr0 be very hard for Carly to avoid their influence.   ------------------------------  % Date: Sat, 13 Jul 2002 12:29:12 -0400a- From: JF Mezei <jfmezei.spamnot@videotron.ca>M4 Subject: Re: McKinley tops SpecFP AND SpecInt charts, Message-ID: <3D305556.4A78FD08@videotron.ca>   Robert Deininger wrote:aF > To be more accurate, you should say that VMS was already in the sameH > organization as Alpha and Tru64.  VMS wasn't "put" there by HP, it was
 > left there.a  N Again, another "we will continue what Compaq had begun" mentality.  Problem is4 that what Compaq had begun wasn't very good for VMS.  K You will note that NSK got its own division. It used to be part of the samerN group as VMS and Tru64 at Compaq.  I would have felt much more confident aboutM VMS if HP had announced that later on, VMS would be moved to another divisionh once it runs on Itanium.   ------------------------------  + Date: Sat, 13 Jul 2002 09:49:56 +0000 (UTC)c From: david20@alpha1.mdx.ac.uk7 Subject: Re: OpenSSL and certificates concept questionsh+ Message-ID: <agot44$atc$1@aquila.mdx.ac.uk>s  f In article <cc5619f2.0207121235.74601f9c@posting.google.com>, jordan@ccs4vms.com (Rich Jordan) writes:] >Rich Jordan <duodec@speakeasy.net> wrote in message news:<3D2E5D27.1020106@speakeasy.net>...D >> Rick Barry wrote:8 >> >>"Rich Jordan" <jordan@ccs4vms.com> wrote in message< >> >>news:cc5619f2.0207101500.14cde0fe@posting.google.com... >> >>o >> m >Rick,@ >     we've got the OpenSSL s_client program working to the testG >server, still having problems getting the actual locally compiled codeoC >(based on the sample code) to run due to problems getting the PRNGsD >(random number generator) seeded.  We can do that with the s_clientE >app with the -rand option, but still looking for a way to get SSL too@ >read an environment variable (symbol or logical?) to locate theG >'random seed file' we provided to get s_client working; changes to theTC >openssl.cnf file also don't seem to make a difference.  Time to donD >some source delving I guess.  Thanks for the pointers and the info;E >it'll take time to plow through all this but at least we have a pathd >now.o >iF >     How busy are the OpenSSL mailing lists?  I'm not looking forwardA >to adding another busy one to my daily email platter but will ifv >needed. >o >Riche  I Don't know if this will help but in order to generate certificates on VMSeN you need to seed the random number generator - the recommended procedure is :-    *  1) To do a SHOW SYSTEM/FULL into a file.   B              $ SHOW SYSTEM/FULL/OUTPUT=SSLROOT:[PRIVATE]RANDFILE.;
             N  2) Define the logical RANDFILE to point to where the RANDFILE.; file is kept.    F              $ DEFINE/SYSTEM/EXEC RANDFILE SSLROOT:[PRIVATE]RANDFILE.;	          s  G However you also in this instance need to make some alterations to the t> openssl.cnf file which is used when generating certificates :-      4  3)  Edit the OPENSSL.CNF file and modify the line.   F              dir     = sys\$disk:[.demoCA    #Where everything is kept
             <      to point to SSLROOT:[000000] directory tree like this.   F              dir     = SSLROOT:[000000       #Where everything is kept
             .      Also modify the line for the RANDFILE.;.   I              RANDFILE = $dir.private].rand   # private random number filep
                   to look like...    L              RANDFILE = $dir.private]RANDFILE.; # private random number file
             *      and just completely remove the line.   .              RANDFILE        = $ENV::HOME/.rnd
                   at the top of the file. u     This is documented on :-  C http://www.ourservers.net/openvms_ports/openssl/openssl3.html#ss3.1e    
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------    Date: 13 Jul 2002 06:58:25 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)b7 Subject: Re: OpenSSL and certificates concept questions 3 Message-ID: <0vCI97g3occD@eisner.encompasserve.org>r  W In article <3D2FB543.9020500@speakeasy.net>, Rich Jordan <duodec@speakeasy.net> writes:a  6 > Who designed the x.509 certs and the SSL API anyway?  D I don't know about the SSL API, but the x.509 certificates are quiteD nice to work with.  The trick is that you should not try to code forE them by hand.  Use an ASN.1 tool that generates code in your favoriteu programming language.    ------------------------------  # Date: Sat, 13 Jul 2002 07:34:57 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")J Subject: Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!)8 Message-ID: <00A10D8D.944452F2@SSRL04.SLAC.STANFORD.EDU>  O In article <01IX8.29945$WJf1.15874@news01.bloor.is.net.cable.rogers.com>, "Johnn Smith" <a@nonymous.com> writes:c   >hK >The more appropriate question to ask is, will a hacker go after a platformIB >whose market share continues to decline or will they be like mostM >opportunists and hack where the action is and the opportunity to affect mored >systems is open to them?n >   N (I can no longer detect any stylistic difference between "John Smith" and JF, = incidentally; I used to be able to tell their writing apart.)o  M Anyway, hackers don't care at all about whether the market share continues toaI decline.  The ones who are in it to learn about stuff want to learn abouteK interesting systems; the ones who are in it to get attention want to defaceqL highly-visible web sites, and if CNN/ABC/Disney/whitehouse.gov were running M on VMS, they'd learn about VMS.  The ones who are just morons running scriptsaM they wouldn't have had the wit to write will blindly attack VMS systems under 4 the assumption that they're Unix or Windows systems.  7 Now, virus writers like to go for the popular platform.b   -- Alane    O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056vM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210oO ===============================================================================r   ------------------------------  + Date: Sat, 13 Jul 2002 09:34:52 +0000 (UTC)  From: david20@alpha1.mdx.ac.ukJ Subject: Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!)+ Message-ID: <agos7r$ahd$1@aquila.mdx.ac.uk>   q In article <20020712191434.10915.qmail@web20204.mail.yahoo.com>, Fabio Cardoso <fabiopenvms@yahoo.com.br> writes:  >At the end... >r5 >I asked here a few days ago, about what do you think*. >about a hacker with an Itanium server at home0 >with OVMS binaries... Nobody hacks OVMS because& >it runs in Alphas (non easy to buy) ! >But with Itanium...., >  >Regards >1 >FC   K I've been getting the impression their are a fair number of people who haveF; obtained hobbyist licenses - they must be finding hardware.o  
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  + Date: Sat, 13 Jul 2002 09:58:57 +0000 (UTC)w From: david20@alpha1.mdx.ac.ukJ Subject: Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!)+ Message-ID: <agotl1$atc$2@aquila.mdx.ac.uk>e  o In article <01IX8.29945$WJf1.15874@news01.bloor.is.net.cable.rogers.com>, "John Smith" <a@nonymous.com> writes:d >r< >"Fabio Cardoso" <fabiopenvms@yahoo.com.br> wrote in message; >news:20020712191434.10915.qmail@web20204.mail.yahoo.com...i >> At the end... >>7 >> I asked here a few days ago, about what do you thinkm0 >> about a hacker with an Itanium server at home2 >> with OVMS binaries... Nobody hacks OVMS because( >> it runs in Alphas (non easy to buy) ! >> But with Itanium....e >aM >Maybe they find and exploit some vulnerability. The trick will be finding an K >OpenVMS system on the web they can attack. After all, there's only 411,000nJ >of them out there (if the published numbers are to be believed), and manyH >will be not connected to the net anyway (eg. national security, processH >control - though I know I will get taken to task on this). Many will be& >communicating via DECnet, not TCP/IP. > J >Those systems that are on the net are usually well protected by firewallsJ >and other security provisions, and I would wager that of the tempting VMSJ >targets that exist, most, if not all, will have a pretty complete list of >ECO patch kits installed. >   E I've been looking after VAX and Alpha systems at Middlesex universityhH completely open to the internet without any firewall for over ten years.H This is at a University so there are lots of students with time to play.J The systems have always held all student mail. Have for most of that time = held student webpages etc Hence are a fairly tempting target.s> As far as I am aware they have never been successfully hacked 4 (by hacked I mean gaining fully privileged access). K I can't say the same for the Unix systems at the University. The signs whenaB they have hacked into the Unix systems are usually fairly blatent.  
 David Webb VMS and Unix team leader CCSS Middlesex University      K >The more appropriate question to ask is, will a hacker go after a platform,B >whose market share continues to decline or will they be like mostM >opportunists and hack where the action is and the opportunity to affect morey >systems is open to them?t >r >m   ------------------------------  + Date: Sat, 13 Jul 2002 10:02:58 +0000 (UTC)  From: david20@alpha1.mdx.ac.ukJ Subject: Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!)+ Message-ID: <agotsi$atc$3@aquila.mdx.ac.uk>r  [ In article <agnkb5$4cu$1@pegasus.csx.cam.ac.uk>, nmm1@cus.cam.ac.uk (Nick Maclaren) writes:t- >In article <agn7kl$2kr3$1@info.cs.uofs.edu>,r. >Bill Gunshannon <bill@cs.scranton.edu> wrote:A >>In article <SvEX8.331515$R61.295766@rwcrnsc52.ops.asp.att.net>,-6 >> "Terry C. Shannon" <terryshannon@attbi.com> writes: >>|>Q >>|> IMHO if VMS had the same massive apps portfolio that our friends at Sun havesO >>|> at their disposal, Sun would cease to be a significant factor in the grand  >>|> scheme of things. >>E >>While I doubt it would make Sun or Unix go away, I too believe thattF >>a wider portfolio of common (and usable) apps would be great for theF >>furtherance of VMS.  Sadly, I have had little luck in finding peopleI >>interested in learning enough about VMS to actually port anything.  :-(  >e% >Had I but world enough and time ....  >aB >Frankly, if someone donated a suitable box or I could get one forC >an appropriate price, I should quite like VMS on my home computer.eB >Currently, it's Linux.  And, given the usual 36-hour day, I might@ >well end up being a porting site for several significant codes.: >After all, I was for MVT.  But, lacking a 36-hour day :-( >   I That begs the question of exactly what you consider an affordable price ?o3 Is the $950 price of a DS10L from  island to much ?p    
 David Webb VMS and Unix team leader CCSS Middlesex University  B >And I suspect that you are looking for people rather younger than
 >my 54 years!e >p >a	 >Regards,o >Nick Maclaren,e+ >University of Cambridge Computing Service,b? >New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.d >Email:  nmm1@cam.ac.ukp0 >Tel.:  +44 1223 334761    Fax:  +44 1223 334679   ------------------------------   Date: 13 Jul 2002 11:28:45 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)J Subject: Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!)0 Message-ID: <agp2td$9i1$1@pegasus.csx.cam.ac.uk>  N In article <agotsi$atc$3@aquila.mdx.ac.uk>,  <david20@alpha1.mdx.ac.uk> wrote: >>& >>Had I but world enough and time .... >>C >>Frankly, if someone donated a suitable box or I could get one for:D >>an appropriate price, I should quite like VMS on my home computer.C >>Currently, it's Linux.  And, given the usual 36-hour day, I might6A >>well end up being a porting site for several significant codes..; >>After all, I was for MVT.  But, lacking a 36-hour day :-(s > J >That begs the question of exactly what you consider an affordable price ?4 >Is the $950 price of a DS10L from  island to much ?  A Not at all, though I don't regard that as particularly good valueaF for money, given the properties of the box, and a decent configurationC would be rather more.  But I paid three times that for the one I aml currently using.  D However, the real trouble is the lack of a 36-hour day :-(  It wouldB be nice to be able to get away from Unix for a while, but I reallyC can't afford the time to do so.  And, no, I do NOT regard Microsoft A systems as a relief from Unix!  There are a few other people withrB my viewpoint around Cambridge, and I have passed the word on aboutD the hobbyist licences.  Some of us have commercial contacts and real$ commercial porting backgrounds, too.  B So, what I am saying, is that the hobbyist licence could well takeC off (especially in dual-boot mode) if boxes that could run it start @ to be very widespread.  DS10Ls aren't, and few people here would@ buy one for their own use - commodity Intel or AMD PCs give more the the money.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679e   ------------------------------  # Date: Sat, 13 Jul 2002 14:08:08 GMTs# From: "John Smith" <a@nonymous.com> J Subject: Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!)E Message-ID: <cvWX8.3140$WsS.881@news01.bloor.is.net.cable.rogers.com>e  H ""Alan Winston - SSRL Admin Cmptg Mgr"" <winston@SSRL.SLAC.STANFORD.EDU>C wrote in message news:00A10D8D.944452F2@SSRL04.SLAC.STANFORD.EDU...1K > In article <01IX8.29945$WJf1.15874@news01.bloor.is.net.cable.rogers.com>,M "John ! > Smith" <a@nonymous.com> writes:s >- > >uD > >The more appropriate question to ask is, will a hacker go after a platformD > >whose market share continues to decline or will they be like mostJ > >opportunists and hack where the action is and the opportunity to affect more > >systems is open to them?a > >- > K > (I can no longer detect any stylistic difference between "John Smith" andp JF,n? > incidentally; I used to be able to tell their writing apart.)u > L > Anyway, hackers don't care at all about whether the market share continues toK > decline.  The ones who are in it to learn about stuff want to learn aboutoF > interesting systems; the ones who are in it to get attention want to defaceE > highly-visible web sites, and if CNN/ABC/Disney/whitehouse.gov wereH runningeG > on VMS, they'd learn about VMS.  The ones who are just morons runningn scripts I > they wouldn't have had the wit to write will blindly attack VMS systemss undern6 > the assumption that they're Unix or Windows systems. >h9 > Now, virus writers like to go for the popular platform.  >,    2 FYI:  JF and I are definitely not the same person.  I And you are correct, I should have made the distinction between 'hackers'sG who what to learn something, malcontents who wish to disrupt sites, ande' nilihists  who write viruses and worms.t  E It probably will be a while before any serious hacker, malcontent, or H nilihist gets their hands on an I2 machine given cost and low volumes to begin with.e  K And then, realistically, is HP going to bring any markeing attention to VMSsJ anyway so that VMS will even register in the mind of a hacker, malcontent,C or nilihist? It certainly has very low mindshare amongst the *broadoF spectrum* of corporate America who would be the buyers, and thence theL targets of the hackers. The common response elicited these days in corporateA America upon hearing of VMS is far more likely to be, in order of 
 frequency, --  a) "What's VMS?" b) "I though it was dead."# c) "We migrated off VMS years ago." ( e) "We're migrating off VMS to Solaris."* f ) "We're migrating from VMS to Windows."% g) "We're migrating from VMS to AIX."i' h) "We're migrating from VMS to HP-UX."e i) "We use Novell." 2 j) "Our PC-DOS apps work fine. We don't need VMS." .s .e+ x) "We're adding to our existing VMS base."e? z) "That's great, I'd better get a system running VMS in here."     J VMS site are likely to be attacked as often as PrimeOS or GCOS. Apple unixK servers would probably be more tempting - there may even be more of them toc attack.-   ------------------------------  % Date: Sat, 13 Jul 2002 11:53:52 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>cJ Subject: Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!), Message-ID: <3D304D10.E6A94ED3@videotron.ca>  * Alan Winston - SSRL Admin Cmptg Mgr wrote:O > (I can no longer detect any stylistic difference between "John Smith" and JF,e? > incidentally; I used to be able to tell their writing apart.)n    Hey, don't insult John Smith :-)  M > interesting systems; the ones who are in it to get attention want to defacetM > highly-visible web sites, and if CNN/ABC/Disney/whitehouse.gov were runningaO > on VMS, they'd learn about VMS.  The ones who are just morons running scriptsnO > they wouldn't have had the wit to write will blindly attack VMS systems undert6 > the assumption that they're Unix or Windows systems.  K However, I suspect that should VMS be very popular and available at the lowON end, hackers would find some vulnerabilities. This is especially true if a lotM of software originated on other OS and were poorly ported to VMS. VMS may notnZ make it easy to jeoperdize a system, but there is not much it can do about an application.    I Also, at this point in time, I have not seen authoritative documents that"< clearly state that IA64 allows VMS to implement all the sameM memory/process/whatever protections that were available on VAX and Alpha.  IfhI some compromises have to be made in porting VMS to IA64, then hackers maye eventually find them.o   ------------------------------  # Date: Sat, 13 Jul 2002 07:09:46 GMTgL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") Subject: Re: Oracle RDB on VMS8 Message-ID: <00A10D8A.0F75E660@SSRL04.SLAC.STANFORD.EDU>  W In article <agmk33$dul$1@newsreader1.netway.at>, "Peter Flunger" <p-i-b@gmx.at> writes:o >t0 >"Tadimeti Keshav" <keshav_tadimeti@yahoo.co.uk>5 >> THe file looks too small. All it has is some files 6 >> with a .a, .d extensions. I'd like to know if this,9 >> when installed, will be a working database server. Are 0 >> there any special steps to be followed during5 >> installation? Anyone who has tried this map pleasea >> provide help. >r >I fully agree with Alan, % >this seems to be the complete works.c: >Although it is hard to beliefe if you are used to working5 >with Oracle9i on OpenVMS ( 2 almost full CDs, thoughr7 >you certainly do not need 70% of the shi<del><del>tuffd  >you still have to install it ).1 >Farewall Oracle RDB, one more sad example of how[= >things go if a company fails to market an excellent product.L  
 Yo, Peter!  B Oracle Rdb is alive and well, if expensive.  Making free developerB versions available on Technet _is_ marketing.  (It would be lovelyF if they priced deployment versions lower, especially on a departmentalF level, and I can dream about inexpensive VMS departmental servers withF Rdb kicking NT/SQLserver's butt, and we're not getting that.)  But RdbC is still under active development, will be ported to IA64, has goodn& support, and is for sure still around.   -- Alan     O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056 M  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210LO ===============================================================================h   ------------------------------  % Date: Sat, 13 Jul 2002 11:40:09 +0200 2 From: martin@radiogaga.harz.de (Martin Vorlaender)1 Subject: Re: oracleRDb on Open VMS install errorsp; Message-ID: <3d2ff579.524144494f47414741@radiogaga.harz.de>   G =?iso-8859-1?q?Tadimeti=20Keshav?= (keshav_tadimeti@yahoo.co.uk) wrote:e8 > On the technet site, there is no Installation guide in. > the same download page as the ZIP file. So I1 > downloaded the installation manual from the RDBo  > documentation site for RDB 7.11 > I downloaded this ZIP file by right clicking ino8 > Internet Explorer and saving to Windows. I unziped the7 > ZIP file on Windows and did an FTP to the VMS machinet > Ds10 in BINARY mode. 0 >e4 > Yes, I did invoke @SYS$UPDATE:VMSINSTAL RDBAMVF070$ > DKA100:[USR,KESHAV.ORD] OPTIONS N / > where RDBAMVF070 is the name of the .A file. o >i > THe error I get is:a6 > %BACKUP-E-INVRECSIZ, invalid record size in save set  H Binary FTP creates "fixed size 512 bytes" files, which is not the recordE format BACKUP expects to see. The ZIP archive does contain the recordtC format information, but Windows UNZIP doesn't care (and couldn't do2" anything about it even if it did).  C So: FTP the ZIP archive in binary mode to the VMS machine and UNZIPJF there. If you don't have UNZIP for VMS, you can find a VMS/Alpha UNZIP/ executable at http://www.process.com/openvms/ .I   cu,e   Martin -- oD                        |  Martin Vorlaender  |  VMS & WNT programmer1   OpenVMS: When you    |  work: mv@pdv-systeme.derE   KNOW where you want  |     http://www.pdv-systeme.de/users/martinv/s8   to go today.         |  home: martin@radiogaga.harz.de   ------------------------------  % Date: Sat, 13 Jul 2002 11:43:11 +0200 9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>e1 Subject: Re: oracleRDb on Open VMS install errors ' Message-ID: <3D2FF62F.844CD8E3@aaa.com>;  . Do *not*, I repeat, DO NOT, unzip on a PC !!!!) FTP the ZIP file to VMS and UNZIP there !N3 If you don't have UNZIP on your VMS system already,y# eveyone should b.t.w, get it here : * http://www.process.com/openvms/index.html.  4 Your method will corrupt the record structure in the9 BACKUP savesets, as you just have found out the hard way.m   Jan-Erik Sderholm   PS. A Often, there is a installation manual in the .A saveset. Not sure=> if it's so with the Rdb kit. Do a BACUP /LIST on the A savesetB and, if you find anything interesting, do a BACUP /EXTRACT on that file. ? Anyway, there should be installation manuals on the Oracle WEB.a0 The 7.1.x.x manual woud probably work just fine. DS.9     Tadimeti Keshav wrote: > 1 > I downloaded this ZIP file by right clicking in=8 > Internet Explorer and saving to Windows. I unziped the7 > ZIP file on Windows and did an FTP to the VMS machinex > Ds10 in BINARY mode.   ------------------------------  % Date: Sat, 13 Jul 2002 11:22:50 -0400o( From: David Froble <davef@tsoft-inc.com>1 Subject: Re: oracleRDb on Open VMS install errorsm, Message-ID: <3D3045CA.4040105@tsoft-inc.com>   Tadimeti Keshav wrote:  	 > Hi all,r4 > The zip file I downloaded contains the foll. fies:, > 	Directory SYS$SYSDEVICE:[USER.KESHAV.ORD] > 	n > 	JRDBAMVF070.A;1     > 	RDBAMVF070.A;1      > 	RDBAMVF070.B;1      > 	RDBAMVF070.C;1      > 	RDBAMVF070.D;1      > 	RDBAMVF070.E;1      > 	RDBSGA_70_AMV.BCK;1 > 	SQLSRVAMVF070.A;1   > 	SQSCLIA070.A;1      > 	  > 	Total of 9 files. > 	d > 	a8 > On the technet site, there is no Installation guide in. > the same download page as the ZIP file. So I1 > downloaded the installation manual from the RDBw  > documentation site for RDB 7.11 > I downloaded this ZIP file by right clicking in 8 > Internet Explorer and saving to Windows. I unziped the7 > ZIP file on Windows and did an FTP to the VMS machinel > Ds10 in BINARY mode. o    I Files in a ZIP archive *MAY* still retain their attributes.  IF they are aN un-ziped on windoz, they will definitely lose them.  Not saying that it would O work Ok, but moving the archive to VMS and then un-zipping might be a solution.o    4 > Yes, I did invoke @SYS$UPDATE:VMSINSTAL RDBAMVF070$ > DKA100:[USR,KESHAV.ORD] OPTIONS N / > where RDBAMVF070 is the name of the .A file.   >  > THe error I get is:.6 > %BACKUP-E-INVRECSIZ, invalid record size in save set6 > %BACKUP-E-INVBLKSIZE, invalid block size in save set6 > %BACKUP-E-INVRECSIZ, invalid record size in save set6 > %BACKUP-E-INVBLKSIZE, invalid block size in save set6 > %BACKUP-E-INVRECSIZ, invalid record size in save set6 > %BACKUP-E-INVBLKSIZE, invalid block size in save set6 > %BACKUP-E-INVRECSIZ, invalid record size in save set+ > %BACKUP-W-NOFILES, no files selected fromT. > SYS$SYSDEVICE:[USER.KESHAV.ORD]RDBAMVF070.A;0 > %VMSINSTAL-E-NOSAVESET, Save set  A  cannot be > restored.  >     L The error message is correct, and indicates your problem.  BACKUP save sets Q usually have a recordsize greater than 512 bytes.  Many savesets written to disk eO have a recordsize of 32256.  Others can have a smaller recordsize.  An example:   3 Z.BCK;1                       File ID:  (8833,12,0)U0 Size:          126/126        Owner:    [CANADA]" Created:   13-JUL-2002 11:01:29.11& Revised:   13-JUL-2002 11:01:29.85 (1) Expires:   <None specified>e Backup:    <No backup recorded>  Effective: <None specified>e Recording: <None specified>f File organization:  Sequential Shelved state:      Online  Caching attribute:  WritethroughF File attributes:    Allocation: 126, Extend: 0, Global buffer count: 0%                      No version limitl3 Record format:      Fixed length 32256 byte records  Record attributes:  None RMS attributes:     None Journaling enabled: None= File protection:    System:RWED, Owner:RWED, Group:RE, World:c Access Cntrl List:  None Client attributes:  None  N Note the record format.  If you do a DIR/FULL on one of your savesets, you'll L probably see a recordsize of 512.  This is simple enough to change.  Do the  following for each saveset:2  % $ SET FILE/ATT=(LRL:32256) <filename>o  M You should then be able to test for appropriate recordsize using BACKUP/LIST.q     Dave   ------------------------------    Date: 12 Jul 2002 23:52:29 -0700- From: goathunter@goatley.com (Hunter Goatley)a Subject: Re: RECALL suggestion= Message-ID: <3ff5fed3.0207122252.79ac503d@posting.google.com><  s SPAMSINK2001@YAHOO.COM (Alan E. Feldman) wrote in message news:<343f30ae.0207121543.3e05e801@posting.google.com>...> >HG > I guess many of us write our own set default programs to take care ofsA > what annoys each of us the most and what we encounter the most.r  H Yep.  In my case, I started using Alan Zirkle's SD from a DECUS SIG tapeI soon after I started using VMS, so the syntax became second-nature for meuI quickly.  Alan's program was a combination of DCL and FORTRAN; I wrote myd first version in 1986 or so.   Hunter ------& Hunter Goatley, goathunter@goatley.com   ------------------------------  % Date: Sat, 13 Jul 2002 07:17:30 -0600y$ From: Lee Y T Mah <lytmah@cha.ab.ca>@ Subject: TSM (Terminal Server Manager) on DECnet IV and DECnet V( Message-ID: <3D30286A.EDFF8F3@cha.ab.ca>  H We still have 127 terminal servers on our LAN and have been using DECnetF IV for many years.  TSM has been used to automate the configuration ofC the terminal servers via script files and batch jobs.  Yesterday we B upgraded to DECnet V on an ES45.  The time required to execute one= particular TSM command under DECnet V has been surprising ande disappointing.  The command is:    $ TSM SHOW SERVER ALL   % Time comparisons running the command:n  @ 22 seconds    DECnet IV, TSM V2.1-03, on an AS1200 at VMS 7.1-2. Acceptable.CE 2 seconds      DECnet IV, TSM V2.1-03, on an ES45 at VMS 7.3.  Happy.QH 5 minutes       DECnet V, TSM V2.1-03 and TSM V2.1-06, on an ES45 at VMS
 7.3.  Sad.  " The DECnet V documentation states:  3           15.9  SHOW SERVER Slower Under DECnet/OSI.  G               Currently even with the circuit retransmit timer set to 1  foroG               all of the circuits which TSM may be using, TSM will takecG               longer to timeout on non-responding terminal servers when>F               doing the SHOW SERVER command in the USE DIRECTORY mode. ItA               takes approximately 15 * (timer setting) seconds toh timeout,G               and the timer can not be set to less than 1. Note that ifu the3D               timer is left at the default of 4, each non-responding terminalD               server will take 1 minute to time out. It is recommend that the-               circuit timers be reduced to 1.r  A The analyst who performed the migration to DECnet V says that the ' circuit timer setting has been set to 1rE and the node rebooted.  However, the time required to run the commandt) against the 127 terminal servers is stille too long to be acceptable.E Is it possible that we did not make the change correctly?  Is there a  fix for this ugly time delay?r  G I also tried running a batch job under DECnet V to configure a terminalu server using TSM commands,# and the following errors showed up.g     ...s     Server G6511I is a DS200G     %DCL-W-IVOPER, unrecognized operator in expression - check spelling,
 and syntax      \.27.\rG     %DCL-W-IVOPER, unrecognized operator in expression - check spellingn
 and syntax      \.27.\g     ...nD It looks like the command broke.  (I realize that debug mode will be$ required to check into the problem.)@ The DECnet V documentation states that TSM should be compatible.= Are there any subtle changes required for TSM under DECnet V?    As always, TIA.e   -- Lees  ; Lee Y T Mah                        Capital Health Authorityr? Email: lytmah@cha.ab.ca            Information Systems, RAH CSCS4 Phone:  (780) 477-4725, 477-4233   10240 Kingsway NW? Fax:      (780) 491-5119, 491-5619    Edmonton, AB, CAN  T5H3V9-   ------------------------------    Date: 13 Jul 2002 10:43:24 -0700( From: bob@instantwhip.com (Bob Ceculski)D Subject: Re: TSM (Terminal Server Manager) on DECnet IV and DECnet V= Message-ID: <d7791aa1.0207130943.26c45b26@posting.google.com>m  T Lee Y T Mah <lytmah@cha.ab.ca> wrote in message news:<3D30286A.EDFF8F3@cha.ab.ca>...J > We still have 127 terminal servers on our LAN and have been using DECnetH > IV for many years.  TSM has been used to automate the configuration ofE > the terminal servers via script files and batch jobs.  Yesterday wesD > upgraded to DECnet V on an ES45.  The time required to execute one? > particular TSM command under DECnet V has been surprising andt! > disappointing.  The command is:t >  > $ TSM SHOW SERVER ALLe > ' > Time comparisons running the command:I > B > 22 seconds    DECnet IV, TSM V2.1-03, on an AS1200 at VMS 7.1-2.
 > Acceptable.eG > 2 seconds      DECnet IV, TSM V2.1-03, on an ES45 at VMS 7.3.  Happy.aJ > 5 minutes       DECnet V, TSM V2.1-03 and TSM V2.1-06, on an ES45 at VMS > 7.3.  Sad. > $ > The DECnet V documentation states: > 5 >           15.9  SHOW SERVER Slower Under DECnet/OSIi > I >               Currently even with the circuit retransmit timer set to 1D > forhI >               all of the circuits which TSM may be using, TSM will takehI >               longer to timeout on non-responding terminal servers whenrH >               doing the SHOW SERVER command in the USE DIRECTORY mode. > ItC >               takes approximately 15 * (timer setting) seconds tou
 > timeout,I >               and the timer can not be set to less than 1. Note that ifr > thecF >               timer is left at the default of 4, each non-responding
 > terminalF >               server will take 1 minute to time out. It is recommend
 > that the/ >               circuit timers be reduced to 1.r > C > The analyst who performed the migration to DECnet V says that theg) > circuit timer setting has been set to 1 G > and the node rebooted.  However, the time required to run the command + > against the 127 terminal servers is stilln > too long to be acceptable.G > Is it possible that we did not make the change correctly?  Is there ao > fix for this ugly time delay?w > I > I also tried running a batch job under DECnet V to configure a terminalo > server using TSM commands,% > and the following errors showed up.f	 >     ...e >     Server G6511I is a DS200I >     %DCL-W-IVOPER, unrecognized operator in expression - check spellingM > and syntax
 >      \.27.\rI >     %DCL-W-IVOPER, unrecognized operator in expression - check spelling" > and syntax
 >      \.27.\I	 >     ...eF > It looks like the command broke.  (I realize that debug mode will be& > required to check into the problem.)B > The DECnet V documentation states that TSM should be compatible.? > Are there any subtle changes required for TSM under DECnet V?e >  > As always, TIA.a  > Phase V command structure is a nightmare, and I think Phase IV7 runs much better with fewer commands ... so why switch?k   ------------------------------  # Date: Sat, 13 Jul 2002 15:05:01 GMT0' From: Stuart Fuller <stufuller@usa.net>e Subject: Re: un-INITing a tape?o0 Message-ID: <ovcpga.0hl.ln@dadsys1.fuller.local>   Mark Daniel wrote:  = > Any way to un-INITIALIZE a (DAT) tape, or recover the data?  >  > OpenVMS Alpha V7.3 > 7 > (I'm surprised I've never needed to ask this before.)e >  > As always, TIA.d >  eH > +--------------------------------------------------------------------+F >  Mark Daniel                         http://wasd.vsm.com.au/adelaideG >  mailto:Mark.Daniel@wasd.vsm.com.au (Mark.Daniel@dsto.defence.gov.au)vH > +--------------------------------------------------------------------+   No.u  K At least not with the standard hardware.  Some data recovery vendors claim ML to be able to recover the data on the tape following the volume labels that  you just wrote with the INIT.S           Stur   ------------------------------  % Date: Sat, 13 Jul 2002 19:06:53 +0200h From: Dirk Munk <munk@home.nl> Subject: Re: un-INITing a tape?S& Message-ID: <3D305E2D.8070003@home.nl>   Stuart Fuller wrote: > Mark Daniel wrote: >  > = >>Any way to un-INITIALIZE a (DAT) tape, or recover the data?o >> >>OpenVMS Alpha V7.3 >>7 >>(I'm surprised I've never needed to ask this before.)o >> >>As always, TIA.  >> aH >>+--------------------------------------------------------------------+F >> Mark Daniel                         http://wasd.vsm.com.au/adelaideG >> mailto:Mark.Daniel@wasd.vsm.com.au (Mark.Daniel@dsto.defence.gov.au) H >>+--------------------------------------------------------------------+ >  >  > No.  > M > At least not with the standard hardware.  Some data recovery vendors claim 5N > to be able to recover the data on the tape following the volume labels that  > you just wrote with the INIT.  > 
 >         Stui   You can do that yourself.@D If you mount the tape as foreign, you can copy the contents to disk.  ' (copy mka500:x dka100:[my-dir]file1.dato, copy mka500:x dka100:[my-dir]file2.dat etc.)  N It is possible to skip to the next tapemark too, with a forward command or so.@ Many years ago I used this to copy all kind of data from a tape.   Dirk   ------------------------------  % Date: Sat, 13 Jul 2002 18:26:00 +0100 E From: Jamie Stallwood <this.no.work.try.something.else@project76.net>nB Subject: VS3100/38: Infinitely looping bugchecks at boot (VMS 552)8 Message-ID: <7ho0ju8resnun5i3hrk85u0hcflf67saen@4ax.com>   Hi,l  F My vaxstation has just decided to go round and round in a loop when it! boots, which is a bit of a pain.    E The screen log is attached if anyone has any clues to help me, and itv would be most appreciated.   Jamie Stallwoode             >>> B      -DKA300eE    VAX/VMS Version V5.5-2   Major version id = 1 Minor version id = 0,  A $!  Copyright (c) 1992 Digital Equipment Corporation.  All rights 	 reserved.S  > %STDRV-I-STARTUP, VMS startup begun at 13-JUL-2002 18:21:23.47  A The VAX/VMS system is now executing the system startup procedure.a    D **** FATAL BUG CHECK, VERSION = V5.5-2   INVEXCEPTN, Exception while above ASTDk=  (     CRASH CPU: 00        PRIMARY CPU: 00  1     ACTIVE/AVAILABLE CPU MASKS: 00000001/00000001i       CURRENT PROCESS = STARTUP        REGISTER DUMP            R0 = 00000014          R1 = 04140000I         R2 = 00000000F         R3 = 00000000=         R4 = 80B12500=         R5 = 806A3BA0=         R6 = 00000000=         R7 = 00003B60-         R8 = 80666800e         R9 = 0001A3D80         R10= 000191B5n         R11= 80666800t         AP = 7FE6C28C:         FP = 7FFE77A8V         SP = 80B8119Cs         PC = 8029BE424         PSL= 04140009h       KERNEL/INTERRUPT/BOOT STACK=           80B811A4  00000004         80B811A8  7FFE77A8         80B811AC  FFFFFFFD         80B811B0  80173000         80B811B4  00000E22         80B811B8  00000001         80B811BC  00000005         80B811C0  0000000C         80B811C4  00000000         80B811C8  00000002         80B811CC  80698F4C         80B811D0  04140005         80B811D4  80698F86         80B811D8  806A4300         80B811DC  8069C63E         80B811E0  80004484         80B811E4  00000E22         80B811E8  0000DDD5         80B811EC  00000001         80B811F0  8067E4D0         80B811F4  00000738         80B811F8  80320F49         80B811FC  00C80005         LOADED IMAGES   8 [SYSMSG]SYSMSG.EXE                     801A3000 801D1C008 [SYS$LDR]SYSLDR_DYN.EXE                80326000 803280008 [SYS$LDR]DDIF$RMS_EXTENSION.EXE        80328600 803298008 [SYS$LDR]RECOVERY_UNIT_SERVICES.EXE    80329A00 8032A2008 [SYS$LDR]RMS.EXE                       801D1C00 801F9A008 VAXCLUSTER_CACHE.EXE                   8025DE00 8025E4008 SYS$NETWORK_SERVICES.EXE               8025EA00 8025EC008 SYS$TRANSACTION_SERVICES.EXE           8025F200 8027A4008 CPULOA.EXE                             8027A800 8027DA008 LMF$GROUP_TABLE.EXE                    8027EA00 8027FE008 SYSLICENSE.EXE                         80280200 80281A008 SYSGETSYI.EXE                          80282000 802836008 SYSDEVICE.EXE                          80283A00 802860008 MESSAGE_ROUTINES.EXE                   80286600 8028B8008 EXCEPTION.EXE                          8029BC00 802A4A008 LOGICAL_NAMES.EXE                      802A5200 802A6E008 SECURITY.EXE                           802A7400 802A9A008 LOCKING.EXE                            802AA000 802AF2008 PAGE_MANAGEMENT.EXE                    802AF800 802B80008 WORKING_SET_MANAGEMENT.EXE             802BCA00 802C1A008 IMAGE_MANAGEMENT.EXE                   802C2400 802C50008 EVENT_FLAGS_AND_ASTS.EXE               802C5600 802C6A008 IO_ROUTINES.EXE                        802C7000 802CF8008 PROCESS_MANAGEMENT.EXE                 802D0000 802D9C008 ERRORLOG.EXE                           8031BC00 8031C6008 PRIMITIVE_IO.EXE                       8031CC00 8031DC008 SYSTEM_SYNCHRONIZATION_UNI.EXE         8031E000 8031FC008 SYSTEM_PRIMITIVES.EXE                  80320200 80323800     **** STARTING MEMORY DUMP....a  *     Header and error log buffers dumped...     SPT & GPT dumped...g     System space (S0) dumped...i     Global pages dumped...     STARTUP dumped...      **** MEMORY DUMP COMPLETE....    ------------------------------   End of INFO-VAX 2002.383 ************************0 -0400o( From: David Froble <davef@tsoft-inc.com>1 Subject: Re: oracleRDb on Open VMS install errorsm, Message-ID: <3D3045CA.4040105@tsoft-inc.com>   Tadimeti Keshav wrote:  	 > Hi all,r4 > The zip file I downloaded contains the foll. fies:, > 	Directory SYS$SYSDEVICE:[USER.KESHAV.ORD] > 	n > 	JRDBAMVF070.A;1     > 	RDBAMVF070.A;1      > 	RDBAMVF070.B;1      > 	RDBAMVF070.C;1      > 	RDBAMVF070.D;@-    A-    B-    C-    D-    E-    F-    G-    H-    I-    J-    K-    L-    M-    N-    O-    P-    Q-    R-    S-    T-    U-    V-    W-    X-    Y-    Z-    [-    \-    ]-    ^-    _-    `-    a-    b-    c-    d-    e-    f-    g-    h-    i-    j-    k-    l-    m-    n-    o-    p-    q-    r-    s-    t-    u-    v-    w-    x-    y-    z-    {-    |-    }-    ~-    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    -    