1 INFO-VAX	Fri, 02 Jul 2004	Volume 2004 : Issue 363       Contents: Re: A lint Utility for OpenVMS Re: A lint Utility for OpenVMS Re: A lint Utility for OpenVMS Re: A lint Utility for OpenVMS Re: A lint Utility for OpenVMS Re: A lint Utility for OpenVMS+ Re: Accuweather video mentions VMS (TWICE!) + Re: Accuweather video mentions VMS (TWICE!) + Re: Accuweather video mentions VMS (TWICE!) * Re: FTP client to understand ODS-5 volumes= Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article  Linux becoming windoze clone! ! Re: Linux becoming windoze clone!  mbxtap
 Re: mbxtap* Re: Memory test diags for Alphastation 255+ Re: More LAT questions on LAT$SYSTARTUP.COM  Re: OpenVMS .... no news?  Re: OpenVMS .... no news?  Re: OpenVMS .... no news? 3 Re: Process quotas identical, but one machine fails 3 Re: Process quotas identical, but one machine fails 3 Re: Process quotas identical, but one machine fails " Re: RAID Array 450 and Controllers Re: Secondary DNS problem ' Re: slap in the face again... thanks HP P Re: Volume shadowing between FC Storage at different sites, and the allocation c  F ----------------------------------------------------------------------  $ Date: Fri, 2 Jul 2004 09:38:39 +0200% From: "Fred Zwarts" <F.Zwarts@KVI.nl> ' Subject: Re: A lint Utility for OpenVMS . Message-ID: <cc32kj$ghc$1@info.service.rug.nl>  . "Scott" <lsk55@hotmail.com> wrote in message =7 news:926edf3b.0406301523.602f3d3d@posting.google.com... / > Does anyone know of a lint utility for DEC C?  >=20I > (It would be nice to find one for DEC COBOL, too... but I'm afraid to = 	 ask!) :-)  >=20 > Thank you! >=20	 > --Scott   7 We use the platform independent FlexeLint from Gimpel =  (http://www.gimpel.com/). ; It's diagnostics are even more complete that those of DECC. I It also allows easy configuration, like skipping diagnostics for header =  files  which are outside your control.   J If you create software which should build on many different platforms it = is=20 - nice to have everywhere the same diagnostics.    F.Z.   ------------------------------  % Date: Fri, 02 Jul 2004 10:44:15 -0000 / From: Thomas Dickey <dickey@saltmine.radix.net> ' Subject: Re: A lint Utility for OpenVMS 0 Message-ID: <10eaf3v6lm18je0@corp.supernews.com>  4 Ed Vogel <edward.vogel_stop_the_spam.@hp.com> wrote:  A > Interesting...this is one of the very few complaints I've heard < > about the additional diagnostics the compiler will output.D > Are there certain diagnostics that you think should not be output? > We do value any feedback.   E offhand - I don't have a particularly current case in mind - I recall H being annoyed that DEC's compilers would warn about things in the system? headers (ctype.h was a particular issue).  Has that been fixed?   I (The warnings themselves are useful, but being told about things that the ' developer cannot reasonably fix is not)    --   Thomas E. Dickey http://invisible-island.net  ftp://invisible-island.net   ------------------------------  % Date: Fri, 02 Jul 2004 10:41:08 -0000 / From: Thomas Dickey <dickey@saltmine.radix.net> ' Subject: Re: A lint Utility for OpenVMS 0 Message-ID: <10eaeu4kkri5j70@corp.supernews.com>  - Keith A. Lewis <lewis@probe.mitre.org> wrote:   N > Nobody "needs" lint.  As others have pointed out, DEC C has some pretty goodL > checks built into the compiler.  They get "better" with every release.  SoJ > much so that upgrading C and C++ compilers has become more work than our+ > reduced VMS programming staff can handle.   I The warnings are good, but I haven't seen a compiler that looks at all of L the objects you list for linking and tells you which functions are no longer? used.  (static functions are checked by a number of compilers).    --   Thomas E. Dickey http://invisible-island.net  ftp://invisible-island.net   ------------------------------   Date: 2 Jul 2004 08:41:41 -0500 - From: Kilgallen@SpamCop.net (Larry Kilgallen) ' Subject: Re: A lint Utility for OpenVMS 3 Message-ID: <ziCxsjcRDuRM@eisner.encompasserve.org>   b In article <10eaeu4kkri5j70@corp.supernews.com>, Thomas Dickey <dickey@saltmine.radix.net> writes:/ > Keith A. Lewis <lewis@probe.mitre.org> wrote:  > O >> Nobody "needs" lint.  As others have pointed out, DEC C has some pretty good M >> checks built into the compiler.  They get "better" with every release.  So K >> much so that upgrading C and C++ compilers has become more work than our , >> reduced VMS programming staff can handle. > K > The warnings are good, but I haven't seen a compiler that looks at all of N > the objects you list for linking and tells you which functions are no longerA > used.  (static functions are checked by a number of compilers).   & That is something I would do with SCA.  G But the typical VMS approach is to use an object library, so the notion 4 of "objects you list for linking" is a bit outdated.   ------------------------------  # Date: Fri, 02 Jul 2004 15:09:12 GMT % From: "John Vottero" <John@mvpsi.com> ' Subject: Re: A lint Utility for OpenVMS 9 Message-ID: <sUeFc.146$m%7.12@newssvr19.news.prodigy.com>   @ "Ed Vogel" <edward.vogel_stop_the_spam.@hp.com> wrote in message+ news:CXYEc.5192$z43.935@news.cpqcorp.net...  > ; > "Keith A. Lewis" <lewis@PROBE.mitre.org> wrote in message * > news:cc12cq$k84$1@newslocal.mitre.org... > > K > > Nobody "needs" lint.  As others have pointed out, DEC C has some pretty  > goodJ > > checks built into the compiler.  They get "better" with every release. SoL > > much so that upgrading C and C++ compilers has become more work than our- > > reduced VMS programming staff can handle.  > > A > Interesting...this is one of the very few complaints I've heard < > about the additional diagnostics the compiler will output.D > Are there certain diagnostics that you think should not be output? > We do value any feedback.  >   L In general, I like all the help and hints I can get from a compiler.  My one complaint is with   H %CC-I-QUESTCOMPARE2, In this statement, the unsigned expression "var" isK being tested to see if it is greater than zero.  This might not be what you 	 intended.    You get this with code like:   unsigned int var;    if (var > 0)...   K I think the warning is flat out wrong.  There's nothing wrong with checking K to see if an unsigned integer is greater than zero.  An unsigned integer is K either equal to zero or greater than zero.  If I change the test to be (var I != 0) then the warning goes away and that doesn't make sense, testing for L not equal to zero implies that I think the variable could be greater than or2 less than zero and it can never be less than zero.  ' I would say to just dump QUESTCOMPARE2.    John Vottero   ------------------------------  * Date: Fri, 2 Jul 2004 15:25:50 +0000 (UTC), From: lewis@PROBE.mitre.org (Keith A. Lewis)' Subject: Re: A lint Utility for OpenVMS . Message-ID: <cc3upu$75k$1@newslocal.mitre.org>   "Ed Vogel" <edward.vogel_stop_the_spam.@hp.com> writes in article <CXYEc.5192$z43.935@news.cpqcorp.net> dated Thu, 01 Jul 2004 18:43:46 GMT: > : >"Keith A. Lewis" <lewis@PROBE.mitre.org> wrote in message) >news:cc12cq$k84$1@newslocal.mitre.org...  >>J >> Nobody "needs" lint.  As others have pointed out, DEC C has some pretty >good M >> checks built into the compiler.  They get "better" with every release.  So K >> much so that upgrading C and C++ compilers has become more work than our , >> reduced VMS programming staff can handle. >>@ >Interesting...this is one of the very few complaints I've heard; >about the additional diagnostics the compiler will output. C >Are there certain diagnostics that you think should not be output?  >We do value any feedback.  E There is no single change that I disagree with.  However, the path of J gradually increasing strictness with each compiler release is maddening.  F The /STANDARD= idea is good but it would be better if I could say, forI example: /STANDARD=DECC6.4, getting the bug fixes and new features of 6.6  without the additional lint.  ; >Also, it should be simple to just disable any new messages : >you don't want to see.  They should not present difficult< >compiler upgrade problem.  On the other hand, maybe there's >something we don't understand.   H Yes I do know about disabling specific warnings, and I have done that inL some past upgrade cycles.  Much of my current problem is that the code/staff  ratio is not what it used to be.  0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------   Date: 2 Jul 2004 08:11:09 -0700 1 From: keithparris_NOSPAM@yahoo.com (Keith Parris) 4 Subject: Re: Accuweather video mentions VMS (TWICE!)= Message-ID: <cf15391e.0407020711.41e39aa2@posting.google.com>   o "Peter Weaver" <WeaverConsultingServices@sympatico.ca> wrote in message news:<2jogvgF13v4e6U1@uni-berlin.de>... G > http://h71000.www7.hp.com/openvms/brochures/accuweather/accunews.html     The URL for this has changed to:B http://h71000.www7.hp.com/openvms/brochures/accuweather/index.html   Sue sent out this update:  ---  Dear Folks,   F The following url is a link to an excellent customer testimonial videoS from Accuweather http://h71000.www7.hp.com/openvms/brochures/accuweather/index.html F Many thanks to Marc Courchesne for making this video and all the otherE OpenVMS customer videos happen.  And of course many thanks to our web F master Warren Sander for making this available to everyone on the web.   ------------------------------  # Date: Fri, 02 Jul 2004 16:30:51 GMT - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 4 Subject: Re: Accuweather video mentions VMS (TWICE!)@ Message-ID: <5a10410e1bbbbaf10c4a6853bc7d0fa0@news.teranews.com>   Keith Parris wrote: " > The URL for this has changed to:D > http://h71000.www7.hp.com/openvms/brochures/accuweather/index.html   <tongue in cheek mode>  N Well, there you go... yet another perfect example of HP purposefully confusingI any potential VMS customer by shifting files around.... Just like grocery N stores who move stuff around to force customers to stumble onto other productsJ and buy those other products instead of what they had originally intended.I Proof that HP has a secret consipiracy to get VMS customers to migrate to L HP-UX by forcing them to browse more onto HP's web site and stumble on HP-UX8 pages while they were searching for relocated VMS pages.   :-) ;-) :-) :-) :-) :-) :-)    </sorry, it is friday>   ------------------------------  # Date: Fri, 02 Jul 2004 17:01:40 GMT " From:   VAXman-  @SendSpamHere.ORG4 Subject: Re: Accuweather video mentions VMS (TWICE!)0 Message-ID: <00A343BD.30DC270B@SendSpamHere.ORG>  q In article <cf15391e.0407020711.41e39aa2@posting.google.com>, keithparris_NOSPAM@yahoo.com (Keith Parris) writes: p >"Peter Weaver" <WeaverConsultingServices@sympatico.ca> wrote in message news:<2jogvgF13v4e6U1@uni-berlin.de>...H >> http://h71000.www7.hp.com/openvms/brochures/accuweather/accunews.html > ! >The URL for this has changed to: C >http://h71000.www7.hp.com/openvms/brochures/accuweather/index.html   1 This is old news... and the same .WMV file too ;(    --  B http://www.legacy-2000.com  for the *best* OpenVMS system securityC                             solutions that others only claim to be.  --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------   Date: 2 JUL 2004 12:51:06 GMT 4 From: karcher@thuria.waisman.wisc.edu (Carl Karcher)3 Subject: Re: FTP client to understand ODS-5 volumes 5 Message-ID: <2JUL04.12510609@thuria.waisman.wisc.edu>   6 In a previous article, Dirk Munk <munk@home.nl> wrote:  S ->You could give WS-FTP a try. A have a rather old pre ods5 lite version, and even  K ->that is capable of using ods5 names! (I did not do extensive trials, but  " ->lowercase names etc. work fine).  = That works provided the filenames don't have any ^ characters K in them. It won't transfer Tx^_plans.doc for example. I tried the eval copy , of their WS_FTP home and has the limitation.  F One thing I found was it's not a good idea to have a lower case ".dir"G extension on directory files. As created by VMS or Pathworks, .DIR will F be used. You can rename to .dir (as done by the convert_fname2 utilityG from Dave Jones to convert pathworks ODS-2 names to ODS-5 names without E changing the revision date) that only appears to have one effect: ftp & clients won't see that as a directory.   --G -- Carl Karcher, Waisman Computing Services, Waisman Center, UW-Madison 2 --                      karcher@waisman.wisc.edu     ------------------------------  $ Date: Fri, 2 Jul 2004 02:04:58 -0400* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <cL2dnZ9zlpZJZ3nd4p2dnA@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:9V5G8btuN7fU@eisner.encompasserve.org... @ > In article <1cGdnc3uNb7upHnd4p2dnA@metrocast.net>, "Bill Todd"  <billtodd@metrocast.net> writes: > > < > > "Rob Young" <young_r@encompasserve.org> wrote in message >  > >>D > >> But that would be very difficult given that Intel is projectingD > >> 50-100% greater performance Itanium vs. Xeon.  Xeon64 certainly9 > >> won't be a candidate to run the much faster Itanium.  > > E > > You're confused as usual, Rob.  If you read the article which you  yourselfJ > > cited, it makes it clear that Itanic is not anticipated to have betterF > > *per-core* performance than Xeon (even 3 years from now, and given Intel's H > > rather abysmal history of predicting relative Itanic performance one might K > > take that with a large grain of salt) - it will just have more cores on  the F > > chip, hence higher *aggregate* chip performance for those who have= > > readily-partitionable loads suitable for multi-threading.  > >  > 5 > And so my mistake was to not to highlight per-chip?   I Well, yuh...  When you make a statement like "Xeon64 certainly won't be a I candidate to run the much faster Itanium", just exactly how do you expect  people to interpret it?      After all,> > the article states what you point it.  It wasn't as if I was< > trying to do some misdirection.  And by the way, how couldE > Itanium NOT have better SpecFp and better tpmC per-core performance  > than Xeon?  L By using significantly lower-performing cores than a linear extrapolation of today's Itanics would suggest.  L Montecito is already in trouble in this regard:  its two cores won't be ableI to clock noticeably faster than today's Madison core even if Intel *does* K solve its 90 nm. process problems, because the pair would generate too much H heat.  Move to 4 or 8 cores in Tukwila, and the problems only get worse.  C It's entirely possible that an 8-core Tukwila could offer twice the I aggregate chip performance of a dual-core Xeon without being able to come H anywhere near it in per-core performance, and even a 4-core Tukwila thatA doubled dual-core Xeon performance would clearly offer only equal   performance on a per-core basis.  H By the way, since the article that you cited claims that Itanic offers aK 30% - 50% per-core performance advantage over Xeon *today* in database use, G it's instructive to note that the actual lead that Itanic enjoys at the I 4-processor node size in TPC-C (in an apples-to-apples, SQL Server to SQL I Server comparison) is only about 18% - most or all of which can likely be K attributed to the fact that the Itanic system has twice the RAM of the Xeon L system and uses nearly twice as many disks in the test configuration.  GivenH that Intel can't even get *today's* performance comparisons right, theirJ ability to forecast future relative performance would be questionable evenJ if they had not established such an absymal record in such fortune-telling in the past.   ...   D > Itanium gets much stronger in SpecInt2000 - probably in Montecito.  J Why?  Do you have any information that suggests significant changes in theG Montecito core from McKinley/Madison?  The only change I've heard of is K primitive SMT - and it's not clear whether that's been there (unenabled and - undisclosed, as it was in P4) from the start.    ...   : > http://www.midrangeserver.com/mid/mid032404-story04.html > 1 > Garrison said that the Itanium core is half the J > size of the Xeon core, which means that Intel will be able to cram twice asF > many Itanium cores on a single chip for a given chip making process.  F C'mon, Rob - you're not *that* dumb (though Morgan often seems to be).  I 1.  Just what part of the fact that cache already consumes more than half L the area on the 'processor' die is escaping you?  If you need more cache dieK area than processor area for each core on the chip, then simply halving the L core size won't get you anything like twice the cores on a die if you retainL a balanced cache component for them (not to mention that Itanic needs *more*L cache per core than Xeon or Opteron to perform competitively with them).  SoG if Intel actually does place twice as many Itanic cores on a die as x86 L cores, that Itanic die is either going to be a hell of a lot bigger than theA x86 die or is going to be extremely cache-starved compared to it.   J 2.  Not to mention the fact that the real question is not how much smallerD than the Xeon core the Itanic core is, but how much smaller than theL Banias/Dothan (and, of course, Opteron) core it is.  Hadn't you noticed thatK Intel is finally admitting that dozens of pipeline stages may make for good ( clock-rate marketecture but little else?  H After this point, you began wandering around in a daze which it would beL uncharitable to comment upon in detail (especially as much of that wandering5 was predicated on some of your misconceptions above).    - bill   ------------------------------   Date: 2 Jul 2004 05:06:05 -0700 ' From: icerq4a@spray.se (David Svensson) F Subject: Re: Intel Itanium's very survival in doubt - inquirer article= Message-ID: <734da31c.0407020406.1ac58a16@posting.google.com>   d "Bill Todd" <billtodd@metrocast.net> wrote in message news:<aOadnTWqwp6q0nndRVn-sQ@metrocast.net>...6 > "David Svensson" <icerq4a@spray.se> wrote in message9 > news:734da31c.0407010414.40dc7918@posting.google.com...  >  > ...  > A > > When I watched Intel presentations in 1997/1998 there were no I > > sightings that Intel wanted to discontinue x86. IA64 was at that time J > > not planned to be a desktop CPU. There may have been hopes before that5 > > time that IA64 would dominate the desktop though.  > J > I've heard multiple people state that around 1994-5 Intel was suggestingE > that at least verbally (though does not seem to have committed such M > statements to the Web for posterity).  IIRC 2003 was the year they expected + > the change-over to be nearing completion.    That is most likely correct.   > >  > > > D > > > When they realised that IA64 was an uncompetitive architecture >  (cost/time toN > > > develop, heat generation, compiler complexity etc), Intel did admit that >  IA64 N > > > would not become industry standard (aka: would not replace the 8086). ToJ > > > anyone without any financial ties to Intel, that was a clear message >  that IA64L > > > had little future and gave much more credibility to all the statements >  preB > > > June 25 from Digital Alpha engineers on how flawed IA64 was. > > C > > I think you are confusing the IA64 architecture and the current G > > Itanium implementation. Yes, there have been problems, but the heat A > > generation and being "uncompetitive" are not tied to the IA64  > > architecture.  > 6 > Could you provide evidence for that last statement?   / No, but have heard it from pretty good sources.    > While any architectureK > can be emulated underneath by something rather significantly different in N > order to avoid some of its weaknesses (witness x86), those weaknesses remainD > tied to the upper architecture - they're just being worked around.  6 Yes, but x86 has had more time to evolve than Itanium.  D > The IA64 'architecture' seems pretty inextricably tied to the EPICM > philosophy of in-order execution.  I haven't yet seen any evidence, real or H > theoretical, that this approach can achieve competitive performance onN > typical commercial workloads (i.e., those without the regularity of FP-styleE > code) without excessive power (and, for that matter, on-chip cache) N > requirements when compared with existing OoO architectures (POWERx, Opteron,N > Alpha, PA-RISC, and even IA32 - though its power requirements have increasedL > lately - come to mind; I might include SPARC64 as well, but don't know howH > much power it requries).  And the fact that both hardware and compilerD > development efforts significantly exceeded those of other existingM > architectures (if for no other reason than that Itanic was breaking so much L > new ground, though I'd suggest in an absolute sense as well) is really not > in question.  F I think Itanium is competitive today, not outstanding, but competitiveD in commercial workload. What would an Itanium core of today with EV7E system features do? Probably very good. Not impossible to do either I F think. Remove 1Mb L3 cache and put EV7 things there. I think the power* requirements of those things will add 10W.  ? It will be interesting to see if they will make an out-of-order 
 version...   ------------------------------   Date: 2 Jul 2004 05:12:29 -0700 ' From: icerq4a@spray.se (David Svensson) F Subject: Re: Intel Itanium's very survival in doubt - inquirer article= Message-ID: <734da31c.0407020412.5fe9a2dd@posting.google.com>   d "Bill Todd" <billtodd@metrocast.net> wrote in message news:<1cGdnc3uNb7upHnd4p2dnA@metrocast.net>... > M > Many servers do run such loads.  But for single-thread loads, it's entirely I > possible that Xeon could emulate Itanic with acceptable performance (at N > least if Xeon's 64-bit performance is somewhere nearly as good as Opteron's,- > something which has yet to be ascertained).   M You usually have good comments, but this one was bad. You have to admit that.   B Emulating IA64 on x86-64 would not provide acceptable performance.  ) You know more than that to understand it.    ------------------------------   Date: 2 Jul 2004 05:15:37 -0700 ' From: icerq4a@spray.se (David Svensson) F Subject: Re: Intel Itanium's very survival in doubt - inquirer article< Message-ID: <734da31c.0407020415.844ca5e@posting.google.com>  w JF Mezei <"jfmezei"@spamnot@teksavvy.com> wrote in message news:<381a0949de8573364fe44b524775ffca@news.teranews.com>...  > Rob Young wrote:S > > > My guess is that 3 years from now, Intel may release an IA64 emulator running H > > > on an 8086 (instead of the original plan to emulate 8086 on IA64). > > K > >         But that would be very difficult given that Intel is projecting : > >         50-100% greater performance Itanium vs. Xeon.  >  > [ > Yeah, just liek Intel was projecting that Merced would have truly impressive performamce.  >   B Intel explicitly said that Merced would not have good performance.  J They did believe and to some degree do believe in EPIC performance though.   ------------------------------  % Date: Fri, 02 Jul 2004 13:42:17 +0100 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> F Subject: Re: Intel Itanium's very survival in doubt - inquirer article0 Message-ID: <cc3l79$91o$1@new-usenet.uk.sun.com>  
 nobody wrote:  > Bill Todd wrote: > M >>Sun clearly still does:  otherwise, under its current pressures it would be L >>heading full-tilt toward AMD64 rather than pressing forward on 3 differentG >>SPARC fronts (two internally for the future, plus one using Fujitsu's 9 >>current - and eminently respectable - SPARC64 product).  >  > O > Hasn't sunb for all practical purposes abandonned in-house development of new O > cores for Sparc, with only tweaks of exsiting generations still planned, with I > reliance on Fujitsu to provide the development of the new generations ?  >   + Forget what Rob Young wants you to beleive.   B Sun hasn't abandoned SPARC development au-contraire Sun canned oneA processor development UltraSPARC V while announcing that it would A be replaced by another design Rock which no-one knew about except  in vague rumours.   > The canning of USV does however leave Sun with a temporal hole= in our product range hence the agreement to work with Fujitsu 9 on a joint development of the followon to Sun's USIV+ and @ Fuji's Primepower range based on SPARC64 which will be available# before Rock based systems could be.   C Anyone reading and placing any credence at all in the sage comments > of Mr Young will also be suprise to discover that Sun has just< taped out Niagara its first radical CMT processor which Rock+ will be the high end companion product for.     P http://news.com.com/Sun+completes+'Niagara'+chip+design/2100-1006_3-5210561.html     > I >>Let's not forget AMD, either.  So far, there's no significant area that - >>Opteron doesn't address better than Itanic   >  > N > My view os Opteron and intels version of 64 bit 8086 is that they still lackN > some of the enterprise features that allow not only for large scale systems,< > but also specific functiosn (such as lockstep for Tandem). >   D Well appart from Lockstep which is really only of interest to Tandem8 what other features do you think are missing from AMD64.  = 64bit support, well no although again if you had been reading > the drivel posted by some Itanium advocates and HP empoyees to= this group your might be forgiven for thinking that AMD64 was > still only 32bit. (It isn't BTW) its just as 64bit as Itanium.  < SMP interconnect support, well no again AMD does pretty wellC it avoids using the shared Frontside Bus (used by Xeon and Itanium) : in favour of the point to point HyperTransport which is anA alltogether more sensible approach for building 1-4 way SMP boxes @ and which is no impediment to building large SMP systems either.  = Remember all large SMP Itanium based systems are saddled with > being built out of building blocks based on 1-4 CPU's attached to a shared Frontside Bus.  P > Intel has a vested interest not to include those features in its 8086 in orderL > to save face with IA64 for at least the next 3 years. But AMD has a vestedB > interest to include those features ASAP to cause Intel problems. >   A Well whatever the motives of AMD and Intel the fact is that AMD's & strategy has worked and Intels hasn't.   > L >>While the x86 ISA carries a quarter-century's worth of historical baggage,C >>I'll suggest that it still manages to move it along right smartly  >  > O > In fairness, Intel recently admitted that it will slow down the "higher clock J > speeds" on its 8086s because it had reached some payback limits and willL > instead start to concentrate on higher throughput per cycle (either better, > design, more cache and/or multiple cores). >   @ And applying the same decision criteria to Itanium would lead to@ exactly the same decision with Itanium as well except that thereA is no simpler more efficient Itanium core lying around to cut and 3 paste accross a die nor is there ever likely to be.   P > Nevertheless, the 8086's architecture has allowed it to reach the 3ghz (if notP > higher this week, I don't check this often) clock speed while the more complex0 > architectures are still at about half of that.  C 3.6, you will however find that Intel are now back pedaling hard on A their Mhz is best claims, this is because their future is in fact ? based on the Pentium M core which is not designed to clock at a @ high clock rate but which is more efficient than P4/Xeon or even- worse Prescott/Noncona at a given clock rate.    Regards  Andrew Harrison    ------------------------------  % Date: Fri, 02 Jul 2004 13:55:33 +0100 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> F Subject: Re: Intel Itanium's very survival in doubt - inquirer article0 Message-ID: <cc3m05$98m$2@new-usenet.uk.sun.com>   Dave Gudewicz wrote:I > I looked through the slides that Intel presented back in April  Saw the L > Tejas and Jayhawk mentioned.  They are or were follow-ons for the PrescottJ > and Xeon (after Nocona) respectively.  They seemed to have nothing to doM > with Itanium.  So while some of the IA-32 plans were canned or changed, the ) > IA-64s were not.  Not that I could see.  >   @ It was rumoured that Tejas and Jayhawk as well as inheriting the< extended NetBurst Pipeline from Prescott and Nocona (So good@ they designed it three times) were also expected to get features
 from Itanium.    Regards  Andrew Harrison    ------------------------------  % Date: Fri, 02 Jul 2004 13:53:12 +0100 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> F Subject: Re: Intel Itanium's very survival in doubt - inquirer article0 Message-ID: <cc3lro$98m$1@new-usenet.uk.sun.com>   Dr. Dweeb wrote: > JF Mezei" <"jfmezei wrote: > ! >>david20@alpha2.mdx.ac.uk wrote:  >>E >>>"Internally, Intel has basically given up hope on IPF becoming the E >>>defacto 64-bit architecture until Tukwilla in 2007. From the specs A >>>being bandied about, that chip looks to be another marvel (pun D >>>intended) from the Alpha team, but between now and then, there is >>>precious little." >> >>B >>IA64 may look much better in 3 years compared to IA64 today. Few >>people will debate this. >>B >>The *REAL* question is whether IA64 will progress as fast as its@ >>competing chips such as Power, 8086 and even Sparc during thatG >>period. And one could argue that it needs to progress faster in order  >>to catch up. >>D >>3 years from now, how will IA64 perform compared to whatever Power >>offers 3 years from now ?  >>G >>Remember that it was those very Alpha developpers that gave all those F >>presentations on how IA64 was a bad archictecture that would be veryE >>difficult to move as quickly as cleaner architectures. So no matter G >>how good the alpha guys are, if they are tasked to help improve a bad G >>architecture, there is no way that they can work the same miracles as ? >>they would have been able to do on a nice clean architecture.  >>@ >>IA64 will NEVER be industry standard. That "just wait 3 years"F >>statement from Intel is yet another "IA64 may not be impressive now,F >>but wait X years, and you'll see" statements. Heard those many times
 >>already. >  > L > Can anyone show me anywhere in writing where INTEL (not HP) have said thatJ > EPIC will become "industry standard", as distinct from a high end server% > chip for specialised applications ?  > B http://www.dhbrown.com/cffiles/RPPage.cfm?ID=2503375&DOC=148254036) http://www.theinquirer.net/?article=10203 X http://www.hp.com/products1/itanium/infolibrary/pdfs/ISS_Solutions_Whitepaper_062503.pdf  = I would caution that much of this stuff is not for the easily : nauseated and that if you are in this category it would be9 best to print this out and read it in your smallest room.    regards  Andrew Harrison    ------------------------------  % Date: Fri, 02 Jul 2004 14:00:39 +0100 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> F Subject: Re: Intel Itanium's very survival in doubt - inquirer article0 Message-ID: <cc3m9n$9g6$1@new-usenet.uk.sun.com>   Dave Gudewicz wrote:L > I remember when it was said that Alpha being sole sourced by DEC was a badN > thing.  Then around the same time, didn't DEC discover some Alpha secrets inM > some of Intel's chips which led to a march to the courts which led to Intel K > buying DECs then new fab plant for around 3/4 billion.  Then someone elseCH > started making the Alpha chip.  Intel also got DECs low-power and veryI > popular processor (StrongARM) which was found in many things like PDAs,U% > GPSs, DSPs and who knows what else.f >  >   4 I think that ARM themselves would be rather suprised' to discover that StrongARM was Digitalse   http://www.arm.com   Regards( Andrew Harrison < > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message/ > news:uSi$rsuVO7ri@eisner.encompasserve.org...t > F >>>I don't expect that. It has been obvious for atleast 4-5 years thatH >>>Itanium would not replace x86. Intel wanted a high-end chip with high7 >>>profit, otherwise they would have cancelled in 2001.r >>H >>Perhaps more important, Intel wants a chip for which they are the sole >>source, avoiding clones. >  >  >    ------------------------------  % Date: Fri, 02 Jul 2004 14:15:54 +0100iO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>qF Subject: Re: Intel Itanium's very survival in doubt - inquirer article0 Message-ID: <cc3n6a$9oh$1@new-usenet.uk.sun.com>   Rick Jones wrote: + > Bill Todd <billtodd@metrocast.net> wrote:i > F >>Let's see: the Itanic hardware-emulation box seems to achieve around9 >>10% - 15% of native Itanic performance running x86 code  >  > D > Always a good idea to be explicit about what that code is doing.   > @ > For example, some rather moldy data on DNS server performance: >  > <excerpt>e >       ? How much of the DNS Server/Bind workload is Kernel and how much 	 is user ?l     User is emulated Kernel isn't  9 Or put another way without that information what you haven' just presented is entirely meaningless.e   Regardsr Andrew Harrisont& > 		    DNS Server Performance SummaryC >      netperf DNS_RR test requesting across 1000 out of cup.hp.comc2 >                      "A" Transactions Per Second( > 		  hp server rx2600, 2x 1GHz Itanium2' > 		   Red Hat Advanced Workstation 2.1e > 			     HP-UX 11.22e >  > 4 >                              Native     Emulated  D >        Flavor                 IPF      x86/PA-RISC     % of native5 >                           +===========+===========+s> >      rh bind 8.3.4 O2     |   8,620   |   3,206   |       37> >      rh bind 9.2.2 O2     |   6,967   |   1,710   |       25> >      rh bind 9.3.0s O2    |   3,695   |   1,637   |       44> >      rh bind 9.3.0s O2 st |   4,722   |   2,279   |       48> >      rh bind 9.3.0s O2 mr |  33,012   |   9,265   |       285 >                           +===========+===========+n5 >      ux bind 4.9.11 O2    |  14,225   |    n/a    |d> >      ux bind 8.3.4 O2     |   9,768   |   3,102   |       32> >      ux bind 9.3.0s O2 st |   4,880   |   1,489   |       31> >      ux bind 9.3.0s O2 mr |  16,797   |   1,301   |       085 >                           +===========+===========+c > D > The magic decode for the "Flavor" column is rh == Red Had AdvancedE > Workstation 2.1, bind == the named from the specified distribution,-@ > 8.3.4 and 4.9.11 are full releases from the ISC, 9.3.0s is the> > December 17th "snapshot" of the 9.3.0 development version of@ > BIND. "O2" is the compiler optimization level - either -O2 forE > gcc/linux or +O2 for HP. A "st" means that the bits were configuredeH > and compiled single-threaded rather than multi-threaded. An "mr" means> > that the named.conf file included a "minimum-responses true"E > directive, which is a relatively new feature of the BIND named thatnG > minimized the quantity of possibly extraneous information placed intod > the DNS reply. >  > </excerpt> > G > Interpreting the middle column, if the row is "rh" then the emulationrF > is x86 (IIRC given the box and the bits, that would be HW emulation)> > if the row is ux then the emulation is PA (aries, software). > E > One of these days I hope to have a chance to run with newer bits aseE > the bits there are indeed rather old. I am not sure when that mighte > be.0 >  > rick jones   ------------------------------  $ Date: Fri, 2 Jul 2004 12:08:22 -0400* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <nJOdnUQHfNGjFXjdRVn-vg@metrocast.net>  4 "David Svensson" <icerq4a@spray.se> wrote in message7 news:734da31c.0407020412.5fe9a2dd@posting.google.com....7 > "Bill Todd" <billtodd@metrocast.net> wrote in messagec. news:<1cGdnc3uNb7upHnd4p2dnA@metrocast.net>... > >fF > > Many servers do run such loads.  But for single-thread loads, it's entirelyK > > possible that Xeon could emulate Itanic with acceptable performance (ateE > > least if Xeon's 64-bit performance is somewhere nearly as good asr
 Opteron's,/ > > something which has yet to be ascertained).  >:I > You usually have good comments, but this one was bad. You have to admit4 that.4 >0D > Emulating IA64 on x86-64 would not provide acceptable performance. > + > You know more than that to understand it.R  J You seem to have ignored the context of the statement:  it applied only toF those few applications (approaching zero today, and there's no obviousH reason that number should increase significantly unless Itanic sales do)K which would not also be able to run natively on the x86 platform - in other.D words, the same argument that people are using today to suggest thatH Itanic's x86 emulation is adequate (because any applications that reallyK care will be ported), except that the number of applications affected wouldo$ be far less in the case I described.   - bill   ------------------------------  $ Date: Fri, 2 Jul 2004 12:10:18 -0400* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <LeKdndmWMvcsFXjdRVn-tw@metrocast.net>  4 "David Svensson" <icerq4a@spray.se> wrote in message6 news:734da31c.0407020415.844ca5e@posting.google.com...< > JF Mezei <"jfmezei"@spamnot@teksavvy.com> wrote in message< news:<381a0949de8573364fe44b524775ffca@news.teranews.com>... > > Rob Young wrote:D > > > > My guess is that 3 years from now, Intel may release an IA64 emulator runningJ > > > > on an 8086 (instead of the original plan to emulate 8086 on IA64). > > >rB > > >         But that would be very difficult given that Intel is
 projecting; > > >         50-100% greater performance Itanium vs. Xeon.o > >e > > E > > Yeah, just liek Intel was projecting that Merced would have trulyr impressive performamce.s > >t >gD > Intel explicitly said that Merced would not have good performance.  J Not until relatively late in its development cycle:  originally, and untilJ at least 1999, Merced was the Great White Hope in the battle against RISC,H and was the platform that the ridiculous early (ca. 1995) suggestions of+ 2x - 3x performance superiority applied to.    - bill   ------------------------------  # Date: Fri, 02 Jul 2004 16:26:40 GMTo- From: JF Mezei <jfmezei.spamnot@teksavvy.com>sF Subject: Re: Intel Itanium's very survival in doubt - inquirer article@ Message-ID: <4808409459e108627ceccd07cbf81b7c@news.teranews.com>  ( Andrew Harrison SUNUK Consultancy wrote:6 > I think that ARM themselves would be rather suprised) > to discover that StrongARM was Digitalse >  > http://www.arm.com  N My impression was that while arm was owner of the IP, it was Digital engineersN who had turned the chip into a high performance low power succesfully and thatK it was using its fancy FAB to make StrongArms. So Digital has a big part in  StrongArm's success.   ------------------------------  # Date: Fri, 02 Jul 2004 16:19:44 GMTn- From: JF Mezei <jfmezei.spamnot@teksavvy.com>2F Subject: Re: Intel Itanium's very survival in doubt - inquirer article@ Message-ID: <8e24e5d31600003e182fd07b00218e79@news.teranews.com>   David Svensson wrote:nD > Emulating IA64 on x86-64 would not provide acceptable performance.  N But when you consider how many applications are only available on IA64 at thisM point in time and not available on 8086, the "unacceptable performance" wouldLQ only apply to a small set of programs on a system since the rest would be native.o  K For VMS, There is more software available on VAX-only than there is on IA64 L only. So a vax emulator on 8086 is more needed than an IA64 emulator. (oh, I forgot, it already exists).t  M Same applies to  HP-UX. And my bet is that there will be very little softwarepL available for NSK on IA64 only.  So customers are more likely to continue onK PA-RISC, Alpha and MIPS until they have a migration path to something otherp
 than IA64.   ------------------------------  # Date: Fri, 02 Jul 2004 16:21:13 GMTl- From: JF Mezei <jfmezei.spamnot@teksavvy.com>hF Subject: Re: Intel Itanium's very survival in doubt - inquirer article@ Message-ID: <1837a9e36ee07443bec1f5c2589fcfb8@news.teranews.com>   David Svensson wrote: D > Intel explicitly said that Merced would not have good performance.  G They said that after years of delays when they decided that they had to I unleash whatever they had at the time which had terrible performance. But H initially, it was to be the greatest thing since sliced bread, with EPIC# breaking RISC barriers etc etc etc.    ------------------------------  # Date: Fri, 02 Jul 2004 16:24:31 GMTd- From: JF Mezei <jfmezei.spamnot@teksavvy.com> F Subject: Re: Intel Itanium's very survival in doubt - inquirer article@ Message-ID: <6009f258fe398952e6774d3ea57f2b56@news.teranews.com>  ( Andrew Harrison SUNUK Consultancy wrote:D > Sun hasn't abandoned SPARC development au-contraire Sun canned oneC > processor development UltraSPARC V while announcing that it would C > be replaced by another design Rock which no-one knew about exceptc > in vague rumours.e  L What I had read is that V was abandonned because they found that 4 still hadN plenty of life into it and could be developped well into the time when Fujitsu8 would have its super Sparc (whatever its name is) ready.  G But my impression was that Sun and Fujitsu woudl be working together tou9 combine forces on Sparc from then on. Is that incorrect ?-   ------------------------------  % Date: Fri, 02 Jul 2004 12:10:30 -0400s( From: David Froble <davef@tsoft-inc.com>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article, Message-ID: <40E588F6.9030700@tsoft-inc.com>   Rob Young wrote:    H > 	Yep.  And some day these posts will be a chuckle.  For one of us ;-).    I Unfortunately for you Rob, your past posts are a chuckle for many, today.-     Dave   -- a4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Roadr Vanderbilt, PA  15486r   ------------------------------   Date: 2 Jul 2004 06:57:19 -0700h( From: bob@instantwhip.com (Bob Ceculski)& Subject: Linux becoming windoze clone!< Message-ID: <d7791aa1.0407020557.37eaa25@posting.google.com>  ) http://www.theinquirer.net/?article=16974f   ------------------------------  % Date: Fri, 02 Jul 2004 15:31:45 +0100o& From: Nic Clews <spamthis@[127.0.0.1]>* Subject: Re: Linux becoming windoze clone!' Message-ID: <cc3rp3$lk3$1@lore.csc.com>o   Bob Ceculski wrote:c  + > http://www.theinquirer.net/?article=16974   C Bob, it's bad practice just to post a URL without some description.H  G Anyway the article alleges that it's [linux] getting the look and feel - of Windows.   C As a user of Mandrake (from the point of view of replacing Windows eH myself), I agree. If you'd a sub 1-gig speed PC base handing around, do I grab the ISO's for mandrake and try it for yourself. You'll need about a CF 10 gig drive to install the whole lot. If you can install VMS, you'll  cope with this install.i  D Lindows have had to undergo a name change because, err, M$ seems to G think that it sounds too similar to Windows. Now that is another worth rL looking at (if you'll pardon the indirect pun) but it's not a free download.  F Bearing in mind that Mandrake is largely based on open source, as the C GNV project progresses, this is what we'll see more of under VMS...    -- e? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciencesb nclews at csc dot comu   ------------------------------   Date: 2 Jul 2004 04:20:13 -0700  From: ijm@uk2.net (I)o Subject: mbxtap = Message-ID: <384b6c37.0407020320.5448f244@posting.google.com>   ? There used to be a product named mbxtap sold by a very small uk-@ company called technosoft ltd. I last saw it about 10 years ago.  E mbxtap performed real time monitoring of a vms mailbox - each messagerE written to a specified mailbox or mailboxes was captured and could bee, viewed or saved to a file for later viewing.  , I am wondering what happend to this product.   ------------------------------  % Date: Fri, 02 Jul 2004 12:33:05 +0100 & From: Nic Clews <spamthis@[127.0.0.1]> Subject: Re: mbxtap>' Message-ID: <cc3ha4$i93$1@lore.csc.com>w   I wrote:  A > There used to be a product named mbxtap sold by a very small ukfB > company called technosoft ltd. I last saw it about 10 years ago. > G > mbxtap performed real time monitoring of a vms mailbox - each messagetG > written to a specified mailbox or mailboxes was captured and could beM. > viewed or saved to a file for later viewing. > . > I am wondering what happend to this product.   ?D  1 You can try MBOX, Neill Clift's mail box utility:a  , http://www.yrl.co.uk/~phil/pds/pds.html#MBOX   -- e? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciencesr nclews at csc dot come   ------------------------------  % Date: Fri, 02 Jul 2004 09:39:24 +0100 & From: Nic Clews <spamthis@[127.0.0.1]>3 Subject: Re: Memory test diags for Alphastation 255 ' Message-ID: <cc374d$f4e$1@lore.csc.com>d   Z wrote: > Nic Clews wrote: > 4 >>> What's the best way to test the system's memory? >  >  >> Power on.K >> If you were seeing memory errors, you'd likely see MACHINECHECK crashes. G >> VMs does a good job of maintaining data integrity, and in particular<F >> it's memory structures, and distinguishing the difference between a1 >> software corruption and a hardware corruption.a >  > > > Is it possible MACHINECHECK is being signaled and written toA > the console, but by the time I get to look at the display, onlyn4 > the Kernel Stack Not Valid error is on the screen?  ' Possibly, but only in these conditions:   D A second machine check prevents the error log being written (to the I error log buffers) so the error is never recorded, but even in this case e4 sometimes you will see a double machine check. Ouch.  / The point is, you'd always see a machine check.a  I If this is recurring, I'd get a terminal emulator, attach it to OPA0 and  C set the console as serial, and you'd catch all the information. We sF specifically do this with many of our servers, even if graphic headed # and capture using console software.   I If I were investigating the crash dump for this, I would look around the tF contents of the kernel stack (SHOW STACK in SDA) and try to translate E the contents, see if it matches anything in any applications you are m running.  H It has not been unknown that a badly programmed bit of code, running in I kernel mode, can leave "rubbish" on the stack, and the system falls over  G it, literally. So I'd look for likely suspects as well, who has kernel pH mode privilege (or an installed image with) and see when they were last G active. Chances are it was relatively recent in the operating system's c2 history (i.e. just a few scheduled processes ago).  H Nonpaged pool corruption (in contrast) can happen long, long ago before  that is discovered.e  G I'm not really favouring hardware problems, they are usually "hard" so  . that when its failed its failed, and thats it.  H I presume you have a crash dump, you look at the stack pointer, and the B stack grows from the bottom (i.e. higher memory addresses) up the @ screen. If you look at the current process a SHOW CALL and SHOW H CALL/NEXT will take you through what the current process was doing, and G may help. If you see IMGACT anywhere, you've got to the "bottom" where a the image started. -- e? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciencesa nclews at csc dot comr   ------------------------------  % Date: Fri, 02 Jul 2004 08:50:22 +0200 * From: Paul Sture <nospam@sture.homeip.net>4 Subject: Re: More LAT questions on LAT$SYSTARTUP.COM* Message-ID: <2kketfF3a2cvU1@uni-berlin.de>   Neil Cherry wrote:= > On Tue, 29 Jun 2004 21:48:03 -0500, David J Dachtera wrote:t >  >>Neil Cherry wrote: >>	 >>>[snip] R >>>OPENVMS-ALPHA-USER DEC             0  0     100    0.0  30-NOV-2004 30-NOV-2004R >>>OPENVMS-HOBBYIST   DEC             0  0     100    0.0  30-NOV-2004 30-NOV-2004	 >>>[snip]rR >>>VAX-VMS            DEC             0  0     A      0.0  30-NOV-2004 30-NOV-2004 >>! >>O.K. There's your VMS licenses.r >>J >>That said, I re-read the earlier post about dynamic rating and I believe1 >>the comment was made about interactive logins.   >  > 1 >>$ SET LOGINS/INTERACTIVE	! No value expression!c >  >   > MV3100$ SET LOGINS/INTERACTIVEC > %SET-I-INTSET, login interactive limit = 100, current interactivet > value = 2e >  > * >>$ WRITE SYS$OUTPUT F$GETSYI( "IJOBLIM" ) >  >   >>$ MCR SYSMAN PARA SHOW IJOBLIM >  > 1 > MV3100$  WRITE SYS$OUTPUT F$GETSYI( "IJOBLIM" )s > 100t& > MV3100$ MCR SYSMAN PARA SHOW IJOBLIMB > %SYSMAN-I-USEACTNOD, a USE ACTIVE has been defaulted on node VAX$                           ^^^^^^^^^^  ' > Node VAX:   Parameters in use: ACTIVEoR > Parameter Name            Current    Default    Minimum    Maximum Unit  DynamicR > --------------            -------    -------    -------    ------- ----  -------R > IJOBLIM                       100         64          1       8192 Jobs        D >   G $ SET LOGIN/INTERACTIVE actually modifies the ACTIVE value of IJOBLIM, i as can be seen here:   $ set login/interactive=100aL %SET-I-INTSET, login interactive limit = 100, current interactive value = 10 $ mc sysgen show ijoblimH Parameter Name           Current    Default     Min.      Max.     Unit 	   DynamicaH --------------           -------    -------    -------   -------   ---- 	   ------- G IJOBLIM                       100         64         1       8192 Jobs e       Dd $ mc sysgen. SYSGEN>  SHOW IJOBLIMcH Parameter Name           Current    Default     Min.      Max.     Unit 	   DynamiciH --------------           -------    -------    -------   -------   ---- 	   ------- G IJOBLIM                       100         64         1       8192 Jobs i       D  SYSGEN>  USE CURRENT SYSGEN>  SHOW IJOBLIMuH Parameter Name           Current    Default     Min.      Max.     Unit 	   DynamiclH --------------           -------    -------    -------   -------   ---- 	   -------aG IJOBLIM                        64         64         1       8192 Jobs -       D- SYSGEN>-   ------------------------------  # Date: Fri, 02 Jul 2004 14:27:27 GMTn! From: Nigel Barker <nigel@hp.com>s" Subject: Re: OpenVMS .... no news?8 Message-ID: <68oae05iv1ei7cei49294a86a6mm14rnai@4ax.com>  N On Thu, 1 Jul 2004 15:34:28 -0400, "Bill Todd" <billtodd@metrocast.net> wrote:  M >>My recollection was likely of a subsequent comment in a different thread byn >a non-Compaq source:1 >4D >"While it is a really great thing to have the head count of the VMS >engineering group doubled..."M >( http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&selm=3B391188.4 >6857D040%40infopuls.com ).l  O So that guy was wrong too. I repeat nobody ever promised to double headcount in4N OpenVMS engineering & for to say otherwise is simply incorrect. In any case inJ my previous posting I also explained why it was not even necessary for the success of the port.  F >I think not.  According to the Compaq announcement at the time of theJ >Alphacide reproduced here, "The first Itanium-based system for Tru64 UNIX! >and OpenVMS is planned for 2003"   M OpenVMS V8.1 shipped in December 2003 & is available as an SDK to anyone withm $75.  J >I'm afraid that minor enhancements to the C RTL are not the kind of thingL >that I was talking about (however much they may have been needed to addressF >minor deficiencies therein).  You might have picked a more impressive! >example, if one actually exists.   O I just picked one slide at random to illustrate the level of detail that was in 
 the notes.   >DJ > I really urge you to actually read the notes accompanying the PowerpointH >> presentation rather than rely on me regurgitating the details in this >newsgroup.h > H >Well, some of the readers of this newsgroup just don't run systems thatM >support ppt, so if you want to reach people who might actually be influencedrM >in their purchasing decisions you might be wise to make the effort here.  If   M If you are allergic to Microsoft products then using Open Office you can readaN the presentation & notes just fine. Open Office runs on a variety of operating! systems & hardware architectures.p   -- Nigel Barker Live from the sunny Cote d'Azur    ------------------------------  $ Date: Fri, 2 Jul 2004 12:20:57 -0400* From: "Bill Todd" <billtodd@metrocast.net>" Subject: Re: OpenVMS .... no news?2 Message-ID: <DI6dnYm1ntqsFnjdRVn-gw@metrocast.net>  . "Nigel Barker" <nigel@hp.com> wrote in message2 news:68oae05iv1ei7cei49294a86a6mm14rnai@4ax.com...I > On Thu, 1 Jul 2004 15:34:28 -0400, "Bill Todd" <billtodd@metrocast.net>e wrote: > L > >>My recollection was likely of a subsequent comment in a different thread by > >a non-Compaq source:x > >eF > >"While it is a really great thing to have the head count of the VMS  > >engineering group doubled..." >;L ( http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&selm=3B391188. > >6857D040%40infopuls.com ).w >  > So that guy was wrong too.  K That would actually be for someone like Fred (who appeared to be conversantoB with the actual numbers involved) to say, would it not?  I have noH difficulty believing that the number might have fallen somewhat short ofG actual doubling, if all the VMS-related developers were included in thei4 original count, but it clearly was very substantial.  5  I repeat nobody ever promised to double headcount inoA > OpenVMS engineering & for to say otherwise is simply incorrect.p  L Well, since I just provided a quote to the contrary, I'd say that's a bit ofL a stretch.  Now, if you'd like to qualify your statement as applying only to* Compaq sources, I have no problem with it.   ...u  H > >I think not.  According to the Compaq announcement at the time of theL > >Alphacide reproduced here, "The first Itanium-based system for Tru64 UNIX# > >and OpenVMS is planned for 2003"g >cJ > OpenVMS V8.1 shipped in December 2003 & is available as an SDK to anyone with > $75.  E I really didn't see the statement I quoted above as specifying a beta-G version (as clearly evidenced by its price, as well as its limitations)iH rather than a production version.  I doubt that most others did, either.   ...   L > > I really urge you to actually read the notes accompanying the PowerpointJ > >> presentation rather than rely on me regurgitating the details in this
 > >newsgroup.  > >oJ > >Well, some of the readers of this newsgroup just don't run systems thatD > >support ppt, so if you want to reach people who might actually be
 influencedK > >in their purchasing decisions you might be wise to make the effort here.m If > J > If you are allergic to Microsoft products then using Open Office you can readF > the presentation & notes just fine. Open Office runs on a variety of	 operating:# > systems & hardware architectures.s  J My suggestion had relatively little to do with my own attitudes, as I made( clear.  Does Open Office run on VMS now?   - bill   ------------------------------  # Date: Fri, 02 Jul 2004 16:54:46 GMT - From: JF Mezei <jfmezei.spamnot@teksavvy.com>g" Subject: Re: OpenVMS .... no news?@ Message-ID: <14479e7835d050731843b72e9d700bdb@news.teranews.com>  ' re: promises of VMS headcount doubling.e  L I had heard that HP made significant reductions in the number of consultantsN working for the VMS engineers. I know of one at least who was very involved inN the TCPIP group (and no, it doesn't appear to be the gold coast surfer boy :-)   ------------------------------  % Date: Fri, 02 Jul 2004 14:28:12 +0200 ! From: Soterro <soterroatyahoocom>c< Subject: Re: Process quotas identical, but one machine fails9 Message-ID: <40e55470$0$331$4d4ef98e@read.news.ch.uu.net>.   Barry Treahy, Jr. wrote:G > You're confusing quotas with working sets...  A small, or different, nD > working sets should not cause a crash but a difference in virtual F > address space, which is a quota, can.  Most likely, you *DO* have a J > difference between how the quotas on your systems are SYSGEN'd, or have 4 > your paged/non-paged memory resources are handled.F > If you have image accounting enabled, look at the image termination   < I just threw in whatever was memory related, just in case :)I Image accounting didn't give anything about the quotas, just the already  I known message that there's one exceeded (would be so difficult to report d that?)  F However my problem is solved. Once I added to LOGINOUT the /AUTHORIZE E flag, it worked like a charm. I can't say why it worked, because the iB scarce explanations I found about LOGINOUT were not enough for my H understanding (end even contradictory a bit), maybe you or someone else ' could explain what and why it happened?a  
 Thanks a lot,t S    ------------------------------   Date: 2 Jul 2004 08:44:13 -0500A- From: Kilgallen@SpamCop.net (Larry Kilgallen) < Subject: Re: Process quotas identical, but one machine fails3 Message-ID: <huwLgCrW30pt@eisner.encompasserve.org>e  ] In article <40e55470$0$331$4d4ef98e@read.news.ch.uu.net>, Soterro <soterroatyahoocom> writes:o  H > However my problem is solved. Once I added to LOGINOUT the /AUTHORIZE G > flag, it worked like a charm. I can't say why it worked, because the 'D > scarce explanations I found about LOGINOUT were not enough for my J > understanding (end even contradictory a bit), maybe you or someone else ) > could explain what and why it happened?t  H Without consulting SYSUAF, LOGINOUT will create the process with minimumE quotas specified by system parameters.  Consulting SYSUAF is required 3 for quotas specified with Authorize to have effect.a  @ Perhaps your two systems have different PQL* parameter settings.   ------------------------------  % Date: Fri, 02 Jul 2004 16:28:01 +0200e3 From: Michael Unger <spam.to.unger@spamgourmet.com>e< Subject: Re: Process quotas identical, but one machine fails* Message-ID: <2kl9snF3qd4kU3@uni-berlin.de>  % On 2004-07-02 14:28, "Soterro" wrote:.   > [...]e > H > However my problem is solved. Once I added to LOGINOUT the /AUTHORIZE G > flag, it worked like a charm. I can't say why it worked, because the oD > scarce explanations I found about LOGINOUT were not enough for my J > understanding (end even contradictory a bit), maybe you or someone else ) > could explain what and why it happened?P  > Quoting from the OpenVMS DCL Dictionary, Volume II (N-Z), "RUN (Process)" section:-   | /AUTHORIZE | /NOAUTHORIZE (default)! | Requires IMPERSONATE privilege.  | I | When the image to be executed is the system login image (LOGINOUT.EXE),rI | this qualifier searches the user authorization file (UAF) to validate asI | detached process. The /NOAUTHORIZE qualifier creates a detached processf9 | that runs under the control of the command interpreter.  | H | When you specify the /AUTHORIZE qualifier, quotas are derived from theH                        ^^^^^^^^^^            ^^^^^^^^^^^^^^^^^^^^^^^^^^^C | user authorization file (UAF) record of the process’ owner. Anyt<   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^H | qualifiers to the RUN command that specify other quotas are ignored inG | favor of the UAF quotas. When you specify the /NOAUTHORIZE qualifier,e<                                                 ^^^^^^^^^^^^F | quotas are derived from the system parameters that set process quotaF   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^2 | default limits (parameters prefixed with PQL_D).   ^^^^^^^^^^^^^^ |eG | Specify the /AUTHORIZE qualifier if you want the login image to checkeG | the UAF whenever a detached process is created. The process-permanent I | files specified by the /INPUT and /OUTPUT qualifiers are made availablea2 | to the command interpreter for input and output.   Michaeln   -- o; Real names enhance the probability of getting real answers. 5 My e-mail account at DECUS Munich is no longer valid.g   ------------------------------   Date: 2 JUL 2004 12:40:02 GMTn4 From: karcher@thuria.waisman.wisc.edu (Carl Karcher)+ Subject: Re: RAID Array 450 and Controllers-5 Message-ID: <2JUL04.12400229@thuria.waisman.wisc.edu>1  G In a previous article, "Richard L. Dyson" <rick-dyson@uiowa.edu> wrote:_  J ->Along these lines, does anyone know how to obtain the final software forK ->an HSZ50 (that is what my RA450 came with BTW).  They discontinued it andwL ->it is not even orderable from HP.  I was told by the sales rep that as far9 ->as HP was concerned, it could be shared or copied, etc.f -> -K ->I found a program to duplicate PCMCIA cards on a PC if I could ever get a E ->copy of the v5.3Z (I think!) software that was the final release...e  I It was V5.7Z. I have two cards of it. This version added support for 36GB 7 drives. Contact me privately if you want to borrow one.i   --G -- Carl Karcher, Waisman Computing Services, Waisman Center, UW-Madisong4 --             karcher.demungthis@waisman.wisc.edu     ------------------------------  $ Date: Fri, 2 Jul 2004 10:42:10 +03007 From: "Oleksii Krykun" <krikun@academy.kiev.ua.no.spam>n" Subject: Re: Secondary DNS problemS Message-ID: <1037270357C4D411A1C900A0C9D4BFCB01147BC4@hqnts40div01.academy.kiev.ua>o  C "Peter 'EPLAN' LANGSTOEGER" <peter@langstoeger.at> wrote in message>* news:newscache$4ls60i$pjt$1@news.sil.at... > In articleH <1037270357C4D411A1C900A0C9D4BFCB0114593A@hqnts40div01.academy.kiev.ua>,9 "Oleksii Krykun" <krikun@academy.kiev.ua.no.spam> writes:tJ > >I used my old VAX4000-200 as secondary DNS in our LAN about 7 years. NT 4.0  > >DNS server was primary. > I > I did it the other way. VMS was more reliable as primary, I could use apH > (very good) text editor (EVE) and scripts (DCL) for zone updates and II > had umpteen NT systems as secondary (and file/print/application) serversI > in remote locations (until the AD came out before BIND9 on VMS came)..., >8  C I tried this 7-8 years ago. I don't  remember exatctly but it seemsd8 non-reliable for me. But again I don't remember what :-(  5 > >Now I've replaced MS DNS on NT server with BIND 9.P >r" > By what ? Upgrading to Win2003 ?  J MS DNS became non-reliable. It hangs often. Moreover I am planning to moveJ this server to FreeBSD with BIND and I would like to test this software in my environment.i   >a6 > >On BIND named.conf there is allow-transfer for VAX. >a= > Do you have security keys in use (wouldn't make sense ;-) ?c  D Hmmm! No. But I invoked rndc-confgen -a without any modifications of+ rndc.key. May be this... What do you think?h  $ > >Event Log shows events like this: > > C > >client 10.0.4.2#1166: transfer of 'BLA.BLA.BLA/IN': AXFR startedt > % > and 10.0.4.2 is the IP of the VAX ?    Yes.   >  > >But on VMS side I see:  > >  > >$ ucx sh host/nolocal7 > >%SYSTEM-E-REJECT, connect to network object rejectede) > >%UCX-W-NORECORD, Information not found 7 > >-SYSTEM-F-REJECT, connect to network object rejectede >rA > That means, you can't connect your DNS client to the DNS servermH > (which I assume is LOCALHOST as you wrote the VAX is a secondary DNS).I > So, this only shows a nonworking secondary on the VAX (which you know).l >o  2 I removed old zone files and restarted DNS. I see: $ ucx sh host/nolocalr& %UCX-W-NORECORD, Information not found5 -UCX-E-BIND_NO_INFORMA, The server has no informationt $d  H > If youever you specified the primary DNS as the first (or only) server@ > in the DNS client, then it is proof that the problem is on M$.  + I would like to exclude VMS problem source.o   >iH > If there is already a NSLOOKUP utility in UCX V3.2 (which I doubt) you  > can use this for more digging. >c > $ NSLOOKUP name server >. > and/or >G > $ NSLOOKUP > Default Server:  localhost > Address:  127.0.0.1  >r > >LS -D domain. > >SET SERVER <primary>  > >LS -D domain. > 
 $ nslookup Default Server:  localhost Address:  127.0.0.1h   > ls -d bla.bla.blah [localhost]h5 *** Can't list domain academy.kiev.ua: No informationo   > server primary Default Server:  primary Address:  10.0.4.1   > ls -d bla.bla.blaC [[10.0.4.1]]6  bla.bla.bla.               SOA   primary.bla.bla.blaa= administrator.bla.bla.ua. (2004063012 3600 600 1209600 86400)e     Then *hangs*  I > Alternatively you can use the NSTEST freeware which was written exactlyw* > for this reason (not having a NSLOOKUP). >  > >UCX$BIND_STARTUP.LOG says:a > > < > >UCX BIND Server Error message -- Wed Jun 30 13:34:14 2004( > >secondary zone "'BLA.BLA.BLA" expired> > >UCX BIND Server Warning message -- Wed Jun 30 13:34:14 2004/ > >recvfrom: connect to network object rejectedh> > >UCX BIND Server Warning message -- Wed Jun 30 13:34:17 2004? > >zoneref: Masters for secondary zone 'BLA.BLA.BLA unreachablep< > >UCX BIND Server Error message -- Wed Jun 30 13:34:24 2004( > >secondary zone "'BLA.BLA.BLA" expired > >eJ > >How to investigate this problem? I can't find any information about UCX BIND > >logging._ >nJ > In UCX V3.2 there is no logging (AFAIK - that's more than a decade ago).. > I'm surprised to see even a BIND in V3.2 ;-) >uG > But you already have a message (see above). The VAX is not allowed tooA > connect to the primary DNS. Check there again (Event Viewer)...c >v@ > How about TELNET to port 53 and see if a connection is allowed > to the primary.s >g $ telnet primary 53i Trying...10.0.4.1o Connected to PRIMARY.o Escape character is '^]'.y   Where is a problem?f   ------------------------------  % Date: Fri, 02 Jul 2004 08:36:26 +0200o* From: Paul Sture <nospam@sture.homeip.net>0 Subject: Re: slap in the face again... thanks HP* Message-ID: <2kke3bF3cdi8U1@uni-berlin.de>  
 nobody wrote:  > Paul Sture wrote:e > H >>I am not familiar with the latest versions, but as Bill Todd mentioned> >>in this thread, Partition Magic can do image backups. And at >>- >>http://www.ultrabac.com/products/45pricing/  >>G >>there is a range of solutions from single workstation image backup to % >>file by file server backups and DR.  >  > G > Thanks for the tip. Have passed this on to my cycling friends who are B > (unfortunatly) relying on a windows laptop during their travels.  H Here's another tip for your cycling friends, assuming they are still on  Win98.  I My memory of it is a bit hazy now, but when I had Win98, I used Linux in  F a second partition to take tar + gzip backups of Win98. IIRC I had to H stick to FAT16 for the Windows partition, as Linux didn't support FAT32 I then (does it now?). I think I also used WinZip in there too, maybe just = for backing up data.  C It really worked a treat, and a full restore was just minutes away.3F (Since I couldn't get Linux to talk to my CD burner, I actually had a F third partition, definitely FAT16, and I'd put my tar.gz files there, + then back into Windows to burn them to CD.)   3 Sorry if that's a bit vague, but it's another idea.    ------------------------------   Date: 2 Jul 2004 06:39:29 -0700o% From: Bart.Zorn@xs4all.nl (Bart Zorn)fY Subject: Re: Volume shadowing between FC Storage at different sites, and the allocation ce= Message-ID: <a98cd882.0407020539.24f4a8d9@posting.google.com>D  M This was also my understanding, but my HP contact could not get it confirmed.r Believe me, we pushed!  	 Bart Zornc  Y Lee Mah <lytmah@telusplanet.net> wrote in message news:<UxCEc.38961$_5.21538@clgrps13>...tG > My understanding was that the 2 retro's would be out for 7.3-1 first,h& > followed later by patches for 7.3-2. >  > Bart Zorn wrote: > X > >Lee <lytmah@telusplanet.net> wrote in message news:<d9qEc.38935$_5.34118@clgrps13>... > >    > >n, > >>We're waiting for the retro-patches for:, > >>   - shadowing of dissimilar-sized disks > >>   - Host Based Mini Merge.e > >>When did you receive HBMM? > >>     > >> > > @ > >According to my information, DDS will not be retro patched to' > >anything. It is in V7.3-2 and later.  > >tF > >For HBMM I have heard that there is a fieldtest kit based on V7.3-1I > >and it may become available in V8.2. Don't know about a kit for V7.3-20
 > >though. > > D > >With around 80 DSAs in a 4 node, 2 site cluster (Hitachi storage,* > >unfortunately), I really need HBMM too! > >D > >Regards,G > >R > >Bart Zorn > >    > >v >  > --   ------------------------------   End of INFO-VAX 2004.363 ************************