At one stage I suspected I was in charge of the oldest in use computer still running in the world.
In 2001, the Australian Navy still used the Mk152 computer. https://en.wikipedia.org/wiki/UNIVAC_418 on the last remaining Charles F Adams class destroyer, HMAS BRISBANE.
It was a general purpose computer entirely constructed from individual transistors with magnetic core memory. We had two of these onboard and if both were down we couldn't fire the missile system. I had 3 sailors dedicates solely to keeping these ancient machines running.
We got to diagnose some pretty cool bugs, like what happens when the card corresponding the the lowest significant bit of the least use register has an intermittent fault due to a bad mechanical connection.
That's pretty neat. My favorite of the older ones was the NSA machine that used mercury for memory. Report said overflow errors were more serious than on most systsms. ;)
I find the wording in this blog entry interesting - in particular "most in need of an upgrade".
In my opinion, hardware that can be repaired and software that has been running in production for years is not in need of an upgrade. The need to refresh software or hardware exists purely to keep vendors in business and even just to keep some I.T. departments busy and their C.V.'s up to date.
Provided a system is working reliably and is not dependent on changing external requirements there is no need to upgrade. The risk to a business or entity from the constant upgrade cycle is far greater than keeping something existing and tested running.
Some organizations are resistant to change and that's OK, but when systems are maintained to the point that they become a historical curiosity-- that's going a bit too far.
Aside from comically high maintenance costs (which only the government and perhaps banks can afford to pay), such organizations also need to _hire_, _train_ and _retain_ staff that can actually do their jobs on these things. It simply isn't feasible to keep let alone recruit strong talent in an environment where legacy goes beyond a certain level. Yeah, good employees _ARE_ going to be concerned about their C.V.'s and that is understandable.
An excessive "upgrade cycle" may, in some cases be risky, but a vastly more common problem is orgs that don't change/adapt/upgrade fast enough. That has risks and costs as well.
That's true except when said system needs to be repaired and there is no one left who knows how to work with any systems that old. In that case it can be painful finding someone knowledgeable enough to work with a system that old.
My rule of the thumb would be - if you can't buy a drop-in replacement and get it delivered in a week, it's outdated.
It doesn't even have to fail in a software/hardware specific way. If your floor collapses or is flooded, and you're using old mainframe with code written in Natural or similar, what's your DR story? Which actually makes me curious - does anyone know what the DR plans look like for companies using 70's mainframes? Let's say a critical S/370 in company basement? (and yes, I'm aware that new z series should virtualise that just fine, but in practice... if you lose a mainframe, what do you even do?)
I toured NORAD inside Cheyenne Mountain back in 1990 or '91, back when you had to submit background information to apply for the tour, and I saw that computing gear. It was amazing to see buildings on giants springs and caverns with Diesel locomotives in them for back-up power.
For sure there's still software written for the IBM 360/370 mainframe series in production, just running either natively or in emulation on a newer zSeries 'frame. "Mainframe" doesn't necessarily mean "old".
I used to run a couple hobbyist/enthusiast sites and mailing lists for people who collected and restored old DEC equipment (and I still run an all-systems-welcome "rescue" list). Shortly after 9/11, I got a phone call from someone working in the Pentagon who was looking for parts to repair a VAX that had been damaged...
I've started working with Z/OS on Zseries machines just a few months ago. Obviously, I'm still learning. There is a _lot_ to learn- it's nothing like linux :0
That's one of the reasons I like fiddling around with the Hercules emulator - exposure to a system that's completely and totally alien compared to what I have used for years and do for a living.
You're right, mainframes are huge in finance, and I wouldn't be surprised to find that the Fed uses them.
I found the second link you posted to be quite baffling; I have worked for several companies where I had to integrate newer and older systems, and I would never list "integration" as a reason to use a mainframe. Yes, it can be done, but in my experience the assumption is that the mainframe must be worked around, with all of its fixed-width EBCDIC glory.
Cuttler and a core of VMS team exited en masse to work on NT. In fact, he coined the term "WNT" as a play on "VMS", each letter is a successor to the corresponding one. (c.f. IBM <==> HAL)
They may just be lore at this point, but I've heard stories from friends in the government about older IRS records being kept on punchcards and read into S/360 family machines. The VA is also apparently heavily dependent on a legacy MUMPS[1] codebase, although that could run on more modern machines in principle.
I did contact work with the IRS from '06-'09, on the IMF and BMF (master file system) and I assure you there are no punch cards. Old school main frame assembly yes, but no punch cards.
The last I heard CADE2, the modernized (J2EE) system, had replaced the majority of the IMF functionality (IMF is the core of tax return processing). I'm not completely sure though as I haven't talked to those guys in over 4 years now.
There should be a way to connect a card reader to a newish System Z machine - IBM is famous for its legacy support - likely via some wonky shit over SNA. MUMPS is also fairly portable to new architectures as it was cross platform out of the gate.
S/360 and descendant mainframes have gone through 3 generations of IO technologies: bus & tag channel (parallel copper cabling), ESCON (proprietary 1990s era fibre optic system), FICON (Fibre Channel based). Contemporary System z mainframes only support FICON, whereas card punches/readers were only ever bus & tag. However, I'm aware that some third party vendors offer protocol converters between bus&tag and ESCON, and between ESCON and FICON, (e.g. Optica Prizm) so in theory it is possible you could use a bus&tag-ESCON and ESCON-FICON converter in series to connect your legacy card punch/reader to a new System z mainframe. I don't know if anyone has tried it, so I don't know if it actually works. (I also don't know to what degree the IO code to handle physical card punches/readers still works in contemporary mainframe OSes, although given that virtual card punches/readers are still used under z/VM, it is possible that some of that code might still handle real ones.)
Last I heard, the budget and plan to replace it got thrown out as a cost saving exercise, but I haven't been involved in the Hawaii tech scene for nearly 3 years now.
Considering that Unisys only recently stopped selling their traditional processors, I wouldn't be surprised if the original machines are still humming away somewhere that couldn't budget an upgrade to the newer stuff.
You'd be surprised. Lots of money number crunching and facility software does stuff like this. I've seen 486 boxes running door entry systems within the last 5 years.
I'm also aware of a network of NT4 Alpha boxes running in production.
In 2001, the Australian Navy still used the Mk152 computer. https://en.wikipedia.org/wiki/UNIVAC_418 on the last remaining Charles F Adams class destroyer, HMAS BRISBANE.
It was a general purpose computer entirely constructed from individual transistors with magnetic core memory. We had two of these onboard and if both were down we couldn't fire the missile system. I had 3 sailors dedicates solely to keeping these ancient machines running.
We got to diagnose some pretty cool bugs, like what happens when the card corresponding the the lowest significant bit of the least use register has an intermittent fault due to a bad mechanical connection.