1 INFO-VAX	Wed, 02 Jul 2003	Volume 2003 : Issue 361       Contents:6 Re: Compaq Solutions Aliance - Do it still existing  ?6 Re: Compaq Solutions Aliance - Do it still existing  ?5 Re: Compaq Solutions Aliance - Do it still existing ?  Re: cxx performance C Re: duplicates of sysuaf.dat & rightlist.dat on VMS7.3-1 FC cluster ( Re: HP Powers More TOP500 Supercomputers( Re: HP Powers More TOP500 Supercomputers( Re: HP Powers More TOP500 Supercomputers( Re: HP Powers More TOP500 SupercomputersI Re: HP Webcast this morning on Next-Generation Intel Itanium 2 processors I Re: HP Webcast this morning on Next-Generation Intel Itanium 2 processors I Re: HP Webcast this morning on Next-Generation Intel Itanium 2 processors I Re: HP Webcast this morning on Next-Generation Intel Itanium 2 processors I Re: HP Webcast this morning on Next-Generation Intel Itanium 2 processors I Re: HP Webcast this morning on Next-Generation Intel Itanium 2 processors I Re: HP Webcast this morning on Next-Generation Intel Itanium 2 processors . Re: Open VMS Alpha upgrade from 7.2-1 to 7.2-2A OpenVMS Host-Based MiniMerge Statement and Schedule for Customers E Re: OpenVMS Host-Based MiniMerge Statement and Schedule for Customers E Re: OpenVMS Host-Based MiniMerge Statement and Schedule for Customers E Re: OpenVMS Host-Based MiniMerge Statement and Schedule for Customers E Re: OpenVMS Host-Based MiniMerge Statement and Schedule for Customers E Re: OpenVMS Host-Based MiniMerge Statement and Schedule for Customers E Re: OpenVMS Host-Based MiniMerge Statement and Schedule for Customers / Re: OpenVMS Technical Seminar Highlights (some) # Porting C Code VAX -> Alpha -> IA64  Re: Rethinking  V.M.S  Re: Running VMS off CDH Re: Subject: Reading long files in BASIC that appears to be "recordless"J Re: Tri-architecture cluster demonstrated at DECUS Ottawa Technical Update Re: VMS backup to NFS shares Re: VMS backup to NFS shares Re: VMS backup to NFS shares Re: VMS backup to NFS shares Re: VMS backup to NFS shares  F ----------------------------------------------------------------------  % Date: Tue, 01 Jul 2003 20:20:48 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> ? Subject: Re: Compaq Solutions Aliance - Do it still existing  ? ' Message-ID: <3F023370.8A2171B0@fsi.net>    Fred Kleinsorge wrote: > 9 > 1) AFAIK Mozilla on VMS is hardly "not current enough".    John Reagan wrote: > G > Lets see Mozilla 1.4 was announced on June 30th and right now on July H > 1st, I'm downloading the PCSI kit for OpenVMS.  Or are you saying that8 > Mozilla.org isn't focusing on the correct feature set?  F I believe both comments are addressed by searching the google archives of this group.   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Tue, 01 Jul 2003 20:27:59 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> ? Subject: Re: Compaq Solutions Aliance - Do it still existing  ? ' Message-ID: <3F02351F.80915920@fsi.net>    David Froble wrote:  >  > David J. Dachtera wrote: >  > > David Froble wrote:  > >  > >>David J. Dachtera wrote: > >> > >> > >>>Tom Linden wrote: > >>>  > >>> I > >>>>If you think you can avoid using windows (or mac perhaps) in todays L > >>>>world you are swimming against a verey strong current.  My windows boxP > >>>>has at least one window open (using Putty) to each cluster member, one forJ > >>>>for a router, one for the browser, and one for Outlook pop client to > >>>>TCPIP5.1 smtp. > >>>> > >>>>What could easier? > >>>> > >>>>J > >>>Believe it or else, there are folks here who find WhineBloze rather aL > >>>puzzlement, since they are hard-core VMS hackers. Forcing them to learnD > >>>a new platform distracts them from their bread-and-butter work. > >>> O > >>There's nothing wrong with learning multiple systems, and a few things very  > >>right with doing so. [snip]  > >> > > K > > I'd have to do to you what my management does to me: what value does it F > > add? ...and does that value outweigh the loss of productive (read:" > > billable) time while learning? > >  > >  > / > I'm really very surprised with that response.  >  > Do you believe in education? > G > Do you stop learning once you've left your last education experience?  > U > If you cannot learn about new things, then you'll rather quickly become unbillable.  > O > I never said that an employer should pay you to learn new ideas.  Ever do any  > such on your own?   F I think the better question is *WHY* are learing what we are learning?  H To someone who makes his/her living from VMS, Windows is "nice to have",H but hardly mandatory, aside from attempts by Borg assimilees to shove it down the world's throat.  < If one is an aviator, is a boat mandatory or "nice to have"?  ? If one is a boater, is an aircraft mandatory or "nice to have"?   @ If one is a plumber, is a table saw mandatory or "nice to have"?  H If one is a carpenter, is an Oxy/MAPP torch mandatory or "nice to have"?  E If one is a geography teacher, is a grand piano mandatory or "nice to  have"?  G If one is a musician (pianist), is a globe mandatory or "nice to have"?    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  $ Date: Tue, 1 Jul 2003 22:12:20 -0400  From: John Santos <JOHN@egh.com>> Subject: Re: Compaq Solutions Aliance - Do it still existing ?5 Message-ID: <1030701221052.2835A-100000@Ives.egh.com>   , On Tue, 1 Jul 2003, David J. Dachtera wrote:   > Fred Kleinsorge wrote: > > ; > > 1) AFAIK Mozilla on VMS is hardly "not current enough".  >  > John Reagan wrote: > > I > > Lets see Mozilla 1.4 was announced on June 30th and right now on July J > > 1st, I'm downloading the PCSI kit for OpenVMS.  Or are you saying that: > > Mozilla.org isn't focusing on the correct feature set? > H > I believe both comments are addressed by searching the google archives > of this group.  H So am I supposed to read all 1690 threads in c.o.v that mention Mozilla?     --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------   Date: 1 Jul 2003 22:41:17 -0700 1 From: usenet_vms@lehrerfamily.com (Joshua Lehrer)  Subject: Re: cxx performance= Message-ID: <477e0934.0307012141.2d8865ba@posting.google.com>   ~ "Craig A. Berry" <craigberry@mac.com.spamfooler> wrote in message news:<1e99b2b7f574092d1ade34986ec50dc0@free.teranews.com>...? > In article <9d337b47.0306302201.35036222@posting.google.com>, ! >  ohm62@hotmail.com (OHM) wrote:  > I > > Please, HP, fix the darn thing!!!!  There is definitely a performance ? > > problem with this C++ compiler, otherwise a very good tool.  > E > Forgive me if I've missed it, but I haven't noticed anyone talking  I > about the demangler database in this thread.  That's one obvious place  H > where a C++ compiler on VMS has to do a lot more work than a compiler H > on other platforms, and very disk-intensive work at that.  I don't do   F Why does the VMS based compiler need to do more work with regards to a= demangler database as compared to a compiler based on another 	 platform?   
 joshua lehrer  factset research systems NYSE:FDS   ------------------------------  % Date: Tue, 01 Jul 2003 22:39:17 +0100 " From: Didier Morandi <no@spam.com>L Subject: Re: duplicates of sysuaf.dat & rightlist.dat on VMS7.3-1 FC cluster' Message-ID: <3F01FF85.6050100@spam.com>    Salvi Schrijen wrote:  > Did anyone see this before:  >=20J > last night our VMS7.3-1 dual node es40 fiberchannel cluster (latest scs= i J > patches installed) generated about 26 versions of sysuaf.dat & rightlis= t.dat F > files all with the same creationdate and the modificationdate within > milliseconds !! F > The queue manager locked sysuaf.dat;23 while the audit_server locked > sysuaf.dat;26.J > This is very strange and i have never seen this before and to be honest= , it > scares me very much.... J > Needless to say that the operator.log and auditfiles did not contain an= y  > clue. J > Logicals like sysuaf.dat is set in the system_table and is pointing at = the 
 > right file. 2 > ana/disk does also not discover any problems.... >=20J > Does anybody know about this scary behaviour and/or any solution ???!!?= ?   6 Put a security audit ACL on the file with access=3D=20< R+W+E+D+C+Success+Failure and you may see "who" accesses it.     D. --=20 - Didier Morandi sarl au capital de 8 000 euros                      Tout VMS-   19 chemin de la Butte 31400 Toulouse France /   T=E9l: 33(0)5 6120 1964 Fax: 33(0)5 6154 1928 &           http://www.didiermorandi.com$             RCS Toulouse 448 694 851   ------------------------------   Date: 1 Jul 2003 16:04:00 -0700 1 From: keithparris_NOSPAM@yahoo.com (Keith Parris) 1 Subject: Re: HP Powers More TOP500 Supercomputers = Message-ID: <cf15391e.0307011504.4fed452d@posting.google.com>   } Lord Isildur <isildur@andrew.cmu.edu> wrote in message news:<Pine.LNX.4.55L-032.0306301741450.27619@unix44.andrew.cmu.edu>... F > just because it is from intel does not make it an industry standard.  E But Intel has a pretty good track record of backing the architectures A which eventually win in the marketplace.  (The iAPX432 was a rare  exception.)   @ They backed the Ethernet standard, along with Digital and Xerox.  @ They proposed the PCI standard against IBM's Microchannel, EISA,- Futurebus+, DEC's Turbochannel, etc. and won.   D The 8080 was the starting point for the x86 instruction set family. B Zilog tried to embrace and extend that ISA with the Z80, but folks+ were reluctant to use those ISA extensions.   = Motorola countered the 8080 with the 6800, and MOS Technology ! countered the 6800 with the 6502.   ? In going to 16 bits, Intel did the 8086 (and the hybrid 8088).  F Motorola did the 68000, Zilog the Z8000.  I remember reading Osborne's@ microprocessor books and thinking how elegant the 68000 ISA was,< almost like a VAX.  But elegant design didn't translate into? marketplace success.  Intel always seemed to be able to get its > product to market 6 months ahead of everyone else for each CPU@ generation, and got the majority of the design wins as a result.  D As with the Z80, some folks will use X86-64 and like it, but withoutF Intel's backing of the ISA extensions, it has a tough road ahead of it* for acceptance in the general marketplace.   ------------------------------  % Date: Tue, 01 Jul 2003 16:23:48 -0700 3 From: Robert Klute <robert_klute_removethis@hp.com> 1 Subject: Re: HP Powers More TOP500 Supercomputers 8 Message-ID: <2s54gvogkgckk1i4p1ci3p6bif7sfjanr2@4ax.com>  A On 1 Jul 2003 16:04:00 -0700, keithparris_NOSPAM@yahoo.com (Keith  Parris) wrote:  @ >In going to 16 bits, Intel did the 8086 (and the hybrid 8088).   G Forgive me, my memory may be a bit hazy.  Why was the 8088 a hybrid?  I B thought it was just a 8086 with a reduced pin count.  I would haveA classified the 8085 a hybrid, or do I have the terminology wrong?    ------------------------------   Date: 2 Jul 2003 01:00:57 GMT ( From: bill@cs.uofs.edu (Bill Gunshannon)1 Subject: Re: HP Powers More TOP500 Supercomputers 6 Message-ID: <bdtas8$1113t9$1@ID-135708.news.dfncis.de>  = In article <cf15391e.0307011504.4fed452d@posting.google.com>, 4 	keithparris_NOSPAM@yahoo.com (Keith Parris) writes: > Lord Isildur <isildur@andrew.cmu.edu> wrote in message news:<Pine.LNX.4.55L-032.0306301741450.27619@unix44.andrew.cmu.edu>... G >> just because it is from intel does not make it an industry standard.  > G > But Intel has a pretty good track record of backing the architectures C > which eventually win in the marketplace.  (The iAPX432 was a rare 
 > exception.)  > B > They backed the Ethernet standard, along with Digital and Xerox. > B > They proposed the PCI standard against IBM's Microchannel, EISA,/ > Futurebus+, DEC's Turbochannel, etc. and won.   I While I have no experience with and therefore can't dispute what you have * said above, ther eare some problems below.   > F > The 8080 was the starting point for the x86 instruction set family. D > Zilog tried to embrace and extend that ISA with the Z80, but folks- > were reluctant to use those ISA extensions.   J Hardly.  The Z80 was consideably more popular than the 8080.  But it. likeK other products we know fell into the hands of inept management (can you say J Exxon) and it's popularity waned.  After the 8080 Intel fell on hard timesJ and had one foot in the grave when IBM bought a majority of their stock soI they could control distribution of chips guaranteeing them the supply for I the fledgling PC.  (The original candidate for the IBM PC was in fact the L M68K, but Motorola refused to agree to slight their other customers in orderJ to guarantee IBM's supply.  IBM was already manufacturing and selling M68K? based computers, primarily for the lab and engineering market.)    > ? > Motorola countered the 8080 with the 6800, and MOS Technology # > countered the 6800 with the 6502.  >   I I don't know that countered is the right word.  the 6800 (followed by the J much improved 6809) came out about the same time as the 8080 and they wereK merely competitors.  The 6502 was designed by ex-Motorola engineers and had I to do things deliberately differnt (and frequently worse) in order to not 6 run afoul of their previous employer and it's lawyers.   A > In going to 16 bits, Intel did the 8086 (and the hybrid 8088).  H > Motorola did the 68000, Zilog the Z8000.  I remember reading Osborne'sB > microprocessor books and thinking how elegant the 68000 ISA was,> > almost like a VAX.  But elegant design didn't translate into > marketplace success.    G True, what it would have taken was a lack of scruples.  If Motorola had J been willing to shaft it's existing customers IBM would have made the M68K? the heart of the IBM PC and all our history would be different.   A >                       Intel always seemed to be able to get its @ > product to market 6 months ahead of everyone else for each CPUB > generation, and got the majority of the design wins as a result.  H If it were not for the power and money of IBM at a time when they were aH cheap target, Intel would not even exist.  Their products since the 8080K have all been inferior to alternatives.  That does not seem to have changed  with the latest generation.    > F > As with the Z80, some folks will use X86-64 and like it, but withoutH > Intel's backing of the ISA extensions, it has a tough road ahead of it, > for acceptance in the general marketplace.   Only time will tell.   billI [Who started on the 8080, moved to the Z80 and then to the M6809 and M68K J all before the first IBM PC hit the marketplace.  Oh yeah, my first LSI-11 was in there too!!]    --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  $ Date: Tue, 1 Jul 2003 20:33:53 -0400* From: "Bill Todd" <billtodd@metrocast.net>1 Subject: Re: HP Powers More TOP500 Supercomputers 2 Message-ID: <MjCdnfE8xZHktZ-iXTWJgA@metrocast.net>  > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message7 news:cf15391e.0307010926.1b4ebb55@posting.google.com... 7 > "Bill Todd" <billtodd@metrocast.net> wrote in message . news:<uyWdnfKyAb_NrpyiXTWJkw@metrocast.net>...B > > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message; > > news:cf15391e.0306301301.6ed41fbc@posting.google.com... I > > > > With 159 entries, representing more than 30 percent of the posted J > > > > sites, HP has more installations on the TOP500 list than any other > > > > technology supplier. > > > $ > > > It's also interesting to note: > > > I > > > HP has held the top spot consecutively for the past three published  > > > lists. > > # > > If you conveniently ignore NEC.  > G > NEC had 14 entries in the list (including the #1 slot), compared with G > 159 for HP.  I think the postings were very clear that the "top spot" H > HP was described as having held for the past 3 years was in having the= > highest number of entries in the TOP500 list of any vendor.   G It's rather easy for the author of a comment to consider it to be 'very K clear' regardless of what wording he may have used.  When you're discussing L an ordered list and refer to 'the top spot', if you're referring to anythingK other than the first element of the list you'd be wise to do so explicitly.    - bill   ------------------------------  # Date: Tue, 01 Jul 2003 18:43:20 GMT & From: Rick Jones <foo@bar.baz.invalid>R Subject: Re: HP Webcast this morning on Next-Generation Intel Itanium 2 processors2 Message-ID: <cDkMa.3696$K41.2289@news.cpqcorp.net>  ) Bill Todd <billtodd@metrocast.net> wrote: K > Of course another question is whether that added SPECint performance will L > actually translate into anything worthwhile in real-world applications.  IH > notice that your 4-processor SPECweb99_SSL result has not yet improvedH > (despite being run on an HP-UX base and hence presumably being able toE > benefit from the same compiler that one might suspect generated the K > SPECint_base score you refer to above:  SGI only managed to get 1077 with : > presumably the best compiler they had available to them)  D I wonder if there is a correlation between SPECint and SPECweb99_SSL scores.   F > - and has now dropped to third place behind not only the 4-processorB > 1.8 GHz Opteron but now the 4-processor 1.7 GHz POWER4+ as well.A > And the dual-Madison results remain only a smidge ahead of both  > Opteron and P4.   2 You didn't look deeply enough at the HP website :)  ( http://www.hp.com/go/hpintegritypresskit  - which has a link to a performance writeup at:   S http://www.hp.com/products1/servers/press/kits/integrity/Performance_Fact_Sheet.pdf   ; which gives a bunch of benchmark results, among them a 3702 E SPECweb99_SSL for the four-CPU 1.5 GHz rx5670, and 1930 SPECweb99_SSL  for the 2 CPU 1.5 GHz rx2600.   D I guess we aren't worrying too much about cache these days, or wouldD have mentioned that the 1.7 GHz POWER4+ has a 128 MB L3 cache :) and? you forgot to mention the 1.7GHz POWER4+ results from IBM use a # dedicated SSL hardware accelerator.   E And speaking of P4 and x86... If you go to IBM's xSeries benchmarking E pages, you will see where they are touting two new 4 CPU Xeon results D at 2.8 GHz for the x360 and the x255.  They come-in at 2174 and 2110 SPECweb99_SSL respectively.   S ftp://ftp.pc.ibm.com/pub/special/serverperformance/pb_x360_specweb99_ssl_june03.pdf   S ftp://ftp.pc.ibm.com/pub/special/serverperformance/pb_x255_specweb99_ssl_june03.pdf   B Those went online at IBM yesterday (June 30th 2003).  They haven'tC gone up on http://www.spec.org yet but IBM mentions SPEC review and G such in those PDF files so ostensibly, baring something untoward during F review those should appear there at some point to take their place forD comparison with all the other results - the latest rx5670 and rx2600( results likely among them at that point.  
 rick jones  = SPECweb is a trademark of SPEC, results as of July 1, 2003 on , www.hp.com, www.spec.org and ibm.com etc etc   --  H Wisdom Teeth are impacted, people are affected by the effects of events.F these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...    ------------------------------  $ Date: Tue, 1 Jul 2003 18:42:31 -0400* From: "Bill Todd" <billtodd@metrocast.net>R Subject: Re: HP Webcast this morning on Next-Generation Intel Itanium 2 processors2 Message-ID: <0BudncjFdqTCk5-iXTWJkA@metrocast.net>  D "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> wrote in message* news:CUfMa.3666$7L.630@news.cpqcorp.net... > 7 > "Bill Todd" <billtodd@metrocast.net> wrote in message . > news:fh6dnaqIJZxk-5yiU-KYvA@metrocast.net... > K > > It would be interesting to see how it would do without that (just as it G > > would be interesting to see how Itanic would fare with less on-chip 	 > cache).  > >  > % > Now there is a brilliant statement.   L I'd be more appreciative of such compliments if they came from someone whose& analytical abilities I respected more.  (   You're not gonna give up no matter howK > much evidence you are wrong starts rolling over you.  If Intel shipped an H > IA64 that consumed 1 watt, and ran twice as fast as anything else, I'm sure1 > you'd have some fallback to why it still sucks.   L Nope.  I suspect that if/when the Alpha team finally rescues Itanic from itsI current core in 3 - 4 more years I'll have nothing left to disparage here 9 except cHumPaq's ethics (and the occasional dimwit post).    - bill   ------------------------------  $ Date: Tue, 1 Jul 2003 20:11:23 -0400* From: "Bill Todd" <billtodd@metrocast.net>R Subject: Re: HP Webcast this morning on Next-Generation Intel Itanium 2 processors2 Message-ID: <-xednXPj2uiuvp-iXTWJgQ@metrocast.net>  D "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> wrote in message+ news:FYiMa.3691$hW.1802@news.cpqcorp.net...  > 0 > "John Smith" <a@nonymous.com> wrote in messageD > news:nShMa.33079$2ay.13913@news01.bloor.is.net.cable.rogers.com... > > 9 > > "Bill Todd" <billtodd@metrocast.net> wrote in message 0 > > news:yYqcnUVMlqcrm5yiXTWJjg@metrocast.net... > > >  > > >   The one with 1318 ( > > > > SpecInt2000 and 2106 SpecFP2000. > > > H > > > Which mostly proves (again) that if you're willing to throw enough
 > > power and I > > > chip area (especially cache) at the problem you can indeed make the  > > barn# > > > door fly, albeit inelegantly.  > > J > > Somewhat similar to the F-4 Phantom II - proof that if you strap a big2 > > enough engine to it, you can make a brick fly. > >  >  > Yup.   Glad you finally agree.   5 >  Like the most successful ISA in history - the x86.   H If Itanic actually *were* 'like' the x86 in more respects, I'd have moreG respect for it.  Until recently, the Pentium (just to stick with Intel, K though of course AMD's Athlon has been at least as worthy of note) core was L small and fast (sort of like RT-11...) - and didn't consume that much power,F either.  P4 was a step backward, sacrificing chip area, IPC, and powerJ efficiency for raw clock speed - but even so remains more performance- andK power-efficient than Itanic (with the possible exception of FP-style code).   L And all that while encumbered with the x86 instruction set:  *that's* worthyF of some respect.  Itanic has no such encumbrance:  it's inefficient by *design* (cough).   
   Frankly, it B > doesn't matter all that much how they did it, they have done it.  I Finally reached approximate parity with far more neglected architectures, K after having started 14 years ago with a completely clean slate and as time E wore on (and boy, did it wear on) a virtually unlimited budget?  Wow!      This brick( > is now the baddest brick on the planet  G That I suspect depends upon how one defines 'bad'.  If you limited your L examination to FP performance you might have at least one pretty good leg to6 stand on, but if you ignore FP and concentrate on more4 commercially-significant areas this is what you see:  K Itanic is certainly close to the *hungriest* brick on the planet:  'smoking K brick of death' remains an appropriate appellation, though at least now the 1 brick actually does something besides just smoke.   J Itanic continues to vie for *biggest* brick on the planet:  twice the sizeF (and according to the scant information available also about twice theK power) of the similarly-performing Opteron (both at 130 nm), about the same I size (and power) as the dual-core POWER4+ (also in 130 nm, and again with I similar performance *per core* unless you're using HP-UX's compiler), and K even similar in size and power to the EV7 (a full process generation behind J at 180 nm - but which matched Itanic's 180 nm performance even when ItanicI used HP-UX's compiler and, of course, included other on-chip goodies that J gave it significant *system* advantages).  Bigness doesn't only compromiseD product price (where Intel's manufacturing efficiencies can at leastG partially compensate for it):  it limits one's ability to include other F useful features on the chip such as EV7's memory and MP glue, POWER5's@ coming off-load engines, and multiple cores (high per-core powerL requirements also compromise the feasibility of using multiple cores, by the way).   L Itanic probably qualifies as *pickiest* brick on the planet:  I suspect thatL more engineering effort may have been devoted just to its compilers than hasK been devoted to the creation of some successful processors, yet still those J predicted dramatic compiler performance advances remain somewhat elusive -L you pretty much need to use extensive feedback-directed optimization and theK HP-UX compiler if you want commercially-competitive performance with other,  far less picky platforms.   J But let's for the moment ignore those drawbacks and concentrate on maximumK raw performance, since I suspect your comment was meant that narrowly.  For K a moment, I'll bring FP performance back into the fold and acknowledge that L Itanic is the single-core SPECfp champion (its closest competitor being overK 25% behind):  you have to start looking at FP performance per Watt or per $ L before other platforms start looking superior (though it's also worth notingG that only SGI seems to be able to build *scalable* non-clustered Itanic F systems:  SuperDome, for example, doesn't seem to do very well in that area).  L Taking FP off the table again, let's look at other benchmarks.  While ItanicJ is now the SPECint champ using HP-UX's compiler, in non-HP-UX environmentsK its SPECint_base performance is equaled by POWER4+ (which has a higher peak A score), slightly bettered by Opteron (more so in peak score), and H significantly bettered by P4.  It ties POWER4+ in SPECweb99_SSL and onlyJ slightly beats Opteron there (and if Opteron hits 2 GHz this month as it'sL supposed to this lead should evaporate).  It beats all comers in 4-processorF TPC-C, but quite likely only because POWER4+ doesn't bother submittingK results for systems that small - since POWER4+'s 32-processor configuration L beats Itanic's 64-processor configuration in TPC-C (and beats a 32-processor$ Itanic configuration by nearly 50%).  E If it were notably *more* efficient than other platforms at achieving I approximate (non-FP) performance parity I wouldn't quibble much with your I attempt to characterize it as a superior product.  But since it's notably 1 *less* efficient, such a suggestion is laughable.   "  (oh, I'm sure we'll start gettingK > into leapfrogging - but that's no different than Alpha's position).  This K > brick is also now flying in a suite of systems from workstations to large K > mainframes, and available from the cheap system vendors like Dell, to the , > bet-your-business vendors like HP and IBM.  L Is this the same 'bet your business' claim that Compaq so earnestly made forK Alpha via the very public and explicit Heil/Lipcon letter?  One might trust < IBM to honor such a 'commitment', but certainly not cHumPaq.   > L > So go on with your complaints.  It's sounding a lot like the "purists" who- > are still bitter over BetaMax losing to VHS   I One major difference being that BetaMax lost to VHS in the *marketplace*, L after a period of real competition, not in the boardroom before VHS had even appeared for sale.  K And another, of course, being that Itanic has by no means even *started* to C prevail over the competition that remains:  for that, it would need H significant *sales*.  You can beat the PR drum all you want, but there'sC something about that that ill-befits someone who professes to be an 	 engineer.    - bill   ------------------------------  # Date: Wed, 02 Jul 2003 01:27:06 GMT & From: Rick Jones <foo@bar.baz.invalid>R Subject: Re: HP Webcast this morning on Next-Generation Intel Itanium 2 processors2 Message-ID: <KxqMa.3718$oA1.3628@news.cpqcorp.net>  ) Bill Todd <billtodd@metrocast.net> wrote: B > It ties POWER4+ in SPECweb99_SSL and only slightly beats Opteron > there   @ It ties POWER4+ at 1.7 GHz when POWER4+ is using a dedicated SSL@ accelerator.  We do not have data from IBM on the performance of; POWER4+ at 1.7 GHz on SPECweb99_SSL without a dedicated SSL  accelerator.    F The last non-accelerated POWER4+ results were for a p630 with 1.45 GHzB POWER4+ CPUs where the SPECweb99_SSL score was 1988.  That was one7 minor release of Zeus behind (4.2r1 rather than 4.2r2).   ; I'll have to leave the back of the envelope calculations to D guesstimate how much of the p655's SPECweb99_SSL score came from the$ SSL accelerator card to the readers.  @ > (and if Opteron hits 2 GHz this month as it's supposed to this > lead should evaporate).   D And I'll be willing to buy you lunch, should we both manage to be inD the same place at the same time :) If Opteron does not hit 2GHz this5 month, maybe you could stop calling Itanium Itanic?-)   A To get to 3700, based on the currenly published 1.8 GHz result of F 3498, they need just shy of another 6%.  Going from 1.8 GHz to 2.0 GHzF increases clock by just over 11%.  The published 64-bit 1.8 GHz figureF was 3498 SPECweb99_SSL.  The published 64-bit 1.4 GHz figure was 3124.A So, when clock increased just shy of 29%, the SPECweb99_SSL score @ increased by just shy of 12%, less than half the clock. All elseA holds, looks tight to get there on clock alone. Presumeably, some ? folks are busy looking for additional software tunes.  As are I D suspect everyone else doing SPECweb99_SSL benchmarking :) Or perhapsE AMD are busily writing Linux drivers for the IBM SSL accelerator card  :)  
 rick jones --  B firebug n, the idiot who tosses a lit cigarette out his car windowF these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...    ------------------------------  $ Date: Tue, 1 Jul 2003 22:06:57 -0400* From: "Bill Todd" <billtodd@metrocast.net>R Subject: Re: HP Webcast this morning on Next-Generation Intel Itanium 2 processors2 Message-ID: <W1ydneFQYd_Uo5-iXTWJjw@metrocast.net>  3 "Rick Jones" <foo@bar.baz.invalid> wrote in message , news:KxqMa.3718$oA1.3628@news.cpqcorp.net...+ > Bill Todd <billtodd@metrocast.net> wrote: D > > It ties POWER4+ in SPECweb99_SSL and only slightly beats Opteron	 > > there  > B > It ties POWER4+ at 1.7 GHz when POWER4+ is using a dedicated SSLB > accelerator.  We do not have data from IBM on the performance of= > POWER4+ at 1.7 GHz on SPECweb99_SSL without a dedicated SSL  > accelerator. > H > The last non-accelerated POWER4+ results were for a p630 with 1.45 GHzD > POWER4+ CPUs where the SPECweb99_SSL score was 1988.  That was one9 > minor release of Zeus behind (4.2r1 rather than 4.2r2).  > = > I'll have to leave the back of the envelope calculations to F > guesstimate how much of the p655's SPECweb99_SSL score came from the& > SSL accelerator card to the readers.  I While I doubt that they included the accelerator just for the hell of it, F any such calculations should also take into account that several otherJ aspects of the platform were significantly upgraded (off-chip cache speed,H I/O bandwidth, and I forget what else) in May (after the p630 submissionJ that you refer to - and the p630 itself is hardly top-of-the-line for that) series) when the new processors came out.    > B > > (and if Opteron hits 2 GHz this month as it's supposed to this > > lead should evaporate).  > F > And I'll be willing to buy you lunch, should we both manage to be in$ > the same place at the same time :)  D Thanks for the thought, even if that situation is unlikely to occur.  "  If Opteron does not hit 2GHz this7 > month, maybe you could stop calling Itanium Itanic?-)   F Opteron would have to slip not months but years just to enter the same	 ballpark.    > C > To get to 3700, based on the currenly published 1.8 GHz result of H > 3498, they need just shy of another 6%.  Going from 1.8 GHz to 2.0 GHzH > increases clock by just over 11%.  The published 64-bit 1.8 GHz figureH > was 3498 SPECweb99_SSL.  The published 64-bit 1.4 GHz figure was 3124.C > So, when clock increased just shy of 29%, the SPECweb99_SSL score B > increased by just shy of 12%, less than half the clock. All else1 > holds, looks tight to get there on clock alone.   L Certainly a fair observation.  But I didn't suggest that Opteron would *takeJ over* the lead, just that Itanic's lead would evaporate.  While suggestingF that *any* evaporation would justify this statement would certainly beL stretching the point, if at least *most* of the lead evaporates I won't feel  that my comment was unjustified.   - bill   ------------------------------  $ Date: Tue, 1 Jul 2003 21:22:20 -0500, From: "Dave Gudewicz" <k9jdk@NOSPAMarrl.net>R Subject: Re: HP Webcast this morning on Next-Generation Intel Itanium 2 processors/ Message-ID: <vg4geqircn7e00@corp.supernews.com>e  C Sent Mr. Stallard a thank you note on his mentioning VMS on severalp occasions Monday.W  L He wrote back and said he was thinking about all the customers who have sentL him mail on the subject.  So it seems like something is working.  And it was& nice to get a "your welcome" from him.   Dave...o  D "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> wrote in message+ news:LPfMa.3665$VK.2955@news.cpqcorp.net...N9 > "Dave Gudewicz" <k9jdk@NOSPAMarrl.net> wrote in messagep+ > news:vg1vepf5sd0fa4@corp.supernews.com...BE > > Heard the Madison stuff and saw the slides.  I think VMS got fairB > attentione > > this time around.  > >uE > > Although also saw that the rx5670 (entry level 4-way) will not beu > supported H > > by VMS.  Wonder why?  Hope this isn't the start of another white-box AlphaoI > > campaign.  Remember the white Alpha boxes?  Most would rather forget.B > >M >ML > Not at all.  VMS is *only* supported on the rx2600 at present.  We will beL > filling out the offering as we get VMS to full production quality in 2004.I > Since 4-way systems are a large part of VMS sales, you can rest assured  that  > we will have a 4-way offering. >n >i >    ------------------------------  $ Date: Tue, 1 Jul 2003 22:25:23 -0400* From: "Bill Todd" <billtodd@metrocast.net>R Subject: Re: HP Webcast this morning on Next-Generation Intel Itanium 2 processors2 Message-ID: <teicneuOq_8B35-iXTWJgA@metrocast.net>  3 "Rick Jones" <foo@bar.baz.invalid> wrote in message-, news:cDkMa.3696$K41.2289@news.cpqcorp.net...   ...0  4 > You didn't look deeply enough at the HP website :) >m* > http://www.hp.com/go/hpintegritypresskit >c/ > which has a link to a performance writeup at:7 >A >1L http://www.hp.com/products1/servers/press/kits/integrity/Performance_Fact_Sh eet.pdfr >t= > which gives a bunch of benchmark results, among them a 3702sG > SPECweb99_SSL for the four-CPU 1.5 GHz rx5670, and 1930 SPECweb99_SSLe > for the 2 CPU 1.5 GHz rx2600.u  % Thanks - yet more grist for the mill.g   >hF > I guess we aren't worrying too much about cache these days, or wouldB > have mentioned that the 1.7 GHz POWER4+ has a 128 MB L3 cache :)  D It would be interesting to see how it would do without that, and theL soon-to-arrive PC970 (and the Apple versions of it, up to 2 GHz) that has noK off-chip L3 and only 512 KB of on-chip L2 should provide at least a clue ineL that regard (my impression is that they will be available in MP servers, but4 who knows whether they'll appear in this benchmark).    andA > you forgot to mention the 1.7GHz POWER4+ results from IBM use aw% > dedicated SSL hardware accelerator.t > G > And speaking of P4 and x86... If you go to IBM's xSeries benchmarkinguG > pages, you will see where they are touting two new 4 CPU Xeon results F > at 2.8 GHz for the x360 and the x255.  They come-in at 2174 and 2110 > SPECweb99_SSL respectively.t >t >aL ftp://ftp.pc.ibm.com/pub/special/serverperformance/pb_x360_specweb99_ssl_jun e03.pdfk >p >iL ftp://ftp.pc.ibm.com/pub/special/serverperformance/pb_x255_specweb99_ssl_jun e03.pdfl  E How abjectly bletcherous!  That's only about 20% better than the bestpI dual-processor P4/Xeon scores with only 512 KB of on-chip cache (vs. 2 MB>G for the MPs tested above), and those dual P4/Xeons only had a 9% faster K clock (though presumably 533 MHz FSBs vs. the 400 MHz FSB in the Xeon MPs).rB Then again, ISTR that the IA32s have always had somewhat less than% impressive scaling in this benchmark.w  J Apropos of another completely unrelated conversation about the new 2.8 GHzK Xeon MPs, does this indicate that they're still only available with the 400y. MHz FSB (and hence PC1600 memory performance)?   - bill   ------------------------------  # Date: Tue, 01 Jul 2003 22:27:14 GMTc From: Beach Runner@nospam.comu7 Subject: Re: Open VMS Alpha upgrade from 7.2-1 to 7.2-2y) Message-ID: <3F020AC2.E3FB4F6@cfl.rr.com>a   Keith Parris wrote:y  J > Rob.Buxton@wcc.govt.nz wrote in message news:<3eff8459.13509046@news>...D > > If you're running a fully patched 7.2-1 then there's very littleH > > difference between taht and 7.2-2. My understanding is that 7.2-2 is: > > just a roll together of patches into a stable release. > > > Actually, 7.2-2 also included some of the features from 7.3.  J There is a rename patch that should be applied before the upgrade. Some of theo# ECOs put patches i the wrong place.   D 7.2-1 is also prior version support, while 7.2-2 still is supported.   Beach Runner   ------------------------------   Date: 1 Jul 2003 11:45:56 -0700n1 From: susan_skonetski@hotmail.com (Sue Skonetski) J Subject: OpenVMS Host-Based MiniMerge Statement and Schedule for Customers= Message-ID: <857e9e41.0307011045.4f3e2ad0@posting.google.com>f  F There was a word schedule attached but I know how you folks feel about that.-   sue-  4 ----------------------------------------------------  + Host-Based MiniMerge Schedule Now AvailableC  C The OpenVMS Engineering and Business Management group would like to2F announce the schedule for Host-Based MiniMerge capability.  As most ofB you know, the teams have been spending virtually all of their timeD over the past 3 months doing design, "proof of concept" and scheduleF development for this important feature.  We are now ready to make this4 information available to the OpenVMS user community.  F Overview - The purpose of the Host-Based MiniMerge feature is to allow= a "minimum" MERGE of only shadow set changes (rather than thecD currently-required "full" MERGE) when a member of an OpenVMS clusterB is removed and re-introduced into a cluster.  A similar capability< exists today for CI-based storage, and this new "host-based"E implementation will allow a MiniMerge to occur on any type of storage C that is utilized in a Host-Based Volume Shadowing shadow set.  ThismA implementation utilizes the "write bitmap" technology in use with A MiniCopy today, in order to keep track of shadow set data changesgC while the cluster member is out of the cluster.  When the member isaC brought back in, shadow sets will be able to MERGE only the changedhA areas of the disk, thus resulting in a much faster restoration of! shadow sets into the cluster.a   ------------------------------   Date: 1 Jul 2003 14:25:07 -0500 + From: young_r@encompasserve.org (Rob Young)aN Subject: Re: OpenVMS Host-Based MiniMerge Statement and Schedule for Customers3 Message-ID: <2hEyOyPaW87X@eisner.encompasserve.org>   q In article <857e9e41.0307011045.4f3e2ad0@posting.google.com>, susan_skonetski@hotmail.com (Sue Skonetski) writes:d   > H > Overview - The purpose of the Host-Based MiniMerge feature is to allow? > a "minimum" MERGE of only shadow set changes (rather than thetF > currently-required "full" MERGE) when a member of an OpenVMS clusterD > is removed and re-introduced into a cluster.  A similar capability> > exists today for CI-based storage, and this new "host-based"G > implementation will allow a MiniMerge to occur on any type of storage0E > that is utilized in a Host-Based Volume Shadowing shadow set.  This C > implementation utilizes the "write bitmap" technology in use withlC > MiniCopy today, in order to keep track of shadow set data changesyE > while the cluster member is out of the cluster.  When the member isdE > brought back in, shadow sets will be able to MERGE only the changedoC > areas of the disk, thus resulting in a much faster restoration of  > shadow sets into the cluster.e    8 	This paragraph reads that the merge is dependent on the7 	crashed member returning to do the merge.  What if theu8 	crashed node is gone for several hours/days?  Maybe I'm 	misreading that paragraph.  e  G 	A scenario would be a node crashes month-end Monday (hardware failure)t& 	and isn't back until mid-afternoon...? 	A host-based mini-merge could be a high priority in that case,!3 	and hopefully isn't dependent on a returning node.c   				Rob    ------------------------------  # Date: Tue, 01 Jul 2003 20:31:40 GMT2/ From: brooks@cuebid.zko.dec.nospam (Rob Brooks) N Subject: Re: OpenVMS Host-Based MiniMerge Statement and Schedule for Customers- Message-ID: <C6t42YoiBeqQ@cuebid.zko.dec.com>   - young_r@encompasserve.org (Rob Young) writes: 5 > susan_skonetski@hotmail.com (Sue Skonetski) writes:-   >> When the member is3F >> brought back in, shadow sets will be able to MERGE only the changedD >> areas of the disk, thus resulting in a much faster restoration of  >> shadow sets into the cluster. > : > 	This paragraph reads that the merge is dependent on the9 > 	crashed member returning to do the merge.  What if thee: > 	crashed node is gone for several hours/days?  Maybe I'm > 	misreading that paragraph.    > I > 	A scenario would be a node crashes month-end Monday (hardware failure)u( > 	and isn't back until mid-afternoon...A > 	A host-based mini-merge could be a high priority in that case,o5 > 	and hopefully isn't dependent on a returning node.n  N The minimerge is not at all dependent upon the return of the crashing node(s).I It *is* dependent upon at least one node that was mastering the bitmap to I survive.  If all the nodes that had bitmaps for a given shadow set crash,r then a full merge is required.  I It appears that there is some confusion between mini-merge and mini-copy,n given that last sentence.2   -- n  M Rob Brooks    VMS Engineering -- I/O Exec Group     brooks!cuebid.zko.dec.com6   ------------------------------   Date: 1 Jul 2003 15:46:48 -0500b+ From: young_r@encompasserve.org (Rob Young)aN Subject: Re: OpenVMS Host-Based MiniMerge Statement and Schedule for Customers3 Message-ID: <SY9ga6PR3gy2@eisner.encompasserve.org>r  _ In article <C6t42YoiBeqQ@cuebid.zko.dec.com>, brooks@cuebid.zko.dec.nospam (Rob Brooks) writes:h/ > young_r@encompasserve.org (Rob Young) writes:m6 >> susan_skonetski@hotmail.com (Sue Skonetski) writes: >  >>> When the member isG >>> brought back in, shadow sets will be able to MERGE only the changedtE >>> areas of the disk, thus resulting in a much faster restoration of3! >>> shadow sets into the cluster.e >> u; >> 	This paragraph reads that the merge is dependent on thep: >> 	crashed member returning to do the merge.  What if the; >> 	crashed node is gone for several hours/days?  Maybe I'mM  >> 	misreading that paragraph.   >> IJ >> 	A scenario would be a node crashes month-end Monday (hardware failure)) >> 	and isn't back until mid-afternoon... B >> 	A host-based mini-merge could be a high priority in that case,6 >> 	and hopefully isn't dependent on a returning node. > P > The minimerge is not at all dependent upon the return of the crashing node(s).K > It *is* dependent upon at least one node that was mastering the bitmap tosK > survive.  If all the nodes that had bitmaps for a given shadow set crash,c  > then a full merge is required. > K > It appears that there is some confusion between mini-merge and mini-copy,i > given that last sentence.s >   ? 	No.  Part of it is -my- trouble with the paragraph.  Maybe I'm7 	alone:1    ThisaA implementation utilizes the "write bitmap" technology in use withiA MiniCopy today, in order to keep track of shadow set data changeseC while the cluster member is out of the cluster.  When the member iskG brought back in, shadow sets will be able to MERGE only the changed     D areas of the disk, thus resulting in a much faster restoration of    shadow sets into the cluster.   < 	"Member" refers to two different things, real close to each6 	other lending itself to *appear* as if things work on 	return of a node:  F 	"keep track of shadow set data changes while the -cluster- member is C 	out of the cluster. When the [-shadow-] member is brought back in, 4 	shadow sets will be able to MERGE only the changed"  0 	As noted, maybe better would be a slight tweek:  , 	"When the shadow member is brought back in"  ? 	The ambiguity threw me.  I thought maybe a new method requirednD 	a tweek of how mini-merge would be taking place.  Yes , after this C 	long I know the difference between minicopy/minimerge having been rC 	admittedly confused at one time.  And Keith Parris pointed out my dG 	confusion a few years back (IIRC).  And I certainly don't want to get   	lost again.  > 	And to get really nitpicky, shadow sets don't merge anything.% 	Nodes do the merging of shadow sets.t   				Robd   ------------------------------   Date: 1 Jul 2003 14:22:40 -0700l1 From: keithparris_NOSPAM@yahoo.com (Keith Parris)dN Subject: Re: OpenVMS Host-Based MiniMerge Statement and Schedule for Customers= Message-ID: <cf15391e.0307011322.44b28758@posting.google.com>o  v susan_skonetski@hotmail.com (Sue Skonetski) wrote in message news:<857e9e41.0307011045.4f3e2ad0@posting.google.com>...H > There was a word schedule attached but I know how you folks feel about > that.   F I often have to 'copy' the text from a Word window and 'paste' it into? a Notepad window to make it suitable for use for character-cell' oriented applications.  E The important dates from the schedule (subject to change, of course),d are:1    External Field Test        12/31/03 to 3/24/04s&    Production Kit available    3/25/04A Initial availability is slated to be on 7.3-1, with 7.3-2 supporti shortly thereafter.n   ------------------------------   Date: 1 Jul 2003 15:10:15 -0700l1 From: keithparris_NOSPAM@yahoo.com (Keith Parris) N Subject: Re: OpenVMS Host-Based MiniMerge Statement and Schedule for Customers= Message-ID: <cf15391e.0307011410.62c3afcf@posting.google.com>   v susan_skonetski@hotmail.com (Sue Skonetski) wrote in message news:<857e9e41.0307011045.4f3e2ad0@posting.google.com>... > ThisC > implementation utilizes the "write bitmap" technology in use withnC > MiniCopy today, in order to keep track of shadow set data changesaE > while the cluster member is out of the cluster.  When the member isaE > brought back in, shadow sets will be able to MERGE only the changed C > areas of the disk, thus resulting in a much faster restoration ofl > shadow sets into the cluster.o  F This paragraph is broken. (And Rob, it was very kind of you to give usF the benefit of the doubt, but I think it's impossible to parse this inD any way that makes it correct.)   I think what they meant to say was something like this:  D "This implementation utilizes the "write bitmap" technology used forF MiniCopy functionality today, to keep track of shadow set data changesB while a shadowset member is temporarily removed from a shadowset. D With MiniCopy, when a shadowset member is brought back in, ShadowingE is able to copy only the changed areas of the disk, thus resulting in-F a much faster restoration of the shadow set member into the shadowset.F  By using similar "write bitmap" technology to track the changes beingE made by each node in a cluster to the members of a shadowset, then ati? the time a node fails and leaves the cluster, it is possible tocF identify those specific areas on the shadowset that were being writtenF to by the node at the time it failed, and thus where the failure mightE have resulted in data ending up different on different members of thenE shadowset, and as a result Shadowing can merge just those areas which E were in the process of being modified at the time the node failed (ineB a MiniMerge operation), rather than having to scan the entire diskF looking for potential discrepancies caused by the node's failure (in a Full Merge operation)."    ------------------------------  % Date: Tue, 01 Jul 2003 20:51:57 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>CN Subject: Re: OpenVMS Host-Based MiniMerge Statement and Schedule for Customers' Message-ID: <3F023ABD.FED6BAF2@fsi.net>e   Sue Skonetski wrote: > H > There was a word schedule attached but I know how you folks feel about > that.i  G Your consideration is appreciated. VMS management could take an examplea	 from you.a   -- f David J. Dachterad dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/e   ------------------------------  # Date: Wed, 02 Jul 2003 03:27:08 GMTr# From: "John Smith" <a@nonymous.com>t8 Subject: Re: OpenVMS Technical Seminar Highlights (some)G Message-ID: <gisMa.38984$x4o.9973@news04.bloor.is.net.cable.rogers.com>.  4 "Neil Rieck" <n.rieck@sympatico.ca> wrote in message3 news:rXVKa.6896$OE2.817794@news20.bellglobal.com... E > Note that a full set of the Ottawa seminar (2003.06.25 + 26) slides.	 and power C > point presentations is going to be published at either one of then two URLs > listed below.a >i > http://www.canacu.org/+ > http://www.communitywerke.com/seminar.htmo >4 > * * * * *E > * * * * *s >  > VMS Application Software:i >bB > 1. H-P requires that their partners develop products for all H-P	 operatingeB > systems. This means that an ISV wanting to develop for HP-UX and
 LINUX willC > now be required to develop for OpenVMS as well. This will help tob dispelE > myths like H-P wants to kill VMS and/or there are no apps availableb for VMS.  D a) How contractually binding, and what penalties exist for ISV's who> do not release VMS versions of the apps? How onerous can thoseE penalties be?.... HP want's their loaner workstation back?... HP willrF not list the product in their applications catalog under any o/s if it isn't available on VMS?   D b) Is there a requirement for pricing parity of the apps and support on VMS vs. other platforms?t  E c) Is there a requirement for simultaneous release of the apps on VMSe  with all other supported o/s'es?  E d) If I were going to sign my company on the line and on the hook forrF this, I'd want to see HP's advertising plans for a platform I may have@ never developed for before. Yes, it's programming, but there's aE learning curve that isn't necessarily cheap under some circumstances,hD and I'd want to know that HP is going to spend the bucks required toB draw customers to my efforts running on OpenVMS otherwise it isn't? worth the effort. So where's the details of the VMS advertising $ campaign HP should be showing ISV's?        : > 2. There are currently 3000 ISVs developing 5000 OpenVMS
 applications.1  E If what you suggest is true, we should be seeing a run on experiencedeC VMS developers right now. Check your local newspaper or Monster.comm9 and the like....do you see this happenning? I sure don't..  ? They hope that there will be 5000 VMS applications if the ISV'sh actually release on VMS.  E Who at HP is teaching all these unix weenies and Access weenies abouteC the differences in coding and tuning an application for use on VMS?l< Are they teaching them how to take advantage of VMS clustersE effectively - perhaps the greatest VMS advantage going?  Without thisiF kind of knowledge, the unix/Windows apps that are released on VMS will? likely be performance pigs, and unsaleable at any price, with aa" corresponding result on VMS sales.           > * * * * *l >r > Good news: > E > OpenVMS business is growing 12-15% each year. It seems to be reallyt
 taking offC > in Europe were many head offices were impressed by their AmericanH subsidiaries> > who managed to keep running right through the 9/11 disaster.    D So we should expect to hear HP execs touting this in virtually everyF public announcement they make to the financial press, conferences, andF in the 10Q and 10K statements filed with the SEC......after all 12-15%C growth would represent THE shining star in the HP server firmament,r+ and very nearly for the company as a whole.s  D I guess the real reason HP doesn't advertise VMS is that if they canA get 12-15% growth without advertising then HP is just a committedaC corporate citizen concerned about the pollution they would cause if ? Alphaserver production had to be bumped up to 3 shifts daily ataB multiple plants resulting from increased customer demand caused by@ advertising, and the global run they'd cause on the blank CD/DVDD market due to being required to press more CONDIST and CONOLD CD/DVDE sets for all the new VMS customers, which would force the music/videom; industry to charge more for CD/DVD's due to higher costs of D productions. There you go...HP is just trying to make sure that SonyA and all the other big music/movie studio executives can still hitn! their annual bonus sales targets.e  F What a great company HP is...environmentally aware and altruistic to a@ fault....always looking out for the interests of other companiesB executives, including those of Sun, IBM, and Microsoft.  Atta girl Carly.   ------------------------------  * Date: Tue, 1 Jul 2003 22:37:31 +0000 (UTC)! From: "Code Monkey" <me@here.com>v, Subject: Porting C Code VAX -> Alpha -> IA640 Message-ID: <bdt2fb$nc7$1@sparta.btinternet.com>  J Currently have an application compiling under DEC C v.5.7 on VAX using the following compiler symbol;  <     CC/STANDARD=VAXC/EXTERN_MODEL=COMMON_BLOCK/SHARE_GLOBALS    L Would like to port this to Alpha eventually, and would like to know if there are anyyD disadvantages to keeping this compiler symbol on the Alpha platform.  L Will the Alpha Compaq C compiler generate code as efficiently as it can withE this symbol ? Or to unlock it's true potential should it be changed ?p  J Would ideally like to change this to the default standard (which I believeK it RELAXED_ANSI), but would need to be able to justify such a move...... asp I'mt1 sure more tweaking to the code would be required.u  I Also does anybody know if the OpenVMS C Compiler on Itanium will have thek /STANDARD=VAXC option in it ??  E If not then I see the above move as a prerequisite to porting to IA64e further on down the road.   6 Your comments and suggestions are greatly appreciated.   ------------------------------  # Date: Wed, 02 Jul 2003 00:59:52 GMT) From: Beach Runner@nospam.comt Subject: Re: Rethinking  V.M.S* Message-ID: <3F022E94.A85B1DE0@cfl.rr.com>  5 The latest OS all have page files and virtual memory.i  S Could you imagine one day they will even have files systems that are shared between R systems with file locking at the record level, transparent to the user/programmer.2 That was VMS Clustering, still never been equaled.  
 Beach Runner.p   Dale Dellutri wrote:  [ > On Sun, 29 Jun 2003 14:14:10 -0700 (PDT), Fabio Cardoso <fabiopenvms@yahoo.com.br> wrote:t6 > > The VMS was developed 25 years ago when memory was+ > > expensive and Virtual Memory an option.e5 > > But do we need a Virtual Memory System nowadays ? 5 > > May be we should think in another architecture asd; > > the memories are becoming cheaper. May be the VM System < > > can be improved or rethinked... What are the performance> > > issues related in having the VM (paging, swapping, related7 > > to disk I/O delay, etc ...) What do u think about ?s >nE > Also, remember that virtual memory provides another benefit even if B > all the processes need less than the real memory: no real memoryA > fragmentation caused by multiple independent running processes.n > G > Before virtual memory (for example, think of the OSes that ran on thehF > IBM 360 series: DOS, OS/MFT, MVS without paging), the memory used byF > each process had to be contiguous and real.  Thus, there were memoryF > fragmentation problems among processes as they were placed / moved / > removed from the system. >nC > Virtual memory eliminated the need to have contiguous real memory  > assigned to processes. >a? > Now all the fragmentation problems are within each process, a-D > different kind of problem from the system manager's point of view. >r > --9 > Dale Dellutri <ddelQQQlutr@panQQQix.com> (lose the Q's)1   ------------------------------  % Date: Tue, 01 Jul 2003 20:48:56 -0500n1 From: "David J. Dachtera" <djesys.nospam@fsi.net>c Subject: Re: Running VMS off CDs' Message-ID: <3F023A08.C5DD8E2E@fsi.net>w   "Doc.Cypher" wrote:i > I > On Mon, 30 Jun 2003, "David J. Dachtera" <djesys.nospam@fsi.net> wrote:i > >"Doc.Cypher" wrote: > >>Q > >> For those that have noticed I have an interest in remailers (duh!). The goodnP > >> news is that the new Type-III remailer (Mixminion) is written in Python and& > >> will therefor be runnable on VMS. > >>O > >> Any system such as that should be as secure as possible, and I'm wonderingh9 > >> about the possibility of booting and running off CD.t > >>Q > >> Has anyone done this?  If so, is XFC enough of a performance booster to makelP > >> this a viable proposition?  What would be a reasonable amount of memory for > >> the system? > >> > >> Thanks for any advice.r > > I > >I'm sure it can be done, provided you are prepared to hack up your owneJ > >bootable image. I've done it. It's not easy, and the time investment is > >substantial.r > O > It would be an interesting exercise, I'd probably be a lot more familiar with F > the boot process - and have a lot of coasters - by the end of it. :)  D All ya really gotta do is take the time to hack STARTUP.COM, or even= just hack up your own. Check out SA_STARTUP.COM, for example.t  I > >I'd have to question the reason why, however. What does a write-lockedsC > >system disk do for you? ...and are you prepared to deal with thee > >ramifications of that?a > O > It should mean that physical access would be required - or intimate knowledger9 > of an undiscovered exploit - to compromise the machine.t  , Then all your storage would be write-locked?  E Just protecting the system disk doesn't seem like it would be enough.t  F ...not to mention how slow even the fastest CD-Rom drives are compared to "hard disk" drives.  G If you've got lots of RAM, I suppose you could hack up a /STARTUP proc. A that copies the distribution up to a RAMdisk before assigning keytB logicals and such and then proceeding, ... but then there goes the write-lock.e  1 ...and your dump device would DEFINITELY be DOSD!,   -- i David J. Dachterau dba DJE Systemst http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t   ------------------------------   Date: 1 Jul 2003 13:29:15 -0700s  From: southshore@niia.net (Jeff)Q Subject: Re: Subject: Reading long files in BASIC that appears to be "recordless"p= Message-ID: <b342eec2.0307011229.1fbe4877@posting.google.com>i  l dennisb@wvhmhc.org (Dennis Baker) wrote in message news:<6f29699e.0306300816.450c0ec6@posting.google.com>...D > Thanks for your timely input, Randy and Dave, but unfortunately it > didn't help. > . > Here's my test program stripped to the bone: >  > 200 when error inl6 >         f$ = "dkb0:[user.ninsur.tagcom]HP150922.835"G >         OPEN f$ for input AS #5, organization virtual, recordtype anyhC >             ! I even tried adding recordsize 512 with same result'	 >     uses >         if err = 5% then* >             print "Can't find file "; f$ >             continue 999 >         end if >         exit handler >     end when >  > 210 Record_number = 0% >     WHEN ERROR IN  >         WHILE -1%s >             get #5%e0 >             Record_number = Record_number + 1% >         NEXT	 >     USEi >         IF ERR = 11% THENo5 >             PRINT "Finished reading " + f$ + " - ";l1 > NUM1$(Record_number); " records (blocks) read."v >             PRINT. >             CONTINUE 999 >         END IF >         EXIT HANDLER >     END WHEN	 > 999 ENDe > H > As you can see, I tried organization virtual, recordtype any and still > gete* > %BAS-F-RECFILTOO, Record on file too big) > -BAS-I-ON_CHAFIL, on channel 5 for filew* > DKB0:[USER.NINSUR.TAGCOM]HP150922.835;10: > -RMS-W-RTB, 1755 byte record too large for user's buffer/ > -BAS-I-FROMOD, In module TEST_STREAM_STRIPPEDa1 > %TRACE-F-TRACEBACK, symbolic stack dump followsGE >   image    module    routine             line      rel PC          n > abs PC@ >                                             0 FFFFFFFF80843E98 > FFFFFFFF80843E98@ >  DEC$BASRTL                                 0 000000000000E52C > 000000000004052C? > ----- above condition handler called with exception 001A84EC:m* > %BAS-F-RECFILTOO, Record on file too big) > -BAS-I-ON_CHAFIL, on channel 5 for file * > DKB0:[USER.NINSUR.TAGCOM]HP150922.835;10: > -RMS-W-RTB, 1755 byte record too large for user's buffer  > ----- end of exception message@ >                                             0 FFFFFFFF8899859C > FFFFFFFF8899859C@ >  DEC$BASRTL                                 0 000000000004A518 > 000000000007C518@ >  DEC$BASRTL                                 0 000000000003CC44 > 000000000006EC44@ >  DEC$BASRTL                                 0 0000000000045E1C > 0000000000077E1C3 >  TEST_STREAM_STRIPPED  TEST_STREAM_STRIPPED$MAIN   > TEST_STREAM_STRIPPED$MAINe@ >                                            15 0000000000000150 > 0000000000020150@ >                                             0 FFFFFFFF88AC70D8 > FFFFFFFF88AC70D8 > E > As David pointed out and I wrote in my original message, there WILL H > definitely be times when these recordless files are over 1 MB in size,F > so allocating a map larger than any filesize that may be encounteredG > will probably bomb at 32768.  In fact, I just tried adding recordsizerH > clauses.  It compiles with large numbers, but running at 65536 returns0 > %BAS-F-BADRECVAL, Bad RECORDSIZE value on OPENE > Interestingly enough, help/libr=basichelp run_time_errors badrecval  > says >  > Run_time_errorso > 
 >   BADRECVALe > - >      Bad RECORDSIZE value on OPEN (ERR=148)n > D >      The value in the RECORDSIZE clause in the OPEN statement  is 
 > zero  orF >      greater than 16384.  Change the value in the RECORDSIZE clause. > G > Well, it'll run without a complaint all the way up to 65535, but thatiC > still won't cover all file sizes I'll receive.  I also today just- > trieda& >      map (chunk) string blk$ = 32768) >      open f$ for input as #5, map chunkj	 > and got 4 >                 OPEN f$ for input AS #5, map chunk > ^c+ > %BASIC-F-MAPTOOLAR, MAP too large in OPENe > 3 > help/libr=basichelp compile_errors maptoolar saysi >  > Compile_errors > 
 >   MAPTOOLAR. > E >      FATAL - The size of the MAP referenced in an OPEN statement isO	 > greaterE5 >      than 32767 bytes.  Reduce the size of the MAP.  > B > So it looks like the QIO method should be my only hope, but as Ig > noted, the code at http://h18000.www1.hp.com/support/asktima/appl_tools/009688F7-F95FC060-1C0097.html C > "Example-BASIC Using ACP QIO To Access File And Display Contents"tC > wouldn't work as written on our new system (OR SO I THOUGHT!).  IeH > thought it worked in all cases on the old VMS 5.5-1 MV3100 but it onlyA > seemed to work if I specify SYS$SYSROOT:[SYSMGR]<any valid filecG > there>.  Well, it only works if that's my default directory!  I triedSC > this again on the Alphas and it, too, works only for files in therA > default directory (but at least it works!).  I changed the code  > slightly by adding$ >     MAP (CHUNK) STRING BLK$ = 512%F > changed the qiow call parameter file_block() BY REF, to BLK$ BY REF,  > and changed the output code to% >     FOR cntr1 = 1% TO 512% STEP 64%a. >         PRINT SEG$(BLK$, CNTR1, CNTR1 + 63%)> > This does seem to work, albeit only for files in the defaultB > directory.  Odd, since the program prompts for a full filespec. F > Sooooooo....anybody know how to make THAT code work for files in anyH > directory?  If so, I think I'd be on my way.  Also, Randy and Dave, ifH > it's not much trouble, I would be interested in any short routines youG > could post or email me, if for nothing else than a learning exercise.h  C You might try "organization undefined" -- I believe that will allow E only 512-byte block reads--I don't have my manual handy, so I workin'k without a net.   ------------------------------  # Date: Tue, 01 Jul 2003 18:48:58 GMTh# From: hoff@hp.nospam (Hoff Hoffman)gS Subject: Re: Tri-architecture cluster demonstrated at DECUS Ottawa Technical Update.1 Message-ID: <uIkMa.3698$K51.152@news.cpqcorp.net>h  q In article <qLVVcLA1TSNw@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: B :  Anyone notice anything that didn't work (other than the support
 :  contract)?   J   We have been over this ground before -- the core of the existing clusterG   environment will likely continue to work and nothing is being done tovI   disable or to remove capabilities; testing and qualification has simplym$   not (yet) been performed with VAX.  F   As has been stated before, the initial target for cluster testing isD   Alpha and Itanium clustering -- the addition of VAX will likely beB   looked at as scheduling and engineering proceeds and as customerB   feedback is received.  VAX was explicitly omitted from the earlyE   configuration and testing work.  (You'll also want to consider youreF   plans for your existing the VAX systems -- and you will want to alsoH   consider Alpha or Itanium system upgrades or replacements, of course.)  G   I certainly know of clustering stuff that doesn't work -- I'm in the iF   process of loading some code changes for one of the areas where someF   capabilities are lacking.  (What I am working on is certainly minor,D   but would eventually prove very annoying to at least a few folks.)D   I know of some other related areas that also don't yet work, and IE   fully expect that there are other incompatibilities and problems inl(   areas that I am not directly aware of.  G   Put another way: If it were simple and certain, we'd already have it.y  N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faqlN  --------------------------- pure personal opinion ---------------------------E         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.comi   ------------------------------   Date: 1 Jul 2003 12:57:55 -0700y0 From: jason.mccormick@lexi.com (Jason McCormick)% Subject: Re: VMS backup to NFS shareso= Message-ID: <7a78a31c.0307011157.2efe5e9e@posting.google.com>   J > > I was hoping that a VMS guru could answer a question for me.  I have aJ > > VAXStation 4000 90A and I'm attempting to get a usable backup solutionG > > for it.  The tape unit I've been using on it requires a data stream<I > > speed that the VAX simply can't keep pushing out to the unit and it'sr$ > > casuing physical damage.  [snip] >  > Whoa, there!!! >  > Care to elucidate??? > F > How can BACKUP be causing physical damage to a tape, drive, etc. ???  C  According to the vendors of the unit, if the VAX isn't pushing outgE enough data to fill the stream for continuous writing, the tape driveaB back-catches and stops and starts, etc. over and over.  They claimC that this puts an enormous amount of wear and tear on the tapes anduA heads inside the unit and the repeated failures I'm seeing is the'F result of this.  I have an identical unit on a large, fast server withF an LVD card and the unit has performed flawlessly.  The combination ofE a slower unit and the SCSI-1 is appearantly not enough to support the(E unit. They've actually gone as far as to replace the entire unit so I D know it's not a lemon unit.  I've been dealing with this issue for 3> years so I'm trying to remove the tape unit from the equation.   ------------------------------  # Date: Tue, 01 Jul 2003 20:46:08 GMT ) From: Andrew Balaam <abalaam@yahoo.co.uk>s% Subject: Re: VMS backup to NFS sharesa5 Message-ID: <20030701.20460800.1228794956@imagnu.geo>f  I We've had repeated problems with both DAT and 8mm Exabyte units over the=t =20gH years - the VAXstations we have are just not fast enough to get these=20I drive streaming, so they have to keep starting, stopping and going back.=t =20iH 8mm Exabyte are worse - the system was really designed for video, not=20G data - too much of the tape is wrapped around the head. Writing file=20bI markers is very slow - and with the VMS using ANSI labelling, the label =t   itself is a file as I recall.r  , tape position lost errors were quite common.  6 >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<  I On 01/07/03, 20:57:55, jason.mccormick@lexi.com (Jason McCormick) wrote =0  ' regarding Re: VMS backup to NFS shares:S    I > > > I was hoping that a VMS guru could answer a question for me.  I ha=s ve aI > > > VAXStation 4000 90A and I'm attempting to get a usable backup solu=w tionI > > > for it.  The tape unit I've been using on it requires a data strea=  myI > > > speed that the VAX simply can't keep pushing out to the unit and i=- t's-& > > > casuing physical damage.  [snip] > >  > > Whoa, there!!! > >n > > Care to elucidate??? > >MI > > How can BACKUP be causing physical damage to a tape, drive, etc. ???=c    E >  According to the vendors of the unit, if the VAX isn't pushing outeG > enough data to fill the stream for continuous writing, the tape drive-D > back-catches and stops and starts, etc. over and over.  They claimE > that this puts an enormous amount of wear and tear on the tapes andoC > heads inside the unit and the repeated failures I'm seeing is theeI > result of this.  I have an identical unit on a large, fast server with=h  I > an LVD card and the unit has performed flawlessly.  The combination of=s  G > a slower unit and the SCSI-1 is appearantly not enough to support the G > unit. They've actually gone as far as to replace the entire unit so I F > know it's not a lemon unit.  I've been dealing with this issue for 3@ > years so I'm trying to remove the tape unit from the equation.   ------------------------------  # Date: Wed, 02 Jul 2003 00:44:06 GMTl From: Rob.Buxton@wcc.govt.nz% Subject: Re: VMS backup to NFS shares-# Message-ID: <3f022a17.4298453@news>-  7 On Mon, 30 Jun 2003 21:45:19 -0500, "David J. Dachtera"  <djesys.nospam@fsi.net> wrote:   >Jason McCormick wrote:l >> eI >> I was hoping that a VMS guru could answer a question for me.  I have afI >> VAXStation 4000 90A and I'm attempting to get a usable backup solutiontF >> for it.  The tape unit I've been using on it requires a data streamH >> speed that the VAX simply can't keep pushing out to the unit and it's# >> casuing physical damage.  [snip]n >. >Whoa, there!!!e >r >Care to elucidate???M >ME >How can BACKUP be causing physical damage to a tape, drive, etc. ???( >h >--  >David J. Dachtera >dba DJE Systems >http://www.djesys.com/e >S) >Unofficial Affordable OpenVMS Home Page:   >http://www.djesys.com/vms/soho/  F It's becoming quite a problem for a number of architectures. There areF reports of the newer SDLT Drives wearing out far quicker than the MTBF9 figures suggest because of what is termed "showshining". m   ------------------------------  % Date: Tue, 01 Jul 2003 20:37:43 -0500t1 From: "David J. Dachtera" <djesys.nospam@fsi.net>n% Subject: Re: VMS backup to NFS sharesf' Message-ID: <3F023767.C16212A6@fsi.net>h   Jason McCormick wrote: > L > > > I was hoping that a VMS guru could answer a question for me.  I have aL > > > VAXStation 4000 90A and I'm attempting to get a usable backup solutionI > > > for it.  The tape unit I've been using on it requires a data stream.K > > > speed that the VAX simply can't keep pushing out to the unit and it'se& > > > casuing physical damage.  [snip] > >@ > > Whoa, there!!! > >  > > Care to elucidate??? > >1H > > How can BACKUP be causing physical damage to a tape, drive, etc. ??? > E >  According to the vendors of the unit, if the VAX isn't pushing outaG > enough data to fill the stream for continuous writing, the tape drivet9 > back-catches and stops and starts, etc. over and over. o  5 This is going to be true of any streaming tape drive.    > They claimE > that this puts an enormous amount of wear and tear on the tapes andsC > heads inside the unit and the repeated failures I'm seeing is thee > result of this.    Pure, unadulterated horse-shit!   < The only cause attributable to this would be tapes that shedG excessively, and that's going to contaminate *ANY* drive, regardless ofa how much start/stop goes on.  7 > I have an identical unit on a large, fast server withhH > an LVD card and the unit has performed flawlessly.  The combination ofG > a slower unit and the SCSI-1 is appearantly not enough to support thei > unit.   = I'd "blame" SCSI-I first, but only after exhausting all othereB possibilities. I had SCSI-I drives direct-connected to small VAXes% before, with no appreciable problems.   B You *HAVE* tuned your "backup" account for the requirements of theE BACKUP utility, right? Huge working-set? Lots of FILLM, DIOLM, BIOLM,t etc.?i  A > They've actually gone as far as to replace the entire unit so I F > know it's not a lemon unit.  I've been dealing with this issue for 3@ > years so I'm trying to remove the tape unit from the equation.  F Go ahead and replace it with something better then. The VAX is not theG problem, the drive is: it can't take it, so it doesn't deserve to be inf your equipment room.   -- t David J. Dachterao dba DJE Systemsn http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Tue, 01 Jul 2003 20:43:20 -0500G1 From: "David J. Dachtera" <djesys.nospam@fsi.net>l% Subject: Re: VMS backup to NFS shares>' Message-ID: <3F0238B8.F1D49446@fsi.net>i   Rob.Buxton@wcc.govt.nz wrote:i > 9 > On Mon, 30 Jun 2003 21:45:19 -0500, "David J. Dachtera".  > <djesys.nospam@fsi.net> wrote: >  > >Jason McCormick wrote:M > >>K > >> I was hoping that a VMS guru could answer a question for me.  I have aeK > >> VAXStation 4000 90A and I'm attempting to get a usable backup solution.H > >> for it.  The tape unit I've been using on it requires a data streamJ > >> speed that the VAX simply can't keep pushing out to the unit and it's% > >> casuing physical damage.  [snip]e > >h > >Whoa, there!!!s > >e > >Care to elucidate???o > >aG > >How can BACKUP be causing physical damage to a tape, drive, etc. ???p > H > It's becoming quite a problem for a number of architectures. There areH > reports of the newer SDLT Drives wearing out far quicker than the MTBF: > figures suggest because of what is termed "showshining".  @ Ours (SDLT-320, 16MB/sec uncompressed) are fed via fibre-channel+ (100MB/sec). I don't see this as a problem.0  G One caveat I will offer, however: Quantum SDLT-320s do not appear to besE 100% VMS-compatible out of the box. I have 12, and can presently only9F use seven(7) of them due to parity errors, errors positioning the tape and just general "flakiness"..  G Sure wish I could convince my VAR to swap 'em out for HP-badged drives!r   --   David J. Dachterah dba DJE Systemsk http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/o   ------------------------------   End of INFO-VAX 2003.361 ************************