1 INFO-VAX	Thu, 08 Nov 2001	Volume 2001 : Issue 621       Contents:< Beta version of PicoVAX (VAX emulator for Windows) available# Re: can't login to VAX on weekends.  Re: Compaq guarantees? Re: Compaq guarantees? Re: Compaq guarantees? Re: Compaq guarantees? Re: Compaq guarantees?% Re: Compaq's future (or lack thereof) $ Re: Compaq: VMS is alive and kicking$ Re: Compaq: VMS is alive and kicking$ Re: Compaq: VMS is alive and kicking$ Re: Compaq: VMS is alive and kicking$ Re: Compaq: VMS is alive and kicking$ Re: Compaq: VMS is alive and kicking$ Re: Compaq: VMS is alive and kicking$ Re: Compaq: VMS is alive and kicking$ Re: Compaq: VMS is alive and kicking$ Re: Compaq: VMS is alive and kicking$ Re: Compaq: VMS is alive and kicking Re: Comparison of defragmenters  Re: Disk Defragmenters Re: Disk Defragmenters Re: eco notices  Emacs-2[01] on VMS Re: Emacs-2[01] on VMS7 Re: Future Programming Platforms - Your Opinions Wanted 7 Re: Future Programming Platforms - Your Opinions Wanted 7 Re: Future Programming Platforms - Your Opinions Wanted 2 Re: Hewlett family votes "NO" on HP-Compaq merger!2 Re: Hewlett family votes "NO" on HP-Compaq merger!2 Re: Hewlett family votes "NO" on HP-Compaq merger!2 Re: Hewlett family votes "NO" on HP-Compaq merger!, Hey I'm Jessica  Com See Me Live 24/7, Free!; Re: Information about the files accessed by an application.  Infoserver 1000  Re: Infoserver 1000  Re: Infoserver 1000  Re: Infoserver 1000  Re: Infoserver 1000  Re: Infoserver 1000  InfoServer 1000, phase 2 Re: InfoServer 1000, phase 2 Re: Lost in MACRO  Re: Lost system password/ Re: network adapters of AXPpci 33 & OpenVMS 7.2  Re: NT/W2K CRSS exploit  ok I am back in my office  Re: ok I am back in my office  Re: ok I am back in my office 5 Re: OpenVMS Patch Mailing List in HTML --- eeeuuyech!  Re: OT - HP's MPE-IX Re: OT - HP's MPE-IX5 TNDRIVER gets wrong environment setting from VMS/Unix 9 Re: TNDRIVER gets wrong environment setting from VMS/Unix  Re: Undo disk Initialize Re: VT520 Setup  Re: VT520 Setup  RE: VT520 Setup # Re: Windows XP reality check please   F ----------------------------------------------------------------------  # Date: Wed, 07 Nov 2001 21:48:17 GMT * From: "Marc Chametzky" <marc@bluevine.net>E Subject: Beta version of PicoVAX (VAX emulator for Windows) available ( Message-ID: <3be9ab01@baja.bluevine.net>  G SRI has released a time-limited beta version of PicoVAX (their hobbyist 0 follow-on to Charon-VAX) on their hobbyist page:  A     http://www.softresint.com/softresint/charon-vax/hobbyist.html   ? Sure enough, I was able to install VMS V7.1 on it this morning.    --Marc   ------------------------------   Date: 7 Nov 2001 21:47:49 -0800 ) From: geoffrey.ive@eskom.co.za (geoffrey) , Subject: Re: can't login to VAX on weekends.= Message-ID: <6f7eb035.0111072147.10a38235@posting.google.com>   m vmendham@altavista.com (Vic Mendham) wrote in message news:<8b51ed8.0111060713.b137926@posting.google.com>... + > Ok I guess I need to be a little clearer.  > - > > >Is there a parameter in SYSGEN or SYSMAN  > > > which is set?  No : > > >Is there perhaps a lexical which could be used to setL > > > this? I know the welcome.txt is changed by the backup to state "backupA > > > running please login later", is there something to set like I > > > logins/inter= which would cause a system password to be required to  > > > login? > > > 0 > > > Please reply to victor.mendham@emergis.comD >Seeing you are using the LAT protocol between the Decserver and theA node, the >password prompt may come from LAT on that node. Within ? LATCP there is a >command latcp>set port/password and latcp>set B node/user_group, as you may be >using a different virtual port and user_group on weekends.  > > >One has to determine which equipment is issuing the password>E prompt.In your >port configuration on the Decserver it might be worth F your while to local> set >port verification enabled, then you will get2 the confirming message of >connecting to the node.
 Regards Geoff    ------------------------------  % Date: Wed, 07 Nov 2001 15:00:01 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>  Subject: Re: Compaq guarantees? , Message-ID: <3BE992C1.1B78EEC1@videotron.ca>   Bob Ceculski wrote: 0 > > Told ? Do you have anything on legal paper ? > K > we have all been told and promised that we would be supported ... the coe K > stuff has been thrown in our faces, i commited to vms and i expect compaq G > to live up to its promises to customers, if not, they will lose their  > credibility completely    I 1- Many customer had been told about commitments to Alpha for a very long 5 term. Compaq had no problems breaking that commitment   L 2- At a recent Compaq presentation where I live, twice, it was hinted to getM stuff on paper since HP would honour signed contracts. What does it say about K a company's honour when their sales critters tell customers to get stuff on  paper before the merger  ?  L It is reasonable to expect that VMS will continue to be maintained on Alpha.L It is also reasonable to expect a few more enhancements. Compaq/HP may ceaseN to sell/market VMS, but they'll continue to milk the customers for their money' and work to provide HP "upgrade" paths.   N However, it is one thing to believe that some expectatiosn are reasonable, andH another thing to believe in a commitment. That recent commitment" letter( specifically said one year for software.   ------------------------------   Date: 7 Nov 2001 16:06:14 -0800 ( From: bob@instantwhip.com (Bob Ceculski) Subject: Re: Compaq guarantees? = Message-ID: <d7791aa1.0111071606.10cc1e67@posting.google.com>   a JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3BE992C1.1B78EEC1@videotron.ca>...  > Bob Ceculski wrote: 2 > > > Told ? Do you have anything on legal paper ? > > M > > we have all been told and promised that we would be supported ... the coe M > > stuff has been thrown in our faces, i commited to vms and i expect compaq I > > to live up to its promises to customers, if not, they will lose their  > > credibility completely >  > K > 1- Many customer had been told about commitments to Alpha for a very long 7 > term. Compaq had no problems breaking that commitment  > N > 2- At a recent Compaq presentation where I live, twice, it was hinted to getO > stuff on paper since HP would honour signed contracts. What does it say about M > a company's honour when their sales critters tell customers to get stuff on  > paper before the merger  ? > N > It is reasonable to expect that VMS will continue to be maintained on Alpha.N > It is also reasonable to expect a few more enhancements. Compaq/HP may ceaseP > to sell/market VMS, but they'll continue to milk the customers for their money) > and work to provide HP "upgrade" paths.  > P > However, it is one thing to believe that some expectatiosn are reasonable, andJ > another thing to believe in a commitment. That recent commitment" letter* > specifically said one year for software.  L well if they try a one year software support, they better have lots of moneyL for lawyers as a major class action suit will come and we will be part of itL demanding every penny of our alpha and vms and vms software investment back!   ------------------------------  # Date: Thu, 08 Nov 2001 05:10:22 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net> Subject: Re: Compaq guarantees? < Message-ID: <2toG7.6099$6E2.2194306@typhoon.ne.mediaone.net>  A "John Malmberg" <Malmberg@dskwld.zko.dec.compaq> wrote in message . news:3BE71805.6010609@dskwld.zko.dec.compaq... > Terry C. Shannon wrote:  >  >  > > K > > I've asked the only legal type that I know (my kid, who won't become an L > > official Corporate Lawyer for another few months) about the ins and outs of9 > > Class Action Lawsuits and have yet to get a response.  >  > J > It would seem that one of the things taught at lawyer school is to avoidJ > giving out free legal advice to relatives and friends.  And the best way  > to stall at giving it out. :-) >   : Good. The kid apparently learned THAT lesson early on! ;-}   ------------------------------   Date: 8 Nov 2001 05:07:03 GMT & From: peter@abbnm.com (Peter da Silva) Subject: Re: Compaq guarantees? % Message-ID: <9sd3tn$qjh@web.nmti.com>   , In article <3BE992C1.1B78EEC1@videotron.ca>,/ JF Mezei  <jfmezei.spamnot@videotron.ca> wrote: N > It is reasonable to expect that VMS will continue to be maintained on Alpha.N > It is also reasonable to expect a few more enhancements. Compaq/HP may ceaseP > to sell/market VMS, but they'll continue to milk the customers for their money) > and work to provide HP "upgrade" paths.   1 Maybe Compaq may need VMS more than they thought:   G http://cbs.marketwatch.com/news/story.asp?column=TechWatch&siteid=mktw    G I hope Compaq can start up the EV8 development again. They may need to.    --  +  `-_-'   In hoc signo hack, Peter da Silva. E   'U`    "A well-rounded geek should be able to geek about anything." L                                                        -- nicolai@esperi.org          Disclaimer: WWFD?   ------------------------------  % Date: Thu, 08 Nov 2001 00:38:13 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>  Subject: Re: Compaq guarantees? , Message-ID: <3BEA1A41.BAAAA162@videotron.ca>   Peter da Silva wrote: 3 > Maybe Compaq may need VMS more than they thought: H > http://cbs.marketwatch.com/news/story.asp?column=TechWatch&siteid=mktwI > I hope Compaq can start up the EV8 development again. They may need to.   / You're putting logic where logic doesn't exist.   M Compaq announced that they would consolidate their current architectures from I Alpha+8086 to IA64+8086.  Prompted by Carly or not, compaq isn't about to = backtrack on their deal on becoming a pure wintel play again.   L To Compaq, this consolidation will save billions and make Compaq profitable.M Of course, they don't realise that this consolidation won't reduce the number  of architectures.   L They had NT, Unix and VMS on Alpha, with plans to move NSK to Alpha, as well as the desktops on 8086.  H Compaq didn't need to jump on the IA64 bandwagon since it had a superiorF product with Alpha. But Curly was too insecure and too focused on thisM quarter's bottom line to look into the future and take a big leap to position 7 Compaq as an industry leader instead of a Dell-wannabe.    ------------------------------   Date: 7 Nov 2001 20:16:00 GMT 1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) . Subject: Re: Compaq's future (or lack thereof)+ Message-ID: <9sc4q0$n9n$1@info.cs.uofs.edu>   3 In article <jIXlpXCplxVQ@eisner.encompasserve.org>, 0  koehler@encompasserve.org (Bob Koehler) writes:_ |> In article <3BE87817.60A53F50@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes:  |>  E |> > If the HP takeover of Compaq fails, what will happen of Compaq ?  |>  I |>    IMHO the Hewletts are right.  More exposure to the PC market is not I |>    most companies need right now.  HP should convince Compaq to split, F |>    buying the profitable lines and allowing the original PC company |>    to die a natural death.   H But if Compaq were to get out of the un-profitable PeeCee biz and decideG to build on it's profitable VMS/Alpha biz what would they need HP for??    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  # Date: Wed, 07 Nov 2001 19:14:31 GMT * From: "Bill Todd" <billtodd@metrocast.net>- Subject: Re: Compaq: VMS is alive and kicking C Message-ID: <rKfG7.165304$b47.17318550@bin3.nnrp.aus1.giganews.com>   0 Alan Greig <a.greig@virgin.net> wrote in message2 news:kp4iutcjqg80djrof35r9iut2bdd1c1eme@4ax.com...   ...   C > I'm puzzled by $300 million VMS annual development. Are there 300 G > people working for VMS engineering on $1 million a year or something? G > Or 50 on $6 million or what. Ok staffing isn't everything but what on E > earth has VMS engineering been doing with $ 300 million a year.  Or D > have we tagged all of the Alpha chip, systems etc design cost onto > VMS?  D My impression from when last this subject came up is that the numberC includes all layered-product development (compilers, etc.), release I engineering, etc.  The last number I heard for people actually working on F the OS was about 100 (including management and possibly people largely performing support functions).   - bill   ------------------------------  # Date: Wed, 07 Nov 2001 19:35:26 GMT * From: "Bill Todd" <billtodd@metrocast.net>- Subject: Re: Compaq: VMS is alive and kicking A Message-ID: <22gG7.92517$tb2.7287291@bin2.nnrp.aus1.giganews.com>   6 Rob Young <young_r@encompasserve.org> wrote in message- news:y2audeG4CLA+@eisner.encompasserve.org... K > In article <Ha4G7.161142$b47.16924032@bin3.nnrp.aus1.giganews.com>, "Bill & Todd" <billtodd@metrocast.net> writes: > > : > > Rob Young <young_r@encompasserve.org> wrote in message1 > > news:oYpTLxM4ZVJR@eisner.encompasserve.org...  > >  > > ...  > > D > >> But one of my main points can't be ignored.  Cross-architectureE > >> VMS clusters are common , adding another architecture isn't that  > >> difficult, nor costly,  > > J > > It may not be all that costly for *Compaq* to add the IPF architecture toD > > VMS's repertoire, but that cost will pale in comparison with the	 aggregate H > > cost across all ISVs and customers of porting their applications andK > > installations to it (unless most don't bother to).  If indeed there are L > > anything like 400,000 VMS installations, an average porting cost of just a K > > few hundred dollars would likely exceed Compaq's costs - and the *real* G > > average porting cost is much more likely to be at least a couple of  orders > > of magnitude higher. > >  > ; > So you wait until your Alphas run out of steam (if ever).   I Sounds like a better argument for choosing a vendor who won't cut off the L development flow to the platform you want than any kind of rationale for the! acceptance of a switch to Itanic.    ...   0 > >  and I suspect Itanium servers will be quite% > >> a bit cheaper than AlphaServers.  > > K > > I'm getting tired of hearing this garbage:  please analyze exactly what G > > server components will cost less (and how much) and compare it with  total * > > server cost before repeating it again. > >  > = > I guess you didn't even bother looking.  I'm not surprised.   K No, you just didn't bother understanding the sense of the comment.  And I'm  not surprised either.    > B > Itanium servers are quite a bit cheaper than AlphaServers today, > never mind the future.  I And you definitely get what you pay for.  My comment above was related to G comparing apples to apples (i.e., Compaq Alpha servers to Compaq Itanic ! servers of similar capabilities).    > D > Have you priced out 16 GBytes of memory for an AlphaServer lately?F > The memory is considerably more expensive for an AlphaServer.  I wasI > looking at 16 GBytes of AlphaServer memory... around $48000* U.S.  That E > same 16 GBytes of memory for a 4-way Itanium server is $25000 U.S.:   K This is called charging what the market will bear (Alphas unfortunately now L being a largely captive market not particularly subject to normal supply andI demand curves).  Although since there is *no* current market for Itanics, < their memory pricing could be considered somewhat arbitrary.   ...   B > What about quad processor?  If you load that Itanium box up with? > CPUs (4MByte L2 - top of the line at 800 MHz) you add a total F > of $20K to the cost.  That puts a quad Itanium server with 16 GBytesE > of RAM, 4 CPUs at $63K U.S.  The same config for an ES40 would most E > likely be in the neighborhood of $115K U.S.  ($48K* for memory, 27K E > base system, each processor add 13K.  I may be $10K low on the base  > system, but what's $10K ?).   L Let's rephrase that in terms of capabilities.  A quad-processor ES40/45 withE *well* over twice the memory bandwidth and processor performance of a H quad-processor Dell Itanic box costs less than twice as much, even afterL being gouged on the memory price.  And this is supposed to make the Itanic a significantly better deal?   - bill   ------------------------------   Date: 7 Nov 2001 14:13:42 -0600l+ From: young_r@encompasserve.org (Rob Young)e- Subject: Re: Compaq: VMS is alive and kickinge3 Message-ID: <T2FM9+edvTNK@eisner.encompasserve.org>p  n In article <22gG7.92517$tb2.7287291@bin2.nnrp.aus1.giganews.com>, "Bill Todd" <billtodd@metrocast.net> writes: >    >>C >> Itanium servers are quite a bit cheaper than AlphaServers today,e >> never mind the future.M > K > And you definitely get what you pay for.  My comment above was related toaI > comparing apples to apples (i.e., Compaq Alpha servers to Compaq Itanica# > servers of similar capabilities).a >   9 	Ah.... excellent tactic not unlike our British Champion.r  9 	But of course what you write above isn't the case at alla> 	as just in the prior post in reply to what I wrote you state:  . >  and I suspect Itanium servers will be quite# >> a bit cheaper than AlphaServers.g > I > I'm getting tired of hearing this garbage:  please analyze exactly whatnK > server components will cost less (and how much) and compare it with total ( > server cost before repeating it again. >   = 	There you are quite concerned about component costs.... so Iv# 	trot out component costs.  Hmmmmm.'  C 	Caught in a bind, so you ever so slightly change the argument.  It @ 	now becomes a matter of capabilities.  So... how do you measure 	that? ... bandwidth.  Sheesh.    	 			Later,    				Robv   ------------------------------  % Date: Wed, 07 Nov 2001 15:33:45 -05000- From: JF Mezei <jfmezei.spamnot@videotron.ca> - Subject: Re: Compaq: VMS is alive and kickingp, Message-ID: <3BE99AA6.9BE22DD0@videotron.ca>   Rob Young wrote:K          where it is a simple matter of moving the databases.  The cost foraM >         ISVs will be mostly trivial as it will involve a recompile and testP3 >         phase, more than made up on the back end.S  N Certifying an application is not trivial. Although VMS is now out of the fundsL transfer business, this was a good example of how much it costed to come outL with a new architecture that you were willing to garantee would work on yourN customer's platform. Customers wouldn't run it unless it was certified and theT vendor would garantee the software wouldn't lose a multi-million dollar transaction.  I >         platform.  My experience there is that the cost involved can bemJ >         astronomical and a nice chunk of customers - for all intents andJ >         purposes - are locked into VMS as it is very painful financially( >         to cut over to a "foreign" OS   L The above is true on its own. However, consider that many companies did moveL to another OS as the headed the call to abandon VMS in the 1990s. MigrationsF have happened. Now, you are asking companies to start a whole platform6 migration project that will cost customers some money.  M While such a migration will cost much less than a migration to another OS, ON6 ITS OWN, you have to consider:  M 	-most customers already have some other platform for their new applications,rN so migrating their remaining VMS apps to some flavour of Unix will alllow some" consolidation and save some costs.  J 	-everyone is very aware that Compaq has no intentions of marketing VMS. AC DII-COE commitment may provide support assurances for your existinghN configuration, but it doesn't garantee that VMS will gain the applications youN need to stay ahead of the pack. VMS may have a future, but its isn't "bright".  N 	-so, when you force the alpha-ia64 migration upon customers, you give them anN opportunity to compare the costs of other options as well. It is no longer theJ issue of comparing status quo with porting to Unix, but rather the cost of% migrating to IA64 vs porting to Unix.t 	eN 	-when customers put a price tag on the lack of bright future for VMS, and theA cost savings of dumping VMS to consolidate on their existing unix>K infrastructure, it may well turn out that the price difference of a port toe% unix vs migration t IA64 is worth it.-   ------------------------------  # Date: Wed, 07 Nov 2001 21:03:53 GMTr* From: "Bill Todd" <billtodd@metrocast.net>- Subject: Re: Compaq: VMS is alive and kicking @ Message-ID: <ZkhG7.90118$U7.7305726@bin1.nnrp.aus1.giganews.com>  6 Rob Young <young_r@encompasserve.org> wrote in message- news:T2FM9+edvTNK@eisner.encompasserve.org...rI > In article <22gG7.92517$tb2.7287291@bin2.nnrp.aus1.giganews.com>, "Billn& Todd" <billtodd@metrocast.net> writes: > >s >t > >>E > >> Itanium servers are quite a bit cheaper than AlphaServers today,M > >> never mind the future.o > >mJ > > And you definitely get what you pay for.  My comment above was related toK > > comparing apples to apples (i.e., Compaq Alpha servers to Compaq Itanich% > > servers of similar capabilities).o > >o >r: > Ah.... excellent tactic not unlike our British Champion.  I Stop being such an asshole, Rob.  Or if you persist, at least try to finde# something substantive to criticize.e   >a: > But of course what you write above isn't the case at all? > as just in the prior post in reply to what I wrote you state:  >s0 > >  and I suspect Itanium servers will be quite% > >> a bit cheaper than AlphaServers.r > > K > > I'm getting tired of hearing this garbage:  please analyze exactly whattG > > server components will cost less (and how much) and compare it withr totalo* > > server cost before repeating it again. > >s >w> > There you are quite concerned about component costs.... so I$ > trot out component costs.  Hmmmmm. >b@ > Caught in a bind, so you ever so slightly change the argument.  L No, you idiot:  I'm saying that the comparison at issue (*certainly* the oneH at issue as far as using VMS is concerned) is *Compaq* Itanic servers to# AlphaServers of similar capability.a     ItA > now becomes a matter of capabilities.  So... how do you measuret > that? ... bandwidth.  Sheesh.   F If you want to throw capability aside (though I suspect most customersE aren't that stupid), there's still the small problem that last time IiJ checked you couldn't buy *any* Itanic platform for anything near the price
 of a DS10.  H And you certainly haven't been inclined to set aside capabilities in theB past when comparing Alpha systems to, say, SPARC systems with moreK processors but less in the way of performance, so why are you so anxious tor
 this time?   - bill   ------------------------------   Date: 7 Nov 2001 15:34:56 -0600t+ From: young_r@encompasserve.org (Rob Young)e- Subject: Re: Compaq: VMS is alive and kickingt3 Message-ID: <vld2VbHKsA0P@eisner.encompasserve.org>   m In article <ZkhG7.90118$U7.7305726@bin1.nnrp.aus1.giganews.com>, "Bill Todd" <billtodd@metrocast.net> writes:o > H > If you want to throw capability aside (though I suspect most customersG > aren't that stupid), there's still the small problem that last time IoL > checked you couldn't buy *any* Itanic platform for anything near the price > of a DS10. >   < 	Ummmm.. how about if you want 16 GBytes of memory, have you 	made that comparison?    J > And you certainly haven't been inclined to set aside capabilities in theD > past when comparing Alpha systems to, say, SPARC systems with moreM > processors but less in the way of performance, so why are you so anxious to  > this time? >    	At your request.  Why else?   				Robo   ------------------------------   Date: 7 Nov 2001 15:21:11 -0600s+ From: young_r@encompasserve.org (Rob Young)d- Subject: Re: Compaq: VMS is alive and kickingz3 Message-ID: <P2vdnt59e7mS@eisner.encompasserve.org>0  \ In article <3BE99AA6.9BE22DD0@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Rob Young wrote:M >          where it is a simple matter of moving the databases.  The cost foroN >>         ISVs will be mostly trivial as it will involve a recompile and test4 >>         phase, more than made up on the back end. > P > Certifying an application is not trivial. Although VMS is now out of the fundsN > transfer business, this was a good example of how much it costed to come outN > with a new architecture that you were willing to garantee would work on yourP > customer's platform. Customers wouldn't run it unless it was certified and theV > vendor would garantee the software wouldn't lose a multi-million dollar transaction. > J >>         platform.  My experience there is that the cost involved can beK >>         astronomical and a nice chunk of customers - for all intents andlK >>         purposes - are locked into VMS as it is very painful financiallyy) >>         to cut over to a "foreign" OS o > N > The above is true on its own. However, consider that many companies did moveN > to another OS as the headed the call to abandon VMS in the 1990s. MigrationsH > have happened. Now, you are asking companies to start a whole platform8 > migration project that will cost customers some money. > O > While such a migration will cost much less than a migration to another OS, ONh  > ITS OWN, you have to consider: > O > 	-most customers already have some other platform for their new applications, P > so migrating their remaining VMS apps to some flavour of Unix will alllow some$ > consolidation and save some costs. > L > 	-everyone is very aware that Compaq has no intentions of marketing VMS. AE > DII-COE commitment may provide support assurances for your existingyP > configuration, but it doesn't garantee that VMS will gain the applications youP > need to stay ahead of the pack. VMS may have a future, but its isn't "bright". > P > 	-so, when you force the alpha-ia64 migration upon customers, you give them anP > opportunity to compare the costs of other options as well. It is no longer theL > issue of comparing status quo with porting to Unix, but rather the cost of' > migrating to IA64 vs porting to Unix.a > 	 P > 	-when customers put a price tag on the lack of bright future for VMS, and theC > cost savings of dumping VMS to consolidate on their existing unixeM > infrastructure, it may well turn out that the price difference of a port tot' > unix vs migration t IA64 is worth it.t    @ 	You are missing a very large picture of this puzzle.  ISVs thatA 	support VMS and have the same product running on other OSes varyaC 	in levels of VMS integration.  The case I am describing is whereby B 	the ISV's product has been running native on VMS for years, there> 	are internal system calls specific to VMS, there are multipleB 	custom scripts (DCL) making it *very* difficult (read: expensive)G 	to decouple from VMS.  Systems where planned downtime is something you9? 	fight for and it is rarely doled out in increments larger than.C 	4 hours.  The expense to go from VMS to another OS is high and the:A 	downsides are easy to forsee... you will introduce instability -.A 	count on it.  This same migration VAX to Alpha is transparent...mC 	all the OS calls are there, the scripts run unmodified.  Same willtC 	be said for transitioning to VMS-Itanium.  Sun lost few customers a7 	SunOS to Solaris and in some ways it was a lot uglier.   O > -so, when you force the alpha-ia64 migration upon customers, you give them and  E 	This won't happen, no more than it happened for VAX customers.  TheyeH 	are still riding those VAXes into the ground and for those applicationsB 	their migration path is Alpha.  It is too costly to cutover those= 	mission critical apps to foreign OSes.. unless of course youn	 	wish to:   , 			1)  Spend a lot more money in the process6 			2)  Introduce instability (at first) into a mission 			    critical environment   E 	It is much more logical to stay with VMS no matter how you slice it.M  = 	I know this is not too hard to believe but I know of someoneaF 	with a lot of money and wishes/wants to go to a foreign OS (strategicF 	direction) but they aren't that stupid.  Yes, stupid ... it will cost; 	them a lot of money and they will introduce a good deal of E 	short-term instability in a high profile application.  Few are that   	stupid.   				Robg   ------------------------------  # Date: Wed, 07 Nov 2001 22:24:09 GMTi* From: "Bill Todd" <billtodd@metrocast.net>- Subject: Re: Compaq: VMS is alive and kickingdA Message-ID: <dwiG7.49095$7x1.4546371@bin4.nnrp.aus1.giganews.com>l  6 Rob Young <young_r@encompasserve.org> wrote in message- news:P2vdnt59e7mS@eisner.encompasserve.org...a7 > In article <3BE99AA6.9BE22DD0@videotron.ca>, JF Mezeio& <jfmezei.spamnot@videotron.ca> writes:   ...e  I > > -so, when you force the alpha-ia64 migration upon customers, you given them anaG > > opportunity to compare the costs of other options as well. It is no 
 longer theK > > issue of comparing status quo with porting to Unix, but rather the costl of) > > migrating to IA64 vs porting to Unix.C > >:I > > -when customers put a price tag on the lack of bright future for VMS,a and theeE > > cost savings of dumping VMS to consolidate on their existing unixsL > > infrastructure, it may well turn out that the price difference of a port to) > > unix vs migration t IA64 is worth it.d >b >tA > You are missing a very large picture of this puzzle.  ISVs thatrB > support VMS and have the same product running on other OSes varyD > in levels of VMS integration.  The case I am describing is wherebyC > the ISV's product has been running native on VMS for years, there ? > are internal system calls specific to VMS, there are multiple C > custom scripts (DCL) making it *very* difficult (read: expensive)hH > to decouple from VMS.  Systems where planned downtime is something you@ > fight for and it is rarely doled out in increments larger thanD > 4 hours.  The expense to go from VMS to another OS is high and theB > downsides are easy to forsee... you will introduce instability -B > count on it.  This same migration VAX to Alpha is transparent...D > all the OS calls are there, the scripts run unmodified.  Same will+ > be said for transitioning to VMS-Itanium.   H The problem is, transitioning to another platform also has major upsidesI that simply migrating to VMS on Itanic does not.  At least it does unlessgF the ISV is planning on using his/her product as a cash cow in the sameG manner that Compaq uses VMS, in which case the ability to bleed captive H customers on a product that may not have any wider audience anyway could make sense.b  L For any other ISV (that doesn't already offer its product on other platformsL and thus have even less reason to bother migrating the VMS version), portingL to a vastly more popular platform may well make a great deal more sense thanD expending the effort to accommodate the portion of the shrinking VMS+ population that may wish to move to Itanic.t   - bill   ------------------------------  # Date: Wed, 07 Nov 2001 22:36:01 GMT * From: "Bill Todd" <billtodd@metrocast.net>- Subject: Re: Compaq: VMS is alive and kickingoA Message-ID: <lHiG7.92914$tb2.7408976@bin2.nnrp.aus1.giganews.com>   6 Rob Young <young_r@encompasserve.org> wrote in message- news:vld2VbHKsA0P@eisner.encompasserve.org...eH > In article <ZkhG7.90118$U7.7305726@bin1.nnrp.aus1.giganews.com>, "Bill& Todd" <billtodd@metrocast.net> writes: > >eJ > > If you want to throw capability aside (though I suspect most customersI > > aren't that stupid), there's still the small problem that last time IaH > > checked you couldn't buy *any* Itanic platform for anything near the price  > > of a DS10. > >  > = > Ummmm.. how about if you want 16 GBytes of memory, have your > made that comparison?r  K Unless there's something really special about Alpha memory, that expense ispK simple price-gouging and has nothing to do with the *ability* to compete onr price.   >y >lL > > And you certainly haven't been inclined to set aside capabilities in theF > > past when comparing Alpha systems to, say, SPARC systems with moreL > > processors but less in the way of performance, so why are you so anxious to > > this time? > >n >e > At your request.  Why else?4  E Since my previous contributions to this thread have included thorough0J descriptions of Itanic's inability to compete on per-processor performanceL with Alpha for *at least* the next 3 years (and its ability to compete afterI that point is by no means clear, since it will depend on exactly what thecE yet-unspecified new Alpha-team-inspired changes may be), and includedoI specific observations on Itanic's disadvantages in terms of EV7's on-chipdH glue features and the resulting difficulty of competing in both absoluteJ performance and cost/performance, it really should have been clear that myL discussion of component prices referred to components of similar capability.H After all, if all you want is a 4-processor box without reference to itsI capability or quality, you can get IA32-based SMPs (and commodity memory)aJ for a great deal less than anything we've talked about here - but so what?   - bill   ------------------------------  % Date: Wed, 07 Nov 2001 19:08:16 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>s- Subject: Re: Compaq: VMS is alive and kickingc, Message-ID: <3BE9CCEC.6CB21A69@videotron.ca>   Rob Young wrote:I >         You are missing a very large picture of this puzzle.  ISVs thataJ >         support VMS and have the same product running on other OSes vary' >         in levels of VMS integration.>  J We're not talking about shrinkwrapped software for what is left of the VMSK marketplace. And even if an ISV does go through the trouble of migrating to I IA64 and doing the testing to certify it, the customers will still need aiG fairly elaborate migration plan that will last some time with their own D testing, parralel runs and eventual switching from one to the other.  J Remember that IA64 brings nothing of value compared to Alpha as far as theJ customers are concerned. Customers are being forced into these unnecessary; expenses just to please Mike Winkler, Andy Grove and Carly.   K >         the ISV's product has been running native on VMS for years, therecG >         are internal system calls specific to VMS, there are multiplevK >         custom scripts (DCL) making it *very* difficult (read: expensive)i  >         to decouple from VMS.   K But since there now exists 3rd party packages on other systems that are the M "industry standard", then all your proprietary stuff is somewhat moot. If theoM package on unix offers the same/more functionality than your in-house system, M then you need not concern yourself about porting your in-house scripts in DCLh  or other VMS specific utilities.  H >         fight for and it is rarely doled out in increments larger than >         4 hours.    I But that applies equally to a Alpha-IA64 migration as it would a VMS-UNIXaK migration. You need to setup and test the new system in parralel and at onec" point, cut over to the new system.  J It is true that with VMS clustering, the cutover can be almost transparent with proper use of clustering.  < >		 The expense to go from VMS to another OS is high and theJ >         downsides are easy to forsee... you will introduce instability - >         count on it.  N But management will be happy to finally dump an unpopular platform and move to" a popular and mainstream solution.    L >         all the OS calls are there, the scripts run unmodified.  Same will3 >         be said for transitioning to VMS-Itanium.,  K Only for user mode applications, remember. But consider just changes to therL console. This requires that you develop new procedures and documentation forN the operators. Being able to compile an application transparently is neat, but0 it is only a small portion of the whole picture.  K You have to consider the security and stability implications of having that L new IA64 box join your existing production cluster , especially if you'll beE playing around with it to test it out, test the applicatiosn etc etc.,  K In some organisations, it isnb't enough to just plug it in and boot it, youcG have to prove to a commitee that this project and the way you intend toi( implement it will not affect production.  K This is why sometimes keeping your test machine totally separate is easier.o  N >         This won't happen, no more than it happened for VAX customers.  TheyQ >         are still riding those VAXes into the ground and for those applicationsxK >         their migration path is Alpha.  It is too costly to cutover thoseoF >         mission critical apps to foreign OSes.. unless of course you    N Lets see. During the 1990s, how much market share and customers did VMS lose ?M Just look at the exit from messaging where Digital used to be THE leader. ThehM lack of migration path for Message Router to Alpha was one of the big reasonssM for the start of the decline. Some stayed and went with PMDF, and many othersnK just dumped that architecture and went with a different vendor alltogether.   I So while on paper the VAX to ALPHA should have been easy, there were someiM details which made it troublesome for many. Those details were not technical, 8 they were business practices, Digital decisions etc etc.  I So while the engineers may do a nice job and allow easy recompiles, it iseM still not a given that the transition will be easy for many customers. It all.F depends on whether *ALL* products are migrated, even the ones that are officially "dead".  L Consider a shop that depends extensively on display postscript. They are nowL frozen at 7.2. Will you post display postscript and VMS 7.2 to IA64 to allow them to migrate ?y  > What other middleware products will not make it over to IA64 ?    N >         It is much more logical to stay with VMS no matter how you slice it.    N If there were no second guessing of Compaq's commitment to VMS, I would agree.L But the fact that VMS' future is not exactly certain will force customers toM consider whether it would be wise to take that opportunity to migrate off VMS  once and for all.r  O >         direction) but they aren't that stupid.  Yes, stupid ... it will costhD >         them a lot of money and they will introduce a good deal of@ >         short-term instability in a high profile application.     N But once a corporation decides to de-emphasize VMS on the long term and buildsJ new stuff on another platform, then that issue becomes less stupid. But itD also means that that company won't bother with that silly Alpha-IA64M migration, they'll keep their old Alphas because as they move applications tolZ newer platforms, it gives the Alpha room to grow processing on the remaining applications.   ------------------------------   Date: 7 Nov 2001 20:23:36 -0600i+ From: young_r@encompasserve.org (Rob Young)l- Subject: Re: Compaq: VMS is alive and kickingr3 Message-ID: <4gXb8drfEOKr@eisner.encompasserve.org>r  \ In article <3BE9CCEC.6CB21A69@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Rob Young wrote:J >>         You are missing a very large picture of this puzzle.  ISVs thatK >>         support VMS and have the same product running on other OSes varyt( >>         in levels of VMS integration. > L > We're not talking about shrinkwrapped software for what is left of the VMS > marketplace. t  B 	Ahem... as Fred points out this piddling VMS marketplace that youB 	refer to is actually quite a bit larger than the NSK market.  YouF 	can't come to grips with the size of it , can you?  And if it shrunk,B 	it is still a very sizable corporation if standalone.  Don't talk> 	about "what is left of it", it doesn't elevate your position.  > And even if an ISV does go through the trouble of migrating toK > IA64 and doing the testing to certify it, the customers will still need a I > fairly elaborate migration plan that will last some time with their ownqF > testing, parralel runs and eventual switching from one to the other. >   < 	Nonsense.  Having been involved in quite a few VAX to Alpha2 	migrations, "elaborate" has never been a keyword.  L > Remember that IA64 brings nothing of value compared to Alpha as far as theL > customers are concerned. Customers are being forced into these unnecessary= > expenses just to please Mike Winkler, Andy Grove and Carly.t >   E 	No more than Alpha brings to VAX.  If your current VAX configurationlB 	is delivering the goods, why come off it?  One of my vehicles hasC 	172000 miles on it, I drove it to New Hampshire last year.  I tirehD 	of it, but it has been rock solid for the 11 years I have owned it.A 	No intention of getting rid of it... same could be said for manyrA 	VAX installations today.  However, parts may be an issue for thes@ 	VAX and me in a few years and I probably would be best to ditch< 	my vehicle.  Easy migration path for me.  Maybe not so easy. 	for all VAX owners, but fairly easy for many.  L >>         the ISV's product has been running native on VMS for years, thereH >>         are internal system calls specific to VMS, there are multipleL >>         custom scripts (DCL) making it *very* difficult (read: expensive)! >>         to decouple from VMS.   > M > But since there now exists 3rd party packages on other systems that are theaO > "industry standard", then all your proprietary stuff is somewhat moot. If thehO > package on unix offers the same/more functionality than your in-house system,jO > then you need not concern yourself about porting your in-house scripts in DCLm" > or other VMS specific utilities. >   C 	Sure.  You have to rewrite those non-standard scripts in somethinghB 	other than DCL.  Those native VMS calls can be a very nasty thingA 	to come away from and require porting and or rotorooting of your C 	code to get them to Unix.  As mentioned before, none of that comest 	into play VAX->Alpha.  I >>         fight for and it is rarely doled out in increments larger than  >>         4 hours.  > K > But that applies equally to a Alpha-IA64 migration as it would a VMS-UNIX M > migration. You need to setup and test the new system in parralel and at one $ > point, cut over to the new system. >   C 	Yes, but as mentioned earlier the exposure is mostly non-existent.eC 	Remember VMS is VMS is VMS.  Secondly, to cut those databases overaB 	to Alpha from VAX is very rapid.  You will need a *ton* more timeF 	to get them to Unix from VAX.  Not a big secret here... plug an AlphaF 	into the existing VAX cluster and suck them across.  Most likely willC 	require 4-5 times the amount of time to get data to Unix from VAX.t4 	(i.e. vast majority of VAXes are 10Mbit networked).  L > It is true that with VMS clustering, the cutover can be almost transparent  > with proper use of clustering. >   C 	Or in my case VAX to Alpha cluster change out overnight.  Piece of  	cake.  = >>		 The expense to go from VMS to another OS is high and theVK >>         downsides are easy to forsee... you will introduce instability -t >>         count on it.  > P > But management will be happy to finally dump an unpopular platform and move to$ > a popular and mainstream solution. >  > M >>         all the OS calls are there, the scripts run unmodified.  Same willt4 >>         be said for transitioning to VMS-Itanium. > M > Only for user mode applications, remember. But consider just changes to the N > console. This requires that you develop new procedures and documentation forP > the operators. Being able to compile an application transparently is neat, but2 > it is only a small portion of the whole picture. >    	No changes.  VMS is VMS.n  M > You have to consider the security and stability implications of having thatnN > new IA64 box join your existing production cluster , especially if you'll beG > playing around with it to test it out, test the applicatiosn etc etc.n > M > In some organisations, it isnb't enough to just plug it in and boot it, youcI > have to prove to a commitee that this project and the way you intend ton* > implement it will not affect production. >   = 	Yes.  I didn't say it was free.  Thorough testing is a must.i  M > This is why sometimes keeping your test machine totally separate is easier.m > O >>         This won't happen, no more than it happened for VAX customers.  TheyeR >>         are still riding those VAXes into the ground and for those applicationsL >>         their migration path is Alpha.  It is too costly to cutover thoseG >>         mission critical apps to foreign OSes.. unless of course you  >  > P > Lets see. During the 1990s, how much market share and customers did VMS lose ?O > Just look at the exit from messaging where Digital used to be THE leader. The@O > lack of migration path for Message Router to Alpha was one of the big reasons7O > for the start of the decline. Some stayed and went with PMDF, and many othersrM > just dumped that architecture and went with a different vendor alltogether.a > K > So while on paper the VAX to ALPHA should have been easy, there were some>O > details which made it troublesome for many. Those details were not technical,r: > they were business practices, Digital decisions etc etc. > K > So while the engineers may do a nice job and allow easy recompiles, it isuO > still not a given that the transition will be easy for many customers. It allgH > depends on whether *ALL* products are migrated, even the ones that are > officially "dead". > N > Consider a shop that depends extensively on display postscript. They are nowN > frozen at 7.2. Will you post display postscript and VMS 7.2 to IA64 to allow > them to migrate ?  > @ > What other middleware products will not make it over to IA64 ? >  > O >>         It is much more logical to stay with VMS no matter how you slice it.a >  > P > If there were no second guessing of Compaq's commitment to VMS, I would agree.N > But the fact that VMS' future is not exactly certain will force customers toO > consider whether it would be wise to take that opportunity to migrate off VMSi > once and for all.i > P >>         direction) but they aren't that stupid.  Yes, stupid ... it will costE >>         them a lot of money and they will introduce a good deal of A >>         short-term instability in a high profile application. e >  > P > But once a corporation decides to de-emphasize VMS on the long term and buildsL > new stuff on another platform, then that issue becomes less stupid. But itF > also means that that company won't bother with that silly Alpha-IA64O > migration, they'll keep their old Alphas because as they move applications tot\ > newer platforms, it gives the Alpha room to grow processing on the remaining applications.    ; 	You say that.  But I am talking about production databasespE 	-mostly wed to VMS-.  Rare?  Maybe not so rare as you would guess.  aG 	The only migration upside is you have your OS strategy lined up.  The  G 	downside is big bucks spent in the cutover and definite instability.  fD 	The kind of thing that costs people jobs and the risk most of them  	wisely forego.a   				Robe   ------------------------------   Date: 08 Nov 2001 00:35:18 GMT' From: "Jim Strehlow" <jims@data911.com> ( Subject: Re: Comparison of defragmenters0 Message-ID: <9sck06$262@dispatch.concentric.net>  7 Several clients of ours use diskeeper. It does its job. E I do not have a comparison of it versus other defragmenting products.   / Be careful when going to ODS-5 disks to not use0> versions of defragmenting software that do not properly handle& the extended file name specifications.  - Jim Strehlow, Data911.com / sunviewMobile.come Alameda, CA$    5 "Nic Clews" <sendspamhere@127.0.0.1> wrote in messaget! news:3BE9661D.650C07@127.0.0.1...  ...y8 > Someone asked about DFO vs. PerfectDisk vs. Diskeeper. > I have not used DFO. >tF > I traded up from an _early_ version of Diskeeper to Perfectdisk, for > this main reason:I >iA > Perfectdisk has a defragmenting methodology which helps prevent E > fragmentation. Firstly old files (not often accessed) end up at thetC > edges of the disk (most head movement, less likely to be accessedhH > 'regularly', or deleted leaving a 'hole'), more often accesed file areI > placed centre and slight off centre (less head movement, more likely toeJ > be deleted, but 'holes' closer together), a volatile area where recentlyE > created and perhaps soon to be deleted files (holes) will be, and a I > reasonably consolidated lump of free space, the volatile and free areas  > being more or less central.  >eG > For this reason, I find you can run Perfectdisk less often (thereforeg > less CPU). >oF > This is just my opinion which may or may not help you to a decision! > --* > Regards, Nic Clews CSC Computer Sciences > nclews at csc dot comi   ------------------------------  # Date: Wed, 07 Nov 2001 21:51:01 GMTn) From: martin.hunt@inl.co.nz (Martin Hunt)a Subject: Re: Disk Defragmenterss8 Message-ID: <3be9a6df.265653479@news.wlg.netlink.net.nz>  C On 6 Nov 2001 22:11:25 -0600, young_r@encompasserve.org (Rob Young)b wrote:  e >In article <3be8a5e4.199870047@news.wlg.netlink.net.nz>, martin.hunt@inl.co.nz (Martin Hunt) writes:sG >> Has anyone had any experience with Compaq's DFO product? I have usedtG >> both Diskeeper and PerfectDisk, but don't know anything about DFO. IuI >> am currently looking at which product would be suitable for some VAXesn6 >> which is currently not running any defrag software. >>  E >> Any information, such as CPU utilisation, performance, and general , >> philosophy of operation, would be useful. >> u >cI >I've used all three and am currenlty using DFO.  Ever since the MOVEFILEdC >primitive showed up defraggers have been pretty reliable.  The DFOeF >SCRIPT takes a bit of getting used to, but like most VMS stuff followF >the examples and you will be okay.  It supports exclusions, etc.  All >and all it works well.a  E Does it have good analysis tools and logging? I quite like Diskeeper,cD as you can select the level of logging to be as extensive as loggingC every file move (including the LBNs before and after), down to just B giving a summary at the end of a pass. It also has a good analysis5 tool which permits just about any level of reporting.   C PerfectDisk seems to be more secretive about what it has been doingmF (although I may have just not discovered the right qualifiers yet). ItE prints a summary every half hour of how many files it has moved. They < seemed obsessed with the disk optimisation (rather than justF defragmentation) and doing everything in a single pass (I really can'tB see how doing things in one pass is any better than using 2 or 3).> Yesterday I set up a test disk (using a command file I createdF fragmented files of various sizes), and ran PerfectDisk. It ran for 18> hours, and the disk was more fragmented when it finished! ThisD included there being a large number of multi-header files which were not there when it started.  D I have just run it on a disk which had been fragmented during normalD operation and was only a little fragmented (400 files out of 33,000)C and about 8% free space. It reduced the number of fragmented files,eB but again made some files more fragmented or multi-header. I wouldD hardly call that a good job. It ran for just over an hour. There was no other activity on the disk.  B And now the questions - does DFO tell you what it is up to, is theE disk close to being toally defragmented when it is finished, and does 7 it have good tools for reporting the state of the disk?n     ---i Martin Hunte Systems Administratorr Independent Newspapers Limited
 Wellington New Zealand    ------------------------------   Date: 7 Nov 2001 16:14:31 -0600 + From: young_r@encompasserve.org (Rob Young)  Subject: Re: Disk Defragmenters 3 Message-ID: <VqnPCxdhS54m@eisner.encompasserve.org>i  d In article <3be9a6df.265653479@news.wlg.netlink.net.nz>, martin.hunt@inl.co.nz (Martin Hunt) writes:E > On 6 Nov 2001 22:11:25 -0600, young_r@encompasserve.org (Rob Young)a > wrote: > f >>In article <3be8a5e4.199870047@news.wlg.netlink.net.nz>, martin.hunt@inl.co.nz (Martin Hunt) writes:H >>> Has anyone had any experience with Compaq's DFO product? I have usedH >>> both Diskeeper and PerfectDisk, but don't know anything about DFO. IJ >>> am currently looking at which product would be suitable for some VAXes7 >>> which is currently not running any defrag software.n >>> F >>> Any information, such as CPU utilisation, performance, and general- >>> philosophy of operation, would be useful.t >>>  >>  5 	Just a nit... but watch attribution... I wrote this:t  J >>I've used all three and am currenlty using DFO.  Ever since the MOVEFILED >>primitive showed up defraggers have been pretty reliable.  The DFOG >>SCRIPT takes a bit of getting used to, but like most VMS stuff followhG >>the examples and you will be okay.  It supports exclusions, etc.  Alll >>and all it works well. > G > Does it have good analysis tools and logging? I quite like Diskeeper,oF > as you can select the level of logging to be as extensive as loggingE > every file move (including the LBNs before and after), down to justlD > giving a summary at the end of a pass. It also has a good analysis7 > tool which permits just about any level of reporting.t >   4 	Yeah, PD may be more wizbang.  DFO does okay by me:  ) DFO> show sys$sysdevice:/volume/histogram   ;                    F r a g m e n t a t i o n    R e p o r to  D DISK$CHOPSYS                                              7-NOV-2001 17:08:04.96    The fragmentation index is 44.0c       1 - 20.9 is excellentt      21 - 40.9 is good      41 - 60.9 is fair      61 - 80.9 is poor/      81 - 100 indicates a badly fragmented disk F Approximately 24.0 (out of 80.0 possible) is due to file fragmentationK Approximately 20.0 (out of 20.0 possible) is due to freespace fragmentationl     Freespace Summary:.         Total free space:       1903518 blocks1         Percentage free:             22 (rounded)s'         Total free extents:         246l<         Maximum free extent:      89469 blocks, LBN: 3232179<         Minimum free extent:          9 blocks, LBN: 5127372.         Average free extent:       7737 blocks.         Median free extent:          63 blocks   File Fragmentation Summary:g6         Number of files (with some allocation):  142356         Total file extents on the disk:          167039         Average number of file extents per file: 1.173375d2         Median number of file extents per file:  1     Most Fragmented File:.9         [SYS5.SYSEXE]TNT$SERVER_ERROR.LOG;1 (307 extents)     D            F i l e    F r a g m e n t a t i o n    H i s t o g r a m   Extent Count  ------            |  11 To 307 |  (24)          7 |  (7)           6 |  (13)          5 |  (20)          4 |  (41)          3 |  (204)           2 | * (292)0          1 | *************************** (13634)0            +------------------------------------:             Number of files with a given number of extents-               Each * corresponds to 500 filest  E > PerfectDisk seems to be more secretive about what it has been doingoH > (although I may have just not discovered the right qualifiers yet). ItG > prints a summary every half hour of how many files it has moved. Theyn> > seemed obsessed with the disk optimisation (rather than justH > defragmentation) and doing everything in a single pass (I really can'tD > see how doing things in one pass is any better than using 2 or 3).@ > Yesterday I set up a test disk (using a command file I createdH > fragmented files of various sizes), and ran PerfectDisk. It ran for 18@ > hours, and the disk was more fragmented when it finished! ThisF > included there being a large number of multi-header files which were > not there when it started. > F > I have just run it on a disk which had been fragmented during normalF > operation and was only a little fragmented (400 files out of 33,000)E > and about 8% free space. It reduced the number of fragmented files,oD > but again made some files more fragmented or multi-header. I wouldF > hardly call that a good job. It ran for just over an hour. There was  > no other activity on the disk. > D > And now the questions - does DFO tell you what it is up to, is theG > disk close to being toally defragmented when it is finished, and doesh9 > it have good tools for reporting the state of the disk?  >   * 	Yes... for the most part... it is decent:    >            The following are examples of invoking the monitor:  2          1.$ DEFRAGMENT MONITOR MY_SCRIPT/NOVOLUME  J            In this example, the monitor function displays ongoing run-timeI            statistics for the defragmentation process associated with MY_tH            SCRIPT. It also displays an approximate free-space map of theH            target volume. The display continues until interrupted with aI            Ctrl/C, Ctrl/Y, or Ctrl/Z because the /CONTINUOUS qualifier ise            present by default.   				Robf   ------------------------------  # Date: Wed, 07 Nov 2001 19:05:53 GMTd2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: eco notices3 Message-ID: <lCfG7.1375$RL6.34094@news.cpqcorp.net>m  f In article <Gy1G7.30112$zK1.8493036@typhoon.tampabay.rr.com>, "john nixon" <jnixon@cfl.rr.com> writes:H :Is anyone else getting deluged with eco notices from "system PRIVILEGEDL :account" that are apparently in HTML code instead of text?  I have received9 :several of them tonight.  It is kind of ironic actually.v  J   Folks here at Compaq are looking at this -- something (quite obviously) 2   glitched in the ECO mail generation mechanisms.   N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------    Date: 07 Nov 2001 15:21:32 -0500R From: "Stefan Monnier <foo@acm.com>" <monnier+comp.os.vms/news/@flint.cs.yale.edu> Subject: Emacs-2[01] on VMSe, Message-ID: <5lr8rafi2b.fsf@rum.cs.yale.edu>  H Has anybody worked on the VMS port of Emacs to get a more recent version than 19.28 working ?8 Would anybody be interested in porting Emacs-21 to VMS ?     	Stefanl   ------------------------------  $ Date: Wed, 7 Nov 2001 22:38:17 +0100. From: "Jesper Naur" <jesper.naur@post.tele.dk> Subject: Re: Emacs-2[01] on VMSs= Message-ID: <3be9a99a$0$25397$edfadb0f@dspool01.news.tele.dk>l  J Stefan Monnier <foo@acm.com> <monnier+comp.os.vms/news/@flint.cs.yale.edu>7 wrote in message news:5lr8rafi2b.fsf@rum.cs.yale.edu...dJ > Has anybody worked on the VMS port of Emacs to get a more recent version > than 19.28 working ?: > Would anybody be interested in porting Emacs-21 to VMS ?  5 There was some attempt getting something started, seeU  F http://www.xray.mpe.mpg.de/mailing-lists/vmsperl/2000-02/msg00293.html  3 and related responses. How far it got - have a look        Best regards     Jesper Naur    ------------------------------  % Date: Wed, 07 Nov 2001 20:13:32 +0100g= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>o@ Subject: Re: Future Programming Platforms - Your Opinions Wanted) Message-ID: <3BE987DC.D924AA67@gtech.com>    John Eisenschmidt wrote:@ > Java is an interesting language for a few reasons: the obvious7 > fact that it's OOP based, and that it's pointer-less.   > I would phrase it as "the programmer can not access pointers".< All objects in Java have the functionality of a pointer. The< programmer are just not allowed to do something "dirty" with them  ? >                                                        But it < > also includes a boat load of libraries (for it's age, it's= > astounding that has almost as many as C and C++). You don'tn; > have to use all those libraries (the base language itself 1 > doesn't include anything more than C/C++ does).    ????  B I would estimate that the Java API are about more than a 100 times bigger< than ANSI C ! Probably also almost as big as ANSI C++ (but I: do not know the ANSI C++ good enough to state it as fact).   Arne   ------------------------------  % Date: Wed, 07 Nov 2001 14:35:58 -0500 - From: "John Eisenschmidt" <jeisensc@aaas.org>a@ Subject: Re: Future Programming Platforms - Your Opinions Wanted+ Message-ID: <sbe946e7.078@AAASMTA.aaas.org>t  H Are we talking about what you have to use or what you have to work with?  H As far as what you have to use, Java is as minimal as C. Look at Hello = World in Java:   public class HelloWorld { ,   public static void main( String Args[] ) {+     System.out.println( "Hello World!\n" );m+     System.exit( 0 );  // terminate programc   }r }o   And in C++:m   #include <iostream>    using namespace std;  
 int main () {  	cout << "Hello World!\n";
 	return 0; }m  G On a Wintel PC the C++ Executable (release stripped) is 52K. The Java =aK Class file is 1k. Now, I know that's just the byte code, and a lot of the =MK funk is in the JRE (which is 20k on Wintel), but you don't have to import =cL 1000 classes if you don't want to - far less cruft than something like VB. =L Most of the 34MB that makes up JDK 1.3.1 are classes you can use, not that = you have to.  L As for what you have to work with...TONS. The fruit of the Giant Java Tree =J (http://www.gjt.org/) is ripe for the picking. Not to mention Sun's Java = site (http://java.sun.com).=20    D >>> Arne Vajh=F8j <arne.vajhoej@gtech.com> 11/07/2001 2:13:32 PM >>>   > But it< > also includes a boat load of libraries (for it's age, it's= > astounding that has almost as many as C and C++). You don'tt; > have to use all those libraries (the base language itselfd1 > doesn't include anything more than C/C++ does).c   ????  B I would estimate that the Java API are about more than a 100 timesC bigger than ANSI C ! Probably also almost as big as ANSI C++ (but Ir: do not know the ANSI C++ good enough to state it as fact).   Arne   ------------------------------   Date: 7 Nov 2001 14:11:21 -0600 - From: koehler@encompasserve.org (Bob Koehler)q@ Subject: Re: Future Programming Platforms - Your Opinions Wanted3 Message-ID: <8AQlK9jH4JPe@eisner.encompasserve.org>   i In article <3BE987DC.D924AA67@gtech.com>, Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> writes:  > John Eisenschmidt wrote:A >> Java is an interesting language for a few reasons: the obvious 8 >> fact that it's OOP based, and that it's pointer-less. > @ > I would phrase it as "the programmer can not access pointers".> > All objects in Java have the functionality of a pointer. The> > programmer are just not allowed to do something "dirty" with > them >   +    At least not without consulting the JNI.m   ------------------------------  # Date: Wed, 07 Nov 2001 19:33:31 GMTh' From: Don Sykes <anonymous@pacbell.net>c; Subject: Re: Hewlett family votes "NO" on HP-Compaq merger!w+ Message-ID: <3BE98CD7.BBD56D67@pacbell.net>   D You may remember I started a "Feeling better about Itanium" thread a while back. F Now I must say , in light of the ongoing developments with the merger,D you "may" be correct in your scenario. At the time I wasn't thinkingD that CPQ was in the process of being duped by Carly, but that may beA what has happened. I hope not for the sake of VMS and even Tru64.eG I guess the truth will come out soon. If the merger now fails and Carly0G stays on as the CEO, your assessment is probably correct. If the mergeriE fails and Carly resigns, CPQ was not duped and this may be the better G scenario for VMS. If the merger goes forward it may take a while longer  to know the truth.; In any event, I am feeling a little worse about everything.  DonS     JF Mezei wrote:  >  > "Dijk, Jeroen van" wrote:e^ > > The itanic platform will be based on the best of alpha and hp9000 processors, but that has, > > nothing to do with the HP-compaq merger. > L > I disagree on both points. Intel has inherited fully capable engineers andP > patents. But that does not necessarily mean that all the goodies in Alpha willI > go to IA64. For one thing those two are quite different chip paradigms.c > K > Look at Cutler and Microsoft. Did NT get all the goodies of VMS includinggN > reliability etc etc ? It got some inspirtation at the level where Cutler wasN > involved, but the rest remain very much a windows piece of bloated software. > M > The ex-digital engineers will have to work for Intel and work inside of thel% > limitations and goals set by Intel.  > I > Secondly, the death of Alpha has everything to do with the HP buyout ofoK > Compaq. Carly admitted that she had been talking seriously with Curly foroK > quite a few months and that they did a lot of the ground work well beforeiM > calling the bankers.  This is similar to Pfeiffer having told Palmer to getnK > rid of te FAB plant before Compaq would consider buying Digital (Pfeiffer L > admitted that he had been working with Palmer for 3 years to get Palmer to< > shape Digital to something Compaq would be interested in). > L > HP invested mega money and resources in IA64 in the hopes it could competeP > against Alpha. It turns out that IA64 will be a dud for quite some time. CarlyL > saw a weakened Compaq and saw opportunity to kill Alpha, thus makling IA64V > look better. She raised her skirt a bit and Curly immediatly donated Alpha to Intel. > K > And for HP, this was a very wise move. Now that Alpha is dead, even if HP P > fails to buy Compaq (or succeeds in not buying Compaq), what is left of Compaq > will be severely wounded.i > M > And if HP fails to buy Compaq, it will then be the recipient of some of themP > Copaq customers looking to leave Compaq. If HP fails and inherits Compaq, then3 > the pissed off customers will move to Sun or IBM.e   ------------------------------   Date: 7 Nov 2001 15:55:36 -0800 ( From: bob@instantwhip.com (Bob Ceculski); Subject: Re: Hewlett family votes "NO" on HP-Compaq merger!a= Message-ID: <d7791aa1.0111071555.5c0859d1@posting.google.com>i  Z Don Sykes <anonymous@pacbell.net> wrote in message news:<3BE98CD7.BBD56D67@pacbell.net>...F > You may remember I started a "Feeling better about Itanium" thread a
 > while back.lH > Now I must say , in light of the ongoing developments with the merger,F > you "may" be correct in your scenario. At the time I wasn't thinkingF > that CPQ was in the process of being duped by Carly, but that may beC > what has happened. I hope not for the sake of VMS and even Tru64.pI > I guess the truth will come out soon. If the merger now fails and CarlyoI > stays on as the CEO, your assessment is probably correct. If the mergertG > fails and Carly resigns, CPQ was not duped and this may be the better I > scenario for VMS. If the merger goes forward it may take a while longero > to know the truth.= > In any event, I am feeling a little worse about everything.  > Don  >   L that was my assessment, and you should not feel bad if this falls thru, thenL maybe compaq will either recommit to alpha vms or if they fall, someone elseM will take over vms and maybe that someone will be the one who takes it to thet$ top of the high end were it belongs!   ------------------------------   Date: 7 Nov 2001 15:58:42 -0800t( From: bob@instantwhip.com (Bob Ceculski); Subject: Re: Hewlett family votes "NO" on HP-Compaq merger!e= Message-ID: <d7791aa1.0111071558.5af9c97b@posting.google.com>r  a JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3BE92ED2.72EE7C84@videotron.ca>...l > "Dijk, Jeroen van" wrote: ^ > > The itanic platform will be based on the best of alpha and hp9000 processors, but that has, > > nothing to do with the HP-compaq merger. > L > I disagree on both points. Intel has inherited fully capable engineers andP > patents. But that does not necessarily mean that all the goodies in Alpha willI > go to IA64. For one thing those two are quite different chip paradigms.- > K > Look at Cutler and Microsoft. Did NT get all the goodies of VMS includingvN > reliability etc etc ? It got some inspirtation at the level where Cutler wasN > involved, but the rest remain very much a windows piece of bloated software. > M > The ex-digital engineers will have to work for Intel and work inside of the % > limitations and goals set by Intel.  >  > I > Secondly, the death of Alpha has everything to do with the HP buyout oftK > Compaq. Carly admitted that she had been talking seriously with Curly foraK > quite a few months and that they did a lot of the ground work well beforenM > calling the bankers.  This is similar to Pfeiffer having told Palmer to getiK > rid of te FAB plant before Compaq would consider buying Digital (PfeiffernL > admitted that he had been working with Palmer for 3 years to get Palmer to< > shape Digital to something Compaq would be interested in). > L > HP invested mega money and resources in IA64 in the hopes it could competeP > against Alpha. It turns out that IA64 will be a dud for quite some time. CarlyL > saw a weakened Compaq and saw opportunity to kill Alpha, thus makling IA64V > look better. She raised her skirt a bit and Curly immediatly donated Alpha to Intel. > K > And for HP, this was a very wise move. Now that Alpha is dead, even if HPtP > fails to buy Compaq (or succeeds in not buying Compaq), what is left of Compaq > will be severely wounded.i > M > And if HP fails to buy Compaq, it will then be the recipient of some of thegP > Copaq customers looking to leave Compaq. If HP fails and inherits Compaq, then3 > the pissed off customers will move to Sun or IBM.   I why would any vms user move to hp, ibm or sun junk?  if merger fails then/J compaq will be forced to revive alpha vms and maybe ev8 until itanium portL shows it is reliable and fast, or if they go bankrupt, then someone will buyE vms, and maybe that someone will take vms to the top were it belongs!t are you listening paul allen?4   ------------------------------  % Date: Wed, 07 Nov 2001 23:57:17 -0500r- From: JF Mezei <jfmezei.spamnot@videotron.ca> ; Subject: Re: Hewlett family votes "NO" on HP-Compaq merger!u, Message-ID: <3BEA10AD.D5D7678C@videotron.ca>   Bob Ceculski wrote: K > why would any vms user move to hp, ibm or sun junk?  if merger fails thenfL > compaq will be forced to revive alpha vms and maybe ev8 until itanium portN > shows it is reliable and fast, or if they go bankrupt, then someone will buyG > vms, and maybe that someone will take vms to the top were it belongs!  > are you listening paul allen?     L You're dreaming buddy. If the merger fails, Compaq will focus 200% on makingG is PC business profitable. If Dell can do it, so should Compaq, right ?   M By the way, Miceky Dell today said that no merger in the IT industry has ever M succeeded in making companies grow. Examples given were plenty (including the N "bunch" etc), and both the Compaq Tandem and Compaq Digital fiascos.  If I hadJ been him, I would have added "this is why I fully support HP buying Compaq' since it will eliminate 2 competitors".7  N Compaq doesn't need to make VMS any more prominent than it is now. It's got isD narrow niche of very captive customers that Compaq can Milk while it4 reorganises itself indefinitely, just as Palmer did.  L I think that Futjuisu or some other large japanese outfit should buy Compaq,5 sell off the PC assets and rename the rest "Digital".m   ------------------------------  $ Date: Thu, 8 Nov 2001 08:54:51 +0200 From: JTrendoa2@msn.come5 Subject: Hey I'm Jessica  Com See Me Live 24/7, Free!l" Message-ID: <081101125147@msn.com>  H I'm always connected so come watch me free by going to my homepage at...     http://www.pcpages.com/jesscam1    ------------------------------  # Date: Wed, 07 Nov 2001 23:43:03 GMTn) From: rob.buxton@wcc.govt.nz (Rob Buxton) D Subject: Re: Information about the files accessed by an application.1 Message-ID: <3be9c672.169357783@news.wcc.govt.nz>   ) AS Alan has posted you can use Set watch. * On a running process you cal also use SDA. The steps would be
 $ anal/systemi? SDA> set proc/index=PID where PID = Process ID of Process to beu
 monitored.A SDA> show proc /channel will show you all the files a process hasy open.l  A On Wed, 7 Nov 2001 10:22:07 +0530, "upadhyaya" <ups@hotvoice.com>  wrote:  A >Is it possible to get information about the files accessed by ana
 >application?i >aC >e.g., Assume you execute an exe. While this starts executing, thishI >application reads some configuration files. Using the information in thenJ >configuration files, the application spawns another application. Is thereK >any command on VMS which gives information about the files opened, spawnedi >etc.? >e >With regards,
 >Upadhyaya >o >h   ------------------------------  $ Date: Wed, 7 Nov 2001 15:27:57 -0500* From: "Stanley F. Quayle" <stan@stanq.com> Subject: Infoserver 1000- Message-ID: <3BE952FD.18559.464F51@localhost>o  E I now own an Infoserver 1000.  It boots just fine, loads from flash, g and asks for a password.   How do I "break" the password?  D There's a jumper inside, that forces an "emergency" MOP load.  What 0 do I specify there so I can change the password?    
 --Stan Quayler! President, Quayle Consulting Inc./  
 ----------G Stanley F. Quayle, P.E.   N8SQ   +1 614-868-1363   Fax: +1 614 868-1671-1 8572 North Spring Ct. NW, Pickerington, OH  43147M= Preferred address:  stan@stanq.com       http://www.stanq.com:   ------------------------------   Date: 7 Nov 2001 15:16:45 -0600m- From: Kilgallen@SpamCop.net (Larry Kilgallen). Subject: Re: Infoserver 10003 Message-ID: <3mfl4+11MMWK@eisner.encompasserve.org>   Z In article <3BE952FD.18559.464F51@localhost>, "Stanley F. Quayle" <stan@stanq.com> writes:G > I now own an Infoserver 1000.  It boots just fine, loads from flash, f > and asks for a password. >   > How do I "break" the password?   Did you try "ESS" ?o   ------------------------------  $ Date: Wed, 7 Nov 2001 16:27:53 -0500* From: "Stanley F. Quayle" <stan@stanq.com> Subject: Re: Infoserver 1000, Message-ID: <3BE96109.4503.7D2E50@localhost>  / On 7 Nov 2001, at 15:16, Larry Kilgallen wrote:-  \ > In article <3BE952FD.18559.464F51@localhost>, "Stanley F. Quayle" <stan@stanq.com> writes:I > > I now own an Infoserver 1000.  It boots just fine, loads from flash, a > > and asks for a password. > > " > > How do I "break" the password? >  > Did you try "ESS" ?n   That got it.  Thanks!E    
 --Stan Quayle ! President, Quayle Consulting Inc.y  
 ----------G Stanley F. Quayle, P.E.   N8SQ   +1 614-868-1363   Fax: +1 614 868-1671h1 8572 North Spring Ct. NW, Pickerington, OH  43147p= Preferred address:  stan@stanq.com       http://www.stanq.com-   ------------------------------  % Date: Wed, 07 Nov 2001 16:45:03 -0500e0 From: Paul Anderson <paul.r.anderson@compaq.com> Subject: Re: Infoserver 1000; Message-ID: <071120011645033263%paul.r.anderson@compaq.com>@  ? In article <3BE952FD.18559.464F51@localhost>, Stanley F. Quayles <stan@stanq.com> wrote:r  G > I now own an Infoserver 1000.  It boots just fine, loads from flash, m > and asks for a password. >   > How do I "break" the password?  A You have to boot with a flag value set.  I've sent you the manualg describing this.   Paul   -- /  Paul Anderson   OpenVMS Engineeringe   Compaq Computer Corporation    ------------------------------  # Date: Wed, 07 Nov 2001 22:59:15 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)  Subject: Re: Infoserver 10000 Message-ID: <00A04B3E.609CA1D6@SendSpamHere.ORG>  Z In article <3BE952FD.18559.464F51@localhost>, "Stanley F. Quayle" <stan@stanq.com> writes:F >I now own an Infoserver 1000.  It boots just fine, loads from flash,  >and asks for a password.e >n >How do I "break" the password?O >bE >There's a jumper inside, that forces an "emergency" MOP load.  What m1 >do I specify there so I can change the password?a >t >f >--Stan Quayle" >President, Quayle Consulting Inc. >  >---------- H >Stanley F. Quayle, P.E.   N8SQ   +1 614-868-1363   Fax: +1 614 868-16712 >8572 North Spring Ct. NW, Pickerington, OH  43147> >Preferred address:  stan@stanq.com       http://www.stanq.com >a   try ESS.  M ***  MicroVAX-IV (the final MicroVAX) has achieved a 2-year uptime today! ***  --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM             aJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbesa   ------------------------------   Date: 7 Nov 2001 17:40:41 -06000- From: Kilgallen@SpamCop.net (Larry Kilgallen)j Subject: Re: Infoserver 10003 Message-ID: <zSV8TIO4pFAS@eisner.encompasserve.org>d  c In article <3mfl4+11MMWK@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: \ > In article <3BE952FD.18559.464F51@localhost>, "Stanley F. Quayle" <stan@stanq.com> writes:H >> I now own an Infoserver 1000.  It boots just fine, loads from flash,  >> and asks for a password.m >> p! >> How do I "break" the password?y >  > Did you try "ESS" ?t  @ Somebody went to great trouble to hide their identity in sending@ me email suggesting that people should not post passwords in the newsgroup like I just did.  E While password security in general is a good idea, the above passwordiD is published in the Infoserver documentation as the default passwordA with which the box ships from the factory (and to which it can ber+ reset with suitable hardware manipulation).   B I actually considered augmenting my above post with a warning that? if your ethernet is accessible by untrustworthy folk you shouldf? change it to something besides ESS, but I declined the honor of = being the most pedantic poster in the newsgroup.  I note thate? Brian Schenkenberger has also just skipped the contest for thatV	 position.n  = People who don't know enough to ensure such an arrangement iso= secure should suffer a revocation of their license to operaten a BNC connector.   ------------------------------  $ Date: Wed, 7 Nov 2001 19:41:20 -0500* From: "Stanley F. Quayle" <stan@stanq.com>! Subject: InfoServer 1000, phase 2 . Message-ID: <3BE98E60.28540.12E4B36@localhost>  B Thanks for all the help in getting into this thing (Paul Anderson B even emailed me the manual!).  Now I'm getting the following.  Is A this machine toast?  I replaced the RAM, which passed the memory e$ test, but still get (what's a QAR?):     MCheck code 80, VAP 8007F2D4.r InfoServer 1000 V3.3 (BL26)a; Exception 3, Curr 3, SP 80069FCC, PC 80040AEA, PSL 4080000.4 Stack: 80040EA5 80083D80 8006B7B4 80083C78 07 0D 0A 0@ 0c 0o7 Please record this information, file a QAR, and reboot.m  
   83 BOOT SYSn  s -FLASH   InfoServer 1000 V3.3C Copyright (c) 1990, 1991, 1992, 1993, 1994, 1995 Digital Equipment ' Corp.aA %ESS-I-CONFIGDEV, Device configuration complete.  0 devices foundr   Enter Password:     
 --Stan Quaylel! President, Quayle Consulting Inc.a  
 ----------G Stanley F. Quayle, P.E.   N8SQ   +1 614-868-1363   Fax: +1 614 868-1671 1 8572 North Spring Ct. NW, Pickerington, OH  43147e= Preferred address:  stan@stanq.com       http://www.stanq.com0   ------------------------------  $ Date: Wed, 7 Nov 2001 20:28:32 -0500% From: "John Vottero" <John@mvpsi.com>e% Subject: Re: InfoServer 1000, phase 2p/ Message-ID: <tujnu4d6ie04b1@news.supernews.com>l  $ A QAR is a Quality Assurance Report.  5 "Stanley F. Quayle" <stan@stanq.com> wrote in messagep( news:3BE98E60.28540.12E4B36@localhost...C > Thanks for all the help in getting into this thing (Paul AndersonhC > even emailed me the manual!).  Now I'm getting the following.  Is.B > this machine toast?  I replaced the RAM, which passed the memory& > test, but still get (what's a QAR?): >  >  > MCheck code 80, VAP 8007F2D4.  > InfoServer 1000 V3.3 (BL26) = > Exception 3, Curr 3, SP 80069FCC, PC 80040AEA, PSL 4080000.t > Stack:
 > 80040EA5
 > 80083D80
 > 8006B7B4
 > 80083C78 > 0r > 0i > 0  > 0a > 0e > 0e9 > Please record this information, file a QAR, and reboot.  >s >   83 BOOT SYSg >  > -FLASH >M > InfoServer 1000 V3.3D > Copyright (c) 1990, 1991, 1992, 1993, 1994, 1995 Digital Equipment > Corp.pC > %ESS-I-CONFIGDEV, Device configuration complete.  0 devices found- >p > Enter Password:  >a >e > --Stan QuayleI# > President, Quayle Consulting Inc.n >s > ----------I > Stanley F. Quayle, P.E.   N8SQ   +1 614-868-1363   Fax: +1 614 868-1671 3 > 8572 North Spring Ct. NW, Pickerington, OH  43147n? > Preferred address:  stan@stanq.com       http://www.stanq.comt >l   ------------------------------  % Date: Wed, 07 Nov 2001 19:22:33 +0100a2 From: martin@radiogaga.harz.de (Martin Vorlaender) Subject: Re: Lost in MACRO; Message-ID: <3be97be9.524144494f47414741@radiogaga.harz.de>n  > Brian Schenkenberger, VAXman- (system@SendSpamHere.ORG) wrote:6 > martin@radiogaga.harz.de (Martin Vorlaender) writes:& > >        .END    DICTIONARY_HASHCODE >  > 	.ENDo  E Yup. Thanks (also to everbody else). I really have to get deeper into - MACRO. It was fun to again do some assembler.l   cu,h   Martin -- eD                        |  Martin Vorlaender  |  VMS & WNT programmer1   OpenVMS: When you    |  work: mv@pdv-systeme.deCE   KNOW where you want  |     http://www.pdv-systeme.de/users/martinv/b8   to go today.         |  home: martin@radiogaga.harz.de   ------------------------------  # Date: Thu, 08 Nov 2001 03:07:03 GMTe From: vze35kfz@mail.verizon.net4! Subject: Re: Lost system passwordg/ Message-ID: <3BE9F7BF.178099D@mail.verizon.net>   / You can do a conversational boot, b <dev> /r5:1   0 That will put you in sysboot. Set UAFALTERNATE 1C That will give you a uafalt.dat that you can set a new password in.t1 There was a set/startup opa0 that worked as well.rD I think the trick with that was to set startup_p1 "min" , spawn, andG then run sys$system:startup.com. That used to leave you logged into thee system account. F Haven't done this in years myself though, but I remember the spawn was2 critical or you would just log yourself out again.     C/spam/arlTBennett@yahoo.com   Mickey Lane wrote:   > Hi,e >wA > Picked up a VAXserver 3500 for next to nothing. No docs, notes, B > postits, etc. It was from a group that has long since dispersed. >uB > Years ago, I had a sheet with notes on how to recover a lost VMSB > system password. Unfortunately, the sheet is in a file cabinet a > couple of states away. > 0 > Anyone have the procedure handy to mail to me? > 	 > Thanks,e1 > Mickey Lane, ex-Digit, Storage group, 1981-1995e > mickeylane@earthlink.net   ------------------------------  # Date: Wed, 07 Nov 2001 19:58:58 GMT 1 From: "Mark D. Jilson" <jilly@clarityconnect.com>s8 Subject: Re: network adapters of AXPpci 33 & OpenVMS 7.22 Message-ID: <3BE992A5.566FC6C6@clarityconnect.com>  D The driver is loaded since the UCB was created.  The driver ran thruG it's initialization code and this did not succeed thus the driver nevery flipped the online bit.y   Michael Joosten wrote: >  > Enrico Badella wrote:Q > >n >  > >aS > > isacfg -slot 1 -dev 0 -mk -handle NE2000 -irq0 5 -iobase0 300 -enadev 1 -etyp 1e > >i > H > Wouldn't a -handle DE305-AA instead be sufficient, i.e. without addingG > the record in SYS$SYSTEM:SYS$USER_CONFIG.DAT ? This seems to have then# > same driver entry SYS$CONFIG.DAT.  >  > > Once OpenVMS is up > >  > > $ show dev era0:/fulll > >eL > > Device ERA0:, device type DE305, is offline, network device, device is a > >         template only. > >eE > >         Error count             0       Operations completede   0:E > >         Owner process          ""       Owner UIC        [SYSTEM]wF > >         Owner process ID 00000000       Dev Prot S:RWPL,O:RWPL,G,WE > >         Reference count         0       Default buffer size     0t > >a > B > I'm not sure if that really means that the driver is loaded, butH > inactive (offline). Did you try to configure TCP/IP by filling out the+ > forms of @SYS$MANAGER:TCPIP$CONFIG.COM ?? < > Perhaps the driver has different iobase and IRQ hardwired? > H > I tried to put an Intel EtherExpress Pro/100 into a PC164 board, whichI > was identified by autoconfig, (driver started, device visible) but thenA: > TCPIP did not start. The drivers seem to be quite picky. > G > What worked quite well is an old Tulip chip-based PCI card from Zynx,n0 > ZX312. These are probably also dirt-cheap now. > G > Another choice might be Lance-based (AM7990) card, like a NE1500/2100mA > clone. I have some, and there is a SRM script called add_de205:n > A > isacfg -slot 1 -dev 0 -mk -handle DE200-LE -irq0 5 -iobase0 300 2 > -membase0 d0000 -memlen0 10000 -etyp 1 -enadev 1 >  > Could be another choice. >  > --, > Michael Joosten, SBS C-LAB, joost@c-lab.de, > Fuerstenallee 11, 33094 Paderborn, Germany. > Phone: +49 5251 606127, Fax: +49 5251 606065: > C-LAB is a cooperation of University Paderborn & SIEMENS   -- iD Jilly	- Working from Home in the Chemung River Valley - Lockwood, NY0 	- jilly@clarityconnect.com			- Brett Bodine fan. 	- Mark.Jilson@Compaq.com			- since 1975 or so, 	- http://www.jilly.baka.com               -   ------------------------------  # Date: Thu, 08 Nov 2001 03:31:05 GMTn3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk>e  Subject: Re: NT/W2K CRSS exploit/ Message-ID: <3BE9FBA2.C6810020@cableinet.co.uk>   & "Brian Schenkenberger, VAXman-" wrote:  oG > Just for "acedemic" purposes, I tried such a file here on the PeeCee. G > It didn't BSoD.  Perhaps, I'm just going about it wrong as I am not aa > PeeCee saavy type. > H > Could you email your file to me and instructions as to how to take the > PeeCee down.   ? I did read the link quoted earlier in the thread and this is NTl	 specific,m/ W9x not affected. You don't say which you have.g   regardsu   --   Tim.Llewellyn@cableinet.co.uk  i  C Standard disclaimer applies. My views in no way represent those of u! my employers or service provider.r   ------------------------------  $ Date: Wed, 7 Nov 2001 16:24:36 -05002 From: "Sue Skonetski" <susan.skonetski@compaq.com>" Subject: ok I am back in my office3 Message-ID: <rDhG7.1378$RL6.34223@news.cpqcorp.net>d    just got this,    suek  , AlphaServer Upgrade/Trade-In Promotion site:  % http://www.compaq.com/hps/promotions/-    K The attached site contains AlphaServer MOA promotions, trade-in informationmE and both leasing programs. It also offers an on-line survey form that - pre-qualifies people for telesales follow-up.r  "  A bounty of Alpha upgrade offers!    Don't lose out.    I The time has never been better to take advantage of Compaq's unparalleledrI upgrade and trade-in offers. Overcome your year-end budget constraints byd@ getting the solution you need now and paying nothing until 2002.  F Conserve your valuable resources while you defer payment for 4 months.   Benefit from a 0% lease.  E Take advantage of up to 15% trade-in value for your older AlphaServerg systems.  	 and more.a    $ Act quickly though! Time is limited.  ? For more detail, log onto http://www.compaq.com/hps/promotions/e   ------------------------------  % Date: Wed, 07 Nov 2001 18:22:58 -0500w- From: JF Mezei <jfmezei.spamnot@videotron.ca>o& Subject: Re: ok I am back in my office, Message-ID: <3BE9C251.EC3E36B2@videotron.ca>   Sue Skonetski wrote:G > Take advantage of up to 15% trade-in value for your older AlphaServerp
 > systems.  L Shouldn't there be some VAX to alpha upgrades yet, or did Digital give up on those a decade ago ?   ------------------------------   Date: 7 Nov 2001 19:48:25 -0600 + From: young_r@encompasserve.org (Rob Young)m& Subject: Re: ok I am back in my office3 Message-ID: <LYGG7LSEz8LE@eisner.encompasserve.org>"  \ In article <3BE9C251.EC3E36B2@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Sue Skonetski wrote:H >> Take advantage of up to 15% trade-in value for your older AlphaServer >> systems.' > N > Shouldn't there be some VAX to alpha upgrades yet, or did Digital give up on > those a decade ago ?   JF,-  9 	Does the sun ever shine north of the border?  The reason @ 	I ask is that it appears to me - regardless of time of season -B 	you suffer from a *chronic* case of seasonal affective disorder*.  > 	Perhaps a large dose of photons would make you a more chipper 	person. . .   				Robn    . *http://www.mentalhealth.com/book/p40-sad.html6 "SAD is defined by the pattern of depressive episodes"   ------------------------------  $ Date: Wed, 7 Nov 2001 17:50:37 -0500  From: John Santos <JOHN@egh.com>> Subject: Re: OpenVMS Patch Mailing List in HTML --- eeeuuyech!6 Message-ID: <1011107174831.19309A-100000@Ives.egh.com>  G I just got a message from the patch mailing list that said the HTML was E a mistake and they will be resending everything in the normal format.s  B I also received a new ECO notice today (a new AUDSRV ECO) that was in the traditional format.    " On 7 Nov 2001, Jim Strehlow wrote:  E > The subject of the patches used to contain the TITLE: of the patch.eJ > The recent flood came to me all with subject: Compaq ... not very useful7 > Come on, Compaq, go back to what worked! (plain text)y > ' > Jim Strehlow, Data911 Systems Managerr
 > Alameda, CAg > 1 > "Let them do their worst. We will do our best."n >  > < > "Joseph B. Gurman" <gurman@crosslink.net> wrote in message9 > news:gurman-7D8AD0.22511906112001@news.crosslink.net... K > >     Has anyone elase started receiving the Patch notifications in HTML?eB > > I received a slew today. Or perhaps the right term is a sewer. > >oI > >     Does anyone who sends these little gems out know that most of the3E > > people reaidng them (OK, I'm guessing) still use the OpenVMS MAIL ! > > utility to read their e-mail?a > >mH > >     Is there even an option to say NO to HTML bandwidth-spam? Where? > >0G > >     Perhaps the august Messrs. Hoffman and Kleinsorge know where toc
 > > point us?e > >0 > >     TIA, > >4  > >                   Joe Gurman >  >  >  >    -- D John Santos@ Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Wed, 07 Nov 2001 20:13:29 GMTs0 From: Monty Brandenberg <mcbinc@ne.mediaone.net> Subject: Re: OT - HP's MPE-IX / Message-ID: <3BE99634.5B5F9262@ne.mediaone.net>    Nic Clews wrote: >  > lroduner@americhem.com wrote:uI > > I believe that Compaq claims that there are 400,000+ VMS systems with.D > > 10,000,000 users world-wide (these figures are likely inflated). > E > There are systems that do not exist, because I certainly don't know  > anything about them. > , > Officially inflated, unofficially correct?  < Well, the Boston-area library network system is VMS based soD there's 1M+ users there give or take a bit.  Telnet to mln.lib.ma.usB for a familiar banner.  (No claims as to usability by me, I prefer< the physical card catalog which is tucked into a dark corner of CPL.)   -- 1M Monty Brandenberg, Software Consultant                              MCB, Inc.dM mcbinc@world.std.com                                          P.O. Box 426188-M mcbinc@ne.mediaone.net                              Cambridge, MA  02142-0021e 617.864.6907   ------------------------------   Date: 7 Nov 2001 15:14:35 -0600l- From: Kilgallen@SpamCop.net (Larry Kilgallen)D Subject: Re: OT - HP's MPE-IXe3 Message-ID: <1h8kZLjfTssk@eisner.encompasserve.org>   b In article <3BE99634.5B5F9262@ne.mediaone.net>, Monty Brandenberg <mcbinc@ne.mediaone.net> writes:  > > Well, the Boston-area library network system is VMS based soF > there's 1M+ users there give or take a bit.  Telnet to mln.lib.ma.us > for a familiar banner.  A They're probably counting me, and I have not used my library card- all year :-)   ------------------------------  $ Date: Wed, 7 Nov 2001 20:22:33 +0100, From: Sachin Chitnis <sachin.chitnis@cmg.nl>> Subject: TNDRIVER gets wrong environment setting from VMS/UnixD Message-ID: <C74F19B9B4B4D411B31B00306E00D1EC021A44EE@NL-NIE-MAIL01>   Hello,C Whenever I use rlogin from a Unix/VMS host to a VMS systems, I findh, that show display command reports as follows       Device:    WSA138:  [exec]'     Node:      <hostip>USER:<loginname>e     Transport: TCPIP     Server:    0     Screen:    0  H where <hostip> is the IP address of Unix/VMS machine I executed  rlogin,G          <loginname> is the login name I have on that Unix/VMS machine.a  L Thus it has lost the $DISPLAY (unix) or previous value of "Node" information and also it is wrong..  : If you know a work around for Unix to VMS, please mail me.L On VMS to VMS rlogin, worked around is by storing the information in a file.L A similar solution for is not possible from Unix as the information is lost.. Any suggestions, please send it to me by email  
 Kind regards,l Sachin   ------------------------------  # Date: Wed, 07 Nov 2001 20:18:11 GMTa2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)B Subject: Re: TNDRIVER gets wrong environment setting from VMS/Unix3 Message-ID: <7GgG7.1377$RL6.34232@news.cpqcorp.net>D  s In article <C74F19B9B4B4D411B31B00306E00D1EC021A44EE@NL-NIE-MAIL01>, Sachin Chitnis <sachin.chitnis@cmg.nl> writes:   D :Whenever I use rlogin from a Unix/VMS host to a VMS systems, I find- :that show display command reports as follows:  <   TCP/IP product and version?  OpenVMS platform and version?  H   I've seen similar reports on certain releases of TCP/IP Services, but H   I've not seen anything similar on the current release (V5.1 with ECO).  M :Thus it has lost the $DISPLAY (unix) or previous value of "Node" informations :and also it is wrong.  I   The DISPLAY setting is the UNIX setting, and applicable only on UNIX.  oG   If you are using X Windows client applications on OpenVMS, it is the  J   DECW$DISPLAY setting (and the SET DISPLAY command) used on OpenVMS that G   is of interest here.  I have seen problems -- as stated above -- withuE   the SYS$REM* logical names on certain configurations of OpenVMS andb   TCP/IP Services.  / :Any suggestions, please send it to me by emailS     Ask here, get an answer here.n   	--o  H   When posting questions, please see the suggestions in the introductoryK   section of the OpenVMS FAQ for the information that can be useful -- the  H   information that you will want to include in your posting, information8   that will aid folks in (quickly) answering your query.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Wed, 07 Nov 2001 19:24:21 GMTo2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)! Subject: Re: Undo disk Initializev3 Message-ID: <FTfG7.1376$RL6.34172@news.cpqcorp.net>C  Z In article <a954c96.0111062240.331462c@posting.google.com>, vmae@themail.com (Van) writes:5 :I know very good undeleted utilities [expurgated]...   I   Please explain why your "very good" tool is relevent to this newsgroup, K   and specifically to OpenVMS users -- the cited tool certainly appears to DL   be entirely specific to the Microsoft operating system disk volume (file)    structures.  r  2   The tool does not appear to function on OpenVMS.  G   Do you have utilities for use on OpenVMS and particularly with ODS-2 r"   or ODS-5 disk volume structures?  L   And as for a more general question, why do I need JavaScript enabled when K   I visit the cited website?  (I was looking for the email contact, but it  K   looks like email to Jaroslav Verchkovsky will have to serve as a contact DD   -- the cited website craters if JavaScript is disabled.  Grumble.)    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Wed, 07 Nov 2001 20:44:30 GMT43 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk>r Subject: Re: VT520 Setup/ Message-ID: <3BE99C58.129A601A@cableinet.co.uk>D   smgcircle wrote: > E > Does anyone know if it is possible to disable the setup key and thenH > setup functions on a VT520? We're lookiing for a way to stop the users > from making changes. > H I have seen a deplyment where the setup keys have been removed and glued over.N( Does that count? Definitely not elegant.   > Thanks for your help.  > 
 > == Steve ==    -- n Tim.Llewellyn@cableinet.co.uk  s  C Standard disclaimer applies. My views in no way represent those of 1! my employers or service provider.    ------------------------------  # Date: Wed, 07 Nov 2001 20:45:25 GMT:3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk>- Subject: Re: VT520 Setup/ Message-ID: <3BE99C90.302DB720@cableinet.co.uk>m   smgcircle wrote: > E > Does anyone know if it is possible to disable the setup key and theeH > setup functions on a VT520? We're lookiing for a way to stop the users > from making changes.  B Can't you password protect the setup features like you can on most
 VT220 clones?D   >  > Thanks for your help.o > 
 > == Steve ==s   -- e Tim.Llewellyn@cableinet.co.uk     C Standard disclaimer applies. My views in no way represent those of  ! my employers or service provider.    ------------------------------  $ Date: Wed, 7 Nov 2001 16:17:24 -0500* From: WILLIAM WEBB <WWEBB1@email.usps.gov> Subject: RE: VT520 Setup- Message-ID: <0033000040888795000002L052*@MHS>   9 =0AOther than site visits with a hammer with which to tap-@ miscreant fingers (just kidding), I don't know what to tell you.   WWWebb   > -----Original Message-----1 > From: Info-VAX-Request@Mvb.Saic.Com at INTERNETz, > Sent: Wednesday, November 07, 2001 3:49 PMD > To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET > Subject: RE: VT520 Setup >h >y > smgcircle wrote: > > H > > Does anyone know if it is possible to disable the setup key and the=  ; > > setup functions on a VT520? We're lookiing for a way tos > stop the users > > from making changes. > >g8 > I have seen a deplyment where the setup keys have been > removed and glued  > over.t* > Does that count? Definitely not elegant. >u > > Thanks for your help.m > >B > > =3D=3D Steve =3D=3Dy >n > -- > Tim.Llewellyn@cableinet.co.ukA >rD > Standard disclaimer applies. My views in no way represent those of# > my employers or service provider.p >=   ------------------------------  # Date: Thu, 08 Nov 2001 04:28:14 GMTS3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk> , Subject: Re: Windows XP reality check please/ Message-ID: <3BEA0908.2B83BA73@cableinet.co.uk>    Paul Sture wrote:k > B > In article <3BDCBBB8.4CB5406F@prodigy.net>, Cjt & trefoil wrote: > > Paul Sture wrote:- > > >-
 > > <snip>W > > > I believe I saw the comment during the XP launch that it would save us an hour ofcR > > > lost time per week. 48 weeks x 5 years x hourly rate comes to a nice invoice
 > > > figure.o > > >hI > > > Multiply by the number of PCs at work and it is indeed a large sum.i > > >t	 > > > ___d > > > Paul Sture > > > Switzerland  > >yQ > > So you would suggest the advertising slogan: "Windows XP -- it wastes less of ) > > your time than our earlier products?"m > >n > I like it :-)5  H But Windows XP makes you fly. Its even better than Red Bull because they use real* people not cartoon characters in the ads.  -- Y Tim.Llewellyn@cableinet.co.uk  i  C Standard disclaimer applies. My views in no way represent those of e! my employers or service provider.v   ------------------------------   End of INFO-VAX 2001.621 ************************