Hamish Laws <hamish.laws@gmail.com> writes:
>On Friday, November 18, 2022 at 10:56:50 PM UTC+11, Thomas Koenig wrote:
>> Dorothy J Heydt <djh...@kithrup.com> schrieb:
>> > (Hal Heydt)
>> > And just because the hardware uses 32-bit words doesn't prevent it
>> > from having 64-bit numeric variables.
>> >
>> > All the programmers I knew in the 1970s were well aware of the
>> > Y2K issue then. One shop I was in in the mid-70s had a program
>> > to print 30 year amortization tables. Even then it was written
>> > to handle post-2000 end dates.
>> >
>> > For a long time, businesses usually replaced application systems
>> > about every 5 to 7 years. As a result, most IT people assumed
>> > that sometime from the late 1980s to early 1990s, the
>> > replacement cycle would shift everything to date routines that
>> > handled the century rollover. Then companies quit *replacing*
>> > systems and it became apparent (years before panic set in among
>> > the MBAs) that Something Needed to be Done. The bean counters
>> > weren't willing to spend the money to fix things until the panic
>> > struck in the late 1990s. At that point, it cost a lot more, of
>> > course.
>> I always thought that the Y2K problem was one reason to move away
>> from legacy mainframe systems. If you have to redo the system
>> anyway, you might as well move to a different system.
>
>It was rarely a complete rewrite.

Indeed. In many cases it was just a minor change to an application.

The problem being that there were a lot of compiled applications for
which the corresponding source card deck had disappeared :-(.

On 18/11/2022 22:56, Thomas Koenig wrote:
> Dorothy J Heydt <djheydt@kithrup.com> schrieb:
>
>> (Hal Heydt)
>> And just because the hardware uses 32-bit words doesn't prevent it
>> from having 64-bit numeric variables.
>>
>> All the programmers I knew in the 1970s were well aware of the
>> Y2K issue then. One shop I was in in the mid-70s had a program
>> to print 30 year amortization tables. Even then it was written
>> to handle post-2000 end dates.
>>
>> For a long time, businesses usually replaced application systems
>> about every 5 to 7 years. As a result, most IT people assumed
>> that sometime from the late 1980s to early 1990s, the
>> replacement cycle would shift everything to date routines that
>> handled the century rollover. Then companies quit *replacing*
>> systems and it became apparent (years before panic set in among
>> the MBAs) that Something Needed to be Done. The bean counters
>> weren't willing to spend the money to fix things until the panic
>> struck in the late 1990s. At that point, it cost a lot more, of
>> course.
>
> I always thought that the Y2K problem was one reason to move away
> from legacy mainframe systems. If you have to redo the system
> anyway, you might as well move to a different system.

Replacing a mainframe with anything else is not trivial.

Which is why most large mainframe sites still use mainframes.

Nothing moves data about whilst transforming it as fast as a
mainframe[1], which is where most, "We can move you to <insert
Relational Database and x64 box> in six months", attempts hit the wall.

Banks really don't like the idea of waiting 36 hours for the end-of-day
processing to complete.

Lots of people what think they're really shmott guys come a cropper on this.

Cheers,
Gary B-)

1 - No, massively parallel Linux boxes don't do the same job[2]. I was
in storage at SGI, they're really good at applying the *same* transform
to a lot of data, not things like, "Here's a set of payroll rules, apply
them to the records on this DASD, and write the resulting records on
that DASD over there".

2 - Those big Linux systems are really, really good at recording and
processing telephone calls looking for "interesting" content. For some
reason the NSA buys them and installs them near large routing hubs in
the USA, I can't think why...

"Gary R. Schmidt" <grschmidt@acm.org> writes:
>On 18/11/2022 22:56, Thomas Koenig wrote:
>> Dorothy J Heydt <djheydt@kithrup.com> schrieb:
>>
>>> (Hal Heydt)
>>> And just because the hardware uses 32-bit words doesn't prevent it
>>> from having 64-bit numeric variables.
>>>
>>> All the programmers I knew in the 1970s were well aware of the
>>> Y2K issue then. One shop I was in in the mid-70s had a program
>>> to print 30 year amortization tables. Even then it was written
>>> to handle post-2000 end dates.
>>>
>>> For a long time, businesses usually replaced application systems
>>> about every 5 to 7 years. As a result, most IT people assumed
>>> that sometime from the late 1980s to early 1990s, the
>>> replacement cycle would shift everything to date routines that
>>> handled the century rollover. Then companies quit *replacing*
>>> systems and it became apparent (years before panic set in among
>>> the MBAs) that Something Needed to be Done. The bean counters
>>> weren't willing to spend the money to fix things until the panic
>>> struck in the late 1990s. At that point, it cost a lot more, of
>>> course.
>>
>> I always thought that the Y2K problem was one reason to move away
>> from legacy mainframe systems. If you have to redo the system
>> anyway, you might as well move to a different system.
>
>Replacing a mainframe with anything else is not trivial.
>
>Which is why most large mainframe sites still use mainframes.
>
>Nothing moves data about whilst transforming it as fast as a
>mainframe[1], which is where most, "We can move you to <insert
>Relational Database and x64 box> in six months", attempts hit the wall.

Back in 2010, the last of the Burroughs medium systems was retired
by the City of Santa Ana. They replaced it (and it was 25 years
old at the time) with 25 windows boxen.

>1 - No, massively parallel Linux boxes don't do the same job[2]. I was
>in storage at SGI, they're really good at applying the *same* transform
>to a lot of data, not things like, "Here's a set of payroll rules, apply
>them to the records on this DASD, and write the resulting records on
>that DASD over there".

The Unisys OPUS MPP (SVr4+Chorus uKernel) boxes were mainly decision
support, running OPS (aka RAC) and/or RedBrick data warehousing
software.

On Thu, 17 Nov 2022 21:22:42 GMT, djheydt@kithrup.com (Dorothy J
Heydt) wrote:

>In article <XnsAF4D56F32F62Dtaustincagmailcom@85.12.62.232>,
>Ninapenda Jibini <taustinca@gmail.com> wrote:
>>scott@slp53.sl.home (Scott Lurndal) wrote in
>>news:l9PbL.74464$1449.32517@fx14.iad:
>>
>>> For the most part, a nothingburger. However, there are likely
>>> lots of small embedded 32-bit processors in devices like routers
>>> which may exhibit issues, if they're still running 16 years from
>>> now.
>>>
>>You sound just like the doom criers ("Give me money or you'll
>>DIE!!!") in the run up to y2k.
>>
>>How many appliances with embedded processors running today do you
>>actually believe will still be functional in another 16 years?
>>
>>https://www.wired.com/2000/01/y2k-alarmist-wha-happened/
>
>(Hal Heydt)
>Actually, more to the point... How many appliances with embedded
>processors "care" what the date is? (As for longevity, if I go
>out to buy a new refrigerator now, I sure as heck expect it to
>still be functioning in 2038. Same for other major appliances.)

Just make sure it is /not/ part of the "smart house/internet of
things" nonsense.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

On Thu, 17 Nov 2022 16:32:09 GMT, djheydt@kithrup.com (Dorothy J
Heydt) wrote:

>In article <l9PbL.74464$1449.32517@fx14.iad>,
>Slcott Lurndal <slp53@pacbell.net> wrote:
>>Jibini Kula Tumbili Kujisalimisha <taustinca@gmail.com> writes:
>>>Lynn McGuire <lynnmcguire5@gmail.com> wrote in
>>>news:tkmbd3$uc0u$2@dont-email.me:
>>>
>>>> xkcd: Y2K and 2038
>>>> https://xkcd.com/2697/
>>>>
>>>> It shouldn't cost more than a trillion dollars or two to
>>>> investigate this.
>>>
>>>I'll start doing so as soon as the check clears.
>>>
>>>Or it could end up being as big a nothingburger as y2k was, because
>>>the people who run such systems aren't idiots.
>>
>>We (Burroughs) started preparing for 2000 in 1987. None of our customers
>>were affected by the rollover (and most customer software on those mainframes
>>used two-digit year fields in 1987).
>>
>>And, on the vast majority of unix/linux servers/desktops currently running,
>>
>>sizeof(time_t)=8 (64 bits)
>>
>>Which pushes the "2038" date out to December 4th, in the year 292,277,026,596.
>>
>>For the most part, a nothingburger. However, there are likely lots of
>>small embedded 32-bit processors in devices like routers which may exhibit
>>issues, if they're still running 16 years from now.
>
>(Hal Heydt)
>And just because the hardware uses 32-bit words doesn't prevent it
>from having 64-bit numeric variables.

No, it doesn't. Or 128-bitters either.

But there may be a cost (in cycles used) for using them. And, perhaps,
also for having to remember to use special functions instead of
operators.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

On Thu, 17 Nov 2022 21:22:42 +0000, Dorothy J Heydt wrote:

> In article <XnsAF4D56F32F62Dtaustincagmailcom@85.12.62.232>, Ninapenda
> Jibini <taustinca@gmail.com> wrote:
>>scott@slp53.sl.home (Scott Lurndal) wrote in
>>news:l9PbL.74464$1449.32517@fx14.iad:
>>
>>> For the most part, a nothingburger. However, there are likely lots
>>> of small embedded 32-bit processors in devices like routers which may
>>> exhibit issues, if they're still running 16 years from now.
>>>
>>You sound just like the doom criers ("Give me money or you'll DIE!!!")
>>in the run up to y2k.
>>
>>How many appliances with embedded processors running today do you
>>actually believe will still be functional in another 16 years?
>>
>>https://www.wired.com/2000/01/y2k-alarmist-wha-happened/
>
> (Hal Heydt)
> Actually, more to the point... How many appliances with embedded
> processors "care" what the date is? (As for longevity, if I go out to
> buy a new refrigerator now, I sure as heck expect it to still be
> functioning in 2038. Same for other major appliances.)

You might be disappointed. My mother's church has gone through three new
refrigerators in two years. Meanwhile a refrigerator my father bought in
the fifties to keep drinks cold for the tobacco croppers is still
running(unless it has stopped in the last few days) under a shelter
outback.

In article <0a82548e-4145-4d3a-8895-8103b9a7ebc0n@googlegroups.com>,
Robert Carnegie <rja.carnegie@excite.com> wrote:
>Incidentally, there may be trouble again around
>the year 9999.

(Hal Heydt)
Barring some really spectacular breakthroughs in gerontology, I
don't expect to have to worry about the Y10K problem. Though if
I'm alive then, I suppose I could dust off my COBOL skills and
see what the market will bear...

On 19/11/22 08:10, Magewolf wrote:
> On Thu, 17 Nov 2022 21:22:42 +0000, Dorothy J Heydt wrote:
>
>> In article <XnsAF4D56F32F62Dtaustincagmailcom@85.12.62.232>, Ninapenda
>> Jibini <taustinca@gmail.com> wrote:
>>> scott@slp53.sl.home (Scott Lurndal) wrote in
>>> news:l9PbL.74464$1449.32517@fx14.iad:
>>>
>>>> For the most part, a nothingburger. However, there are likely lots
>>>> of small embedded 32-bit processors in devices like routers which may
>>>> exhibit issues, if they're still running 16 years from now.
>>>>
>>> You sound just like the doom criers ("Give me money or you'll DIE!!!")
>>> in the run up to y2k.
>>>
>>> How many appliances with embedded processors running today do you
>>> actually believe will still be functional in another 16 years?
>>>
>>> https://www.wired.com/2000/01/y2k-alarmist-wha-happened/
>>
>> (Hal Heydt)
>> Actually, more to the point... How many appliances with embedded
>> processors "care" what the date is? (As for longevity, if I go out to
>> buy a new refrigerator now, I sure as heck expect it to still be
>> functioning in 2038. Same for other major appliances.)
>
> You might be disappointed. My mother's church has gone through three new
> refrigerators in two years.

The practice of chilling souls is a relatively recent phenomenon whose
premise is based on the false assumption that a condemned soul does not
begin to burn until it reaches the depths of hell. Perhaps unreasonable
to criticise the refrigerator, perhaps not but my personal opinion is
that smoke alarms in refrigerators should not be compulsory.

Meanwhile a refrigerator my father bought in
> the fifties to keep drinks cold for the tobacco croppers is still
> running(unless it has stopped in the last few days) under a shelter
> outback.

Drinks! Tobacco! A refrigerator obviously powered by the devil.

On 11/18/2022 6:11 PM, Dorothy J Heydt wrote:
> In article <0a82548e-4145-4d3a-8895-8103b9a7ebc0n@googlegroups.com>,
> Robert Carnegie <rja.carnegie@excite.com> wrote:
>> Incidentally, there may be trouble again around
>> the year 9999.
>
> (Hal Heydt)
> Barring some really spectacular breakthroughs in gerontology, I
> don't expect to have to worry about the Y10K problem. Though if
> I'm alive then, I suppose I could dust off my COBOL skills and
> see what the market will bear...

Cryogenics. Then you can BE the COBOL programmer in the old joke about
the programmer who after Y2K put himself into some kind of suspended
animation, then got woken up on the year 9,999 so the ruler of Earth
could ask him, "We understand you know COBOL...?"

--
I've done good in this world. Now I'm tired and just want to be a cranky
dirty old man.

Gary R. Schmidt <grschmidt@acm.org> schrieb:
> On 18/11/2022 22:56, Thomas Koenig wrote:
>> Dorothy J Heydt <djheydt@kithrup.com> schrieb:
>>
>>> (Hal Heydt)
>>> And just because the hardware uses 32-bit words doesn't prevent it
>>> from having 64-bit numeric variables.
>>>
>>> All the programmers I knew in the 1970s were well aware of the
>>> Y2K issue then. One shop I was in in the mid-70s had a program
>>> to print 30 year amortization tables. Even then it was written
>>> to handle post-2000 end dates.
>>>
>>> For a long time, businesses usually replaced application systems
>>> about every 5 to 7 years. As a result, most IT people assumed
>>> that sometime from the late 1980s to early 1990s, the
>>> replacement cycle would shift everything to date routines that
>>> handled the century rollover. Then companies quit *replacing*
>>> systems and it became apparent (years before panic set in among
>>> the MBAs) that Something Needed to be Done. The bean counters
>>> weren't willing to spend the money to fix things until the panic
>>> struck in the late 1990s. At that point, it cost a lot more, of
>>> course.
>>
>> I always thought that the Y2K problem was one reason to move away
>> from legacy mainframe systems. If you have to redo the system
>> anyway, you might as well move to a different system.
>
> Replacing a mainframe with anything else is not trivial.
>
> Which is why most large mainframe sites still use mainframes.

Around the 2000 timeframe, a lot of mainframe sites became
no-longer-mainframe sites.

SAP R/3 had a lot to do with it, I believe. The company I worked
for still had 3270 terminal emulators running on PCs in the late
1990s. Before 2000, they were all gone when they replaced their
home-grown accounting system with SAP R/3, which ran client-server.

If that transformation saved any money, I'm not sure, the project
was horrible. No, it wasn't horrible, it was _really_ horrible.
Fortunately, I wasn't involved, I just heard a few tidbits from
people who were in that project.

> Nothing moves data about whilst transforming it as fast as a
> mainframe[1], which is where most, "We can move you to <insert
> Relational Database and x64 box> in six months", attempts hit the wall.

Those who can convert easily have already converted, I believe.

> Banks really don't like the idea of waiting 36 hours for the end-of-day
> processing to complete.
>
> Lots of people what think they're really shmott guys come a cropper on this.
>
> Cheers,
> Gary B-)
>
> 1 - No, massively parallel Linux boxes don't do the same job[2].

You've looked at what IBM mainframe run these days, right? zOS isn't
the only game in town :-)

And SAP HANA will run exclusively on Linux by 2027, zOS will no
longer be supported. Nor will SAP continue to support Oracle or
or DB2 as unerlying database.

"Marketing by crowbar" comes to mind.

> I was
> in storage at SGI, they're really good at applying the *same* transform
> to a lot of data, not things like, "Here's a set of payroll rules, apply
> them to the records on this DASD, and write the resulting records on
> that DASD over there".
>
> 2 - Those big Linux systems are really, really good at recording and
> processing telephone calls looking for "interesting" content. For some
> reason the NSA buys them and installs them near large routing hubs in
> the USA, I can't think why...

The NSA has always been a big driver for computer development. Didn't
Cray implement POPCNT due to their demanding it?

On Sat, 19 Nov 2022 16:06:37 -0000 (UTC), Thomas Koenig
<tkoenig@netcologne.de> wrote:

>Gary R. Schmidt <grschmidt@acm.org> schrieb:
>> On 18/11/2022 22:56, Thomas Koenig wrote:
>>> Dorothy J Heydt <djheydt@kithrup.com> schrieb:
>>>
>>>> (Hal Heydt)
>>>> And just because the hardware uses 32-bit words doesn't prevent it
>>>> from having 64-bit numeric variables.
>>>>
>>>> All the programmers I knew in the 1970s were well aware of the
>>>> Y2K issue then. One shop I was in in the mid-70s had a program
>>>> to print 30 year amortization tables. Even then it was written
>>>> to handle post-2000 end dates.
>>>>
>>>> For a long time, businesses usually replaced application systems
>>>> about every 5 to 7 years. As a result, most IT people assumed
>>>> that sometime from the late 1980s to early 1990s, the
>>>> replacement cycle would shift everything to date routines that
>>>> handled the century rollover. Then companies quit *replacing*
>>>> systems and it became apparent (years before panic set in among
>>>> the MBAs) that Something Needed to be Done. The bean counters
>>>> weren't willing to spend the money to fix things until the panic
>>>> struck in the late 1990s. At that point, it cost a lot more, of
>>>> course.
>>>
>>> I always thought that the Y2K problem was one reason to move away
>>> from legacy mainframe systems. If you have to redo the system
>>> anyway, you might as well move to a different system.
>>
>> Replacing a mainframe with anything else is not trivial.
>>
>> Which is why most large mainframe sites still use mainframes.
>
>Around the 2000 timeframe, a lot of mainframe sites became
>no-longer-mainframe sites.
>
>SAP R/3 had a lot to do with it, I believe. The company I worked
>for still had 3270 terminal emulators running on PCs in the late
>1990s. Before 2000, they were all gone when they replaced their
>home-grown accounting system with SAP R/3, which ran client-server.
>
>If that transformation saved any money, I'm not sure, the project
>was horrible. No, it wasn't horrible, it was _really_ horrible.
>Fortunately, I wasn't involved, I just heard a few tidbits from
>people who were in that project.
>
>> Nothing moves data about whilst transforming it as fast as a
>> mainframe[1], which is where most, "We can move you to <insert
>> Relational Database and x64 box> in six months", attempts hit the wall.
>
>Those who can convert easily have already converted, I believe.
>
>> Banks really don't like the idea of waiting 36 hours for the end-of-day
>> processing to complete.
>>
>> Lots of people what think they're really shmott guys come a cropper on this.
>>
>> Cheers,
>> Gary B-)
>>
>> 1 - No, massively parallel Linux boxes don't do the same job[2].
>
>You've looked at what IBM mainframe run these days, right? zOS isn't
>the only game in town :-)
>
>And SAP HANA will run exclusively on Linux by 2027, zOS will no
>longer be supported. Nor will SAP continue to support Oracle or
>or DB2 as unerlying database.
>
>"Marketing by crowbar" comes to mind.

IIRC, they used to change the plugs on each new generation of
mainframe. Forcing their competitors for peripherals to scramble to
catch up.

Apparently, old habits die hard.

>> I was
>> in storage at SGI, they're really good at applying the *same* transform
>> to a lot of data, not things like, "Here's a set of payroll rules, apply
>> them to the records on this DASD, and write the resulting records on
>> that DASD over there".
>>
>> 2 - Those big Linux systems are really, really good at recording and
>> processing telephone calls looking for "interesting" content. For some
>> reason the NSA buys them and installs them near large routing hubs in
>> the USA, I can't think why...
>
>The NSA has always been a big driver for computer development. Didn't
>Cray implement POPCNT due to their demanding it?

Well, they probable /were/ (and, for all I know, may still be) Cray's
most lucrative client.

And he who pays the piper calls the tune.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

On Saturday, November 19, 2022 at 11:57:53 AM UTC-5, Paul S Person wrote:
> On Sat, 19 Nov 2022 16:06:37 -0000 (UTC), Thomas Koenig
> <tko...@netcologne.de> wrote:
>
> >Gary R. Schmidt <grsc...@acm.org> schrieb:
> >> On 18/11/2022 22:56, Thomas Koenig wrote:
> >>> Dorothy J Heydt <djh...@kithrup.com> schrieb:
> >>>
> >>>> (Hal Heydt)
> >>>> And just because the hardware uses 32-bit words doesn't prevent it
> >>>> from having 64-bit numeric variables.
> >>>>
> >>>> All the programmers I knew in the 1970s were well aware of the
> >>>> Y2K issue then. One shop I was in in the mid-70s had a program
> >>>> to print 30 year amortization tables. Even then it was written
> >>>> to handle post-2000 end dates.
> >>>>
> >>>> For a long time, businesses usually replaced application systems
> >>>> about every 5 to 7 years. As a result, most IT people assumed
> >>>> that sometime from the late 1980s to early 1990s, the
> >>>> replacement cycle would shift everything to date routines that
> >>>> handled the century rollover. Then companies quit *replacing*
> >>>> systems and it became apparent (years before panic set in among
> >>>> the MBAs) that Something Needed to be Done. The bean counters
> >>>> weren't willing to spend the money to fix things until the panic
> >>>> struck in the late 1990s. At that point, it cost a lot more, of
> >>>> course.
> >>>
> >>> I always thought that the Y2K problem was one reason to move away
> >>> from legacy mainframe systems. If you have to redo the system
> >>> anyway, you might as well move to a different system.
> >>
> >> Replacing a mainframe with anything else is not trivial.
> >>
> >> Which is why most large mainframe sites still use mainframes.
> >
> >Around the 2000 timeframe, a lot of mainframe sites became
> >no-longer-mainframe sites.
> >
> >SAP R/3 had a lot to do with it, I believe. The company I worked
> >for still had 3270 terminal emulators running on PCs in the late
> >1990s. Before 2000, they were all gone when they replaced their
> >home-grown accounting system with SAP R/3, which ran client-server.
> >
> >If that transformation saved any money, I'm not sure, the project
> >was horrible. No, it wasn't horrible, it was _really_ horrible.
> >Fortunately, I wasn't involved, I just heard a few tidbits from
> >people who were in that project.
> >
> >> Nothing moves data about whilst transforming it as fast as a
> >> mainframe[1], which is where most, "We can move you to <insert
> >> Relational Database and x64 box> in six months", attempts hit the wall.
> >
> >Those who can convert easily have already converted, I believe.
> >
> >> Banks really don't like the idea of waiting 36 hours for the end-of-day
> >> processing to complete.
> >>
> >> Lots of people what think they're really shmott guys come a cropper on this.
> >>
> >> Cheers,
> >> Gary B-)
> >>
> >> 1 - No, massively parallel Linux boxes don't do the same job[2].
> >
> >You've looked at what IBM mainframe run these days, right? zOS isn't
> >the only game in town :-)
> >
> >And SAP HANA will run exclusively on Linux by 2027, zOS will no
> >longer be supported. Nor will SAP continue to support Oracle or
> >or DB2 as unerlying database.
> >
> >"Marketing by crowbar" comes to mind.
> IIRC, they used to change the plugs on each new generation of
> mainframe. Forcing their competitors for peripherals to scramble to
> catch up.
>
> Apparently, old habits die hard.
> >> I was
> >> in storage at SGI, they're really good at applying the *same* transform
> >> to a lot of data, not things like, "Here's a set of payroll rules, apply
> >> them to the records on this DASD, and write the resulting records on
> >> that DASD over there".
> >>
> >> 2 - Those big Linux systems are really, really good at recording and
> >> processing telephone calls looking for "interesting" content. For some
> >> reason the NSA buys them and installs them near large routing hubs in
> >> the USA, I can't think why...
> >
> >The NSA has always been a big driver for computer development. Didn't
> >Cray implement POPCNT due to their demanding it?
> Well, they probable /were/ (and, for all I know, may still be) Cray's
> most lucrative client.
>
> And he who pays the piper calls the tune.

I've always heard that POPCOUNT was for code breaking. Look up
'Index of Coincidence' if you're curious.

There are alternatives, but Cray is still up there.. The Cray 1 reached about
160 megaflops in 1975. The Cray X-MP in 1982, 800.

The Apple M1 processor, currently used in Mac desktops, can reach
21 TERAflops. That's 130,000x the Cray 1. Even the iPad Air I'm typing this
on reaches 2.6 TFlops.

The fastest commercial computer I'm aware of, from Cray/HP Enterprise,
is over 1,000,000 TFlops (1 Exaflop).

Pt

On 11/19/2022 9:40 AM, pete...@gmail.com wrote:
> On Saturday, November 19, 2022 at 11:57:53 AM UTC-5, Paul S Person wrote:
>> On Sat, 19 Nov 2022 16:06:37 -0000 (UTC), Thomas Koenig
>> <tko...@netcologne.de> wrote:
>>
>>> Gary R. Schmidt <grsc...@acm.org> schrieb:
>>>> On 18/11/2022 22:56, Thomas Koenig wrote:
>>>>> Dorothy J Heydt <djh...@kithrup.com> schrieb:
>>>>>
>>>>>> (Hal Heydt)
>>>>>> And just because the hardware uses 32-bit words doesn't prevent it
>>>>>> from having 64-bit numeric variables.
>>>>>>
>>>>>> All the programmers I knew in the 1970s were well aware of the
>>>>>> Y2K issue then. One shop I was in in the mid-70s had a program
>>>>>> to print 30 year amortization tables. Even then it was written
>>>>>> to handle post-2000 end dates.
>>>>>>
>>>>>> For a long time, businesses usually replaced application systems
>>>>>> about every 5 to 7 years. As a result, most IT people assumed
>>>>>> that sometime from the late 1980s to early 1990s, the
>>>>>> replacement cycle would shift everything to date routines that
>>>>>> handled the century rollover. Then companies quit *replacing*
>>>>>> systems and it became apparent (years before panic set in among
>>>>>> the MBAs) that Something Needed to be Done. The bean counters
>>>>>> weren't willing to spend the money to fix things until the panic
>>>>>> struck in the late 1990s. At that point, it cost a lot more, of
>>>>>> course.
>>>>>
>>>>> I always thought that the Y2K problem was one reason to move away
>>>>> from legacy mainframe systems. If you have to redo the system
>>>>> anyway, you might as well move to a different system.
>>>>
>>>> Replacing a mainframe with anything else is not trivial.
>>>>
>>>> Which is why most large mainframe sites still use mainframes.
>>>
>>> Around the 2000 timeframe, a lot of mainframe sites became
>>> no-longer-mainframe sites.
>>>
>>> SAP R/3 had a lot to do with it, I believe. The company I worked
>>> for still had 3270 terminal emulators running on PCs in the late
>>> 1990s. Before 2000, they were all gone when they replaced their
>>> home-grown accounting system with SAP R/3, which ran client-server.
>>>
>>> If that transformation saved any money, I'm not sure, the project
>>> was horrible. No, it wasn't horrible, it was _really_ horrible.
>>> Fortunately, I wasn't involved, I just heard a few tidbits from
>>> people who were in that project.
>>>
>>>> Nothing moves data about whilst transforming it as fast as a
>>>> mainframe[1], which is where most, "We can move you to <insert
>>>> Relational Database and x64 box> in six months", attempts hit the wall.
>>>
>>> Those who can convert easily have already converted, I believe.
>>>
>>>> Banks really don't like the idea of waiting 36 hours for the end-of-day
>>>> processing to complete.
>>>>
>>>> Lots of people what think they're really shmott guys come a cropper on this.
>>>>
>>>> Cheers,
>>>> Gary B-)
>>>>
>>>> 1 - No, massively parallel Linux boxes don't do the same job[2].
>>>
>>> You've looked at what IBM mainframe run these days, right? zOS isn't
>>> the only game in town :-)
>>>
>>> And SAP HANA will run exclusively on Linux by 2027, zOS will no
>>> longer be supported. Nor will SAP continue to support Oracle or
>>> or DB2 as unerlying database.
>>>
>>> "Marketing by crowbar" comes to mind.
>> IIRC, they used to change the plugs on each new generation of
>> mainframe. Forcing their competitors for peripherals to scramble to
>> catch up.
>>
>> Apparently, old habits die hard.
>>>> I was
>>>> in storage at SGI, they're really good at applying the *same* transform
>>>> to a lot of data, not things like, "Here's a set of payroll rules, apply
>>>> them to the records on this DASD, and write the resulting records on
>>>> that DASD over there".
>>>>
>>>> 2 - Those big Linux systems are really, really good at recording and
>>>> processing telephone calls looking for "interesting" content. For some
>>>> reason the NSA buys them and installs them near large routing hubs in
>>>> the USA, I can't think why...
>>>
>>> The NSA has always been a big driver for computer development. Didn't
>>> Cray implement POPCNT due to their demanding it?
>> Well, they probable /were/ (and, for all I know, may still be) Cray's
>> most lucrative client.
>>
>> And he who pays the piper calls the tune.
>
> I've always heard that POPCOUNT was for code breaking. Look up
> 'Index of Coincidence' if you're curious.
>
> There are alternatives, but Cray is still up there.. The Cray 1 reached about
> 160 megaflops in 1975. The Cray X-MP in 1982, 800.
>
> The Apple M1 processor, currently used in Mac desktops, can reach
> 21 TERAflops. That's 130,000x the Cray 1. Even the iPad Air I'm typing this
> on reaches 2.6 TFlops.
>
> The fastest commercial computer I'm aware of, from Cray/HP Enterprise,
> is over 1,000,000 TFlops (1 Exaflop).
>
Anyone know the minimum required Flops to run Skynet?

--
I've done good in this world. Now I'm tired and just want to be a cranky
dirty old man.

Dimensional Traveler <dtravel@sonic.net> schrieb:

> Anyone know the minimum required Flops to run Skynet?

As we all know (or should) Skynet is just a pretentious buffer
overrun.

http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html

Dimensional Traveler <dtravel@sonic.net> writes:
>On 11/19/2022 9:40 AM, pete...@gmail.com wrote:
>> On Saturday, November 19, 2022 at 11:57:53 AM UTC-5, Paul S Person wrote:

>> There are alternatives, but Cray is still up there.. The Cray 1 reached about
>> 160 megaflops in 1975. The Cray X-MP in 1982, 800.
>>
>> The Apple M1 processor, currently used in Mac desktops, can reach
>> 21 TERAflops. That's 130,000x the Cray 1. Even the iPad Air I'm typing this
>> on reaches 2.6 TFlops.
>>
>> The fastest commercial computer I'm aware of, from Cray/HP Enterprise,
>> is over 1,000,000 TFlops (1 Exaflop).
>>
>Anyone know the minimum required Flops to run Skynet?

Thomas P Ryan created an self-aware AI with a bunch of teleconnected IBM 360's in
the _Adolescence of P1_. His 'jailbreak' on the 360 anticipated Spectre.

On 11/18/2022 10:11 PM, Dimensional Traveler wrote:
> On 11/18/2022 6:11 PM, Dorothy J Heydt wrote:
>> In article <0a82548e-4145-4d3a-8895-8103b9a7ebc0n@googlegroups.com>,
>> Robert Carnegie  <rja.carnegie@excite.com> wrote:
>>> Incidentally, there may be trouble again around
>>> the year 9999.
>>
>> (Hal Heydt)
>> Barring some really spectacular breakthroughs in gerontology, I
>> don't expect to have to worry about the Y10K problem.  Though if
>> I'm alive then, I suppose I could dust off my COBOL skills and
>> see what the market will bear...
>
> Cryogenics.  Then you can BE the COBOL programmer in the old joke about
> the programmer who after Y2K put himself into some kind of suspended
> animation, then got woken up on the year 9,999 so the ruler of Earth
> could ask him, "We understand you know COBOL...?"

Yeah, woken up as an AI in a computer. Just like Bob Johansson.
https://www.amazon.com/We-Are-Legion-Bob-Bobiverse/dp/1680680587/

Lynn

On 11/19/2022 1:27 PM, Lynn McGuire wrote:
> On 11/18/2022 10:11 PM, Dimensional Traveler wrote:
>> On 11/18/2022 6:11 PM, Dorothy J Heydt wrote:
>>> In article <0a82548e-4145-4d3a-8895-8103b9a7ebc0n@googlegroups.com>,
>>> Robert Carnegie  <rja.carnegie@excite.com> wrote:
>>>> Incidentally, there may be trouble again around
>>>> the year 9999.
>>>
>>> (Hal Heydt)
>>> Barring some really spectacular breakthroughs in gerontology, I
>>> don't expect to have to worry about the Y10K problem.  Though if
>>> I'm alive then, I suppose I could dust off my COBOL skills and
>>> see what the market will bear...
>>
>> Cryogenics.  Then you can BE the COBOL programmer in the old joke
>> about the programmer who after Y2K put himself into some kind of
>> suspended animation, then got woken up on the year 9,999 so the ruler
>> of Earth could ask him, "We understand you know COBOL...?"
>
> Yeah, woken up as an AI in a computer.  Just like Bob Johansson.
>    https://www.amazon.com/We-Are-Legion-Bob-Bobiverse/dp/1680680587/
>
I wasn't referring to a story, there was an actual joke going around.

--
I've done good in this world. Now I'm tired and just want to be a cranky
dirty old man.

On 20/11/2022 03:06, Thomas Koenig wrote:
> Gary R. Schmidt <grschmidt@acm.org> schrieb:
[SNIP]
>>
>> 1 - No, massively parallel Linux boxes don't do the same job[2].
>
> You've looked at what IBM mainframe run these days, right? zOS isn't
> the only game in town :-)
>
No, MSP and XSP are still alive and paying some salaries in the group I
work in at Fujitsu Oz. :-)

Cheers,
Gary B-)

On 11/19/2022 6:00 PM, Dimensional Traveler wrote:
> On 11/19/2022 1:27 PM, Lynn McGuire wrote:
>> On 11/18/2022 10:11 PM, Dimensional Traveler wrote:
>>> On 11/18/2022 6:11 PM, Dorothy J Heydt wrote:
>>>> In article <0a82548e-4145-4d3a-8895-8103b9a7ebc0n@googlegroups.com>,
>>>> Robert Carnegie  <rja.carnegie@excite.com> wrote:
>>>>> Incidentally, there may be trouble again around
>>>>> the year 9999.
>>>>
>>>> (Hal Heydt)
>>>> Barring some really spectacular breakthroughs in gerontology, I
>>>> don't expect to have to worry about the Y10K problem.  Though if
>>>> I'm alive then, I suppose I could dust off my COBOL skills and
>>>> see what the market will bear...
>>>
>>> Cryogenics.  Then you can BE the COBOL programmer in the old joke
>>> about the programmer who after Y2K put himself into some kind of
>>> suspended animation, then got woken up on the year 9,999 so the ruler
>>> of Earth could ask him, "We understand you know COBOL...?"
>>
>> Yeah, woken up as an AI in a computer.  Just like Bob Johansson.
>>     https://www.amazon.com/We-Are-Legion-Bob-Bobiverse/dp/1680680587/
>>
> I wasn't referring to a story, there was an actual joke going around.

I know. But I liked the lead in.

Lynn

Gary R. Schmidt <grschmidt@acm.org> schrieb:
> On 20/11/2022 03:06, Thomas Koenig wrote:
>> Gary R. Schmidt <grschmidt@acm.org> schrieb:
> [SNIP]
>>>
>>> 1 - No, massively parallel Linux boxes don't do the same job[2].
>>
>> You've looked at what IBM mainframe run these days, right? zOS isn't
>> the only game in town :-)
>>
> No, MSP and XSP are still alive and paying some salaries in the group I
> work in at Fujitsu Oz. :-)

Last time I read it, the Fujitsu mainframes were still 31 bit.
Is that the case?

On Thu, 17 Nov 2022 21:25:39 GMT, djheydt@kithrup.com (Dorothy J
Heydt) wrote:

>>(Hal Heydt)
>>Actually, more to the point... How many appliances with embedded
>>processors "care" what the date is? (As for longevity, if I go
>>out to buy a new refrigerator now, I sure as heck expect it to
>>still be functioning in 2038. Same for other major appliances.)
>
>(Hal Heydt)
>I should have added... *I* may not still be operational in 2038.

Well there >IS< that.

My daughter is back east seeing her aunt right now or she would be
VERY upset to hear me say to our 9 year old kitty cat that I expect to
outlast her.....(uh the cat not my daughter)

The events of the past year have tended to make one take things less
for granted.

On Thu, 17 Nov 2022 21:27:02 GMT, djheydt@kithrup.com (Dorothy J
Heydt) wrote:

>(Hal Heydt)
>A Real Programmer can write a FORTRAN program in *any* language.

Just because something CAN be done doesn't mean it SHOULD be.

Back in my student days I once saw an APL program essentially written
in FORTRAN. Think about that ;)

On Fri, 18 Nov 2022 14:45:49 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>>> I always thought that the Y2K problem was one reason to move away
>>> from legacy mainframe systems. If you have to redo the system
>>> anyway, you might as well move to a different system.
>>
>>It was rarely a complete rewrite.
>
>Indeed. In many cases it was just a minor change to an application.
>
>The problem being that there were a lot of compiled applications for
>which the corresponding source card deck had disappeared :-(.

Back in 2000 my sister-in-law was the IT manager of a major insurance
company's main server center (she retired recently as VP Network
Operations - e.g. all servers within a 600 mile radius) and was in
charge of their Y2K program. Their main site was fully staffed the
evening of 12/31/1999 including her.

Shortly before midnight they gathered all their staff in the server
room and despite a corporate wide policy against booze on the premises
she and her assistant disappeared and right about the time the
countdown started she and the assistant returned with a dolly loaded
with a large case of champagne and ice buckets.

THEIR New Year's Eve party started at 1 am once they had agreed
nothing catastrophic was happening anywhere on the network and a very
nice party started (with cabs prearranged to take everyone home)

She said it was one of the more memorable moments in her career and
that while the work her people had done had identified a few problems
which they fixed ahead of the date nothing catastrophic kicked in at
midnight. Her view was that a LOT of preventive maintenance had been
done and that her network was the better for it.

And the strict anti-booze on the premises policy was back in full
force the next day.

In article <sp1lnh944dm9i3ieujgh3tag9s50mp345c@4ax.com>,
The Horny Goat <lcraver@home.ca> wrote:
>On Fri, 18 Nov 2022 14:45:49 GMT, scott@slp53.sl.home (Scott Lurndal)
>wrote:
>
>>>> I always thought that the Y2K problem was one reason to move away
>>>> from legacy mainframe systems. If you have to redo the system
>>>> anyway, you might as well move to a different system.
>>>
>>>It was rarely a complete rewrite.
>>
>>Indeed. In many cases it was just a minor change to an application.
>>
>>The problem being that there were a lot of compiled applications for
>>which the corresponding source card deck had disappeared :-(.
>
>Back in 2000 my sister-in-law was the IT manager of a major insurance
>company's main server center (she retired recently as VP Network
>Operations - e.g. all servers within a 600 mile radius) and was in
>charge of their Y2K program. Their main site was fully staffed the
>evening of 12/31/1999 including her.

The IT guy for a certain major cultural organization decided
the best way to deal with Y2K was to schedule his holiday
for the last week of 1999 and the first week of 2000. As it
happened, the org's software was _not_ Y2K compliant.
--
My reviews can be found at http://jamesdavisnicoll.com/
My tor pieces at https://www.tor.com/author/james-davis-nicoll/
My Dreamwidth at https://james-davis-nicoll.dreamwidth.org/
My patreon is at https://www.patreon.com/jamesdnicoll

On 20/11/2022 20:57, Thomas Koenig wrote:
> Gary R. Schmidt <grschmidt@acm.org> schrieb:
>> On 20/11/2022 03:06, Thomas Koenig wrote:
>>> Gary R. Schmidt <grschmidt@acm.org> schrieb:
>> [SNIP]
>>>>
>>>> 1 - No, massively parallel Linux boxes don't do the same job[2].
>>>
>>> You've looked at what IBM mainframe run these days, right? zOS isn't
>>> the only game in town :-)
>>>
>> No, MSP and XSP are still alive and paying some salaries in the group I
>> work in at Fujitsu Oz. :-)
>
> Last time I read it, the Fujitsu mainframes were still 31 bit.
> Is that the case?
Tep.

But only an idiot does anything other than approximations using floating
point.

Cheers,
Gary B-)