Slashdot Mirror
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?
I forget how old the system has been in place as I have never seen it, but I know a guy at a bank who has been working on the same credit card system software for his entire carere. It's been about 30-35 years now, which puts it at about 1966 to 1971, and writen in cobal.
Who wants Pork Chops?
I do have some code in the same environment that hasn't seen much change since the mid to late 80s. (680x0 assembler, to boot).
You could've hired me.
Don't hold me to this, but I think some of the software on the Pioneer probes was written in the 1970's.
I like to play children's songs in minor keys.
"We're all sons of bitches now." --J. Robert Oppenheimer
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.
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.
"I figure you're here 'cause you need some whacko who's willing to stick his finger in the fan. So who are we helping?
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.
Conformity is the jailer of freedom and enemy of growth. -JFK
The software I support was originally writtten in 1974. Not so Bad except for the fact we still SELL it. Modified to support faster PC's But the base code is still the same. You should see when We hire sombody New and Hand them A DOS 6.22 Manual and say "some of these commands Are from A Newer version of DOS."
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.
"The future's good and the present is nothing to sneeze at." - Roblimo's last
30 year old code shouldn't be a suprise, it should be taken as a counterexample to the "If bridges were designed like software..." argument. There are a lot of things that are in constant use that hold up to countless years of abuse.
If you want to compare software to machines, there are plenty of things that've been arround longre than 20-30yrs. The B-52 bombers, originally built durring the cold war are flying over Afghanistan as we speak. I've seen machining equipment built in the 20s still in regular use at machine shops (granted, many of them have been supplanted by CNC gear, but they're still accurate & reliable). Some of the massive earthmoving equipment used in mining has been in 24/7 operation for 40-50 years.
Or, if you consider software less of a physical thing, there are many abstraction that still work fine. The American government was established over 200 years ago, and, nitpicking asside, is still doing a damned good job. Mathematics and philosophy are considerably older, and most of it still valid today. Lets not forget that most of the planet practices religions that are over a millenia old.
Compared to that, what is a 20yr old piece of software? I'm sure many of us would -love- to throw away the old COBOL running dinosaurs and replace them with something more modern, but weren't the greatest of the Medieval cathedrals the ones in which the designers stuck to the descisions of previous designers, rather than taking off on their own tangents?
my sig's at the bottom of the page.
I got a call in 1999 from the MD at my first-ever job - back in 1983. It turns out that the dBase II code I'd written for them to produce engineering job status documents had blown up, and could I fix it?
I went in, had a look at the source and recalled that I couldn't document it as the code was interpreted and the original IBM-PC it ran on was so slow that stripping out comments yielded a significant performance improvement.
Luckily the code itself was OK - the 5Mb hard disc had finally filled up. Imagine a PC hard disc running for 18 years without a problem! This was one of the original PC hard discs - external box, separate power supply, cabled to the PC with a monster cable that was barely flexible enough to bend through the required 180 degrees to plug it in at both ends. Oh yeah, DOS 2.1 as well - I remember upgrading that same PC from DOS 1.1 to get those new fangled "directories" that sounded pretty cool.
Not tough to fix - whoever had been using it had lost the original documentation (probably 10+ years ago) and didn't know how to archive off the old data to floppies. Wait a minute - where do you get 5.25" floppies these days? After a bit of consultation, we agreed that some of the contracts that hadn't been updated for 15+ years were probably pretty much useless these days, so I went in and deleted the individual records, packed the table and they were up and running with about 500k of free space. That should have seen them through to Y2k, when who knows what would've happened...
I didn't bother to invoice them for the work - I figured the story was worth enough on its own.