INFO-VAX Tue, 20 Mar 2007 Volume 2007 : Issue 157 Contents: Re: AMD's well may be running dry Re: AMD's well may be running dry Re: AMD's well may be running dry Re: AMD's well may be running dry Re: AMD's well may be running dry Re: AMD's well may be running dry Re: AMD's well may be running dry Re: AMD's well may be running dry Re: Comments on my license reuse plan Re: Itanium exception handling performance Re: Itanium exception handling performance Mikey and Richard "Dick" Scoville, Sodomy Twins Problems zipping RBF file Re: Problems zipping RBF file Re: Problems zipping RBF file Re: RMS indexed file structure questions Re: RMS indexed file structure questions Re: Suggestion for the VMS X-windows server Re: Suggestion for the VMS X-windows server Re: Suggestion for the VMS X-windows server Re: Suggestion for the VMS X-windows server Re: Suggestion for the VMS X-windows server Re: Switch to PREFERRED_PATH on HSZ80 and VMS 7.2-1 Re: Switch to PREFERRED_PATH on HSZ80 and VMS 7.2-1 Re: Switch to PREFERRED_PATH on HSZ80 and VMS 7.2-1 Re: SYSMAN IO SET EXCLUDE question Re: SYSMAN IO SET EXCLUDE question Re: SYSMAN IO SET EXCLUDE question ---------------------------------------------------------------------- Date: Mon, 19 Mar 2007 12:12:20 -0400 From: "William Webb" Subject: Re: AMD's well may be running dry Message-ID: <8660a3a10703190912o1aa45e58obcf265e3bd39f20d@mail.gmail.com> ------=_Part_105085_20514026.1174320740843 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 3/19/07, Dr. Dweeb wrote: > > Andrew wrote: > > On 18 Mar, 19:49, "Dr. Dweeb" wrote: > >> Bill Todd wrote: > >>> Dr. Dweeb wrote: > >> > Non of this alters the obvious economic issue which is that man made > > CO2 comes mainly from burning fossil fuels, these are running out or > > becoming increasing expensive to exploit. Whatever the cause of GW the > > reality is that we need to wean ourselves of fossil fuels before they > > become too scarce and too expensive for our economies to support. > > > > I continue to agree with this sentiment. > > > Regards > > Andrew Harrison > > Whatever the cause of GW the > > reality is that we need to wean ourselves of fossil fuels before they > > become too scarce and too expensive for our economies to support. > > At the risk of causing outrage among some members of this discussion, this what is known as "the free market working". The increase in price will cause a greater adoption of alternatives to fossil fuels without the need for government fiat (play on words intended because humor is an extremely scarce commodity in this discussion). As an example, the discontinuation of the use of whale oil didn't happen because everybody suddenly got their consciousness raised concerning the intelligence of cetaceans, it occurred because more economical alternatives became widely available. Those of you with a greater amount of curiosity about market economics, price as a means of conveying market knowledge and so forth should consider reading Dr. Thomas Sowell's "Applied Economics: Thinking Beyond Stage One." In fact, I highly recommend anything that the man has written. WWWebb ------=_Part_105085_20514026.1174320740843 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 3/19/07, Dr. Dweeb <spam@dweeb.net> wrote:
Andrew wrote:
> On 18 Mar, 19:49, "Dr. Dweeb" <s...@dweeb.net > wrote:
>> Bill Todd wrote:
>>> Dr. Dweeb wrote:
>>
 
<snip>

> Non of this alters the obvious economic issue which is that man made
> CO2 comes mainly from burning fossil fuels, these are running out or
> becoming increasing expensive to exploit. Whatever the cause of GW the
> reality is that we need to wean ourselves of fossil fuels before they
> become too scarce and too expensive for our economies to support.
>

I continue to agree with this sentiment.

> Regards
> Andrew Harrison

 Whatever the cause of GW the
> reality is that we need to wean ourselves of fossil fuels before they
> become too scarce and too expensive for our economies to support.
>
 
At the risk of causing outrage among some members of this discussion, this what is known as "the free market working".  The increase in price will cause a greater adoption of alternatives to fossil fuels without the need for government fiat (play on words intended because humor is an extremely scarce commodity in this discussion).
 
As an example, the discontinuation of the use of whale oil didn't happen because everybody suddenly got their consciousness raised concerning the intelligence of cetaceans, it occurred because more economical alternatives became widely available.
 
Those of you with a greater amount of curiosity about market economics, price as a means of conveying market knowledge and so forth should consider reading Dr. Thomas Sowell's "Applied Economics:  Thinking Beyond Stage One."
 
In fact, I highly recommend anything that the man has written.
 
WWWebb

 

------=_Part_105085_20514026.1174320740843-- ------------------------------ Date: 19 Mar 2007 17:19:19 -0700 From: "AEF" Subject: Re: AMD's well may be running dry Message-ID: <1174349959.472204.246410@y66g2000hsf.googlegroups.com> On Mar 19, 7:56 am, "Andrew" wrote: > On 18 Mar, 19:59, dav...@montagar.com wrote: > > > On Mar 17, 1:25 pm, Bill Todd wrote: > > > > dav...@montagar.com wrote: [...] > > And some of the "cures" I'm not sure are better than the "disease". > > Let's all switch to flouresent lights. Now will have lots of mercury > > and other toxic items from the ballasts filling out landfills rather > > than glass/alumimum/copper/tungsten. Not sure that's what I want > > leaching into my water supplies... We're all in a tizzy about global > > warming, and jumping on a "solution" that may not be as good as we > > think long term. Also what about the manufacturing costs of those > > CFL's? Is the CO2 we save lighting our house being consumed producing > > the bulbs? Who's done that analysis? > > Fluorescent lights contain very small amounts of mercury which is why > you should not put them in the trash/rubbish. But they can be recycled > safely and these recycling facilities will come on tap as the > traditional light business is phased out. > > Yes CFL's require more energy to manufacture than traditional lights > but this is easily offset by their much longer life (7-10x) and the > energy savings while using them. Of course. It certainly doesn't take 100 W of power running for several years to manufacture a light bulb. If it did, they'd certainly cost a lot more! > > And reducing the amount of fossil fuel burnt to light our homes no > only reduces CO2 emmisions but also reduces the other toxic pollutants > produced during the generation process in much larger quantities than > the mercury used in the CFL's. Ironically one of the toxic pollutants > produced by fossil fuel power plants is mercury and the net effect of > using CFL's is actually to reduce the amount of mercury in the > environment. > > Of course CFL's are not the only game in town, LED's may well replace > them offering greater efficiency and even longer life. [shameless plug warning:] Another overlooked idea is to use more efficient lighting fixtures outdoors. Most outdoor lighting is notoriously inefficient not necessarily becuase of inefficient bulbs, but because of inefficient and/or badly aimed fixtures! Look at the sky at night, especially if it's cloudy. Look how bright the sky is! That's from the light wasted by inefficient fixtures. By switching to full cutoff fixtures, we can redirect that wasted light back to earth where it's needed. Then we can use lower wattage bulbs to achieve the same lighting levels we had before. This also reduces glare, thereby improving visibility. See http://www.darksky.org for more information about fighting light pollution, which has the added side benefit of reducing energy consumption and thereby reducing humans' contribution to global warming. [...] AEF ------------------------------ Date: Mon, 19 Mar 2007 20:27:18 -0400 From: Bill Todd Subject: Re: AMD's well may be running dry Message-ID: William Webb wrote: ... > Whatever the cause of GW the > > reality is that we need to wean ourselves of fossil fuels before > they > > become too scarce and too expensive for our economies to support. > > > > > At the risk of causing outrage among some members of this discussion, > this what is known as "the free market working". The increase in price > will cause a greater adoption of alternatives to fossil fuels without > the need for government fiat (play on words intended because humor is an > extremely scarce commodity in this discussion). I'm afraid that's an extremely superficial analysis. The free market does not look ahead very well: it's mostly driven by *current* reality. Whereas the kinds of changes you're imagining will occur 'automagically' as prices for fossil fuels rise can take a very long time indeed to implement (far longer than the free market horizon will account for). At best, the result is that, left to the free-market, major temporary (on the order of a decade or less, which some might not consider all that temporary) problems will arise: prices that force most people to alter their behavior radically and on short notice while the industries affected scurry to adjust. Converting most new vehicles to run mostly on ethanol (to pick one example the analysis of which is informative even if the desirability of that specific response to the problem may be in doubt) could conceivably be done in two or three years - but it would take another decade or so before the demand for gasoline trailed off commensurately because that's how long *pre-existing* vehicles would continue running. And of course that's ignoring the latencies in getting high levels of ethanol production and distribution up and running. How about home (and commercial) heating and cooling, another major consumer of fossil fuels? The best solutions there involve rather fundamental building design: if you thought waiting for existing cars to be replaced took a long time, consider that existing buildings have at least an order of magnitude longer lifetimes than cars do (i.e., we really should have started redesigning new buildings not long after WWII to be anywhere nearly ready for major changes in their collective energy use within our lifetime: the free market wasn't worth squat in that regard, and even now has only begun to take very small steps in that direction - there are innovative exceptions, but they mostly serve only as proofs of concept - because heating costs still aren't high enough yet). That's just talking about use of fossil fuel as fuel: how about its non-fuel use in producing things like plastics? What will the kind of cost-overshoot that's likely (in large part due to continued consumption as fuel far beyond the point where we *could* have started significantly weaning ourselves off of it) do to other major industries and the prices of their products? Free-market Utopians aren't very good at providing answers to such questions, because the free market isn't very good at providing anything approaching optimal solutions for them: the forward vision in its 'invisible hand' is far too myopic. - bill ------------------------------ Date: Mon, 19 Mar 2007 22:01:55 -0400 From: "William Webb" Subject: Re: AMD's well may be running dry Message-ID: <8660a3a10703191901r64e30090m7a3f5b8a3a269f70@mail.gmail.com> ------=_Part_115489_19800612.1174356115698 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 3/19/07, Bill Todd wrote: > > William Webb wrote: > > ... > > > Whatever the cause of GW the > > > reality is that we need to wean ourselves of fossil fuels before > > they > > > become too scarce and too expensive for our economies to support. > > > > > > > > > At the risk of causing outrage among some members of this discussion, > > this what is known as "the free market working". The increase in price > > will cause a greater adoption of alternatives to fossil fuels without > > the need for government fiat (play on words intended because humor is an > > extremely scarce commodity in this discussion). > > I'm afraid that's an extremely superficial analysis. > > The free market does not look ahead very well: it's mostly driven by > *current* reality. Whereas the kinds of changes you're imagining will > occur 'automagically' as prices for fossil fuels rise can take a very > long time indeed to implement (far longer than the free market horizon > will account for). > > At best, the result is that, left to the free-market, major temporary > (on the order of a decade or less, which some might not consider all > that temporary) problems will arise: prices that force most people to > alter their behavior radically and on short notice while the industries > affected scurry to adjust. Converting most new vehicles to run mostly > on ethanol (to pick one example the analysis of which is informative > even if the desirability of that specific response to the problem may be > in doubt) could conceivably be done in two or three years - but it would > take another decade or so before the demand for gasoline trailed off > commensurately because that's how long *pre-existing* vehicles would > continue running. > > And of course that's ignoring the latencies in getting high levels of > ethanol production and distribution up and running. > > How about home (and commercial) heating and cooling, another major > consumer of fossil fuels? The best solutions there involve rather > fundamental building design: if you thought waiting for existing cars > to be replaced took a long time, consider that existing buildings have > at least an order of magnitude longer lifetimes than cars do (i.e., we > really should have started redesigning new buildings not long after WWII > to be anywhere nearly ready for major changes in their collective energy > use within our lifetime: the free market wasn't worth squat in that > regard, and even now has only begun to take very small steps in that > direction - there are innovative exceptions, but they mostly serve only > as proofs of concept - because heating costs still aren't high enough > yet). > > That's just talking about use of fossil fuel as fuel: how about its > non-fuel use in producing things like plastics? What will the kind of > cost-overshoot that's likely (in large part due to continued consumption > as fuel far beyond the point where we *could* have started significantly > weaning ourselves off of it) do to other major industries and the prices > of their products? > > Free-market Utopians aren't very good at providing answers to such > questions, because the free market isn't very good at providing anything > approaching optimal solutions for them: the forward vision in its > 'invisible hand' is far too myopic. > > - bill Your use of the word Utopian implies that those favoring free markets are unrealistic. Compared to a centralized planning solution such as you propose? I subscribe to the libertarian economics of the Austrian school of Von Mises, Hayek, Friedman and Sowell. Free markets have made more things possible and created a better standard of living for more people on this planet than any other sort of market. And the "forward vision" of most intellectuals has historically favored the totalitarian worldview over the one favoring human liberty. And this goes back hundreds, if not thousands of years. WWWebb ------=_Part_115489_19800612.1174356115698 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 3/19/07, Bill Todd <billtodd@metrocast.net> wrote:
William Webb wrote:

...

>      Whatever the cause of GW the
>      > reality is that we need to wean ourselves of fossil fuels before
>     they
>      > become too scarce and too expensive for our economies to support.
>      >
>
>
> At the risk of causing outrage among some members of this discussion,
> this what is known as "the free market working".  The increase in price
> will cause a greater adoption of alternatives to fossil fuels without
> the need for government fiat (play on words intended because humor is an
> extremely scarce commodity in this discussion).

I'm afraid that's an extremely superficial analysis.

The free market does not look ahead very well:  it's mostly driven by
*current* reality.  Whereas the kinds of changes you're imagining will
occur 'automagically' as prices for fossil fuels rise can take a very
long time indeed to implement (far longer than the free market horizon
will account for).

At best, the result is that, left to the free-market, major temporary
(on the order of a decade or less, which some might not consider all
that temporary) problems will arise:  prices that force most people to
alter their behavior radically and on short notice while the industries
affected scurry to adjust.  Converting most new vehicles to run mostly
on ethanol (to pick one example the analysis of which is informative
even if the desirability of that specific response to the problem may be
in doubt) could conceivably be done in two or three years - but it would
take another decade or so before the demand for gasoline trailed off
commensurately because that's how long *pre-existing* vehicles would
continue running.

And of course that's ignoring the latencies in getting high levels of
ethanol production and distribution up and running.

How about home (and commercial) heating and cooling, another major
consumer of fossil fuels?  The best solutions there involve rather
fundamental building design:  if you thought waiting for existing cars
to be replaced took a long time, consider that existing buildings have
at least an order of magnitude longer lifetimes than cars do (i.e., we
really should have started redesigning new buildings not long after WWII
to be anywhere nearly ready for major changes in their collective energy
use within our lifetime:  the free market wasn't worth squat in that
regard, and even now has only begun to take very small steps in that
direction - there are innovative exceptions, but they mostly serve only
as proofs of concept - because heating costs still aren't high enough yet).

That's just talking about use of fossil fuel as fuel:  how about its
non-fuel use in producing things like plastics?  What will the kind of
cost-overshoot that's likely (in large part due to continued consumption
as fuel far beyond the point where we *could* have started significantly
weaning ourselves off of it) do to other major industries and the prices
of their products?

Free-market Utopians aren't very good at providing answers to such
questions, because the free market isn't very good at providing anything
approaching optimal solutions for them:  the forward vision in its
'invisible hand' is far too myopic.

- bill
 
Your use of the word Utopian implies that those favoring free markets are unrealistic.
 
Compared to a centralized planning solution such as you propose?
 
I subscribe to the libertarian economics of the Austrian school of Von Mises, Hayek, Friedman and Sowell.
 
Free markets have made more things possible and created a better standard of living for more people on this planet than any other sort of market.
 
And the "forward vision" of most intellectuals has historically favored the totalitarian worldview over the one favoring human liberty. 
 
And this goes back hundreds, if not thousands of years.
 
WWWebb
 
------=_Part_115489_19800612.1174356115698-- ------------------------------ Date: Mon, 19 Mar 2007 22:23:23 -0400 From: Bill Todd Subject: Re: AMD's well may be running dry Message-ID: William Webb wrote: ... > Your use of the word Utopian implies that those favoring free markets > are unrealistic. You need to work on your reading comprehension: my use of the word only suggests that those who believe that free markets eliminate the need for additional mechanisms (i.e., those who are Utopian rather than balanced in their embrace of the concept) are unrealistic. > > Compared to a centralized planning solution such as you propose? Begin with a false premise as you did above, and it's not surprising that garbage comes out the other end. My suggestion is that free markets don't solve all problems (and this one in particular) very well without some adult supervision. > > I subscribe to the libertarian economics of the Austrian school of Von > Mises, Hayek, Friedman and Sowell. I suspect that you don't understand them adequately - but if indeed they're as tunnel-visioned as your comments suggest they might be, they're rubbish (just as most unbalanced extremist views are). I haven't read Friedman (assuming that you mean Milton) in a long time, but as best I recall he was, while a bit over the top in some respects, still well aware that free markets weren't the best solution for *every* problem. Some of his ideas about the virtues of privatization have made it into the mainstream, and rightly so (I don't subscribe to traditional liberal ideals of government any more than I do to the opposite extreme). > > Free markets have made more things possible and created a better > standard of living for more people on this planet than any other sort of > market. No, they have not - not in isolation (where they have been more likely to generate revolts by the exploited and suppressed proletariat). Adequately moderated but still *largely* free markets have, though. > > And the "forward vision" of most intellectuals has historically favored > the totalitarian worldview over the one favoring human liberty. I see that you're not all that well-versed in the thinking of the intellectual founders of this country, either. But in any event, such generalizations (regardless of their dubious accuracy) have nothing to do with the specific subject in question here. - bill ------------------------------ Date: 19 Mar 2007 22:01:43 -0700 From: davidc@montagar.com Subject: Re: AMD's well may be running dry Message-ID: <1174366903.242492.24000@y80g2000hsf.googlegroups.com> On Mar 18, 8:30 pm, "AEF" wrote: > On Mar 18, 4:10 pm, dav...@montagar.com wrote: > > It's not irrelevant, as you later in your own post you state: "(though > > we should care about where *all* taxes go)" > > > So, appearently I SHOULD care about where all the taxes go, except a > > tax which you have some sort of philophical attachment to. That > > doesn't make any sense, Bill. How can you write that with a straight > > keyboard? What if all that tax money ended up in the pockets of Exxon/ > > Mobile? Would that be okay with you? Or would that suddenly not be > > irrelevant? > > So we can't do anything because it might cause some problem. I guess a > small risk of some money going to Exxon Mobil is worse than ruining > the climate of the planet (assuming it really is a problem). You need to understand the risks, and be sure they aren't worse than alternative. That's the basis for critical thinking. And there's no basis that simply adding a tax is going to make the world all better. > > > Which (as noted above) is indeed an answer, whether you agree with it or > > > not. > > > And what if the tax disbursement suddenly was disagreeable with you? > > You see, I just don't see imposing a tax as a "solution". I assure > > you that tax money is going to be spent somewhere, and if gets spent > > on things that encourage fossil fuel usage, then the tax is worse than > > not having it. > > If, if, if!!! What if the gov't puts the money in a stove and burns it > up! How do you come up with these things? How do you simply ignore the other half of the equation? > > Why just this issue, Bill? You recognize the importance of knowing > > where taxes go, but why is this tax so "holy" that it's disbursement > > is somehow beyond question, or appearently even consideration? > > > No, the question is not irrelevant. It's an unconfortable question, > > and you just don't have an answer for it. > > So where does gasoline tax go? > Where does the cigarette tax go? Dodging a question with a question, are we? > If one just starts a carbon tax, it can go into the general fund which > means it will help pay down the national debt. What's wrong with that? The Fed can't even keep the Social Security "lockbox" locked. The increase in the "general fund" will get nibbled away by special interest groups and the new bureacracy created to manage the tax. Take careful note of some of the verbiage used in Federal Budgets that use creative language to describe a reduced increase in a budget as a "budget CUT" despite in raw numbers, it's still a budget increase. > Can you give an example of some tax that sends money to some awful > place? (Maybe you can -- I'm just asking for examples.) Did you know tobacco farmers still receive federal subsidies? I'll tell you what would likely happen, this "carbon tax" would end up being used to provide "foreign aide" or "carbon offsets" or other WTO benefits to carbon polluting countries (after all, they need our help), which would help subsidize their products so we'll continue to buy them. Net result on CO2? 0%. Yeah, I'm a cynic, but you have to admit that this isn't a far-fetched result. ------------------------------ Date: 19 Mar 2007 22:12:12 -0700 From: davidc@montagar.com Subject: Re: AMD's well may be running dry Message-ID: <1174367532.441395.12260@b75g2000hsg.googlegroups.com> On Mar 18, 8:36 pm, "AEF" wrote: > The market will do its magic and provide an alternative. What if the > price of oil went up all on its own without any tax? Like today, alternatives are becoming more (and truly) competitive. > The tax money will help pay down the national debt, which if left > unaddressed can cause inflation or even hyperinflation. Won't happen. The money will either get spent "helping" those hurt by the added tax burden, which makes it ineffective, and/or otherwise consumed by the bureacracy such a new tax would create. > > It did. Many people worked the equations through and proposed > > experiments to VALIDATE that theory. You are proposing a theory that > > taxing fossil fuels will reduce CO2 emissions. I'm simply challenging > > your theory by following the equations through, specifically the money > > trail for starters. > > When the price of oil went up in 1973 and 1979, it reduced use of oil. > I've already said this. But it also make some oil that was previously "impractical" to retrieve worth extracting, thus actually boosting production of otherwise unproductive wells. > > And that's why I used the Monty Python reference, since it sounds good > > at first, until you really realize what he said. Just taxing > > something doesn't make it automatically a good idea, despite what > > others may think. > > It doesn't automatically make it a bad idea, either. It cuts both > ways. But in actual practice, it simply doesn't work. > > > Quantum mechanics is as crazy as nature gets, but is fully verified by > > > experiment, and you wouldn't have modern computers without it. > > > But you haven't proved taxing an item reduces it's usage. What about > > Income Tax? Wouldn't that tend to reduce income, since higher income > > levels are taxed at a higher rate (35%) than lower income levels? > > You don't buy income. And how do you know what the situation would be > if the higher rate went away? You don't. You're comaring apples to > nothing. But you work for it. You buy it terms of labor. Why work harder for reduced rate of return? > > based upon your taxation theory, the income tax is designed to reduce > > everyones income to a essentially minimum wage (where you pay $0 > > income tax). But that doesn't happen. Tax is not always a > > disincentive. > > No, my theory doesn't say that. You're convoluting it and I'm not > going to fall for it. But you saying your theory says that for taxing fossil fuels? ------------------------------ Date: 19 Mar 2007 22:37:27 -0700 From: davidc@montagar.com Subject: Re: AMD's well may be running dry Message-ID: <1174369047.927239.169560@y66g2000hsf.googlegroups.com> On Mar 18, 8:18 pm, "AEF" wrote: > > Yes, the tax money needs to go somewhere, and to whose benefit is it > > really being tweaked? I keep getting answers like "It doesn't matter" > > or "give it to the countries producing the most CO2". Which is either > > disingenius or downright counter-productive. And tweaking > > Well, the tax could help reduce the spiraling national debt. Finally, at least an attempt. Of course, I believe what would really happen is that special interest groups will simply nibble away at it. > > to achieve societal goals is not only nothing new, but often doesn't > > work, either. I'd wager that the true effect of this tax would > > benefit those already in the fossil fuel market, at the continued > > expense of the consumer. > > How do you figure that? Let's take an extreme example of a law that benefits those it's against: Who is financially benefiting from the fact that certain drugs are illegal. The makers of illegal drugs. Do the existing gasoline taxes reduce driving? No they help build new roads which help encourage increased driving, and despite the tax, we have more people driving and with larger vehicles (again, to the benefit of the oil companies). > When price goes up, usage goes down. What's so hard about that? > Sometimes the demand is very inelastic and that complicates things. Bingo. I don't believe the demand is as elastic as you think, and without a replacement for a fossil resource, all you do is artificially raise the price without providing a viable way to reduce CO2 emissions. ------------------------------ Date: 19 Mar 2007 21:53:17 -0700 From: "David B Sneddon" Subject: Re: Comments on my license reuse plan Message-ID: <1174366397.645243.309040@e1g2000hsg.googlegroups.com> On Mar 19, 3:18 pm, "tadamsmar" wrote: > We have looked high and low and cannot anything called contract, but > we bought all our systems and software legally. I cannot find > anything in any of our paperwork that limits our licenses or paks to a > single machine. > > Looks like transfers within a company, redesignations as they are > called, are legal if they are valid: > > http://licensing.hp.com/swl/view.slm?page=xfer Have you not read the back of the PAK certificate? Dave ------------------------------ Date: Mon, 19 Mar 2007 19:20:58 GMT From: John Reagan Subject: Re: Itanium exception handling performance Message-ID: Dan Foster wrote: > I'm curious -- why is exception handling performance so poor on Itanium? > > Lots of overhead? Translated calls? Something else? Noticed a mention of > this in passing in the BRUDEN presentation PDF and wondered about the > technical reasons for it. > > -Dan Pipelining has nothing to do with it. The extra context to save/restore is about half to blame, but it is also related to Intel Calling Standard that we use on OpenVMS I64. (We started with it and made some enhancements but using it allowed us to incorporate Intel compiler technology for the C++ compiler much quicker). VAX and Alpha have frame-pointers. When an exception occurs, software can quickly find out where the compilers (or hardware in the case of VAX) saved various registers (including the return address). That allows code to easily walk back up the stack. I64 does not have a frame pointer. The Intel Calling Standard is PC-based. So when an exception occurs, the system has to look up the PC (in a balanced tree, look at the SYS$SET_UNWIND_TABLE system service). Once the system finds the unwind info left behind by the compiler, it has to interpret it. It is a rather complicated set of data structures. Not as simple as the VAX register save masks or the Alpha Procedure Descriptor register save information. Items like the address of a routine's static handler is also encoded in these unwind descriptors unlike Alpha where the frame-pointer could quickly find the procedure descriptor which contains the static handler's address. All of this makes the LIB$I64_ calling standard routines and/or exception delivery much slower than their Alpha counterparts. We're looking at improving the performance as much as possible, but it is not trivial. -- John Reagan HP Pascal/{A|I}MACRO/COBOL for OpenVMS Project Leader Hewlett-Packard Company ------------------------------ Date: Mon, 19 Mar 2007 10:22:45 -0800 From: "Tom Linden" Subject: Re: Itanium exception handling performance Message-ID: On Mon, 19 Mar 2007 11:20:58 -0800, John Reagan wrote: > Dan Foster wrote: >> I'm curious -- why is exception handling performance so poor on Itanium? >> Lots of overhead? Translated calls? Something else? Noticed a mention >> of >> this in passing in the BRUDEN presentation PDF and wondered about the >> technical reasons for it. >> -Dan > > Pipelining has nothing to do with it. > > The extra context to save/restore is about half to blame, but it is also > related to Intel Calling Standard that we use on OpenVMS I64. (We > started with it and made some enhancements but using it allowed us to > incorporate Intel compiler technology for the C++ compiler much quicker). > > VAX and Alpha have frame-pointers. When an exception occurs, software > can quickly find out where the compilers (or hardware in the case of > VAX) saved various registers (including the return address). That > allows code to easily walk back up the stack. > > I64 does not have a frame pointer. The Intel Calling Standard is > PC-based. So when an exception occurs, the system has to look up the PC > (in a balanced tree, look at the SYS$SET_UNWIND_TABLE system service). > Once the system finds the unwind info left behind by the compiler, it > has to interpret it. It is a rather complicated set of data structures. > Not as simple as the VAX register save masks or the Alpha Procedure > Descriptor register save information. Items like the address of a > routine's static handler is also encoded in these unwind descriptors > unlike Alpha where the frame-pointer could quickly find the procedure > descriptor which contains the static handler's address. Mips did something similar, which was a real nusiance. It was not the right way to do then or is it now, for the reasons you cited. > > All of this makes the LIB$I64_ calling standard routines and/or > exception delivery much slower than their Alpha counterparts. We're > looking at improving the performance as much as possible, but it is not > trivial. > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: 19 Mar 2007 20:26:11 -0700 From: "Bed Wetter" Subject: Mikey and Richard "Dick" Scoville, Sodomy Twins Message-ID: <1174361171.614058.46780@e65g2000hsc.googlegroups.com> Borked Pseudo Mailed wrote: > FREQUENTLY ASKED QUESTIONS > About > JF MEZEI Why is it whenever I take a crap, you seem to be swimming among the turds in my toilet bowl?? ------------------------------ Date: Mon, 19 Mar 2007 15:03:21 -0700 From: DeanW Subject: Problems zipping RBF file Message-ID: <3f119ada0703191503p3a8bfa94w4addc17288cd35ff@mail.gmail.com> Oh, what a tangled web... On a DS20, VMS 7.2-1 / RDB 7.1-240 / ZIP 2.3 One customer site is insisting that database backups be transferred off to their primary backup system, rather than relying on the VMS system's DDS-3 tape. (Putting all their eggs in a Windows basket... I digress.) So we do a database backup to disk, which gets us RBF & AIJ files. To be careful, we want to encapsulate those in a ZIP file, right? ZIP won't handle the RBF, giving no reason- just won't store it. (see below) So now we have to BACKUP the RBF & AIJ files before we can ZIP them, to FTP them across town. It'd be nice to skip the BACKUP step, as the system's loaded down enough that (I'm told) BACKUP is causing performance issues. The disk this is being done on has ~70GB of free space. Any clues? I've thought about trying VMSTAR, but ideally we'd prefer to just skip the step altogether. -------------------->8 cut here 8<-------------------- EAGLE$ CD SYS$USER3:[RDB_DATABASES.BACKUPS] SYS$USER3:[RDB_DATABASES.BACKUPS] EAGLE$ zip "-V" LT$2007-03-19.zip LT$2007-03-19.RBF adding: LT$2007-03-19.RBF (stored 0%) EAGLE$ -------------------->8 cut here 8<-------------------- ------------------------------ Date: Mon, 19 Mar 2007 17:21:46 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Problems zipping RBF file Message-ID: <07031917214626_2020028F@antinode.org> From: DeanW > On a DS20, VMS 7.2-1 / RDB 7.1-240 / ZIP 2.3 2.3? Eeuww! Ptui! Ptui! Zip 2.32 and UnZip 5.52 are the current released versions, and are much less likely to cause trouble and waste time than older ones. http://www.info-zip.org/ http://www.info-zip.org/UnZip.html http://www.info-zip.org/Zip.html > ZIP won't handle the RBF, giving no reason- just won't store it. (see > below) "(stored 0%)" is not necessarily an indication of failure, but it might be. (It could simply mean that no compression was done.) Knowing nothing about an "RBF" file, I might suspect that its EOF datum does not agree with reality, and that might confuse Zip (especially an old one). A new one, using "-VV", may be harder to confuse with a malformed file. > So now we have to BACKUP the RBF & AIJ files before we can ZIP > them, to FTP them across town. It'd be nice to skip the BACKUP step, > as the system's loaded down enough that (I'm told) BACKUP is causing > performance issues. Zip 2.x and UnZip 5.x also can't cope with files bigger than 2GB, but I wouldn't expect BACKUP to solve that one. > The disk this is being done on has ~70GB of free space. No one cares about that. A full disk would probably lead to an informative message. > Any clues? I've thought about trying VMSTAR, but ideally we'd prefer > to just skip the step altogether. Not enough yet. DIRE /FULL on the mystery file might say something interesting. These files _are_ closed when you're looking at them, right? (I'd expect a different complaint if not, I suppose.) > EAGLE$ zip "-V" LT$2007-03-19.zip LT$2007-03-19.RBF > adding: LT$2007-03-19.RBF (stored 0%) > EAGLE$ How big is the resulting Zip archive? For a good time, what does "UnZip -Zv" say about it? ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Mon, 19 Mar 2007 19:01:03 -0600 From: David J Dachtera Subject: Re: Problems zipping RBF file Message-ID: <45FF324F.2EF03152@spam.comcast.net> DeanW wrote: > > Oh, what a tangled web... > > On a DS20, VMS 7.2-1 / RDB 7.1-240 / ZIP 2.3 > > One customer site is insisting that database backups be transferred > off to their primary backup system, rather than relying on the VMS > system's DDS-3 tape. (Putting all their eggs in a Windows basket... I > digress.) > > So we do a database backup to disk, which gets us RBF & AIJ files. To > be careful, we want to encapsulate those in a ZIP file, right? > > ZIP won't handle the RBF, giving no reason- just won't store it. (see > below) So now we have to BACKUP the RBF & AIJ files before we can ZIP > them, to FTP them across town. It'd be nice to skip the BACKUP step, > as the system's loaded down enough that (I'm told) BACKUP is causing > performance issues. > > The disk this is being done on has ~70GB of free space. > > Any clues? I've thought about trying VMSTAR, but ideally we'd prefer > to just skip the step altogether. > > -------------------->8 cut here 8<-------------------- > > EAGLE$ CD SYS$USER3:[RDB_DATABASES.BACKUPS] > SYS$USER3:[RDB_DATABASES.BACKUPS] > EAGLE$ zip "-V" LT$2007-03-19.zip LT$2007-03-19.RBF > adding: LT$2007-03-19.RBF (stored 0%) > EAGLE$ > > -------------------->8 cut here 8<-------------------- Well, Steve Schweda *IS* the ZIP/UNZIP guru these days! That said, yes - "stored 0%" means the file *WAS* stored in the archive, but was not compressed. The default compression level is 5 ("DeflateN"), I think, which means "give it a shot, but don't kill yourself". Try level 8 (DeflateX) or so: $ zip "-8V" archive_name filespec ...or... $zip/level=8/vms archive_name filespec For sure, level 9 will try the hardest, including trying to further compress .JPG, .ZIP and others where level 8 will leave them as-is and just "store 0%" them. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: 19 Mar 2007 18:55:29 -0700 From: "Hein RMS van den Heuvel" Subject: Re: RMS indexed file structure questions Message-ID: <1174355729.819290.73530@o5g2000hsb.googlegroups.com> On Mar 19, 12:56 am, JF Mezei wrote: > Hein RMS van den Heuvel wrote: > > > This is turning into quit the lesson! > > And it is very appreciated. And I am sure that someone bitten by a similar > problem later on will appreciate your having taken the time to document this for > me and Mr Google. That's what I am counting on. That's why I replied mostly with general descriptions, and not for the specific file in question (which is a well known file). > The problem I have is to generate the list of bad blocks/buckets. This is a 50k > block file with a few thousand bad blocks. All the standard tools such as > ANA/RMS just choke at the first one. That's not really that big a file. Attached you'll find a simple skeleton Macro program which will happily bruteforce it is way through an indexed file lookign for valid data buckets, a block at a time untill it hits an other one. As written it will attempt to extract records, but that only works for Prologue-1 uncompressed files. So you'll have to modify it to perhaps just print a list of valid bucket starts. Or modify it to update the NEXT pointer in the last known good bucket to point to any next good bucket. They may be totally out of order, but a CONVERT/SORT will take care of that. The program takes liberties which may not be valid for the file. For example it assumes that FAB$B_BKS = Data Bucket Size. This is likely but not certain. It could also readily be improved to read large chunks and use pointers to more forwards, but why worry about 50,000 IOs between friends !? > And I also want an idea of exactly how much have lost from the file and record > which key ranges were lost. I have a 1 year old backup and may then see if any > of the missing records can be sourced from the old file. Good plan. If the key is unique then a simple CONV/MERG/EXC can be used to 'backfill' lost records with ancient copies. > But for a large file, manual scanning doesn't work. Right. You'll need to code up a tool, or send me money. > partial reconstruction can be made from the email file as > well as the private docdb records which have pointers to the corrupted file and > a few copies of the fields. That's often a good way to approach broken files. External reference may well be able to generate a list of key (sic) values. > So I can then safely modify the nxtbkt fields to skip over totally empty buckets then. Ayup. > Out of curiosity, is this documented somewhere regular humans have access to ? It'll be in my book :-). It was in the old RMS traning 'Digital' used to offer. I've done several Decus presentations covering it. In front of me I have paper copy of a 1988 document by Kirby McCoy which was going to be a Part II in the VMS Guide to File Internals covering RMS On Disk structures. I have never found a machine readable version for that :-(. I do have a machine readable (.TXT :-) version of a Spring'85 DECUS presentation Jim Teague (ex-Isam developer) made. It stick that in the next reply. > The ability to ring an alarm bell to warn of bad file structure is extremely > valuable. the ability to scan files to detect corruption is extremely valuable. > And this is a HUGE asset for VMS. Right. Hein. -< INDEXFILE_EXTRACT.MAR. Mostly template. Hope it works some still >- -------------------------------------------------------------------------------- ; ; Very simplistic tool extract anything that looks like a valid ; data record form anything that looks like a valid data bucket ; from a prolog-1 indexed file. ; The output is likely to be out of sequence and needs to be sorted ; The output may well contain duplicates and garbage but gets it ; right more often then not. At least that is what I recall because ; the last time I needed is was way back when in 1985 or so. ; ; Have fun, Hein van den Heuvel, 1985 ; FAB: $FAB FAC = , - ;Allow block I/O read AND write FNA = FILENAME_BUF, - ;Address of filename string SHR = UPI RAB: $RAB FAB = FAB, - ;Associated FAB ROP = , - ;block I/O Processing UBF = BUF ;Input buffer OUTFAB: $FAB ALQ = 1000, - ;Initial allocation 1,000 blocks DEQ = 1000, - ;Default extension 1,000 blocks FAC = , - ;Put access FOP = , - ;Contiguous best try, truncate at EOF ORG = SEQ, - ;Sequential organization RAT = CR, - ;Record attributes - Carriage Return RFM = VAR, - ;Variable length records FNA = FILENAME_BUF ;Address of filename string ;Output file Record Attributes Block OUTRAB: $RAB FAB = OUTFAB,- ;FAB pointer RAC = SEQ ;Sequential record access .ENTRY START, ^M<> PUSHAL FILENAME_SIZ PUSHAQ FILENAME_PROMPT PUSHAQ FILENAME CALLS #3, G^LIB$GET_INPUT MOVB FILENAME_SIZ, FAB+FAB$B_FNS ;Insert the filename size $OPEN FAB=FAB ;Open the input file BLBC R0, BYE ;See you later! MOVZBL FAB+FAB$B_BKS, R10 ;Pick up bucket size ASHL #9, R10, R11 ;Multiply by 512 MOVW R11, RAB+RAB$W_USZ ;Set up size of read $CONNECT RAB=RAB ;Connect BLBC R0, BYE ;See you later! MOVAL FILENAME_BUF,R0 ;Point to input file name MOVZBL FILENAME_SIZ,R1 ;Get its length 20$: CMPB (R0)+,#^A/./ ;Is it a period BEQL 10$ ;Yes DECL R1 ;No reduce the counter... BGTR 20$ ;...and continue 10$: MOVL #^A/SEQ /,(R0) ;Stick in the new file type SUBL2 #4,R1 ;Count the new characters SUBL2 R1,FILENAME_SIZ ;Adjust the string lenght MOVB FILENAME_SIZ,OUTFAB+FAB$B_FNS ;Insert the length into the FAB MOVW FAB+FAB$W_MRS,OUTFAB+FAB$W_MRS ;Set maximum record size $CREATE FAB=OUTFAB ;Open the sequential output file BLBC R0, BYE ;See you later! $CONNECT RAB = OUTRAB ;Connect the record stream to it BLBC R0, BYE ;See you later! CLRL R9 ;Valid data bucket counter CLRL R8 ;Valid record counter CLRL R7 ;Valid byte counter CLRL RAB+RAB$L_BKT ;Init BLBS R0, MAIN_LOOP ;Go for it! BYE: RET MAIN_LOOP: ADDL2 R10, RAB+RAB$L_BKT ;Next Block RAB 10$: $READ RAB=RAB ;Read the bucket BLBS R0, 20$ PUSHAL ENDOF_ERROR CMPL R0,#RMS$_EOF BNEQ 15$ BRW DONE 15$: PUSHAL READ_ERROR BRW GIVE_ERROR 20$: CMPW BUF+2, RAB+RAB$L_BKT ;Sample OK? BNEQ 90$ CMPB BUF, BUF-1(R11) ;Checkbyte OK? BNEQ 90$ CMPW R11, BUF+4 ;Next avaiable reasonable? BGTRU 21$ 90$: INCL RAB+RAB$L_BKT ;Next Block RAB BRW 10$ ; ; Valid bucket! ; 21$: TSTB BUF+12 ;Data level? BNEQ MAIN_LOOP INCL R9 ;Count a valid data bucket MOVL #14, R5 ;Point to first record 30$: CMPB #02, BUF(R5) ;Valid data record? BNEQ 40$ ;No, branch INCL R8 ;Count a valid record BITL #8191, R8 ;Multiple of 8192? BNEQ 35$ JSB STAT 35$: MOVZWL BUF+9(R5), R2 ;Get number of bytes ADDL2 #2, R5 ;Adjust for record length MOVAB BUF+9(R5), OUTRAB+RAB$L_RBF ;Point to the record. MOVW R2, OUTRAB+RAB$W_RSZ ;Adjust the record size in the RAB ADDL2 R2, R7 ;Count the bytes! ADDL2 R2, R5 ;Build next record pointer $PUT RAB=OUTRAB ;Write the record BLBS R0,40$ PUSHAQ WRITE_ERROR CALLS #1, G^LIB$PUT_OUTPUT pushl #ss$_debug calls #1, g^lib$signal nop nop 40$: ADDL2 #9, R5 ;Point to next record. CMPW R5, BUF+4 ;In used range? BLSS 30$ ;Ok, go for next record! BRW MAIN_LOOP ;Ok, go for next bucket! DONE: $CLOSE FAB=OUTFAB ;Close the file. $CLOSE FAB=FAB ;Close the file. JSB STAT $EXIT_S STAT: DIVL3 R8, R7, R6 ;Average number of bytes. PUSHL R6 PUSHL R7 PUSHL R8 PUSHL R9 MOVL #FAO_OUTBUF_L, FAO_OUTBUF_D ;init size PUSHAL FAO_OUTBUF_D ;3 PUSHAL FAO_OUTBUF_D ;2 PUSHAL FAO_CTRSTR_D ;1 CALLS #7, G^SYS$FAO PUSHAL FAO_OUTBUF_D CALLS #1, g^LIB$PUT_OUTPUT RSB GIVE_ERROR: CALLS #1, G^LIB$PUT_OUTPUT BRW MAIN_LOOP WRITE_ERROR: .ASCID "Error writing record" READ_ERROR: .ASCID "Error reading VBN" ENDOF_ERROR: .ASCID "Beyond EOF" FILENAME_PROMPT:.ASCID "Please enter filename:" FILENAME: .LONG 80,FILENAME_BUF ;input buffer descriptor FILENAME_SIZ: .WORD 0 ;Receives length of filename FILENAME_BUF: .BLKB 80 FAO_CTRSTR_A: .ASCII "Total count of valid data BUCKETS : !UL!/" .ASCII "Total count of valid data RECORDS : !UL!/" .ASCII "!UL Bytes of data, average record length: !UL" FAO_CTRSTR_L = . - FAO_CTRSTR_A FAO_CTRSTR_D: .LONG FAO_CTRSTR_L, FAO_CTRSTR_A FAO_OUTBUF_L = 200 FAO_OUTBUF_A: .BLKB FAO_OUTBUF_L FAO_OUTBUF_D: .LONG FAO_OUTBUF_L, FAO_OUTBUF_A BUF:: .BLKB 512*64 .END START ------------------------------ Date: 19 Mar 2007 18:58:47 -0700 From: "Hein RMS van den Heuvel" Subject: Re: RMS indexed file structure questions Message-ID: <1174355927.367328.196060@e65g2000hsc.googlegroups.com> On Mar 19, 12:56 am, JF Mezei wrote: > Out of curiosity, is this documented somewhere regular humans have access to ? See Jim Teague Spring '85 Decus presenation below. Hein. SPRING 1985 U.S. DECUS ---------------------- Overall RMS ISAM File Structure ------------------------------- Prolog - The prolog contains important file-wide information and is always in VBN 1. The most important information it contains is the size of the data buckets, the VBN where the area descriptors begin, the global buffer count, and the prolog version number. Currently allowable prologs are 1, 2 and 3. Key Descriptors - There is a key descriptor for each key defined in the file. The first key descriptor is in VBN 1, and overlays the prolog. Key descriptors provide information about each key in the file such as where the key appears in the record, number of segments, length of each segment, etc. Things like the root VBN, root level, null character, compression flags are also there, along with a pointer to the next key descriptor. If there is more than one key, then the second key descriptor begins in VBN 2. Area Descriptors - These descriptors begin in first VBN after the last VBN to contain a key descriptor, and contain information about the areas of the file. Index and Data Buckets - The index and data buckets appear after the area descriptors. RMS ISAM files have their index and data buckets in a B-tree arrangement. The root (or top) index bucket contains a high key value and a pointer for each bucket below it in the structure. Buckets at that level contain similar keys and pointers to buckets at the next lower level. At the bottom level (level 0, or the data level) appear the data records. Records at the primary index data level contain the actual data bytes of the records in the file. Records at the secondary index data level (SIDRs) contain secondary key values and pointers to primary index data records with the corresponding alternate key value. Bucket levels are numbered from 0 (at the data, or bottom level) upwards to the root level. Prolog Structure ---------------- +--------------------------------------------------------------------------- + / unused (11 bytes) / +------------------ + + ! PLG $B_DBKTSIZ ! ! +------------------ +--------------------------------------------------------+ ! unused ! +-------------------------------------------------------- +------------------+ / unused (85 bytes) ! PLG $B_FLAGS ! +------------------+------------------+ +------------------+ ! PLG$B_AMAX ! PLG $B_AVBN ! / +------------------+------------------ +-------------------------------------+ ! unused ! PLG $W_DVBN ! +------------------------------------- +-------------------------------------+ ! PLG $L_MRN ! +--------------------------------------------------------------------------- + ! PLG $L_EOF ! +------------------------------------- +-------------------------------------+ ! PLG$W_GBC ! PLG $W_VER_NO ! +------------------------------------- +-------------------------------------+ * Note that the prolog structure overlays the key descriptor for the primary key * PLG$B_FLAGS, PLG$L_MRN, and PLG$L_EOF are only used in relative files * PLG$B_AVBN - VBN of first area descriptor * PLG$B_AMAX - maximum number of areas * PLG$W_DVBN - first data bucket VBN * PLG$W_VER_NO - prolog version number * PLG$W_GBC - default global buffer count Key Descriptor --------------- +--------------------------------------------------------------------------- + ! KEY $L_IDXFL ! +------------------+------------------ +-------------------------------------+ ! KEY$B_LANUM ! KEY$B_IANUM ! KEY $W_NOFF ! +------------------+------------------+------------------ +------------------+ ! KEY$B_DATBKTSZ ! KEY$B_IDXBKTSZ ! KEY$B_ROOTLEV ! KEY $B_DANUM ! +------------------+------------------+------------------ +------------------+ ! KEY $L_ROOTVBN ! +------------------+------------------+------------------ +------------------+ ! KEY$B_NULLCHAR ! KEY$B_SEGMENTS ! KEY$B_DATATYPE ! KEY $B_FLAGS ! +------------------+------------------+------------------ +------------------+ ! KEY$W_MINRECSZ ! KEY$B_KEYREF ! KEY $B_KEYSZ ! +-------------------------------------+------------------ +------------------+ ! KEY$W_DATFILL ! KEY $W_IDXFILL ! +------------------------------------- +-------------------------------------+ ! KEY$W_POSITION1 ! KEY $W_POSITION ! +------------------------------------- +-------------------------------------+ ! KEY$W_POSITION3 ! KEY $W_POSITION2 ! +------------------------------------- +-------------------------------------+ ! KEY$W_POSITION5 ! KEY $W_POSITION4 ! +------------------------------------- +-------------------------------------+ ! KEY$W_POSITION7 ! KEY $W_POSITION6 ! +------------------+------------------+------------------ +------------------+ ! KEY$B_SIZE3 ! KEY$B_SIZE2 ! KEY$B_SIZE1 ! KEY $B_SIZE ! +------------------+------------------+------------------ +------------------+ ! KEY$B_SIZE7 ! KEY$B_SIZE6 ! KEY$B_SIZE5 ! KEY $B_SIZE4 ! +------------------+------------------+------------------ +------------------+ / KEY$T_KEYNAM (32 bytes) / + + ! ! +--------------------------------------------------------------------------- + ! KEY $L_LDVBN ! +------------------+------------------+------------------ +------------------+ ! KEY$B_TYPE3 ! KEY$B_TYPE2 ! KEY$B_TYPE1 ! KEY $B_TYPE ! +------------------+------------------+------------------ +------------------+ ! KEY$B_TYPE7 ! KEY$B_TYPE6 ! KEY$B_TYPE5 ! KEY $B_TYPE4 ! +------------------+------------------+------------------ +------------------+ Key Descriptor (continued) -------------- * KEY$L_IDXFL - VBN for next key descriptor * KEY$W_NOFF - Offset to next key descriptor * KEY$B_IANUM - index area number * KEY$B_LANUM - level 1 index area number * KEY$B_DANUM - data level area number * KEY$B_ROOTLEV - Root level: height of index tree * KEY$B_IDXBKTSZ - index bucket size * KEY$B_DATBKTSZ - data bucket size * KEY$L_ROOTVBN - VBN of root bucket * KEY$B_FLAGS - duplicates (bit 0), change key (1), null key (2), index compression (3), index uninitialized (4), key compression (6), record compression (7) * KEY$B_DATATYPE - data type for key * KEY$B_SEGMENTS - number of segments in key * KEY$B_NULLCHAR - null character if specified * KEY$B_KEYSZ - key size * KEY$B_KEYREF - key of reference * KEY$W_MINRECSIZ - minimum record size * KEY$W_xxxFILL - index and data fill values * KEY$W_POSITIONx, KEY$B_SIZEx - beginning positions and sizes of up to 8 key segments * KEY$T_KEYNAM - key name (ASCII counted string) * KEY$L_LDVBN - first data bucket VBN Area Descriptor ---------------- +------------------+------------------+------------------ +------------------+ ! AREA$B_ARBKTSZ ! AREA$B_AREAID ! AREA$B_FLAGS ! unused ! +------------------+------------------+------------------ +------------------+ ! AREA$B_AOP ! AREA$B_ALN ! AREA $W_VOLUME ! +------------------+------------------ +-------------------------------------+ ! AREA $L_AVAIL ! +--------------------------------------------------------------------------- + ! AREA $L_CVBN ! +--------------------------------------------------------------------------- + ! AREA $L_CNBLK ! +--------------------------------------------------------------------------- + ! AREA $L_USED ! +--------------------------------------------------------------------------- + ! AREA $L_NXTVBN ! +--------------------------------------------------------------------------- + ! AREA $L_NXT ! +--------------------------------------------------------------------------- + ! AREA $L_NXBLK ! +------------------------------------- +-------------------------------------+ ! unused ! AREA $W_DEQ ! +------------------------------------- +-------------------------------------+ ! AREA $L_LOC ! +--------------------------------------------------------------------------- + ! AREA $W_RFI ! +------------------------------------- + + <---- AREA $L_TOTAL_ALLOC ! ! +------------------------------------- +-------------------------------------+ ! ! AREA$L_TOTAL_ALLOC <---- + +-------------------------------------+ ! unused ! +------------------------------------- + + ! AREA $W_CHECK ! ! +------------------------------------- +-------------------------------------+ Area Descriptor (continued) --------------- * AREA$B_FLAGS - not used * AREA$B_AREAID - area number * AREA$B_ARBKTSZ - bucket size for area * AREA$W_VOLUME - relative volume number * AREA$B_ALN - extend allocation alignment * AREA$B_AOP - alignment options: absolute alignment/hard (bit 0), locate on cylinder (1), contiguous best try (5), contiguous (7) * AREA$L_AVAIL - reclaimed bucket chain * AREA$L_CVBN - starting VBN for current extent * AREA$L_CNBLK - number of blocks in current extent * AREA$L_USED - number of blocks used * AREA$L_NXTVBN - next VBN to use * AREA$L_NXT - starting VBN for next extent * AREA$L_NXBLK - number of blocks in next extent * AREA$W_DEQ - default extend quantity * AREA$L_LOC - start LBN on volume * AREA$W_RFI - related file ID (6 bytes) * AREA$L_TOTAL_ALLOC - total block allocation * AREA$W_CHECK - checksum Prologue 3 Data Bucket Structure -------------------------------- (Note that picture runs right to left) +-------------------------------------+------------------ +------------------+ ! BKT$W_ADRSAMPLE ! BKT$B_INDEXNO ! BKT $B_CHECKCHAR ! +-------------------------------------+------------------ +------------------+ ! BKT$W_NXTRECID ! BKT $W_FREESPACE ! +------------------------------------- +-------------------------------------+ ! BKT $L_NXTBKT ! +-------------------------------------+------------------ +------------------+ <---- data records ! BKT$B_BKTCB ! BKT $B_LEVEL ! +------------------ +------------------+ * BKT$B_CHECKCHAR - This first byte of the bucket should be identical to the last byte of the bucket. Both are incremented every time the bucket is modified. If the bucket check bytes are out of phase, RMS will complain about a bucket format check error: what this usually indicates is that something has interrupted the writing of all blocks in a bucket. * BKT$B_INDEXNO - The index number: 0 for primary; 1, 2, ... for alternates. * BKT$W_ADRSAMPLE - The low order word of the bucket VBN. * BKT$W_FREESPACE - The first byte of unused space in the bucket. * BKT$W_NEXTRECID - Next available record id. * BKT$L_NXTBKT - Horizontal link to next bucket. * BKT$B_LEVEL - Level in the index structure. * BKT$B_BKTCB - Control byte. Can indicate, among other things, that this is the last bucket in the structure at this level. Prologue 3 Data Record Structure (with key compression) ------------------------------------------------------- (Note that picture runs right to left) +---...---------------------------------------------------------------- + | key + | cnt | len | record | RRV | record | ctrl | | data | | | length | VBN | id | id | byte | +---...---------------------------------------------------------------- + size: byte byte word 6 bytes word byte * The first key in each bucket is always fully expanded (but may be repeating character truncated, however). * The high order 6 bits of the record control byte indicate that the record is deleted (bit 2), or is an RRV (bit 3). ANALYZE/RMS will display the state and position of these bits. The low order two bits are practically meaningless: a typical non-deleted record that is not an RRV will have a control byte of hex 02. * Data records are assigned a record id to uniquely identify them within the data bucket. These ids are assigned in the order of insertion, and may have nothing to do with the physical order of records within the data bucket. RRVs are in essence "forwarding addresses" of records that are useful only after the record has been displaced by a bucket split. If a record has never been moved by a bucket split, then its RRV points to itself. * Prolog 3 compression features imply something that may not be obvious about record lengths: even with fixed-length records, if there is data or key compression, then there must be a record length, since the length can vary based on the amount of compression. * "len" and "cnt" are key compression fields. "len" is the length of the key (not including the "cnt" byte). "cnt" is the count of front bytes, based on the previous key. Repeating characters at the end are truncated. There is an example given below. * Prolog 3 data records ALWAYS have the key at the front (even if there is no key compression). If the key field is in the middle of the record, it is still extracted and placed at the front for performance reasons (of course, it is inserted at the proper point before the record is returned to the user. Example of key compression using 6-byte string keys (see explanation of "len" and "cnt" given above): (Example runs right to left) Second key in bucket has First key in bucket has value "ABCDFF" value "ABCDEF" key cnt len key cnt len ...data... 46 04 01... ...data... 464544434241 00 06 ... Note here that with the second key fully expanded based on the preceding key, we only come up with 5 characters because there has been rear end truncation of repeating characters. We manufacture enough bytes of the last character (D, or hex 46) and append them to make the key 6 bytes long. Data Record Compression ----------------------- The compression algorithm is different for data records -- it is strictly a repeating character truncation process. The data portion of the record begins immediately after the key. Note that RMS will not do repeating character truncation unless there are at least 5 repeating characters, to make sure that the extra overhead will not negate the savings. There are two fields associated with data record compression: a word field which points to the compressed character, and a byte field that tells how many repetitions of the character were truncated. The general format of the record is: pointer word, data segment, truncation count byte; pointer word, data segment, truncation count byte, etc. An example of data record compression is given below. Each set of {word, data, byte} is termed a compression segment. A record with a data portion that looks like: "ABBBBBBCDDDDDDDDDDD" (A, 7 Bs, C, 11 Ds) will compress to two segments: (Example runs right to left) count data pointer count data pointer byte word byte word overhead 0A 4443 0002 06 4241 0002 ... Index Bucket Structure ---------------------- Index buckets look identical, except that the "index #" byte is not necessarily 0, and neither is the "index level" byte. They of course reflect the index number and the level in the index structure. Index levels are numbered with the root level being the highest level, and data levels always being level 0. Note that there is a data level for alternate index structures as well that consists of a key and an RRV pointer. The RRV pointer points to the primary data record with that secondary key value. RMS saves index bucket space for all prologs by minimizing the size of the field needed to represent a bucket's VBN pointer. For prolog 3, all VBN pointers in a particular index bucket are the same size, maximized to the size necessary to represent the largest pointer in the bucket. Bits 3 and 4 of the bucket control byte indicate the pointer size for the bucket: 00 means two-byte pointers, 01 means three-byte pointers, and 10 means four-byte pointers. Note that if there is no index compression, RMS will do a binary search through index buckets for the requested key value. This of course includes binary and integer keys. This is why prolog 3 keeps all VBN pointers in a given index bucket the same size. Index compression is done exactly like key compression. Prolog 3 index records are split into two parts, the key and the VBN pointer. The keys are at the beginning of the index bucket, and the VBN pointers are at the end of the index bucket. (A little silly, but it's too late now.) Secondary Index Data Records (SIDRs) ------------------------------------ "Data level" records of alternate indexes are called "SIDRs". A SIDR consists of a size word, followed by a key value and one or more RRVs with control fields. The control field indicates whether or not the record is deleted. If data key compression is enabled for this index, then the key will be compressed, otherwise not. The following illustrates the layout of a SIDR record. (Examples run right to left) With key compression: +--...------------------------------------------------------------------ + | ... | RRV2 | ctl | RRV1 | ctl | key | cnt | len | size | +--...------------------------------------------------------------------ + Without key compression: +--...-----------------------------------------------------+ | ... | RRV2 | ctl | RRV1 | ctl | key | size | +--...-----------------------------------------------------+ o Record Operations (assumes no bucket splits) - $PUT 1. Initialization/validation (if sequential access, is key value of new record greater than that of last record, etc.) 2. Position to point of insert (involves positioning through the index structure by key, and leaves data bucket locked) 3. Adjust "high set" appropriately 4. Build record overhead fields in bucket; move in record itself 5. Lock new record 6. Update primary index (if necessary) 7. Unlock bucket 8. Insert alternate keys (if any) (extracted from user buffer) - $DELETE (assumes previous $GET/$FIND) + V4 $DELETE 1. Initialization/validation (is there a current record, etc.) 2. Position by RFA to record (leaves bucket locked) 3. SAVE RECORD IN INTERNAL BUFFER 4. Delete the RRV (if any) 5. Delete the primary record itself 6. Unlock bucket 7. Delete all alternate keys, plucking values from saved record + V3 $DELETE 1. Initialization/validation 2. Position by RFA to record (leaves bucket locked) 3. Delete RRV (if any) 4. Delete all alternate keys -- NOTE BUCKET IS STILL LOCKED at this point (*) 5. Delete primary data record 6. Unlock bucket - $UPDATE (assumes previous $GET/$FIND) 1. Initialization/validation 2. Position by RFA to record (leaves bucket locked) 3. If alternate keys will change, then: 1. Save old record 2. Unlock data bucket 3. Insert new SIDR entries 4. Reposition by RFA to record (leaves bucket locked again) 4. Is new record size less than or equal to old size? + YES (smaller or same as old record) 1. Adjust high set appropriately 2. Insert record + NO (larger than old record) 1. Save record ID 2. Perform "pseudo-$DELETE" 3. Perform "pseudo-$PUT" (stuffing saved record ID) (*) 5. Unlock bucket 6. Delete old SIDR entries (if any) using old record buffer o Bucket Splits (or How to Complicate Matters by a Few Orders of Magnitude) (assumes old bucket is already locked) 1. Lock area 2. Allocate new bucket 3. Unlock area 4. Format new bucket 5. Set new bucket's next pointer to old bucket's next pointer 6. Set old bucket's next pointer to the new bucket 7. Move data into new bucket 8. Write out new bucket 9. Scan old bucket for records past the split point that have RRVs, and keep in a table. 10. Update free space in old bucket and unlock it 11. Update RRVs in table to point to new location of records. This involves multiple positionings by RRV -- one for each RRV to be updated. Note that SIDRs are not updated! SIDR entries may point to an RRV, which in turn points to the real record. Because of the RRV updating process however, this level of indirection never goes beyond one. o Performance Issues - Bucket Size versus Record Size + Larger data buckets yield fewer index buckets, which results in fewer DIOs, but longer search times (CPU) at the data level + Smaller data buckets yield more index buckets, which results in more DIOs, but shorter search times at the data level + Keep in mind: Prolog 3 performs binary searches in index buckets IFF there is no index compression. Index bucket search times are greatly reduced, so the major consideration for CPU usage is data level searches. + What are you willing to trade? If you don't have memory to burn, then the trade is more significant. If you DO have lots of memory, you can have the best of both worlds: - Index Caching and Global Buffers. If you can use global buffers to cache the entire index structure, then EVERYBODY WINS! If you cache the entire index structure locally (multibuffer count), then the process wins at the expense of other processes (using more memory). Really better only in the nonshared case. Note that this argument for caching lots of the index structure falls apart for sequential access, where a small number of buffers is plenty (2). - Compression Considerations. Certain data record formats do NOT lend themselves to compression. Consider the case of a file created at the beginning of a year. The data records in this file consist of twelve blank subfields, with data inserted into one subfield each month throughout the year. OUCH! ------------------------------ Date: Mon, 19 Mar 2007 14:33:45 -0400 From: JF Mezei Subject: Re: Suggestion for the VMS X-windows server Message-ID: <9d03e$45fed7a3$cef8887a$15180@TEKSAVVY.COM> FredK wrote: > I need an example. 19-MAR-2007 03:05:25.8 Connection 165714d0 is accepted by Txport 19-MAR-2007 03:05:25.9 Access granted to: LOCAL 0 JFMEZEI matched entry: LOCAL 0 JFMEZEI 19-MAR-2007 03:05:31.5 Connection 165714d0 is closed by Txport 19-MAR-2007 03:37:02.3 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:04.7 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:05.7 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:06.7 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:07.5 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:08.2 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:08.8 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:10.1 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:10.9 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:12.3 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:13.1 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:13.3 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:14.1 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:15.1 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:15.8 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:16.9 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:17.3 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:18.0 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:18.6 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:19.3 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:20.1 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:21.5 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:21.8 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:22.4 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:23.0 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:24.5 AllocatePixmap failed, called from fbCreatePixmapBpp 19-MAR-2007 03:37:25.8 AllocatePixmap failed, called from fbCreatePixmapBpp (and it goes on) That particular page completed it loading. Not all of the mozilla window was redrawn, but I was able to scroll down with some of the images being shown, others just a white rectangle. But there are times when this gets much worse, with garbage bitmaps being displayed when move the mouse over an object that changes when the mouse is over it for instance. And there are times when scrolling down causes a continual repeat of the last 50 of so pixels. I mention scrolling down, because often, on those pages, doing a "page down" won't work or gives very erratic display. ------------------------------ Date: 19 Mar 2007 20:54:21 +0100 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: Re: Suggestion for the VMS X-windows server Message-ID: <45fef87d$1@news.langstoeger.at> In article <1174310844.221759.167200@n59g2000hsh.googlegroups.com>, etmsreec@yahoo.co.uk writes: >A fully configured rx2660 with disk, tape and VMS licenses comes in at >about 10k GBP. >The FOE PCL is presently 490 GBP list price. A dual-core CPU, of >course, requires two. So, that sums up to 11k GBP, which is 16k EUR (and way more than $20k). Almost 8 times the price I have as limit. Remember, I'm a hobbyist, a fully configured rx2660 is more than I need, but I don't think, I can strip it down to Eur 2k at all... -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ Date: Mon, 19 Mar 2007 20:43:28 GMT From: "FredK" Subject: Re: Suggestion for the VMS X-windows server Message-ID: "JF Mezei" wrote in message news:84e48$45fee224$cef8887a$6288@TEKSAVVY.COM... > FredK wrote: >> The answer is to grow the server VA space - as you have noted. I'm not >> quite sure what else you could possibly want the X11 server to do. >> Perhaps it could put out an error in the log suggesting how to fix it. > > I realise that Mozilla is ill-behaved. However, if you consider its > requirement for hundreds of megabytes to display a web page to be a > "bug", then it would be nice if X-11 would pop up some small warning on > the screen at the time the available virtual memory becomes very low. One > would then immediatly relate the error message with what is happening on > the screen (aka: in mozilla , loading some page). First it needs to detect and determine what "low" is. Then popping up a window may not be possible, and in fact could exacerbate the problem. While not slapping you silly with being obvious - you seemed to figure it out by looking at the error message. Popping up a message window isn't as simple as you think - since the server itself would have to send some type of property change event to the window manager to actually cause it to happen. ------------------------------ Date: Mon, 19 Mar 2007 21:30:05 +0100 From: Marc Van Dyck Subject: Re: Suggestion for the VMS X-windows server Message-ID: After serious thinking Peter 'EPLAN' LANGSTOeGER wrote : > In article <1174310844.221759.167200@n59g2000hsh.googlegroups.com>, > etmsreec@yahoo.co.uk writes: >> A fully configured rx2660 with disk, tape and VMS licenses comes in at >> about 10k GBP. >> The FOE PCL is presently 490 GBP list price. A dual-core CPU, of >> course, requires two. > > So, that sums up to 11k GBP, which is 16k EUR (and way more than $20k). > Almost 8 times the price I have as limit. > > Remember, I'm a hobbyist, a fully configured rx2660 is more than I need, > but I don't think, I can strip it down to Eur 2k at all... Which is exactly why I'm looking at Integrity blades. It's for office & system management work, so I expect the built-in graphics controller should be powerful enough. 8 blades in an enclosure should be rather cheaper than 8 RX2660. -- Marc Van Dyck ------------------------------ Date: Tue, 20 Mar 2007 02:03:46 GMT From: rdeininger@mindspringdot.com (Robert Deininger) Subject: Re: Suggestion for the VMS X-windows server Message-ID: In article , "FredK" wrote: >The office friendly version of the rx2600 was the zx6000. The firmware for >it could run the fans slower IIRC. Well, the zx6000 was the variant with the PCI+AGP I/O backplane. ------------------------------ Date: 19 Mar 2007 11:58:46 -0700 From: "Jim" Subject: Re: Switch to PREFERRED_PATH on HSZ80 and VMS 7.2-1 Message-ID: <1174330726.355678.153470@y66g2000hsf.googlegroups.com> On Mar 19, 12:40 pm, "Peter Weaver" wrote: > I am working with a customer that is frozen in time. They have two > HSZ80 controllers and VMS 7.2-1 on their cluster. > > Currenly every unit in the HSZ80 is online to the other controller, > even for the disks that the PREFERRED_PATH is this controller. > > State: > ONLINE to the other controller > PREFERRED_PATH = THIS_CONTROLLER > > Jobs that normally execute in a few hours are now running over 12 > hours so we want to get some units back to the correct controller. > > Since this is VMS 7.2-1 I have no SET DEVICE/SWITCH command, I recall > running some utility in SYSTARTUP_VMS to set the path before the SET > DEVICE/SWITCH came out, but I can not remember how that used to > happen. Every thing I can think of searching on gives me the new > method, not the old. > > Does anyone remember how you go about switching the path back to the > preferred path on this old setup? If anyone knows where I can find > HSZ80 manuals then a pointer there would be appreciated too. > Does the OTHER HSZ controller have a PREFERRED_ID specified? My recollection (which may be incorrect) is that any path preferrence specified at the the controller level (selecting SCSI ports) takes precedence over that specified at the unit level. Additionally, I think that you'll find that the only control over the paths that you have is via the HSZs and not with VMS. If, all of the disks are being served by a single HSZ its because there is either a hardware issue with THIS controller (is cache ok?) or the controller configuration specifies it. ------------------------------ Date: 19 Mar 2007 12:20:53 -0700 From: "Peter Weaver" Subject: Re: Switch to PREFERRED_PATH on HSZ80 and VMS 7.2-1 Message-ID: <1174332053.634766.219150@l77g2000hsb.googlegroups.com> On Mar 19, 2:58 pm, "Jim" wrote: >... > Does the OTHER HSZ controller have a PREFERRED_ID specified? My >... I should have pointed out that these controllers are "Configured for MULTIBUS_FAILOVER" so (if I understand correctly) the PREFERRED_ID does not come into play. SET THIS ? does not show PREFERRED_ID as one of the options and SHOW THIS and SHOW OTHER does not show PREFERRED_ID. The cache is OK, batteries are OK, the controller seems to be working fine. But somewhere there was a hiccup and the disks on one controller failed over to the other. At another site I had a HSG80 and VMS 7.3 and we could fail over the paths using SET DEVICE/SWITCH/PATH=x. I remember doing something to fail the disks over before we upgraded to 7.3 but I do not remember what we had to do. It might have been a program we got from engineering, but I am not sure now. I did try SET unit NOPREFERRED_PATH and SET unit PERFERRED_PATH = THIS_CONTROLLER, but the path did not switch. Peter Weaver www.weaverconsulting.ca CHARON-VAX CHARON-AXP DataStream Reflection PreciseMail HP Commercial Hardware ------------------------------ Date: Mon, 19 Mar 2007 11:12:49 -0800 From: "Tom Linden" Subject: Re: Switch to PREFERRED_PATH on HSZ80 and VMS 7.2-1 Message-ID: On Mon, 19 Mar 2007 11:20:53 -0800, Peter Weaver = wrote: > On Mar 19, 2:58 pm, "Jim" wrote: >> ... >> Does the OTHER HSZ controller have a PREFERRED_ID specified? My >> ... > > I should have pointed out that these controllers are "Configured for > MULTIBUS_FAILOVER" so (if I understand correctly) the PREFERRED_ID > does not come into play. SET THIS ? does not show PREFERRED_ID as one > of the options and SHOW THIS and SHOW OTHER does not show > PREFERRED_ID. > > The cache is OK, batteries are OK, the controller seems to be working > fine. But somewhere there was a hiccup and the disks on one controller= > failed over to the other. At another site I had a HSG80 and VMS 7.3 > and we could fail over the paths using SET DEVICE/SWITCH/PATH=3Dx. I > remember doing something to fail the disks over before we upgraded to > 7.3 but I do not remember what we had to do. It might have been a > program we got from engineering, but I am not sure now. > > I did try SET unit NOPREFERRED_PATH and SET unit PERFERRED_PATH =3D > THIS_CONTROLLER, but the path did not switch. > > Peter Weaver > www.weaverconsulting.ca > CHARON-VAX CHARON-AXP DataStream Reflection PreciseMail HP Commercial= > Hardware > what do you see to SHOW THIS, SHOW OTHER -- = Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ------------------------------ Date: Mon, 19 Mar 2007 17:07:08 -0400 From: JF Mezei Subject: Re: SYSMAN IO SET EXCLUDE question Message-ID: <68dc7$45fefb7d$cef8887a$3968@TEKSAVVY.COM> >I just applied the VMS83A UPDATE 2.0 to one node. Is it possible that the >SYSMAN IO EXCLUDE list is no longer working properly ? OK, this is getting interesting. My original complaint was that node CHAIN didn't seem to honour the SYSMAN IO SET EXCLUDE. BIKE had not yet rebooted with the update 2.0 patch and still had the "right" list of devices with the junk ones having been excluded. Now, I have rebooted BIKE and the excluded devices are still working fine. Both nodes share a common system disk, currently hosted by BIKE (the node where the device exclusion works). I tried to do a SYSMAN IO SHOW EXCLUDE from an unprivileged account and it generated alarms for some files including: _$10$DQA0:[SYS1.SYSMGR]IOGEN$PREFIX.DAT; CHAIN happens to boot as a satellite. Is it possible that it doesn't yet have access to the above file by the time the devices are being configured and thus doesn't know which ones to avoid configuring ? (or perhaps the satellite booting sequence doesn't support the SYSMAN IO SET EXCLUDE stuff at all ?) I should eventually test this theory when CHAIN becomes a boot node and BIKE a satellite and see if the device exclusion is reversed with CHAIN properly excluding the devices and BIKE configuring the non existant IDE devices. ------------------------------ Date: Mon, 19 Mar 2007 22:10:25 GMT From: "FredK" Subject: Re: SYSMAN IO SET EXCLUDE question Message-ID: "JF Mezei" wrote in message news:68dc7$45fefb7d$cef8887a$3968@TEKSAVVY.COM... > >I just applied the VMS83A UPDATE 2.0 to one node. Is it possible that the > >SYSMAN IO EXCLUDE list is no longer working properly ? > > > OK, this is getting interesting. My original complaint was that node CHAIN > didn't seem to honour the SYSMAN IO SET EXCLUDE. BIKE had not yet > rebooted with the update 2.0 patch and still had the "right" list of > devices with the junk ones having been excluded. > > Now, I have rebooted BIKE and the excluded devices are still working fine. > > Both nodes share a common system disk, currently hosted by BIKE (the node > where the device exclusion works). > > I tried to do a SYSMAN IO SHOW EXCLUDE from an unprivileged account and it > generated alarms for some files including: > > _$10$DQA0:[SYS1.SYSMGR]IOGEN$PREFIX.DAT; > > > CHAIN happens to boot as a satellite. Is it possible that it doesn't yet > have access to the above file by the time the devices are being configured > and thus doesn't know which ones to avoid configuring ? (or perhaps the > satellite booting sequence doesn't support the SYSMAN IO SET EXCLUDE stuff > at all ?) > > I should eventually test this theory when CHAIN becomes a boot node and > BIKE a satellite and see if the device exclusion is reversed with CHAIN > properly excluding the devices and BIKE configuring the non existant IDE > devices. The SYSMAN IO AUTO is done from a command file long after everything is running - so it should not matter if it is a satellite or not (it might make a difference if we were talking about boot device configuration). The question I have is if you have excluded the devices on both nodes... [SYS1.SYSMGR] implies a system-specific file not a common file has been found. ------------------------------ Date: Mon, 19 Mar 2007 17:40:53 -0400 From: JF Mezei Subject: Re: SYSMAN IO SET EXCLUDE question Message-ID: FredK wrote: > question I have is if you have excluded the devices on both nodes... > [SYS1.SYSMGR] implies a system-specific file not a common file has been > found. Yep. $ mc sysman io show exclude %SYSMAN-I-OUTPUT, command execution on node CHAIN %SYSMAN-I-IOEXCLUDE, the current permanent exclusion list is: DQA1,DQB1,DVA0 $ show dev $11$d Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt $11$DQA0: (CHAIN) Mounted 0 SHIMANO 28390576 1 4 $11$DQA1: (CHAIN) Offline 1 $11$DQB0: (CHAIN) Mounted 0 MAVIC 44502822 1 4 $11$DQB1: (CHAIN) Offline 1 ==================================== $ mc sysman io show exclude %SYSMAN-I-OUTPUT, command execution on node BIKE %SYSMAN-I-IOEXCLUDE, the current permanent exclusion list is: DQA1,DQB0,DQB1,DVA0 $ show dev $10$d Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt $10$DQA0: (BIKE) Mounted 0 FREEWHEEL 27841136 555 4 CHAIN: DS10L with 2 30 gig IDE drives BIKE: DS10L with 1 30 gig drive. ------------------------------ End of INFO-VAX 2007.157 ************************