Oldest Software Seen in Production?

Ian Bevan asks: "In my last job we were replacing a legacy system, written in COBOL and running on a Fujitsu mainframe since 1985 (it was a payroll application). A bespoke database application I wrote in 1989 was still being used, unmodified, last year. What's the oldest software you know of still in production? Anybody know of anything from the 70s, or even 60s ? What's it used for?" Has anyone seen software in production that is older than they are?

Comments

NASA

[Nater]

Don't hold me to this, but I think some of the software on the Pioneer probes was written in the 1970's.

Computer Associates, Keeper of the Old

[Snowfox]

Any time you want to find the Ancient Ones, look at the heart of any big and old company. Invariably you'll find a package or two which they're afraid to touch for fear of breaking some business fundamental, i.e. payroll or inventory.

And Computer Associates seems to have their name on that package every time. From what I can tell, CA seems to specialize in buying up ancient software and maintaining it.

When I was doing database consulting, I ran across a number of payroll packages which had been purchased by CA, always running on some mainframe that'd dim the lights when it ran, but which seemed to do nothing that a desktop PC couldn't.

CA's got a good deal. From what I've seen, they don't update the software, save for critical fixes (Y2K, etc). They merely collect annual license fees on top of support costs.

When I'd tell companies that I could take users off their green screens without moving away from the CA package, rather than replacing the CA package as every other contractor had wanted to do, I'd always have their ear. Typically, I'd make a mint by making form applications and data importers/exporters which usually took longer to spec out than to write.

My core memory still has some 000s and 111s in it

[Ocelot Wreak]

If you have a chunk of core memory (you remember: little teeeny iron donuts strung on fine copper wires in a grid that would write and read the direction of the magnetic field on each iron magnet, manufactured by a woman handling a sewing needle peering through a microscope), and the donuts are still magnetized and thus the chunk of memory still has a "program" in it, does that count? Could it be said to be still "running?" [It's certainly "persistent!"]

I like to bring the panel of core memory out at geek parties and show it to the younger crowd and see the reaction - usually disbelief. I also have a DECtape with all my Algol and DECSYSTEM-10 assembler programs from 1969-74. [DECSYSTEM-10: world's first useful multiuser timesharing systems - one model of the 36-bit Digital Equipment Corporation (DEC) computers. Beautifully designed, giant cabinets w/cool colours, toggle switches, flashing lights - everything that made a computer the best-est toy in the whole world!] A DEC engineer once showed us how you could roll the tape out on the floor, jump on it, roll it back up and still read the data off it, there was so much redundancy built in. [The tape is about an inch wide.] Too bad there are no DECtape drives still in existence that I could use to copy the files... *sigh* CompuServe also ran on DEC-10s for many, many years.

See URL:

http://www.columbia.edu/acis/history/pdp10.html

for some nice pics, history and links...

-Ocelot Wreak.

1967

[duffbeer703]

One of the mainframes that takes up some space in our data center now spends all of it's days running the climate control, utility and elevator management software for the state capitol and various gov't buildings.

I believe they are planning on writing a replacement to run on Sun or IBM unix boxes, but it probaly won't be done for 5-7 years (it's low-priority, since the current system is fine until the people who run it retire in 10 years)

The mainframe is from the late 80's, but the initial revision of the software (now on version 6.6 or something) was coded in 1967.

Ancient Code is all over the place

[dublin]

Heck, there's "living fossil" code under every rock in most large corporations, especially those technically oriented.

I've seen some seriously old code running in the aerospace and oilfiled exploration areas - in some cases, the old algorithms really can't be improved that much, in others, the code has been kept alive through heroic methods simply because the source (or anyone that understood it) was lost to the company decades ago. You'd be amazed at how many PDP-11s or 16s are still in service as factory process controllers - they were the standard in Manufacturing and refineries just a few years ago - if Compaq hadn't pulled support, thier users wouldn't even be migrating off the things - they're dead simple and just flat bulletproof.

This can even happen in relatively new large companies: The heart of Dell's build-to-order production system is a pile of extremely crufty Tandem code that is only partially understood by no more than maybe a half-dozen old-timers, most of whom aren't programmers. It's a good thing that the Non-Stop architecture hasn't changed too much in years - they've been relying on Moore's law to make the old code scale enough to accommodate their growth. (Dell may finally be moving off the Tandem by now - Compaq's acquisition of Tandem really tweaked Dell - they couldn't stand being so reliant on *Compaq* for the core technology their whole business is based upon, although they also rely on Sun for all the data warehousing that drives their marketing and sales machine. I know because I considered a job running the "secret" Sun data center at Dell, the one with no windows, that customers never see...)

NASA has tons of ancient code, much of which runs pretty much as it was ages ago - This is partly because NASA's planning horizon is so far out that they have to freeze the hardware years before it goes into production. For example, the primary computing infrastructure for the ISS was frozen about 1995 as being based on the '486 and 640x480 VGA displays. (I was at Sun at the time, and had a heck of a time finding 6x4 S-Bus display adapters for a project at JSC - NASA considered some exceptions to the Intel rule, but not many...) Around the same time, I had a meeting with another group of JSC ISS engineers to find a suitable computer for another part of the station. They were terribly concerned about weight, heat, physical size, and resilience to vibration, but get this, they *insisted* on VME-bus architecture, which had alreaady been obsolete for more than a decade and would be about the worst choice possible to meet their needs, not to mention banishing any hope of acceptable performance. And some people wonder how NASA can waste so much money...

Of course, Unix itself falls into the category of ancient software still in production use for those that run BSD or other *real* Unix, not that wimpy GNU stuff with those perverted "--" options and the like... ;-)

I know for a fact that some companies I've worked for (and shall remain nameless) have decades-old code that they've used various binary conversion tools on because the source was lost long ago, and it would cost too much to rebuild the program from scratch. Sometimes even having the source doesn't do you much good when the Fortran source has made rugged transitions across several version s of Fortran before being unceremoniously dumped into a Fortran-to-C translator (to "run in the modern world", like Fortran doesn't...) The C source that now comprises the "current" source of these apps is so ugly no one will *ever* maintain it, so it will likely limp on for decades more.

As a last observation, good computer architectures tend to allow code to stay in use for a very long time: current IBM mainframes still run code from the 360 days just fine, VAX and PDP code has lasted darn near forever, and it's quite apparent that Sun's unique commitment to binary compatibility will carry some old apps well into the future with thier customers as well... (Most people don't know it, but this is one of the cooler things about Sun - they are adamant about binary compatibility: the same exact Solaris code that ran on your original SPARCstation 1 will run unmodified (but a whole lot faster) on the latest UltraSPARC behemoth. Both the hardware and the OS have been carefully designed to make architecture transitions totally seamless, one big reason Sun's kicked butt against HP, SGI, IBM and DEC/Compaq, all of which thought it was OK to force their customers to throw away all their old stuff for the new. Of course, nobody else has Bill Joy to plan these things through 5 years before they're needed, either. The amazing thing about Bill's architectures is that Sun has provided binary compatibilty without paying any penalty for legacy support. That's just plain cool.