Nasdaq used to use Unisys 2200 machines until some time around the year
2000, are the replacement systems the ones which suffered from the
32-bit 429496.7295 limit on May 6?
Berkshire Hathaway A Shares (traded on NYSE) exceeded that limit and the
Nasdaq systems cound not handle it. The stupid part was that this was
not down to a sudden jump in the share price, it had been around 350 000
before the Covid crash and was around 400 000 in early March.
Unisys 2200 systems can handle values 8 or 16 times as high, depending
on the language used (not all languages can handle unsigned 36 bit values).
It would be rather amusing if the systems they had "modernised" were the
ones which failed here.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, June 18, 2021 at 7:53:01 AM UTC-3, Andrew wrote:

Nasdaq used to use Unisys 2200 machines until some time around the year 2000, are the replacement systems the ones which suffered from the
32-bit 429496.7295 limit on May 6?
Berkshire Hathaway A Shares (traded on NYSE) exceeded that limit and the Nasdaq systems cound not handle it. The stupid part was that this was
not down to a sudden jump in the share price, it had been around 350 000 before the Covid crash and was around 400 000 in early March.
Unisys 2200 systems can handle values 8 or 16 times as high, depending
on the language used (not all languages can handle unsigned 36 bit values). It would be rather amusing if the systems they had "modernised" were the ones which failed here.

I worked at Nasdaq in the late 1990s, supporting Unisys 2200/IX (now called Dorado) systems. That gives me no special insight into last month's problem showing Berkshire Hathway's share price. But I have some general comments.

My understanding is that 20 years ago Nasdaq dropped Unisys for Tandem, which was already heavily and expertly used there. But this might well have changed since then.

I see this less as an architectural issue than an application issue, particularly a lack of imagination. Yes, had the share price stored in an unsigned Dorado 36-bit word, the limit would have been $6,871,947.6736. (If Warren Buffett lives long enough,
even that limit might be exceeded!) Never mind what might be accomplished on 48-bit or 72-bit systems. But there are many ways to store large numbers in any computer system, and the system with the largest word size doesn't always prevail. Using an
architectural limit as an application limit itself shows quite a lack of imagination.

I worked at Nasdaq on the first day that total shares traded exceeded 1 billion. Like your car odometer, the Nasdaq display of total shares traded rolled over from 999,999,999 to zero. It was embarrassing but easily fixed, and not the end of the world
as we knew it.

Of course, with both of these limits, Nasdaq should have been aware of them, monitoring the approach to them, and taking corrective action before the limit was exceeded.

Our lack of imagination is everywhere. Consider Y2K, periodic GPS rollovers, 2028 TDATE$ rollover, 2038 Unix time rollover, Ken Olsen not seeing any reason for home computers, Bill Gates claiming that 640K of memory would be sufficient. It happens to
the best of us.

Cheers,
Steve J. Martin
(Speaking only for myself on 2021-06-21.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Steve J. Martin wrote:

On Friday, June 18, 2021 at 7:53:01 AM UTC-3, Andrew wrote:

Nasdaq used to use Unisys 2200 machines until some time around the year
2000, are the replacement systems the ones which suffered from the
32-bit 429496.7295 limit on May 6?
Berkshire Hathaway A Shares (traded on NYSE) exceeded that limit and the
Nasdaq systems cound not handle it. The stupid part was that this was
not down to a sudden jump in the share price, it had been around 350 000
before the Covid crash and was around 400 000 in early March.
Unisys 2200 systems can handle values 8 or 16 times as high, depending
on the language used (not all languages can handle unsigned 36 bit values). >> It would be rather amusing if the systems they had "modernised" were the
ones which failed here.

I worked at Nasdaq in the late 1990s, supporting Unisys 2200/IX (now called Dorado) systems. That gives me no special insight into last month's problem showing Berkshire Hathway's share price. But I have some general comments.

My understanding is that 20 years ago Nasdaq dropped Unisys for Tandem, which was already heavily and expertly used there. But this might well have changed since then.

I see this less as an architectural issue than an application issue, particularly a lack of imagination. Yes, had the share price stored in an unsigned Dorado 36-bit word, the limit would have been $6,871,947.6736. (If Warren Buffett lives long

enough, even that limit might be exceeded!) Never mind what might be accomplished on 48-bit or 72-bit systems. But there are many ways to store large numbers in any computer system, and the system with the largest word size doesn't always prevail.
Using an architectural limit as an application limit itself shows quite a lack of imagination.

I worked at Nasdaq on the first day that total shares traded exceeded 1 billion. Like your car odometer, the Nasdaq display of total shares traded rolled over from 999,999,999 to zero. It was embarrassing but easily fixed, and not the end of the

world as we knew it.

Of course, with both of these limits, Nasdaq should have been aware of them, monitoring the approach to them, and taking corrective action before the limit was exceeded.

Our lack of imagination is everywhere. Consider Y2K, periodic GPS rollovers, 2028 TDATE$ rollover, 2038 Unix time rollover, Ken Olsen not seeing any reason for home computers, Bill Gates claiming that 640K of memory would be sufficient. It happens to

the best of us.

Cheers,
Steve J. Martin
(Speaking only for myself on 2021-06-21.)

Hi Steve,

I knew you had been there and that question was aimed as much at you as
at anybody.
Who was thinking about a TDATE$ rollover in 1964? I thought it rather
pathetic that it took until after 2010 (?) to create the (days since
1-1-1900, seconds since midnight) format - that should have been
available from around 1990 instead of yymmddssssss - but 1964 was a
different matter.
Similarly, total shares traded exceeding 999 999 999 was obviously going
to happen a couple of years before it actually did. I suppose the idea
is to recognise which fields are liable to overflow, total shares traded
would not necessarily have been on mine.
Another 17-odd years until Unix time rolls over, I wonder what the
side-effects are going to be.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Steve J. Martin" <sjmsoft@gmail.com> writes:

Our lack of imagination is everywhere. Consider Y2K, periodic GPS rollover= >s, 2028 TDATE$ rollover, 2038 Unix time rollover, Ken Olsen not seeing any = >reason for home computers, Bill Gates claiming that 640K of memory would be=
sufficient. It happens to the best of us.

Y2K:

In the 60's memory and storage space was expensive. Why store four
digits when two suffice? To be fair, we started mitigations for it
in the 1980's in the Burroughs MCPs, and survived the turn of the
millenium (2000 or 2001 as you wish) sans a hickup, with the next
hickup being circa 2060 when the hack to determine the century
no longer works. Not to worry, they're all retired now (except
for the v-series simulator which handles 2021 just fine).

Unix Time:
To the extent that there will be any significant number of 32-bit systems remaining seventeen years from now, they'll need mitigation. It's not like there isn't plenty of time to prepare. 64-bit unix should good for a few
years thereafter. I would expect that most professionaly written applications don't store dates relative to the unix Epoch anyway (e.g. databases, et alia).

The same constraints on memory existed in the 1970s.

Bill Gates, Ken Olson:

A meaningless statement then, and meaningless now. Not relevent.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/21/21 2:16 PM, Scott Lurndal wrote:

"Steve J. Martin" <sjmsoft@gmail.com> writes:

Our lack of imagination is everywhere. Consider Y2K, periodic GPS rollover= >> s, 2028 TDATE$ rollover, 2038 Unix time rollover, Ken Olsen not seeing any = >> reason for home computers, Bill Gates claiming that 640K of memory would be= >> sufficient. It happens to the best of us.

Y2K:

In the 60's memory and storage space was expensive. Why store four digits when two suffice? To be fair, we started mitigations for it
in the 1980's in the Burroughs MCPs, and survived the turn of the
millenium (2000 or 2001 as you wish) sans a hickup, with the next
hickup being circa 2060 when the hack to determine the century
no longer works. Not to worry, they're all retired now (except
for the v-series simulator which handles 2021 just fine).

Amazing how often Y2K still comes up. I lived thru it. I knew of
no typical legacy system that had an actual problem when it hit.
All the problems I saw were in modern systems programmed in Perl,
PHP and mostly Java. Lot's of web programming that rolled over
to some truly weird dates.

bill

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bill Gunshannon wrote:

On 6/21/21 2:16 PM, Scott Lurndal wrote:

"Steve J. Martin" <sjmsoft@gmail.com> writes:

Our lack of imagination is everywhere.  Consider Y2K, periodic GPS
rollover=
s, 2028 TDATE$ rollover, 2038 Unix time rollover, Ken Olsen not
seeing any =
reason for home computers, Bill Gates claiming that 640K of memory
would be=
sufficient.  It happens to the best of us.

Y2K:

   In the 60's memory and storage space was expensive.   Why store four >> digits when two suffice?   To be fair, we started mitigations for it
in the 1980's in the Burroughs MCPs, and survived the turn of the
millenium (2000 or 2001 as you wish) sans a hickup, with the next
hickup being circa 2060 when the hack to determine the century
no longer works.  Not to worry, they're all retired now (except
for the v-series simulator which handles 2021 just fine).

Amazing how often Y2K still comes up. I lived thru it.  I knew of
no typical legacy system that had an actual problem when it hit.
All the problems I saw were in modern systems programmed in Perl,
PHP and mostly Java.  Lot's of web programming that rolled over
to some truly weird dates.

bill

1999 + 1 = 19100 (I saw that a lot in January 2000)
99 + 1 = '0 (that was the @cts version)
99 + 1 = :0 (that was the ascii equivalent).

@cts was no longer supported by then but the place I worked used it
extensively and that '0 was also returned as part of the date()
function. I wrote and generated a fix which changed the processor-id
line to use I$D$, and subtracted 100 from the year if it exceeded 99 to
fix date(). A second version of the date() fix would have added 1900 to
the year and made it 4-digit, but that broke things.
Hmmm, I see the @cts fix was integrated in Summer 1997 - I must have
tested this stuff ahead of time.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/22/21 6:23 AM, Andrew wrote:

Bill Gunshannon wrote:

On 6/21/21 2:16 PM, Scott Lurndal wrote:

"Steve J. Martin" <sjmsoft@gmail.com> writes:

Our lack of imagination is everywhere.  Consider Y2K, periodic GPS
rollover=
s, 2028 TDATE$ rollover, 2038 Unix time rollover, Ken Olsen not
seeing any =
reason for home computers, Bill Gates claiming that 640K of memory
would be=
sufficient.  It happens to the best of us.

Y2K:

   In the 60's memory and storage space was expensive.   Why store four >>> digits when two suffice?   To be fair, we started mitigations for it
in the 1980's in the Burroughs MCPs, and survived the turn of the
millenium (2000 or 2001 as you wish) sans a hickup, with the next
hickup being circa 2060 when the hack to determine the century
no longer works.  Not to worry, they're all retired now (except
for the v-series simulator which handles 2021 just fine).

Amazing how often Y2K still comes up. I lived thru it.  I knew of
no typical legacy system that had an actual problem when it hit.
All the problems I saw were in modern systems programmed in Perl,
PHP and mostly Java.  Lot's of web programming that rolled over
to some truly weird dates.

bill

1999 + 1 = 19100 (I saw that a lot in January 2000)
99 + 1 = '0 (that was the @cts version)
99 + 1 = :0 (that was the ascii equivalent).

@cts was no longer supported by then but the place I worked used it extensively and that '0 was also returned as part of the date()
function.  I wrote and generated a fix which changed the processor-id
line to use I$D$, and subtracted 100 from the year if it exceeded 99 to
fix date().  A second version of the date() fix would have added 1900 to
the year and made it 4-digit, but that broke things.
Hmmm, I see the @cts fix was integrated in Summer 1997 - I must have
tested this stuff ahead of time.

So the problem was fixed in 1997, three years before it would
actually be a problem. That was the norm I saw on serious IT
systems approaching Y2K. The web, not so much.

bill

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/18/2021 3:53 AM, Andrew wrote:

Nasdaq used to use Unisys 2200 machines until some time around the year
2000, are the replacement systems the ones which suffered from the
32-bit 429496.7295 limit on May 6?
Berkshire Hathaway A Shares (traded on NYSE) exceeded that limit and the Nasdaq systems cound not handle it.  The stupid part was that this was
not down to a sudden jump in the share price, it had been around 350 000 before the Covid crash and was around 400 000 in early March.
Unisys 2200 systems can handle values 8 or 16 times as high, depending
on the language used (not all languages can handle unsigned 36 bit values). It would be rather amusing if the systems they had "modernised" were the
ones which failed here.

Since, as you point out above, Berkshire Hathaway A shares are traded on
the NYSE, not NASDAQ, whatever the NASDAQ's computers use is irrelevant.

On the other hand, SIAC, the subsidiary of the NYSE that provides its
computer services, at least was an 1100 series customer in the late
1970s and early 1980s. I remember some very interesting discussions
with their people at USE conferences. Their up-time requirements were,
for that time, "interesting".

In any event, I understand that the NYSE uses a different representation
of prices than NASDAQ,so this particular problem didn't occur.



--
- Stephen Fuld
(e-mail address disguised to prevent spam)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stephen Fuld wrote:

On 6/18/2021 3:53 AM, Andrew wrote:

Nasdaq used to use Unisys 2200 machines until some time around the
year 2000, are the replacement systems the ones which suffered from
the 32-bit 429496.7295 limit on May 6?
Berkshire Hathaway A Shares (traded on NYSE) exceeded that limit and
the Nasdaq systems cound not handle it.  The stupid part was that this
was not down to a sudden jump in the share price, it had been around
350 000 before the Covid crash and was around 400 000 in early March.
Unisys 2200 systems can handle values 8 or 16 times as high, depending
on the language used (not all languages can handle unsigned 36 bit
values).
It would be rather amusing if the systems they had "modernised" were
the ones which failed here.

Since, as you point out above, Berkshire Hathaway A shares are traded on
the NYSE, not NASDAQ, whatever the NASDAQ's computers use is irrelevant.

On the other hand, SIAC, the subsidiary of the NYSE that provides its computer services, at least was an 1100 series customer in the late
1970s and early 1980s.  I remember some very interesting discussions
with their people at USE conferences. Their up-time requirements were,
for that time, "interesting".

In any event, I understand that the NYSE uses a different representation
of prices than NASDAQ,so this particular problem didn't occur.

My understanding is that NASDAQ provides a reporting service for share
prices - including those on the NYSE. It would have been a lot worse if Berkshire Hathaway were traded directly on the NASDAQ.

That was what I read as well - I can't remember if NYSE use 64 bits but
it was certainly more than 32.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/25/2021 11:24 AM, Andrew wrote:

Stephen Fuld wrote:

On 6/18/2021 3:53 AM, Andrew wrote:

Nasdaq used to use Unisys 2200 machines until some time around the
year 2000, are the replacement systems the ones which suffered from
the 32-bit 429496.7295 limit on May 6?
Berkshire Hathaway A Shares (traded on NYSE) exceeded that limit and
the Nasdaq systems cound not handle it.  The stupid part was that
this was not down to a sudden jump in the share price, it had been
around 350 000 before the Covid crash and was around 400 000 in early
March.
Unisys 2200 systems can handle values 8 or 16 times as high,
depending on the language used (not all languages can handle unsigned
36 bit values).
It would be rather amusing if the systems they had "modernised" were
the ones which failed here.

Since, as you point out above, Berkshire Hathaway A shares are traded
on the NYSE, not NASDAQ, whatever the NASDAQ's computers use is
irrelevant.

On the other hand, SIAC, the subsidiary of the NYSE that provides its
computer services, at least was an 1100 series customer in the late
1970s and early 1980s.  I remember some very interesting discussions
with their people at USE conferences. Their up-time requirements were,
for that time, "interesting".

In any event, I understand that the NYSE uses a different
representation of prices than NASDAQ,so this particular problem didn't
occur.

My understanding is that NASDAQ provides a reporting service for share
prices - including those on the NYSE.

I hadn't heard that, but it certainly could be true.

It would have been a lot worse if
Berkshire Hathaway were traded directly on the NASDAQ.

That was what I read as well - I can't remember if NYSE use 64 bits but
it was certainly more than 32.

Or, perhaps they don't keep prices to 4 decimal places. I haven't found
out through a quick web search, though I did find a lot of references to
the problem being called a Buffett Overflow.



--
- Stephen Fuld
(e-mail address disguised to prevent spam)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)