Re: big iron mainframe vs. x86 servers
Anne & Lynn Wheeler
ly...@GARLIC.COM (Anne & Lynn Wheeler) writes:
> lots of the financial stuff grew up in mainframe batch ... some past
> references/discussions (this from linkedin greater ibm)
> http://www.garlic.com/~lynn/2009o.html#51 8 ways the American information worker remains a Luddite
> and slightly older from year ago
> http://www.garlic.com/~lynn/2008p.html#27 Father of Financial Dataprocessing
re:
http://www.garlic.com/~lynn/2009o.html#81 big iron mainframe vs. x86 servers
... at tandem, after leaving ibm, Jim did this study:
Why Do Computers Stop and What Can Be Done About It?
http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf
from above:
An analysis of the failure statistics of a commercially available
fault-tolerant system shows that administration and software are the
major contributors to failure.
... snip ...
also ...
Fault Tolerance in Tandem Computer Systems
http://www.hpl.hp.com/techreports/tandem/TR-86.2.pdf
from above:
When the sources of faults are examined in detail, a surprising
picture emerges: Faults come from hardware, software, operations,
maintenance and environment in about equal measure. Hardware may go
for two months without giving problems and software may be equally
reliable. The result is a one month MTBF. When one adds in operator
errors, errors during maintenance, and power failures the MTBF sinks
below two-weeks.
... snip ...
in the later part of the 90s, we spent some time with large financial
transaction operation ... that had 100% availability so far in the
decade. they attributed the 100% availability to:
1) IMS hot-standby
2) automated operator
recent post about high i/o error (disk development) environment where
MVS had MTBF of 15 minutes ... and I undertook to rewrite i/o supervisor
to never fail ... also brought down the wrath of the MVS group for
just referring to the MVS failure rate internally
http://www.garlic.com/~lynn/2009o.html#17 Broken hardware was Re: Broken Brancher
http://www.garlic.com/~lynn/2009o.html#31 Justice Department probing allegations of abuse by IBM in mainframe computer market
other posts mentioning bldgs 14 (disk engineering) & 15 (disk product
test)
http://www.garlic.com/~lynn/subtopic.html#disk
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
jmfbahciv
When that goes "wrong" (and it does twice/year), the effects begin
to cascade like a series-->parallel setup of dominos.
/BAH
Morten Reistad
>Anne & Lynn Wheeler wrote:
>> ly...@GARLIC.COM (Anne & Lynn Wheeler) writes:
>>> lots of the financial stuff grew up in mainframe batch ... some past
>>> references/discussions (this from linkedin greater ibm)
>>> http://www.garlic.com/~lynn/2009o.html#51 8 ways the American information worker remains a Luddite
>>> and slightly older from year ago
>>> http://www.garlic.com/~lynn/2008p.html#27 Father of Financial Dataprocessing
>>
>> re:
>> http://www.garlic.com/~lynn/2009o.html#81 big iron mainframe vs. x86 servers
>>
>> ... at tandem, after leaving ibm, Jim did this study:
>>
>> Why Do Computers Stop and What Can Be Done About It?
>> http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf
Nice to see that paper again. Been a few decades.
>> from above:
>>
>> An analysis of the failure statistics of a commercially available
>> fault-tolerant system shows that administration and software are the
>> major contributors to failure.
>>
>> ... snip ...
>>
>> also ...
>>
>> Fault Tolerance in Tandem Computer Systems
>> http://www.hpl.hp.com/techreports/tandem/TR-86.2.pdf
>>
>> from above:
>>
>> When the sources of faults are examined in detail, a surprising
>> picture emerges: Faults come from hardware, software, operations,
>> maintenance and environment in about equal measure. Hardware may go
>> for two months without giving problems and software may be equally
>> reliable. The result is a one month MTBF. When one adds in operator
>> errors, errors during maintenance, and power failures the MTBF sinks
>> below two-weeks.
One thing that this paper does not mention is fault isolation. Never
let the fault propagate beyond the scope of the program; i.e. don't let
a simple pointer fault take down a system.
>> ... snip ...
>>
>> in the later part of the 90s, we spent some time with large financial
>> transaction operation ... that had 100% availability so far in the
>> decade. they attributed the 100% availability to:
>>
>> 1) IMS hot-standby
>> 2) automated operator
Relevance today is to use the HA stuff for what it is worth.
>> recent post about high i/o error (disk development) environment where
>> MVS had MTBF of 15 minutes ... and I undertook to rewrite i/o supervisor
>> to never fail ... also brought down the wrath of the MVS group for
>> just referring to the MVS failure rate internally
>> http://www.garlic.com/~lynn/2009o.html#17 Broken hardware was Re: Broken Brancher
>> http://www.garlic.com/~lynn/2009o.html#31 Justice Department probing allegations of abuse by
>IBM in mainframe computer market
>>
>> other posts mentioning bldgs 14 (disk engineering) & 15 (disk product
>> test)
>> http://www.garlic.com/~lynn/subtopic.html#disk
>>
>There is also that pesky problem of not having the "correct" date/time.
>When that goes "wrong" (and it does twice/year), the effects begin
>to cascade like a series-->parallel setup of dominos.
This is a solved one. Keep all permanent time stamps in UTC, and
just have a little conversion layer when presenting this to the user.
-- mrr
Walter Bushell
Morten Reistad <fr...@last.name> wrote:
OBTO: That requires an intelligent designer. [1]
And is a constant problem of road warriors and an annoyance for casual
travelers who cross time zones.
[1] TO -> talk.origins
--
A computer without Microsoft is like a chocolate cake without mustard.
Anne & Lynn Wheeler
jmfbahciv <jmfbahciv@aol> writes:
> There is also that pesky problem of not having the "correct" date/time.
> When that goes "wrong" (and it does twice/year), the effects begin
> to cascade like a series-->parallel setup of dominos.
re:
http://www.garlic.com/~lynn/2009p.html#0 big iron mainframe vs. x86 servers
one of the early things that I remember getting draged into after
graduation and joining the science center (which consumed several
peoples time and went on for three months) was discussing when did the
century start and what to do about leap seconds (by comparison, the
twice a year problem was relatively trivial). this was all about the new
architecture specification for the 370 64bit TOD clock.
Morten Reistad
Walter Bushell <pr...@panix.com> wrote:
>In article <qm9br6-...@laptop.reistad.name>,
>>
>> This is a solved one. Keep all permanent time stamps in UTC, and
>> just have a little conversion layer when presenting this to the user.
>>
>> -- mrr
>
>OBTO: That requires an intelligent designer. [1]
>
>And is a constant problem of road warriors and an annoyance for casual
>travelers who cross time zones.
No, on the contrary. The internals keep representing the same point
in time, as utc, but you have it presented as a time in the format
of your choosing.
Set the right sysctls on linux and bsd, and you get this behaviour out of
the box.
-- mrr
Dave Wade
> Relevance today is to use the HA stuff for what it is worth.
>
Just "using the HA stuff" does not deliver HA. To get HA requires an HA
approach and HA culture.
It should to permeate down from top management , through all layers.
Then it has to run across all services. Incident, Capacity & problem
management...
If you do that then you so long as you build and install it properly you can
deliver HA with most of the commodity kit out there....
Dave
jmfbahciv
> In article <hbuoi...@news5.newsguy.com>, jmfbahciv <jmfbahciv@aol> wrote:
>> Anne & Lynn Wheeler wrote:
>>> ly...@GARLIC.COM (Anne & Lynn Wheeler) writes:
>>>> lots of the financial stuff grew up in mainframe batch ... some past
>>>> references/discussions (this from linkedin greater ibm)
>>>> http://www.garlic.com/~lynn/2009o.html#51 8 ways the American information worker remains a Luddite
>>>> and slightly older from year ago
>>>> http://www.garlic.com/~lynn/2008p.html#27 Father of Financial Dataprocessing
>>> re:
>>> http://www.garlic.com/~lynn/2009o.html#81 big iron mainframe vs. x86 servers
>>>
>>> ... at tandem, after leaving ibm, Jim did this study:
>>>
>>> Why Do Computers Stop and What Can Be Done About It?
>>> http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf
>
> Nice to see that paper again. Been a few decades.
<snip>
>>>
>> There is also that pesky problem of not having the "correct" date/time.
>> When that goes "wrong" (and it does twice/year), the effects begin
>> to cascade like a series-->parallel setup of dominos.
>
> This is a solved one. Keep all permanent time stamps in UTC, and
> just have a little conversion layer when presenting this to the user.
That pushes the potential problem down one step to all those
program stubs which are twisty little mazes, not alike.
/BAH
jmfbahciv
>> There is also that pesky problem of not having the "correct" date/time.
>> When that goes "wrong" (and it does twice/year), the effects begin
>> to cascade like a series-->parallel setup of dominos.
>
> re:
> http://www.garlic.com/~lynn/2009p.html#0 big iron mainframe vs. x86 servers
>
> one of the early things that I remember getting draged into after
> graduation and joining the science center (which consumed several
> peoples time and went on for three months) was discussing when did the
> century start and what to do about leap seconds (by comparison, the
> twice a year problem was relatively trivial). this was all about the new
> architecture specification for the 370 64bit TOD clock.
>
it. One idea, which was never implemented by our hardware types,
was to have an inquirer installed with each CPU which would find
the "correct" time, especially if the rebooting system was
unattended.
Someday I might find the letter written to me by somebody in Europe
describing all their date-time problems when I was starting to
do the research for the USAGE project.
/BAH
Joe Pfeiffer
> Anne & Lynn Wheeler wrote:
>> jmfbahciv <jmfbahciv@aol> writes:
>>> There is also that pesky problem of not having the "correct" date/time.
>>> When that goes "wrong" (and it does twice/year), the effects begin
>>> to cascade like a series-->parallel setup of dominos.
>>
>> re:
>> http://www.garlic.com/~lynn/2009p.html#0 big iron mainframe vs. x86 servers
>>
>> one of the early things that I remember getting draged into after
>> graduation and joining the science center (which consumed several
>> peoples time and went on for three months) was discussing when did the
>> century start and what to do about leap seconds (by comparison, the
>> twice a year problem was relatively trivial). this was all about the new
>> architecture specification for the 370 64bit TOD clock.
>>
> Yours was only three months long? ;-) We never stopped discussing
> it. One idea, which was never implemented by our hardware types,
> was to have an inquirer installed with each CPU which would find
> the "correct" time, especially if the rebooting system was
> unattended.
Modern PCs do this.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
Charlton Wilbur
>> There is also that pesky problem of not having the "correct"
>> date/time. When that goes "wrong" (and it does twice/year), the
>> effects begin to cascade like a series-->parallel setup of
>> dominos.
MR> This is a solved one. Keep all permanent time stamps in UTC, and
MR> just have a little conversion layer when presenting this to the
MR> user.
The solution is still a long way from being fully propagated.
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
jmfbahciv
> jmfbahciv <jmfbahciv@aol> writes:
>
>> Anne & Lynn Wheeler wrote:
>>> jmfbahciv <jmfbahciv@aol> writes:
>>>> There is also that pesky problem of not having the "correct" date/time.
>>>> When that goes "wrong" (and it does twice/year), the effects begin
>>>> to cascade like a series-->parallel setup of dominos.
>>> re:
>>> http://www.garlic.com/~lynn/2009p.html#0 big iron mainframe vs. x86 servers
>>>
>>> one of the early things that I remember getting draged into after
>>> graduation and joining the science center (which consumed several
>>> peoples time and went on for three months) was discussing when did the
>>> century start and what to do about leap seconds (by comparison, the
>>> twice a year problem was relatively trivial). this was all about the new
>>> architecture specification for the 370 64bit TOD clock.
>>>
>> Yours was only three months long? ;-) We never stopped discussing
>> it. One idea, which was never implemented by our hardware types,
>> was to have an inquirer installed with each CPU which would find
>> the "correct" time, especially if the rebooting system was
>> unattended.
>
> Modern PCs do this.
>
/BAH
Patrick Scheible
Actually, the batteries don't have to be working, but the internet
does.
-- Patrick
Charlie Gibbs
(Morten Reistad) writes:
> In article <proto-D96AA0....@news.panix.com>,
>
> Walter Bushell <pr...@panix.com> wrote:
>
>> In article <qm9br6-...@laptop.reistad.name>,
>>
>>> This is a solved one. Keep all permanent time stamps in UTC, and
>>> just have a little conversion layer when presenting this to the
>>> user.
>>
>> OBTO: That requires an intelligent designer. [1]
>>
>> And is a constant problem of road warriors and an annoyance for
>> casual travelers who cross time zones.
>
> No, on the contrary. The internals keep representing the same point
> in time, as utc, but you have it presented as a time in the format
> of your choosing.
Exactly. UTC has been the standard in aviation for decades for this
very reason.
> Set the right sysctls on linux and bsd, and you get this behaviour
> out of the box.
I'm still a little surprised that keeping the hardware clock in UTC
isn't the default on Linux installs.
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Charlie Gibbs
g8...@yahoo.com (Dave Wade) writes:
>> Relevance today is to use the HA stuff for what it is worth.
>
> Just "using the HA stuff" does not deliver HA. To get HA requires
> an HA approach and HA culture.
> It should to permeate down from top management , through all layers.
> Then it has to run across all services. Incident, Capacity & problem
> management...
Top management? Good luck.
And then there's Microsoft...
howard...@cusys.edu
wrote:
>> No, on the contrary. The internals keep representing the same point
>> in time, as utc, but you have it presented as a time in the format
>> of your choosing.
>
>Exactly. UTC has been the standard in aviation for decades for this
>very reason.
With 20-20 hindsight, all computers should have started off marking
files that way. It's not easy changing, but it would really be worth
it.
Especially for those sites that gradually change the time to make sure
transactions get stored in order as the clock bumps back because of
daylight savings time - but also for any multi-time zone database.
Morten Reistad
No, no batteries required. Just NTP, and updated tzdata for
the local presentation. Library, system provided, code takes
care of the details. I even have a .deb and .rpm on my home
server that downloads a script to do this right, 6 lines of
code.
This is sysadmin 101. All linux distros, bsds, even symbian and beos,
and all the commercial unixen do this right. I just let the windows boxes
get time from ntp.
Hardware need not know calenders. Hardware needs to know a
uniformly increasing number of ticks, and store a boot time
so userland can make sense of the ticks.
-- mrr
Anne & Lynn Wheeler
"Charlie Gibbs" <cgi...@kltpzyxm.invalid> writes:
> Top management? Good luck.
>
> And then there's Microsoft...
re:
http://www.garlic.com/~lynn/2009o.html#81 big iron mainframe vs. x86 servers
http://www.garlic.com/~lynn/2009p.html#0 big iron mainframe vs. x86 servers
http://www.garlic.com/~lynn/2009p.html#7 big iron mainframe vs. x86 servers
Jim and I had a little dust up at acm sigops '91 ... about whether
commodity component clusters could provide HA ... of course he was then
at DEC (and pushing DEC cluster database and previously at tandem).
DEC then sold their dbms group to oracle and jim took a sabbatical. he
came back for m'soft sanfran research center ... and then had to get up
on stage as part of m'soft's (commodity component) cluster/HA
announcement.
misc. past posts mentioning our ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp
and misc. old email about work on ha/cmp cluster scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa
misc. other recent posts mentioning tandem
http://www.garlic.com/~lynn/2009o.html#2 IMS
http://www.garlic.com/~lynn/2009o.html#51 8 ways the American information worker remains a Luddite
http://www.garlic.com/~lynn/2009o.html#58 Rudd bucks boost IBM mainframe business
http://www.garlic.com/~lynn/2009o.html#77 Is it time to stop research in Computer Architecture ?
Bernd Felsche
>(Morten Reistad) writes:
>> Walter Bushell <pr...@panix.com> wrote:
>>> In article <qm9br6-...@laptop.reistad.name>,
>>>> This is a solved one. Keep all permanent time stamps in UTC, and
>>>> just have a little conversion layer when presenting this to the
>>>> user.
>>> OBTO: That requires an intelligent designer. [1]
>>> And is a constant problem of road warriors and an annoyance for
>>> casual travelers who cross time zones.
>> No, on the contrary. The internals keep representing the same point
>> in time, as utc, but you have it presented as a time in the format
>> of your choosing.
>Exactly. UTC has been the standard in aviation for decades for this
>very reason.
>> Set the right sysctls on linux and bsd, and you get this behaviour
>> out of the box.
>I'm still a little surprised that keeping the hardware clock in UTC
>isn't the default on Linux installs.
Depends on the installer. The openSUSE one appaers to note the
presence of a blue-screen OS and then default to local time whereas
installing to an untainted system defaults to UTC.
I think that's a good compromise ... allowing for the stupidity of
others.
--
/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia
\ / ASCII ribbon campaign | Those who can make you believe absurdities
X against HTML mail | can make you commit atrocities.
/ \ and postings | -- Voltaire
jmfbahciv
the system comes up with date 0 (whatever that translates to).
If your system requires any date comparisons before connecting
to the internet your data is toasted bits that have flopped
off the disk.
/BAH
jmfbahciv
keeping the system sleep warm), and the date is wrong, all
kinds of things can go worng. If the system has one bit
that is important, it will be that bit that goes kaphlooey.
/BAH
jmfbahciv
> On 26 Oct 09 08:41:40 -0800, "Charlie Gibbs" <cgi...@kltpzyxm.invalid>
> wrote:
>
>>> No, on the contrary. The internals keep representing the same point
>>> in time, as utc, but you have it presented as a time in the format
>>> of your choosing.
>> Exactly. UTC has been the standard in aviation for decades for this
>> very reason.
>
> With 20-20 hindsight, all computers should have started off marking
> files that way. It's not easy changing, but it would really be worth
> it.
How? Count your bits. Oh, and think about IBM cards.
>
> Especially for those sites that gradually change the time to make sure
> transactions get stored in order as the clock bumps back because of
> daylight savings time - but also for any multi-time zone database.
Don't confuse the correct time of day with time flow recordings. W.r.t.
processing, most time usages have to do with comparisons, i.e.,
connect time.
/BAH
howard...@cusys.edu
>> With 20-20 hindsight, all computers should have started off marking
>> files that way. It's not easy changing, but it would really be worth
>> it.
>
>How? Count your bits. Oh, and think about IBM cards.
I meant, all files marked with time, should have been marked with
UTC/Zulu/Grenwich.
Charlie Gibbs
writes:
So you design the system such that it doesn't care about the
exact date and time until it's managed to pull it from the net.
With a bit of care (as you said, "if the coding is correct"),
any monotonically-increasing counter will do as a clock
long enough for you to get out to the net.
Charles Richmond
Is the clock chip now part of the CPU??? In the olden PC days, the
clock chip was separate from the CPU, and of course required (does
require today) a battery.
--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+
Patrick Scheible
Pulling the correct date and time off the internet is done fairly
early in the booting process. Certainly before starting a database
application. It might be an interesting experiment for the next time
I dust out and reboot my computer.
Some users of NTP set it so that if the time fetched from the time
server is more than, say, 5 minutes different from what their clock
says, it figures Moriarity has spoofed the time server and it won't
change the clock. In that case the battery would need to be working.
However, lots of people just trust the time server.
-- Patrick
Eric Chomko
Why?
For space applications, sure. A satellite that orbits in 101 minutes
had better use UTC, but why humans on Earth in the same place? You
think UTC tells you anything about where the Earth's terminator is?
When the Earth is facing totally opposite the Sun on any given day.
No, local time is a must for determining exactly when the sun will
rise where you are!
Heck well can live with two measuring systems, we can live with two
times.
Eric
Scott Lurndal
>On Oct 27, 8:59=A0am, howard.bra...@cusys.edu wrote:
>> On Tue, 27 Oct 2009 08:10:18 -0500, jmfbahciv <jmfbahciv@aol> wrote:
>> >> With 20-20 hindsight, all computers should have started off marking
>th
>> >> it. =A0 =A0
>>
>> >How? =A0Count your bits. =A0Oh, and think about IBM cards.
>>
>> I meant, all files marked with time, should have been marked with
>> UTC/Zulu/Grenwich.
>
>Why?
>
>For space applications, sure. A satellite that orbits in 101 minutes
>had better use UTC, but why humans on Earth in the same place? You
>think UTC tells you anything about where the Earth's terminator is?
>When the Earth is facing totally opposite the Sun on any given day.
>No, local time is a must for determining exactly when the sun will
>rise where you are!
So a database running in New York stores an item at 8:10 local. A
database running in California stores an item at 8:11 local. Which data item
was stored first? Storing timestamps in UTC is the only sensible
way to store them.
scott
Andy Wood
"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
Any constant field could be called monotonically increasing, but would
not be much use as a clock.
>
>--
>/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
>\ / I'm really at ac.dekanfrus if you read it the right way.
> X Top-posted messages will probably be ignored. See RFC1855.
>/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
>
Andy Wood
woo...@trap.ozemail.com.au
howard...@cusys.edu
<pne.c...@comcast.net> wrote:
>For space applications, sure. A satellite that orbits in 101 minutes
>had better use UTC, but why humans on Earth in the same place? You
>think UTC tells you anything about where the Earth's terminator is?
>When the Earth is facing totally opposite the Sun on any given day.
>No, local time is a must for determining exactly when the sun will
>rise where you are!
>
>Heck well can live with two measuring systems, we can live with two
>times.
My computer doesn't care where the sun is. If it needs to support
people 24 hours per day, maybe anywhere in the world, what does the
sun have to do with it?
But if it is important to know when data are modified, having over 24
time zones has no advantage. Mark it with a common, universal time.
The display routine can change it to local time just fine for users,
even when the users are on the opposite sides of the Earth.
Dave Wade
news:fWGFm.68197$oS.3...@news.usenetserver.com...
> Eric Chomko <pne.c...@comcast.net> writes:
>>On Oct 27, 8:59=A0am, howard.bra...@cusys.edu wrote:
>>> On Tue, 27 Oct 2009 08:10:18 -0500, jmfbahciv <jmfbahciv@aol> wrote:
>>> >> With 20-20 hindsight, all computers should have started off marking
>>> >> files that way. =A0 It's not easy changing, but it would really be
>>> >> wor=
>>th
>>> >> it. =A0 =A0
>>>
>>> >How? =A0Count your bits. =A0Oh, and think about IBM cards.
>>>
>>> I meant, all files marked with time, should have been marked with
>>> UTC/Zulu/Grenwich.
Whilst you might set the zone to GMT if you sync the clock to the Internet
it will be set to UTC.
<And yes there is a difference>
Walter Bushell
sc...@slp53.sl.home (Scott Lurndal) wrote:
You take your laptop to Hawaii from NYC and it shows the local time, but
keeps the internal times consistent.
--
A computer without Microsoft is like a chocolate cake without mustard.
Morten Reistad
We have three concepts here. First, the kernel time. This needs to
be a sufficiently uniformly increasing tick to take kernel-type decisions
from, like scheduling, garbage collecting packet buffers, retransmitting
packets etc. The kernel does not care where the sun is, and very, very
little about absolute time. Set the right sysctl, and linux/bsd ticks
happily away like this.
Next, application time. There is a good reason to normalise this
kernel tick to some epoch, like 1.1.70, 1.1.80, 17.11.1857, 1.1.1900
or some other fixed time; and synchronise this time; still a uniformly
increasing integer so persistent data is correct. The database internals,
file timestamps, or other storage designed to make computer programs
happy very rarely care about actual calendar functions. Fire up NTP, and
keep using the recommended library functions; and times are stored in
some time counter format.
The last is user time. Then we have to handle timezones, all 43, dst,
calendars, weekdays, leap days, full moons, episcopalian and synodic easter,
and all that other stuff. But computing in these formats is a nightmare,
orders of magnitude worse than doing differential equations in roman
numerals.
So, let the computer handle things in the first two formats, and
have a little setting, like a shell variable "TZ" informing the display
functions how the human wants the time presented.
This is how all the posix stuff handles time.
So, you take your laptop to Hawaii? Set the timezone to whatever that
Hawaiian time zone is named (there are graphical user interfaces for this
where you can point at the little dot in the Pacific ocean and set the
time from there), Voila, you get a time presentation that fits Hawaii.
But the timestamps in your file system did not change. The sql
TIMESTAMP variables are the same, the values are just presented differently.
-- mrr
Morten Reistad
It has been more than a decade since this one was fixed.
Yes, the pc may have issues if the bios battery is dead, but
the time is no longer critical. The first seconds of the boot
will have a way-back time like 1.1.1970; and then you run
ntptime to get a sort-of-good time (good to a few hundred ms),
finish the boot; and start real ntp in the process.
Just a local network with time servers on is fine.
-- mrr
Morten Reistad
Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
>In article <4MednS2bHLYKDH7X...@eclipse.net.uk>,
>g8...@yahoo.com (Dave Wade) writes:
>
>>> Relevance today is to use the HA stuff for what it is worth.
>>
>> Just "using the HA stuff" does not deliver HA. To get HA requires
>> an HA approach and HA culture.
>> It should to permeate down from top management , through all layers.
>> Then it has to run across all services. Incident, Capacity & problem
>> management...
There are pretty comprehensive "best current practice" documents
for the "juniks" world, and especially for Linux. All the necessary
components for failovers etc. are just a "yum" or "apt" away.
Implementing this for a server farm isn't "sysadmin 101", but it
should be "201". Setting up servers on isolated power, network,
cooling etc with failover for databases, network protocols etc
should be routine work for anyone calling themselves "system
administrator". It is not particularly hard to do; it just requires
a little attention to detail.
Just doing this mechanically should add a whole digit to your
uptime figure. This is what I mean by "turning on HA".
A Naive IT installation typically starts out at 1.5 nines uptime,
or somewhere around 96%. Here we expect to be out for two days
if a disk fails, or a day if we lose power.
The we add hardware protection, dual power, at least one of which
is an UPS, mirrored/raid disks, kvm, rack mount and dual network
access; and we get at least another digit. 99.6%. Single disk
failures, network outages and fuse problems do not affect uptime.
Then we add the basic, packaged HA stuff with multiple servers,
and we get another digit, 99.96%.
This is what I consider a baseline to work from. In many instances
this baseline is OK. I would say it is for all corporate installations
where IT is not minute-to-minute business critical.
Because this is where the going gets touch.
I know, and have been involved in, projects where direct nuclear
hits are planned for, and sabotage, falling airplanes, demonstrations,
power strikes etc are all in the planning. Still they struggle to
stay at five nines.
>Top management? Good luck.
I would regard my baseline as the threshold for where I would
need specific attention from management. Below that it is just
good system administration.
>And then there's Microsoft...
Let them handle their own HA.
-- mrr
Charles Richmond
When you check the times that you stored files in NYC, are the
times automatically converted to local Hawaiian time???
jmfbahciv
How can you store that in 8 bits?
/BAH
jmfbahciv
trust which time?
/BAH
jmfbahciv
is "remembered" is by not pulling the rechargable battery.
I have at least one other system which has a dead "cpu" battery that
cannot be replaced.
/BAH
jmfbahciv
Calling the ISP is not part of my booting process. {{{shudder}}}}
>
> Some users of NTP set it so that if the time fetched from the time
> server is more than, say, 5 minutes different from what their clock
> says, it figures Moriarity has spoofed the time server and it won't
> change the clock. In that case the battery would need to be working.
> However, lots of people just trust the time server.
I was paid a lot of money to not trust :-). OS developers shouldn't
trust just any old time server. Think about a rogue attack.
/BAH
jmfbahciv
access to a Boss CPU who has been assigned to keep the date-time.
/BAH
jmfbahciv
And then you have that pesky little problem where c is too slow.
/BAH
jmfbahciv
<snip excellent synopsis>
Seems to me there should be one other category but I can't think of it
right now.
>
> The last is user time. Then we have to handle timezones, all 43, dst,
> calendars, weekdays, leap days, full moons, episcopalian and synodic easter,
> and all that other stuff. But computing in these formats is a nightmare,
> orders of magnitude worse than doing differential equations in roman
> numerals.
What an evil thought. JMF would have appreciated that analogy.
When we were talking about which date-times to record in the USAGE
files, we finally decided we didn't know enough to choose. So
we recorded the date-time the system had and left all the rest
as an exercise for the downstream billing program which would
be written by the people who lived in that date-time environment.
Some days, in OS design, it's better to do nothing.
/BAH
Joe Pfeiffer
You can't. You can't store a timestamp with a useful granularity in
eight bits in any other timezone, either. If anything, storing a
timestamp takes less bits if they're all UTC, since you don't need to
store what timezone it is.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
howard...@cusys.edu
wrote:
>>>> I meant, all files marked with time, should have been marked with
>>>> UTC/Zulu/Grenwich.
>
>Whilst you might set the zone to GMT if you sync the clock to the Internet
>it will be set to UTC.
><And yes there is a difference>
It hasn't always been so, and I'm talking 20-20 hindsight about the
way things would have been done.
Walter Bushell
wrote:
That part of the system you have coded by code apes.
Walter Bushell
Charles Richmond
> jmfbahciv <jmfbahciv@aol> writes:
>
>> howard...@cusys.edu wrote:
>>> On Tue, 27 Oct 2009 08:10:18 -0500, jmfbahciv <jmfbahciv@aol> wrote:
>>>
>>>>> With 20-20 hindsight, all computers should have started off marking
>>>>> files that way. It's not easy changing, but it would really be worth
>>>>> it.
>>>> How? Count your bits. Oh, and think about IBM cards.
>>> I meant, all files marked with time, should have been marked with
>>> UTC/Zulu/Grenwich.
>> How can you store that in 8 bits?
>
> You can't. You can't store a timestamp with a useful granularity in
> eight bits in any other timezone, either. If anything, storing a
> timestamp takes less bits if they're all UTC, since you don't need to
> store what timezone it is.
In this age of gigabytes of RAM and terabytes of hard disk space,
it seems silly to worry about how many bits a timestamp will take.
On a software system I worked on at a PPoE, we kept the timestamp
as a 20 byte character *string*: "MM/DD/YYYY HH:MM:SS". Adding
the NULL at the end of a C string makes 20 bytes. IIRC it was
local time, and conversions were necessary to compare the times
and dates.
Patrick Scheible
You only let the code monkeys work on application code that runs after
bootup is complete.
-- Patrick
Patrick Scheible
I guess you'd better make sure your batteries are working then...
> > Some users of NTP set it so that if the time fetched from the time
> > server is more than, say, 5 minutes different from what their clock
> > says, it figures Moriarity has spoofed the time server and it won't
> > change the clock. In that case the battery would need to be working.
> > However, lots of people just trust the time server.
>
> I was paid a lot of money to not trust :-). OS developers shouldn't
> trust just any old time server. Think about a rogue attack.
Well, it isn't "any old" time server. It's one they've chosen to be
trustworthy, within their own organization if it's large or medium
sized. And it isn't just one, they usually consult several.
-- Patrick
Walter Bushell
Charles Richmond <fri...@tx.rr.com> wrote:
The times you see with the localization set to Hawaii will be in
Hawaiian time.
Eric Chomko
Who cares!? There is no practical reason why a NY store and a CA store
need to know a stocking time difference between them! But if I was
the guy in NY and someone told me the store opened at 8am but he was
referring to CA time, I'd be pissed that I was three hours late.
Eric Chomko
> On Tue, 27 Oct 2009 10:26:38 -0700 (PDT), Eric Chomko
>
> >For space applications, sure. A satellite that orbits in 101 minutes
> >had better use UTC, but why humans on Earth in the same place? You
> >think UTC tells you anything about where the Earth's terminator is?
> >When the Earth is facing totally opposite the Sun on any given day.
> >No, local time is a must for determining exactly when the sun will
> >rise where you are!
>
> >Heck well can live with two measuring systems, we can live with two
> >times.
>
> My computer doesn't care where the sun is. If it needs to support
> people 24 hours per day, maybe anywhere in the world, what does the
> sun have to do with it?
It doesn't.
> But if it is important to know when data are modified, having over 24
> time zones has no advantage. Mark it with a common, universal time.
> The display routine can change it to local time just fine for users,
> even when the users are on the opposite sides of the Earth.
Yes, the GMT +/- value in time functions.
I use GMT all the time. But I don't want someone to tell me what time
it is in GMT.
Eric Chomko
> In article <aseee5h6q7qg724gkrinq9s1lcdetoa...@4ax.com>,
Don't you mean 1/1/70, 1/1/80, 11/17/1857 and 1/1/1900?
> or some other fixed time; and synchronise this time; still a uniformly
> increasing integer so persistent data is correct. The database internals,
> file timestamps, or other storage designed to make computer programs
> happy very rarely care about actual calendar functions. Fire up NTP, and
> keep using the recommended library functions; and times are stored in
> some time counter format.
>
> The last is user time. Then we have to handle timezones, all 43, dst,
> calendars, weekdays, leap days, full moons, episcopalian and synodic easter,
> and all that other stuff. But computing in these formats is a nightmare,
> orders of magnitude worse than doing differential equations in roman
> numerals.
Yes, the Calendar
> So, let the computer handle things in the first two formats, and
> have a little setting, like a shell variable "TZ" informing the display
> functions how the human wants the time presented.
>
> This is how all the posix stuff handles time.
>
> So, you take your laptop to Hawaii? Set the timezone to whatever that
> Hawaiian time zone is named (there are graphical user interfaces for this
> where you can point at the little dot in the Pacific ocean and set the
> time from there), Voila, you get a time presentation that fits Hawaii.
>
> But the timestamps in your file system did not change. The sql
> TIMESTAMP variables are the same, the values are just presented differently.
>
Exactly. The time is still the time. It is just a matter of
representation. And to think that a single time is sufficient on the
Earth doesn't account for location. As there is such a thing as day,
night, morning and evening and all times in between on Earth.
Eric Chomko
c = 186,000 mps
It's the law!
Scott Lurndal
Compared to what? Modern optimizing C compilers are far, far better than most
humans writing assembly. (There are some bit-gods that can do better
than the compiler, but the techniques vary based on the processor vendor,
family and model and the percentage of programmers that fit this category
is miniscule).
Or are you referring the physical constant denoting the speed of light?
scott
sidd
> Any constant field could be called monotonically increasing, but would
> not be much use as a clock.
please ? i thought monotonically increasing went sumpn like:
given a function f with domain and range the real line R, then we have
f(x1)>f(x2) if and only if x1>x2, x1,x2 in R
i think we can replace R with any partially ordered set, but the 'strictly
greater than' inequality is part of the 'monotonic' definition ?
or i am all muddled up like usual ?
Eric Chomko
> jmfbahciv <jmfbahciv@aol> writes:
> > howard.bra...@cusys.edu wrote:
> >> On Tue, 27 Oct 2009 08:10:18 -0500, jmfbahciv <jmfbahciv@aol> wrote:
>
> >>>> With 20-20 hindsight, all computers should have started off marking
> >>>> files that way. It's not easy changing, but it would really be worth
> >>>> it.
> >>> How? Count your bits. Oh, and think about IBM cards.
>
> >> I meant, all files marked with time, should have been marked with
> >> UTC/Zulu/Grenwich.
>
> > How can you store that in 8 bits?
>
> You can't. You can't store a timestamp with a useful granularity in
> eight bits in any other timezone, either. If anything, storing a
> timestamp takes less bits if they're all UTC, since you don't need to
> store what timezone it is.
That is true.
For space applications timestamps are usually or typically stored in
64-bit long words, either as a segmented time code or unsegmented time
code.
For segmented time code it is 16 bits for number of days since
1/1/1958, 32 bits for milliseconds of day and 16 bits for microseconds
of millisecond.
For unsegmented time code there is a so-called preamble field that
contains the number of leap seconds to date (7 bits of the first 16
bits) followed by a 32 bits
for number of seconds since 1/1/1958 and a 16 bit subseconds fields
that equals ~15.259 microseconds per bit incrementation.
Eric
Eric Chomko
> Joe Pfeiffer wrote:
> > jmfbahciv <jmfbahciv@aol> writes:
>
> >>> On Tue, 27 Oct 2009 08:10:18 -0500, jmfbahciv <jmfbahciv@aol> wrote:
>
> >>>>> With 20-20 hindsight, all computers should have started off marking
> >>>>> files that way. It's not easy changing, but it would really be worth
> >>>>> it.
> >>>> How? Count your bits. Oh, and think about IBM cards.
> >>> I meant, all files marked with time, should have been marked with
> >>> UTC/Zulu/Grenwich.
> >> How can you store that in 8 bits?
>
> > You can't. You can't store a timestamp with a useful granularity in
> > eight bits in any other timezone, either. If anything, storing a
> > timestamp takes less bits if they're all UTC, since you don't need to
> > store what timezone it is.
>
> In this age of gigabytes of RAM and terabytes of hard disk space,
> it seems silly to worry about how many bits a timestamp will take.
Though you do need to know and it should be fixed like 64 bits.
> On a software system I worked on at a PPoE, we kept the timestamp
> as a 20 byte character *string*: "MM/DD/YYYY HH:MM:SS". Adding
> the NULL at the end of a C string makes 20 bytes. IIRC it was
> local time, and conversions were necessary to compare the times
> and dates.
And we use: YYYY/DOY/HH:MM:SS.uuuuuu
where DOY is day of year and uuuuuu is subseconds (mircoseconds).
Eric Chomko
> In article <hc99hl51...@news3.newsguy.com>, jmfbahciv <jmfbahciv@aol>
> wrote:
>
>
>
>
>
> > Charlie Gibbs wrote:
> > > In article <hc6p9e02...@news6.newsguy.com>, jmfbahciv@aol (jmfbahciv)
And specifically the orangutans and chimpanzes as the gorillas are
just to heavy handed on the keyboard.
Eric Chomko
> Charles Richmond wrote:
> > jmfbahciv wrote:
> >> Patrick Scheible wrote:
> >>> jmfbahciv <jmfbahciv@aol> writes:
>
> >>>> Joe Pfeiffer wrote:
> >>>>> jmfbahciv <jmfbahciv@aol> writes:
>
> >>>>>> Anne & Lynn Wheeler wrote:
> >>>>>>> jmfbahciv <jmfbahciv@aol> writes:
> >>>>>>>> There is also that pesky problem of not having the "correct"
> >>>>>>>> date/time.
> >>>>>>>> When that goes "wrong" (and it does twice/year), the effects begin
> >>>>>>>> to cascade like a series-->parallel setup of dominos.
> >>>>>>> re:
Cannot be replaced or is really hard to replace? I have managed to
hack in quite a few new batteries in old systems when I really wanted
to. :)
Eric Chomko
> Patrick Scheible wrote:
> > jmfbahciv <jmfbahciv@aol> writes:
>
> >> Patrick Scheible wrote:
> >>> jmfbahciv <jmfbahciv@aol> writes:
>
> >>>> Joe Pfeiffer wrote:
> >>>>> jmfbahciv <jmfbahciv@aol> writes:
>
> >>>>>> Anne & Lynn Wheeler wrote:
> >>>>>>> jmfbahciv <jmfbahciv@aol> writes:
> >>>>>>>> There is also that pesky problem of not having the "correct" date/time.
> >>>>>>>> When that goes "wrong" (and it does twice/year), the effects begin
> >>>>>>>> to cascade like a series-->parallel setup of dominos.
> >>>>>>> re:
The only rogue attack on an old system is by some guy that is better
described as a goon rather than a rogue.
Eric Chomko
> In article <hc6p9e02...@news6.newsguy.com>, jmfbahciv <jmfbahciv@aol> wrote:
> >Patrick Scheible wrote:
> >> jmfbahciv <jmfbahciv@aol> writes:
>
> >>>>> unattended.
> >>>> Modern PCs do this.
>
> >>> Only if the coding is correct and other things work, e.g. batteries.
>
> >> Actually, the batteries don't have to be working, but the internet
> >> does.
>
> >Actually, the battery to the CPU has to be working. Otherwise
> >the system comes up with date 0 (whatever that translates to).
> >If your system requires any date comparisons before connecting
> >to the internet your data is toasted bits that have flopped
> >off the disk.
>
>
> Yes, the pc may have issues if the bios battery is dead, but
> the time is no longer critical. The first seconds of the boot
> will have a way-back time like 1.1.1970; and then you run
> ntptime to get a sort-of-good time (good to a few hundred ms),
> finish the boot; and start real ntp in the process.
>
> Just a local network with time servers on is fine.
>
Its nice to see you guys from Europe getting the dates right when the
day number matches the month number. Now if we can only get you to
remove the decimal points within the dates and replace them with
strokes... now there's a good fellow.
Charlie Gibbs
(Charles Richmond) writes:
> In this age of gigabytes of RAM and terabytes of hard disk space,
> it seems silly to worry about how many bits a timestamp will take.
> On a software system I worked on at a PPoE, we kept the timestamp
> as a 20 byte character *string*: "MM/DD/YYYY HH:MM:SS". Adding
> the NULL at the end of a C string makes 20 bytes. IIRC it was
> local time, and conversions were necessary to compare the times
> and dates.
That should be "YYYY/MM/DD HH:MM:SS" so it'll sort properly.
But you're right, times have changed. Quoting from "The Mythical
Man-Month":
For example, OS/360 devotes 26 bytes of the permanently
resident date-turnover routine to the proper handling of
December 31 on leap years (when it is Day 366). That might
have been left to the operator.
As much as I hate bloatware, I'm glad we don't have to squeeze
things that tightly anymore.
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Peter Flass
And probably afraid of mice.
Charles Richmond
>>
>> In this age of gigabytes of RAM and terabytes of hard disk space,
>> it seems silly to worry about how many bits a timestamp will take.
>
> Though you do need to know and it should be fixed like 64 bits.
>
Hey, I'm feeling generous. Take 256 bits for the time stamp. What
you can't use now, just put "reserved" on the definition.
Charles Richmond
> In article <hc9shr$di1$1...@news.eternal-september.org>, fri...@tx.rr.com
> (Charles Richmond) writes:
>
>> In this age of gigabytes of RAM and terabytes of hard disk space,
>> it seems silly to worry about how many bits a timestamp will take.
>> On a software system I worked on at a PPoE, we kept the timestamp
>> as a 20 byte character *string*: "MM/DD/YYYY HH:MM:SS". Adding
>> the NULL at the end of a C string makes 20 bytes. IIRC it was
>> local time, and conversions were necessary to compare the times
>> and dates.
>
> That should be "YYYY/MM/DD HH:MM:SS" so it'll sort properly.
>
Yes, that would be more useful to sort. But we did *not* do the
timestamp this way. The timestamp was created in an "easy to read"
format, and comparisons required some conversions first.
We did *not* do a lot of sorting the timestamps, in any case.
> But you're right, times have changed. Quoting from "The Mythical
> Man-Month":
>
> For example, OS/360 devotes 26 bytes of the permanently
> resident date-turnover routine to the proper handling of
> December 31 on leap years (when it is Day 366). That might
> have been left to the operator.
>
> As much as I hate bloatware, I'm glad we don't have to squeeze
> things that tightly anymore.
>
Over-abundance of a resource almost always leads to wasteful
behavior. But certainly, there are great benefits for having
"adequate" space and CPU power resources to get things done.
Charles Richmond
c = 186,000 mps. It's *not* just a suggetion; it's the law!
(That paraphrases the old "55 miles per hour" speed limit PSA's.)
Charles Richmond
> On Oct 28, 12:44 pm, Walter Bushell <pr...@panix.com> wrote:
>> In article <hc99hl51...@news3.newsguy.com>, jmfbahciv <jmfbahciv@aol>
>> wrote:
>>
>>
>>> Sure. Now how do you train all those code monkeys to not
>>> trust which time?
>>> /BAH
>> That part of the system you have coded by code apes.
>>
>
> And specifically the orangutans and chimpanzes as the gorillas are
> just to heavy handed on the keyboard.
>
:-)
Back in college 30 years ago, I knew a guy who probably weighed
250 pounds and was an engineering major. He was in the faction
that adored computers. We had these old Tel-Ray terminals and were
running Wylbur on an IBM 370/155.
This large guy really *pounded* those flimsy keys on that junky
terminal. I mean, he beat the hell out of it!!! So he might have
been one of those "heavy handed apes" that you speak of, but *I*
was *not* going to be the one to tell him that! ;-)
Charles Richmond
> On Oct 28, 7:36 am, jmfbahciv <jmfbahciv@aol> wrote:
>> Charles Richmond wrote:
>>>
>>>
>>> Is the clock chip now part of the CPU??? In the olden PC days, the clock
>>> chip was separate from the CPU, and of course required (does require
>>> today) a battery.
>>
>> I have one in this system which is dead. The only way the date-time
>> is "remembered" is by not pulling the rechargable battery.
>> I have at least one other system which has a dead "cpu" battery that
>> cannot be replaced.
>>
>
> Cannot be replaced or is really hard to replace? I have managed to
> hack in quite a few new batteries in old systems when I really wanted
> to. :)
I had really good luck finding batteries at <www.ebatts.com>.
Their prices are *not* bad either, compared to what local stores
wanted to gouge me for... on "obsolete" style batteries.
(Disclaimer: I have *no* financial arrangement to promote eBatts;
I'm only a satisfied customer.)
jmfbahciv
> Joe Pfeiffer wrote:
>> jmfbahciv <jmfbahciv@aol> writes:
>>
>>> howard...@cusys.edu wrote:
>>>> On Tue, 27 Oct 2009 08:10:18 -0500, jmfbahciv <jmfbahciv@aol> wrote:
>>>>
>>>>>> With 20-20 hindsight, all computers should have started off marking
>>>>>> files that way. It's not easy changing, but it would really be
>>>>>> worth
>>>>>> it.
>>>>> How? Count your bits. Oh, and think about IBM cards.
>>>> I meant, all files marked with time, should have been marked with
>>>> UTC/Zulu/Grenwich.
>>> How can you store that in 8 bits?
>>
>> You can't. You can't store a timestamp with a useful granularity in
>> eight bits in any other timezone, either. If anything, storing a
>> timestamp takes less bits if they're all UTC, since you don't need to
>> store what timezone it is.
>
> In this age of gigabytes of RAM and terabytes of hard disk space, it
> seems silly to worry about how many bits a timestamp will take. On a
> software system I worked on at a PPoE, we kept the timestamp as a 20
> byte character *string*: "MM/DD/YYYY HH:MM:SS". Adding the NULL at the
> end of a C string makes 20 bytes. IIRC it was local time, and
> conversions were necessary to compare the times and dates.
>
are invalid these days.
/BAH
jmfbahciv
/BAH
jmfbahciv
This is so wrong, it isn't even wrong.
>But if I was
> the guy in NY and someone told me the store opened at 8am but he was
> referring to CA time, I'd be pissed that I was three hours late.
/BAH
jmfbahciv
Of course. And it's very slow.
/BAH
jmfbahciv
because of formatting differences.
/BAH
jmfbahciv
Yes. I spelled it c, not C.
/BAH
jmfbahciv
> In article <hc9shr$di1$1...@news.eternal-september.org>, fri...@tx.rr.com
> (Charles Richmond) writes:
>
>> In this age of gigabytes of RAM and terabytes of hard disk space,
>> it seems silly to worry about how many bits a timestamp will take.
>> On a software system I worked on at a PPoE, we kept the timestamp
>> as a 20 byte character *string*: "MM/DD/YYYY HH:MM:SS". Adding
>> the NULL at the end of a C string makes 20 bytes. IIRC it was
>> local time, and conversions were necessary to compare the times
>> and dates.
>
> That should be "YYYY/MM/DD HH:MM:SS" so it'll sort properly.
You will never convince the hardware types to do that.
>
> But you're right, times have changed. Quoting from "The Mythical
> Man-Month":
>
> For example, OS/360 devotes 26 bytes of the permanently
> resident date-turnover routine to the proper handling of
> December 31 on leap years (when it is Day 366). That might
> have been left to the operator.
>
> As much as I hate bloatware, I'm glad we don't have to squeeze
> things that tightly anymore.
>
Now we have to squeeze other nefarious things tightly.
/BAH
Patrick Scheible
Find coders who are at least up to chimpanzee level for code that runs
before bootup is complete.
-- Patrick
Ahem A Rivet's Shot
jmfbahciv <jmfbahciv@aol> wrote:
> But nobody agrees on your format either. And ASCII-7 strings
> are invalid these days.
Nope they're a perfectly good and useful subset of UTF-8 encoded
Unicode.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
jmfbahciv
> On Thu, 29 Oct 2009 07:31:30 -0500
> jmfbahciv <jmfbahciv@aol> wrote:
>
>> But nobody agrees on your format either. And ASCII-7 strings
>> are invalid these days.
>
> Nope they're a perfectly good and useful subset of UTF-8 encoded
> Unicode.
>
/BAH
Ahem A Rivet's Shot
I /hope/ the Unicode standard will last a long time, unlike all
preceeding standards for character encoding it has plenty of scope for
expansion. It'll probably need a major revision when the Galactic
Federation gets in touch but it shouldn't need much doing to it before then.
Joe Pfeiffer
Unicode has a lot of inertia at this point, and 7-bit ASCII has more. I
can reasonably expect both of them to last long after my death, and docs
and conversion programs until civilization collapses to the point
computers are gone.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
howard...@cusys.edu
<pfei...@cs.nmsu.edu> wrote:
>Unicode has a lot of inertia at this point, and 7-bit ASCII has more. I
>can reasonably expect both of them to last long after my death, and docs
>and conversion programs until civilization collapses to the point
>computers are gone.
How about EBCDIC?
grey...@mail.com
uuencode stuff is still very common on the Internet.
--
Greymaus....
\/\
\?
Joe Pfeiffer
What about it? If I needed to read it, it would be one-line awk script
away. Sort of my point.
Eric Chomko
They morph into something else not unlike x86 starting with an 8086
and being an x86 to this day from chips by Intel and AMD.
ASCII is still embedded withing Unicode.
That is the thing about standards, if you can ensure backward
compatibility, then no one can complain when new things are added.
Eric Chomko
> On Fri, 30 Oct 2009 09:45:04 -0600, Joe Pfeiffer
>
> >Unicode has a lot of inertia at this point, and 7-bit ASCII has more. I
> >can reasonably expect both of them to last long after my death, and docs
> >and conversion programs until civilization collapses to the point
> >computers are gone.
>
> How about EBCDIC?
Dead as it should be!
<ducking> :)))
Eric Chomko
> howard.bra...@cusys.edu writes:
> > On Fri, 30 Oct 2009 09:45:04 -0600, Joe Pfeiffer
> > <pfeif...@cs.nmsu.edu> wrote:
>
> >>Unicode has a lot of inertia at this point, and 7-bit ASCII has more. I
> >>can reasonably expect both of them to last long after my death, and docs
> >>and conversion programs until civilization collapses to the point
> >>computers are gone.
>
> > How about EBCDIC?
>
> What about it? If I needed to read it, it would be one-line awk script
> away. Sort of my point.
Ain't worth the code!
Joe Pfeiffer
Patrick Scheible
> On Oct 30, 11:26=A0am, howard.bra...@cusys.edu wrote:
> > On Fri, 30 Oct 2009 09:45:04 -0600, Joe Pfeiffer
> >
> > <pfeif...@cs.nmsu.edu> wrote:
> > >Unicode has a lot of inertia at this point, and 7-bit ASCII has more. =
> =A0I
> > >can reasonably expect both of them to last long after my death, and docs
> > >and conversion programs until civilization collapses to the point
> > >computers are gone.
> >
> > How about EBCDIC?
>
> Dead as it should be!
>
> <ducking> :)))
I disagree.... it's not as dead as it should be.
-- Patrick
jmfbahciv
/BAH
jmfbahciv
People keep forgetting about data.
/BAH
Walter Bushell
Patrick Scheible <k...@zipcon.net> wrote:
Surely there room in Unicode for the varients of EBCIDIC, or is ebc dick
a social disease?
--
A computer without Microsoft is like a chocolate cake without mustard.
Patrick Scheible
All the characters from the several versions of EBCDIC are in Unicode.
It should be simple enough to map them from EBCDIC order to Unicode
order, and back, if necessary.
-- Patrick
Charlie Gibbs
writes:
> Eric Chomko wrote:
>
>> That is the thing about standards, if you can ensure backward
>> compatibility, then no one can complain when new things are added.
>
> Why do you believe that "if" in your last sentence will happen?
Oh, it happens. Just look at the x86.
The thing that's less likely to happen is forward compatibility,
unless it's carefully arranged to be a one-way trip (e.g. Word
documents).
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Patrick Scheible
If a new standard doesn't ensure backwards compatibility, it has a
hard time being adopted.
-- Patrick
Peter Flass
There is at least one Unicode -- whatchacallit, plane? -- for EBCDIC.
Anne & Lynn Wheeler
Patrick Scheible <k...@zipcon.net> writes:
> All the characters from the several versions of EBCDIC are in Unicode.
> It should be simple enough to map them from EBCDIC order to Unicode
> order, and back, if necessary.
that makes things a lot simpler than when i first added tty/ascii
support to cp67 ... i had to make some judgements on how to deal with
ascii characters that weren't in ebcdic and ebcdic that weren't in ascii
(as part of translating incoming & outgoing streams).
even more interesting was how to deal with traffic on the wire coming
into mainframe memory.
one of the first "bugs" when getting the clone controller working at the
univ ... misc. past posts
http://www.garlic.com/~lynn/subtopic.html#360pcm
was initial incoming terminal data was all garbage in mainframe memory;
had (momentarily) overlooked the fact that the official terminal
controller line scanner placed leading bit off the wire in low-order bit
position. as a result when ascii terminal bytes actually transferred to
mainframe memory ... each ascii terminal/character byte was
"bit-reversed". in order to properly emulate the official mainframe
controller ... the clone controller also had to bit-reverse each byte
off the line.
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
Gene Wirchenko
wrote:
[snip]
>Just doing this mechanically should add a whole digit to your
>uptime figure. This is what I mean by "turning on HA".
^^
What is this acronym, please?
[snip]
Sincerely,
Gene Wirchenko