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 worked on some PL/I from '72 a few years ago...still chugging along just fine. (4 years older than me)
:wq
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.
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
Much air traffic control software is still the same that's been running since the 70's. I can vouch for having seen a machine, in use, that was programmed by flipping switches on the front. Most aren't that old, but many small airports (and some larger ones) are running the same old software, just patched as needed through the years.
It's the "it works, it was designed to never ever break, let's not mess with it" principle.
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
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.
Up until December last year I worked as a Reactor Physics Engineer at a nuclear power station in Essex, UK. That summer, the Honeywell 316 (16-bit mini with 16k words of RAM and 160k "hard disk") had just been relegated from its role as primary reactor temperature monitoring computer, to that of secondary. The "new" machines were second-hand PDP11's running RSX11/M and a custom compiled language and libraries called CUTLASS (originally developed by the CEGB).
The Honeywell monitored both reactors, each having several hundred thermocoples. It had a teletype for the console and two green-screen terminals for the reactor operators.
It had no filesystem on the disk. Data was stored directly in disk blocks and numbers were entered in octal. There was a paper tape punch for backup and loading the operating system.
There was a Fortran IV compiler and a shelf full of manuals. The machine was bought and comissioned in 1972 (two years before I was born) and the software (including multi-tasking OS) was partly developed then by one of my former colleagues who retired a few years ago.
Ink ribbons for the teletype were no longer available, so we had a bottle of Quink and surgeons gloves....
Finally, one Friday last summer, sectors started to dissapear from the built-in disk. There was a spare that had been sitting in the store since 1972 but no one knew how to fit it, how to set it up or anything, and bits had been cannibalised over the years.
As far as I know, it still sits in it's wee room dark and quiet.
I never thought I'd ever have to boot a machine by toggling switches to load memory directly, in my life.... but that's the British nuclear industry for you.
Conservative (and lethargic) are understatements.
I'm out of my tree just now but please feel free to leave a banana.