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" <william.w.webb@gmail.com>
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 <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
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br><br>
<div><span class="gmail_quote">On 3/19/07, <b class="gmail_sendername">Dr. Dweeb</b> <<a href="mailto:spam@dweeb.net">spam@dweeb.net</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Andrew wrote:<br>> On 18 Mar, 19:49, "Dr. Dweeb" <<a href="mailto:s...@dweeb.net">s...@dweeb.net
</a>> wrote:<br>>> Bill Todd wrote:<br>>>> Dr. Dweeb wrote:<br>>></blockquote>
<div> </div>
<div><snip></div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> Non of this alters the obvious economic issue which is that man made<br>> CO2 comes mainly from burning fossil fuels, these are running out or
<br>> becoming increasing expensive to exploit. Whatever the cause of GW the<br>> reality is that we need to wean ourselves of fossil fuels before they<br>> become too scarce and too expensive for our economies to support.
<br>><br><br>I continue to agree with this sentiment.<br><br>> Regards<br>> Andrew Harrison<br><br><font color="#550055"> Whatever the cause of GW the<br>> reality is that we need to wean ourselves of fossil fuels before they
<br>> become too scarce and too expensive for our economies to support.<br>></font></blockquote>
<div> </div>
<div>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).
</div>
<div> </div>
<div>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.
</div>
<div> </div>
<div>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."
</div>
<div> </div>
<div>In fact, I highly recommend anything that the man has written.</div>
<div> </div>
<div>WWWebb</div><br> </div><br>
------=_Part_105085_20514026.1174320740843--
------------------------------
Date: 19 Mar 2007 17:19:19 -0700
From: "AEF" <spamsink2001@yahoo.com>
Subject: Re: AMD's well may be running dry
Message-ID: <1174349959.472204.246410@y66g2000hsf.googlegroups.com>
On Mar 19, 7:56 am, "Andrew" <andrew_harri...@symantec.com> wrote:
> On 18 Mar, 19:59, dav...@montagar.com wrote:
>
> > On Mar 17, 1:25 pm, Bill Todd <billt...@metrocast.net> 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 <billtodd@metrocast.net>
Subject: Re: AMD's well may be running dry
Message-ID: <hvidnel-Wef7t2LYnZ2dnUVZ_r2onZ2d@metrocastcablevision.com>
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" <william.w.webb@gmail.com>
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 <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
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br><br>
<div><span class="gmail_quote">On 3/19/07, <b class="gmail_sendername">Bill Todd</b> <<a href="mailto:billtodd@metrocast.net">billtodd@metrocast.net</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">William Webb wrote:<br><br>...<br><br>> Whatever the cause of GW the<br>> > reality is that we need to wean ourselves of fossil fuels before
<br>> they<br>> > become too scarce and too expensive for our economies to support.<br>> ><br>><br>><br>> At the risk of causing outrage among some members of this discussion,<br>> this what is known as "the free market working". The increase in price
<br>> will cause a greater adoption of alternatives to fossil fuels without<br>> the need for government fiat (play on words intended because humor is an<br>> extremely scarce commodity in this discussion).<br><br>
I'm afraid that's an extremely superficial analysis.<br><br>The free market does not look ahead very well: it's mostly driven by<br>*current* reality. Whereas the kinds of changes you're imagining will<br>
occur 'automagically' as prices for fossil fuels rise can take a very<br>long time indeed to implement (far longer than the free market horizon<br>will account for).<br><br>At best, the result is that, left to the free-market, major temporary
<br>(on the order of a decade or less, which some might not consider all<br>that temporary) problems will arise: prices that force most people to<br>alter their behavior radically and on short notice while the industries
<br>affected scurry to adjust. Converting most new vehicles to run mostly<br>on ethanol (to pick one example the analysis of which is informative<br>even if the desirability of that specific response to the problem may be
<br>in doubt) could conceivably be done in two or three years - but it would<br>take another decade or so before the demand for gasoline trailed off<br>commensurately because that's how long *pre-existing* vehicles would
<br>continue running.<br><br>And of course that's ignoring the latencies in getting high levels of<br>ethanol production and distribution up and running.<br><br>How about home (and commercial) heating and cooling, another major
<br>consumer of fossil fuels? The best solutions there involve rather<br>fundamental building design: if you thought waiting for existing cars<br>to be replaced took a long time, consider that existing buildings have<br>
at least an order of magnitude longer lifetimes than cars do (i.e., we<br>really should have started redesigning new buildings not long after WWII<br>to be anywhere nearly ready for major changes in their collective energy
<br>use within our lifetime: the free market wasn't worth squat in that<br>regard, and even now has only begun to take very small steps in that<br>direction - there are innovative exceptions, but they mostly serve only
<br>as proofs of concept - because heating costs still aren't high enough yet).<br><br>That's just talking about use of fossil fuel as fuel: how about its<br>non-fuel use in producing things like plastics? What will the kind of
<br>cost-overshoot that's likely (in large part due to continued consumption<br>as fuel far beyond the point where we *could* have started significantly<br>weaning ourselves off of it) do to other major industries and the prices
<br>of their products?<br><br>Free-market Utopians aren't very good at providing answers to such<br>questions, because the free market isn't very good at providing anything<br>approaching optimal solutions for them: the forward vision in its
<br>'invisible hand' is far too myopic.<br><br>- bill</blockquote></div>
<div> </div>
<div>Your use of the word Utopian implies that those favoring free markets are unrealistic.</div>
<div> </div>
<div>Compared to a centralized planning solution such as you propose?</div>
<div> </div>
<div>I subscribe to the libertarian economics of the Austrian school of Von Mises, Hayek, Friedman and Sowell.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>And the "forward vision" of most intellectuals has historically favored the totalitarian worldview over the one favoring human liberty. </div>
<div> </div>
<div>And this goes back hundreds, if not thousands of years.</div>
<div> </div>
<div>WWWebb<br> </div>
------=_Part_115489_19800612.1174356115698--
------------------------------
Date: Mon, 19 Mar 2007 22:23:23 -0400
From: Bill Todd <billtodd@metrocast.net>
Subject: Re: AMD's well may be running dry
Message-ID: <MNidncrvEPYB2GLYnZ2dnUVZ_hqdnZ2d@metrocastcablevision.com>
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" <spamsink2...@yahoo.com> 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" <spamsink2...@yahoo.com> 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" <spamsink2...@yahoo.com> 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" <dbsneddon@bigpond.com>
Subject: Re: Comments on my license reuse plan
Message-ID: <1174366397.645243.309040@e1g2000hsg.googlegroups.com>
On Mar 19, 3:18 pm, "tadamsmar" <tadams...@yahoo.com> 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 <john.reagan@hp.com>
Subject: Re: Itanium exception handling performance
Message-ID: <uoBLh.1399$a16.641@news.cpqcorp.net>
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" <tom@kednos-remove.com>
Subject: Re: Itanium exception handling performance
Message-ID: <op.tpf7z7cvtte90l@hyrrokkin>
On Mon, 19 Mar 2007 11:20:58 -0800, John Reagan <john.reagan@hp.com> 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" <richard-scoville@hotmail.com>
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 <dean.woodward@gmail.com>
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 <dean.woodward@gmail.com>
> 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 <djesys.no@spam.comcast.net>
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" <heinvandenheuvel@gmail.com>
Subject: Re: RMS indexed file structure questions
Message-ID: <1174355729.819290.73530@o5g2000hsb.googlegroups.com>
On Mar 19, 12:56 am, JF Mezei <jfmezei.spam...@vaxination.ca> 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 = <BIO,BRO,GET>, - ;Allow block I/O read AND write
FNA = FILENAME_BUF, - ;Address of filename string
SHR = UPI
RAB: $RAB FAB = FAB, - ;Associated FAB
ROP = <BIO>, - ;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>, - ;Put access
FOP = <CBT,TEF>, - ;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" <heinvandenheuvel@gmail.com>
Subject: Re: RMS indexed file structure questions
Message-ID: <1174355927.367328.196060@e65g2000hsc.googlegroups.com>
On Mar 19, 12:56 am, JF Mezei <jfmezei.spam...@vaxination.ca> 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 <jfmezei.spamnot@vaxination.ca>
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" <fred.nospam@dec.com>
Subject: Re: Suggestion for the VMS X-windows server
Message-ID: <QBCLh.1407$216.252@news.cpqcorp.net>
"JF Mezei" <jfmezei.spamnot@vaxination.ca> 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 <marc.vandyck@brutele.be>
Subject: Re: Suggestion for the VMS X-windows server
Message-ID: <mn.9d0a7d73855416cd.30579@brutele.be>
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: <rdeininger-1903072203520001@dialup-4.233.173.64.dial1.manchester1.level3.net>
In article <yoxLh.1379$QW5.1298@news.cpqcorp.net>, "FredK"
<fred.nospam@dec.com> 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" <mckinneyj@saic.com>
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" <info-...@weaverconsulting.ca>
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" <info-vax@weaverconsulting.ca>
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" <mckinn...@saic.com> 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" <tom@kednos-remove.com>
Subject: Re: Switch to PREFERRED_PATH on HSZ80 and VMS 7.2-1
Message-ID: <op.tpgabnd6tte90l@hyrrokkin>
On Mon, 19 Mar 2007 11:20:53 -0800, Peter Weaver =
<info-vax@weaverconsulting.ca> wrote:
> On Mar 19, 2:58 pm, "Jim" <mckinn...@saic.com> 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 <jfmezei.spamnot@vaxination.ca>
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" <fred.nospam@dec.com>
Subject: Re: SYSMAN IO SET EXCLUDE question
Message-ID: <lTDLh.1417$nY5.1322@news.cpqcorp.net>
"JF Mezei" <jfmezei.spamnot@vaxination.ca> 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 <jfmezei.spamnot@vaxination.ca>
Subject: Re: SYSMAN IO SET EXCLUDE question
Message-ID: <b702$45ff0367$cef8887a$22304@TEKSAVVY.COM>
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
************************