On Fri, 31 Jan 2025 10:24:01 -0500, Dan Espen wrote:
IBM is still selling mainframe hardware.
I doubt they’re making any profit on it any more.
That's something you could look up for yourself.
I understand that all the profit has been in software, for many years.
I agree that mainframes is a legacy business but it's one that still has
a long life aheade it it.
On Fri, 31 Jan 2025 10:24:01 -0500, Dan Espen wrote:
IBM is still selling mainframe hardware.
I doubt they’re making any profit on it any more.
That's something you could look up for yourself.
I understand that all the profit has been in software, for many years.
IBM continues to put a lot of effort into their mainframe hardware. If
you look at their financial reports, they usually have a bullet for "IBM Z" >which is up some quarters, down others. The most recent slide deck has a >bullet that says:
z16 our most successful program in history
I agree that mainframes is a legacy business but it's one that still has
a long life aheade it it.
John Levine <johnl@taugh.com> writes:
I agree that mainframes is a legacy business but it's one that still has
a long life aheade it it.
IBM deliberately misclassified mainframe sales to enrich execs, lawsuit >claims. Lawsuit accuses Big Blue of cheating investors by shifting
systems revenue to trendy cloud, mobile tech >https://www.theregister.com/2022/04/07/ibm_securities_lawsuit/
I agree that mainframes is a legacy business but it's one that still has
a long life aheade it it.
z15, 190 processors, 190BIPS (1000MIPS/proc), Sep2019
z16, 200 processors, 222BIPS (1111MIPS/proc), Sep2022
Note max configured z196 (& 50BIPS) went for $30M, at same time E5-2600 >server blade (two 8core XEON & 500BIPS) had IBM base list price of $1815 >(before industry press announced server chip vendors were shipping half
the product directly to cloud megadatacenters for assembly at 1/3rd
price of brand name systems, and IBM sells off server blade business)
I gather that a major reason one still uses a mainframe is databases and
in particular database locking. Whi;e the aggregate throughput of a lot
of blades may be more than a single mainframe, when you need to do database updates it's a lot faster if the updates are in one place rather than
trying to synchronize a lot of loosely coupled systems. On that 200 processor z16, you can do a CAS on one processor and the other 199
will see it consistently.
I realize there are ways around this, sharding and such, but there's good reasons that the reading parts of database applications are widely distributed while the writing parts are not.
I gather that a major reason one still uses a mainframe is databases and
in particular database locking. Whi;e the aggregate throughput of a lot
of blades may be more than a single mainframe, when you need to do database updates it's a lot faster if the updates are in one place rather than
trying to synchronize a lot of loosely coupled systems. On that 200 processor z16, you can do a CAS on one processor and the other 199
will see it consistently.
I realize there are ways around this, sharding and such, but there's good reasons that the reading parts of database applications are widely distributed while the writing parts are not.
On 2025-01-31 20:31, John Levine wrote (in part):
[...]
I gather that a major reason one still uses a mainframe is databases and
in particular database locking. Whi;e the aggregate throughput of a lot
of blades may be more than a single mainframe, when you need to do database >> updates it's a lot faster if the updates are in one place rather than
trying to synchronize a lot of loosely coupled systems. On that 200
processor z16, you can do a CAS on one processor and the other 199
will see it consistently.
I realize there are ways around this, sharding and such, but there's good
reasons that the reading parts of database applications are widely
distributed while the writing parts are not.
Speaking of mainframes, Dave's Garage has an interesting video of the
IBM factory: https://www.youtube.com/watch?v=ouAG4vXFORc
Back in 1980, there were something like 10 different companies
operating in the mainframe business. Now there is only one.
John Levine <johnl@taugh.com> wrote:
According to Bob Eager <news0009@eager.cx>:
On Fri, 31 Jan 2025 10:24:01 -0500, Dan Espen wrote:
IBM is still selling mainframe hardware.
I doubt they’re making any profit on it any more.
That's something you could look up for yourself.
I understand that all the profit has been in software, for many years.
IBM continues to put a lot of effort into their mainframe hardware. If
you look at their financial reports, they usually have a bullet for "IBM Z" >> which is up some quarters, down others. The most recent slide deck has a
bullet that says:
z16 our most successful program in history
I agree that mainframes is a legacy business but it's one that still has
a long life aheade it it.
No one is going to watch to convert 60 years of production software to another platform. Actually, i take that back. It’s been tried, but never successfully.
No one is going to watch to convert 60 years of production software to another platform. Actually, i take that back. It’s been tried, but never successfully.
I gather that a major reason one still uses a mainframe is databases and
in particular database locking.
No one is going to watch to convert 60 years of production software to
another platform. Actually, i take that back. It’s been tried, but never >> successfully.
More likely the company that is chained to that mainframe albatross goes
out of business, and its systems get junked instead of converted.
On 2025-02-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
More likely the company that is chained to that mainframe albatross
goes out of business, and its systems get junked instead of converted.
I Denmark, the main users of mainframes are:
- all the banks
- state tax administration
- motor vehicle registry
In Poland during comunist times one of basic machines were domesticaly produced ICL-1900 compatible machines, using ICL operating system. It
seems that our manufacturer of those machines stopped production around
1990 (and during eighties production was decreasing). For few years alternative manufacturer offered compatible machines using bit-slice microprocessors. Few years ago supposedly last machine of this family
was decomissioned (it was used by railway as part of trafic control).
On Sun, 2 Feb 2025 03:04:25 -0000 (UTC), Lars Poulsen wrote:
On 2025-02-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
More likely the company that is chained to that mainframe albatross
goes out of business, and its systems get junked instead of converted.
I Denmark, the main users of mainframes are:
- all the banks
- state tax administration
- motor vehicle registry
I can imagine the last two could just about manage on batch operations,
but the banks cannot. Otherwise they cannot handle online transactions
which require pretty much instant updates.
Do you still have cheques in 🇩🇰? We don’t in 🇳🇿.
On Sat, 1 Feb 2025 01:31:37 -0000 (UTC), John Levine wrote:
I gather that a major reason one still uses a mainframe is
databases and in particular database locking.
Ironic, actually, but no. You think a modern company like Facebook
runs its main system on a mainframe, using some proprietary
mainframe DBMS? No, it uses MySQL/MariaDB with other pieces like
memcached, plus code written in its home-grown PHP engine
(open-sourced as HHVM), and also some back-end Python (that we
know of).
Peter Flass <peter_flass@yahoo.com> wrote:
John Levine <johnl@taugh.com> wrote:
According to Bob Eager <news0009@eager.cx>:
On Fri, 31 Jan 2025 10:24:01 -0500, Dan Espen wrote:
IBM is still selling mainframe hardware.
I doubt they’re making any profit on it any more.
That's something you could look up for yourself.
I understand that all the profit has been in software, for many years.
IBM continues to put a lot of effort into their mainframe hardware. If
you look at their financial reports, they usually have a bullet for "IBM Z"
which is up some quarters, down others. The most recent slide deck has a >> bullet that says:
z16 our most successful program in history
I agree that mainframes is a legacy business but it's one that still has >> a long life aheade it it.
No one is going to watch to convert 60 years of production software to another platform. Actually, i take that back. It’s been tried, but never successfully.
I think that there were a lot of successful migrations from
mainframes to other systems. It is likely that most succesful
cases were gradual, taking substantial time.
In Poland during comunist times one of basic machines were
domesticaly produced ICL-1900 compatible machines, using ICL
operating system. It seems that our manufacturer of those
machines stopped production around 1990 (and during eighties
production was decreasing). For few years alternative
manufacturer offered compatible machines using bit-slice
microprocessors. Few years ago supposedly last machine
of this family was decomissioned (it was used by railway
as part of trafic control).
So, it is basically question of time and financial balance:
currently mainframe users pay higer prices to mainframe
vendors so that users can keep using their systems and
avoid migration. But as user population shrinks it may
become too small to adequatly support vendors. That may
force vendors to limit their offer leading to colapse:
limited vendor offer accelerates migration. That seem
to happened with several smaller vendors. IBM-compatible
world currently looks relatively healthy, but it is not
clear for how long. I expect at least 10 more years of use
of IBM-compatible mainframes, but it is hard to make
prediction for longer time. 10 years may look like
long time, but it is short compared to 60 year history.
On Sun, 2 Feb 2025 00:58:36 -0000 (UTC)
antispam@fricas.org (Waldek Hebisch) wrote:
Peter Flass <peter_flass@yahoo.com> wrote:
John Levine <johnl@taugh.com> wrote:
According to Bob Eager <news0009@eager.cx>:
On Fri, 31 Jan 2025 10:24:01 -0500, Dan Espen wrote:
IBM is still selling mainframe hardware.
So, it is basically question of time and financial balance:No one expected 2 digit year field programs written in 1980 to
currently mainframe users pay higer prices to mainframe
vendors so that users can keep using their systems and
avoid migration. But as user population shrinks it may
become too small to adequatly support vendors. That may
force vendors to limit their offer leading to colapse:
limited vendor offer accelerates migration. That seem
to happened with several smaller vendors. IBM-compatible
world currently looks relatively healthy, but it is not
clear for how long. I expect at least 10 more years of use
of IBM-compatible mainframes, but it is hard to make
prediction for longer time. 10 years may look like
long time, but it is short compared to 60 year history.
still be in production in 20 years time.
In article <vnjfai$3mhvf$4@dont-email.me>, ldo@nz.invalid (Lawrence D'Oliveiro) wrote:
Back in 1980, there were something like 10 different companies
operating in the mainframe business. Now there is only one.
Nope. IBM is the market leader, sure. In Japan, Fujitsu and Hitachi
continue to sell IBM-like 31-bit mainframes, and NEC sells a proprietary mainframe.
The ex-Univac OS 2200, ex-Burroughs MCP, Groupe Bull GCOS,
ex-Siemens BS2000 and ex-ICL VME are all still used, mostly under
emulation.
Do you still have cheques in 🇩🇰? We don’t in 🇳🇿.
Denmark did away with checks a decade ago, and is headed towards
eliminating cash as well. Think 6-year olds with debit cards for their >allowances.
Here in the US, we still use checks. In fact, when I am moving money
between banks, I go into my branch of the big national bank, get a
cashier's check for some multiple of USD 50 000 and hand carry it to my >branch of the small regional bank to deposit it there.
If I were to do the transfer electronically, it would cost about USD 30,
and take about 36 hours before the money was available in the new
account. Doing it my way, it is free and the money is available when I
leave the branch.
The USA is stuck in the past, waxing nostalgic for the golden days of
the 1950s. And rapidly becoming a lawless 3rd world country.
Speed of synchronisation matters a lot to a credit card provider who is >trying to enforce customer credit limits and avoid double-spends. They
still use mainframes with z/TPF for that. z/TPF is a curious OS; it >essentially makes a mainframe into a single real-time transaction
processing system.
On Sun, 2 Feb 2025 00:58:36 -0000 (UTC)
antispam@fricas.org (Waldek Hebisch) wrote:
Peter Flass <peter_flass@yahoo.com> wrote:No one expected 2 digit year field programs written in 1980 to
John Levine <johnl@taugh.com> wrote:
According to Bob Eager <news0009@eager.cx>:
On Fri, 31 Jan 2025 10:24:01 -0500, Dan Espen wrote:IBM continues to put a lot of effort into their mainframe hardware. If >> >> you look at their financial reports, they usually have a bullet for "IBM Z"
IBM is still selling mainframe hardware.
I doubt they’re making any profit on it any more.
That's something you could look up for yourself.
I understand that all the profit has been in software, for many years. >> >>
which is up some quarters, down others. The most recent slide deck has a >> >> bullet that says:
z16 our most successful program in history
I agree that mainframes is a legacy business but it's one that still has >> >> a long life aheade it it.
No one is going to watch to convert 60 years of production software to
another platform. Actually, i take that back. It’s been tried, but never >> > successfully.
I think that there were a lot of successful migrations from
mainframes to other systems. It is likely that most succesful
cases were gradual, taking substantial time.
In Poland during comunist times one of basic machines were
domesticaly produced ICL-1900 compatible machines, using ICL
operating system. It seems that our manufacturer of those
machines stopped production around 1990 (and during eighties
production was decreasing). For few years alternative
manufacturer offered compatible machines using bit-slice
microprocessors. Few years ago supposedly last machine
of this family was decomissioned (it was used by railway
as part of trafic control).
So, it is basically question of time and financial balance:
currently mainframe users pay higer prices to mainframe
vendors so that users can keep using their systems and
avoid migration. But as user population shrinks it may
become too small to adequatly support vendors. That may
force vendors to limit their offer leading to colapse:
limited vendor offer accelerates migration. That seem
to happened with several smaller vendors. IBM-compatible
world currently looks relatively healthy, but it is not
clear for how long. I expect at least 10 more years of use
of IBM-compatible mainframes, but it is hard to make
prediction for longer time. 10 years may look like
long time, but it is short compared to 60 year history.
still be in production in 20 years time.
"Kerr-Mudd, John" <admin@127.0.0.1> writes:
On Sun, 2 Feb 2025 00:58:36 -0000 (UTC)
antispam@fricas.org (Waldek Hebisch) wrote:
Peter Flass <peter_flass@yahoo.com> wrote:
John Levine <johnl@taugh.com> wrote:
According to Bob Eager <news0009@eager.cx>:
On Fri, 31 Jan 2025 10:24:01 -0500, Dan Espen wrote:
IBM is still selling mainframe hardware.
So, it is basically question of time and financial balance:No one expected 2 digit year field programs written in 1980 to
currently mainframe users pay higer prices to mainframe
vendors so that users can keep using their systems and
avoid migration. But as user population shrinks it may
become too small to adequatly support vendors. That may
force vendors to limit their offer leading to colapse:
limited vendor offer accelerates migration. That seem
to happened with several smaller vendors. IBM-compatible
world currently looks relatively healthy, but it is not
clear for how long. I expect at least 10 more years of use
of IBM-compatible mainframes, but it is hard to make
prediction for longer time. 10 years may look like
long time, but it is short compared to 60 year history.
still be in production in 20 years time.
At Burroughs, we fully expected 2-digit year field programs
written in 1968 to be still in production by 2000 when we
started the Y2K mitigation work in the mid 1980s.
1960 was used as the dividing line - any two digit year smaller
was assumed to be 21st century; any larger was assumed to be
20th century.
Some of this left over from mid-90s where billions were spent on
rewritting mainframe financial systems that queued real time
transactions for processing during overnight batch settlement windows
(many from the 60s&70s) ... to straight-through processing using large
number of parallelized killer micros. Some of us pointed out that they
were using industry standard parallelization libraries that had hundred
times the overhead of mainframe cobol batch ... ignored until their
pilots went down in flames (retrenching to the existing status quo).
A major change was combination of 1) major RDBMS vendors (including IBM)
did significiant throughput performance work on cluster RDBMS, 2) implementations done with fine-grain SQL statements that were highly parallelized (rather than RYO implementation parallelization), and 3) non-mainframe systems having significantly higher throughput.
40 max configured mainframe systems (none older than 18months) allrunning the same 450K statement Cobol app (number needed to finish
No one expected 2 digit year field programs written in 1980 to still be
in production in 20 years time.
One time I made an RTP payment to my account at my medium sized local< bank, which showed up as promised in a few seconds.
On Sun, 2 Feb 2025 18:04:23 +0000, Kerr-Mudd, John wrote:
No one expected 2 digit year field programs written in 1980 to still be
in production in 20 years time.
Already in the 1970s there were standards for representing dates and times that specified a four-digit year. It’s not as though you could say nobody saw this coming.
Dan Espen <dan1espen@gmail.com> wrote:<Y2K mitigations>
scott@slp53.sl.home (Scott Lurndal) writes:
I fixed one of my applications by looking at the current year, then
setting the window accordingly. Fixed forever.
Depends on the application. For something like Social Security you may have >records on someone born this year(parents applied for SSN) to this year
minus 100 or more. For a payments system this works fine, since all you >usually need is last year, this year, and next year.
On Sun, 2 Feb 2025 20:51:48 -0000 (UTC), John Levine wrote:
One time I made an RTP payment to my account at my medium sized local< bank, which showed up as promised in a few seconds.
Somehow I don’think
On 2025-02-02, Dan Espen <dan1espen@gmail.com> wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
"Kerr-Mudd, John" <admin@127.0.0.1> writes:
No one expected 2 digit year field programs written in 1980 to
still be in production in 20 years time.
At Burroughs, we fully expected 2-digit year field programs
written in 1968 to be still in production by 2000 when we
started the Y2K mitigation work in the mid 1980s.
1960 was used as the dividing line - any two digit year smaller
was assumed to be 21st century; any larger was assumed to be
20th century.
I fixed one of my applications by looking at the current year,
then setting the window accordingly. Fixed forever.
FSVO "forever". My first programming job was at a small
card-only shop in 1970. We did a lot of squeezing to fit
data onto an 80-column card. One way was to only store
the last digit of the year in date fields. My first
assignment was to go through all our programs and change
the digit they inserted from a 6 to a 7.
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
On 2025-02-02, Dan Espen <dan1espen@gmail.com> wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
"Kerr-Mudd, John" <admin@127.0.0.1> writes:
No one expected 2 digit year field programs written in 1980 to
still be in production in 20 years time.
At Burroughs, we fully expected 2-digit year field programs
written in 1968 to be still in production by 2000 when we
started the Y2K mitigation work in the mid 1980s.
1960 was used as the dividing line - any two digit year smaller
was assumed to be 21st century; any larger was assumed to be
20th century.
I fixed one of my applications by looking at the current year,
then setting the window accordingly. Fixed forever.
FSVO "forever". My first programming job was at a small
card-only shop in 1970. We did a lot of squeezing to fit
data onto an 80-column card. One way was to only store
the last digit of the year in date fields. My first
assignment was to go through all our programs and change
the digit they inserted from a 6 to a 7.
Uggh!
Meanwhile, fixes using 4 digit years are setting us up for
the Y9K bug.
No one expected 2 digit year field programs written in 1980 to
still be in production in 20 years time.
At Burroughs, we fully expected 2-digit year field programs
written in 1968 to be still in production by 2000 when we
started the Y2K mitigation work in the mid 1980s.
1960 was used as the dividing line - any two digit year smaller
was assumed to be 21st century; any larger was assumed to be
20th century.
I fixed one of my applications by looking at the current year,
then setting the window accordingly. Fixed forever.
FSVO "forever". My first programming job was at a small
card-only shop in 1970. We did a lot of squeezing to fit
data onto an 80-column card. One way was to only store
the last digit of the year in date fields. My first
assignment was to go through all our programs and change
the digit they inserted from a 6 to a 7.
Uggh!
Meanwhile, fixes using 4 digit years are setting us up for
the Y9K bug.
Peter Flass <peter_flass@yahoo.com> writes:
Dan Espen <dan1espen@gmail.com> wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
<Y2K mitigations>
I fixed one of my applications by looking at the current year, then
setting the window accordingly. Fixed forever.
Depends on the application. For something like Social Security you may have >> records on someone born this year(parents applied for SSN) to this year
minus 100 or more. For a payments system this works fine, since all you
usually need is last year, this year, and next year.
For SS, even in the 1960's, they'd have to be able to store dates
from the 19th century; two-digit years were never useful in that context.
Dan Espen <dan1espen@gmail.com> writes:
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
On 2025-02-02, Dan Espen <dan1espen@gmail.com> wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
"Kerr-Mudd, John" <admin@127.0.0.1> writes:
No one expected 2 digit year field programs written in 1980 to
still be in production in 20 years time.
At Burroughs, we fully expected 2-digit year field programs
written in 1968 to be still in production by 2000 when we
started the Y2K mitigation work in the mid 1980s.
1960 was used as the dividing line - any two digit year smaller
was assumed to be 21st century; any larger was assumed to be
20th century.
I fixed one of my applications by looking at the current year,
then setting the window accordingly. Fixed forever.
FSVO "forever". My first programming job was at a small
card-only shop in 1970. We did a lot of squeezing to fit
data onto an 80-column card. One way was to only store
the last digit of the year in date fields. My first
assignment was to go through all our programs and change
the digit they inserted from a 6 to a 7.
Uggh!
Meanwhile, fixes using 4 digit years are setting us up for
the Y9K bug.
A signed 64-bit integer can represent any time value (in seconds)
for a few hundred million years BCE and CE.
scott@slp53.sl.home (Scott Lurndal) writes:
Dan Espen <dan1espen@gmail.com> writes:
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
On 2025-02-02, Dan Espen <dan1espen@gmail.com> wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
"Kerr-Mudd, John" <admin@127.0.0.1> writes:
No one expected 2 digit year field programs written in 1980 to
still be in production in 20 years time.
At Burroughs, we fully expected 2-digit year field programs
written in 1968 to be still in production by 2000 when we
started the Y2K mitigation work in the mid 1980s.
1960 was used as the dividing line - any two digit year smaller
was assumed to be 21st century; any larger was assumed to be
20th century.
I fixed one of my applications by looking at the current year,
then setting the window accordingly. Fixed forever.
FSVO "forever". My first programming job was at a small
card-only shop in 1970. We did a lot of squeezing to fit
data onto an 80-column card. One way was to only store
the last digit of the year in date fields. My first
assignment was to go through all our programs and change
the digit they inserted from a 6 to a 7.
Uggh!
Meanwhile, fixes using 4 digit years are setting us up for
the Y9K bug.
A signed 64-bit integer can represent any time value (in seconds)
for a few hundred million years BCE and CE.
Hopefully, those 64bit dates will remain an internal representation.
Anything converting a 4 digit year to a 64bit date still has
a Y9K problem.
Dan Espen <dan1espen@gmail.com> writes:
scott@slp53.sl.home (Scott Lurndal) writes:
Dan Espen <dan1espen@gmail.com> writes:
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
On 2025-02-02, Dan Espen <dan1espen@gmail.com> wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
"Kerr-Mudd, John" <admin@127.0.0.1> writes:
No one expected 2 digit year field programs written in 1980 to >>>>>>>> still be in production in 20 years time.
At Burroughs, we fully expected 2-digit year field programs
written in 1968 to be still in production by 2000 when we
started the Y2K mitigation work in the mid 1980s.
1960 was used as the dividing line - any two digit year smaller
was assumed to be 21st century; any larger was assumed to be
20th century.
I fixed one of my applications by looking at the current year,
then setting the window accordingly. Fixed forever.
FSVO "forever". My first programming job was at a small
card-only shop in 1970. We did a lot of squeezing to fit
data onto an 80-column card. One way was to only store
the last digit of the year in date fields. My first
assignment was to go through all our programs and change
the digit they inserted from a 6 to a 7.
Uggh!
Meanwhile, fixes using 4 digit years are setting us up for
the Y9K bug.
A signed 64-bit integer can represent any time value (in seconds)
for a few hundred million years BCE and CE.
Hopefully, those 64bit dates will remain an internal representation. >>Anything converting a 4 digit year to a 64bit date still has
a Y9K problem.
Does it? Let's take the year 10355, for example.
scott@slp53.sl.home (Scott Lurndal) writes:
Dan Espen <dan1espen@gmail.com> writes:
scott@slp53.sl.home (Scott Lurndal) writes:
Dan Espen <dan1espen@gmail.com> writes:
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
On 2025-02-02, Dan Espen <dan1espen@gmail.com> wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
"Kerr-Mudd, John" <admin@127.0.0.1> writes:
No one expected 2 digit year field programs written in 1980 to >>>>>>>>> still be in production in 20 years time.
At Burroughs, we fully expected 2-digit year field programs
written in 1968 to be still in production by 2000 when we
started the Y2K mitigation work in the mid 1980s.
1960 was used as the dividing line - any two digit year smaller >>>>>>>> was assumed to be 21st century; any larger was assumed to be
20th century.
I fixed one of my applications by looking at the current year,
then setting the window accordingly. Fixed forever.
FSVO "forever". My first programming job was at a small
card-only shop in 1970. We did a lot of squeezing to fit
data onto an 80-column card. One way was to only store
the last digit of the year in date fields. My first
assignment was to go through all our programs and change
the digit they inserted from a 6 to a 7.
Uggh!
Meanwhile, fixes using 4 digit years are setting us up for
the Y9K bug.
A signed 64-bit integer can represent any time value (in seconds)
for a few hundred million years BCE and CE.
Hopefully, those 64bit dates will remain an internal representation. >>>Anything converting a 4 digit year to a 64bit date still has
a Y9K problem.
Does it? Let's take the year 10355, for example.
I think you missed my point...It's going to be difficult to store
10355 in a 4 digit field.
scott@slp53.sl.home (Scott Lurndal) writes:
Dan Espen <dan1espen@gmail.com> writes:
Meanwhile, fixes using 4 digit years are setting us up for
the Y9K bug.
A signed 64-bit integer can represent any time value (in seconds)
for a few hundred million years BCE and CE.
Hopefully, those 64bit dates will remain an internal representation.
Anything converting a 4 digit year to a 64bit date still has
a Y9K problem.
Meanwhile, fixes using 4 digit years are setting us up for the Y9K bug.
Hopefully, those 64bit dates will remain an internal representation.
Anything converting a 4 digit year to a 64bit date still has a Y9K
problem.
On Mon, 03 Feb 2025 17:21:50 -0500, Dan Espen wrote:
Hopefully, those 64bit dates will remain an internal representation.
Anything converting a 4 digit year to a 64bit date still has a Y9K
problem.
The ultimate integer representation of time would be in units of the
Planck interval (5.39e-44 seconds, according to Da Wiki). Representing the current age of the observable Universe would take about 200 bits,
according to this scale.
So I figure a 256-bit integer in this scale (representing a maximum
duration of about 10**16 years) ought to be enough to represent any
duration of time we are ever likely to be physically concerned with. ;)
On Mon, 03 Feb 2025 11:39:25 -0500, Dan Espen wrote:
Meanwhile, fixes using 4 digit years are setting us up for the Y9K bug.
I’m expecting that the Gregorian calendar, with its zero point set to some arbitrary guess at the birth date of some figure that was mythological anyway, will not be in use for that long.
scott@slp53.sl.home (Scott Lurndal) writes:
Peter Flass <peter_flass@yahoo.com> writes:
Dan Espen <dan1espen@gmail.com> wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
<Y2K mitigations>
I fixed one of my applications by looking at the current year, then
setting the window accordingly. Fixed forever.
Depends on the application. For something like Social Security you may have >>> records on someone born this year(parents applied for SSN) to this year
minus 100 or more. For a payments system this works fine, since all you
usually need is last year, this year, and next year.
For SS, even in the 1960's, they'd have to be able to store dates
from the 19th century; two-digit years were never useful in that context.
Indeed. My greatgrandfather Alderson was born in 1876, and died in 1962; my greatgrandmother was born in 1885, and died 6 weeks short of her 90th birthday
in 1975.
On 04/02/2025 01:05, Lawrence D'Oliveiro wrote:
On Mon, 03 Feb 2025 15:03:10 GMT, Colin Macleod wrote:
I couldn't even interrupt my own program. They had to reboot the machine >>> to fix it and I was told in no uncertain terms to never do that again!
Fragile things, mainframes. They were not battle-hardened by exposure to
inquisitive students, the way interactive timesharing systems were.
Nonsense.
On 2025-02-03, Dan Espen <dan1espen@gmail.com> wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
Dan Espen <dan1espen@gmail.com> writes:
Meanwhile, fixes using 4 digit years are setting us up for
the Y9K bug.
A signed 64-bit integer can represent any time value (in seconds)
for a few hundred million years BCE and CE.
Hopefully, those 64bit dates will remain an internal representation.
Anything converting a 4 digit year to a 64bit date still has
a Y9K problem.
s/Y9K/Y10K/
At the year 9000 we'll still have a millennium left to fix it.
On 4 Feb 2025 at 01:15:08, moi<findlaybill@blueyonder.co.uk> wrote:
On 04/02/2025 01:05, Lawrence D'Oliveiro wrote:
On Mon, 03 Feb 2025 15:03:10 GMT, Colin Macleod wrote:
I couldn't even interrupt my own program. They had to reboot the machine
to fix it and I was told in no uncertain terms to never do that again!
Fragile things, mainframes. They were not battle-hardened by exposure to inquisitive students, the way interactive timesharing systems were.
Nonsense.
Everything Lawrence says is nonsense.
If only people would stop responding to him.
In article <vnmh9e$butt$6@dont-email.me>, ldo@nz.invalid (Lawrence D'Oliveiro) wrote:
You think a modern company like Facebook runs
its main system on a mainframe, using some proprietary mainframe DBMS?
No, it uses MySQL/MariaDB with other pieces like memcached, plus code
written in its home-grown PHP engine (open-sourced as HHVM), and also
some back-end Python (that we know of).
Facebook has quite different synchronisation requirements from a credit
card provider. It doesn't matter to FB if updates to the page someone is looking at arrive take a few seconds to arrive.
Speed of synchronisation matters a lot to a credit card provider who is trying to enforce customer credit limits and avoid double-spends. They
still use mainframes with z/TPF for that. z/TPF is a curious OS; it essentially makes a mainframe into a single real-time transaction
processing system.
On 4 Feb 2025 07:13:37 GMT
Bob Martin <bob.martin@excite.com> wrote:
On 3 Feb 2025 at 21:40:05, Rich Alderson <news@alderson.users.panix.com> wrote:Can we presume that your other grandfather is no longer around?
scott@slp53.sl.home (Scott Lurndal) writes:
Peter Flass <peter_flass@yahoo.com> writes:Indeed. My greatgrandfather Alderson was born in 1876, and died in 1962; my
Dan Espen <dan1espen@gmail.com> wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
<Y2K mitigations>
I fixed one of my applications by looking at the current year, then
setting the window accordingly. Fixed forever.
Depends on the application. For something like Social Security you may have
records on someone born this year(parents applied for SSN) to this year >> >>> minus 100 or more. For a payments system this works fine, since all you >> >>> usually need is last year, this year, and next year.
For SS, even in the 1960's, they'd have to be able to store dates
from the 19th century; two-digit years were never useful in that context. >> >
greatgrandmother was born in 1885, and died 6 weeks short of her 90th birthday
in 1975.
My grandfather was born in 1863.
On 4 Feb 2025, Bob Martin wrote
(in article <m0dt5gFpgnqU1@mid.individual.net>):
On 4 Feb 2025 at 01:15:08, moi<findlaybill@blueyonder.co.uk> wrote:
On 04/02/2025 01:05, Lawrence D'Oliveiro wrote:
On Mon, 03 Feb 2025 15:03:10 GMT, Colin Macleod wrote:
I couldn't even interrupt my own program. They had to reboot the machineFragile things, mainframes. They were not battle-hardened by exposure to >> > > inquisitive students, the way interactive timesharing systems were.
to fix it and I was told in no uncertain terms to never do that again! >> > >
Nonsense.
Everything Lawrence says is nonsense.
If only people would stop responding to him.
Untruths need to be challenged.
On 4 Feb 2025 at 13:47:59, "Kerr-Mudd, John" <admin@127.0.0.1> wrote:
On 4 Feb 2025 07:13:37 GMT
Bob Martin <bob.martin@excite.com> wrote:
On 3 Feb 2025 at 21:40:05, Rich Alderson <news@alderson.users.panix.com> wrote:Can we presume that your other grandfather is no longer around?
scott@slp53.sl.home (Scott Lurndal) writes:
Peter Flass <peter_flass@yahoo.com> writes:
Dan Espen <dan1espen@gmail.com> wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
<Y2K mitigations>
I fixed one of my applications by looking at the current year, then >> >>>> setting the window accordingly. Fixed forever.
Depends on the application. For something like Social Security you may have
records on someone born this year(parents applied for SSN) to this year
minus 100 or more. For a payments system this works fine, since all you
usually need is last year, this year, and next year.
For SS, even in the 1960's, they'd have to be able to store dates
from the 19th century; two-digit years were never useful in that context.
Indeed. My greatgrandfather Alderson was born in 1876, and died in 1962; my
greatgrandmother was born in 1885, and died 6 weeks short of her 90th birthday
in 1975.
My grandfather was born in 1863.
Sorry, full info:
Paternal grandfather : 1863 to 1952
Maternal grandfather : 1877 to 1940
I'm 83
In article <0001HW.2D528791002FB78C30DA3538F@news.individual.net>,
Bill Findlay <findlaybill@blueyonder.co.uk> wrote:
On 4 Feb 2025, Bob Martin wrote
(in article <m0dt5gFpgnqU1@mid.individual.net>):
On 4 Feb 2025 at 01:15:08, moi<findlaybill@blueyonder.co.uk> wrote:
On 04/02/2025 01:05, Lawrence D'Oliveiro wrote:
On Mon, 03 Feb 2025 15:03:10 GMT, Colin Macleod wrote:
I couldn't even interrupt my own program. They had to reboot the machine
to fix it and I was told in no uncertain terms to never do that again!
Fragile things, mainframes. They were not battle-hardened by exposure to
inquisitive students, the way interactive timesharing systems were.
Nonsense.
Everything Lawrence says is nonsense.
If only people would stop responding to him.
Untruths need to be challenged.
My suggestion for handling this would be to have a periodically
posted FAQ that includes a section on cranks and bad-faith
posters that mentions Lawrence.
On Wed, 5 Feb 2025 16:58:46 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
In article <0001HW.2D528791002FB78C30DA3538F@news.individual.net>,
Bill Findlay <findlaybill@blueyonder.co.uk> wrote:
On 4 Feb 2025, Bob Martin wrote
(in article <m0dt5gFpgnqU1@mid.individual.net>):
On 4 Feb 2025 at 01:15:08, moi<findlaybill@blueyonder.co.uk> wrote:
On 04/02/2025 01:05, Lawrence D'Oliveiro wrote:
On Mon, 03 Feb 2025 15:03:10 GMT, Colin Macleod wrote:Nonsense.
I couldn't even interrupt my own program. They had to reboot the machine
to fix it and I was told in no uncertain terms to never do that again!
Fragile things, mainframes. They were not battle-hardened by exposure to
inquisitive students, the way interactive timesharing systems were. >> >> >
Everything Lawrence says is nonsense.
If only people would stop responding to him.
Untruths need to be challenged.
My suggestion for handling this would be to have a periodically
posted FAQ that includes a section on cranks and bad-faith
posters that mentions Lawrence.
Challenging idi^w uninformed presid^w posters rarely gets you anywhere
good.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 6 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 132:02:14 |
| Calls: | 154 |
| Files: | 21,500 |
| Messages: | 79,202 |