Oldest Supported Software?
Dave Santek writes "In development since the early 1970s, the McIDAS [Man computer Interactive Data Access System] software celebrated its 30th anniversary in October 2003. McIDAS is used to integrate and visualize weather information. The software was originally run on a Datacraft /5 and has gone through 4 major hardware configuration changes over the last 30 years. It is a supported software package that remains in use at more than 100 locations worldwide. A history of the first 25 years (pdf) is available. A freeware version of the software is also available."
The Integrated Data Retrieval System had been part of the American tax administration since the mid 60s. It's not 40 years old yet, but it probably will be before it is replaced.
It may not be just, but it is fair, and that is more important.
Contrary to what many slashdot readers seem to think, election coding is non-trivial, encompassing variations in laws and tradition in virtually every county of every state in the US. Since execution time is not an issue, and accuracy is, emulation and translation make lots of sense.
"Eve of Destruction", it's not just for old hippies anymore...
Sadly TeX is being replaced by (what else?) Microsoft Word. Not for scientific documents yet, but in businesses and governments around the world people stuggle to get page references and a proper index out of Microsoft Word. Those poor, damned souls.
In Soviet America the banks rob you!
NASA still runs software, to this day, from the 1960s due to funding cuts and that fact that it "still works," much of it on the same computers from the 1960s.
In fact, most of this software is so old it actually can no longer be maintained because the people who wrote it are DEAD, and modern programmers who replaced the retirees can't make heads or tails of all the spaghetti code within. There's all kinds of fascinating data from the golden age of space exploration that we could still use, but it's in proprietary, decayed backup formats in proprietary structures.
If they started using Linux and open standards now, though, 30-40 years from now, they won't be having this problem, as Linux will still be around then -- and the rest will be in the dustbin of history.
However, I believe that a version of IBM's DITTO was available on System/360 in 1965. I've not been able to confirm this, though.
The situation isn't as simple or straightforward as that, and in may ways, it's much worse (TeX documents taken by a publisher, poured into Word for copyediting, then typeset in Quark w/ all equations reset using proprietary XTensions such as PowerMath or York Graphics' XMath).
;)
Opensource software in many ways is catching up and surpassing Word---LyX, http://www.lyx.org is one of the most promising and innovative, a ``What You See Is What You Mean'' document processor, it's actually used by some compositors to make LaTeX documents accessible to mere mortals so that they may then by typeset using the publisher's style---let me know what you think of Kaplan's _Introduction to Scientific Computation_, just released
William
Sphinx of black quartz, judge my vow.
Insurance Companies are still running mainframe systems to track your annuities and policies that have been under active development and support since the 1960's.
Systems like lifecomm, all writen in assembly are still worked on.
-L
Old truckers never die, they just get a new peterbilt
Canada started working on its replacements long after the FAA but it looks like we'll get there sooner. Like the FAA, we initially contracted a system called CAATS that would have done most of the things proposed by AAS. Somewhere in the mid-90's it became obvious that the proposal was pie-in-the-sky and the contractors would never be able to deliver -- every time the players sat down to review the situation they ended up reducing the goals of the project and delaying the acceptance date. Since the existing systems were starting to fall apart we switched to off-the-shelf systems (HP Unix boxes with Sony 2kx2k displays) running software that emulated the old vector tube displays. The main computers were essentially unaware that they were talking to modern hardware. The privatized ATC system also started rewriting the host software to run under Unix, and will be replacing the old hardware in 2004-2005. At that point we will have a new host emulating an old host, talking to new displays emulating old displays. Once a bug-for-bug clone is operational, we will be able to look at modernizing the software to take advantage of the increased computing power available. The original CAATS project has been scaled back to the point where it's little more than a shim layer that manipulates data passing between the host and the displays.
The British have already purchased a few ATC support systems from Canada and are considering more of them. Since they are running on similar hardware, there's a good chance that we will see common software running on both sides of the Atlantic by the end of the decade.
The FAA has looked at some of our systems. As the parent post said, however, they no longer know how their own system works and are terrified at the prospect of changing just a portion lest the whole house of cards falls down.
BTW, with reference to the topic at hand, we are just now replacing our 30-year-old ATC weather system. The original OIDS system ran on an Interdata-70 system with core storage and tape I/O. The only significant changes in the last 30 years was the switch to TTL memory and the addition of a floppy controller (that simulates a tape device). We still boot the machine using the binary switches on the front panel.... The replacement system runs on a network of NT4 machines and has been installed at about half of our facilities. I'm hoping the old system is donated to a computer museum.
You guys have more airports and more aircraft but also more sectors and more controllers. The net effect is that the number of flights handled at any one display is roughly constant (and limited by human capabilities).
The real reason the FAA isn't using the Canadian solution is that it's not complete. As I mentioned elsewhere in this thread, we are replacing systems one component at a time using emulation on modern hardware. Our components aren't interchangeable with your components due to differences in system architecture. They might do well to consider following our approach to the problem, but I doubt the resulting systems will ever converge.
...DATACRAFT? Wow, did that bring back memories. However, I suddenly realized that more than coincidence was at work, when I went to the McIDAS website and saw the "Dayton Street, Madison" address.
The University of Wisconsin, circa the late seventies, was a hotbed of Datacraft users. I believe it was Geophysics that pioneered their use with a Datacraft 6024/3. They introduced the cheaper 6024/5 at about the same time Digital came out with, IIRC, the PDP-11/20.
Departments at UW that needed minicomputers in the $50,000 class started buying Datacrafts right and left. Digital lost a lot of sales selling PDP-11's against Datacrafts. But the price/performance comparison, at that time and place, was really compellingly in favor of Datacraft.
Datacraft was headquartered in Fort Lauderdale, and I believe a lot of its engineering staff consisted of Cuban emigres. The Datacraft machines were 24 bits versus Digital's 16. I forget how many bits were in the mantissa and exponent, but there was a very usable 24-bit floating-point format. The instruction set was well designed for doing floating point without a dedicated processor (though a dedicated FPU was available). One of the things that sold us on the Datacraft was that without an FPU, the Datacraft's times for floating point add, subtract, multiply, and divide were all less than forty microseconds; the comparable times for Digital was about a millisecond.
The Datacraft had a hardware square root function.
The instruction set was the most godawful asymmetrical mess I've ever seen. If you were used to the elegant orthogonality of, say, a PDP-8, a Datacraft was a bit of a shock. (It made even a 6502 look pretty). Most instructions took a 15-bit address, and the natural address space was limited to 32K (of 24-bit words). However, in order to win some bid that required 65K, they had shoehorned in a few instructions that accepted a 16-bit address. This meant that when working in an address space of more than 32K, the linker (and compiler) had to keep track of an incredible number of linkage flavors, and probably about half the bugs reported had to do with things that happened when you crossed the 32K boundary.
There were three sort-of-index registers, named I, J, and K (if you used the variables I, J, and K in a FORTRAN program they were automatically assigned to the index registers). They were all slightly specialized, though. I don't remember what each of them did, but there were some instructions in which the I register, and only the I register had some special role, and ditto for J and K.
There was a 3-bit index register field, and most of the instructions that moved data into or out of index registers used the field to specify the register. That meant, of course, that those instructions could NOT themselves perform indexed addressing.
A very cool feature was an instruction that swapped the contents of a register and memory in a single cycle. The same architectural feature that enabled this also enabled another cool feature: there were functions that simultaneously set a word to all zeros or all ones and set the condition register to reflect the previous contents of the word. That is, a single instruction could you whether a word was zero or nonzero at the same time as it set it to zero.
Generally speaking--if there was anything general about the architecture, which I doubt--you could, at the binary level, specify more than one index register, which resulted in storage into all of the specified registers if it was a store instruction or loading the OR of the contents of the specified register if it was a load instruction. This resulted in a lot of possible instructions for which there were no assembler mnemonics defined. (And the assembler syntax was IBM-style card-oriented, with a single mnemonic going in a specified set of columns--you couldn't just OR the mnemonics themselves). Some of these instructions were actually useful, and there was always controversy, never quite resolved by Datacraft, as t
"How to Do Nothing," kids activities, back in print!
IBM IMS is over 35 years old (the first version dates from August 14, 1968, the same day Halle Berry was born). It's still supported.
IBM's First OS for the 16k IBM 360 model 30 in 1964 was DOS. DOS evolved to DOS/VS release 34 by 1968. DOS/VS release 34 is still supported and runs on several hundred systems. The LAST bug in DOS/VS r34 was fixed in 1980.