1 INFO-VAX	Mon, 08 Dec 2003	Volume 2003 : Issue 679       Contents:9 Re: Announcement OpenVMS backup solution special offer...  burger king and billy  DEC$DOCUMENT v2.3  Re: DEC$DOCUMENT v2.3 @ Re: Financial-services institutions move to HP Integrity systems3 Gartner: HP is Leader in High-Availability Services  Re: Hairdoo Economics  Re: Hairdoo Economics  Re: Hairdoo Economics  Re: Hairdoo Economics  Re: Hairdoo Economics : Re: I wonder if this HP director will resign from HP's BOD: Re: I wonder if this HP director will resign from HP's BOD: Re: I wonder if this HP director will resign from HP's BOD lib$spawn particulars  Re: lib$spawn particulars  RE: New patchkits available  Re: New patchkits available : Re: OpenVMS clusters give Windows, Unix thorough thrashing: Re: OpenVMS clusters give Windows, Unix thorough thrashing: Re: OpenVMS clusters give Windows, Unix thorough thrashing: Re: OpenVMS clusters give Windows, Unix thorough thrashing OpenVMS VAX Emulator Services  OSU http server & http headers" Re: OSU http server & http headers" Re: OSU http server & http headers" Re: OSU http server & http headers" Re: OSU http server & http headers" Re: OSU http server & http headers" Re: OSU http server & http headers Re: Passing var into F$SEARCH  porting problems encountered  Re: porting problems encountered Re: Replacement for CSWING?  Re: Replacement for CSWING?   Re: Results of SAN vendor survey  Re: Results of SAN vendor survey SEARCH enhancement Re: SEARCH enhancement Re: SEARCH enhancement Re: SEARCH enhancement Re: SEARCH enhancement Re: SEARCH enhancement Re: SEARCH enhancement Re: SEARCH enhancement9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday , Re: VAX 11/750 and RL02 - trying to boot VMS, Re: VAX 11/750 and RL02 - trying to boot VMS= Re: VMS clusters prove they are the best - Sun comes in last! = Re: VMS clusters prove they are the best - Sun comes in last! = Re: VMS clusters prove they are the best - Sun comes in last! 	 XFC cache 
 Re: XFC cache 
 Re: XFC cache 
 Re: XFC cache   F ----------------------------------------------------------------------  $ Date: Mon, 8 Dec 2003 13:09:15 -0500. From: "David Wehrle" <david@davidandjanet.net>B Subject: Re: Announcement OpenVMS backup solution special offer...0 Message-ID: <LMednXzHWf_OI0miRVn-vw@comcast.com>   > G > The reason this is good news is that Legato supports the VMS platform @ > as the backup engine.  Many backup solutions propose a non-VMSA > platform as the backup engine, only supporting VMS as a client.  > < > SLS and ABS are not going away, and neither in VMS Backup.  H This is wonderful, of course, but where is the tape library database andH where is all of the historical backup data?  Where is the control of the backup?   L It looks like the only surviving OpenVMS backup solution is TAPESYS.  Funny,E it was the original OpenVMS backup solution.  (SLS is a derivative of 	 TAPESYS.)    ------------------------------  $ Date: Mon, 8 Dec 2003 11:54:48 -0600( From: Wayne Sewell <wayne@tachysoft.com> Subject: burger king and billy/ Message-ID: <00A2A10A.8B7C54AA.7@tachysoft.com>   N Looks like the local burger king has discovered the joys of the billyworld.  IJ just went through the drivethru and just after the whopper appeared on theI display panel, I saw a system crash, with dump and everything, before the , chicken tenders could show up.  :-) :-) :-)   M They still had the order, so it was apparently just the display that died.  I ' guess the main system will crash later. O =============================================================================== N Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com; http://www.tachysoft.com/www/tachyon.html and wayne.html    O =============================================================================== H Randolph Duke (in Trading Places): "Mother always said you were greedy."1    Mortimer Duke: "She meant it as a compliment!"    ------------------------------   Date: 8 Dec 2003 03:40:42 -0800 . From: send_lotsa_spam_here@yahoo.com (Soterro) Subject: DEC$DOCUMENT v2.3= Message-ID: <1a63f162.0312080340.6a2a1c72@posting.google.com>    Hello,  C I just installed this DOCUMENT 2.3 on a OpenVMS VAX 6.2 - old, that F hobbyist cd was never used as I thought why should I touch a perfectly@ working system. Now when trying to do something useful I got the" following unknown (to me) message:  2 $ document  myfile.sdml software.online bookreader% %DOC-E-NOMSG, Message number 00BE8CCA A -RMS-F-DEV, error in device name or inappropriate device type for 	 operation % %DOC-F-NOMSG, Message number 00BE8FBC   > Any idea what would be the inappropriate device, what might be' undefined or what's all the fuss about?   
 Thanks a lot,  S    ------------------------------  % Date: Mon, 08 Dec 2003 23:49:43 +0800 , From: Paul Repacholi <prep@prep.synonet.com> Subject: Re: DEC$DOCUMENT v2.3- Message-ID: <87brqj71ig.fsf@prep.synonet.com>   0 send_lotsa_spam_here@yahoo.com (Soterro) writes:  E > I just installed this DOCUMENT 2.3 on a OpenVMS VAX 6.2 - old, that > > hobbyist cd was never used as I thought why should I touch aD > perfectly working system. Now when trying to do something useful I, > got the following unknown (to me) message:  4 > $ document  myfile.sdml software.online bookreader' > %DOC-E-NOMSG, Message number 00BE8CCA C > -RMS-F-DEV, error in device name or inappropriate device type for  > operation ' > %DOC-F-NOMSG, Message number 00BE8FBC   @ > Any idea what would be the inappropriate device, what might be) > undefined or what's all the fuss about?   < Did you run DOC$STARTUP? Installing the DOC message file may: fix the NOMSG as well. It defines a shed load of logicals.   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Mon, 08 Dec 2003 01:21:39 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>I Subject: Re: Financial-services institutions move to HP Integrity systems ) Message-ID: <3FD41862.3ACE1503@istop.com>    John Smith wrote: $ > How many of these are running VMS?< > After all, as some would point out, this is c.o.v. and not$ > comp.hardware.IA64.HP.blatent.hype  J Come on, lets be fair. HP as the right to announce that a handful of banksM have bought a couple of IA64 boxes for pilot/evaluation. After all, they will L be forced to migrate all their HP, Tandem and Digital infrastructure to thatK Ia64 thing.  It is only normal that they have to buy a few to evaluate what , will be involved with that forced migration.  J But if HP has to pay customers to accept delivery of an IA64 box and startB porting their own software, how could HP be a profitable company ?   ------------------------------   Date: 8 Dec 2003 09:19:01 -0800 1 From: keithparris_NOSPAM@yahoo.com (Keith Parris) < Subject: Gartner: HP is Leader in High-Availability Services= Message-ID: <cf15391e.0312080919.4075d65b@posting.google.com>   A HP recognized by Gartner in Leaders Quadrant in High-Availability  Services by Jay Moore  F HP appears in the leaders quadrant in Gartner's Magic Quadrant: ServerC Vendor High-Availability Services, 2003, as reported on October 29. F According to Gartner, Inc., "Leaders are performing well today, have a: clear vision of market direction and are actively buildingE competencies to sustain their leadership position in the market." The > authors of the report state, "Sustaining high levels of system= availability continues to be a key issue and concern for many F organizations." Both vendor surveys and customer feedback were used to? determine the level of strategic focus, investment, and service E delivery skill that distinguish leadership in this critical area. The D strength of HP in providing proactive and reactive services that are? critical to business and IT success are further evidence of the ? company's ability to deliver true business value. Leadership in > services that enable the Adaptive Enterprise demonstrates HP'sD commitment to meeting both current and future customer requirements.  H Gartner Report: http://mediaproducts.gartner.com/reprints/hp/118198.html --- E I note that not only is HP IN the Leaders Quadrant, it is in the VERY  TOP SPOT there. --KP   ------------------------------  % Date: Mon, 08 Dec 2003 01:29:04 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com> Subject: Re: Hairdoo Economics) Message-ID: <3FD41A1E.310EFFFC@istop.com>   M Of course, there was also the famous gas pump ads as soon as Compaq finalised L the purchase of Digital. This was done with Compaq's own ad agency before itL was dumped and replaced by Digotal,s ad agency. Compaq's ad agency knew thatM customers wanted to see "VMS" on the gas pump, not the stupid name Palmer had ) given it. And VMS was the first gas pump.   N This ad was definitely mainstream, published in Time magazine around the world as well as other publications.  N But as soon as Compaq erred in hiring Digital's old markleting agency, the VMS marketing faltered again.    ------------------------------  % Date: Mon, 08 Dec 2003 01:23:58 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com> Subject: Re: Hairdoo Economics) Message-ID: <3FD418EC.24E70C5C@istop.com>    John Smith wrote: N > Nothing was going to dislodge 80x86 architecture from having sole possession > of 'mainstream'." > Since when is IA64 'mainstream'?    I Many computer companies, when indoctyrinbating new employees proceed with M surgical installation of blinders which restricts the new employee's field of F vision. As a result, they become unaware of what goes on outside theirN organisation and more importantly, much more likely to absorb information fromH their employer without challenging it. This is not specific to HP. It is( specicic to many computer manufacturers.   ------------------------------  $ Date: Mon, 8 Dec 2003 03:53:44 -0500* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Hairdoo Economics2 Message-ID: <Q-6dnTDbtbmOoUmiRVn-gw@metrocast.net>  0 "Mike Naime" <mnaime@kc.rr.com> wrote in message4 news:3BRAb.132508$M02.75132@twister.rdc-kc.rr.com...   ...   E   Can someone point me to advertising to the masses that DIGITAL used  > during the 80's or 90's?  L I remember seeing print ads, but after this length of time can't be specificH about them.  But I certainly remember one significant piece of exposure:G DEC was a long-time primary sponsor of PBS's Nightly Business Report (I K think - it conceivably could have been the McNeil/Lehrer News Hour instead, I or in addition), which certainly got its name and a brief synopsis of its 8 product offerings in front of a lot of the right people.   - bill   ------------------------------  % Date: Mon, 08 Dec 2003 13:24:12 +0000 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>  Subject: Re: Hairdoo Economics0 Message-ID: <br1u1s$n69$1@new-usenet.uk.sun.com>   Main, Kerry wrote: >>-----Original Message-----  F >>>AIX and Solaris are struggling to remain relevant in light of Linux > I > (and Solaris has the additional boat-anchor of poor SPARC performance).  > << > G > Yep, and IBM (Senior VP of IBM Software) stated publicly earlier this G > year that the likely future for their AIX base was likely going to be F > Linux. So that decision, if in fact this is true, is likely going toJ > impact Sun as well. It also means some potential migrations are going toG > be required for current AIX users at some point in the future (albeit D > IBM will support them for some time - likely just like VAX users). >   @ Umm, if you had bothered to post or read the rest of the article you would have noticed that:  6 1.	There is no commitment from IBM to move to Linux it3 	from AIX it is just a logical option and of course  	it is a logical option.7 2.	The IBM exec interviewed is not responsible for OS's 7 3.	The timelines for this migration are multidecade e.g  	10-20 years minimum.   9 10-20 years is way too long for anyone to either take any ; notice of the comments or even think about planning for the  event.  = In addition I would also be really very interested in how you H imagine that IBM's 10-20 year migration from AIX to Linux (if it happens" at all) is going to impact on Sun.  ? This has been usefull though for one reason its a great example  of real FUD in action.  D For anyone who doesn't know what real FUD is Kerry has just provided+ the almost perfect reference example of it.   < Speculation piled on speculation linked with supposition and> all designed to spread a little uncertainty, not a fact in it.   regards  Andrew Harrison    ------------------------------   Date: 8 Dec 2003 10:12:42 -0800 1 From: keithparris_NOSPAM@yahoo.com (Keith Parris)  Subject: Re: Hairdoo Economics= Message-ID: <cf15391e.0312081012.3365b859@posting.google.com>   r "John Smith" <a@nonymous.com> wrote in message news:<8YRAb.155$r%u1.69@twister01.bloor.is.net.cable.rogers.com>...$ > Is Power an industry standard? No.N > Is Power 'mainstream'. Not by your definition. Yet is IBM looking to kill it > and line Intel's pockets? No  F Power is indeed NOT mainstream, nor an industry standard, and it neverE will be.  It doesn't run Windows (it had its chance and blew it), and ? no other computer manufacturer (unless you count Apple with the D PowerPC flavor) will ever make systems using it.  It's a dead end at this point.   A IBM recently announced 16-way Itanium servers. An astute observer B might ask why IBM is doing that if it has Power? IBM appears to be> hedging its bets because it looks like Itanium will become theF mainstream 64-bit CPU for servers, and IBM doesn't want to miss out onF that market. IBM may even be considering ending Power. Sure looks like  Sun is thinking of ending SPARC.  N > Nothing was going to dislodge 80x86 architecture from having sole possession > of 'mainstream'.  ? The important word there is "was".  Now something "is" going to F dislodge 80x86 from the "mainstream" title eventually, as the industryA moves from a 32-bit focus to 64-bit.  VMS itself is already at 64 > bits, and going to IA32 now would arguably be a step backward.  " > Since when is IA64 'mainstream'?   Not yet, but it's headed there.   F Intel wants IA64 to be that mainstream, and AMD wants x86-64 to be theD mainstream.  I think the signals at present indicate that Intel willB get the majority of the design wins, as it did when competing withC Motorola in the '80s. (Time to market beat technical elegance every E time.)  If somehow AMD were to become the mainstream on desktops, and B even extend that into the server space, then I expect we'd see VMS; running on x86-64, so I can continue to run VMS either way.    ------------------------------  $ Date: Mon, 8 Dec 2003 03:45:19 -0500* From: "Bill Todd" <billtodd@metrocast.net>C Subject: Re: I wonder if this HP director will resign from HP's BOD 2 Message-ID: <N4SdnaMx4MOHp0miRVn-sQ@metrocast.net>  > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message6 news:cf15391e.0312072142.7153086@posting.google.com...7 > JF Mezei <jfmezei.spamnot@istop.com> wrote in message % news:<3FD3B57D.5E76A8F8@istop.com>...    ...   0 > > Then why did Compaq kill Alpha prematurely ? > @ > Alpha isn't dead just yet, so no one has killed it yet. CompaqE > announced their future direction, HP reviewed the plans and agreed, H > and things are progressing very well and on schedule in the directions > planned and promised.   	 Bullshit.   H 1.  At the time of the Alphacide, Compaq's plan was to release EV7 in Q3K 2002.  That remained the target date until at least January, 2002 (8 months K after first silicon and 7 months after first VMS boot, so there should have I been no significant surprises left).  Then, with no announced reason, the I release date was slipped to January, 2003 (and the clock rate cut back by L 50 - 100 MHz):  not only does this not qualify as 'progressing very well' orL as 'on schedule', but it raises significant suspicions (not that they didn'tI exist already) that HP is happy to do whatever it may take to keep even a 8 fading Alpha from taking any attention away from Itanic.  K 2.  At the time of the Alphacide (and for two years thereafter), the formal K plan (stated explicitly as a 'commitment' as well) was to release a faster, L cooler, larger-cache, smaller-die EV79 product to give customers one more atK least moderately significant upgrade to replace the cancelled EV8.  This is J not 'progressing very well and on schedule' either - by any stretch of theJ imagination:  all anyone will get now is an EV7 clocked barely faster than' it should have been from the beginning.   I 3.  At the time of the Alphacide, Compaq (knowing full well that a merger F with HP was imminent) committed to porting Tru64 to Itanic.  So eitherG Compaq lied knowingly, or HP 'agreed' and then immediately reneged - in H either case, Tru64's current terminal status is certainly *not* what wasJ announced at the time - and, once again, can't in any conceivable sense be5 termed to be 'progressing very well and on schedule'.   H 4.  For that matter, even the fig-leaf migration of AdvFS and TruClusterK features into HP-UX (announced when the promise to port Tru64 to Itanic was J broken) has just been slipped from the announced 2004 date to (late) 2005.  L So aside from the 'promise' to kill EV8, the majority of other promises madeB at the time of the Alphacide have either been completely broken orC significantly delayed.  Which is why the proper description of your 2 statement was the one I provided above:  bullshit.  .   How would customers have reacted if, as someF > have suggested here, Compaq had made secret plans to wind down AlphaE > and only revealed those after the Itanium port was a fait accompli?   E That would not have been nearly as stupid as what actually occurred - L because it would have given Compaq considerably more time to evaluate ItanicH (and see how customers accepted it) before committing irrevocably to anyK course of action.  After all, Compaq *already* had been considering killing L Alpha for a couple of years, ever since Capellas took over (and as his firstJ major action killed 32- and 64-bit Windows development on Alpha), so afterG having lied to its customers about the rock-solid commitment to Alpha's K future for two years already there was really no pressing need to bring the  situation to a head.  I Of course, subsequent drastic drops in VMS and Tru64 revenues and profits L made it crystal-clear just how stupid the decision had been:  it cost CompaqF many times as much as it 'saved' by terminating Alpha development, andH continues to do so to this day.  And that was in the context of Compaq'sG on-going neglect of the platform:  had they instead followed through on H Pfeiffer's plan to leverage Alpha and expand its market share as much asK possible *before* the fearsome Itanic appeared, then when Merced burst upon G the world like a damp firecracker Alpha's revenue and profit would have K already been considerably increased - and even more so by the time McKinley = finally provided an Itanic platform that was at least usable.   # > Many would see that as dishonest.   J Hardly more dishonest than the actual behavior Compaq exhibited:  breakingD commitments that it continued to make right up to June 25, 2001, andF accompanying this perfidy with outright lies attempting to justify it.  $   You may not like the decision, butE > at least customers have all the information they need to make plans  > and decisions.  H Absolutely.  And a large number of them seem to have decided that they'dG prefer to deal with a more honest vendor.  For those that still haven't 9 quite gotten the message, we're happy to keep it visible.    > F > Many people are much more confident about the future of VMS now thatH > it is being ported to an architecture which is being strongly promotedG > by the largest and most successful microprocessor manufacturer in the  > world.  H But even more seem to have bailed out, given the drastic drop in revenueH (from $4 billion to $2 billion annually shortly after the Alphacide, andE still under $3 billion at last report) plus the major portion of that J revenue derived from on-going support contracts rather than new sales.  IfK the nominal 400K installed base of people supposedly worried about the fact H that VMS was available only on Alpha shrinks to a 100K installed base ofJ people 'much more confident' in its future, that's hardly anything to brag about.   - bill   ------------------------------  # Date: Mon, 08 Dec 2003 10:32:17 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) C Subject: Re: I wonder if this HP director will resign from HP's BOD L Message-ID: <rdeininger-0812030534080001@user-uinj459.dialup.mindspring.com>  > In article <N4SdnaMx4MOHp0miRVn-sQ@metrocast.net>, "Bill Todd" <billtodd@metrocast.net> wrote:   ? >"Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message 7 >news:cf15391e.0312072142.7153086@posting.google.com... 8 >> JF Mezei <jfmezei.spamnot@istop.com> wrote in message& >news:<3FD3B57D.5E76A8F8@istop.com>... >  >... > 1 >> > Then why did Compaq kill Alpha prematurely ?  >>A >> Alpha isn't dead just yet, so no one has killed it yet. Compaq F >> announced their future direction, HP reviewed the plans and agreed,I >> and things are progressing very well and on schedule in the directions  >> planned and promised. > 
 >Bullshit. > I >1.  At the time of the Alphacide, Compaq's plan was to release EV7 in Q3 L >2002.  That remained the target date until at least January, 2002 (8 monthsL >after first silicon and 7 months after first VMS boot, so there should haveJ >been no significant surprises left).  Then, with no announced reason, theJ >release date was slipped to January, 2003 (and the clock rate cut back byM >50 - 100 MHz):  not only does this not qualify as 'progressing very well' or M >as 'on schedule', but it raises significant suspicions (not that they didn't J >exist already) that HP is happy to do whatever it may take to keep even a9 >fading Alpha from taking any attention away from Itanic.   B In January 2002, there was no shippable EV7 chip, and there _were_I significant surprises left.  In short, the chip was still buggy as hell.  4 Maybe you think that was intentional, but it wasn't.  B I guess HP should apologize for not sending you a personal letter,H detailing each of the technical problems and the plans for solving them.  J I don't think Alpha is different from other product lines in this regard. F Compaq/HP never "commits" to schedule until around the time of product0 announcement.  Until then, everything is vapor.   J HP has delayed several non-alpha, non-VMS products lately.  As has Intel. J As has every computer company I can think of.  Only a fool or a malcontent+ builds plans around pre-announced hardware.     L >2.  At the time of the Alphacide (and for two years thereafter), the formalL >plan (stated explicitly as a 'commitment' as well) was to release a faster,M >cooler, larger-cache, smaller-die EV79 product to give customers one more at D >least moderately significant upgrade to replace the cancelled EV8.   G I never saw anything from Compaq or HP claiming E79 was a "replacement" G for EV8.  And EV8 was NEVER anything but far-off roadmap fodder.  There J was a team of engineers working on it, but schedules and specific featuresI were completely up in the air.  None of which will keep a plan from being  shown on a roadmap.   B In May 2001, I saw a roadmap with EV10 on it.  I knew, and I thinkJ everyone in the room knew, that Compaq was just playing with pretty colors5 in Powerpoint.  Nobody thought EV10 was a comittment.   I Product roadmaps are intended for adults, who understand that the farther D in the future you go, the less certain the roadmap's details become.    	 > This is K >not 'progressing very well and on schedule' either - by any stretch of the K >imagination:  all anyone will get now is an EV7 clocked barely faster than ( >it should have been from the beginning.  G I agree, the whole EV7 program shares problems that the EV6 program had F before.  Difficult bugs show up, requiring significant re-work.  EveryG revision cycle has a big negative impact on the schedule.  EV79 samples I weren't working right, and it looked to be very late by the time it could E have gone to market.  EV7z was clearly a compromise, but it will give J customers a performance boost probably a year earlier than EV79 would have done.   D Yes, HP could have soldiered on with EV79, and probably gotten it toF customers sometime in 2005.  Someone decided that was a foolish way toG spend money.  I suppose they think few customers care about the name of F the chip, but rather care about what a system can do for them.  At the@ system level, there will be both alpha and itanium alternatives.  F Predicting schedules in advance for difficult projects with multi-year@ lead times is very difficult.  Engineers usually give a range ofG estimates, and the managers, publicity folks, and roadmap cartographers G almost always pick the most optimistic numbers.  The original published H EV7 schedules were hype, and I bet the engineers thought so at the time.  G There's not much Compaq or HP could have done to fix the EV7 schedule.  J Once the fab was gone, and chips were made by IBM, the cycle time for eachG chip change is pretty much beyond the control of the Alpha group.  They G (consistently) made their best effort for each chip.  When samples came J back and problems were found, there are few choices:  1) ship with reduced? speed/functionality, 2) try again, 3) give up.  During EV7, all & combinations of these three were done.  G Throwing more money (engineers) at the problem wouldn't have speeded up B product delivery.  Well, running 2 or 3 complete design efforts inB parallel (as Intel seems to do) would have improved the odds.  But8 incremental additions of people would not have mattered.    J >3.  At the time of the Alphacide, Compaq (knowing full well that a mergerG >with HP was imminent) committed to porting Tru64 to Itanic.  So either H >Compaq lied knowingly, or HP 'agreed' and then immediately reneged - inI >either case, Tru64's current terminal status is certainly *not* what was K >announced at the time - and, once again, can't in any conceivable sense be 6 >termed to be 'progressing very well and on schedule'.  F You may be right about Tru64, but I'm not sure.  Some people in CompaqJ probably knew about the merger talks, but it's not clear to me than anyoneH associated with Tru64 knew.  I know from a first-hand account that thereG was still a team working on the Tru64 port a couple of months after the D merger closed.  (After Tru64 was already announced to be un-ported.)  ? It never ceases to amaze me how incompetently and inefficiently H information flows in large companies.  You can attribute it to malice if	 you want.     I >4.  For that matter, even the fig-leaf migration of AdvFS and TruCluster L >features into HP-UX (announced when the promise to port Tru64 to Itanic wasK >broken) has just been slipped from the announced 2004 date to (late) 2005.   I Again, the published schedule was too optimistic.  The migration work was H going badly.  HP is throwing significantly more money (engineers) at theJ migration.  Pretty clever of them to pour money down a drain if their goal  is to screw their customers, eh?   ------------------------------  % Date: Mon, 08 Dec 2003 12:10:40 +0000 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> C Subject: Re: I wonder if this HP director will resign from HP's BOD 0 Message-ID: <br1po1$lm7$1@new-usenet.uk.sun.com>   Keith Parris wrote: ] > JF Mezei <jfmezei.spamnot@istop.com> wrote in message news:<3FCE5F06.4BE97F3F@istop.com>...  >  >>One needs to do the math:  >>@ >>If HP were to streamline its product line into a much simpler: >>	HP-UX >>	Linux
 >>	Windows >>  >>How much money would it save ? >  > D > We can easily answer that question, at least for VMS. Based on theG > latest public figures, VMS annually produces $2.5 to $3 US Billion in D > revenues, and $500 Million in profits, so we can readily calculateF > that HP would save $2.0 to $2.5 Billion in expenses if it got rid ofG > VMS, but lose $2.5 to 3.0 US Billion in revenues, for a net 'savings"  > of negative $500 Million.  >   D Well if that is really true then the rest of the Enterprise Business, is in even worse shape than anyone realised.  ? If OpenVMS is really making a 500 million dollar PA profit then A this is terrible for the rest of the Enterprise Systems business.   @ Last year the EBU lost 56 million dollars this loss excludes R&D) costs which now do not appear in EBU P&L.   G So what you are saying in essence is without OpenVMS the EBU would have + lost 556 million dollars not including R&D.   D Wow and HP don't push OpenVMS and it would seem to be the only thing keeping the EBU afloat.   > Doesn't sound like very smart business or good management from HP.    That or the 500 million is BS.   Regards  Andrew Harrison E > So it's well worth the current level of investment to HP to get the E > $500 Million in profits that the VMS business provides, because the  > ROI is so high.  >  > N >>But from a purely logical point of view, it makes sense for HP to streamline >>its product line.  >  > ' > It's not logical if it hurts profits.  >  >  >>Can HP really N >>afford to maintain products such as VMS whose functionality doesn't *really*G >>make it stand out from HP's own products, especially when HP plans to $ >>incorporate many of those "soon" ? >  > = > As many posters here have pointed out, VMS DOES have unique ? > functionality and value compared with other HP offerings.  As > > Microsoft has found out, clusters aren't so easy to do.  AndD > TruClusters, which I believe are about the best that one can do in@ > translating VMScluster features and benefits to UNIX given theH > constraints of the UNIX platform's design assumptions, still lack some5 > features of VMS Clusters, and probably always will.    ------------------------------  % Date: Mon, 08 Dec 2003 10:02:13 -0500 % From: Thien-Thi Nguyen <ttn@glug.org>  Subject: lib$spawn particulars( Message-ID: <7gwu97gxoq.fsf@gnufans.net>  
 greetings,  D lib$spawn takes a "byte-wide-event-flag", as well as a "finish-code"E and a "finish-ast" args (all pointers).  i was not able to understand C from reading the programming concepts and utils lib manuals what is D the purpose of the byte-wide-event-flag.  some questions for the vms gurus:  :  - are these args somehow mutually exclusive in their use?>    that is, if i specify finish-ast and finish-code, does that>    mean the byte-wide-event-flag is ignored?  (or vice versa?)  C  - is finish-ast guaranteed to be called on subprocess termination? A    (are there possibly exceptional situations where finish-ast is E    not called?)  should CLI (speficially DCL) subprocesses be treated     specially in some way?   >  - what mechanisms are recommended for the lib$spawn caller toB    insulate its event flags and mailbox channels from being munged5    by the subprocess?  shouldn't that be "automatic"?   E all these are to address my ignorance of openvms 7.3-1 in the face of F a bug whereby GNU Emacs 21.2 (work-in-progress) M-x shell (using PTYs)B works fine until i enter the "logout" command.  at that point, theF whole terminal seems to freeze, although a C-g goes through and "Quit"B shows up in the echo area.  disabling PTYs and falling back onto aD pair-of-mailboxes implementation shows other problems as well (we'll  get to those problems later :-).   thi    ------------------------------   Date: 8 Dec 2003 09:59:06 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) " Subject: Re: lib$spawn particulars3 Message-ID: <pn7SnRwPsToo@eisner.encompasserve.org>   P In article <7gwu97gxoq.fsf@gnufans.net>, Thien-Thi Nguyen <ttn@glug.org> writes: > greetings, > F > lib$spawn takes a "byte-wide-event-flag", as well as a "finish-code"G > and a "finish-ast" args (all pointers).  i was not able to understand E > from reading the programming concepts and utils lib manuals what isCF > the purpose of the byte-wide-event-flag.  some questions for the vms > gurus: > < >  - are these args somehow mutually exclusive in their use?@ >    that is, if i specify finish-ast and finish-code, does that@ >    mean the byte-wide-event-flag is ignored?  (or vice versa?)  8  No.  All the mechanisms will be used if they are there.  E >  - is finish-ast guaranteed to be called on subprocess termination?lC >    (are there possibly exceptional situations where finish-ast isfG >    not called?)  should CLI (speficially DCL) subprocesses be treated  >    specially in some way?i  H  Guaranteed.  By "CLI subprocesses" I assume you mean you are giving theF  user a command prompt?  Just make sure sys$output and sys$command are  what you want them to be.  @ >  - what mechanisms are recommended for the lib$spawn caller toD >    insulate its event flags and mailbox channels from being munged7 >    by the subprocess?  shouldn't that be "automatic"?   E  The subprocess does not inherit I/O channels or process event flags,tF  both are process specific.  You can set up common event flags and addD  code to the subprocess to use them, but you have to specifically doE  that if you want it.  The subprocess could also be coded to open ther=  same mailboxes, but you'ld have to put in the code to do it.G  G > all these are to address my ignorance of openvms 7.3-1 in the face ofuH > a bug whereby GNU Emacs 21.2 (work-in-progress) M-x shell (using PTYs)D > works fine until i enter the "logout" command.  at that point, theH > whole terminal seems to freeze, although a C-g goes through and "Quit"D > shows up in the echo area.  disabling PTYs and falling back onto aF > pair-of-mailboxes implementation shows other problems as well (we'll" > get to those problems later :-).  H    Ah, now I think I know what you are doing.  Do you map the PTY to an H    emacs window?  You may need to clean up the PTY, use "SHOW SYSTEM" toE    make sure that the subprocess really exited.  In particular if you B    used a mailbox you never read the subprocess might be in RWMBX.   ------------------------------  $ Date: Mon, 8 Dec 2003 10:40:09 -06001 From: "Grealy, Patrick" <PGrealy@sph.uth.tmc.edu>-$ Subject: RE: New patchkits availableL Message-ID: <EEC575D39D864C4BBAE8CD309982B0F20816F6@sphnt33.sph.uth.tmc.edu>  D I believe the culprit is the patch for Graphics 3.0. We are in the =H process of bringing two DS10s up with 7.3-1 and hit a similar problem. =G In the process of patching we lose DECWindows after applying Graphics =pH 3.0 and reclaim DECWindows if we undo the patch. Since Graphics 3.0 is =G included in Update 2.0 I'm guessing this is the cause of your problem = G also. Unfortunately, I don't think there is a way to apply the update =o: patch and skip/undo a single component, is there? - Pat G.   > -----Original Message-----. > From: EJHeller [mailto:ejheller@aol.com.com]) > Sent: Friday, December 05, 2003 5:58 PMO > To: Info-VAX@Mvb.Saic.ComE& > Subject: Re: New patchkits available >=20 >=208 > I just received a new DS10 today and being the good=20 > integrator went to the< > patch site to get the patches to apply to the system. I=20 > noticed that the UPDATEr? > 0200 was available so I downloaded it and apllied it. Upon=20m > reboot, I no longerc? > had the DECWindows interface, had to change the console to=20t > the terminal so IvA > could see what was going on. I seems that the new driver for=20s > the Radeon cardw= > uses a file naming convention that is different from the=20w > previous naming B > convention and the DECWindows startup cannot find the file it=20 > is expecting.=20 >=20B > In going through the Product History, it seems that I already=20 > have most of the@ > patches in the UPDATE - so the question is should I use the=20 > UPDATE 0200? >=20	 > Thanks,c > Edward Hellerc! > edward.heller-@-transcore-.comln >=20 > >From: norm.raphael@metso.com=1 > >Date: 12/5/2003 11:14 AM Eastern Standard Time  > >d > >D > >i@ > >Karl Rohwedder <extern.karl.rohwedder@volkswagen.de> wrote=20 > on 12/05/2003a > >03:32:17 AM:m > > B > >> On ftp://ftp.itrc.hp.com/openvms_patches/alpha/V7.3-1/ you=20 > can find the= > >> new SYS V5.0 patchkit, which resolves the memory leak=20  > introduced with V4.0. > >> and a new UPDATE V2.0 kit together with a* > >> ALPHA_V731_MASTER_ECO_LIST.TXT, which, > >> lists all available patches for V7.3-1. > >> --d > > @ > >I just looked at the ALPHA_V731_MASTER_ECO_LIST.TXT file, andB > >it says that there are included in the UPDATE V2.0 ECO kit some# > >ECO's that are Rated 2 and/or 3.t > >oD > >As usual, I have installed most of the ECO's in this kit, but notD > >all of them.  I was about to install another group Rated 1.  Now,G > >should I do that, or just install the UPDATE V2.0 kit, getting thoseo> > >I was about to install, new ones, a group I have already=20 > installed, andC > >those Rated 2 and 3 that I don't really need, but will not hurt.3 > >9@ > >Will UPDATE V2.0 now be a required ECO for follow-on ECO's=20 > as is UPDATE > >V1.0eE > >now, so that the question of whether or not to install it is moot?h > >mB > >Oh, and what about recovery-sets?  I would expect to want to=20 > accept the > >ECO's@ > >that I now have installed, and then produce a recovery-set=20 > for only UPDATE  > >V2.0o? > >and then recovery-sets for subsequent ECO installations. =20w > How do I clear > >theB > >existing recovery-sets before taking my phase-0 backup of my=20 > system disk? > > G > >On, and given these bundled UPDATE ECO's, how does one readily check  > >whether a! > >specific ECO has been applied?B > >  > >-Norm > > 8 > >> mit freundlichen Gr=3DFC=3DDFen | with best regards > >r8 > >> Karl Rohwedder          | it-ingteam(at)t-online.de- > >> | extern.karl.rohwedder(at)volkswagen.deS >=20   ------------------------------   Date: 08 Dec 2003 16:48:12 GMT% From: ejheller@aol.com.com (EJHeller)d$ Subject: Re: New patchkits available: Message-ID: <20031208114812.14218.00000540@mb-m28.aol.com>  M Perhaps - if the 7.3-2 distribution were available. The system was build thisoI November with 7.3-1 and the CD set is 7.3-1. And we have not received theeJ system update package with the 7.3-2 CDs, even though we do have an active maintenance agreement.O Oh well, however my basic question was really pointing at whether the SYSUPDATErK v0200 was broken in some way with regard to the DECWindows graphics driver.5 Edward.c  8 >From: peter@langstoeger.at  (Peter 'EPLAN' LANGSTOEGER). >Date: 12/7/2003 5:51 PM Eastern Standard Time > ; >In article <20031205185808.26331.00000233@mb-m15.aol.com>,o( >ejheller@aol.com.com (EJHeller) writes:L >>I just received a new DS10 today and being the good integrator went to theJ >>patch site to get the patches to apply to the system. I noticed that the UPDATE6 >>0200 was available so I downloaded it and apllied it > E >"being the good integrator" would mean installing V7.3-2, I suppose.r >  >--  >Peter "EPLAN" LANGSTOEGER& >Network and OpenVMS system specialist >E-mail  peter@langstoeger.atwG >A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist-   ------------------------------  % Date: Mon, 08 Dec 2003 10:59:20 +0000hO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>cC Subject: Re: OpenVMS clusters give Windows, Unix thorough thrashing 0 Message-ID: <br1li9$k2j$1@new-usenet.uk.sun.com>   JF Mezei wrote:e* > Andrew Harrison SUNUK Consultancy wrote: > B >>There should be a pretty close relationship between the capacityB >>of the system and the cost of downtime assuming that the systems/ >>being compared are equally business critical.e >  > + > It is the last asusmption which is wrong.  > N > Yes, when comparing two systems that have the same application (such as yourO > example of credit card authoriozations), the system handling the greater loadu& > will have the higher downtime costs. >   C Well if you don't compare two systems doing basically the same task B then there is no point to doing a TCO analysis in the first place.  P > However, one cannot make a generalisation since a much smaller system handlingJ > hindred of very high value transactions per day (instead of transactionsP > measured in the tens per second) may have downtime costs that are far greater. > M > If your credit card authorisation application fails and you blind authorizeaP > transactions, you don't lose customers. But if your SWIFT system goes down andN > a 100 million payment from Boeing to some japanese supplier of wings doesn'tL > make it before the deadline, your bank is not only liable to pay the steepM > late payment fees in the contract between Boeing and the japanese supplier,9N > but you also styand to lose Boeing as a customer because Boeing will want toH > take its businses to a bank that can transfer payment amounts on time.  D Actually losing an OLA system can also impact customer satisfaction.  C Imagine you are in a supermarket and suddenly the supervisor attenduB lights go on on all the tills and stay on for the rest of the day.  E In the case of the failure of an OLA system that is what would happenl@ with Supervisor/Managers being responsible for authorising every4 credit card transaction above a certain floor limit.  A Lines get longer and longer people get more and more irritated. IaD agree its not quite the same as losing a SWIFT system but it doesn't> help customer sat because of the the process that replaces it.   Regards3 Andrew Harrison    ------------------------------  % Date: Mon, 08 Dec 2003 11:37:47 +0000 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>oC Subject: Re: OpenVMS clusters give Windows, Unix thorough thrashing'0 Message-ID: <br1nqb$kst$1@new-usenet.uk.sun.com>   Maarten van Tilburg wrote:* > Andrew Harrison SUNUK Consultancy wrote: >  >>B >>There should be a pretty close relationship between the capacityB >>of the system and the cost of downtime assuming that the systems/ >>being compared are equally business critical.m >  > ? > Which relates to the size of the business, not to that of then1 > hardware (with properly sized systems, that is)c >  >  >>> >>If my cluster is half the size and only able to process half= >>the OLA transactions then my exposure is halved and my costr >>of downtime is halved. >  > D > And , in normal situations, income (or profit) would be only half.? > In that case, long downtimes can equally destroy the business.
 > profits. >  - > $ >>TechWise used what was at the time= >>the fastest available Alpha Server the GS320 it had ~1/3 tot! >>1/4 of the capacity of an F15K.n >> >  > @ > Use 4 GS320's in a cluster, if you need that kind of computing > power.  D Sure you could but thats not what the TechWise study actually did so& it ended up being chip paper wrapping.   Regardsh Andrew Harrisonb   ------------------------------  # Date: Mon, 08 Dec 2003 13:39:50 GMT,# From: "John N." <JNixon@cfl.rr.com>rC Subject: Re: OpenVMS clusters give Windows, Unix thorough thrashingt< Message-ID: <Ga%Ab.31537$b01.697588@twister.tampabay.rr.com>  J I really really really hate to say this, but I have to agree with at leastK part of what Andrew is saying.  When doing a TCO study, you have to compare-K systems of similar capacity.  To do anything else is ludicrous.   If I haveaL an application that needs to be able to handle a specific application, and IG need to select a platform on which to run that system,   I will look atRI systems that will be able to handle my needs.  And they will obvisouly beeA systems of similar capacity.  To compare the needs of Boeing to aI* supermarket makes very little sense to me.  L Cany anyone verify Andrews assertion that the Sun system he spoke of and theL GS320 are such performance mismatches?  And is that indeed what the Techwise study compared?s    K "Andrew Harrison SUNUK Consultancy" <Andrew_No.Harrison_No@nospamn.sun.com>j; wrote in message news:bqqk6f$bak$1@new-usenet.uk.sun.com...o > JF Mezei wrote:t > > Andrew Harrison wrote: > >dC > >>The problem with the Study is that it acheives its goal (makingo= > >>OpenVMS look good) through a totally transparent trick ofc@ > >>comparing a the costs of downtime for a mid-range HPQ server< > >>with the costs of downtime for high end servers from the- > >>vendors the study is designed to rubbish.o > >  > >nL > > The size of the machine doesn't necessarily define the cost of downtime. A K > > weather office may require huge amounts of CPU, but downtime of an hour  mayg9 > > not be critical at all for regions without tornadoes.t > >e > B > There should be a pretty close relationship between the capacityB > of the system and the cost of downtime assuming that the systems/ > being compared are equally business critical.j > D > For example the client I work for runs Online Credit Authorisation? > on a Sun Cluster. The cluster is designed to meet a specified  > transaction rate for OLA.n >a> > If the cluster failed then there would be a fixed charge per= > unauthorised transaction payable to each bank involved plusr > an exposure to any fraud.a >s> > If my cluster is half the size and only able to process half= > the OLA transactions then my exposure is halved and my costc; > of downtime is halved. TechWise used what was at the timei= > the fastest available Alpha Server the GS320 it had ~1/3 to.! > 1/4 of the capacity of an F15K.o >d	 > regardsY > Andrew Harrisono >l >t   ------------------------------  % Date: Mon, 08 Dec 2003 18:00:52 +0000i= From: Andrew Harrison <removethisAndrew.snipHarrison@sun.com>sC Subject: Re: OpenVMS clusters give Windows, Unix thorough thrashingr0 Message-ID: <br2aqm$s3d$1@new-usenet.uk.sun.com>   John N. wrote:L > I really really really hate to say this, but I have to agree with at leastM > part of what Andrew is saying.  When doing a TCO study, you have to compareiM > systems of similar capacity.  To do anything else is ludicrous.   If I havewN > an application that needs to be able to handle a specific application, and II > need to select a platform on which to run that system,   I will look atiK > systems that will be able to handle my needs.  And they will obvisouly be C > systems of similar capacity.  To compare the needs of Boeing to am, > supermarket makes very little sense to me. > N > Cany anyone verify Andrews assertion that the Sun system he spoke of and theN > GS320 are such performance mismatches?  And is that indeed what the Techwise > study compared?o >   & Oracle Applications Standard Benchmark1 A 24 CPU Sun F68000 was ~30% faster than a GS320.d  8 The throughput per CPU of the GS320 was 58% of the F6800  5 The F6800 used 900 Mhz US III CPU's the GS320 731 Mhza7 CPU's both systems now support faster CPU's 1.2 Ghz forh! the F6800 1001 Mhz for the GS320.t  - TPC-H GS320 with 32 x 731 Mhz CPU's 4951 QphHe0        F15K  with 72 x 900 Mhz CPU's 18,802 QppH  . The throughput per CPU of the GS320 was 59% of& the F15K and the F15K was 3.8x faster.  0 Again you can also get 1.2Ghz CPU's for the F15K as well.  5 Even on something not too challenging for the GS320's-2 memory subsystem like SPECrate_int and SPECrate_fp3 where you would expect the thing to do a bit betterw you get.;                   F6800 24 CPU    GS 320 32 CPU F15K 72 CPUn2 SPECint_rate     180             218           4782 SPEcint_fp       205             242           717   Similar stories for SAP6  6 In reality the GS320 was never equivalent to a F15K or3 even the F15K's smaller brother the F12K instead it.2 was comparable with the F6800 which is a mid range0 server from Sun, ditto for comparisons with IBM.   Regardsh Andrew Harrison    > M > "Andrew Harrison SUNUK Consultancy" <Andrew_No.Harrison_No@nospamn.sun.com> = > wrote in message news:bqqk6f$bak$1@new-usenet.uk.sun.com...o >  >>JF Mezei wrote:s >> >>>Andrew Harrison wrote:e >>>  >>>eC >>>>The problem with the Study is that it acheives its goal (makingn= >>>>OpenVMS look good) through a totally transparent trick ofe@ >>>>comparing a the costs of downtime for a mid-range HPQ server< >>>>with the costs of downtime for high end servers from the- >>>>vendors the study is designed to rubbish.t >>>u >>>2K >>>The size of the machine doesn't necessarily define the cost of downtime.q >  > A  > J >>>weather office may require huge amounts of CPU, but downtime of an hour >  > mayt > 8 >>>not be critical at all for regions without tornadoes. >>>  >>B >>There should be a pretty close relationship between the capacityB >>of the system and the cost of downtime assuming that the systems/ >>being compared are equally business critical.' >>D >>For example the client I work for runs Online Credit Authorisation? >>on a Sun Cluster. The cluster is designed to meet a specifiede >>transaction rate for OLA.l >>> >>If the cluster failed then there would be a fixed charge per= >>unauthorised transaction payable to each bank involved pluso >>an exposure to any fraud.c >>> >>If my cluster is half the size and only able to process half= >>the OLA transactions then my exposure is halved and my costt; >>of downtime is halved. TechWise used what was at the timet= >>the fastest available Alpha Server the GS320 it had ~1/3 to ! >>1/4 of the capacity of an F15K.h >>	 >>regardss >>Andrew Harrisont >> >> >  >  >    ------------------------------   Date: 8 Dec 2003 09:36:20 -0800o1 From: keithparris_NOSPAM@yahoo.com (Keith Parris)w& Subject: OpenVMS VAX Emulator Services= Message-ID: <cf15391e.0312080936.41451779@posting.google.com>t  : HP OpenVMS: VAX Emulator Services extend application life  by Steve Davis  E Customers with business-critical software applications powered by the B OpenVMS operating system on VAX- or MicroVAX-based systems can useD Software Resources International's (SRI) VAX to CHARON-VAX emulator,C which extends the usability of VAX and MicroVAX applications on thefD OpenVMS operating system. Customers can transfer applications to newA hardware platforms without any porting effort. Because CHARON-VAXaD emulates a complete VAX system in an OpenVMS, Windows NT, or WindowsC 2000 environment, it eliminates the need for recoding or rebuildinge
 applications.u  5 View the "VAX Emulator Services" information sheet atiG http://h18011.www1.hp.com/iqcenter/infosheets/Vax_Emulator_External.pdfe  ; Customers may view the benefits of VAX Emulator Services at 5 http://h18011.www1.hp.com/iqcenter/expertise.html#vaxn  # Visit the IQ Center public website:,# http://h18011.www1.hp.com/iqcenter/s   ------------------------------  % Date: Mon, 08 Dec 2003 14:14:46 +0000)0 From: Chris Sharman <chris.sharman@sorry.nospam>' Subject: OSU http server & http headerse4 Message-ID: <br210m$554$1$8302bc10@news.demon.co.uk>  1 We generate PDFs for customer approval/amendment.sD If customers request amendments, we do them & create new PDFs (same J filename). Customers frequently don't see the changes because of cacheing.  G Can anyone suggest what http headers we should be using to ensure that eB browsers (especially ie) at least check the file date every time ?8 And how we should get the OSU HTTP server to send them ?  4 I've got "fileexpire /proofs/*.pdf CDT+00:04:30" in F www_root:[system]http_paths.conf, which I thought would do it (expire H all PDFs 4.5 mins after creation, forcing a check-back and/or re-fetch).   Thanks,u Chrisr   Here's an example pdf document:i> http://services.ccagroup.co.uk/proofs/tn5604_devicen_color.pdf  ) Fetch_http returns the following headers:e, HTTP/1.0 200 CGI script output data follows. Accept-ranges: bytes Allow-ranges: bytest, Last-Modified: Mon, 08 Dec 2003 13:59:10 GMT Content-Length: 111047 MIME-version: 1.0t Server: OSU/3.9c;UCX Content-type: application/pdfo# Date: Mon, 08 Dec 2003 14:00:23 GMT.   ------------------------------  # Date: Mon, 08 Dec 2003 14:26:36 GMTh> From: Michael Austin <maustin@no-more-spam.firstdbasource.com>+ Subject: Re: OSU http server & http headersa> Message-ID: <wS%Ab.32$ko3.13403245@newssvr11.news.prodigy.com>   Chris Sharman wrote:  3 > We generate PDFs for customer approval/amendment. F > If customers request amendments, we do them & create new PDFs (same L > filename). Customers frequently don't see the changes because of cacheing. > I > Can anyone suggest what http headers we should be using to ensure that rD > browsers (especially ie) at least check the file date every time ?: > And how we should get the OSU HTTP server to send them ? > 6 > I've got "fileexpire /proofs/*.pdf CDT+00:04:30" in H > www_root:[system]http_paths.conf, which I thought would do it (expire J > all PDFs 4.5 mins after creation, forcing a check-back and/or re-fetch). > 	 > Thanks,o > Chriss > ! > Here's an example pdf document:w@ > http://services.ccagroup.co.uk/proofs/tn5604_devicen_color.pdf > + > Fetch_http returns the following headers:h. > HTTP/1.0 200 CGI script output data follows. > Accept-ranges: bytes > Allow-ranges: bytes . > Last-Modified: Mon, 08 Dec 2003 13:59:10 GMT > Content-Length: 111047 > MIME-version: 1.0e > Server: OSU/3.9c;UCX > Content-type: application/pdf-% > Date: Mon, 08 Dec 2003 14:00:23 GMTi >   F IE -> TOOLS --> Internet Options --> SETTINGS --> Check for new pages  every time you visit the pager  < take a look at <http://vancouver-webpages.com/META/FAQ.html>H <meta http-equiv="Pragma" content="no-cache;>  !! causes page to not be  cached at all...   Michael Austin   ------------------------------  % Date: Mon, 08 Dec 2003 14:59:48 +0000.0 From: Chris Sharman <chris.sharman@sorry.nospam>+ Subject: Re: OSU http server & http headerso4 Message-ID: <br23l4$85d$1$8302bc10@news.demon.co.uk>   Michael Austin wrote:i   > Chris Sharman wrote: > 4 >> We generate PDFs for customer approval/amendment.G >> If customers request amendments, we do them & create new PDFs (same  D >> filename). Customers frequently don't see the changes because of  >> cacheing. >>J >> Can anyone suggest what http headers we should be using to ensure that E >> browsers (especially ie) at least check the file date every time ?g; >> And how we should get the OSU HTTP server to send them ?e >>7 >> I've got "fileexpire /proofs/*.pdf CDT+00:04:30" in aI >> www_root:[system]http_paths.conf, which I thought would do it (expire sK >> all PDFs 4.5 mins after creation, forcing a check-back and/or re-fetch).n >>
 >> Thanks, >> Chris >>" >> Here's an example pdf document:A >> http://services.ccagroup.co.uk/proofs/tn5604_devicen_color.pdft >>, >> Fetch_http returns the following headers:/ >> HTTP/1.0 200 CGI script output data follows.f >> Accept-ranges: bytes  >> Allow-ranges: bytes/ >> Last-Modified: Mon, 08 Dec 2003 13:59:10 GMTn >> Content-Length: 111047  >> MIME-version: 1.0 >> Server: OSU/3.9c;UCX   >> Content-type: application/pdf& >> Date: Mon, 08 Dec 2003 14:00:23 GMT >> > H > IE -> TOOLS --> Internet Options --> SETTINGS --> Check for new pages  > every time you visit the pagem  C If our customers were clued-up enough & willing to do this, then I lI suspect there wouldn't be a problem in the first place. I can't persuade rI thousands of customers to fiddle their IE config. I need to configure my fE website so that it 'just works right', for any normal browser config.a  > > take a look at <http://vancouver-webpages.com/META/FAQ.html>  D Well, "Cache-Control: must-revalidate" seems to be what I want, and G "Expires:" for http 1.0. I'd prefer not to use no-cache if possible (a c4 lot of clients seem to fetch their pdfs repeatedly).B But I've used the OSU HTTPserver "fileexpire" tag, to no avail ...I Anyone know how to generate them, without using html "<meta http-equiv",  $ which only works for html, not pdf ?4 Or where there's better info on the OSU httpserver ?  J > <meta http-equiv="Pragma" content="no-cache;>  !! causes page to not be  > cached at all...  F This is an html fake of an http header, and of course I'm not serving 3 out html here, but PDF, so I can't embed it. Sorry.o   Thanks,a Chrisq   ------------------------------  # Date: Mon, 08 Dec 2003 15:17:32 GMT " From:   VAXman-  @SendSpamHere.ORG+ Subject: Re: OSU http server & http headersa0 Message-ID: <00A2A0FC.FC11D854@SendSpamHere.ORG>   In article <wS%Ab.32$ko3.13403245@newssvr11.news.prodigy.com>, Michael Austin <maustin@no-more-spam.firstdbasource.com> writes:i >Chris Sharman wrote:  >l4 >> We generate PDFs for customer approval/amendment.G >> If customers request amendments, we do them & create new PDFs (same eM >> filename). Customers frequently don't see the changes because of cacheing.g >> iJ >> Can anyone suggest what http headers we should be using to ensure that E >> browsers (especially ie) at least check the file date every time ?a; >> And how we should get the OSU HTTP server to send them ?r >> c7 >> I've got "fileexpire /proofs/*.pdf CDT+00:04:30" in sI >> www_root:[system]http_paths.conf, which I thought would do it (expire eK >> all PDFs 4.5 mins after creation, forcing a check-back and/or re-fetch).5 >> m
 >> Thanks, >> Chris >> l" >> Here's an example pdf document:A >> http://services.ccagroup.co.uk/proofs/tn5604_devicen_color.pdfh >> r, >> Fetch_http returns the following headers:/ >> HTTP/1.0 200 CGI script output data follows.i >> Accept-ranges: bytesc >> Allow-ranges: bytes/ >> Last-Modified: Mon, 08 Dec 2003 13:59:10 GMTm >> Content-Length: 111047n >> MIME-version: 1.0 >> Server: OSU/3.9c;UCXe  >> Content-type: application/pdf& >> Date: Mon, 08 Dec 2003 14:00:23 GMT >> m > G >IE -> TOOLS --> Internet Options --> SETTINGS --> Check for new pages d >every time you visit the page >t= >take a look at <http://vancouver-webpages.com/META/FAQ.html>xI ><meta http-equiv="Pragma" content="no-cache;>  !! causes page to not be e >cached at all...h  I I have added this to pages and I have sent the http equivalent in scriptscI and in http enabled apps I have written; IE, in most cases, still caches k	 the page.m   --K http://www.legacy-2000.com  for the best OpenVMS system security solutions.    K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM             r5   "Well my son, life is like a beanstalk, isn't it?" d   ------------------------------  # Date: Mon, 08 Dec 2003 15:20:38 GMT " From:   VAXman-  @SendSpamHere.ORG+ Subject: Re: OSU http server & http headersd0 Message-ID: <00A2A0FD.6A86FC4B@SendSpamHere.ORG>  g In article <br23l4$85d$1$8302bc10@news.demon.co.uk>, Chris Sharman <chris.sharman@sorry.nospam> writes:t >Michael Austin wrote: >  >> Chris Sharman wrote:k >> g5 >>> We generate PDFs for customer approval/amendment.eH >>> If customers request amendments, we do them & create new PDFs (same E >>> filename). Customers frequently don't see the changes because of e
 >>> cacheing.o >>>pK >>> Can anyone suggest what http headers we should be using to ensure that 'F >>> browsers (especially ie) at least check the file date every time ?< >>> And how we should get the OSU HTTP server to send them ? >>> 8 >>> I've got "fileexpire /proofs/*.pdf CDT+00:04:30" in J >>> www_root:[system]http_paths.conf, which I thought would do it (expire L >>> all PDFs 4.5 mins after creation, forcing a check-back and/or re-fetch). >>>m >>> Thanks,t	 >>> Chrisn >>>i# >>> Here's an example pdf document:mB >>> http://services.ccagroup.co.uk/proofs/tn5604_devicen_color.pdf >>> - >>> Fetch_http returns the following headers:d0 >>> HTTP/1.0 200 CGI script output data follows. >>> Accept-ranges: bytes >>> Allow-ranges: bytesh0 >>> Last-Modified: Mon, 08 Dec 2003 13:59:10 GMT >>> Content-Length: 111047 >>> MIME-version: 1.0a >>> Server: OSU/3.9c;UCX! >>> Content-type: application/pdfi' >>> Date: Mon, 08 Dec 2003 14:00:23 GMTn >>>  >> eI >> IE -> TOOLS --> Internet Options --> SETTINGS --> Check for new pages l  >> every time you visit the page > D >If our customers were clued-up enough & willing to do this, then I J >suspect there wouldn't be a problem in the first place. I can't persuade J >thousands of customers to fiddle their IE config. I need to configure my F >website so that it 'just works right', for any normal browser config. > ? >> take a look at <http://vancouver-webpages.com/META/FAQ.html>F >FE >Well, "Cache-Control: must-revalidate" seems to be what I want, and HH >"Expires:" for http 1.0. I'd prefer not to use no-cache if possible (a 5 >lot of clients seem to fetch their pdfs repeatedly). C >But I've used the OSU HTTPserver "fileexpire" tag, to no avail ... J >Anyone know how to generate them, without using html "<meta http-equiv", % >which only works for html, not pdf ?r5 >Or where there's better info on the OSU httpserver ?e >.K >> <meta http-equiv="Pragma" content="no-cache;>  !! causes page to not be S >> cached at all...  > G >This is an html fake of an http header, and of course I'm not serving l4 >out html here, but PDF, so I can't embed it. Sorry. >v >Thanks, >Chris    G I had this problem with the directory server.  I modified the directoryfG server code within OSU to display just the filename but the link itselfsF maintains the ;version#.  This seems to have fixed the issues I've had% with users accessing files with IE.  L --K http://www.legacy-2000.com  for the best OpenVMS system security solutions.o  5K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COMt            o5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  % Date: Mon, 08 Dec 2003 15:55:20 +0000 0 From: Chris Sharman <chris.sharman@sorry.nospam>+ Subject: Re: OSU http server & http headerse4 Message-ID: <br26t8$lsb$1$830fa795@news.demon.co.uk>   VAXman- wrote:  i > In article <br23l4$85d$1$8302bc10@news.demon.co.uk>, Chris Sharman <chris.sharman@sorry.nospam> writes:s >  >>Michael Austin wrote:  >> >> >>>Chris Sharman wrote:t >>>c >>> 5 >>>>We generate PDFs for customer approval/amendment.tH >>>>If customers request amendments, we do them & create new PDFs (same E >>>>filename). Customers frequently don't see the changes because of >
 >>>>cacheing.y >>>>K >>>>Can anyone suggest what http headers we should be using to ensure that uF >>>>browsers (especially ie) at least check the file date every time ?< >>>>And how we should get the OSU HTTP server to send them ? >>>>8 >>>>I've got "fileexpire /proofs/*.pdf CDT+00:04:30" in J >>>>www_root:[system]http_paths.conf, which I thought would do it (expire L >>>>all PDFs 4.5 mins after creation, forcing a check-back and/or re-fetch). >>>> >>>>Thanks,e	 >>>>Chrisb >>>># >>>>Here's an example pdf document:-B >>>>http://services.ccagroup.co.uk/proofs/tn5604_devicen_color.pdf >>>>- >>>>Fetch_http returns the following headers:s0 >>>>HTTP/1.0 200 CGI script output data follows. >>>>Accept-ranges: bytes >>>>Allow-ranges: bytes 0 >>>>Last-Modified: Mon, 08 Dec 2003 13:59:10 GMT >>>>Content-Length: 111047 >>>>MIME-version: 1.0r >>>>Server: OSU/3.9c;UCX! >>>>Content-type: application/pdft' >>>>Date: Mon, 08 Dec 2003 14:00:23 GMTf >>? >>>take a look at <http://vancouver-webpages.com/META/FAQ.html>  >>F >>Well, "Cache-Control: must-revalidate" seems to be what I want, and I >>"Expires:" for http 1.0. I'd prefer not to use no-cache if possible (a e6 >>lot of clients seem to fetch their pdfs repeatedly).D >>But I've used the OSU HTTPserver "fileexpire" tag, to no avail ...K >>Anyone know how to generate them, without using html "<meta http-equiv", e& >>which only works for html, not pdf ?6 >>Or where there's better info on the OSU httpserver ? >>I > I had this problem with the directory server.  I modified the directorygI > server code within OSU to display just the filename but the link itself H > maintains the ;version#.  This seems to have fixed the issues I've had' > with users accessing files with IE.     I So you duck the issue by forcing a different url every time - would urls tH with ";<ver>" on the end work in all mail clients (sent in text emails)?  8 That would be possible, but undesirable - a last resort.I Many customers insist on rekeying the urls we give them - we can tell by 'A the calls we get for their typos. And no, it's not just the poor -G benighted souls saddled with aol - we put <a href="... in the text for aG aol email addresses. Making the url more complicated, and mailing them eH different ones each time would confuse them even more. Making them look D the same, despite being different, would baffle even the relatively G competent. [My situation is different from yours in that mail messages h, have a much greater tendency to hang around]  F And you say pragma no-cache is ignored by ie - what about the expires  and cache-control ?l  H Anyone know how to get the 'fileexpires' configuration working properly = (and for ie5&6), or do I have to go with the ";<ver>" kluge ?u  A <rant>And why do we have to spend so much time working around MS c screwups?</rant>   Thanks,  Chrisd   ------------------------------  # Date: Mon, 08 Dec 2003 16:34:05 GMTl" From:   VAXman-  @SendSpamHere.ORG+ Subject: Re: OSU http server & http headersp0 Message-ID: <00A2A107.AD2B4310@SendSpamHere.ORG>  g In article <br26t8$lsb$1$830fa795@news.demon.co.uk>, Chris Sharman <chris.sharman@sorry.nospam> writes:r {...snip...}J >So you duck the issue by forcing a different url every time - would urls I >with ";<ver>" on the end work in all mail clients (sent in text emails)?a  G The original purpose was to *force* IE to respect the MIME type.  BillyrH is so much smarter than the rest of us.  He doesn't need IE to read the F MIME header because he can tell what to do with the file simply by theH .EXTension of the file.  Yeap!  Billy's IE knew exactly what to do with G the .COM and .MAR files it encountered on my web site!  It tried to RUNeF the .COMs and launched XL for the .MARs.  Adding the ;# caused Billy's? brain-fart to respect the information sent in the MIME headers.o      G >And you say pragma no-cache is ignored by ie - what about the expires d >and cache-control ?  < Don't know, off-hand, if I've ever experimented with either.      B ><rant>And why do we have to spend so much time working around MS  >screwups?</rant>e  E Do you think these are screwups?  I contend that they are intentional E to force everybody to the dark side to use Billywarez servers becausea> of the virtual ubiquitous nature of Billywarez on the desktop. --K http://www.legacy-2000.com  for the best OpenVMS system security solutions.e  -K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM             n5   "Well my son, life is like a beanstalk, isn't it?" M   ------------------------------  # Date: Mon, 08 Dec 2003 14:23:46 GMTo3 From: hammond@not@peek.ssr.hp.com (Charlie Hammond)i& Subject: Re: Passing var into F$SEARCH3 Message-ID: <SP%Ab.10294$Xj4.6375@news.cpqcorp.net>r  ) Others have poited out the coding errors.u; Here is a much simpler (untested) way to do the same thing,D< although it does not save the last file name found and skips- some other tings that might be used elswhere..   $LOOP_1:5 $ FSP = F$SEARCH("INFOPLUS$ROOT:[SITE.RUNTEST]*.TST") " $ IF FSP .EQS. "" GOTO EXIT_LOOP_1
 $ TYPE FSP
 $ GOTO LOOP_1C
 $EXIT_LOOP_1:p   -- GJ       Charlie Hammond -- Hewlett-Packard Company -- Ft Lauderdale  FL  USAF           (hammond@not@peek.ssr.hp.com -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------   Date: 8 Dec 2003 04:55:15 -0800 ) From: navin_2013@yahoo.co.in (navin_2016)e% Subject: porting problems encounterede< Message-ID: <268bf130.0312080455.b31cf9f@posting.google.com>   Hi, E    Can somone please describe the problems one would face when we try F to port a software written in C to another platform some of them being& endianness ,alignment,data types etc ?  C It would be very helpful if you could state the solution along withn? problem .Also can you please give me some pointers and links to 7 documents so that porting can be  easily accomplished ?t   Navine -n   ------------------------------   Date: 8 Dec 2003 15:10:53 GMTr< From: gartmann@non.immunbio.mpg.de.sens (Christoph Gartmann)) Subject: Re: porting problems encounteredn0 Message-ID: <br249t$54i$1@n.ruf.uni-freiburg.de>  h In article <268bf130.0312080455.b31cf9f@posting.google.com>, navin_2013@yahoo.co.in (navin_2016) writes:F >   Can somone please describe the problems one would face when we tryG >to port a software written in C to another platform some of them beinge' >endianness ,alignment,data types etc ?= > D >It would be very helpful if you could state the solution along with@ >problem .Also can you please give me some pointers and links to8 >documents so that porting can be  easily accomplished ?  L You should first tell us the platforms which you would like to port from and9 to. In addition one of these platforms should be OpenVMS.o   Regards,    Christoph Gartmannc   --  E  Max-Planck-Institut fuer      Phone   : +49-761-5108-464   Fax: -452A  ImmunbiologieI  Postfach 1169                 Internet: gartmann@immunbio dot mpg dot deI  D-79011  Freiburg, Germany19                http://www.immunbio.mpg.de/home/menue.htmln   ------------------------------  * Date: Mon, 8 Dec 2003 16:50:42 +0000 (UTC), From: lewis@mazda.mitre.org (Keith A. Lewis)$ Subject: Re: Replacement for CSWING?. Message-ID: <br2a52$9ch$1@newslocal.mitre.org>   "Richard L. Dyson" <rick-dyson@uiowa.edu> writes in article <lZtAb.442412$HS4.3481380@attbi_s01> dated Sat, 06 Dec 2003 23:52:49 GMT: J >I have found that somewhere in the recent ECOs for v7.3-1, the problems IJ >used to have with CSwing v3.7.6 have all but gone away.  NOW, I don't useL >it with ODS-5, but even with ODS-2, it was pretty broken.  I honestly don'tL >know where it got "fixed".  I was not testing CSwing and v7.3-1 anymore andI >just accidentally started using an old executable from OpenVMS v6.2 thata >worked just fine...  E Hmmm, I'm still having a problem, even on ODS-2 disks.  These are theo; patches I've installed so far.  Can you list what you have?c  P DEC AXPVMS VMS731_ACRTL V1.0        Patch       Install     30-MAR-2003 15:30:25P DEC AXPVMS VMS731_SYS V3.0          Patch       Install     11-MAR-2003 18:14:09  H (It might be worthwhile to mention that CSWING does not fail 100% of theJ time on my end either.  Single-node directory trees seem to work fine, for	 example.)d  0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------  # Date: Mon, 08 Dec 2003 17:37:29 GMTm# From: hoff@hp.nospam (Hoff Hoffman)i$ Subject: Re: Replacement for CSWING?3 Message-ID: <tF2Bb.10311$UH4.5439@news.cpqcorp.net>e  ] In article <br2a52$9ch$1@newslocal.mitre.org>, lewis@mazda.mitre.org (Keith A. Lewis) writes:t :"Richard L. Dyson" <rick-dyson@uiowa.edu> writes in article <lZtAb.442412$HS4.3481380@attbi_s01> dated Sat, 06 Dec 2003 23:52:49 GMT:K :>I have found that somewhere in the recent ECOs for v7.3-1, the problems IYK :>used to have with CSwing v3.7.6 have all but gone away.  NOW, I don't use M :>it with ODS-5, but even with ODS-2, it was pretty broken.  I honestly don't M :>know where it got "fixed".  I was not testing CSwing and v7.3-1 anymore and.J :>just accidentally started using an old executable from OpenVMS v6.2 that :>worked just fine...  :0F :Hmmm, I'm still having a problem, even on ODS-2 disks.  These are the< :patches I've installed so far.  Can you list what you have? :2Q :DEC AXPVMS VMS731_ACRTL V1.0        Patch       Install     30-MAR-2003 15:30:25"Q :DEC AXPVMS VMS731_SYS V3.0          Patch       Install     11-MAR-2003 18:14:09N    E   I would encourage downloading and installing the mandatory patches 3E   for OpenVMS -- what ECOs are listed above appear rather incomplete.-B   The above list is missing the VMS731_UPDATE ECO, for instance.    0   The OpeVMS ECO kits are available via the URL:       http://www.itrc.hp.com/c    I :(It might be worthwhile to mention that CSWING does not fail 100% of the-K :time on my end either.  Single-node directory trees seem to work fine, foro
 :example.)  D   There are relevent patches for OpenVMS, and there are fixes to theF   original CSWING source code -- I went looking for the CSWING updatesG   for the Freeware V6.0 distribution, but could not find a copy posted.tF   (If somebody has an updated copy of CSWING, please let me know where<   and I will get the code posted onto the Freeware website.)  E   Before proceding further, visit Google and dig up the archives from F   a year or two ago, when last this topic arose -- you'll find detailsD   of the OpenVMS bugs, as well as the bugs in CSWING discussed then.  ?   For folks running DECwindows, see the provided Fileview tool.a  N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faqrN  --------------------------- pure personal opinion ---------------------------E         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.como   ------------------------------   Date: 8 Dec 2003 09:50:05 -0600 + From: young_r@encompasserve.org (Rob Young)a) Subject: Re: Results of SAN vendor survey 3 Message-ID: <D+vZPsO+nwMY@eisner.encompasserve.org>p  f In article <32MAb.258811$Dw6.891587@attbi_s02>, brad@.gateway.2wire.net (Bradford J. Hamilton) writes:d > In article <F0LAb.111843$Eq1.71916@twister.rdc-kc.rr.com>, "Mike Naime" <mnaime@kc.rr.com> writes: > !tB > !Bradford J. Hamilton <brad@.gateway.2wire.net> wrote in message- > !news:2xHAb.328032$275.1086687@attbi_s53... 7 > !> In article <3FD32146.817D5521@istop.com>, JF Mezein& > !<jfmezei.spamnot@istop.com> writes: > !> !snip! O > !> !Judging from the HP apologists on this group, I was fairly convinced thatd > !HPlL > !> !was seen as one of the leading storage product vendors. Biased or not, > !thistK > !> !survey didn't put HP anywhere near the leading pack.  This is at oddsr > !witheI > !> !statements from HP that it is a leading vendor of storage products.t > !nN > !I do not see "HP" as a leading vendor.  I still see Compaq as a top vendor.K > !HP wants to claim Compaq/Digital Storage Works as their product now, but1G > !they still have competing products that suck, and will not work withoM > !Alpha's.  I'm fairly certain that whoever ran this survey is also ignoringg > !the Compaq EVA line.  > !q > P > Although technically an HP product, HP did its best to denigrate EVA when theyM > made a presentation to my previous employer.  They spent most of their timeeM > pushing their "XP" product line, and dismissed EVA as being a "middle-tier"eP > product, meant for smaller (less-important?) customers.  The only problem withP > their strategy at the time, was that the "XP" line was not usable by VMS (thisN > situation may have changed in the past year or so, but I'm now working for a? > much smaller company, not in the market for SAN of any type).  > O > In any case, the company purchased EVA, and was very pleased with the result.p >  > !snip! > L > __________________________________________________________________________C > Bradford J. Hamilton                    "All opinions are my own"sM > bMradAhamiPltSon-at-coMmcAast.nPeSt     "Lose the MAPS, and replace '-at-'  2 >                                          with @"   ------------------------------   Date: 8 Dec 2003 09:59:53 -0600s+ From: young_r@encompasserve.org (Rob Young) ) Subject: Re: Results of SAN vendor surveye3 Message-ID: <hhO69RzZsSbp@eisner.encompasserve.org>-  f In article <32MAb.258811$Dw6.891587@attbi_s02>, brad@.gateway.2wire.net (Bradford J. Hamilton) writes:  P > Although technically an HP product, HP did its best to denigrate EVA when theyM > made a presentation to my previous employer.  They spent most of their time M > pushing their "XP" product line, and dismissed EVA as being a "middle-tier" P > product, meant for smaller (less-important?) customers.  The only problem withP > their strategy at the time, was that the "XP" line was not usable by VMS (thisN > situation may have changed in the past year or so, but I'm now working for a? > much smaller company, not in the market for SAN of any type).i >   G 	Ah... depends on who is doing the presentation.  It isn't middle-tier,tG 	it is modular.  Part of a SAN presentation, here is one of the slides:d  G "Customers are increasingly interested in modular storage because it isoK flexible, scalable, [has] less cost and more dynamics of scaling capacity," F Lewis says. "Cost is becoming a bigger factor, especially price versusI performance. With modular we can offer lower latency [than monolithic]." M  # 			Mark Lewis - CTO EMC Corporation:  B 	But it goes beyond "defining terms."  Of course you have to flesh0 	out all other aspects to support your strategy.  O > In any case, the company purchased EVA, and was very pleased with the result.v  @ 	You see, VMS forced a win.  3 years ago VMS eliminated more andA 	probably forceed more wins than Compaq cared to admit.  Today iti 	forces far fewer wins.    				Rob    ------------------------------  # Date: Mon, 08 Dec 2003 12:52:15 GMTu0 From: "Guy Peleg" <guy.peleg@hp.com_remove_this> Subject: SEARCH enhancemento3 Message-ID: <3u_Ab.10290$xp4.3439@news.cpqcorp.net>   J Here is a sneak preview of a new enhancement to search that will ship with V8.2 :   BLUSKY> ty test.txts
 first line second linee
 third line
 forth line
 fifth line
 sixth line  @ Now let's search the file for the word line, limit the number of) matches to 2 and skip the first 4 matchesp( BLUSKY> sea test.txt/limit=2/skip=4 line
 fifth line
 sixth line  C One of the things I like about this is that you can now type a fileyD from the middle.  Let's say I want to type the file starting the 4th line :  = BLUSKY> search test.txt/skip=3/match=nor "nonexistancestring"r
 forth line
 fifth line
 sixth line BLUSKY>c  A Coming soon to a system near you......(actually not so soon.....)    Guyt   ------------------------------  # Date: Mon, 08 Dec 2003 13:06:31 GMTt" From:   VAXman-  @SendSpamHere.ORG Subject: Re: SEARCH enhancement-0 Message-ID: <00A2A0EA.AE56FC18@SendSpamHere.ORG>  f In article <3u_Ab.10290$xp4.3439@news.cpqcorp.net>, "Guy Peleg" <guy.peleg@hp.com_remove_this> writes:K >Here is a sneak preview of a new enhancement to search that will ship withn >V8.2 :. >> >BLUSKY> ty test.txt >first linel >second line >third lineb >forth linea >fifth linel >sixth lineo >hA >Now let's search the file for the word line, limit the number of * >matches to 2 and skip the first 4 matches) >BLUSKY> sea test.txt/limit=2/skip=4 linep >fifth line  >sixth lineb >tD >One of the things I like about this is that you can now type a fileE >from the middle.  Let's say I want to type the file starting the 4thl >line :l >y> >BLUSKY> search test.txt/skip=3/match=nor "nonexistancestring" >forth linea >fifth lineo >sixth linem >BLUSKY>  . Great!  Just don't change the verb to grep. ;)      B >Coming soon to a system near you......(actually not so soon.....)  E I'm assuming this will be in ALL VMS flavors not just Itanium flavor?i     --K http://www.legacy-2000.com  for the best OpenVMS system security solutions.8   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?" a   ------------------------------  # Date: Mon, 08 Dec 2003 13:15:21 GMT10 From: "Guy Peleg" <guy.peleg@hp.com_remove_this> Subject: Re: SEARCH enhancement 3 Message-ID: <JP_Ab.10293$db4.9888@news.cpqcorp.net>t  1 I did not specify the architecture on purpose ;-)5  / I see the hidden question.....it will be on VAX    Guyo    , <VAXman- @SendSpamHere.ORG> wrote in message* news:00A2A0EA.AE56FC18@SendSpamHere.ORG...A > In article <3u_Ab.10290$xp4.3439@news.cpqcorp.net>, "Guy Peleg"i& <guy.peleg@hp.com_remove_this> writes:H > >Here is a sneak preview of a new enhancement to search that will ship with	 > >V8.2 :8 > >  > >BLUSKY> ty test.txt
 > >first line  > >second line
 > >third line 
 > >forth line6
 > >fifth linet
 > >sixth linev > >uC > >Now let's search the file for the word line, limit the number ofd, > >matches to 2 and skip the first 4 matches+ > >BLUSKY> sea test.txt/limit=2/skip=4 linei
 > >fifth line 
 > >sixth liner > >rF > >One of the things I like about this is that you can now type a fileG > >from the middle.  Let's say I want to type the file starting the 4ths	 > >line :  > >>@ > >BLUSKY> search test.txt/skip=3/match=nor "nonexistancestring"
 > >forth lineh
 > >fifth lineh
 > >sixth linei
 > >BLUSKY> >n0 > Great!  Just don't change the verb to grep. ;) >t >i >oD > >Coming soon to a system near you......(actually not so soon.....) >>G > I'm assuming this will be in ALL VMS flavors not just Itanium flavor?  >d >s > --B > http://www.legacy-2000.com  for the best OpenVMS system security
 solutions. > 2 > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM >o6 >   "Well my son, life is like a beanstalk, isn't it?"   ------------------------------  # Date: Mon, 08 Dec 2003 14:53:43 GMTd# From: "John N." <JNixon@cfl.rr.com>e Subject: Re: SEARCH enhancementn< Message-ID: <Xf0Bb.31552$b01.705846@twister.tampabay.rr.com>  L Will this buy us a performance boost?   We have an awful design problem, and; this could conceivably save us some serious re-design work.e  L Our application generates a few huge log files throughout the day.   The logI files grow to several hundred thousand blocks and we have several supportcL people that have to search this file hundreds of times daily.  SEARCH is our single biggest cpu user.  I If they could do a SEARCH/STAT and see how many records there are, and onsJ the next search, they could skip all the records they previously searched,I and if that would save them the IO and CPU time associated with searching/@ the same data over and over, that would be a huge benefit to us.    ; "Guy Peleg" <guy.peleg@hp.com_remove_this> wrote in message - news:3u_Ab.10290$xp4.3439@news.cpqcorp.net...PL > Here is a sneak preview of a new enhancement to search that will ship with > V8.2 : >. > BLUSKY> ty test.txtt > first line
 > second lineS > third line > forth line > fifth line > sixth line >DB > Now let's search the file for the word line, limit the number of+ > matches to 2 and skip the first 4 matcheso* > BLUSKY> sea test.txt/limit=2/skip=4 line > fifth line > sixth line >VE > One of the things I like about this is that you can now type a fileoF > from the middle.  Let's say I want to type the file starting the 4th > line : >n? > BLUSKY> search test.txt/skip=3/match=nor "nonexistancestring"C > forth line > fifth line > sixth line	 > BLUSKY>V > C > Coming soon to a system near you......(actually not so soon.....)r >d > Guyr >i >n >  >l   ------------------------------  % Date: Mon, 08 Dec 2003 15:26:49 +0000/0 From: Chris Sharman <chris.sharman@sorry.nospam> Subject: Re: SEARCH enhancement 4 Message-ID: <br257p$6tj$1$8300dec7@news.demon.co.uk>   John N. wrote:  N > Will this buy us a performance boost?   We have an awful design problem, and= > this could conceivably save us some serious re-design work.  > N > Our application generates a few huge log files throughout the day.   The logK > files grow to several hundred thousand blocks and we have several support2N > people that have to search this file hundreds of times daily.  SEARCH is our > single biggest cpu user. > K > If they could do a SEARCH/STAT and see how many records there are, and on L > the next search, they could skip all the records they previously searched,K > and if that would save them the IO and CPU time associated with searchingiB > the same data over and over, that would be a huge benefit to us.  H To skip N records of a normal log file would involve scanning over them I to discover the start position of the N+1'th record, so you'd still have 5 to read it all.i  E It was unclear from Guy's post, whether /skip skipped all records or aE just matches - if just matches you'd have to do all the work, & just d suppress some output.c  I The process you describe sounds like a terrible waste of both manpower & oH cpu power though. You'd be much better off fixing the application to do H something more useful with the 'interesting' records (you imply they're ) searching for the same thing repeatedly).d   Chris    ------------------------------  # Date: Mon, 08 Dec 2003 15:09:30 GMT - From: Mike Rechtman <michael.rechtman@hp.com>u Subject: Re: SEARCH enhancementb& Message-ID: <3FD4B047.753C1D52@hp.com>   John N. wrote: > N > Will this buy us a performance boost?   We have an awful design problem, and= > this could conceivably save us some serious re-design work.  > N > Our application generates a few huge log files throughout the day.   The logK > files grow to several hundred thousand blocks and we have several supportoN > people that have to search this file hundreds of times daily.  SEARCH is our > single biggest cpu user. > K > If they could do a SEARCH/STAT and see how many records there are, and onhL > the next search, they could skip all the records they previously searched,K > and if that would save them the IO and CPU time associated with searchingmB > the same data over and over, that would be a huge benefit to us. >  ... <O.P. snipped>...e3 You could, if the increments are not too large do -o= pipe search/stat/windo=0 /match=NOT file.lg "abracadabra"....r# to find the current number of lines0  # next time, find the number of lines 3 subtract previous number to find number incrementedM) type/tail=<increment> /out=temporary-fileo ...-   Possibly more IO, less CPU....   Mike   > >S > >c   --  E --------------------------------------------------------------------- E Usual disclaimer: All opinions are mine alone, perhaps not even that.a? Mike Rechtman                            *rechtman@tzora.co.il*nF Kibbutz Tzor'a.                          Voice (home): 972-2-9908337  B   "20% of a job takes 80% of the time, the rest takes another 80%"E ---------------------------------------------------------------------4 -----BEGIN GEEK CODE BLOCK-----r Version: 3.1: GCM/CS d(-)pu s:+>:- a++ C++ U-- L-- W++ N++ K? w--- V+++$6 PS+ PE-- t 5? X- tv-- b+ DI+ D-- G e++ h--- r+++ y+++@ ------END GEEK CODE BLOCK------h   ------------------------------  # Date: Mon, 08 Dec 2003 15:41:36 GMT>9 From: Hein van den Heuvel <hein_netscape@eps.zko.dec.com>D Subject: Re: SEARCH enhancementr/ Message-ID: <3FD49A5E.E78F93DC@eps.zko.dec.com>>   "John N." wrote:  ' > Will this buy us a performance boost?l   :u  P > we have several support people that have to search this file hundreds of times0 > daily.  SEARCH is our single biggest cpu user.  N No, this new window will not help you. It will still read all records to count down.w  O The only new that could help you, but this is not implemented (nor requested?!).+ today is the ability to specify an RMS RFA.nL This stands for Record File Address. It allows for direct file access. It isO much similar to the C/perl SEEK function, but it normally needs the exact startF/ byte of the target records (VBN + OFFSET or ID)/O That would of course also require a way to display an RFA from earlier seaches.e. Maybe as part of a match or statistics output?H The only standard tool outputting (opaque!) RFAs to date is DUMP/RECORD.  J Instead of doing the RFA, or in addition to, search could possibily take a& /BYTE_START_HINT or /BLOCK_START_HINT.L I would suggest _HINT in the parameter name to indicate that it might not be honored exactly as specified. L For STREAM files it is trivial. For VARIABLE length record file search would' have to try find a real record boundaryeO (read 16 bits on even boundary, add to current position and even out. See if ite: points to a next, 16 bit  counter with alue less than LRL)N For INDEXED files it would be a blcok to start in and could be anywhere in the5 logical structure... but it coudl still be valueable.     P In the mean time I would stongly encourage you to write your own tool instead of
 using search.sK It is TRIVIAL to start a search with your own tool, where you last left of.xH You coudl easily print out a number, or remember in a symbol or logical.K You could make a miny menu mapping say a timestamp to a starting RFA and sot on...bM You are currently using a hammer instead of a screwdriver... don't wait for aa2 better hammer to be invented... buy a screwdriver!   Cheers,  Hein.    ------------------------------  # Date: Mon, 08 Dec 2003 15:45:36 GMTt0 From: "Guy Peleg" <guy.peleg@hp.com_remove_this> Subject: Re: SEARCH enhancement-2 Message-ID: <A01Bb.10301$1w4.348@news.cpqcorp.net>   Hi John,  L You should consider upgrading to V7.3-2. In V7.3-2 performance of SEARCH had been dramatically improved.RH Depends on the files and load you may see 1:2 reduction in CPU and 1:2.5 reduction in I/O.n  I If you can't upgrade..let me know and I might be able to backport the fixe   As for /SKIP - it skips matchesm   Guy.. "John N." <JNixon@cfl.rr.com> wrote in message6 news:Xf0Bb.31552$b01.705846@twister.tampabay.rr.com...J > Will this buy us a performance boost?   We have an awful design problem, andh= > this could conceivably save us some serious re-design work.  >pJ > Our application generates a few huge log files throughout the day.   The logtK > files grow to several hundred thousand blocks and we have several supportdJ > people that have to search this file hundreds of times daily.  SEARCH is ourd > single biggest cpu user. > K > If they could do a SEARCH/STAT and see how many records there are, and on,L > the next search, they could skip all the records they previously searched,K > and if that would save them the IO and CPU time associated with searchingoB > the same data over and over, that would be a huge benefit to us. >A >p= > "Guy Peleg" <guy.peleg@hp.com_remove_this> wrote in message,/ > news:3u_Ab.10290$xp4.3439@news.cpqcorp.net...1I > > Here is a sneak preview of a new enhancement to search that will shipi with
 > > V8.2 : > >n > > BLUSKY> ty test.txtT > > first line > > second liner > > third line > > forth line > > fifth line > > sixth line > >iD > > Now let's search the file for the word line, limit the number of- > > matches to 2 and skip the first 4 matches", > > BLUSKY> sea test.txt/limit=2/skip=4 line > > fifth line > > sixth line > >pG > > One of the things I like about this is that you can now type a file H > > from the middle.  Let's say I want to type the file starting the 4th
 > > line : > >-A > > BLUSKY> search test.txt/skip=3/match=nor "nonexistancestring"m > > forth line > > fifth line > > sixth line > > BLUSKY>I > >)E > > Coming soon to a system near you......(actually not so soon.....)" > >  > > Guy- > >- > >- > >- > >  >e >o   ------------------------------  % Date: Mon, 08 Dec 2003 10:45:09 +0000RO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>RB Subject: Re: Sun to use AMD Opteron - announcement expected Monday0 Message-ID: <br1knm$jrv$1@new-usenet.uk.sun.com>   Keith Parris wrote:>] > JF Mezei <jfmezei.spamnot@istop.com> wrote in message news:<3FCFB81D.F75699CC@istop.com>...s > O >>Based on comments I have heard here, it seems to me that there is very littleeM >>cross polination between the VMS and Tandem/NSK folks as well as HP-UX with  >>regards to systems design. >  > B > VMS, NSK, and Tru64 share IP stack code.  HP-UX will, of course,A > benefit from VMS Cluster technology by way of TruClusters code.S >   ? Ummm are you really really sure about TruCluster making it intop6 HP-UX, at the moment the project doesn't look to safe.  > You seem to be a tad late at recycling HP marketing literatureE (your recent TPC-C posting) perhaps you have also missed the 12 monthtE delay that HP recently announced for the release of Tru64 integrationr with HP-UX.p    H > The designers of Itanium systems have been very helpful and interested4 > in meeting the needs of OpenVMS in system designs.  6 I should hope so and its a bit suprising that you even mention it as a plus point.    Regards  Andrew Harrison    ------------------------------  % Date: Mon, 08 Dec 2003 13:38:49 +0000>O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> B Subject: Re: Sun to use AMD Opteron - announcement expected Monday0 Message-ID: <br1ut9$nep$1@new-usenet.uk.sun.com>   Bill Todd wrote:> > "Greg Cagle" <news@removethisgregcagle.com> wrote in message+ > news:vt1j4jdqttip27@corp.supernews.com...I >  > ...u >  > 8 >>I don't trust Sun and I don't trust you personally. To+ >>repeat - can you back up your assertions?k >  > L > While I can understand your not trusting Andrew, Sun's record in followingM > through on its plans doesn't seem that bad to me (save for problems meetingbL > target dates).  Its purchase of Afara (and the Niagara technology) a whileK > ago was covered by the industry press, its intent to manufacture productstH > based on this technology is fully public, Fujitsu's SPARC64 technologyK > already exists (along with a future roadmap), and USIV, while late, seemslJ > fairly close to the sampling stage.  USV may be more like vaporware, andM > whether it will ever incorporate some of the technologies that Sun has beentN > actively pursuing for a long time now (asynchronous cooperation on the chip,I > SMT, I forget what else) may be questionable, but the rest seems prettyt > credible.  >    There is one further point  A The attempt by members of the choir to compare and contrast (I amcD being nice) HPQ/Compaqs treatment of Alpha and their Alpha customers7 and Sun's SPARC business ignores some undeniable facts.   B Sun has a range of products currently on sale the V480->F15K whichD currently run Ultra III, there is ample evidence that Sun will bringG Ultra IV to market and because Ultra IV is designed to run in V480-F15K F existing customers will get what Sun had in their product roadmaps and: customers investment in these platforms will be preserved.  D HPQ has a range of Alpha Server products on sale which currently runA EV7. EV79 has now been cancelled and so existing customers of EV7f= systems have had their investment protection roadmap cut off.4  H Sure they could migrate to Itanium when OpenVMS ships for it but are HPQ? going to give them what they paid for their EV7 system and fundn@ all the costs of the migration as well ? Answers on a post card.  F So even if Sun doesn't deliver US V (I am not suggesting that we won'tH BTW) Sun will not have done what HPQ has done which is hit our customers  where it hurts in their pockets.  H A large number of ITT's ask for headroom in a platform, some insist thatA this is headroom deliverable today, some that it can be deliverede& through CPU's that are on the roadmap.  H If the need for headroom is real and the customer allowed HPQ the option= of a headroom based on processor roadmaps then the inevitableu@ consequence of the EV79 cancellation is an earlier than expected: replacement of the EV7 based platform with something else.   regards> Andrew Harrison    ------------------------------  # Date: Mon, 08 Dec 2003 17:52:16 GMTd9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com>gB Subject: Re: Sun to use AMD Opteron - announcement expected Monday3 Message-ID: <kT2Bb.10313$kI4.3536@news.cpqcorp.net>t  I I restored the quote that Keith responded to, which clearly shows you areE; incorrect.  Your rebuttal was a non-responsive redirection.p  J But in answer your rebuttal, yes you can buy a VMS workstation - and thereD are more than a few people who do.  But the fact is that there is noL competition for the general "workstation" market any more - Windows has won.D What remains of the UNIX (and VMS) workstation market is legacy, andL specialized - or used as SW development stations.  The fact is that there isJ precious little in that market that can't be done with (one or more) PC's.K It is overwhelmingly Windows.  Even OS's like Solaris or Linux are noise inr this market.  J DECwrite was a modified version of a buyout that was intended to be commonJ for Windows, UNIX and VMS.  The marketplace spoke.  It's possible that VMSI could have thrown engineering resources at it to continue to develop it -eD but frankly there were arguably better, cheaper and easier solutionsE available for PC's.  I don't think there is a market for WPS any more K either.  If you want a generic, widely known, cheap WYSIWYG word processingx application - buy a $500 PC.  E As to PDF, we continue to invest and make new available tools for ournJ customers in the e-business space.  There are solutions available for you.L However, the simple truth is the vast majority of customers have PC's, and aJ heterogenious environment - they use the tool most suitable for the job at hand.d  I In any case, while we sell many GS1280's - we sell many more units in theMJ 1-4 processor market.  We are competetive in both price and performance inF most of these markets, and Itanium will allow us to reman competetive.    7 "JF Mezei" <jfmezei.spamnot@istop.com> wrote in message " news:3FD3B643.B227FCF@istop.com...  5 JF Mezei <jfmezei.spamnot@istop.com> wrote in message % news:<3FCE493D.627363AB@istop.com>...eK > VMS started in workstations, small servers, midrange servers and high endt5 > systems, and all that is left are high end systems.n >o > Keith Parris wrote:nJ > > VMS started in midrange systems (11/780) and moved in both directions,G > > and you can buy anything from a workstation to a cluster of GS1280seE > > (arguably mainframe-class) today, with strong products across the0 > > entire range.H >.L > Sorry, while you *can* buy a workstation running VMS, Digital , Compaq and HPL > make sure that they are not priced competitively with the competition. And ifI > Digital wanted VMS to remain in the workstation market, why did DigitallJ > abandon all its software products attributed to workstations ? (Decwrite etc) >eK > Granted, they have ported Mozzilla to Alpha-VMS. But haven't gotten Adobes toL > port the official PDF reader, especially considering they want to have pdf& > documentation instead of bookreader.   ------------------------------  # Date: Mon, 08 Dec 2003 18:03:06 GMT 9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> B Subject: Re: Sun to use AMD Opteron - announcement expected Monday3 Message-ID: <u13Bb.10314$hL4.1076@news.cpqcorp.net>e  K "Andrew Harrison SUNUK Consultancy" <Andrew_No.Harrison_No@nospamn.sun.com>r; wrote in message news:br1knm$jrv$1@new-usenet.uk.sun.com...v > Keith Parris wrote:t9 > > JF Mezei <jfmezei.spamnot@istop.com> wrote in message % news:<3FCFB81D.F75699CC@istop.com>...  > >yJ > >>Based on comments I have heard here, it seems to me that there is very littleJ > >>cross polination between the VMS and Tandem/NSK folks as well as HP-UX with > >>regards to systems design. > >  > >tD > > VMS, NSK, and Tru64 share IP stack code.  HP-UX will, of course,C > > benefit from VMS Cluster technology by way of TruClusters code.t > >I >oA > Ummm are you really really sure about TruCluster making it into'8 > HP-UX, at the moment the project doesn't look to safe. >e  K Yes.  Since I see lots of the traffic on AdvFS and TruClusters - you may bejL listening to sources of NIH - *you* shouldn't put too much faith or FUD into them.t   > J > > The designers of Itanium systems have been very helpful and interested6 > > in meeting the needs of OpenVMS in system designs. >   I Unfortunately, because of FUD from people like Andrew - we sometimes feel.# compelled to point out the obvious.L   ------------------------------   Date: 8 Dec 2003 09:43:10 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)i5 Subject: Re: VAX 11/750 and RL02 - trying to boot VMSF3 Message-ID: <OHJOFGm5eWsw@eisner.encompasserve.org>o  c In article <br0390$p95@library1.airnews.net>, "misc@vectorgames.org" <misc@vectorgames.org> writes:  > 7 > Could this be a UNIBUS backplane jumper/wiring issue?0 > D > Maybe the controller requires DMA support but the backplane isn't  > configured for it?  B   I would assume that any disk controller is a DMA device and mustF   have the DMA jumper removed from the UNIBUS backplane.  Installation5   instructions for the board would contain specifics.h   ------------------------------  # Date: Mon, 08 Dec 2003 17:27:21 GMTf# From: hoff@hp.nospam (Hoff Hoffman)o5 Subject: Re: VAX 11/750 and RL02 - trying to boot VMSn3 Message-ID: <Zv2Bb.10309$UH4.4827@news.cpqcorp.net>   c In article <bqtqaj$39v@library1.airnews.net>, "misc@vectorgames.org" <misc@vectorgames.org> writes:r  G :I have a VAX 11/750 that wants to join the rest of it's brothers in a : :VAXCluster. : I :I was able to dig up a QBus RL02 controller, and using a VAX 4000 I was eH :able to install VMS 6.1 Standalone Backup to an RL02. The VAX 4000 was G :then able to successfully boot from this disk pack. I'm trying to use lJ :the RL02 since it is the only drive that I currently have that I can use ' :with my QBus VAXen *and* UNIBUS Vaxen.d : G :I have a UNIBUS RL02 controller in the '750, but for some reason when oB :attempting to boot the '750 from RL02 (b dla0) it gives an error: :i :fc2c 06  J   Do you have the CSRs set correctly for the various Unibus devices?  (YouH   need to use the CONFIGURE command on a working OpenVMS VAX box, and toH   determine the CSR and vector settings for all Unibus devices present.)   $ RUN SYS$SYSTEM:SYSGENn SYSGEN> CONFIGUREo DEVICE> RL11 ..  E   You need to entire the type and quanitity of each device present one(   the Unibus -- do not skip any devices.  D   Do you have a bootblock on the target disk?  WRITEBOOT is requiredC   here.  (Standalone BACKUP does usually write that onto the target03   disk, so this may or may not apply in your case.)K  C   The VAX-11/750 absolutely requires the presence of a bootblock on5C   the target disk -- more recent VAX systems usually have a versioneE   of VMB present in the console, or a rather smarter console program,6F   or both.  (The VAX-11/750 console is severely dumb, even compared to)   the standards of a VAX-11/780 console.)   D   (If not, you will have to use BOOT58 and the TU58 -- the last timeF   I was working with that console was in preparation for the twentieth!   anniversary VAX presentations.)t    I :Obviously the drive and disk pack is okay, since the 4000 seems to work xG :fine with it. I've tried using two different UNIBUS RL02 controllers,  F :one of them from a PDP-11/84 that loads RSX-11 from an RL02 - so the  :controller is probably okay.a  0   Do you have the VAX-11/750 microcode update?    A   This is often loaded from the console TU58, though at least the3A   older releases of OpenVMS VAX were also capable of loading thish   microcode during startup.a   ..J :My VAXCluster (a couple of MicroVaxes and a 4000-500) is running VMS 6.1. :eJ :Does anyone have any clues to give on what I could possibly do to at get J :some form of VMS running on this machine? I realize that I can't run VMS I :6.1 on the RL02, but I was hoping to at least use it to boot the 11/750  2 :and enable it to join the cluster (via ethernet).  E   The VAX-11/750 cannot be a satellite, so you have to stuff most alltJ   of OpenVMS onto that RL02 disk -- the last time I tried anything similarK   was back around V3.4, and it was a rather tight fit even back then.  (AndnL   I had to leave various chunks off the "system" disk -- I did manage to getI   the core of OpenVMS VAX and enough of DECnet to operate onto the disk. lK   This particular work cited predated clustering and its files, obviously.)'  I   What you want is to find a bigger disk, and load OpenVMS VAX onto that.l  F   I will assume you are aware this is the second slowest VAX platform.    N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faqnN  --------------------------- pure personal opinion ---------------------------E         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.coml   ------------------------------  % Date: Mon, 08 Dec 2003 10:53:13 +0000 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>lF Subject: Re: VMS clusters prove they are the best - Sun comes in last!0 Message-ID: <br1l6q$k0m$1@new-usenet.uk.sun.com>   Bob Ceculski wrote:T > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<bqkvef$aie$1@new-usenet.uk.sun.com>...  >  >  > < > I am smarter than you Andrew in that I run my platforms on2 > OpenVMS and you don't ... CERT COUNTS DON'T LIE!  7 CERT counts do lie, you know this and just to reinforce : the point engineers from Compaq have admitted that OpenVMS3 CERT advisories have not in the past been accurate.e  9 There is also uncontovertable proof that they still arn't 	 accurate.s  9 If smart is clinging to a statistical measure of security 9 which has been demonstrated to be total tosh then you aree6 one very very smart cookie, I congratulate you on your
 smartness.   Regards  Andrew Harrisont   ------------------------------  % Date: Mon, 08 Dec 2003 11:52:39 +0000 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>vF Subject: Re: VMS clusters prove they are the best - Sun comes in last!0 Message-ID: <br1om7$l7t$1@new-usenet.uk.sun.com>   Bob Ceculski wrote:S > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<bqkvef$aie$1@new-usenet.uk.sun.com>...H >   E > I must be better at a lot more than you ... I will keep counting my-H > bonus money for this year while you continue to look for a new job! :)  . This has to be one of your best posts yet Bob.  : My email address is still Andrew.Harrison@sun.com and like7 most employers Sun doesn't generally allow ex employeese use of their internal systems.  6 I thought you were trying to configure OpenVMS to work6 as a Firewall (without a Firewall package) perhaps you6 would be more gainfully employed doing that than being a source of amusement.  5 Hadn't you worked it out yet, everytime you loose offl5 one of your Slowaris SPARC sucks Alpha sings missives.. I prove you wrong (again) and anyone out there7 suffering under the missaprehension that Compaq/Digitaly4 did in fact build fast systems gets to see that they may have been misslead.v  6 Every time you post one of your just look at the CERTS7 for Linux etc arn't they terrible compared with OpenVMSw2 and I prove that OpenVMS security violations don't3 get CERTED another little brick in the OpenVMS wallH	 crumbles.d  : You can't even accuse me of wanting to FUD OpenVMS because< I am only responding to factually incorrect FUD on your part and correcting it.   Regardsg Andrew Harrisonc   ------------------------------   Date: 8 Dec 2003 08:25:51 -0800v( From: bob@instantwhip.com (Bob Ceculski)F Subject: Re: VMS clusters prove they are the best - Sun comes in last!= Message-ID: <d7791aa1.0312080825.58598c88@posting.google.com>    Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<br1l6q$k0m$1@new-usenet.uk.sun.com>...  > Bob Ceculski wrote:l > > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<bqkvef$aie$1@new-usenet.uk.sun.com>...i > >  > >  > > > > > I am smarter than you Andrew in that I run my platforms on4 > > OpenVMS and you don't ... CERT COUNTS DON'T LIE! > 9 > CERT counts do lie, you know this and just to reinforcey< > the point engineers from Compaq have admitted that OpenVMS5 > CERT advisories have not in the past been accurate._ > ; > There is also uncontovertable proof that they still arn't  > accurate.M > ; > If smart is clinging to a statistical measure of security ; > which has been demonstrated to be total tosh then you are 8 > one very very smart cookie, I congratulate you on your > smartness. > 	 > Regardso > Andrew HarrisonY  < in the real world, I have demonstrated VMS security as being< valid for over 18 years now ... not one security problem and not one OS crash ... EVER!   ------------------------------  # Date: Mon, 08 Dec 2003 13:43:53 GMTc# From: "John N." <JNixon@cfl.rr.com>s Subject: XFC cache< Message-ID: <te%Ab.31539$b01.689566@twister.tampabay.rr.com>  H When we upgraded our Alpha cluster nodes to VMS 7.3-1, we still had someI VAXen in the cluster at VMS 7.2-1.  We experienced data corruption due totJ the mismatch of XFC and VIOC and were advised to select VIOC on all nodes.  K We have since removed all the VAXen and have only AlphaVMS 7.3-1 nodes left H and wish to reinstate XFC.  Are there any necessary ECOs we need to make$ sure are appliled to make this safe?   ------------------------------  # Date: Mon, 08 Dec 2003 14:48:02 GMTr# From: "John N." <JNixon@cfl.rr.com>e Subject: Re: XFC cache< Message-ID: <Ca0Bb.31550$b01.705203@twister.tampabay.rr.com>  / Actually, the VAXen were at VMS 7.2, not 7.2-1.h  . "John N." <JNixon@cfl.rr.com> wrote in message6 news:te%Ab.31539$b01.689566@twister.tampabay.rr.com...J > When we upgraded our Alpha cluster nodes to VMS 7.3-1, we still had someK > VAXen in the cluster at VMS 7.2-1.  We experienced data corruption due tobL > the mismatch of XFC and VIOC and were advised to select VIOC on all nodes. >uH > We have since removed all the VAXen and have only AlphaVMS 7.3-1 nodes leftJ > and wish to reinstate XFC.  Are there any necessary ECOs we need to make& > sure are appliled to make this safe? >n >h >C   ------------------------------  # Date: Mon, 08 Dec 2003 15:04:00 GMT - From: Mike Rechtman <michael.rechtman@hp.com>  Subject: Re: XFC cache& Message-ID: <3FD4AEFE.585B7DDD@hp.com>   John N. wrote: > J > When we upgraded our Alpha cluster nodes to VMS 7.3-1, we still had someK > VAXen in the cluster at VMS 7.2-1.  We experienced data corruption due to2L > the mismatch of XFC and VIOC and were advised to select VIOC on all nodes. > M > We have since removed all the VAXen and have only AlphaVMS 7.3-1 nodes leftmJ > and wish to reinstate XFC.  Are there any necessary ECOs we need to make& > sure are appliled to make this safe?  0 VMS731_UPDATE-V0200 supersedes VMS731_XFC-V0100. but first: VMS731_PCSI-V01007 also recommended: VMS731_SYS-V0500 and VMS731_RMS-V04004  7 Read the release notes before installing any of these!!e   Mike -- gE ---------------------------------------------------------------------sE Usual disclaimer: All opinions are mine alone, perhaps not even that.-? Mike Rechtman                            *rechtman@tzora.co.il* F Kibbutz Tzor'a.                          Voice (home): 972-2-9908337  B   "20% of a job takes 80% of the time, the rest takes another 80%"E ---------------------------------------------------------------------i -----BEGIN GEEK CODE BLOCK-----  Version: 3.1: GCM/CS d(-)pu s:+>:- a++ C++ U-- L-- W++ N++ K? w--- V+++$6 PS+ PE-- t 5? X- tv-- b+ DI+ D-- G e++ h--- r+++ y+++@ ------END GEEK CODE BLOCK------l   ------------------------------  % Date: Mon, 08 Dec 2003 11:44:48 -0500 5 From: David Beatty <David.Beatty@qwertysasasdfgh.com>s Subject: Re: XFC cache2 Message-ID: <OqrUP1sROvN2crTa01oyA4Q8zFo7@4ax.com>  F On Mon, 08 Dec 2003 13:43:53 GMT, "John N." <JNixon@cfl.rr.com> wrote:  I >When we upgraded our Alpha cluster nodes to VMS 7.3-1, we still had someKJ >VAXen in the cluster at VMS 7.2-1.  We experienced data corruption due toK >the mismatch of XFC and VIOC and were advised to select VIOC on all nodes.p >)L >We have since removed all the VAXen and have only AlphaVMS 7.3-1 nodes leftI >and wish to reinstate XFC.  Are there any necessary ECOs we need to make % >sure are appliled to make this safe?  >t  = If you've installed VMS731_UPDATE-V0100, you've installed thee2 patch that contains a fix to XFC for this release.   David R. BeattyW   ------------------------------   End of INFO-VAX 2003.679 ************************te: Mon, 08 Dec 2003 13:15:21 GMT10 From: "Guy Peleg" <guy.peleg@hp.com_remove_this> Subject: Re: SEARCH enhancement 3 Message-ID: <JP_Ab.10293$db4.9888@news.cpqcorp.net>t  1 I did not specify the architecture on purpose ;-)5  / I see the hidden question.....it will be on VAX    Guyo    , <VAXman- @SendSpamHere.ORG> wrote in message* news:00A2A0EA.AE56FC18@SendSpamHere.ORG...A > In article <3u_Ab.10290$xp4.3439@news.cpqcorp.net>, "Guy Peleg"i& <guy.peleg@hp.com_remoԛQ:~t{UQNŹ5ǖǂ7UR:_YZJ!͒ lP<7WjF@G@xfotF^K\ju2%_8	w`ߋ7Y10k[',KWM)A7HV<i
[8)=%k
aʁ5kK8O5bbmon:Э/؜-\t
?a`/ɯWANdZ1av9=s'h"N=_G8)ǇhOYYԪN>
m
|0]K*bN5@ozv9\Wݿ|fjsͶIsZuQbIsm{<pst(yQaVS	ip<lG?f>]x=
]ApoB];rhs0NfmN$AWy	;B
6_LB:qa7}XiBlNIƎ]YpkR]]NC;AW#:P<f6'㚁EKL'0$Q2Pr^ų[92crR[;8ư/eW9DxEM
x\N\*n#5/2J|gO=I_w@OWĲܛOy[|OVp*IEyFw:F]p~ۻm2mK"[߈l[!TbZ9eNp
`ry3 CGsOAsEp1Dq%Ly\3
^C_A"r3:Ul14NE, wX ~,02<罎5Ka=Y-֫%H0\\Ht?ezA%OO|$-)QR-J<މw3i\s
"H^
٣oE5}LP/Zb