0 INFO-VAX	Mon, 29 Jan 2001	Volume 2001 : Issue 57      Contents: Re: ACP-QIO and VBN  CSWS Authentication  Re: Himalaya / Alpha / VMS Re: Himalaya / Alpha / VMS Re: Himalaya / Alpha / VMS Re: Himalaya / Alpha / VMS Re: Himalaya / Alpha / VMS Re: Himalaya / Alpha / VMS/ Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours / Re: It's the end for VMS and other Wild Rumours $ Re: It's the end for VMS get off now$ Re: It's the end for VMS get off now LN03 system password Re: LN03 system password. RE: Midrange I/O with VMS WAS: DS20 - Slow I/O* Re: Quick (stupid) question on DECnet Plus Re: samba 2.0.6  Re: samba 2.0.6 / Re: Share Your Feelings About "The end for VMS" # Re: VaxStation 4000/90A Question(s)  VMS actually mentioned but... ! Re: VMS actually mentioned but... 7 Re: VMS vs UNIX (was: Linux worm and RedHat 7.0 broken) 7 Re: VMS vs UNIX (was: Linux worm and RedHat 7.0 broken) 4 Re: Volume Shadowing vs. RA7000 (WAS: DS20 Slow I/O)4 Re: Volume Shadowing vs. RA7000 (WAS: DS20 Slow I/O)4 Re: Volume Shadowing vs. RA7000 (WAS: DS20 Slow I/O)' RE: Writes flushed to Disk on Dismount?   F ----------------------------------------------------------------------  # Date: Sun, 28 Jan 2001 19:28:58 GMT ' From: moi_is_me <moi_is_me@my-deja.com>  Subject: Re: ACP-QIO and VBN) Message-ID: <951rti$68d$1@nnrp1.deja.com>   
 Thanks ...  8 When you perform an extend, ACP-QIO returns the starting; virtual block number of the blocks allocated in FIB$L_EXVBN   ; Presumably FIB$L_EXVBN will ALWAYS, ALWAYS be one more than < the total of all blocks that had previously been allocated ? (for a succesful extend)  ? Also ... the code I am writing/changing will ONLY be performing < 512 block writes. In limited testing, I have been performing< 10000 * 512 writes using synchronous versions of ACP-QIO and: and $PUT. $PUT is nearly twice as fast on my DS-10 ... any* ideas as to what I am likely doing wrong ?  < BTW - The initial allocation for the ACP-QIO is 4096 blocks, and 100 blocks for RMS   thanks inadvance   -Pierre   > ==============================================================  > In article <MPG.14dc5404a84a3e679896bf@news.bellatlantic.net>,3   John Santos <john.santos@post.harvard.edu> wrote: A > In article <94t8g4$s4k$1@nnrp1.deja.com>, moi_is_me@my-deja.com  says...  > > Hi,  > > 3 > >   Std Disclaimer ... please excuse my ignorance  > >  > > F > >   I have been examing some code that uses ACP-QIO to create/extend > >   and write to disc. > >  > > A > >   However, there seems to be case where the code may write to ; > >   a VBN outside of what has been allocated by the code.  > > E > >   For example, if it has successfully allocated 4096 blocks,  and 8 > >   then, in it's infinite wisdom, decides to write toC > >   VBN 5050 ... will the disc driver reject the request, or will F > >   it silently accept it, with the possible consequence of trashing > >   some other file ?  > ' > No, of course not!  This is VMS.  ;-)  > F > However, one thing to watch out for.  If you ask for 4096 blocks, itD > will allocate to the next multiple of the disk clustersize, so youF > may really get, e.g. 4100 blocks if the clustersize is 5.  You wouldB > then be able to write in blocks 4097, 4098, 4099 and 4100.  4100F > and beyond will give an error.  The ACP returns the number of blocksE > actually allocated.  It is important to remember this number if you F > need to do more extends, since the starting block number is input to > the extend service, IIRC.  >  > > TIA  > > 
 > > Pierre >  > --
 > John Santos  >      Sent via Deja.com  http://www.deja.com/   ------------------------------  % Date: Mon, 29 Jan 2001 16:42:08 +1030 : From: "Barratt, Chris (FMC)" <Chris.Barratt@fmc.sa.gov.au> Subject: CSWS AuthenticationN Message-ID: <07103702F27FD411ACA30000F808545257C37B@sagemshs001.fmc.sa.gov.au>  J The VMS user authentication added in the last release of CSWS works nicelyK and I have managed to use a GROUP file to specify groups of users for Alias  acls.    F I was wondering if there is currently (or planned for future) a way toJ specify an identifier from SYSUAF to be used as the group authenticator onK acls ?   (eg. grant an identifier to a vms user which would then be used to # allow access to a web resource).       G This would work much nicer than setting up files containing user lists.     Cheers, 
 Chris Barratt  FMC          ------------------------------  % Date: Sun, 28 Jan 2001 22:30:00 +0000 ) From: Christof Brass <brass@infopuls.com> # Subject: Re: Himalaya / Alpha / VMS , Message-ID: <3A749D68.6834B10F@infopuls.com>    richard_maher@my-deja.com wrote: >  > Hi,  > I > One thing that you might be interested in is that Himalaya can talk TIP D > (Transaction Internet Protocol) and can therefore participate in aG > distributed 2PC with a W2K SQLServer database. Trader's system W2K to D > Exchange's Himilaya? W2K Teller machine to Bank's Himalaya server? > 4 > Why was it again that Compaq's customers need VMS? > I > (And more importantly, why are we being denied TIP functionality on VMS I > by Messrs Incompetent and Ineffectual? If it's good enough for Compaq's . > flagship system then why can't VMS have it?) >  > Regards Richard Maher  > C > PS. If you people cared/complained more about issues of substance G > rather than sound bites and nuances then VMS would be in a lot better  > shape. >  > Sent via Deja.com  > http://www.deja.com/  , Did you escpecially address me with the PS??  > I'm not familiar enough with DECnet but I remember that it was= clean designed whereas TCP/IP was not and DECnet offered some ? transaction oriented features. The SWX Swiss Stock Exchange and ? all derived bourse transaction systems use only DECnet which is ? extended over LAN/MAN/WAN to the member banks. IIRC these banks = can then decide to use DECnet or to use some DECnet to TCP/IP ; converter. It could be that for the niche market TIP is not ? needed. But I agree that it would be an advantage to have it if < interconnection on that level is a need. Depends also on the> effort needed to add it to VMS. I'm admittedly extreme in that< I'm not a fan of TCP/IP and I'm thinking of changing back to@ DECnet, at least for my local communication needs. But this is a different topic.  ? To summerise what I got from the valuable input to this thread: @ it still seems that NSK will be migrated to Alpha (or is already8 running on Alpha). As long as Compaq pushes Himalaya and@ continues to use NSK on Alpha there is no problem for the future	 of Alpha.    ------------------------------  % Date: Sun, 28 Jan 2001 22:41:25 +0000 % From: Alan Greig <a.greig@virgin.net> # Subject: Re: Himalaya / Alpha / VMS ) Message-ID: <3A74A015.9800B4A@virgin.net>    Christof Brass wrote:c.    > A > To summerise what I got from the valuable input to this thread: B > it still seems that NSK will be migrated to Alpha (or is already: > running on Alpha). As long as Compaq pushes Himalaya andB > continues to use NSK on Alpha there is no problem for the future > of Alpha.   J Winkler said in his speech that the Himalaya group had been transferred toJ the Industry Standard Server Group and Tandem/Himalaya technology would beJ implemented on that platform. First I'd heard of this.  Whether this is in5 addition to or instead of Alpha he didn't make clear.    --
 Alan Greig   ------------------------------  % Date: Sun, 28 Jan 2001 23:43:52 +0000 ) From: Christof Brass <brass@infopuls.com> # Subject: Re: Himalaya / Alpha / VMS , Message-ID: <3A74AEB8.2263BD5F@infopuls.com>   Alan Greig wrote:  >  > Christof Brass wrote:c.  >  > > C > > To summerise what I got from the valuable input to this thread: D > > it still seems that NSK will be migrated to Alpha (or is already< > > running on Alpha). As long as Compaq pushes Himalaya andD > > continues to use NSK on Alpha there is no problem for the future
 > > of Alpha.  > L > Winkler said in his speech that the Himalaya group had been transferred toL > the Industry Standard Server Group and Tandem/Himalaya technology would beL > implemented on that platform. First I'd heard of this.  Whether this is in7 > addition to or instead of Alpha he didn't make clear.  >  > -- > Alan Greig  ? I read this in your post to another thread only after I posted.   : If NSK on Alpha is dead as it looks like Compaq made a big< mistake in the past by throwing in money to equip Alpha with8 lock-step and to start porting NSK to Alpha which Compaq> probably did already. I regard this as financial losses. There= is no clear strategy behind that or they changed the strategy ? already again and if this happens twice within a few years than < I wouldn't call it strategy. How is this lock-step mechanism< emulated with Intel architecture CPUs anyway? If this can be; done easily throwing in money for equipping Alpha with this # technique is another dumb decision. ? Although I hate wrong thead names I want to add one thought: if 6 Compaq helps Micro$oft by transferring knowledge in SW: development and OS architecture/features from their OSs to> W2k-problem-OS it sooner or later sacrifies its assets because@ it looses its differentiating factor, its uniqueness of features> offered by Compaq because Micro$oft will never let Compaq draw> any advantage out of that as the Micro$oft OSs are aimed to be8 multi-vendor HW independent (only dependent on the Intel? architecture specifications). I'm really interested what Compaq : gets out of that knowledge transfer deal other than money.; Strategically I don't see any wins in that move, but severe  losses.   > One last thought about (missing) strategy. I think that Ekhard@ Pfeiffer had the vision of competing with HP and SUN (IBM is out= of reach as I pointed out in another thread). Pfeiffer bought ? Digital and IIRC Tandem. They threw Pfeiffer out because of one > bad quarter after he made Compaq to a 100 times bigger company@ within about 10 years (the numbers are guesses but should not be@ completely wrong). I'm sure this was a big mistake. Most members; of the board didn't like Pfeiffer because he was German and @ because they didn't like the enterprise business vision which in@ fact is the only chance to stabilise your business and to have a? chance of substantial growth. The PC market is volatile and low @ margin. It really makes sense to harvest your development effort< in the high end market and use the technique in lower priced> market segements after a certain delay. This is done by almost= all companies in other areas like the car industry or by pure = software companies where the features of the flagship product 6 appear in later versions of the lower priced products.? Now I come to the point: buying Digital and Tandem doesn't make = sense if they aren't integrated into the whole company to win ? from the synergy effect, besides from the service business. But > you don't improve ROI if you don't properly integrate and only= continue to run these bought companies as before. Bying makes ; sense to cumulate/acquire knowlegde/technique and to reduce ; costs by using the same number of people and the facilities = alread there to process a bigger number of requests. Buying a : company, getting the special technique and licencing it to< another company doesn't make much sense to me although it is= done sometimes as a side effect or for strategic reasons. The ? whole story reminds me to the AT&T UNIX group and Novell. Where  is Unixware today?  @ Could someone explain what Compaq really plans to be a sucessful1 company on the long term or even on the mid term?    ------------------------------  % Date: Sun, 28 Jan 2001 19:09:14 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> # Subject: Re: Himalaya / Alpha / VMS , Message-ID: <3A74B499.EE8AE5F2@videotron.ca>  N > > Winkler said in his speech that the Himalaya group had been transferred toN > > the Industry Standard Server Group and Tandem/Himalaya technology would beN > > implemented on that platform. First I'd heard of this.  Whether this is in9 > > addition to or instead of Alpha he didn't make clear.     T Lets speculate for a minute (well we have been doing this for over 10 years now..,):  N Compaq intends to keep Tandem's assets, but wants to get rid of that pesky VMSN and true64 which really irrirate Bill Gates. It will be a long while before NTI can rival NSK so Compaq is probably safe with it, besides it doesn't need ; marketing because its niches are identified and rock solid.   I So, what is the best way to acheive this ? Isolate VMS, Unix and Alpha in L their own corner, and move Tandem over the the real enterprise division (theL wintel stuff). Since VMS and True64 share compilers etc, it is a natural fit to put them together.   K Of course, before you throw away the bath water, you keep the baby and give  all the goodies to Microsoft.   N The big question is how Compaq intends to flush True64 and VMS. Will they spinJ it off into a separate compny and then sell it, or perhaps spon it off andL give it to the current shareholders of Compaq, or just wind those operations down ?  K From a microsoft/intel point of view, I am sure that they would prefer that M Compaq wind VMS down since it will eliminate a potential competitor that just 
 won't die.   ------------------------------  % Date: Sun, 28 Jan 2001 17:15:05 -0700 % From: Dean Woodward <deanw@rdrop.com> # Subject: Re: Himalaya / Alpha / VMS ) Message-ID: <3A74B609.6FFC59B8@rdrop.com>    Christof Brass wrote:  > A > Now I come to the point: buying Digital and Tandem doesn't make ? > sense if they aren't integrated into the whole company to win = > from the synergy effect, besides from the service business.   H As pointed out, these acquisitions were made under different management,@ with a different plan which was a fairly bold vision coming from Compaq's roots.   E I find myself in a similar situation where I work- the organization I E work for was acquired by a management team with a sweeping vision.  A H couple bad quarters and stockholders used the excuse to oust one CEO and= replace him with another who had a vision that was more "core ? business".  Now we're languishing with minimal support, lack of 9 investment by management, etc.  (Sound familiar, anyone?)   A If raising and selling chickens is what you know, then buying the F neighbor's herd of cattle is probably a bad idea unless you're willingF to expand your horizons.  Compaq's core business is selling Wintel....   ------------------------------    Date: 29 Jan 2001 00:10:54 -0500* From: young_r@eisner.decus.org (Rob Young)# Subject: Re: Himalaya / Alpha / VMS + Message-ID: <YNe$LBr22lzY@eisner.decus.org>   \ In article <878znvptxc.fsf@prep.synonet.com>, Paul Repacholi <prep@prep.synonet.com> writes:. > young_r@eisner.decus.org (Rob Young) writes: > 6 >> 	Himalya uses MIPS.  Lock-step was added to EV7 and >> 	will be used by NSK.0 > Do you have a pointer or ref for the EV7 part? >  > = > Rember MIRA? and the failover Vaxen? A cluster it was found = > did most everything that they aimed at. There are spots in  ? > RT, and also things like POS networks where visible fail-over  > is not good enough.  >   8 	But the EV7 part is a nice evolution in processors that< 	puts Compaq a few years ahead of Intel in the 64-bit space.   	This is a decent overview:   8 http://www.alphapowered.com/presentations/alpha21364.ppt  G 	(Apologize if you don't have powerpoint.  Some of these Windoze things ? 	have ppt "viewers".  I picked my virus up from somewhere to do / 	that, the product I have is called QuickView).    	A quip by Terry:   3 http://www5.compaq.com/alphaserver/vax/vax_now.html   P "Compaqs commitment to Alpha is underscored by the firms decision to base future3 Himalaya NonStop systems on Alpha EV7 processors. "   ? 	There are many more out there.  Alpha isn't going away no moree; 	than PA-RISC is going away.  Going to EPIC would be a stepA? 	backwards for anyone on Alpha(1), that is why it wasn't really/= 	a hard battle (I suppose) to convince the Tandem folks to goe 	Alpha.a   				RobV    C (1)  For at least 4-5 years.  Paul DeMone's excellent series on EV8u@ 	aka "Arana"  "Ah-RON-yah" (should be a n-yeah, not n) is a must% 	read if interested in Alpha futures:   ? http://www.realworldtech.com/page.cfm?ArticleID=RWT121300000000d? http://www.realworldtech.com/page.cfm?ArticleID=RWT122600000000h? http://www.realworldtech.com/page.cfm?ArticleID=RWT011601000000    ------------------------------  % Date: Sun, 28 Jan 2001 15:02:54 -0500S- From: JF Mezei <jfmezei.spamnot@videotron.ca>V8 Subject: Re: It's the end for VMS and other Wild Rumours, Message-ID: <3A747AEC.21DF6181@videotron.ca>   Jordan Henderson wrote: I > As you mention below, Windows is a big growth market.  If MS is helping3F > you to market your biggest growth market, you'd be crazy not to playF > along.  That doesn't mean that your other products will be neglected) > in development and targetted marketing.F  M Yes it means exactly that. The ALL-IN-1 group had begun to port the server tolN NT and Unix when Palmer got the brilliant idea of licking Bill Gates' privatesL and start to sell/push Microsoft products, including Exchange. Not only sell6 it, but istall it on every Digital employee's desktop.  N It took Digital a few weeks to find out what the ALL-IN-1 group was doing, andJ as soon as it was found, the roject to build to move A1 to NT and UNIX wasO killed because it would have created a competing product with Microsoft's gear.   L Alpha based servers were purpusefully priced higher than 8086s to ensure theG health of intel based servers. VMS was restricted to a few narrower and K narrower market niches. The last Inform sent to me talks only about defenset+ and VMS. So it seems we're down to one now.I  N Capellas made it Compaq's product lineup very clear. And VMS has no room in it; because the NT-Unix-Himalaya products fill the whole range.a  K > Capellas does things for strategic reasons.  There may be joint marketingoJ > with Compaq partners at work here (hint: M$), but that doesn't mean that > VMS is dead.  J But if for strategic reasons, you cannot repair the problems of VMS due toL your relationship with Intel and Microsoft, then VMS is as good as a sinkingN ship. It may still be afloat, but it is taking on water and the more you wait,9 the harder it will be to shore it up if you ever want to.=  M And at one point, sinking will be inevitable. Many have been given high hopeseM that Compaq would come to the rescue and not only plug the hole, but pump thetI water out and refurbish VMS. But as of last week, Compaq won't even admitiB being aware that it has such a ship, even less that it is sinking.  I > As Terry pointed out, CPQ would be crazy not to support a business thatd( > is so profitable and actually growing.  F But as a JP Morgan analyst asked (with no response from Compaq on thatM specific question), he was wondering whether Compaq's enterprise revenus camei3 from new sales or from milking existing customers.    N After the titanic started to take on water, the generators were still working,H they were still serving drinks and playing music until the ship could noI longer support those activities. Of course Compaq will continue to accepto6 money from VMS customers until the last ones are gone.  I You can beleive that the VMS ship is unsinkable. But once you have enoughtH holes in it, any ship will sink. VMS has been taking on water for over aJ decade. Compaq may have temporarily closed some of the holes recently, but- last week, they just made a huge hole in VMS.e  H Because Compaq sends mixed messages about VMS, customers do not have anyH confidence in what compaq says. And because of that, they have no way foK knowing what Compaq's true intentions were for VMS. And when a company doeseJ not advertise or mention one of its products in a contects where its otherJ products are mentioned, it is generally because it does not intend to keep that product very long.1  G > Gartner never has anything good to say about VMS?  Well, Gartner just G > issued a really good report on VMS, but now, there's something new to5* > cry about, so you focus on that instead.  L "Just" ? No. Read the date on that report.  It may have been released to theL public recently, it it was published last year. (June if I recall). This wasN at a time when Compaq started seding balls and posters to customers to signifyF a renaissance.  But now, Compaq is back it its old self again, totally
 ignoring VMS.n        C > true that VMS is still viable?"  Then does a quick Net search for H > information and finds comp.os.vms where long-time VMS USERS are sayingF > "oh, dear, oh my, VMS will be dead in weeks, it's all over now, blah? > blah blah".  What effect does THAT have on the future of VMS?0  N If you were a company selling a product, and you found out that your customersN were saying such thigs about your product, wouldn't you take very active stepsM to dispell once and for all these rumours and take the actions your customersaJ have told you are necessary for them to have confidence in your promises ?  L It would not have cost Compaq ANYTHING to have Capellas mention VMS wins andN its renaissance during his interview on CNN following his press conference. 10L seconds of free advertising that would have given VMS the boost it needed to< give back confidence to customers that Compaq does want VMS.  N NO ! Capellas ignored VMS at a time where customers were looking at him to seeK if he the promises of a renaissance coming from his underlings were reallyt  going to happen or not.a   ------------------------------  % Date: Sun, 28 Jan 2001 15:31:45 -0500 ' From: "Bill Todd" <billtodd@foo.mv.com>p8 Subject: Re: It's the end for VMS and other Wild Rumours( Message-ID: <951vbk$o5i$1@pyrite.mv.net>  8 JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message& news:3A747AEC.21DF6181@videotron.ca...   ...n  F > If you were a company selling a product, and you found out that your	 customersnJ > were saying such thigs about your product, wouldn't you take very active steps E > to dispell once and for all these rumours and take the actions youru	 customersrL > have told you are necessary for them to have confidence in your promises ? >TJ > It would not have cost Compaq ANYTHING to have Capellas mention VMS wins andeA > its renaissance during his interview on CNN following his presse conference. 10K > seconds of free advertising that would have given VMS the boost it neededg to> > give back confidence to customers that Compaq does want VMS.  K The first paragraph above is more to the point:  it's *actions* that reallylI count.  Statements, if they can be considered 'actions' at all, come in a J very distant second.  If Capellas *had* said something positive about VMS,I then at least that would have provided an opening to ask him exactly what D Compaq intended to *do* to support VMS - and then if Compaq followedL through, *that* (actions, not words) could help restore customer confidence.   - bill   >DL > NO ! Capellas ignored VMS at a time where customers were looking at him to seewE > if he the promises of a renaissance coming from his underlings werea reallytl > going to happen or not.s   ------------------------------  % Date: Mon, 29 Jan 2001 00:14:12 +0000t% From: Alan Greig <a.greig@virgin.net>r8 Subject: Re: It's the end for VMS and other Wild Rumours* Message-ID: <3A74B5D3.4C4F4DF8@virgin.net>   Bill Todd wrote:  G > Capellas apparently did mention VMS, by implication:  didn't he staten= > explicitly that anything he hadn't mentioned was dead meat?  >   O I missed the last minute or so of his second speech first time round because of-L connection problems. I think he had heard our questions because right at theM very end he gave it a very brief mention. Sod's law got in the way first timeDL round. But it doesn't really change my view. He did not give a very positiveO feeling for its future saying "there are reasons to be cautious". But that also 8 seemed to be leaving the door just that little bit ajar.   > M > You're welcome to your opinion, and free to spread it.  But don't castigate M > those whose opinions differ:  they're not part of the problem, they're parta2 > of the solution - whatever that solution may be. >g > - bill >  > >f > > -Jordan Hendersony > > jordan@greenapple.comT > >/   --
 Alan Greig   ------------------------------  # Date: Mon, 29 Jan 2001 01:46:56 GMTt+ From: "Nikita V. Belenki" <public@kits.net>l8 Subject: Re: It's the end for VMS and other Wild Rumours< Message-ID: <kY3d6.11325$1%2.519134@sjc-read.news.verio.net>  < "Jordan Henderson" <jordan@lisa.gemair.com> wrote in message$ news:951bs4$hq7$1@lisa.gemair.com...  I > As you mention below, Windows is a big growth market.  If MS is helpingqF > you to market your biggest growth market, you'd be crazy not to play > along.  J Misrosoft never helps you. You are helping Microsoft. Remember DEC's fate?   Kit.   ------------------------------    Date: 28 Jan 2001 21:07:08 -0500/ From: jordan@lisa.gemair.com (Jordan Henderson)u8 Subject: Re: It's the end for VMS and other Wild Rumours* Message-ID: <952j8c$p1c$1@lisa.gemair.com>  ' In article <951kf5$75f$1@joe.rice.edu>,t* Jerry Leslie <leslie@clio.rice.edu> wrote:1 >Jordan Henderson (jordan@lisa.gemair.com) wrote:l >:J >: As you mention below, Windows is a big growth market.  If MS is helpingH >: you to market your biggest growth market, you'd be crazy not to play G >: along.  That doesn't mean that your other products will be neglected * >: in development and targetted marketing. >tF >Other companies have "buried their gold" out of fear from retribution >from M$; e.g. H-P's OpenMAIL :I >lI >  http://www.infoworld.com/articles/op/xml/00/01/17/000117oppetreley.xmltK >  And now announcing the General Protection Fault award "winners" for 1999  > J >  "OpenMail is not only a drop-in replacement for Microsoft Exchange, it M >   is faster, more scalable, more stable, less expensive, and performs some dL >   tasks more intelligently than Exchange. But HP won't market OpenMail as K >   an Exchange replacement. HP is petrified of what Microsoft might do in r >   retaliation."o >q  = This is a good point, but Compaq and the rest of the industrys- are hedging their bets with Linux these days.g  9 I don't deny the very good point that others make that MSd9 makes a treacherous friend.  Helping MS in the commodity h: markets helps the best of your competition as much or more than it helps you.   >:H >: Get over it.  Even if VMS was dying, all this extended negativity andI >: whining doesn't help matters in the least.  How do you think this veryeB >: public forum looks to the mostly VMS-ignorant public out there? >:I >: Say some CIO reads the positive Gartner press and says to himself "I'm J >: sick of all these Wintel and UNIX over-promises.  I wonder, could it beE >: true that VMS is still viable?"  Then does a quick Net search for sI >: information and finds comp.os.vms where long-time VMS USERS are saying G >: "oh, dear, oh my, VMS will be dead in weeks, it's all over now, blaha@ >: blah blah".  What effect does THAT have on the future of VMS? >sF >You have more faith in the technical ability of CIOs than I do, basedG >on limited exposure.  Even most IT staffs don't use USENET newsgroups,c/ >not realizing the technical help they can get.  >o  D A lot of CIOs know about the existence of USENET newsgroups.  If youG wanted to get some sort of real-time picture of industry opinion, you'dsD go to the Internet, and you wouldn't find much in the way of OpenVMS9 discussion on the Web, so you might seek out comp.os.vms.c  D In any case, certainly there are people who CIOs listen to who mightE read what's said here and report it with a spin that could only hurt. A I can hear it now, "OpenVMS?  HA!  Boss, you should see what the mC customer base is saying on comp.os.vms!  They all say it's dead and + that Compaq is telling them so in private!"z  D >If anyone is convinced that shareholders' best interests are being @ >neglected because of M$, the place to post such opinions, WITH C >SUPPORTING EVIDENCE, is in forums that market analysts follow, andhH >not in a technical newsgroup, such as comp.os.vms or comp.sys.hp.hpux. ? >Some investor-oriented web sites have discussion forums; e.g.:e >h' >   http://www.redherring.com/investor/l > 5 >--Jerry Leslie     (my opinions are strictly my own)    -Jordan Hendersoni jordan@greenapple.comr   ------------------------------    Date: 28 Jan 2001 21:30:59 -0500/ From: jordan@lisa.gemair.com (Jordan Henderson)r8 Subject: Re: It's the end for VMS and other Wild Rumours* Message-ID: <952kl3$qaa$1@lisa.gemair.com>  O In article <951pbp$jo8$1@pyrite.mv.net>, Bill Todd <billtodd@foo.mv.com> wrote:l > ; >Jordan Henderson <jordan@lisa.gemair.com> wrote in messagen% >news:951bs4$hq7$1@lisa.gemair.com... / >> In article <3A73EA45.1F2052AF@videotron.ca>, 2 >> JF Mezei  <jfmezei.spamnot@videotron.ca> wrote: >> >Terry C Shannon wrote:J >> >> omission (no references to VMS) than a death warrant. Windoze is not >ready& >> >> for prime time in the VMS space, >> >I >> >What is the VMS space ? Compaq's web cast filled the "space" with its  >otherL >> >OSes leaving no room for VMS. And as far as NT not ready for prime time, >thati' >> >is not the message given by Compaq.a >> > >>J >> As you mention below, Windows is a big growth market.  If MS is helpingG >> you to market your biggest growth market, you'd be crazy not to playiG >> along.  That doesn't mean that your other products will be neglected-* >> in development and targetted marketing. > G >It *needn't* mean that your other products will be neglected.  But thelJ >evidence is overwhelming that in the case of VMS that's *exactly* what it= >means, and I wouldn't be too comfortable about Tru64 either.d >n >> >> >J >> >> business is actually growing again, the revenue is substantial--much >morey >> >> than Himalaya NSK--e >> >M >> >Bot according to the numbers published. I beleive NSK made over a billiongK >> >while VMS just under a billion. (although you'd have to verify this). Ip >canI >> >beleive VMS has improved. But if it did turn around, you'd think thato	 >Capellasf$ >> >would have proudly mentioned it. >> > >>L >> Capellas does things for strategic reasons.  There may be joint marketingK >> with Compaq partners at work here (hint: M$), but that doesn't mean that  >> VMS is dead.e > J >Of course not:  it's Compaq's lack of support for *any* action that wouldF >help VMS compete outside its existing customer base that means VMS is1 >comatose ('dead' it is not, but neither is RSX).  >p >> >> >F >> >> make no sense for CPQ to mess with this formula, especially with
 >declining! >> >> growth in the Wintel space.- >> >I >> >Wintel base enterprise servers grew by 24%, and the business criticalo >grew 6 >> >only by 17%. (this includes unix, tandem and vms). >> >K >> >Whether Capellas presented the whole facts or not, what is important is  >the; >> >image he projected, And in that image, VMS has no room.c >>J >> As Terry pointed out, CPQ would be crazy not to support a business that) >> is so profitable and actually growing.h > K >Terry's viewpoint may not be completely unbiased:  Compaq is his bread anda" >butter, whether VMS lives or not. >t  B I reference a point that Terry has made and you seem to imply thatB he's biased.  That's called an ad hominem.  Now, what's wrong with
 the argument?t  K >And VMS's growth, last I heard, was hardly impressive.  My personal beliefaH >is that it *could* be impressive if Compaq really got behind it, but itH >seems pretty clear that Compaq's leadership doesn't share that opinion:J >they seem to feel that VMS's profit potential is short-term regardless ofL >what they do with it, hence are reluctant to devote any long-term resources >to the job. >  >>J >> Look, you can read whatever you want into it, but I'm still optimistic.H >> There are some here who want to read everything in the negative.  HowF >> long has there been whining and nashing of teeth over the fact thatH >> Gartner never has anything good to say about VMS?  Well, Gartner justH >> issued a really good report on VMS, but now, there's something new to+ >> cry about, so you focus on that instead.  >tL >You can be as optimistic as you want.  Some people might prefer not to sink >with the ship.  >   F I contend that all this hand wringing and whining in a public forum is! not helping the ship stay afloat.u   >>H >> Get over it.  Even if VMS was dying, all this extended negativity andI >> whining doesn't help matters in the least.  How do you think this verylB >> public forum looks to the mostly VMS-ignorant public out there? >WH >I'd hope it makes them think long and hard before deciding to commit toK >using VMS in any long-term project.  That would be a public service, in my:	 >opinion.n >o  H _This_ is keeping the ship afloat?  Seems like you're really saying thatC now that Compaq has abandoned us, we need to pay them back in kind.g   >>I >> Say some CIO reads the positive Gartner press and says to himself "I'm'J >> sick of all these Wintel and UNIX over-promises.  I wonder, could it beD >> true that VMS is still viable?"  Then does a quick Net search forI >> information and finds comp.os.vms where long-time VMS USERS are saying G >> "oh, dear, oh my, VMS will be dead in weeks, it's all over now, blahv@ >> blah blah".  What effect does THAT have on the future of VMS? >NM >That's for Compaq to decide.  If it chooses to take the actions necessary to K >make VMS's long-term viability more believable, then it will likely find aoF >large chorus of evangelists ready to spread the word.  The sentimentsC >expressed here didn't *cause* VMS's current predicament, they're a'- >*reaction* to it - and a realistic reaction.l >r  B I believe that some of the negativity here feeds into the "current  predicament", whatever that is.    >>M >> I'm NOT saying that we should all be pollyannas here.  I really appreciate K >> David Mathogs attention to specific goals (~$2K VMS box some years back)d >andL >> clear presentation of hard performance data.  We need more of this.  MoreJ >> specifics, more specific goals and hard data and less wringing of hands >andM >> crying "Why has Capellas failed to mention us?? What have we done?? All ish >> lost!!!"a >hF >Capellas apparently did mention VMS, by implication:  didn't he state< >explicitly that anything he hadn't mentioned was dead meat? >oL >You're welcome to your opinion, and free to spread it.  But don't castigateL >those whose opinions differ:  they're not part of the problem, they're part1 >of the solution - whatever that solution may be.i >b  G I'm sorry, but I don't agree that people who make statements like (fromh <94vvl3$8ur$1@pyrite.mv.net>)h  K > If people wanted to do something that *might* be constructive, they couldnN > band together and present Capellas with a list of what actions it would takeM > to keep them from bailing out:  at least that would force Compaq to ante updL > or suffer immediate consequences, and help clear the air at the same time.L > But the time for that kind of effort to be effective may be long gone now.  H are really interested in solutions.  The paragraph does offer a definiteG suggestion for action, which I might support, but the last sentence is eH just spleen-venting fatalism that proves that it's all about bitterness  against Compaq management.  G You might believe that it's too late.  Saying it in a public forum that D might cause it to be a self fulfilling prophecy is not constructive.   >- bille >S   -Jordan HendersonB jordan@greenapple.comt   ------------------------------  % Date: Sun, 28 Jan 2001 21:58:22 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 8 Subject: Re: It's the end for VMS and other Wild Rumours, Message-ID: <3A74DC48.9A0907E8@videotron.ca>   Jordan Henderson wrote:eI > You might believe that it's too late.  Saying it in a public forum thateF > might cause it to be a self fulfilling prophecy is not constructive.  N What I see (and personally feel) happening now is that people's patiences haveL runned out and this last fiasco has shown that you can't trust Compaq to act& on their fancy promises to revive VMS.  N So we are essentially back to the days of Palmer, not being able to trust whatN the vendor is saying. And since we can all look back at the damage that PalmerT did to  VMS, we know what is coming. There isn't much left of VMS to keep it afloat.  J But the fact that some/many are crying foul over this issue is a sign thatL there is still hope that if we make enough noise, Compaq may re-evaluate itsI position once more or do the honourable thing and sell VMS to someone whosM wants to develop it in many markets and is not affraid to compete against thel propellor-heads at Redmond.a  M It is when Compaq ignores VMS and nobody notices that you should worry about.g   ------------------------------  % Date: Sun, 28 Jan 2001 22:33:16 -0500 ' From: "Bill Todd" <billtodd@foo.mv.com>n8 Subject: Re: It's the end for VMS and other Wild Rumours( Message-ID: <952o1v$9at$1@pyrite.mv.net>  : Jordan Henderson <jordan@lisa.gemair.com> wrote in message$ news:952kl3$qaa$1@lisa.gemair.com...J > In article <951pbp$jo8$1@pyrite.mv.net>, Bill Todd <billtodd@foo.mv.com> wrote:   ...   L > >> As Terry pointed out, CPQ would be crazy not to support a business that+ > >> is so profitable and actually growing.d > > I > >Terry's viewpoint may not be completely unbiased:  Compaq is his bread  andd$ > >butter, whether VMS lives or not. > >  > D > I reference a point that Terry has made and you seem to imply that, > he's biased.  That's called an ad hominem.  K Which is perfectly appropriate if you're using the source (Terry), not justa% the sentiment, to bolster your point.   K Terry recently separated himself from a VMS advocacy effort to make sure ituJ did not make him appear 'anti-MS'.  One can debate whether this separationJ was justified, and I wouldn't suggest that he's not still a friend of VMS,I but that action suggests that his friendship is limited to activities ands5 statements that don't upset other factions at Compaq.      Now, what's wrong with > the argument?d  J What' wrong is that exactly the same argument applied for the past decade:L it didn't stop DEC from neglecting and actively denigrating VMS, and for theH past two years it hasn't stopped Compaq from neglecting VMS (all they've* stopped doing is actively denigrating it).  C *Why* this is the case is debatable.  *That* it is the case is not.    ...   I > >You can be as optimistic as you want.  Some people might prefer not tor sink > >with the ship.e > >  >fH > I contend that all this hand wringing and whining in a public forum is# > not helping the ship stay afloat.m  I Which is not the point.  The only entity that can keep the ship afloat isaL Compaq.  Though it hasn't sunk yet, the ship currently has a very large holeJ in it.  You seem to be saying that we should not be telling people to keepE close to the lifeboats, because that might cause some of them to stopoK bailing.  I'm saying that if Compaq doesn't see an incipient evacuation, itCK will have no motivation to patch the hole, in which case the ship *will* gom down, regardless of what we do.    >C > >>J > >> Get over it.  Even if VMS was dying, all this extended negativity andK > >> whining doesn't help matters in the least.  How do you think this very D > >> public forum looks to the mostly VMS-ignorant public out there? > > J > >I'd hope it makes them think long and hard before deciding to commit toJ > >using VMS in any long-term project.  That would be a public service, in my > >opinion.  > >T > J > _This_ is keeping the ship afloat?  Seems like you're really saying thatE > now that Compaq has abandoned us, we need to pay them back in kind.   J No, I'm saying that keeping the ship afloat is Compaq's job, not ours.  IfF we see a commitment to do so, we'll gladly help.  If we don't see suchK commitment, we not only have no obligation to go down with the ship, but weeF *do* have an obligation to warn others that is may not be safe to come aboard.v   >o > >>K > >> Say some CIO reads the positive Gartner press and says to himself "I'maL > >> sick of all these Wintel and UNIX over-promises.  I wonder, could it beF > >> true that VMS is still viable?"  Then does a quick Net search forK > >> information and finds comp.os.vms where long-time VMS USERS are sayingaI > >> "oh, dear, oh my, VMS will be dead in weeks, it's all over now, blahfB > >> blah blah".  What effect does THAT have on the future of VMS? > >eL > >That's for Compaq to decide.  If it chooses to take the actions necessary toK > >make VMS's long-term viability more believable, then it will likely findn atH > >large chorus of evangelists ready to spread the word.  The sentimentsE > >expressed here didn't *cause* VMS's current predicament, they're ae/ > >*reaction* to it - and a realistic reaction.n > >b >wD > I believe that some of the negativity here feeds into the "current! > predicament", whatever that is.e  H You can believe what you wish.  I believe that whatever contribution ourJ attitude may make negatively is miniscule (Compaq, and DEC before it, haveJ taken care of that end of things), and that the only hope of improving theI situation (small though that hope seems now) is to make Compaq understandDI that abandoning VMS will have immediate consequences (which your approacht
 does not do).<   >e > >>D > >> I'm NOT saying that we should all be pollyannas here.  I really
 appreciateG > >> David Mathogs attention to specific goals (~$2K VMS box some yearsu back)k > >andH > >> clear presentation of hard performance data.  We need more of this. MoreL > >> specifics, more specific goals and hard data and less wringing of hands > >andL > >> crying "Why has Capellas failed to mention us?? What have we done?? All is
 > >> lost!!!"P > >eH > >Capellas apparently did mention VMS, by implication:  didn't he state> > >explicitly that anything he hadn't mentioned was dead meat? > >aD > >You're welcome to your opinion, and free to spread it.  But don't	 castigatecI > >those whose opinions differ:  they're not part of the problem, they'res part3 > >of the solution - whatever that solution may be.  > >n > I > I'm sorry, but I don't agree that people who make statements like (fromi > <94vvl3$8ur$1@pyrite.mv.net>)r > G > > If people wanted to do something that *might* be constructive, theyt couldsK > > band together and present Capellas with a list of what actions it would  takeL > > to keep them from bailing out:  at least that would force Compaq to ante upH > > or suffer immediate consequences, and help clear the air at the same time.pI > > But the time for that kind of effort to be effective may be long gonea now. >d% > are really interested in solutions.e  K What you believe is up to you.  I've been actively involved with a group ofgL people for almost a year now attempting, non-confrontationally, to promote aK change in attitude within Compaq, and what we've seen is a string of brokensL promises and dashed hopes.  What have you done to attempt to fix things, andK what positive experiences do you have to draw upon to support your beliefs?U  %   The paragraph does offer a definiteSH > suggestion for action, which I might support, but the last sentence isI > just spleen-venting fatalism that proves that it's all about bitternesse > against Compaq management.  L No, it's about realism, based on experience.  I was hoping a couple of yearsJ ago that the VMS base would band together, as I said above, and get CompaqI to change its handling of VMS.  Proposing the same thing now, however, issG more like a last-ditch effort, and I didn't want to advocate it without G adding that the likelihood of success may be minimal:  raising people'ssJ hopes and exhorting them to pitch in without significant reason to believeK the effort will be productive may be something you're comfortable with, buti I'm not.   >lI > You might believe that it's too late.  Saying it in a public forum thatmF > might cause it to be a self fulfilling prophecy is not constructive.  	 Bullshit.s   - bill   >o	 > >- bill! > >  >  > -Jordan Hendersonh > jordan@greenapple.come >t   ------------------------------    Date: 28 Jan 2001 23:03:42 -0500/ From: jordan@lisa.gemair.com (Jordan Henderson) 8 Subject: Re: It's the end for VMS and other Wild Rumours* Message-ID: <952q2u$vsv$1@lisa.gemair.com>  O In article <952o1v$9at$1@pyrite.mv.net>, Bill Todd <billtodd@foo.mv.com> wrote:w >r; >Jordan Henderson <jordan@lisa.gemair.com> wrote in messages% >news:952kl3$qaa$1@lisa.gemair.com...rK >> In article <951pbp$jo8$1@pyrite.mv.net>, Bill Todd <billtodd@foo.mv.com>n >wrote:3 >9 >... >rM >> >> As Terry pointed out, CPQ would be crazy not to support a business thatM, >> >> is so profitable and actually growing. >> >J >> >Terry's viewpoint may not be completely unbiased:  Compaq is his bread >and% >> >butter, whether VMS lives or not.o >> > >>E >> I reference a point that Terry has made and you seem to imply that.- >> he's biased.  That's called an ad hominem.c > L >Which is perfectly appropriate if you're using the source (Terry), not just& >the sentiment, to bolster your point. >h  C I don't believe I was arguing by the authority of Terry above, just 8 referring from where this reasonable opinion originated.  L >Terry recently separated himself from a VMS advocacy effort to make sure itK >did not make him appear 'anti-MS'.  One can debate whether this separationnK >was justified, and I wouldn't suggest that he's not still a friend of VMS,eJ >but that action suggests that his friendship is limited to activities and6 >statements that don't upset other factions at Compaq. >o >  Now, what's wrong withc >> the argument? >nK >What' wrong is that exactly the same argument applied for the past decade:iM >it didn't stop DEC from neglecting and actively denigrating VMS, and for thehI >past two years it hasn't stopped Compaq from neglecting VMS (all they've6+ >stopped doing is actively denigrating it).c >lD >*Why* this is the case is debatable.  *That* it is the case is not. >m  E I disagree.  I see a lot more support for VMS under Compaq than under H DEC.  I believe that DEC was trying to kill VMS to convince the IndustryD that they really weren't the hidebound ol' DEC who couldn't see thatD the future was UNIX and NT.  Compaq, I feel, is more sanguine and is5 only interested in results, long term AND short term.   D I saw real marketing going on with OpenVMS last year from Compaq, inA trade magazines and even the Wall Street Journal.  I believe thati@ Compaq analyzed the results of that marketing and found it to beB ineffectual.  The fact is that you had to get the Analysts to turnE around before that kind of marketing could be effective.  Guess what? $ The Analysts are turning around now.  A I think this state of affairs is due to direct, behind-the-scenes>D efforts by Compaq and we can expect to see even better things in the future.    >... > J >> >You can be as optimistic as you want.  Some people might prefer not to >sinks >> >with the ship. >> > >>I >> I contend that all this hand wringing and whining in a public forum ise$ >> not helping the ship stay afloat. > J >Which is not the point.  The only entity that can keep the ship afloat isM >Compaq.  Though it hasn't sunk yet, the ship currently has a very large holemK >in it.  You seem to be saying that we should not be telling people to keepSF >close to the lifeboats, because that might cause some of them to stopL >bailing.  I'm saying that if Compaq doesn't see an incipient evacuation, itL >will have no motivation to patch the hole, in which case the ship *will* go  >down, regardless of what we do. >   @ I completely disagree with the premise that the only entity that# can keep the ship afloat is Compaq.p   >> >> >>eK >> >> Get over it.  Even if VMS was dying, all this extended negativity andrL >> >> whining doesn't help matters in the least.  How do you think this veryE >> >> public forum looks to the mostly VMS-ignorant public out there?w >> >K >> >I'd hope it makes them think long and hard before deciding to commit torK >> >using VMS in any long-term project.  That would be a public service, ine >myv >> >opinion. >> > >>K >> _This_ is keeping the ship afloat?  Seems like you're really saying that F >> now that Compaq has abandoned us, we need to pay them back in kind. >tK >No, I'm saying that keeping the ship afloat is Compaq's job, not ours.  If G >we see a commitment to do so, we'll gladly help.  If we don't see suchhL >commitment, we not only have no obligation to go down with the ship, but weG >*do* have an obligation to warn others that is may not be safe to comee >aboard. >i  C Cynical negativity will fail to see Compaq's efforts even when theyn actually exist.p   >> >> >>oL >> >> Say some CIO reads the positive Gartner press and says to himself "I'mM >> >> sick of all these Wintel and UNIX over-promises.  I wonder, could it berG >> >> true that VMS is still viable?"  Then does a quick Net search foriL >> >> information and finds comp.os.vms where long-time VMS USERS are sayingJ >> >> "oh, dear, oh my, VMS will be dead in weeks, it's all over now, blahC >> >> blah blah".  What effect does THAT have on the future of VMS?c >> >M >> >That's for Compaq to decide.  If it chooses to take the actions necessaryS >totL >> >make VMS's long-term viability more believable, then it will likely find >aI >> >large chorus of evangelists ready to spread the word.  The sentimentsdF >> >expressed here didn't *cause* VMS's current predicament, they're a0 >> >*reaction* to it - and a realistic reaction. >> > >>E >> I believe that some of the negativity here feeds into the "currento" >> predicament", whatever that is. > I >You can believe what you wish.  I believe that whatever contribution ourrK >attitude may make negatively is miniscule (Compaq, and DEC before it, have K >taken care of that end of things), and that the only hope of improving thehJ >situation (small though that hope seems now) is to make Compaq understandJ >that abandoning VMS will have immediate consequences (which your approach >does not do). >t  @ What, exactly, is my approach?  I'm only advocating not being soB negative about the future on OpenVMS in a public forum, if you are& interested in OpenVMS having a future.  D As I've said, I support direct communications with Compaq management  about these views in other fora.   >> >> >>sE >> >> I'm NOT saying that we should all be pollyannas here.  I reallyd >appreciateSH >> >> David Mathogs attention to specific goals (~$2K VMS box some years >back) >> >andmI >> >> clear presentation of hard performance data.  We need more of this.t >MoreaM >> >> specifics, more specific goals and hard data and less wringing of handst >> >and M >> >> crying "Why has Capellas failed to mention us?? What have we done?? Allt >ise >> >> lost!!!" >> >I >> >Capellas apparently did mention VMS, by implication:  didn't he states? >> >explicitly that anything he hadn't mentioned was dead meat?e >> >E >> >You're welcome to your opinion, and free to spread it.  But don'th
 >castigateJ >> >those whose opinions differ:  they're not part of the problem, they're >partq4 >> >of the solution - whatever that solution may be. >> > >>J >> I'm sorry, but I don't agree that people who make statements like (from  >> <94vvl3$8ur$1@pyrite.mv.net>) >>H >> > If people wanted to do something that *might* be constructive, they >couldL >> > band together and present Capellas with a list of what actions it would >takenM >> > to keep them from bailing out:  at least that would force Compaq to anten >upiI >> > or suffer immediate consequences, and help clear the air at the samen >time.J >> > But the time for that kind of effort to be effective may be long gone >now.- >>& >> are really interested in solutions. >2L >What you believe is up to you.  I've been actively involved with a group ofM >people for almost a year now attempting, non-confrontationally, to promote aoL >change in attitude within Compaq, and what we've seen is a string of brokenM >promises and dashed hopes.  What have you done to attempt to fix things, andoL >what positive experiences do you have to draw upon to support your beliefs? >h  C I've worked within my organization as an OpenVMS advocate and I've hD tried to do things in public forums, not just here, that I feel are E supportive of a future for OpenVMS.  I try to offer helpful technicalt advise here, when I can.    ; I find it difficult to believe that you have done anything rI behind-the-scenes non-confrontationally, when you are so confrontational   here, in a public forum.  & >  The paragraph does offer a definiteI >> suggestion for action, which I might support, but the last sentence ispJ >> just spleen-venting fatalism that proves that it's all about bitterness >> against Compaq management.o >vM >No, it's about realism, based on experience.  I was hoping a couple of yearseK >ago that the VMS base would band together, as I said above, and get Compaq J >to change its handling of VMS.  Proposing the same thing now, however, isH >more like a last-ditch effort, and I didn't want to advocate it withoutH >adding that the likelihood of success may be minimal:  raising people'sK >hopes and exhorting them to pitch in without significant reason to believe L >the effort will be productive may be something you're comfortable with, but	 >I'm not.d >i  A If you really believe it's hopeless now, why do you bother if notw for vengeance?  F If you believe there's just this glimmer of hope, then I would suggestH that it would be more constructive to express your pessimism in private.  H I believe that all this fatalism has a definite and pulpable dispiritingH effect on the readers of comp.os.vms which has a real negative influenceI on the future prospects for OpenVMS.  I gather you don't agree with this,i but that's my position.  j  E You seem to believe that only Compaq and it's management can have anyh- effect on the future of OpenVMS.  I disagree.i   >>J >> You might believe that it's too late.  Saying it in a public forum thatG >> might cause it to be a self fulfilling prophecy is not constructive.  > 
 >Bullshit. >g  5 Well, that's constructive and so non-confrontational.t   >- billa >o   -Jordan Hendersono jordan@greenapple.com,   ------------------------------    Date: 28 Jan 2001 23:30:42 -0500* From: young_r@eisner.decus.org (Rob Young)8 Subject: Re: It's the end for VMS and other Wild Rumours+ Message-ID: <jmmgfhILOKHL@eisner.decus.org>t  \ In article <3A73EA45.1F2052AF@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Terry C Shannon wrote:M >> omission (no references to VMS) than a death warrant. Windoze is not readyi# >> for prime time in the VMS space,f > M > What is the VMS space ? Compaq's web cast filled the "space" with its othergO > OSes leaving no room for VMS. And as far as NT not ready for prime time, thatc& > is not the message given by Compaq.  >  > L >> business is actually growing again, the revenue is substantial--much more >> than Himalaya NSK-- > K > Bot according to the numbers published. I beleive NSK made over a billion M > while VMS just under a billion. (although you'd have to verify this). I can P > beleive VMS has improved. But if it did turn around, you'd think that Capellas" > would have proudly mentioned it. >   @ 	Ah... but what numbers are *you* measuring?  It goes far beyond
 	hardware.   				Robf   ------------------------------  % Date: Sun, 28 Jan 2001 23:57:38 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>r8 Subject: Re: It's the end for VMS and other Wild Rumours, Message-ID: <3A74F83F.3BB5915D@videotron.ca>   Jordan Henderson wrote:eE > I don't believe I was arguing by the authority of Terry above, justu: > referring from where this reasonable opinion originated.  N Lets speculate for a minute that Charlie Matco's dog, Charlie Muttco, was ableK to sneak into a very secret strategic meeting inside of Compaq's boardroom.gN Lets assume that in that meeting, the discussed a massive advertising campaignL for VMS and decide to make VMS Compaq's core OS system to be rolled out from; desktop to datacentre, and dropping all Microsoft products.v  N Obviously, Mutt would go back to to his master Charlie Matco and tell him thatL the female dog in blue told him about some very great plans for VMS. CharlieN Matco would then advise people to be patient and wait because Compaq has great plans for VMS.  K OK, so we stay quiet for a while because we we told to expect great things.fL But what happens when those great things never happen and no Compaq not onlyK stops mentioning VMS, but appears to have filled VMS' niches with its othere
 products ?  J What happens if, between that meeting and now, Compaq changed its mind andK decided to let VMS sink ? And lets be a bit conspirary-theorist for a whileoM and consider the possibility that the Board were fully aware that the furry 4aM legged Muttco was in the board room, listening in and reporting everything tocK Matco ? They would use this occasion to feed unconfirmed information to thenA masses to get the VMS folks to be patient and be quiet once more.t   Spies and leaks work both ways.t  I Compaq knows that it cannot abandon VMS in one shot. The instant drain intL revenus could not be hidden. So controlling/extending the migration from VMSN is the best possible course of action. The problem is that once you've decidedK this, it becomes far too easy to forget about VMS and end up in the currenttA situation where the customers are seing through Compaq's tactics.o  G > I disagree.  I see a lot more support for VMS under Compaq than underd > DEC. o  K There was a push last year. But that push seems to have completely vanishedgK and VMS back into the oblivion. That is what has triggered this discussion.r    C > I think this state of affairs is due to direct, behind-the-sceneseF > efforts by Compaq and we can expect to see even better things in the	 > future.C  N We're tired of "in the future". Patience has runned out. Compaq has had plentyN of opportunities to send a strong PUBLIC signal that it was serious about VMS,K even without advertising budget. If Capellas had been serious about VMS, hecM would have found a way to slip in some encouraging news in his long speeches.o5 Those analysts conference calls are free advertising.h    B > I completely disagree with the premise that the only entity that% > can keep the ship afloat is Compaq.a  N For as long as Compaq keep control of VMS, then Compaq is the only entity that keep it afloat.d  J It is pointless for a VAR to start advertising VMS if Compaq keeps controlK over prices and sales forces and marketing, and more importantly, if CompaqeN keeps claiming its other systems are the best in the world even in areas where VMS still has an edge. c  E > Cynical negativity will fail to see Compaq's efforts even when they  > actually exist.e  L When Jobs came back to Apple, there was great hope, he came through with theM imac and was cheered at the Macworld because the mac fanatics were very happy % to see Apple rebuilt its MAC product.,  L We have yet to see this happen, but I can garantee you that if you get a CEOM that is gung-ho about VMS and actually does something concrete with it, he'llo* be cheered big time at a decus conference.   ------------------------------    Date: 29 Jan 2001 00:24:47 -0500/ From: jordan@lisa.gemair.com (Jordan Henderson)i8 Subject: Re: It's the end for VMS and other Wild Rumours* Message-ID: <952uqv$4ov$1@lisa.gemair.com>  , In article <3A74F83F.3BB5915D@videotron.ca>,/ JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:e >Jordan Henderson wrote:F >> I don't believe I was arguing by the authority of Terry above, just; >> referring from where this reasonable opinion originated.r >sO >Lets speculate for a minute that Charlie Matco's dog, Charlie Muttco, was able L >to sneak into a very secret strategic meeting inside of Compaq's boardroom.O >Lets assume that in that meeting, the discussed a massive advertising campaigntM >for VMS and decide to make VMS Compaq's core OS system to be rolled out fromr< >desktop to datacentre, and dropping all Microsoft products. >o  L This is an Alice In Wonderland scenario.  No Compaq management would surviveK the emergency board meeting that would ensue if they proposed dropping all   Microsoft products.e  O >Obviously, Mutt would go back to to his master Charlie Matco and tell him that8M >the female dog in blue told him about some very great plans for VMS. CharliejO >Matco would then advise people to be patient and wait because Compaq has greati >plans for VMS.  >aL >OK, so we stay quiet for a while because we we told to expect great things.M >But what happens when those great things never happen and no Compaq not onlyqL >stops mentioning VMS, but appears to have filled VMS' niches with its other >products ?o >vK >What happens if, between that meeting and now, Compaq changed its mind andyL >decided to let VMS sink ? And lets be a bit conspirary-theorist for a whileN >and consider the possibility that the Board were fully aware that the furry 4N >legged Muttco was in the board room, listening in and reporting everything toL >Matco ? They would use this occasion to feed unconfirmed information to theB >masses to get the VMS folks to be patient and be quiet once more. >n  >Spies and leaks work both ways. >s  I This has nothing to do with the discussion at hand.  I was not referring aI to, nor quoting Terry Shannon's statements that we should wait for betternI things in the future for OpenVMS coming from Compaq, I was only referringtH to the sensible belief that Compaq does not want to kill OpenVMS as it's" a profitable and growing business.    J >Compaq knows that it cannot abandon VMS in one shot. The instant drain inM >revenus could not be hidden. So controlling/extending the migration from VMSnO >is the best possible course of action. The problem is that once you've decidednL >this, it becomes far too easy to forget about VMS and end up in the currentB >situation where the customers are seing through Compaq's tactics. >S  J If you feel this is true, then it's reasonable for you to state this here.J But be mindful that you might be helping to hurry VMS along to an untimelyF death if you've read Compaq's intentions incorrectly because you might' convince others that VMS has no future.e  B You might suggest that Compaq take definite steps to correct this D situation so that VMS users won't feel obliged to say such things inA a public forum.  I could counter that there's little Compaq couldeB do to satisfy VMS users who seem to feel that putting VMS up frontB as Compaq's premier OS, desktop to datacenter, and dropping all MS products would be a good thing.e  H >> I disagree.  I see a lot more support for VMS under Compaq than under >> DEC.  > L >There was a push last year. But that push seems to have completely vanishedL >and VMS back into the oblivion. That is what has triggered this discussion. >s >hD >> I think this state of affairs is due to direct, behind-the-scenesG >> efforts by Compaq and we can expect to see even better things in thee
 >> future. >eO >We're tired of "in the future". Patience has runned out. Compaq has had plenty O >of opportunities to send a strong PUBLIC signal that it was serious about VMS,IL >even without advertising budget. If Capellas had been serious about VMS, heN >would have found a way to slip in some encouraging news in his long speeches.6 >Those analysts conference calls are free advertising. >s > C >> I completely disagree with the premise that the only entity thatb& >> can keep the ship afloat is Compaq. >lO >For as long as Compaq keep control of VMS, then Compaq is the only entity thatp >keep it afloat. >n  F I disagree.  I think the user community has as much to do with keepingH a product viable as a vendor.  If you have a visible user community full/ of bile and negativity, it doesn't help at all.   K >It is pointless for a VAR to start advertising VMS if Compaq keeps controlpL >over prices and sales forces and marketing, and more importantly, if CompaqO >keeps claiming its other systems are the best in the world even in areas wherek >VMS still has an edge.  >mF >> Cynical negativity will fail to see Compaq's efforts even when they >> actually exist. >nM >When Jobs came back to Apple, there was great hope, he came through with thetN >imac and was cheered at the Macworld because the mac fanatics were very happy& >to see Apple rebuilt its MAC product. >'M >We have yet to see this happen, but I can garantee you that if you get a CEOmN >that is gung-ho about VMS and actually does something concrete with it, he'll+ >be cheered big time at a decus conference.s   -Jordan Henderson  jordan@greenapple.com    ------------------------------  % Date: Sun, 28 Jan 2001 15:07:15 -0500e- From: JF Mezei <jfmezei.spamnot@videotron.ca>i- Subject: Re: It's the end for VMS get off nowi, Message-ID: <3A747BF0.DAC0BA17@videotron.ca>   Bill Todd wrote:K > While it would be nice not to have to, when the mule doesn't respond it's E > time to pick up a 2x4 and get its attention.  Or find another mule.    Well said.    L (Geez, the end of the world must truly be near, I have found myself agreeing with you more than once :-)m   ------------------------------  % Date: Sun, 28 Jan 2001 22:36:13 +0000,% From: Alan Greig <a.greig@virgin.net>,- Subject: Re: It's the end for VMS get off nowa* Message-ID: <3A749EDC.D1B010EE@virgin.net>  E I've just replayed the first two speeches by Capellas and Winkler andiJ still come to the same conclusion. One correction to make. It is not clearD that Capellas said that they had given more clustering technology toF Microsoft. He said they were working jointly with Microsoft to improveI datacentre abilities of W2K and to improve clustering. He then went on toaG say that they had licensed their industry leading cluster technology tooJ Oracle. They would then help Oracle tune this for Windows 2000 Datacentre.E Hmm, maybe my joke about a Compaq/Oracle merger wasn't such a joke...a  E I would say that Winkler is no friend of VMS and no friend of Unix. I ? think his tone clearly gives that away, He also stated that the I Tandem/Himalaya team had been moved to the Industry Standard Server Group D (ie Microsoft). The Himalaya technology would be transferred to thisG platform he said. No mention of Himalaya on Alpha by him. He managed tocJ almost spit the word unix a few times and he went further than Capellas byJ stating that they would not only attack its soft underbelly but would thenF drive Unix out all the way up. He said that it was inevitable that W2K will win the war.>  H I am now even more convinced the word VMS was left out of these speechesJ intentionally. Where a win or an application possibly referred to VMS theyI always substituted the generic term Alphaserver or clustering technology.dI They did commit to continuing to support Alpha and clustering technology.aC They pointedly did not commit - at least in these two speeches - to H continuing with VMS. If Winkler had his way I'm sure VMS would have been dead and buried by now.l   ------------------------------  % Date: Mon, 29 Jan 2001 01:10:42 +0000c) From: Christof Brass <brass@infopuls.com>d Subject: LN03 system passwordl, Message-ID: <3A74C312.D3D74C1F@infopuls.com>  ? Although not direct related to VMS I dare to ask here because Io= don't know where else (please direct me if inappropriate) andh8 because several other posters in cov already asked using printers with VMS systems.  @ Problem: each time I switch on my LN03 it spits out a test page.; I read in the manual that there is the possibilty to changec> this. For that I have to log in (yes the printer offers to log9 in) using the printer's account password. If I try that I - receive a message that the password is wrong.m  
 Questions:8 - Is there any trick in replying to the password prompt?< - What passwords besides the default as stated in the manual could be tried? ? - Is there a way to reset the printer including the password toi the factory settings?   > If there is any information missing please ask. Searching with( LN03 and password doesn't find anything.   TIAo   ------------------------------  % Date: Sun, 28 Jan 2001 21:29:37 -0500w- From: JF Mezei <jfmezei.spamnot@videotron.ca> ! Subject: Re: LN03 system passwordn, Message-ID: <3A74D58D.76A0FBA7@videotron.ca>   Christof Brass wrote:eB > Problem: each time I switch on my LN03 it spits out a test page.  K You should have asked before I transformed my old LN03 into a foot rest ...r   There were 3 models of the LN03   ? LN03 (useless basic text printer, with minimal graphics memory)i LN03-PLUS (capable of graphics)  LN03-R  ( postscript printer)e    D Neither the LN03 not LN03 plus were capable of handling passwords orK generating test pages on their own at startup. So I have to assume you haveh
 the LN03-R  M I don't have the documentation set for that printer, however, looking at the eD DCPS$LAYUP:*.PS files on my system, I can see two files of interest:  M One is specifically to stop the automatic cutting of a billion trees whenever . you turn on the printer: (DCW1000_NOSTRTPG.PS)  C %  After this file is sent, the start page will not be printed whena% %  the printer is turned on or reset.o  = %  Wrap function with startjob to make the change persistent.f   <<  /Password (0) defo     /DoStartPage false def >> setsystemparams  L Note that in the above, you need to change the (0) to the correct (password)   -------u   To change/reset the password:    <<  /Password (oldpassword) defb+     /SystemParamsPassword (newpassword) defm >> setsystemparams  P you you set newpassword to a empty string (), then no password will be enforced.    A > - Is there a way to reset the printer including the password tot > the factory settings?c  H There should be a way to do this, but I do not know offhand. If all elseN fails, unscrew the lower back panel which gives you access to the motherboard,R and pull the boards out. If you see a small battery, remove it for a few hours :-)   ------------------------------  # Date: Mon, 29 Jan 2001 02:22:12 GMTe" From: fooguy <jweisen@my-deja.com>7 Subject: RE: Midrange I/O with VMS WAS: DS20 - Slow I/O ) Message-ID: <952k4g$pcr$1@nnrp1.deja.com>   H My only problem with the RA3000 is similar to my problem with the RA7000F - it's only Ultra. 40MB/Sec was great 3 years ago, but what about LVD,B U160, and U320. I can get them if I buy a Fiber Channel SAN and anF HSG80, but if I'm not willing to spend that kind of money I'm resigned to dated technology.  E I can buy a 6000$ Dell PowerEdge or a 6000$ Proliant with a 64bit PCIcD RAID controller that supports U160 drives, but I can't buy a 30,000$E Alpha that even supports LVD, let alone U160, let alone hardware RAIDaD that is affordable. I'm not asking for cutting edge, I just want theE Alpha hardware people to keep with the times. The only 64bit LVD RAIDeF Controller in the Alpha product line is only supported on the DS10 and the ES40, and not under VMS.  B And the RA3000, like the 7000, is a smart cabinet, dumb controllerA solution. You're limited by the bandwidth the host controller caneH provide, all in all a poorly architectured solution. I'm sure there is aE reason for it, but damned if I can find it. All I want, is a midrangedG backplane host based RAID controller (translation: Go buy a Mylex 64bit F PCI RAID Controller that supports LVD and U160 and write some firmware? for it!) I want an updated KZPAC, for all intents and purposes.k   I'll get off my soapbox now.   Thanks,n John  
 In articleC <910612C07BCAD1119AF40000F86AF0D805284CD1@kaoexc3.kao.cpqcorp.net>,..   "Main, Kerry" <Kerry.Main@compaq.com> wrote: >a > > > >>> The RaidArray 3000 still seems to be sold by Compaq. <<< >i > Yep. >r > Reference: >'H <http://www5.compaq.com/products/storageworks/raidstorage/maRA3000.html> >o
 > Regards, >d > Kerry Main > Senior Consultanti > Compaq Canada Inc. > Professional Servicesv > Voice: 613-592-4660r > Fax  :  819-772-7036 > Email: Kerry.Main@Compaq.com >a > -----Original Message-----3 > From: Eric Ebinger [mailto:eebinger@telocity.com] ! > Sent: January 27, 2001 11:32 AMe > To: Info-VAX@Mvb.Saic.Coms9 > Subject: Re: Midrange I/O with VMS WAS: DS20 - Slow I/Ot >n6 > The RaidArray 3000 still seems to be sold by Compaq. > $ > Yes, it does claim to support VMS. >d > Eric Ebinger >p > -----Original Message-----$ > From: fooguy <jweisen@my-deja.com>3 > To: Info-VAX@Mvb.Saic.Com <Info-VAX@Mvb.Saic.Com>e+ > Date: Thursday, January 25, 2001 11:11 AMl5 > Subject: Midrange I/O with VMS WAS: DS20 - Slow I/O  >pH > >So I think we've all come to the same conclusion - this system sucks. > >tH > >I'm looking around at other midrange options, and I don't see any. ItF > >looks like my options are the KZPAC, and HSZ80. So what I'm hearing isG > >that Compaq and OpenVMS only support two backplane RAID controllers:? oneh5 > >that is 5 years old and the other that is $25,000.n > >tE > >I understand the industry trend is moving to detached storage, butr hereF > >I am, an admin of a VMS based financial system with 16Gigs of data, and H > >I can't buy a decent performing Ultra Wide 64bit RAID controller thatF > >can do RAID 5 with (3) 18gig disks? How do I justify a $25,000 RAIDH > >controller for a system with 20 users? I can get a DS10 with a KZPCC,C > >which would suit my needs perfectly, but what I'm seeing is thats theret3 > >is no support for VMS, and none planned for 7.3.t > >eG > >If some could write back and say that I can get the KZPCC and a DS10 G > >working under OpenVMS with a 4224 enclosure, I'd be the happiest mancB > >alive. (C'mon people - today is my birthday. Help me out here.) > > < > >In any event, if anyone can offer their I/O success story (preferrablyB > >that doesn't involve the KZPAC) I'd appreciate. That could even include = > >performance of volume shadowing with faster, non-raid SCSIh controllers. > >s
 > >Thanks, > >Johnt > >  > >i, > >In article <949rps$mcj$1@nnrp1.deja.com>,( > >  fooguy <jweisen@my-deja.com> wrote:E > >> I know that the KZPAC is not supposed to be the shining stars ofc diskH > >> performance, but we just purchased two DS20s, and I have to say I'mG > >> really disappointed in the performance of the disk subsystem. I'ved runrE > >> the gambit of configurations, and I have yet to get the DS20s toi
 > >perform > >> faster than my desktop PC.  > >>G > >> My test was copying several large files (Oracle dumps - each aboutp6 > >> 200MB) from one directory on the disk to another. > >>	 > >> DS20  > >> > >> Number of Disks: (4) 9GBt% > >> RAID Config: RAID 10 - 2 Channele > >> Cluster Size: 35a > >> MB/Sec: 1.13C > >> > >> Number of Disks: (4) 9GBq% > >> RAID Config: RAID 10 - 2 Channelt > >> Cluster Size: 1 > >> MB/Sec: 1.48a > >> > >> Number of Disks: (4) 9GBl% > >> RAID Config: RAID 10 - 1 Channele > >> Cluster Size: 1 > >> MB/Sec: 1.20e > >> > >> Number of Disks: (1) 9GBe' > >> RAID Config: SLED/JBOD - 1 ChannelM > >> Cluster Size: 1C > >> MB/Sec: Tested all four disks. Results range from 1.07 to 1.37t > >>. > >> Number of Disks: (1) 3GB Solid State Disk0 > >> RAID Config: N/A - attached to Symbios Card > >> Cluster Size: 1 > >> MB/Sec: 13.21D > >> (Not Bad, but for a $30k hard drive it should be better. Compaq says > >iteE > >> has a maximum sustainable transfer rate of ~60MB/Sec, I'd settleC forh > >20u > >> in this test) > >> > >> Dell PowerEdge 4300 > >>% > >> Number of Disks: (2) 9GB 7200RPMc$ > >> RAID Config: RAID 1 - 1 Channel > >> Cluster Size: N/A > >> MB/Sec: 8.385 > >> > >> Dell Optiplex GX1pm > >>" > >> Number of Disks: (1) 10GB IDE > >> RAID Config: N/A  > >> Cluster Size: N/A > >> MB/Sec: 1.82a > >>F > >> Like I said, I know the KZPAC isn't the universe's answer to Fast I/O,E > >> but is there any sort of tuning I can do to improve performance?e I'veE > >> already played with cluster size, moving disks from the internal 
 > >cabinetE > >> to the BA356, and cache type (write back vs. write through) with  only > >aD > >> tiny difference. I'm not expecting a while lot, but is this the best I- > >> can expect? I'd be happy with 3-8MB/Sec.n > >> > >> Thanks in advance.m > >> > >> --i2 > >> *********************************************- > >> "All I every wanted from life was to seet1 > >> Larry Wall give Bill Gates a Perl Necklace."t > >> > >> Sent via Deja.com > >> http://www.deja.com/m > >> > >e > >--d0 > >*********************************************+ > >"All I every wanted from life was to seef/ > >Larry Wall give Bill Gates a Perl Necklace."  > >s > >e > >Sent via Deja.com > >http://www.deja.com/  > >n >u   --- *********************************************i( "All I every wanted from life was to see, Larry Wall give Bill Gates a Perl Necklace."     Sent via Deja.com, http://www.deja.com/   ------------------------------  % Date: Sun, 28 Jan 2001 19:58:24 -0600t7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>s3 Subject: Re: Quick (stupid) question on DECnet Plusn- Message-ID: <3A74CE40.6DC9EF32@earthlink.net>a   Andrew Robert wrote: > [snip]> > I am exploring the requirements for converted from Phase IV.   Strictly my opinion: r  F Exhaust all other alternatives first. Set up and management of Phase-VG is a royal PITA and getting it to run as quiet and reliable as Phase-IVn7 takes a serious commitment of time and effort to learn.s  G Unless you absoultely postively *MUST* have something that only Phase-VVF can do, IMO, you'd do much better to stay with Phase-IV or learn to do2 without DECnet completely, environment permitting.  9 Your mileage may (and probably will) vary considerably...e   -- n David J. Dachteraa dba DJE Systemsf http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/p  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.    ------------------------------   Date: 28 Jan 2001 20:05:33 GMT7 From: Thomas.Hahnemann@nospam_s-t.de (Thomas Hahnemann)t Subject: Re: samba 2.0.60 Message-ID: <Oozvf8elmJpy-pn2-dOvc2o7wdJ6P@Tom2>   John,   ? thanks, now the build runs. I've changed  in add_to_library.coms
 the line :3 $ lib_base_name = f$element(1, ".",lib_dir) - delimn to3 $ lib_base_name = f$element(2, ".",lib_dir) - delims6 I think it's why I did not setup the project directory6 for the build as device name and it should be the last2 element of lib_dir, so 2 is my last and it should  finaly be chagnged to :d   $ element = "" $ old_element = elementc $ i1 = 0 $ l1:  $       old_element = elemento4 $       element = f$element(i1, ".",lib_dir) - delim $       i1 = i1 + 1'& $ if( element .nes. "." ) then goto l1 $ lib_base_name = old_elementd  7 Now I need some install hints for new compiled product.o> 1. I have unpacked the VMS base kit into samba_root, correct ?@ 2. What have I to copy from my [samba.source.bin], .lib],... to  [samba_root] ?< 3. Is it enough to copy samba_startup.com to sys$startup to     install the new version ?   Thanks in advancer   Regards-   Thomas Hahnemann   ------------------------------    Date: 28 Jan 2001 17:22:28 -05002 From: malmberg@eisner.decus.org (John E. Malmberg) Subject: Re: samba 2.0.6+ Message-ID: <KD0+IxsJRrix@eisner.decus.org>t  0 In article <Oozvf8elmJpy-pn2-dOvc2o7wdJ6P@Tom2>,9 Thomas.Hahnemann@nospam_s-t.de (Thomas Hahnemann) writes:o > John,V > A > thanks, now the build runs. I've changed  in add_to_library.com  > the line :5 > $ lib_base_name = f$element(1, ".",lib_dir) - delim. > to5 > $ lib_base_name = f$element(2, ".",lib_dir) - delimo  8 > I think it's why I did not setup the project directory8 > for the build as device name and it should be the last3 > element of lib_dir, so 2 is my last and it shouldi > finaly be chagnged to :o >n > $ element = "" > $ old_element = element 
 > $ i1 = 0 > $ l1:I > $       old_element = elementt6 > $       element = f$element(i1, ".",lib_dir) - delim > $       i1 = i1 + 1r( > $ if( element .nes. "." ) then goto l1 > $ lib_base_name = old_elements  A Your second fix of course is better.  Since I only had 1 level ofa, subdirectories, I did not do a general case.  A I also think that maybe the command procedure be modified to alsog= do the C compile and in case of a warning would not leave thet2 object file to fool the next build into moving on.  9 > Now I need some install hints for new compiled product.h@ > 1. I have unpacked the VMS base kit into samba_root, correct ?  : The directories created by the base kit and there contents= will give you good roadmap as to what binaries are needed fora running.  F For testing, the only file that actually needs to be in that directory  tree is SAMA_ROOT:[LIB]SMB.CONF.  @ Logical names are used to find all of the images, and can be set as needed to do debugging.  ? If the codepage files are missing, the Samba programs may issuet& a diagnostic but they will still work.  A > 2. What have I to copy from my [samba.source.bin], .lib],... tol > [samba_root] ?  A Not all are needed.  The .OLB_* are only needed for relinking the', executables, and are not needed for running.  D See above about examining the current contents of SAMBA_ROOT:[*...].( It has everything where they need to be.  2 I think this is also described in the *.txt files.  = > 3. Is it enough to copy samba_startup.com to sys$startup tor >    install the new version ?  ? Since SAMBA_STARTUP.COM assumes that it is residing in the same3D directory tree that the rest of the base SAMBA package is in, moving3 it to sys$startup: would probably not work to well.a  D In your SYSTARTUP_VMS.COM or command procedure that is called by it,> simply put line to run @dev:[samba_root.bin]samba_startup.com.  > What I usually do is put a lines in SYLOGICALS.COM that define6 the concealed rooted logical names such as SAMBA_ROOT:  = Then I can just put @SAMBA_ROOT:[BIN]SAMBA_STARTUP.COM in the  SYSTARTUP_VMS.COM.  C By placing all the commands that defined the concealed roots in thecB SYLOGICALS.COM, I only have to go to one place to change things ifC I need to reorganize my disk usage.  After using BACKUP to move thee files of course.  B The SAMBA_STARTUP.COM will create the SAMBA_ROOT concealed logical& name if it does not exist in any case.  
 Good luck,   -Johnr wb8tyw@qsl.network Personal Opinion Onlyg  @ I still do not know if the SWAT program works or not, nor have IA looked into what it would take to get an OpenVMS based WEB servere
 to launch it.w   ------------------------------    Date: 28 Jan 2001 22:40:20 -00003 From: lcs Mixmaster Remailer <mix@anon.lcs.mit.edu>l8 Subject: Re: Share Your Feelings About "The end for VMS"6 Message-ID: <20010128224020.21760.qmail@nym.alias.net>  C On Sun, 28 Jan 2001, Terry C Shannon <shannon@world.std.com> wrote:pD >If you are a VMS user or enthusiast who is concerned about Compaq'sD >treatment of the OS in the recent financial analyst conference, whyC >not visit www.compaqworkinggroup.org and register your opinion viadB >the online advocacy mechanism? It's far more likely that CPQ willE >respond to a slew of postings in the advocacy forum than to materiale >posted on Usenet.   Terry,  J Do they permit the anonymous registration of opinions? Or will disgruntledH employees find themselves seeking alternative employment for registering: their disgust at the mis-treatment of such a fine product?           /.   ------------------------------  % Date: Sun, 28 Jan 2001 17:02:17 -0500a0 From: "Sharkonwheels" <tonym@compusourceDOT.net>, Subject: Re: VaxStation 4000/90A Question(s)) Message-ID: <1R0d6.18$2E1.2600@news4.mco>   ' "Dan O'Reilly" <dano@process.com> wrotel. > At 08:40 AM 1/28/2001, Paul Repacholi wrote:* > >Dan O'Reilly <dano@process.com> writes: > >   , > >And set S3 iunder the front flap 'right'. >f > Yep. >   + I think he meant set it to the UP position?gB At any rate, got it working, thenks to Steven  Schweda. He brought1 up the idea of modifying an RJxx phone connector.t  = Actually, I modified one of my RJ45 Cisco Console cables with B a Dremel tool! Works great now! Seems I just happened to have some= RJ45-to-DB25 and -DB9 connectors in the garage. Probably beena  in that same toolbox since 1994!  2 Thanks guys! Got OpenVMS 7.2 installed last night.  > Now, if I can ask 1 more....how do I run the NET$CONFIGURE.COM; scripts? Startup says SYS$MANAGER:NET$CONFIGURE.COM, but...   H Yes I'm a VMS newbie, but DAMN! I 'mtrying hard as I can, even using the Digital/Q online manuals!!   Tony tonymATcompusourceDOTnet   ------------------------------  % Date: Sun, 28 Jan 2001 23:30:44 +0000r% From: Alan Greig <a.greig@virgin.net>s& Subject: VMS actually mentioned but...* Message-ID: <3A74ABA4.8D15AC94@virgin.net>  J Ok, I've watched the second Capellas speech now. Took about three hours ofI video drops before I got there and he does mention VMS but...What he saidtH was that OpenVMS had a large installed base in healthcare and they wouldD especially work to keep those accounts. They might try to expand theE market but "there are reasons to be cautious. Especially in the firsti quarter"  F He pointedly did not, as I hear it, commit to anything solid about theG future of VMS. He specifically said "there are reasons to be cautious".aH Perhaps lower than expected VMS sales are causing problems but I thought: they were up? Sounded like he was implying something more.  G The VMS mention was the very last item in his speech. Tagged on?  And I D suspect he knew we were looking for a message. He told us "there areI reasons to be cautious". If VMS sales have plummeted then the decision tod retire it becomes easier.P  F It does sound as if Capellas might be convinced VMS could grow but theJ majority of the rest of management want rid of it. In any case I think nowG is the time to make it as clear as possible to Compaq that we are happy H with VMS and will continue to buy it but only if Compaq give us some farJ more positive news. I really can't recommend a new installation right now.C It reminds me of just before Alpha/NT was dropped. Doesn't mean the,J outcome will be the same but I think now *is* the time to make some noise.  H Last year, based on strong assurances, I pushed for VMS on Alpha insteadA of just running the VAXes into the ground while moving to another$I platform. Several European sites have migrated without problem and we arepG now looking at a much larger migration in the US. However our corporate,J head office (in Houston funnily enough) seems almost immune to any pro-VMSJ literature saying that we "don't see the big picture" and "that VMS reallyG does not have a future" Now there are also plenty of people arguing for0H the switch but right at the moment I'm not confident enough to be one of them.c   --
 Alan Greig   ------------------------------    Date: 28 Jan 2001 21:45:57 -0500/ From: jordan@lisa.gemair.com (Jordan Henderson)g* Subject: Re: VMS actually mentioned but...* Message-ID: <952lh5$r6l$1@lisa.gemair.com>  * In article <3A74ABA4.8D15AC94@virgin.net>,' Alan Greig  <a.greig@virgin.net> wrote:0 >nK >Ok, I've watched the second Capellas speech now. Took about three hours ofoJ >video drops before I got there and he does mention VMS but...What he saidI >was that OpenVMS had a large installed base in healthcare and they would E >especially work to keep those accounts. They might try to expand the F >market but "there are reasons to be cautious. Especially in the first	 >quarter"C >rG >He pointedly did not, as I hear it, commit to anything solid about the H >future of VMS. He specifically said "there are reasons to be cautious".I >Perhaps lower than expected VMS sales are causing problems but I thought2; >they were up? Sounded like he was implying something more.@ >pH >The VMS mention was the very last item in his speech. Tagged on?  And IE >suspect he knew we were looking for a message. He told us "there are/J >reasons to be cautious". If VMS sales have plummeted then the decision to >retire it becomes easier. > G >It does sound as if Capellas might be convinced VMS could grow but theaK >majority of the rest of management want rid of it. In any case I think nowgH >is the time to make it as clear as possible to Compaq that we are happyI >with VMS and will continue to buy it but only if Compaq give us some fargK >more positive news. I really can't recommend a new installation right now. D >It reminds me of just before Alpha/NT was dropped. Doesn't mean theK >outcome will be the same but I think now *is* the time to make some noise.. >>I >Last year, based on strong assurances, I pushed for VMS on Alpha insteadaB >of just running the VAXes into the ground while moving to anotherJ >platform. Several European sites have migrated without problem and we areH >now looking at a much larger migration in the US. However our corporateK >head office (in Houston funnily enough) seems almost immune to any pro-VMShK >literature saying that we "don't see the big picture" and "that VMS reallyDH >does not have a future" Now there are also plenty of people arguing forI >the switch but right at the moment I'm not confident enough to be one of  >them. >   D If I've said anything to make people feel that I'm unsympathetic to C their problems selling VMS internally, let me make it clear tht I'ml not at all.c  A I've worked with management who disparage OpenVMS for the reasons A given above ("big picture", "VMS has no future").  I'm not askingC anyone to be unrealistic.n  ? I'm hoping someone inside Compaq will bring Mr. Greig's post tooA the attention of Compaq management at the highest levels.  If hiseC organization abandons VMS, there is absolutely no reason to believeO) that this could be a positive for Compaq.p  A One of the worst problems I see for OpenVMS, as I've said before,uD is the brain drain, good people finally being convinced that OpenVMSA has no future and moving on to work other fields.  Compaq may be iB spurring this along with their inattentiveness.  What Compaq mightD not recognize that the people they most need to keep involved in VMS> are the people who can read-between-the-lines most accurately.  > As Bill Todd points out, IBM has no problem selling Wintel ANDB AS/400, MVS, AIX aggressively.  Compaq should want to be more like# IBM and less like Dell and Gateway.h   >--s >Alan Greigr >l   -Jordan Henderson  jordan@greenapple.com    ------------------------------  # Date: Mon, 29 Jan 2001 02:51:27 GMT  From: sabolich@my-deja.com@ Subject: Re: VMS vs UNIX (was: Linux worm and RedHat 7.0 broken)) Message-ID: <952lrd$qon$1@nnrp1.deja.com>c  - In article <87lmrvpxen.fsf@prep.synonet.com>,i/   Paul Repacholi <prep@prep.synonet.com> wrote:e > sabolich@my-deja.com writes: >f > > >D5 > > > > >       status = lib$spawn('xyz','fds','fdf')1	 > > > > > E > > > > > We'll have to move the priority-change into xyz if we do it 	 this way,rC > > > > or wrap xyz in a little script to change the priority if we 
 don't want > > > > to change xyz. > > > >uG > > > > For my example to work I need sys$creprc and no wrapping xyz in  aR > > > > script.J > > > F > > > Perhaps not fair.  A script is certainly a way to combine simpleG > > >things to achieve a desired complex whole.  A moment ago, that wast a G > > >Good Thing.  Why would you not allow a script, if it happens to be: the > > > >right VMS tool?  Are you trying to start an argument? :-) > >b@ > > No argument wanted.  I think you misunderstood my intent.  I intended to E > > pick and example that lends itself to sys$creprc.  You may find al way toE > > skirt around sys$creprc with lib$spawn.  But there are times wheng youD4 > > have to use sys$creprc -- that is why it exists. > > F > > My intent is to show that I can construct a complex (high argument@ > > count) sys$whatever function with no Unix equivalent, with a
 collectionD > > of simple Unix functions.  In the end the complexity of the UnixA > > contruction is comparable to its VMS sys$whatever equivalent.o >nA > But, you CAN'T obtain equivalence with the unix calls! Create amE > High priority process on VMS and you have a well defined behaviour.cB > On unix, you are wide open to race conditions between the system@ > calls. Go and get a late set of RSX manuals and see the systemA > calls that where added to close some of the really obscure nits>A > in this sort of thing. Or do s lit search for stuff on priority> > inversion. >t > --> > Paul Repacholi                               1 Crescent Rd.,9 > +61 (08) 9257-1001                           Kalamunda.cB >                                              West Australia 60760 > Raw, Cooked or Well-done, it's all half baked. >      Sent via Deja.com  http://www.deja.com/   ------------------------------  # Date: Mon, 29 Jan 2001 03:43:40 GMT  From: sabolich@my-deja.com@ Subject: Re: VMS vs UNIX (was: Linux worm and RedHat 7.0 broken)) Message-ID: <952otb$t4d$1@nnrp1.deja.com>e  A > But, you CAN'T obtain equivalence with the unix calls! Create a-E > High priority process on VMS and you have a well defined behaviour. B > On unix, you are wide open to race conditions between the system@ > calls. Go and get a late set of RSX manuals and see the systemA > calls that where added to close some of the really obscure nitsqA > in this sort of thing. Or do s lit search for stuff on priority  > inversion. >  > --> > Paul Repacholi                               1 Crescent Rd.,   Sorry about that mispost.t  E You're right.  Instead of my example supporting my claim that you can @ obtain equivalence, it is a nice little _proof_ that you cannot.   Fran       Sent via Deja.com, http://www.deja.com/   ------------------------------  # Date: Mon, 29 Jan 2001 01:00:04 GMTe" From: fooguy <jweisen@my-deja.com>= Subject: Re: Volume Shadowing vs. RA7000 (WAS: DS20 Slow I/O)t) Message-ID: <952fai$lph$1@nnrp1.deja.com>o  " Good news! I am the Oracle DBA <G>  G Yeah, I'm well aware of the poor distribution of the data in the db, itn> was a flat file system that was put into Oracle, quite a mess.   Assume 6 database elements:e) -System Tablespace (Oracle System Tables)e4 -User Tablespaces ("The DB" including the big table) -Indexes
 -Redo Logs -Rollback Segments
 -Archive Logs-  G I posed the question in comp.database.oracle.misc months ago - which isH@ better: 6 mirrored pairs or 12 disks RAID 10, and the answer wasE unanimously RAID 10 because of that big table - need to throw as muchs  spindle speed at it as possible.  E So what you're telling me, is I can tell VMS "here are 12 disks, 6 onlF one channel, six on another, make them a RAID 10 set" and it will justG do it. That I've never heard, but I will read the attached link. Sounds B pretty good to me. If Vol Shadow and Bound Sets don't produce muchC overhead as you're saying they don't, then I'd want to pick two LVD H controllers and a 4254 since the I/O potential is over double (triple if2 they ever produce an Ultra 160 SCSI card for VMS).  + In article <sCvYVzy$Oynp@eisner.decus.org>,.-   young_r@eisner.decus.org (Rob Young) wrote:dH > In article <94v9es$905$1@nnrp1.deja.com>, fooguy <jweisen@my-deja.com> writes:eD > > Can you just define what you mean when you say "hot table", "hot disk".H > > Is that a member of the shadow set that is constantly pretty far our ofC > > sync? Are you recommending creating a software 10 disk RAID 10?i (bound > > vol set + mirrored pair) > >  >-? > 	When you speak about spreading Oracle across 10 mirror sets, = > 	you are talking about spreading Oracle's tables.  WARNING::= > 	I'm not an Oracle DBA nor do I pretend to mimic one.  I don= > 	know enough to be dangerous and I can do fulltext searchesn= > 	with the best of them.... here is what I am talking about:n > G > http://cma.zdnet.com/book/oracle/chapters/0-672-31159-3/ch20/ch20.htm  >iG > Do not cluster tables if full-table scans are often performed on only  one ofA > the tables in the cluster. The additional space required by thet cluster and theo% > additional I/O reduces performance.i >h@ > 	That is somewhat related.  Again, if you had a very hot table- > 	you may end up with a saturated mirrorset.n > @ > 	Your DBA should be able to show you how many tables you have.A > 	If you have 5 gigs of data, you may only have one table... but)B > 	that would be a poor design.  Maybe you have data broken out by? > 	year and are scanning data by year, maybe you have ten yearsu; > 	worth of data .. 10 tables.  Again, someone should know.  >iB > 	The software RAID 10 is not volume shadowing and bound members.B > 	It is stripes of single drives (RAID0) or stripes of shadowsetsC > 	(which makes it RAID10) OR host-based RAID5 (steer clear of thatg > 	one). > = > http://www.openvms.compaq.com/openvms/storage/raidpage.htmlv >n > 	It too has a loaner program.a >o: > 	Regarding recommending... using 10 disks and creating a> > 	RAID10 would be one way of going about it.  But if you have< > 	5-6 gigs of production data, it seems like quite a waste. However,A > 	it doesn't seem like you have a whole lot of time to step backiC > 	and evaluate.  I am just suggesting the RAID10 would most likelye? > 	spread the I/O and limit your exposure to I/O bottlenecks ifa? > 	one mirrorset is hotter than the others.  This may not be an ? > 	issue.  That is why it is important to gather I/O statistics ? > 	as you go.  But if what you are looking at has never been ine? > 	production, that's not feasible.  If however it has been and.A > 	now you are trying to improve it, the I/O stats would give you.= > 	a very clear understanding of what is hot and what is not.i >l	 > 				Robd > / > > In article <blP2q8lZgjEM@eisner.decus.org>,b1 > >   young_r@eisner.decus.org (Rob Young) wrote:n5 > >> In article <94usjg$vak$1@nnrp1.deja.com>, fooguy  <jweisen@my-deja.com>3 > > writes:r > >>C > >> > Ramdisk might not work know anyway, if we get the RA7000 I'm: goingp > > toG > >> > want to spread Oracle out over like 10 mirrored pairs (more if I  > > can...IiG > >> > think we quoted 18 disks, but if we attach both systems to the 1t > > cabinet G > >> > I can only access 12 disks on each machine). No way I can mirrorl > > that ins= > >> > Ram, although it still has to be cheaper than 10K$/MB.T > >>B > >> 	You may end up with a very hot table on one of your mirrored> > >> 	pairs.  You can use RAID Software for OpenVMS and create> > >> 	a host based 0+1 of maybe 5 stripes where each stripe is@ > >> 	a shadowset comprising two physical disks.  This gains youC > >> 	the advantage of spreading a hot table across mucho spindles.e> > >> 	That's why I was interested in just how hot your I/O is.D > >> 	Nice thing about the above , if you notice one of your stripesA > >> 	is getting hot, you can add a third member to that stripe'se > >> 	shadowset. > >>B > >> 	This is the software that folks with very hot I/O are using. > >> > >> 				Rob > >> > >> > >  > > --1 > > *********************************************:, > > "All I every wanted from life was to see0 > > Larry Wall give Bill Gates a Perl Necklace." > >  > >S > > Sent via Deja.comC > > http://www.deja.com/ >o   --- *********************************************i( "All I every wanted from life was to see, Larry Wall give Bill Gates a Perl Necklace."     Sent via Deja.comw http://www.deja.com/   ------------------------------  # Date: Mon, 29 Jan 2001 01:51:58 GMTr" From: fooguy <jweisen@my-deja.com>= Subject: Re: Volume Shadowing vs. RA7000 (WAS: DS20 Slow I/O) ) Message-ID: <952ibt$o1m$1@nnrp1.deja.com>m  E Taking a quick look, the most archive logs I see in one day are 225MB H worth. My assumption is that has to do with a billing update. On averageG though, I only see maybe 4 logs of 5MB. If you can propose a way for me-F to monitor just the writes on the VMS side (or if there is a statisticG you'd like to see), I will be happy to do that tomorrow and Tuesday and9G see what it looks like. I will check with some Oracle people and see iflD there is a data dictionary view I should be looking at to track I/O.  E The controller we're looking at in just a dumb SCSI controller, no WB F cache, but we are planning to shadow the disks across controllers (1/2E on Controller 1, 1/2 on Controller 2) to create a full duplex mirror.S  G I assume some amount of tuning can be done to VMS to control shadowing?c6 Is it just a matter of watch and tune, watch and tune?  + In article <tZ8xOPRhRzKe@eisner.decus.org>,u-   young_r@eisner.decus.org (Rob Young) wrote: F > In article <sCvYVzy$Oynp@eisner.decus.org>, young_r@eisner.decus.org (Rob Young) writes:t4 > > In article <94v9es$905$1@nnrp1.deja.com>, fooguy <jweisen@my-deja.com> writes:TE > >> Can you just define what you mean when you say "hot table", "hott disk".E > >> Is that a member of the shadow set that is constantly pretty fare our ofD > >> sync? Are you recommending creating a software 10 disk RAID 10? (bound > >> vol set + mirrored pair)  > >> >0 > 	Few other considerations... >i8 > 	With database tuning you can give Oracle a nice chunkB > 	of SGA for cache buffers, maybe a Gig (more?)  That - with your 5-6a? > 	Gigs of production data - might minimize the possiblities ofI? > 	hot spots.  Got to watch what I say... I've had to follow myO? > 	own posts and others correct me.  Hot spots may not be a bigs: > 	deal given your ratio of cache to data.  Second, if the
 controller(s)bC > 	(can't recall and am not familiar with the one you are using bute I do; > 	remember it doesn't support controller based RAID) don'ta? > 	contain write-back cache using Shadowsets with modest writestA > 	will bottleneck the shadowsets.  Meaning:  in HBVS (host based < > 	volume shadowing) both members must acknowledge the write@ > 	before I/O completion is acknowledge.  So a typical technique? > 	to bypass that "gotcha" is to use controllers with writebacko; > 	caching turned on the physical disks that are members ofI shadowsets.a> > 	To guard against catastrophic cache failure (it is rare butC > 	has happened), typically shadowsets are split across controllerst# > 	or better yet, controller pairs.t >n8 > 	In your case, if you had modest writes to one of your shadowsets,s< > 	that could buckle performance to that shadowset.  I had a	 situation @ > 	whereby I had controllers with shadowsets and the controllers didnB > 	not support writeback cache.  The performance was bad for a hotA > 	database with modest writes.  Would be nice to know your ratioa> > 	of reads to writes.  RAID10 will help with controllers that> > 	don't support writeback as you are striping across a number > 	of disks. > < > 	You can see why your vendor was/is trying to steer you to7 > 	HSZ technology.  The HSZs support writeback caching.w >rC > 	Our problem out here is we are seeing only a portion of what youp> > 	see.  That isn't a complaint, but the very real risk is our@ > 	advice would be imperfect if for no other reason than lack of@ > 	information.  Information exchange is often quite slow and at) > 	times difficult in a text based forum.w >h	 > 				Roba >h > >eA > > 	When you speak about spreading Oracle across 10 mirror sets, ? > > 	you are talking about spreading Oracle's tables.  WARNING:5? > > 	I'm not an Oracle DBA nor do I pretend to mimic one.  I do:? > > 	know enough to be dangerous and I can do fulltext searchesm? > > 	with the best of them.... here is what I am talking about:g > >g > >vE http://cma.zdnet.com/book/oracle/chapters/0-672-31159-3/ch20/ch20.htmw > >kD > > Do not cluster tables if full-table scans are often performed on only one of.C > > the tables in the cluster. The additional space required by theh cluster and thel' > > additional I/O reduces performance.t > >eB > > 	That is somewhat related.  Again, if you had a very hot table/ > > 	you may end up with a saturated mirrorset.H > >nB > > 	Your DBA should be able to show you how many tables you have.C > > 	If you have 5 gigs of data, you may only have one table... but.D > > 	that would be a poor design.  Maybe you have data broken out byA > > 	year and are scanning data by year, maybe you have ten years@= > > 	worth of data .. 10 tables.  Again, someone should know.g > >n > >dD > > 	The software RAID 10 is not volume shadowing and bound members.D > > 	It is stripes of single drives (RAID0) or stripes of shadowsetsE > > 	(which makes it RAID10) OR host-based RAID5 (steer clear of thata
 > > 	one). > >c? > > http://www.openvms.compaq.com/openvms/storage/raidpage.htmla > >d! > > 	It too has a loaner program.i > > < > > 	Regarding recommending... using 10 disks and creating a@ > > 	RAID10 would be one way of going about it.  But if you have> > > 	5-6 gigs of production data, it seems like quite a waste. However,C > > 	it doesn't seem like you have a whole lot of time to step back E > > 	and evaluate.  I am just suggesting the RAID10 would most likelymA > > 	spread the I/O and limit your exposure to I/O bottlenecks if A > > 	one mirrorset is hotter than the others.  This may not be an A > > 	issue.  That is why it is important to gather I/O statisticseA > > 	as you go.  But if what you are looking at has never been inlA > > 	production, that's not feasible.  If however it has been andHC > > 	now you are trying to improve it, the I/O stats would give your? > > 	a very clear understanding of what is hot and what is not.D > >e > > 				Robf > >"0 > >> In article <blP2q8lZgjEM@eisner.decus.org>,2 > >>   young_r@eisner.decus.org (Rob Young) wrote:6 > >>> In article <94usjg$vak$1@nnrp1.deja.com>, fooguy <jweisen@my-deja.com>  > >> writes: > >>>cD > >>> > Ramdisk might not work know anyway, if we get the RA7000 I'm goingo > >> tocH > >>> > want to spread Oracle out over like 10 mirrored pairs (more if I > >> can...IH > >>> > think we quoted 18 disks, but if we attach both systems to the 1 > >> cabinetH > >>> > I can only access 12 disks on each machine). No way I can mirror > >> that in> > >>> > Ram, although it still has to be cheaper than 10K$/MB. > >>>eC > >>> 	You may end up with a very hot table on one of your mirroredo? > >>> 	pairs.  You can use RAID Software for OpenVMS and createe? > >>> 	a host based 0+1 of maybe 5 stripes where each stripe isvA > >>> 	a shadowset comprising two physical disks.  This gains yousD > >>> 	the advantage of spreading a hot table across mucho spindles.? > >>> 	That's why I was interested in just how hot your I/O is. E > >>> 	Nice thing about the above , if you notice one of your stripestB > >>> 	is getting hot, you can add a third member to that stripe's > >>> 	shadowset.  > >>>XC > >>> 	This is the software that folks with very hot I/O are using.  > >>>d
 > >>> 				Rob- > >>>a > >>>r > >> > >> -- 2 > >> *********************************************- > >> "All I every wanted from life was to see11 > >> Larry Wall give Bill Gates a Perl Necklace."V > >> > >> > >> Sent via Deja.com > >> http://www.deja.com/  >2   --- *********************************************f( "All I every wanted from life was to see, Larry Wall give Bill Gates a Perl Necklace."     Sent via Deja.com  http://www.deja.com/   ------------------------------  # Date: Mon, 29 Jan 2001 02:01:19 GMTt" From: fooguy <jweisen@my-deja.com>= Subject: Re: Volume Shadowing vs. RA7000 (WAS: DS20 Slow I/O)t) Message-ID: <952itc$ofv$1@nnrp1.deja.com>   E I think our tests were broken too. Funny thing is, no one seems to beyE able to point out why. Not our VAR, not Compaq. I can't explain why IeG get those numbers. Trust me, I'd give anything for this config to be okg) so I can move on with my life already. =)m  F Do you see significant read performance improvement from the Ram disk?G Do the shadow set members need to be the same size? (Can I shadow 108MBr> of Disk to 3Gigs of Ram, even if there is only 2gigs of data?)  - In article <87puh7pyac.fsf@prep.synonet.com>,k/   Paul Repacholi <prep@prep.synonet.com> wrote:u& > fooguy <jweisen@my-deja.com> writes: >cC > > Really? Ramdisk as a Shadow Set Member? Can you or someone elses commentpH > > of the stability? I assume since on boot I'd have to put data in theH > > ram disk, it won't be the primary (what's the VMS term, "full copy >F > merge to"?) so how do I know it will get sufficient use? I mean, > >C will VMS know to read from that first because it has the lowest > >iG latency? In two years I've never had VMS crash on me, but what kind > > G of stability are we looking at? Am I going to be restoring a backup > >v if the OS bugchecksv) > > (in reality, I prob would be anyway).e >n? > Yep, Takes a bit of a fiddle, but once you have it set up, it H > is a doddle. Create your ram disk, and init it. ( not sure if the initC > is needed... ) Label it SCRATCH_DISK. mount the real disk(s) as a E > shadowset, without the ram disk. Add the Ramdisk. there is a switch H > added in one of the updatres that will require the added drive to haveD > the scratch_disk label.  Shoving the wrong drive into a shadow set8 > is probably THE instant death mistake on VMS today! :( > E > Don't forget that every byte of ramdisk, is less memory for orible.-B > If you can have the DB use that memory effectivly, then you win. > Talk to your DBA.u >cF > > Ramdisk might not work know anyway, if we get the RA7000 I'm goingG > > to want to spread Oracle out over like 10 mirrored pairs (more if IhF > > can...I think we quoted 18 disks, but if we attach both systems toG > > the 1 cabinet I can only access 12 disks on each machine). No way InD > > can mirror that in Ram, although it still has to be cheaper than > > 10K$/MB. > > H > > We just got a 30 day Vol Shadow license from DEC/Q to try it out andG > > see what the overhead it. I understand the concept, and I've done > B > some reading (I knew enough from the people here to know that itH > > does pretty well) but like you I don't have numbers (but I will by >
 > next week).c > >tH > > The tech at our VAR who didn't like soft raid admitted he knows very- > > little about VMS, so there is that there.w >dE > The config you mentioned seems to me to be way over the top... Plus:G > talking to DBA people ( I try to avoid that stuff ) the logs generalyw" > end up being the write hot spot.  C I agree, but what Oracle wants, Oracle gets. In fact, 12 disks is acD little light (I think the "Oracle" config for our installation wantsE like 27 disks). You should see how unhappy it is in a 5 Member RAID 5eE (and, to boot, this DB is so poorly designed). I am constantly tuningsF this thing, from what I understand is way beyond the norm of any otherG Oracle DB. For the size this thing is, it should never need tuning. ButiH hey, I despise SQL Server, so if I have to put up with it, I have to put up with it.d  ? > I still think that your original tests where broken, but fromaB > what you have posted, I can't point to anything and call it out.D > I know that I can read 13 1/2 K blocks, decompress them, and writeB > 49 1/2 K block out in under 7 sec. ( I think 5.4 sec wall is theA > usual time ) on a 400MHz 4100 with a single 960. Its a 6 memberhC > RAID set of RZ29s, not what I would consider optimal at all. Hell'( > of a way to make a 27Gb system disk... >yE > I fhave been wanting to get back to that machine and re-try some IOeB > tests and post them for you, but have not had the chance as yet.! > In the next day or two, I hope.c >< > --> > Paul Repacholi                               1 Crescent Rd.,9 > +61 (08) 9257-1001                           Kalamunda.gB >                                              West Australia 60760 > Raw, Cooked or Well-done, it's all half baked. >t   --- *********************************************t( "All I every wanted from life was to see, Larry Wall give Bill Gates a Perl Necklace."     Sent via Deja.comr http://www.deja.com/   ------------------------------  % Date: Mon, 29 Jan 2001 11:26:31 +1100e, From: Malcolm Wade <Malcolm.Wade@asx.com.au>0 Subject: RE: Writes flushed to Disk on Dismount?F Message-ID: <A8854B7F33E5D3119FDA00508B6A8C6334B18A@ASX235.asx.com.au>  B > From: young_r@eisner.decus.org [mailto:young_r@eisner.decus.org]* > Sent: Saturday, January 27, 2001 3:06 AM > To: Info-VAX@Mvb.Saic.Com02 > Subject: Re: Writes flushed to Disk on Dismount? >  > 7 > In article <3A719A97.6090803@wi.rr.com>, Scott Vieth   > <svieth@wi.rr.com> writes:@ > > My best guess is that if you had an application doing a ton 
 > of writes,   > > the controllers could cache,< > > a lot of blocks without having to start writing them to  > disk after 45  > > seconds.  By setting the: > > timeout to 64k second, you are telling the controller  > "Write these to # > > the disk when you get a chance.l' > > There's no hurry.  Take your time."b > >  > 7 > 	But this isn't accurate and which raised my initial  1 > 	thread.  What it really means is:  "hold theses6 > 	writes for 65K seconds before flushing"  of course,: > 	the reality is most of those get pushed out in a modest9 > 	write environment.  But during low I/O times one coulde= > 	imagine a write is in cache for a few hours before getting.
 > 	committed.w  I Is this really the case?  In my HSG80 V8.5 CLI reference manual it statesnF "Specifies how may seconds (1-65535) of idle time on a unit may elapseJ before the write-back cache flushes its entire contents to the idle units"  K My reading of this is that if you're constantly writing to disk it stays in L cache (until the cache is full obviously???) and only when the disk has beenF idle for CACHE_FLUSH_TIMER value does the cache get flushed.  This was confirmed to me by CPQ local.c  J If you shut your system down or dismount the disk, after CACHE_FLUSH_TIMER  time the cache will get flushed.  L I actually changed my value down to 1 second.  By my reading, pushing it outK to a large value doesn't make any sense; if you ain't using the disk; flush. the cache!    I Of course if you're really paranoid; before dismounting the shadow membersH issue a SET unit NOWRITEBACK_CACHE on the controller and turn it back on again on the unit later.  / Seems like we need a definitive answer from KB.n   Cheers,  Malcolmr   Malcolm J. Wade@2 Senior Systems Engineer, Australian Stock Exchange3 Level 3, 20 Bridge St, Sydney, NSW, 2000, Australiaa; PO Box H224, Australia Square, Sydney, NSW, 2000, Australia @ Tel: +61 2 9227 0263, Mobile: 0417 046 925, Fax: +61 2 9227 0023 Email: Malcolm.Wade@asx.com.au Web: http://www.asx.com/   ------------------------------   End of INFO-VAX 2001.057 ************************