Nasdaq, Unisys and Berkshire Hathaway A

[Andrew]

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.

[Steve J. Martin]

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.)

[Andrew]

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.

[Scott Lurndal]

"Steve J. Martin" <sjm...@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.

[Bill Gunshannon]

On 6/21/21 2:16 PM, Scott Lurndal wrote:
> "Steve J. Martin" <sjm...@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

[Andrew]

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.

[Bill Gunshannon]

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

[Stephen Fuld]

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)

[Andrew]

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.

[Stephen Fuld]

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.