Slashdot Mirror
Windows 3.1 Glitch Causes Problems At French Airport -- Wait, 3.1? (vice.com)
OakDragon writes: Microsoft has tamped down the earth on XP's grave, steered Internet Explorer toward the nursing home, and is trying to convince everyone Windows 10 is a bright up-and-comer. But in the Paris airport of Orly, a system called DECOR — which helps air traffic controllers relay weather information to pilots — is running on Windows 3.1. That program suffered a glitch recently that grounded planes for some time. The airport actually runs on a variety of old systems, including Windows XP and UNIX. Maintenance is a problem. There are only three people in Paris that work on DECOR issues, and one of them is retiring soon. Hardware is also an issue. "Sometimes we have to go rummaging on eBay to replace certain parts," said Fiacre. "In any case, these machines were not designed to keep working for more than 20 years."
You're both wrong. The reason why these machines weren't virtualized a while ago is that you have to make a lot of serial/parallel/ps2 conversions for ports that are truly physical. These are the types of programs that send specific voltage down the wires and expect exactly something specific in return. Lots of times you try to get those returns right and you simply can't anticipate the various bugs that amazingly show up just a few months after you convert. The real problem? Some are nearly unsolveable. You can't even figure out what the manufacturer/programmer was trying to achieve with their hardware interface so it's best to simply leave eveything as is. Half these people don't even work in computers anymore, let alone the vendor they were at in the 80's.
This coming from a guy who espouses VMs every day on a variety of systems.
When the foot seeks the place of the head, the line is crossed. Know your place. Keep your place. Be a shoe.
I have some old VB apps from the 3.1 era.
Although it may be technically possible to get them running, it's certainly not as easy as just copying the files across and running the program.
The fact that it is to do with weather suggests it interfaces with hardware of some kind or some external services. That's where you'll REALLY hit problems that just running as admin or renaming files or providing substitutes isn't going to fix.
Good luck getting a driver from the 3.1 era working on anything at all nowadays, even emulated. You would literally just be better off throwing it out, starting again and suffering the inconvenience.
And, more importantly, it's also why you can't always replace those mainframe systems: because it works, and has worked for decades.
I've been on projects to replace aging mainframe stuff, some of which went back to the mid 60s or so.
You could start off trying to design a replacement, gather requirements, and design something which works on your assumptions and in the limited use cases you've seen.
And the more you delve into it, and discover all of the exceptions, corner cases, "didn't we tell you that?", sheer size of the data, all of the hairy bits, the 50 other systems which tie into that system and would also need to be replaced or updated ... you can quickly reach the point where you really can't design a system which does the same things, you can't replace all of the integration points, you can't even really map out all the logic and business rules embedded in that system.
At the end of the day I've seen at least two such projects utterly fail.
Say what you will about legacy mainframe stuff. But they work, are so closely tied into the entire business and other systems that you can't simply swap them out as easily as people think you can, and as often as not are vastly more complex than you can possibly know until it's too late.
They're old, clunky, convoluted, and utterly mission critical. And when every other computer system in the company ties into them to extract data, you quickly realize you can't possibly update all of them.
That, and you might also find that you simply can't match the performance and throughput of those damned things.
A mainframe is a big lumbering beast. But it's a big lumbering beast which has kept the company moving for decades, hasn't had much in the way of downtime, has been expanded and added onto over the years, and in many cases will cost so much damned money to replace that nobody can afford to do it.
The guys coming in thinking they can whip up something in .NET, running SQL server, and on one machine? They often have no idea of just how big of a task they're trying to take on.
Personally, I would run screaming in the opposite direction from any project trying to replace a mainframe that's been in service for a long period. Because the scope of those things, and extent to which they interact with everything else in the company can be mind-boggling.
Lost at C:>. Found at C.