Oldest software system in continuous use
guinnessworldrecords.com
guinnessworldrecords.com
The US DOD have built a COBOL to Java transpiler that emits nearly-idiomatic Java. As far as I can remember they expect it to essentially be reviewed like any other Java contribution from an engineer and receive minor tweaks, and they're expecting to translate millions of lines of code with it.
There's also MicroFocus, a company who build JVM COBOL, with all of the implementation/CPU specific bugs, so that you can move everything on to JVM (or maybe even CLR I think?) and then start replacing pieces with Java/C#.
It's not unreasonable for a company or organisation around since the 60s to have this sort of stuff around, however with all the modern options available today, it's pretty unreasonable for them to not have a convincing modernisation plan.
It seems like a truly insane effort to port 20e6 lines of assembly and expect to get identical behavior. I doubt the current behavior is even fully documented. Ensuring identical outputs for a lot of recorded data seems at least slightly more valid than trying to go back to documentation or requirements.
Perhaps the simplest way to migrate the IRS code is to make the laws simple enough you don't need 20e6 lines of assembly to implement it anymore?
Not 100% serious but then again seems like serious resources are put into this problem, so maybe worth a try
So much better written than Intel’s Software Developer Manuals, where anything complicated is just “look at these three pages of c-like pseudo code we probably pulled from our tests, good luck!”
IBM themselves have had to maintain backwards compatibility for > 50 years, and there is a long history of compatible machines: https://www.computerhistory.org/revolution/mainframe-compute...
So all the strange behaviours are well documented.
I think it would be a hard challenge to create such a beast, But did they also have to create a huge framework around it so that the Java could could interact with the same environment as the COBOL code?
That seems like a hard challenge as well.
The planning isn't the issue, it's the conviction, resolve, determination...whatever you want to call it.
COBOL modernization is quite expensive and fraught with major risk. You're talking about multi-year efforts where the key players who initiate the effort are often not around to see it through. Limited legacy resources, poor-to-absent documentation, mission critical systems...it's a mess no one internally wants to touch or take the fall for. MicroFocus, Blu Age (now part of AWS), TSRI, and plenty of other companies are happy to take your money and tell you it can be done, and it certainly can be done technically.
The reality is the cost benefit is often years down the line, so keeping the right people around to sustain the effort and see it through financially and technically is the tallest of enterprise orders. So it's the old two-step: 1) Pay IBM for another three years of support and licensing and 2) Go through the motions of migration planning then repeat Step 1.
Of course, bad code and bad data are cofactors.
On the subject of emulation, Sabre also had acquired a company called Agency Data Systems which was written for a Data General minicomputer using a language developed in-house. The guy who invented the language was named Hugh, so internally this was called "HUBOL" (the actual name was something else that only Hugh actually could remember). Some time in the 80s they decided to port it to a PC architecture but instead of porting ADS to a more modern language, they decided to build a DG emulator to run on a PC. When I was there, they were still updating the HUBOL source code (Y2K was a big deal at the time, plus with changes in the travel business, the updates were constant) but running on the homegrown DG emulator on a MS-DOS system. Hugh was quite a character. Back then we still had to wear a shirt and tie to work and Hugh's shirts all had these breast pockets that were stuffed with odd slips of paper. The joke was that he had run every project he'd worked on in the previous 30 years out of his shirt pocket, given the way things operated, there was probably some truth to that.
Somebody linked to Adam Fletcher's talk. Adam co-founded ITA which was eventually acquired by Google and probably is the basis for Google Flights. I saw a demo in probably early 1997 when they came around the startup I worked at looking for customers. Their software was written in Lisp and ran on a PC and was completely jaw-dropping. I never realized how bad Sabre's pricing software was until I saw what they were doing. ITA absolutely was the best pricing engine around at the time. In retrospect I probably should have quit my job and begged those guys to hire me.
Namely, C standard library was not reentrant safe, with considerable global variables et al - and the code on CICS (and I suspect TPF) had to be fully reentrant because it effectively ran inside green threads.
So, unless IBM wanted to advertise C that wouldn't contain standard standard library, modules written in C would be possibly dangerously playing with global side effects. Relatively recently this was solved by common runtime component whose name eludes me at this time, which underlies standard run times for C/C++ and I think Java, at least inside CICS
This is an absolutely wild pair of claims. Adam was nothing like (and does not claim to be) a co-founder and google flights is driven entirely by ITAs QPX product. ITA was a very good place to work.
It's kind of a joke to me that we're modernizing a small part of the whole system and still using 1960s-era backend systems. Polishing a turd.
"Java!" used to be talked about as a good way to create software that you could run in the future, but anyone who has had to keep around old laptops / old VMs to run ancient Java to handle KVMs or device management tools knows how ridiculous an expectation about the stability of Java can be.
"Windows!" is funny, because I can't tell you the number of places that have an ancient Windows PC that has either been repaired or carefully replaced with new enough, yet old enough hardware to still run Windows 2000 or XP, because copy protection is stupid, and / or because drivers for specific hardware can't be updated or run on newer Windows, and / or because the software can't be compiled and run on newer Windows without tons of work.
On the other hand, you can take large, complicated programs from the 1980s written in C and compile them on a modern Unix computer without issues, even when the modern computer is running architectures which hadn't even been dreamt of when the software was written...
That's not remotely true. Saying that as a Windows user for three last 35 years.
Usually something like:
1. Run these handful of commands that never actually fix anything but take hours to complete (sfc/dism/chkdsk/etc).
2. Reseat RAM/GPU/CMOS.
3. Out of ideas, may as well just fresh install.
Hard disagree. In my 20 years of experience, Java is very, very, extremely stable and backwards-compatible.
I would absolutely expect Java bytecode compiled in 1996 on Java 1.1 to have a very good chance to run without errors on a brand new Java 20 JVM, and source code from that time to compile with some very minor adjustments such as changing identifiers that clash with newly introduced keywords. Ironically, the older the code, the less likely it is to have problems with the post-Java 8 breaking changes.
But you talk about "handling KVMs or device management tools" - that's hardware stuff not covered by Java's standard API, so it will involve native code. That will bring you compatibility problems, not Java. Admittedly, that could be seen as Java avoiding the hard problems rather than solving them.
> On the other hand, you can take large, complicated programs from the 1980s written in C and compile them on a modern Unix computer without issues, even when the modern computer is running architectures which hadn't even been dreamt of when the software was written...
I want some of what you're smoking. Toy programs, sure. But nothing that does any kind of hardware interfacing (notice a theme?) or uses any but the most trivial syscalls (this would be pre POSIX), or makes any of a myriad common assumptions about hardware architecture (see https://catb.org/jargon/html/V/vaxocentrism.html). So how many large, complicated programs does that really leave?
But I think you're forgetting how much code is written to C89. How much of bash, for instance, is ancient, with updates that avoid newer toolchain features so that it can be as portable as possible?
Yes, people don't often write stuff with portability as a goal at the beginning, but once something is relatively portable, it stays that way. Lots of code that wasn't poorly written made it from all-the-world's-a-VAX to i386, from i386 to amd64, and now ARM and aarch64, with a minimum of extra effort. There just had to be a little effort to NOT program like a jerk, which, as funny as it is, is still an issue now.
I'm running Pine as my daily email program, which was written in 1989 and hasn't had any real updates since 2005. New architecture? Compile it. Lots of modern software started out as C software from the 1980s.
If it's over the network (using IP sockets), Java can do it just fine and what I wrote about downwards compatibility applies. Same if it's a Swing GUI, which is part of the standard API. Admittedly, Swing is the area where I once witnessed a real bug caused by version incompatibility; IIRC code made some assumptions about undocumented behaviour in event handling, which caused an endless loop on a newer JVM.
As for portable C, I have very limited experience really working with C, but remember trying to get some tarballs to compile and having big problems with fragile autoconf scripts.
And it is still actively used.
Software like things can be done with it, but this is no different than treating a bunch of pipes, valves, and a water source as a computer. (Edit to add: Which would make our sewers the oldest hardware system. And I'm sure there are supercentenarians still pumping software through those systems.)
I imagine that many physicists feel about physics envy the same way I feel about imagining biology as software. https://en.wikipedia.org/wiki/Physics_envy
Maybe someday we'll have a grand unified theory of everything imaginable and real. But even then distinctions should be made between levels of emergent phenomena. A habitable environment allows biology to exist. Biology allows intelligent beings to exist. Intelligent beings create tools that allow them to make even more tools that do predictable, or otherwise defined, sequences based on various inputs. Hardware is two levels above biology, and software is a level above that.
From a conceptual point of view that can be grabbed by some human mind, this all make perfect sense.
However, these hierarchies tell more about our way to handle sensedata than it reveals of the actual structure of the universe, if this does match anything relevant past our thoughts.
It's important to recognize what thinking modality is best fit for a particular idea. You could instead describe this as a line of entropy. A pre-requisite chain. A web of interconnections. Whatever. And certainly it's grossly simplistic to describe it the way I did as being "two levels above", when these levels are based only on ad hoc categorical conveniences.
I agree with you. My describing it this way was a matter of convenience to describe an underlying truth of required precursors. When we have Von Neumann machines capable of evolving their code the link between software and the DNA/RNA system will be a better analogy than it is now. But an analogy is not an equivalence.
https://www.sabre.com/insights/releases/sabre-forges-10-year...
I googled "oldest software still in use" and the rest of the internet think it's MOCAS, the USA DOD contract management software, launched in 1958, two years earlier than Guinness' earliest guess for either of its options mentioned in the article: https://fossbytes.com/mocas-worlds-oldest-computer-program/
Sorry to be "that guy" but I'm just really cynical about Guinness and records in general. Plenty of their records really are just fun, and I can't find a profit angle for this article for either the IRS or whoever manages SABRE, so I guess I'm just being a snark.
As an aside, I always thought "snark" was a real word, but apparently it's a neologism meaning "snide or sarcastic remark". It's also the name of various fictional creatures, including The Hunting of the Snark by Lewis Carroll, as well as in A Song of Ice and Fire.
Not an absolute definitive agency, and when there EXISTS a more official agency, take those; but it's a fun read of "these are reasonably close to the extreme in this obscure area I never thought of"
In case this is news to anybody, the basic shape of the grift is that while anyone can theoretically apply for a record and submit proof, the requirements are fairly stringent and complex. And wouldn't you know it, Guinness World Records offers various levels of "consulting" on setting/breaking a record, including defining the record to break, setting up an event, and flying out an adjudicator to witness the record being broken.
I have had 'continuously running' software system in house as old as they reference. From first hand experience, I'd imagine it's not something folks are crowing about.
Your reference is older than what I had in house.
I think the point I was trying to make is if a substantial amount has been changed, on what basis is it still considered “old”?
If every plank and nail of the ship is replaced during it’s voyage, is it still the same “old” ship that disembarked?
It would be interesting to run a diff of snapshots of any software in 1960 and its 2060 version, if e.g. SABRE or the IRS system may last that long.
Is it though? Or are you assuming it has to be replaced life-for-like? If so, why don't we apply the same to software? I don't think that constraint is a given with hardware. Is a remodeled house constrained by it's original design? It seems to come down to how much you want to invest in "refactoring" the old house.
Your comment made me think of the evolution of the F/A-18. The new variants are utterly different than their original, yet are still technically the same airframe.
This is what Boeing had in the 737MAX. It was a different aircraft, but it looked like the 737-800.
Before DNA sequencing became efficient, a particular protein inside the ribosome was used to study genetic divergence.
There is also an entry on IRS Individual Master File, but is short on information: https://en.wikipedia.org/wiki/Individual_Master_File
I remember spending whole evenings piecing together flights for a round-the-world trip at lowest cost. There was little or no error checking. I once almost booked a flight to Sydney, Nova Scotia, instead of the one down under.
Then, tragically, Travelocity shut down the service, leaving their crappy web-based frontend as the only online booking option until ITA came along.
... any confusion is obviously your own fault
I've never used Java professionally, but that's probably what I'd pick. Seems to hit the sweet spot between time-tested, widely-used, enterprise-proven, performant, future-proof/portable, and well-understood. Seems from another comment that's what US DOD is betting on, as well.
Maybe TeX, written in 1982? Though pdfTeX displaced the classic TeX DVI compiler long ago, and all the major TeX distributions translate the Pascal source code to C. I don't know whether that means it's a different program from the one Knuth wrote 40 years ago.
https://en.m.wikipedia.org/wiki/Basic_Linear_Algebra_Subprog...
Becoming a secret travel agent.
Travel booking systems are among the oldest global IT infrastructures, and have changed surprisingly little since the 80s. The personal information contained in these systems is hence not well secured by today's standards. This talk shows real-world hacking risks from tracking travelers to stealing flights.
Airline reservation systems grew from mainframes with green-screen terminals to modern-looking XML/SOAP APIs to access those same mainframes.
The systems lack central concepts of IT security, in particular good authentication and proper access control.
We show how these weaknesses translate into disclosure of traveler's personal information and would allow several forms of fraud and theft, if left unfixed.
A decade ago, a family friend with a band wanted help with burning their CDs.
Timidly, "hat in hand, eyes down", they asked if I could maybe, possibly, add 2 seconds of silence in front of their recorded tracks? It's OK if I couldn't, they'd understand.
"I finished it while we were talking"
"Really?? Amazing!! That's awesome! Didn't know you could do that!!
Now, can you also remove John's guitar from this song?"
They really had no clue that removing an instrument from a finished mix is HARD, as opposed to adding 2 seconds of silence (and for context this was years before the current deluge of "AI Powered" apps that might conceivably actually do that).
That's literally jobs for life for some (un)lucky team.
The oldest software system known to us, and in continuous use would be 'religion'. The hardware in this case is obviously humans. If you observe, the computer and its I/O all are derived from the hardware known to humans, and it is the human itself.
If you see, the hardware features rarely changed, but the software in this case updated and adapted to all situations and has been running for many centuries now. It probably can be related to STUXNET or affects only certain type of hardware. I know this is not the original post about, but this just came out as a thought.
I'm fairly glad I declined.
Migration to a new language is nothing but an extreme form of maintenance. And it's not even that expensive. We're just used to scales of a dozen or so programmers at best.
As a very conservative estimate, translation from assembly to, say, Java, should proceed at the pace of maybe 100 lines per day on average. So a team of 100 developers would need a year or so to translate a 20M lines application. Of course, there's also the effort to create tooling and the framework of the new application, but it's certainly doable.
It might even be better if your team was smaller.
There’s a lot of overhead spent on communication. Probably even more so when converting legacy software.
The IRS has been trying to modernize for decades.
Here's something from way back in the Clinton admin:
https://clintonwhitehouse4.archives.gov/pcscb/rmo_irs.html
But you'll never hear anyone there actually be responsible for the failures. They'll always whine about needing even more money.
An emulator could certainly beat the performance of something you could watch execute on incandescent lightbulbs.