Many universities have systems like that. Banks too. Probably true of many early adopters: they built systems that worked and didn't rewrite them simply for the sake of having something new.
At my first job, we built I/O cards that did stuff like the Amiga in the article does. The cards used adapters so they could run on anything from TRS80's to PC's because at the time the system was conceived, the IBM PC hadn't emerged as the dominant desktop yet.
The company is long out of business, but every so often someone finds some of their products at a garage sale or industrial auction or it comes in a box of other things on eBay. When they search for manuals on the product they often find me because by coincidence someone asked about those products on a forum I frequent and that conversation tends to come up in the first page on google.
It's amazing how many really old systems are still running after decades without change and no one gives it a thought until something breaks. I've often wished I had a list of their old customers so I could contact them and offer my services to upgrade old controls.
Yes and please do blog about it regularly if you feel like it - this whole thread on legacy systems is the most interesting read on HN for a long time IMHO.
Most of my credit cards will not update the balance immediately after I make a payment. It takes a day (sometimes more, depending on timing). Clearly batch processes are involved.
There's nothing wrong with batch processes. They are often easier to reason about than having a system where everything can change in real time.
Sometimes you want real time. Sometimes (many times) a daily batch is just fine.
Credit card processing does seem to be moving towards real-time. Lately I've found more and more merchants where I get a notification on my phone instantly after my Amex is swiped.
You can have delays for that purpose in real-time systems too. And they'd actually be consistent, instead of having variable lengths to cancel the transaction.
When I interned at IBM from 2003-2006, we submitted our timecards using a terminal application accessed over telnet. I don't know exactly what system it was, but the key commands certainly evoked thoughts of early mainframes.
It's not for the sake of having something new. New technologies do often provide obvious benefits. It's the cost of a new version (both in software development and reorganization of processes) that may be too high to justify these benefits.
