Re: [TUHS] The 2038 bug...

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

On Thu, Dec 31, 2020 at 11:37 AM Theodore Ts'o <tytso@mit.edu> wrote:

> Twenty years ago, one of larger customers for the company I was
> working for at the time (VA Linux Systems) was one of the new
> electronic stock exchanges, and they were using Linux boxes with
> PDP-11 emulators because their stock trading software was written in
> Macro-11 and running on RSTS/E.  They had tried three times to rewrite
> it so it could run on something more modern, but each time, the
> rewrite had ended in failure.  So they simply sharded the problem, so
> one x86 server running RSTS/E in emulation would service stocks
> symbols AAAA--ADZZ, and the next would service stocks AEAA--AFZZ, and
> so on.  Given that this was back in 1999, I assume they had solved the
> Y2K problem one way or another, but even if they hadn't yet, I suspect
> it would have been easier for them to fix the problem by asking their
> dedicated Macro-11 Software Engineering team to fix it, than to ask
> that same team to help the other team put themselves out of a job
> (which for some reason, never seemed to happen successfully...)
>

This is the sort of reason why QBUS x86 machines exist...  Not cheap, or
easy to come by these days, but they filled a niche of emulation but with
access to real hardware... Nor easy to find with a web search, it seems :(.

There's a number of nuclear power plants that employ MACRO-11 programmers
because they can't swap out the old gear w/o going through a prohibitively
expensive recertification process... It's cheaper to hire and train good
programmers than it is to go through that process :(.

Warner

[-- Attachment #2: Type: text/html, Size: 2064 bytes --]