0 INFO-VAX	Sun, 20 Jan 2002	Volume 2002 : Issue 37      Contents: Re: A position statement Re: A position statement Re: A position statement7 Re: building a vms box as a project.. is this possible? 7 Re: building a vms box as a project.. is this possible? 7 Re: building a vms box as a project.. is this possible? 7 Re: building a vms box as a project.. is this possible? 7 Re: building a vms box as a project.. is this possible? / Re: Capellas wants IBM model, but does reverse! / Re: Capellas wants IBM model, but does reverse!  Re: Change quorum disk question  Re: Change quorum disk question  Re: Dec2000 and Decserver 90 Re: Dec2000 and Decserver 90# DS20 PCI bus configuration question P Re: Evidence of external help required for a VMS reboot - was: 17  years and sti( Re: Making bootable images from VMS disk( Re: Purveyor is superior for VMS - proof Re: triple boot  Re: triple boot  Re: triple boot  Veritas Client for VMS Re: Veritas Client for VMS; VMS721_SYS-V1100: Caution do not apply with Pathworks V6.0D F Re: Younger recruits versus experienced veterans ( was Re:     The demM Re: Younger recruits versus experienced veterans ( was The demise of compaq ) 5 Re: [OT / Humor] Things not to do on a *nix system... 5 Re: [OT / Humor] Things not to do on a *nix system... 9 Re: [Q] Why is there the limit of 8 levels of directories 9 Re: [Q] Why is there the limit of 8 levels of directories 9 Re: [Q] Why is there the limit of 8 levels of directories 9 Re: [Q] Why is there the limit of 8 levels of directories   F ----------------------------------------------------------------------  # Date: Sat, 19 Jan 2002 19:31:21 GMT * From: "Bill Todd" <billtodd@metrocast.net>! Subject: Re: A position statement > Message-ID: <dQj28.937$TC1.275393@bin5.nnrp.aus1.giganews.com>  > "John McLean" <mcleanj@swissonline.delete.ch> wrote in message/ news:3C494C3A.211300E8@swissonline.delete.ch...  > I > This is a summary of my current thinking about Compaq and VMS.  You may I > not agree with my statements but I hope it gives some food for thought.   H I see nothing here that you haven't said before, and it's still based on. faulty logic and/or absurdly wishful thinking.   >  > I > 1.  Compaq's transfer of Alpha made short-term financial sense.  In the F > circumstances that they had created for themselves, removing a largeF > part of an expense of roughly $400 million per annum is a fair call.D > Whether it is a smart long-term move remains to be seen; there are? > certainly some favorable aspects and there are certainly some  > unfavorable aspects.  L Where did you come up with $400 million per annum?  Winkler's figure was theL highest I've heard, at $300 million annually (which would include completionH of EV7, so the actual short-term savings will be less) - and the EETimesD Marcello interview pegged Alpha development expenses at $150 million	 annually.   I This means that the actual short-term savings realized will be at most in J the $100 - $200 million range.  If one accepts Compaq's statement that 80%K of its customers plan to hang around despite the Alphacide, the annual loss J of profit in VMS alone from the other 20% would have covered that amount -J which means that no real savings occurred at all, even when you limit your vision to the short term.   J But the only circumstances when it's at all rational to limit one's visionJ to the short term are when short-term survival is at stake (i.e., when youK won't be around later if you don't make drastic changes now).  And from all J appearances the Alphacide decreased rather than increased Compaq's chances of being around later.  G The only obvious benefit was to make Compaq a more attractive take-over : target to another company equally uninterested in fieldingL 'non-industry-standard' solutions.  Aside from that, it appears to have beenJ at best fiscally neutral in the short term, a significant loss medium-termK (the period when VMS and Tru64 will be available only on the declared-dying G Alpha platform), and a disaster long-term unless the Alpha team pulls a J miracle out of its hat for Intel (and of course since the Alpha team wouldD not have been working for Intel had the Alphacide not occurred, that: possible miracle would not have been on the table at all).   > H > 2.  Compaq's handling of the announcement of the transfer was poor andF > their justifications were weak.  Various announcements about methodsH > which will reduce the customers' costs of change of platform have doneJ > something to redress the balance.  Personally I would chalk it up as yet5 > another failure in their "external communications".   D Failure to justify an unjustifiable decision is not a communicationsI failure.  Perhaps you're just saying that their lies could have been less  transparent.   > J > 3.  Compaq appears to be run as four separate competing companies - VMS,F > NSK, Tru64 and NT - and this kind of attitude is a major obstacle to@ > income growth.  These subcompanies never mention each other inI > advertising and, even worse, the sales philosophy seems to be to divide H > the range of possible markets into four sectors - VMS being sandwichedH > between NSK and Unix - and that the given platform will ONLY advertiseA > to that sector.  To put it very politely, I just cannot see any - > reasonable justification for this approach.   F Any statement that suggests (as yours does above) that VMS competes onL anything like equal footing in the corporation is flat-out blind to reality.E The most charitable interpretation I can come up with (of your entire D approach, not just this point) is that you've completely given up onI challenging Compaq's handling of its assets and are willing to grovel for L whatever crumbs that might produce - an approach that has proven disasterous< over many years (first with DEC, more recently with Compaq).   > G > 4.  The OpenVMS division within Compaq seems to be enthusiastic about H > the platform and certainly want to improve sales.  The obstacles trulyH > seem to be elsewhere.  Given that only the VMS people in Compaq appearJ > to read this newsgroup, any criticism here - constructive or otherwise - > is misdirected.   J If your premise were correct, your conclusion would be as well.  But sinceK both customers and the competition also read what transpires here (you even % say so in your next point), it's not.   6   Compaq's VMS people and us here all seem to want theJ > best for VMS - to see it grow in use, to expand the markets which use itI > - and we would be better to join forces in this task than to spend time J > arguing.  (I know that Compaq's VMS people are the "face of the company"G > from our perspective but when all of us are in violent agreement with D > our aims - but maybe not method! - it really makes little sense to > harangue them.)   L I haven't noticed anyone haranguing them except when they attempt to supportK Compaq's lies (in which case confrontation is entirely appropriate, even if L one can also sympathize with the position they're in:  if they *really* haveI credible evidence that we lack on these matters, let them produce it - or 0 convince higher-ups that doing so is important).   > I > 5.  In regard to the previous point, it seems that Compaq's competitors J > have been using information from this newsgroup that criticizes Compaq'sF > actions as regards VMS.  This can only have a negative affect on VMSG > sales and so it plays directly into the hands of the people in Compaq ) > who believe that VMS should be ignored.   H So what?  It's abundantly clear that these people already have the upper$ hand, so matters won't be any worse.  I VMS is not so much owned by Compaq (and these people who run it) as it is D held hostage by it.  "Watch out!", you seem to be saying:  "If we do; anything to make them mad, they'll only make things worse!"   H Well, things already *are* worse, and they got that way by following theK course of action you're promoting now.  A new course is indicated, one that L will either make them sit up and take notice or result in their expulsion byH the BoD or the stockholders.  Yes, it *feels* risky, but Compaq has doneI such a good job of marginalizing VMS already that there's really not that L much *actual* down-side risk left - and the potential up-side, as we've said for so long, is huge.      What needs to be done in this J > group (when we are not dealing with technical questions) is to encourage? > the growth of VMS sales and to show its advantages over other I > platforms.  (In regard to the former, reports of sales into new markets H > are always interesting and for the latter, just how difficult is it to0 > show the security advantages that VMS enjoys?)  G JF answered this more than adequately.  I suggest that you consider his H points carefully (especially the issue of how ethical it is to encourageI others to adopt an at-risk platform without notifying them of said risks, A simply in the hope that their presence will improve its chances).    > B > 6.  In a broader picture we need to do what we can to reduce theI > influence of those people in Compaq who appear to have relegated VMS to G > the "second division" of platforms (along with NSK).  For some reason J > the PC "sub-company" appears to have preference in Compaq, regardless ofG > the questionable logic in supporting something that has produced such H > small return on investment for the last few years and is very unlikelyJ > to change this situation in future.  Whether this PC emphasis comes fromI > the marketing people or from the decision-makers at the top is somewhat G > irrelevant.  We need to work with Compaq's VMS people to convince the B > decision-makers that there are very good reasons to increase theF > publicity of VMS.  When that action results in greater VMS sales andF > hence greater income, we will have clearly demonstrated that it is aD > platform which deserves rather more attention than it is currentlyJ > receiving.  If this reduces of the credibility of those providing pro-PCG > advice to Compaq's decision-makers, then so be it; I for one won't be  > upset.  L That's *exactly* what we tried 20 months ago, John.  It didn't work, at all.   - bill   ------------------------------  % Date: Sat, 19 Jan 2002 15:35:56 -0500 % From: JF Mezei <jfmezei@videotron.ca> ! Subject: Re: A position statement , Message-ID: <3C49D8A6.BD64A921@videotron.ca>   Bill Todd wrote:N > Where did you come up with $400 million per annum?  Winkler's figure was theN > highest I've heard, at $300 million annually (which would include completionJ > of EV7, so the actual short-term savings will be less) - and the EETimesF > Marcello interview pegged Alpha development expenses at $150 million > annually.   I Do we know for sure that those figures are for the chip only ? Could they J include the development cost of the fancy Alpha servers (aka: Wildfire and offspring ?)  M Is EV7 going to be available in anything less than wildfire-class machines ?    & What about EV8 (if it had been made) ?  N If any of the above amounts include the cost of developping the actual systemsM for that chip, then one should also include such costs because they are still 9 going to have to build such systems with that IA64 thing.   L Also, since EV7 is the second generation to support wildfire class machines,J the development of the systems should be less involved since it will be an3 evolution of the chip to make things faster/easier.   N But when IA64 comes out and Compaq attempts to build a wildfire-class machine,N I suspect that the development costs will be quite hard with lots of headachesI since IA64 will still be a young chip without much support for such large  scale systems.  . Intel has never built CPUs for supercomputers.   ------------------------------  # Date: Sat, 19 Jan 2002 21:12:02 GMT * From: "Bill Todd" <billtodd@metrocast.net>! Subject: Re: A position statement B Message-ID: <Cil28.745965$8q.58933677@bin2.nnrp.aus1.giganews.com>  2 "JF Mezei" <jfmezei@videotron.ca> wrote in message& news:3C49D8A6.BD64A921@videotron.ca... > Bill Todd wrote:L > > Where did you come up with $400 million per annum?  Winkler's figure was the E > > highest I've heard, at $300 million annually (which would include 
 completionL > > of EV7, so the actual short-term savings will be less) - and the EETimesH > > Marcello interview pegged Alpha development expenses at $150 million
 > > annually.  > K > Do we know for sure that those figures are for the chip only ? Could they L > include the development cost of the fancy Alpha servers (aka: Wildfire and > offspring ?)  G If Winkler's figure did include those costs and Marcello's did not that : would help a lot in explaining the disparity between them.  D It has been claimed that having Alpha and Itanic share future serverK architectures is all that kept Alpha alive at all (i.e., that Itanic server E development was assured but Alpha server development - at least after I Marvel - was not).  But if the $300 annual development cost figure indeed H included Alpha server development once again Compaq appears to have beenK penny-wise but pound-foolish given how much more effectively a given server D configuration can leverage Alpha-level performance than Itanic-levelK performance (especially considering Itanic's lack of on-chip MP glue, which F will be a *major* server disadvantage against EV7, POWER, and Hammer).   > L > Is EV7 going to be available in anything less than wildfire-class machines ?   I IIRC Fred stated that single-processor configurations weren't a priority, @ but that certainly leaves open *very* attractive DS20/ES45-classJ configurations (no alternative lower-end VMS and Tru64 configurations willJ exist for quite a while after EV7 is shipping, so unless Compaq is alreadyK willing to give up even more of those markets such configurations should be L expected - unless it thinks it can just get customers to continue to buy the current platforms).    > ( > What about EV8 (if it had been made) ?  L Fred also made the comment that EV8 would have supported 'only' a 64-KB pageJ size (ignoring the fact that by 2003 - 4 this won't be at all unreasonableI in anything but possibly the lowest-end platforms).  Given that EV8 would H have something like halved the required number of processors from an EV7J configuration just on the basis of SMT (leaving aside the probability thatF EV8 would have enjoyed the advantages of the next process generation),K pushing it unnecessarily even farther up-market would not have made a great K deal of sense (though sense has been in *very* short supply at Compaq since  Pfeiffer's departure).   > H > If any of the above amounts include the cost of developping the actual systems I > for that chip, then one should also include such costs because they are  still ; > going to have to build such systems with that IA64 thing.   H They considered those costs a 'given', so they presumably weren't on theF table at all.  Whether this attitude was a sensible one is a different	 question.    > D > Also, since EV7 is the second generation to support wildfire class	 machines, L > the development of the systems should be less involved since it will be an5 > evolution of the chip to make things faster/easier.   L EV7 may still contain the EV6 core, but its interaction with the rest of theI system is markedly different from that in Wildfire (private local memory, I on-chip MP glue).  But of course EV7 (Marvel) system development *wasn't* 
 cancelled.  I Developing systems for EV8 (given that it planned to use almost identical L memory and MP mechanisms and hence presumably would have 'just slipped into'J the existing Marvel architecture) should have been relatively inexpensive,B so it would indeed have been misleading to include much in claimedD cost-savings from system-level development.  Even if they consideredD blade-style servers to be the inevitable future, the existing MarvelH architecture could still have supported EV8 very nicely indeed at littleI incremental cost while saving the expense of supporting blade-style Alpha K servers at all - assuming that they in fact follow through on their current / 'commitment' to support Alpha in blade systems.    > G > But when IA64 comes out and Compaq attempts to build a wildfire-class  machine,F > I suspect that the development costs will be quite hard with lots of	 headachesiK > since IA64 will still be a young chip without much support for such largeg > scale systems.  K In particular, IA64 presumably won't be able to leverage Marvel developmentbG much, since that presumes the on-chip memory and MP glue that Itanic soiK conspicuously lacks.  Rob has suggested that this won't matter much becauser@ the future belongs to 'blade' servers, but that prediction is asE questionable (especially outside the commodity low-end) as is that ofe Itanic's 'inevitable' success.  C More likely, the 'blade' architecture will be more Wildfire-like in E character, which means that Itanic may well slip into it without mucheK difficulty but that EV7's on-chip MP advantages may be completely discardedaG (anyone know enough about blade-style MP operation to shed any light onr this?).    - bill   ------------------------------  # Date: Sat, 19 Jan 2002 22:06:28 GMTr4 From: Tim Llewellyn <tim.llewellyn@blueyonder.co.uk>@ Subject: Re: building a vms box as a project.. is this possible?0 Message-ID: <3C49ED03.C229A516@blueyonder.co.uk>   Herb Asher wrote:w > D > Well it's kinda better than blowing 1.5 to 5k a time on overpricedF > training courses. I'm at the bottom end of I.T and need some skills,= > how would you suggest improving them without a box at home?h >   H the problem with the UK market at present (from our perspective) is thatH its difficult to get into anything without previous business experience B in your most recent (preferably current) position of that specificC technology skill or business segment. Its an employers market :-(. BL Thus training courses and at home self training have some benefit (I prefer Q the latter)  but but it is not clear quite how much they will help you get a job.sQ e.g. I cannot get interviews for Tru64 positions because I do not have commercialhJ exp since 1997, even though there is allegedly  a shortage of Tru64 peopleH on the market, and quite a few of those roles require VMS as well, and I1 do have 5 years experience with it from V1 to V3.a  G anyway, good luck, I hope you find something local, and I hope for bothi# of us the VMS market picks up soon.s   regardsa    D > >Interesting query. I usually associate "out of work" with "out ofK > >money". Please make sure your dependents are provided for before blowing0 > >your bankroll on hardware.l   I not everyone has dependents. Anyway, we still have the NHS over here :-).t  D Thats about the politest reply I could come up with to that comment.   -- t Tim.Llewellyn@cableinet.co.uk  $  C Standard disclaimer applies. My views in no way represent those of t! my employers or service provider.    ------------------------------  # Date: Sat, 19 Jan 2002 22:13:18 GMT)4 From: Tim Llewellyn <tim.llewellyn@blueyonder.co.uk>@ Subject: Re: building a vms box as a project.. is this possible?/ Message-ID: <3C49EE9E.665617B@blueyonder.co.uk>    Herb Asher wrote:$ > F > Can someone post me a short list of the main vax boxes that would beG > suitable for home project use and things like on board memory, speed,i8 > and would they be usable with a pc monitor and mouse.. > F > Before I left my last job we installed some blue boxes, i'm not sureH > if they were alpha's but maybe they were. We were able to use these onF > our pc monitor's and they had some color in decwindows as apposed toC > the normal vt green or grey. Any idea what these boxes would havefH > been, they were desktops not towers and I remember support saying they@ > were not amazingly fast just better than the old boxes we had.  = Might have been Alphastation 255's, nice boxes for their day.e   > F > Also, any uk vms people who can recomend a retailer for decommisonedH > boxes? I have had a scan of the net, including ebay and it doesnt look > that good.  S www.prodec.co.uk used to , but they don't seem to have the Digital section anymore.n  5 How about a new low cost alpha from www.islandco.com?n   regardsl      ,   -- d Tim.Llewellyn@cableinet.co.uk  a  C Standard disclaimer applies. My views in no way represent those of h! my employers or service provider.o   ------------------------------  # Date: Sat, 19 Jan 2002 22:30:11 GMTu4 From: Tim Llewellyn <tim.llewellyn@blueyonder.co.uk>@ Subject: Re: building a vms box as a project.. is this possible?0 Message-ID: <3C49EE91.2328B4FD@blueyonder.co.uk>   Herb Asher wrote:  > F > Can someone post me a short list of the main vax boxes that would beG > suitable for home project use and things like on board memory, speed, 8 > and would they be usable with a pc monitor and mouse.. > F > Before I left my last job we installed some blue boxes, i'm not sureH > if they were alpha's but maybe they were. We were able to use these onF > our pc monitor's and they had some color in decwindows as apposed toC > the normal vt green or grey. Any idea what these boxes would havesH > been, they were desktops not towers and I remember support saying they@ > were not amazingly fast just better than the old boxes we had.  = Might have been Alphastation 255's, nice boxes for their day.    > F > Also, any uk vms people who can recomend a retailer for decommisonedH > boxes? I have had a scan of the net, including ebay and it doesnt look > that good.  S www.prodec.co.uk used to , but they don't seem to have the Digital section anymore.a  7 How about a new low cost alpha from www.islandco.co.uk?a   regardsn      r   -- n Tim.Llewellyn@cableinet.co.uk  h  C Standard disclaimer applies. My views in no way represent those of p! my employers or service provider.t   ------------------------------  # Date: Sun, 20 Jan 2002 03:36:23 GMTt1 From: "David J. Dachtera" <djesys.nospam@fsi.net>h@ Subject: Re: building a vms box as a project.. is this possible?& Message-ID: <3C4A3C29.8ECD91E@fsi.net>   Tim Llewellyn wrote: >  > Herb Asher wrote:w > > F > > Well it's kinda better than blowing 1.5 to 5k a time on overpricedH > > training courses. I'm at the bottom end of I.T and need some skills,? > > how would you suggest improving them without a box at home?p > >  > J > the problem with the UK market at present (from our perspective) is thatI > its difficult to get into anything without previous business experienceeD > in your most recent (preferably current) position of that specificD > technology skill or business segment. Its an employers market :-(.M > Thus training courses and at home self training have some benefit (I preferaS > the latter)  but but it is not clear quite how much they will help you get a job.eS > e.g. I cannot get interviews for Tru64 positions because I do not have commercial L > exp since 1997, even though there is allegedly  a shortage of Tru64 peopleJ > on the market, and quite a few of those roles require VMS as well, and I3 > do have 5 years experience with it from V1 to V3.e > I > anyway, good luck, I hope you find something local, and I hope for bothi% > of us the VMS market picks up soon.a > 	 > regardsz > F > > >Interesting query. I usually associate "out of work" with "out ofM > > >money". Please make sure your dependents are provided for before blowingt > > >your bankroll on hardware.  >  > not everyone has dependents.  C Yeah, you're right. I suppose if you live alone, then that's not anm< issue. If you have a non-working spouse and are otherwise anH empty-nester, then it gets a bit stickier. If you a family but your wifeF is not a wage-earner, well, the laws here in the U.S. are beginning toH take a fairly dim view of buying computers rather than feeding, clothing3 and or sheltering your family - for right or wrong.n  . > Anyway, we still have the NHS over here :-).  5 Here in the states, it's all still profit driven. :-(   A Good thing too, or there'd be one less niche in VMS's market. :-|e  G (I'm currently employed in the healthcare field - one of the few fieldse2 where VMS jobs are occasionally still found here.)   -- y David J. Dachtera. dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/h   ------------------------------  # Date: Sun, 20 Jan 2002 03:40:45 GMTu1 From: "David J. Dachtera" <djesys.nospam@fsi.net>r@ Subject: Re: building a vms box as a project.. is this possible?' Message-ID: <3C4A3D30.3D26B2B0@fsi.net>l   Tom Linden wrote:h > G > Wow!, Thanks for the plug, Larry.  Actually if you have an Hobbyist's ; > License you can get PL/I for $250, and it is available ons >  > VAX 5.5-2 to 7.3 > AXP 6.2 to 7.3 > Tru64 4.0d to 5.1  > D > Documentation is free and may be downloaded from freja.kednos.com.= > The kits are there as well, but you will need a license pak D > to activate them, obviously.  To obtain such a license you need to? > send a copy of your Hobbyist License from Compaq and $250 to:t [snip]  @ $250??!! WOW!  Any chance to whittle that down by 80% to 90%??!!  F ...or is that a commercial license (you can code on a non-hobby system7 and sell your product for a profit to recoup the cost)?o  E Some folks have a lotta bux to throw at a hobby. Few (if any) of theme are VMS folks.   -- p David J. Dachterat dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Sun, 20 Jan 2002 04:01:27 GMTp1 From: "David J. Dachtera" <djesys.nospam@fsi.net>e8 Subject: Re: Capellas wants IBM model, but does reverse!& Message-ID: <3C4A4209.857CD5F@fsi.net>   Bob Ceculski wrote:p > ? > What makes IBM profitable?  It is not just software services.aD > It is the hardware!  When you provide a superior hardware platformC > (power) that can run software that is secure, can scale well, anddA > run 24x7, then software services soar ... Capellas is doing theuB > opposite, he is giving away the industries best hardware (alpha)F > to a competitor and thinks software services will rake in the dough,D > except, because your competitors are all selling the same hardwareB > platform, you have just entered the same low dollar, high volumeC > market that pc's are in right now!  It's the hardware that drivesl  > software and services dummy!    4 ...and it's *MARKETING* that drives the other three.  G Important thing to remember about IBM: IBM is *NOT* a computer company!<E IBM is a *MARKETING* company that designs, builds and sells computers D and many other office and business machines. The great bulk of their? efforts go into *MARKETING* the products they design and build.   @ ...and as another poster pointed out, "marketing" covers a broadH spectrum of activities, everything from the actual design of the product. to packaging, merchandising, advertising, etc.  G The Q may CLAIM to be emulating IBM (careful with that word emulate, byt6 the way), but they haven't got that right yet, either.   --   David J. Dachtera  dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/-   ------------------------------  % Date: Sat, 19 Jan 2002 23:55:56 -0500h% From: JF Mezei <jfmezei@videotron.ca>e8 Subject: Re: Capellas wants IBM model, but does reverse!, Message-ID: <3C4A4DDA.C4DCB061@videotron.ca>   "David J. Dachtera" wrote:I > Important thing to remember about IBM: IBM is *NOT* a computer company!nG > IBM is a *MARKETING* company that designs, builds and sells computersl. > and many other office and business machines.  N I think that IBM started off as a marketing company, evolved (devolved ?) intoM a brainwashing company, but I think that since the mid 1990s when IBM startedsL to awaken to other people's technologies (ethernet, tcpip, unix and even NT)' and improved its mentality quite a bit.   K No longer the closed shop with such a strong "NIH" syndrome it used to have-L ("If IBM didn't invent it, then it could not possibly exist"). The fact thatN IBM went into outsourcing also helped because they needed to have the image of1 being able to run any system, not just their own.   L Yeah, they are still strong in marketing, but you need that for any computerH company. But IBM has become more agressive with its prices  and isn't as, snobbish with its attitude as it used to be.   ------------------------------  % Date: Sat, 19 Jan 2002 18:57:04 +0000e1 From: Robert DiRosario <rdirosario@starpower.net>w( Subject: Re: Change quorum disk question- Message-ID: <3C49C180.E7FF6F16@starpower.net>a   Patrick Young wrote: > h > Robert DiRosario <rdirosario@starpower.net> wrote in message news:<3C4773C9.E4851B5E@starpower.net>... > > H > > The system disk is the quorum disk, and I see now that I should haveC > > changed that before I added the second system.  How do I change E > > that now?  Can I copy the quorum.dat file to the new quorum disk,eE > > take one node down, edit modparms.dat and run autogen on the nodee> > > that's up, take it down and do the same on the other node? > >e > F > I'm not sure QUORUM.DAT contains any data that needs to be preservedC > between reboots so I don't think you need to worry about making an > copy of it...e > > >  00010002 454C4946 20204D55 524F5551 QUORUM  FILE.... 000000> >  00A0831A 2A8798BD 00A08319 06E9CA08 ........*.... 000010> >  00A0831A 09C50480 00A0831A 2B298FD8 .)+........... 000020> >  04010000 00000404 00030002 00010002 ................ 000030> >  00000000 00000000 3DA38CAA 00000000 .....=........ 000040 > I > Simply shut down one computer (disk watcher), modify your MODPARAMS.DATsJ > on the other (disk watcher), autogen, and reboot. Boot the other then do > the same thing.e > F > The cute thing about this is the first time you mount the new quorumE > disk you will notice it will automagically get a QUORUM.DAT createda > on it right before your eyes.l > C > Make sure you mount the (new non system disk) QUORUM disk on bothe< > nodes (disk watchers) on startup when all done - this is a > requirement.    How did you create the hex dump?   ------------------------------    Date: 19 Jan 2002 21:39:01 -0800) From: P.Young@unsw.EDU.AU (Patrick Young)c( Subject: Re: Change quorum disk question= Message-ID: <55f85d77.0201192139.5c9425e4@posting.google.com>o  f Robert DiRosario <rdirosario@starpower.net> wrote in message news:<3C49C180.E7FF6F16@starpower.net>...  " > How did you create the hex dump?  $ H dump/header $9$dk2:<0,0>quorum.dat .t .  .t Map area     Retrieval pointers0         Count:          3        LBN:          6  & H dump $9$dk2:/block=(count=3,start=6)  C At the risk of providing TMI ("Too Much Information") the format of > the file is not defined in LIB or STARLET, however is CLUQF...   struct CLUQF {N /* Start of owner block                                                     */N     char CLUQF$T_IDENT [12];            /* Quorum block identification area */N     unsigned short int CLUQF$W_VERSION; /* Quorum block version number      */     union  {N         unsigned short int CLUQF$W_FLAGS; /* Flags word                     */         struct  {lN             unsigned CLUQF$V_QUORUM : 1; /* Cluster has dynamic quorum      */)             unsigned CLUQF$V_FILL_0_ : 7;             } CLUQF$R_FLAG_BITS;          } CLUQF$R_FLAGS_UNION;  s	 etc, etc.s  G Usual cluster stuff such as date cluster formed, quorum, votes, clustere
 system ID.   ------------------------------  % Date: Sat, 19 Jan 2002 21:37:04 -0500t- From: Michael Austin <miaustin@bellsouth.net>i% Subject: Re: Dec2000 and Decserver 90 2 Message-ID: <3C4A2D50.8D655132@firstdbasource.com>   Jimbond wrote: > > > I'm trying to setup a DEC200AXP with a Decserver90 attached. > The server has 90L+ cards.N > What I need is a list in order of installation of the software I need to get > this thingK > up and running. Any help, advise, direction or redicule will be helpfull.n  % I believe the 90L+ can support TCPIP.o  E Connect a serial line to port 1 of the router and at the local prompt-H type SET PRIV default password SYSTEM   from there HELP SET TCPIP. Or asG Brian pointed out there may be a menu option.  A good place to start isa HELP.w   Hope that "help"s  -- s   Regards,  9 Michael Austin  -- Currently available full- or part-time 7 First DBA Source, Inc. -- http://www.firstdbasource.com  President/Sr. Consultant   ------------------------------  # Date: Sun, 20 Jan 2002 03:50:26 GMTl1 From: "David J. Dachtera" <djesys.nospam@fsi.net>s% Subject: Re: Dec2000 and Decserver 90d' Message-ID: <3C4A3F75.6157D8A8@fsi.net>g   Michael Austin wrote:t >  > Jimbond wrote: > >y@ > > I'm trying to setup a DEC200AXP with a Decserver90 attached. > > The server has 90L+ cards.P > > What I need is a list in order of installation of the software I need to get > > this thingM > > up and running. Any help, advise, direction or redicule will be helpfull.r > ' > I believe the 90L+ can support TCPIP.s  ! You may be thinking of the 90TL. d  : The 90L and 90L+ were LAT only and "boot" from local ROM.   C The 90TL runs either DECserver or NAS software (I believe) and onlywG boots from a remote host, but provides limited modem control (the jackstG are RJ45 instead of MMJ). 90TL provides TCP/IP support with either loadn image.  F The 90M I believe also runs either DECserver or NAS software, providesE some modem control (RJ45 instead of MMJ, and I think it supports moreM? hardware flow control than 90TL) and has a flash-ROM option for:H "booting" locally, without a load host. 90M provides TCP/IP support with either load image.  ) See http://www.dnpg.com/ for better info.l   -- i David J. Dachteraw dba DJE Systemsi http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------    Date: 19 Jan 2002 15:40:08 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)), Subject: DS20 PCI bus configuration question, Message-ID: <$jXggV9sRdmP@malvm6.mala.bc.ca>  H   I recently had a problem with a DS20 wherein data on a KZPAC would getC silently corrupted ( no errors logged but the data read back wasn'to& always the same as the data written ).  ;   It appears that the reason this was happening was becausee= the controller was on PCI bus 0 and it only works properly one? PCI bus 1.  I also understand that the graphics cards only work = properly on bus 0, not bus 1. I had the graphics card and the 7 KZPAC in adjacent slots on bus 0, I don't know if this u8 contributed to the problem or not ( ie does a KZPAC work1 ok on bus 0 if there's no graphics card there? ).i  =    All this led me to wonder if these configuration rules arec> all collected anywhere or if there is a rule-of-thumb to apply8 when setting up a DS20. Anyone know somehere this wisdom$ is available in a consolidated form?  8    I'd also like to understand how the data got silently9 mangled. I could understand errors being logged if thingse< are misconfigured but not how it could get perverted without5 anything noticing. I presume it was getting corruptedu< during the transfer on the PCI bus, but shouldn't there have8 been parity errors logged in that case? ( it appears the3 corruption was typically single bit errors ). Is it2; supposed to work like this or is there some console settingo; that might be messed up? I notice in the ARC console theresp5 an option to turn off PCI bus parity, is there an SRMk  option that does the same thing?  =   ps. It would also be nice if the firmware would whine if ite< finds PCI widgets in unsupported slots ( like it appears the9 PWS systems do if you put unsupported stuff in the 64 bita slots ).   ------------------------------  # Date: Sat, 19 Jan 2002 21:50:58 GMTu4 From: Tim Llewellyn <tim.llewellyn@blueyonder.co.uk>Y Subject: Re: Evidence of external help required for a VMS reboot - was: 17  years and sti 0 Message-ID: <3C49E95B.811C8D57@blueyonder.co.uk>   Paul Sture wrote:f > G > In article <3C4460D7.68D9CB7F@blueyonder.co.uk>, Tim Llewellyn wrote:  > > Paul Sture wrote:  > [snip] > >nR > > > Another Compaq customer here told me that this style of startup was taken toM > > > fresh heights at his company, with C programs used to generate the DCL.n > > X > > well, if the input to the C program was a high level description of the requirements_ > > then at least this approach would reduce errors due to typos when editing systartup_vms.com T > > (of course, I wouldn't suggest anyone ever made a typo in systartup_vms.com:-)). > >iI > Point taken, but in the context of going into an unknown site, I reallyhK > don't like this. Do they even have a C compiler on site? If so, where are-L > the sources? You walk in confident of your ability with DCL and all things9 > to do with startup, but you may not be a whiz with C...e  K if their custom startup procedure or whatever is not documented adequately bM for an experienced VMS professional to pick it up fast then it is really the a7 clients problem, and you should point this out to them.k  G Not always that easy, I know, 'specially if you've been hired for a oned off upgrade over the hols.   regardso   > ___a > Paul Sture
 > Switzerland    --   Tim.Llewellyn@cableinet.co.uk  e  C Standard disclaimer applies. My views in no way represent those of o! my employers or service provider.o   ------------------------------  # Date: Sun, 20 Jan 2002 05:42:40 GMT ( From: Howard Harte <hharte@hartetec.com>1 Subject: Re: Making bootable images from VMS diskf+ Message-ID: <3C4A58CF.4030402@hartetec.com>    Hi,a  H 	Thanks for the information.  It worked well, and I was able to produce B three bootable drives.  I will mess around with some of the other . suggestions to try and create a bootable tape.  J 	Does anyone know if there are any CD-ROM drives that are compatible with  DSSI?e   	Thanks, 	Howarda     Jan-Erik Sderholm wrote:   < > Backup (and other security features) are one of the really< > strong parts of VMS, so of course there is a way to backup > the system disk :-)  >  > Normaly you could just do a : A > (firstdisk: is teh current (booted) system disk and seconddisk:2 > is the target for the backup)D >  > $ MOUNT/FORAIGN seconddisk:i? > $ BACKUP/IMAGE/IGNORE=INTERLOCK/VERIFY firstdisk: seconddisk:s > : > That should produce a bootable copy of your system disk. > > > Make sure you don't have anything else running on the system< > during the copy.  You will get warnings tat some files are@ > "open for write", but the "/IGNORE=INTERLOCK" will try to copy? > them anyway. These files will only be some log files, so it's A > normaly no problem. Anyway, take a lock at what the VERIFY passi > tels you.  > E > And, of course, Compaq tels you to backup the system disk off-line.y >  > Jan-Erik Sderholm.  >  > Howard Harte wrote:p >  >>Hi,e >>P >>        I just got my Vax 4000/300 to boot VMS 6.2 from an RF35 DSSI drive.  IJ >>have two other (empty) RF35's in the system, and for now, no tape drive. >>P >>        I am wondering how to make a disk image of the bootable drive onto theE >>other drives so in case I mess one up, I can boot from another.  Is # >>there a way to do this under VMS?a >> >>   ------------------------------    Date: 19 Jan 2002 16:06:23 -0800( From: bob@instantwhip.com (Bob Ceculski)1 Subject: Re: Purveyor is superior for VMS - proof = Message-ID: <d7791aa1.0201191606.45607bdf@posting.google.com>e  [ Arne Vajhj <arne.vajhoej@gtech.com> wrote in message news:<3C49B575.37BA876B@gtech.com>...  > Bob Ceculski wrote:tH > > wrong again!  We compile and run java scripts embedded in dcl coms &G > > called from dcl coms using purveyor and also call perl scripts from  > > dcl ...d > = > Any web-server that supports DCL can run scripts written in ) > any language (including java and Perl).r > > > But performance usually sucks with that approach. Activating= > the JVM or the Perl interpreter for each script call is note# > a solution for high-volume stuff.i >  > Arne  K wrong ... we tested cgi scripting performance from every angle and it workssL best to pass the www symbols/logicals to another executable (dibol) from dclM and handle everything from there ... performance is terrific on alpha vms ...oN no need to learn perl when you can efficently use one programming language andK synergy dibol performs very well ... external html code/java code files canaO be "included" directly into dibol, then just redirect sys$output to tt: channel O and performance flies ... remember, dibol supports all vms system library callseI so you have full access to vms ... plus, a generic c dll can call a dibol0N external subroutine, just as powerful ... why dibol, you can do anything, keepN your code standardized on one language platform, plus keep all html/java filesM external to the programs and just "include" them into the executable ... plus N synergy dibol easily ports from vms to unix, linux, windoze ... with dibol, itL is powerful, portable, and you can code for the internet, accounting, healthN care, anything, even vms system programming ... perl is just for the internet!   ------------------------------   Date: 19 Jan 2002 19:36:06 GMT8 From: Michal Jaegermann <michal@gortel.phys.ualberta.ca> Subject: Re: triple boot/ Message-ID: <a2chr6$fs0$1@pulp.srv.ualberta.ca>s  > In comp.os.linux.alpha Chris Adams <cmadams@hiwaay.net> wrote:  G > If you use UFS under Tru64, you should be able to read (haven't triedyF > write, but I think it should work) those partitions from Linux.  YouJ > can't access AdvFS domains from Linux (that's a proprietary filesystem).  E Current kernels have FreeVxFS support from Veritas (makers of AdvFS)./B How close is FreeVxFS to AdvFS I have no idea.  Probably not very.F I did not have an opportunity to try and see if reading of AdvFS would. be possible but I would be somewhat surprised.  + Here is a full entry from 'Configure.help':B  : FreeVxFS file system support (VERITAS VxFS(TM) compatible) CONFIG_VXFS_FSD   FreeVxFS is a file system driver that support the VERITAS VxFS(TM)C   file system format.  VERITAS VxFS(TM) is the standard file systemw@   of SCO UnixWare (and possibly others) and optionally available>   for Sunsoft Solaris, HP-UX and many other operating systems..   Currently only readonly access is supported.  >   NOTE: the file system type as used by mount(1), mount(2) andF         fstab(5) is 'vxfs' as it describes the file system format, not         the actual driver.  F   This file system is also available as a module ( = code which can beE   inserted in and removed from the running kernel whenever you want).tB   The module is called freevxfs.o.  If you want to compile it as aC   module, say M here and read <file:Documentation/modules.txt>.  IfB   unsure, say N. o  E > AFAIK, Tru64 has no support for reading anything that you can writee# > under Linux (except for CD-ROMs).   ? Well, you can always set up a common UFS partition.  One of UFSRD problems is that there is not one UFS but a number of variants of it9 which are the same but not quite.  'Configure.help' says:i  ) UFS file system write support (DANGEROUS)t CONFIG_UFS_FS_WRITEiB   Say Y here if you want to try writing to UFS partitions. This isE   experimental, so you should back up your UFS partitions beforehand.t  C In other words - you may try but better on a scratch partition. :-)m     Michal   ------------------------------  # Date: Sat, 19 Jan 2002 19:58:34 GMTe* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: triple boot? Message-ID: <Kdk28.1344$TC1.305503@bin5.nnrp.aus1.giganews.com>   E "Michal Jaegermann" <michal@gortel.phys.ualberta.ca> wrote in message4) news:a2chr6$fs0$1@pulp.srv.ualberta.ca...a@ > In comp.os.linux.alpha Chris Adams <cmadams@hiwaay.net> wrote: > I > > If you use UFS under Tru64, you should be able to read (haven't triednH > > write, but I think it should work) those partitions from Linux.  YouL > > can't access AdvFS domains from Linux (that's a proprietary filesystem). >iG > Current kernels have FreeVxFS support from Veritas (makers of AdvFS).   F AdvFS was written by Chris Saether and Debbie Girdler (and likely some# others) at DECWest, not by Veritas.a  D > How close is FreeVxFS to AdvFS I have no idea.  Probably not very.  F Definitely not very:  AdvFS was designed to be a DCE-style 'local file> system', complete with 'aggregates, 'cloning', etc.  VxFS is aK log-protected, extent-based Unix file system with (AFAIK) no such DCE-styleeH capabilities (though its underlying VxVM logical volume manager has someD similar features and indeed IIRC is used by Tru64 underneath AdvFS).   - bill   ------------------------------  % Date: Sat, 19 Jan 2002 21:02:45 -0500-# From: "Jeremy Ozer" <jozer@rcn.com>2 Subject: Re: triple boot+ Message-ID: <a2d8r6$r58$1@bob.news.rcn.net>u  E Wow!  5 OSs' and I can't even get one working!  Which brings me to myaI problem.  I got a DEC AlphaStation 500 333 Mhz and a 6 disk external SCSIaE hard drive array from my work, and I do not think that they were used J together.  The AlphaStation has an internal SCSI harddrive, of what size IL am not sure, but all the external disks are 4.3 Gig.  It says that it has NTH Server on it, but when I try to boot it, it gives me a message saying itK can't find that disk address or file.  I have a Win2k install disk, and theu4 newest BIOS, how should I go about installing Win2k?   Thanks,' Jeremy  H P.S.  When I tried to install Win2k, it extracted a bunch of files, thenJ gave me a blue screen of death saying that it couldn't find the boot disk. Please help!          ; Herman Zilverberg <zilverberg@t-online.de> wrote in message0) news:u4gthope0j5adc@news.supernews.com... ' > No problem if you have a raid server.. >.K > Actually i am running tru64 5.1, tru64 4.0, VMS7.3, Suse 7.1, Win2000 and0I > WinNT4 on the same machine (Alphaserver 2100 4/75 with 4 processors andp 512u	 > Mb ram)cL > The unit has a 2 times 2.1 Gb hd on the internal scsi bus and 8 hds (2.1GbJ > each) on the Mylex raid 960, which i configured as JBOD (Just a bunch ofI > disks). This gives me DKA0 and 1 for the Win stuff and DRA0 - 7 for thekL > rest. Each DRA can be booted from SRM by just typing b dra0, or dra1, etc. > Works without any problema: > Win2K and NT4 run from the bootmenue of the ARC console. >e > Greetingss > Harrys >nA > "Peter Watkinson" <peterw@u.genie.co.uk> schrieb im Newsbeitragr- > news:3c486e19.6826265@news.cable.ntl.com...- > >  > >e > > Hi,2 > >1G > > Does anyone know if it would be possible to triple boot linux, VMS,a( > > Tru64 off of SRM on the same system? > >.F > > Also would it be possible to have the three OS residing off of one > > hard disk. > >  > >  cheers, > >4 > >. > > Peter Watkinsont > > peterw@u.genie.co.uk >t >h   ------------------------------  % Date: Sat, 19 Jan 2002 14:32:11 -0500 # From: "Nobody" <nowhere@nobody.com>  Subject: Veritas Client for VMS / Message-ID: <u4jiea5ne6v95e@corp.supernews.com>r   Hi everyone,  H I am tasked with testing the Veritas Client for VMS and I was wondering:  + - Has anyone had success implementing this?F) - What kind of gotchas have you run into? G - Have you had problems restoring data during a data recovery exercise? F - Have you tried using the freeware VMS TAR to recover data from tape?  6 Any input you might have would be greatly appreciated.  3 Please direct any feedback to arobert@townisp.com .F   Thanks, 
 Andrew Robert  Principal Systems Analyst ( Enterprise Technology Services - OpenVMS  Massachusetts Financial Services Phone: (617) 954-5882C Fax:     (617) 954-7999    ------------------------------  # Date: Sun, 20 Jan 2002 04:05:46 GMTc1 From: "David J. Dachtera" <djesys.nospam@fsi.net>e# Subject: Re: Veritas Client for VMS.' Message-ID: <3C4A430C.D2514B8B@fsi.net>e  A Second-hand info. here. Based on input from my partner at work...l  
 Nobody wrote:j >  > Hi everyone, > J > I am tasked with testing the Veritas Client for VMS and I was wondering: > - > - Has anyone had success implementing this?D   No. Not in our case.  + > - What kind of gotchas have you run into?l  7 Everything from network bandwidth to disaster recovery.   I > - Have you had problems restoring data during a data recovery exercise?b  F Dunno. Never got that far with it. (Could never get the Veritas serverH to come up far enough to attempt a VMS recovery within the allotted time window for a DR test.)  H > - Have you tried using the freeware VMS TAR to recover data from tape?  H I would *NEVER* recommend even attempting that. Use BACKUP instead. That what it's there for.  5 > Please direct any feedback to arobert@townisp.com .e  - As Hoff says, "Ask here, get an answer here".n   -- o David J. Dachtera- dba DJE Systems- http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/j   ------------------------------   Date: 19 JAN 2002 19:50:31 GMT4 From: karcher@thuria.waisman.wisc.edu (Carl Karcher)D Subject: VMS721_SYS-V1100: Caution do not apply with Pathworks V6.0D6 Message-ID: <19JAN02.19503183@thuria.waisman.wisc.edu>  D After applying patch VMS721_SYS-V1100 (to an Alphaserver 1200 5/533)G and rebooting, PWRK$LMSRV.EXE (from Pathworks V6.0D) crashed the systemb with:u  A   "INVSECURESTATE, Invalid state detected by SECURITY subsystem" k  & shortly after starting up. The PC was:  % 	NSA$DEREFERENCE_RIGHTS_CHAIN_C+0008C   + This was repeatable (same thing next time).(  H After renaming the SECURITY.EXE_OLD and SECURITY_MON.EXE_OLD to *.EXE inF SYS$LOADABLE_IMAGES and rebooting the crash no longer occurred. We hadH previously installed VMS721_SYS-V1000 so the problem was introduced withB V11 of this patch. The problem has been reported to CSC (Pathworks  handed it off to the VMS group).  D VMS721_SYS-V1100 was one of 14 patches I applied in a single PRODUCTB INSTALL session followed by a single reboot. I've always done thisF (except for one patch that said not too) and never had a problem. ThisF time it was an example of the risks of applying more than one patch atH the same time. In this case the bugcheck code pretty much pointed to theG SECURITY*.EXE images (and a search on DSNlink confirmed it) so recoveryoD was fairly simple. Next time I may not be so lucky (but I had a good backup).   ------------------------------  % Date: Sat, 19 Jan 2002 20:44:17 -0800a& From: name99@mac.com (Maynard Handley)O Subject: Re: Younger recruits versus experienced veterans ( was Re:     The dem'7 Message-ID: <name99-1901022044170001@handma2.apple.com>s  J In article <bruce-BCBAE6.14465712012002@news.paradise.net.nz>, Bruce Hoult <bruce@hoult.org> wrote:  B > In article <3381.776T2711T7025736@sky.bus.com>, "Charlie Gibbs"  > <cgibbs@sky.bus.com> wrote:s > C > > Thanks for the sermon.  One of the reasons Apple irritates many @ > > people is that they seem to claim total knowledge of what is? > > "intuitive" and what isn't.  Anyone who disagrees with them ? > > obviously has his brain wired incorrectly; how dare someone @ > > suggest that what's intuitive to one person might be totally > > opaque to someone else?k >  > But they *don't* claim that. > J > What Apple does (or at least did 15 years ago) and which pretty much no F > one else does (then or now) is implement the same functionallity in K > every reasonable way they can think of and then *TEST* it on real people IE > and carefully record and analyse to see which techniques cause the   > fewest user mistakes.  > H > Of course no one does this because it's ten times more expensive than D > just implementing the first thing you think of and stopping there.  H Apple, of course (and I am quite serious here) no longer do this either.G There are still ten variants coded up, but they are all showed to StevenJ Jobs, not "the public" who then decides what he wants. Hence the continualF fury by almost everyone but Steve Jobs at the UI decisions in MacOS X.   Maynard    ------------------------------  % Date: Sat, 19 Jan 2002 21:43:41 -0800-& From: name99@mac.com (Maynard Handley)V Subject: Re: Younger recruits versus experienced veterans ( was The demise of compaq )7 Message-ID: <name99-1901022143410001@handma2.apple.com>w  J In article <20020113130550.5b01c771.steveo@eircom.net>, Steve O'Hara-Smith <steveo@eircom.net> wrote:  $ > On Sun, 13 Jan 2002 11:49:09 +01002 > Paul Sture <paul.sture@bluewin.delete.ch> wrote: > O > PS> Let's face it - English is a crazy language. There is no egg in eggplant,  > L >         In honour of Frederick Brown - English is a crazy language, I like > it.L > I > PS> nor ham in hamburger; neither, apple nor pine in pineapple. EnglishoP > PS> muffins weren't invented in England, or French fries in France. SweetmeatsJ > PS> are candies while sweetbreads, which aren't sweet, are meat. We takeH > PS> English for granted. But if we explore its paradoxes, we find thatL > PS> quicksand can work slowly, boxing rings are square and a guinea pig is* > PS> neither from Guinea nor is it a pig. > % >         Road works means it doesn'te. >         Common sense isn't common or a sense' >         Hot dogs aren't (usually) dogi$ >         Trust me (need I say more)$ > and one that puzzled me as a child& >         Lloyds Bank as your executor > N >         I have long believed that English is a language well evolved for theJ > purpose of shading the truth, saying nothing in many words and providingD > plausible deniability no matter what was said - in short politics.  9 And your linguistic qualifications and knowledge of otheryJ languages---Japanese, Arabic, Mandarin, Russian, Swahili are what exactly?  F Christ, I am so sick of these "based on my complete ignorance of everyJ other language [or nation or culture] on Earth I proclaim that English [orJ the US or Christians] are the [most | least] [awful | decent | difficult |& greedy | kind | etc ] ever" type post.   Maynard    ------------------------------  # Date: Sat, 19 Jan 2002 22:00:41 GMT 4 From: Tim Llewellyn <tim.llewellyn@blueyonder.co.uk>> Subject: Re: [OT / Humor] Things not to do on a *nix system...0 Message-ID: <3C49EBA0.D0E0D4B9@blueyonder.co.uk>   Carl Perkins wrote:  > 3 > Kilgallen@SpamCop.net (Larry Kilgallen) writes...oT > }In article <3C485C79.38FF5910@rdrop.com>, Dean Woodward <deanw@rdrop.com> writes:K > }> This is *not* meant to slam the *nix family of O/Ss.  I'm one of thoseoM > }> freaks that can see a place for everything and uses Windows and Linux on I > }> the desktop.  But the "humor" of the situation below was too much toe
 > }> pass up.  > }>F > }> A friend who teaches at a local higher-education institution justK > }> checked in on another list I'm subscribed to.  All their Solaris boxeneH > }> are down this morning; details are sketchy, but apparently somebodyJ > }> suffered a case of the clevers and thought it would be interesting toL > }> see what all gets redirected to /dev/null on a *nix box, so he replacedM > }> /dev/null with a file.  (Obviously, this would make him a system manglery: > }> of some sort, to have the rights to even attempt it.) > }>D > }> Shame he forgot to fix the file permissions on his new improvedF > }> "/dev/null" so that common users could write to it, though... ;-) > }nA > }Doing the equivalent on VMS should be straightforward as well,, > }given SYSNAM privilege. > 4 > Sure, but how many things would it actually break? > I > I don't think very many things on VMS require a writeable NLA0: device.oF > From the above, it looks like simply logging in requires a writeableF > /dev/null on Solaris. (I can't imagine why - what is the login doingD > that requires it to write, ar at least be able to write, something > to nowhere?)  @ presumably you have to open /dev/null to be able to write to it.  J My take is that you MUST learn to test from a non-priv'd (VMS) or non-root+ (*nix) account after making mods like this.r   regards  > 
 > --- Carl   --   Tim.Llewellyn@cableinet.co.uk     C Standard disclaimer applies. My views in no way represent those of  ! my employers or service provider.t   ------------------------------  % Date: Sun, 20 Jan 2002 01:51:22 -0500a  From: John Santos <JOHN@egh.com>> Subject: Re: [OT / Humor] Things not to do on a *nix system...6 Message-ID: <1020120012906.19335B-100000@Ives.egh.com>  # On 19 Jan 2002, Carl Perkins wrote:e  3 > Kilgallen@SpamCop.net (Larry Kilgallen) writes...eT > }In article <3C485C79.38FF5910@rdrop.com>, Dean Woodward <deanw@rdrop.com> writes:K > }> This is *not* meant to slam the *nix family of O/Ss.  I'm one of thosecM > }> freaks that can see a place for everything and uses Windows and Linux onaI > }> the desktop.  But the "humor" of the situation below was too much to/
 > }> pass up.  > }> eF > }> A friend who teaches at a local higher-education institution justK > }> checked in on another list I'm subscribed to.  All their Solaris boxenrH > }> are down this morning; details are sketchy, but apparently somebodyJ > }> suffered a case of the clevers and thought it would be interesting toL > }> see what all gets redirected to /dev/null on a *nix box, so he replacedM > }> /dev/null with a file.  (Obviously, this would make him a system manglerx: > }> of some sort, to have the rights to even attempt it.) > }> nD > }> Shame he forgot to fix the file permissions on his new improvedF > }> "/dev/null" so that common users could write to it, though... ;-) > } A > }Doing the equivalent on VMS should be straightforward as well,- > }given SYSNAM privilege. > 4 > Sure, but how many things would it actually break? > I > I don't think very many things on VMS require a writeable NLA0: device.eF > From the above, it looks like simply logging in requires a writeableF > /dev/null on Solaris. (I can't imagine why - what is the login doingD > that requires it to write, ar at least be able to write, something > to nowhere?) > 
 > --- Carl  C There may exist programs that normally write to some device or file @ but are usually run with that output directed to /dev/null so itC just gets thrown away.  These programs may be required for a normalaA login, or may be commonly invoked in a typical .login, etc. file.i< (This could easily be invisible to the user, since the login= program or one of the setup programs or the shell might spawnA$ them with a fork() or system() call.  = If /dev/null becomes read-only, these programs may detect theS write errors and abort.t  ; Another possibility is lack of write access caused an errorW< when programs try to open the file.  (They are explicitly or: implicitly requesting write access, and so open returns an1 error instead of just granting read-only access.)   > When I first read this post, I had an entirely different guess> as to the cause of the problem.  I thought they had managed to@ lock up the system disk by quickly filling with large amounts of; junk written to /dev/null.  Another possibility was the 1str; process to open /dev/null owned it, and every other processa; attempting to use it died with the Unix equivalent of "Filea= currently locked by another user".  However, Dean did say theu= original problem was caused by lack of world write permissioni9 on the /dev/null file.  What happened when they fixed the > file protection?  Did the system work (at least until the disk filled up?)s  = I am not a Unix expert, so this is all speculation.  However,c; these are the things I would look at if I was attempting to  debug this situation.r  8 I think redirecting NL:, NL0:, NLA: and NLA0: (any other7 required logicals?) on VMS to point to a file would, ift> it and its directory were world-writeable, probably work until: the 32768'th attempt to open it, when something would die.> Maybe.  If the program was using $QIO to read/write NLA0:, and; assigned an I/O channel to a disk instead, but failed to dor7 the necessary IO$_ACCESS calls to access the files, the1< IO$_[READ|WRITE]VBLK's would fail.  If the program was using? IO$_WRITEPBLK or IO$_WRITELBLK, and was sufficiently privilegedc> (PHY_IO or LOG_IO), then bye, bye disk...   If the program wasA using RMS, then RMS would recognize that it was a file-structuredT> disk and do the IO$_ACCESS and would also use IO$_WRITEVBLK's, so not problems there.   -- p John Santosm Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Sat, 19 Jan 2002 19:42:58 GMTF* From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: [Q] Why is there the limit of 8 levels of directories? Message-ID: <6%j28.1055$TC1.288553@bin5.nnrp.aus1.giganews.com>V  7 "Arne Vajhj" <arne.vajhoej@gtech.com> wrote in messagee# news:3C49AF99.A0A8DB2E@gtech.com...e > "Alan E. Feldman" wrote:6 > > Why is there the limit of 8 levels of directories? >aF > I would phrase it as "why were there a 8 level limit on directories"7 > since current version does not have this restriction.v >m= > A good guess would be that each level adds a small overhead @ > to accessing a file. It is nothing on an EV6 Alpha. But it mayD > actually have been noticable on VAX 7xx's. I think VMS engineering/ > tried to protect people from bad performance.D  K It's almost exactly the same performance hit on an EV6 Alpha as it was on akI uVAX I, since virtually all the perceivable overhead is in the additionalzH disk accesses (well, disks have gotten faster too, but nowhere nearly as	 much so).t  K My vague recollection is that it was simply considered a 'reasonable' limitwJ 'way back when, given that memory was tight (VMS V1 would run in 256 KB ofK memory, IIRC) and internal system structures maintained the entire expandedsH path string in (likely non-pageable) memory.  Rather than just limit theK expanded path length (which could have produced hard-to-understand behavior'B depending on the size of its individual constituents, logical nameJ expansions, etc.), a hard limit of levels was defined (I suspect such thatH the max path length could not be exceeded even with the longest possible individual elements).s   - bill   ------------------------------  % Date: Sat, 19 Jan 2002 21:37:56 +0100v= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> B Subject: Re: [Q] Why is there the limit of 8 levels of directories) Message-ID: <3C49D924.BF0483F5@gtech.com>r   Bill Todd wrote:? > > A good guess would be that each level adds a small overhead B > > to accessing a file. It is nothing on an EV6 Alpha. But it mayF > > actually have been noticable on VAX 7xx's. I think VMS engineering1 > > tried to protect people from bad performance.y > M > It's almost exactly the same performance hit on an EV6 Alpha as it was on auK > uVAX I, since virtually all the perceivable overhead is in the additionalPJ > disk accesses (well, disks have gotten faster too, but nowhere nearly as > much so).e  : 1)  Disks has become a lot faster from VAX 7xx's to EV6's.>     Maybe "just" a factor 20-100, but that may be noticeable !  > 2)  VMS has cached directories for a long time. And then it is2     CPU and memory that determines speed not disk.   Arne   ------------------------------  # Date: Sat, 19 Jan 2002 21:20:53 GMTu* From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: [Q] Why is there the limit of 8 levels of directories? Message-ID: <Vql28.5516$QB1.413429@bin3.nnrp.aus1.giganews.com>-  7 "Arne Vajhj" <arne.vajhoej@gtech.com> wrote in message # news:3C49D924.BF0483F5@gtech.com...C > Bill Todd wrote:A > > > A good guess would be that each level adds a small overheadhD > > > to accessing a file. It is nothing on an EV6 Alpha. But it mayH > > > actually have been noticable on VAX 7xx's. I think VMS engineering3 > > > tried to protect people from bad performance.  > >iJ > > It's almost exactly the same performance hit on an EV6 Alpha as it was on aB > > uVAX I, since virtually all the perceivable overhead is in the
 additionalL > > disk accesses (well, disks have gotten faster too, but nowhere nearly as
 > > much so).: > < > 1)  Disks has become a lot faster from VAX 7xx's to EV6's.@ >     Maybe "just" a factor 20-100, but that may be noticeable !  G IIRC hard disk seek times (the dominating factor in perceived deep-path.L look-up performance) have improved by about a factor of 10 over the past twoK decades (and I did mention such improvement above, though it has nothing toiH do with the comparison you made, which was between processors).  And theK *percentage* incremental cost of adding a directory level is still the sameh in both cases.   >l@ > 2)  VMS has cached directories for a long time. And then it is4 >     CPU and memory that determines speed not disk.  I If you've got an early VAX handy, I suspect you'll find that there's *no* E noticeable difference in response-time between, say, a 3-level and antK 8-level look-up, if all levels are indeed cached:  there wasn't *that* muchw# extra processing activity involved.?   - bill   ------------------------------  % Date: Sat, 19 Jan 2002 16:34:27 -0500'' From: Glenn Everhart <Everhart@gce.com>aB Subject: Re: [Q] Why is there the limit of 8 levels of directories' Message-ID: <3C49E662.9FEB88B1@gce.com>b  O Chances are this notion of increased time for deeper directories is an artifact H of unix thinking. Unix typically does traverse the whole tree with everyJ access; it is instructive to watch requests at, say, an NFS server and seeH this. VMS on the other hand tends to have the file IDs cached inside RMSM (this was essentially always true on VAX; there are more exceptions on alpha)hO so that a lookup in a directory that is already accessed will result in a bunchfL of accesses with the FID set up in the FIB. This can be interesting to watch6 in a kernel debugger or the like too (as I have done).  K There is some overhead in each level on the first access, but VMS is prettys, aggressive about caching this sort of thing.     Bill Todd wrote: > 9 > "Arne Vajhj" <arne.vajhoej@gtech.com> wrote in messageE% > news:3C49D924.BF0483F5@gtech.com...u > > Bill Todd wrote:C > > > > A good guess would be that each level adds a small overhead F > > > > to accessing a file. It is nothing on an EV6 Alpha. But it mayJ > > > > actually have been noticable on VAX 7xx's. I think VMS engineering5 > > > > tried to protect people from bad performance.g > > >oL > > > It's almost exactly the same performance hit on an EV6 Alpha as it was > on aD > > > uVAX I, since virtually all the perceivable overhead is in the > additionalN > > > disk accesses (well, disks have gotten faster too, but nowhere nearly as > > > much so).n > >e> > > 1)  Disks has become a lot faster from VAX 7xx's to EV6's.B > >     Maybe "just" a factor 20-100, but that may be noticeable ! > I > IIRC hard disk seek times (the dominating factor in perceived deep-path9N > look-up performance) have improved by about a factor of 10 over the past twoM > decades (and I did mention such improvement above, though it has nothing toeJ > do with the comparison you made, which was between processors).  And theM > *percentage* incremental cost of adding a directory level is still the sameu > in both cases. >  > > B > > 2)  VMS has cached directories for a long time. And then it is6 > >     CPU and memory that determines speed not disk. > K > If you've got an early VAX handy, I suspect you'll find that there's *no*yG > noticeable difference in response-time between, say, a 3-level and anlM > 8-level look-up, if all levels are indeed cached:  there wasn't *that* mucht% > extra processing activity involved.  >  > - bill   ------------------------------   End of INFO-VAX 2002.037 ************************